nignx正向代理，nginx反向代理

nginx正向代理

• 正向代理就是假設有一個內網
• 內網有兩臺機器，這兩臺機器只有 a 能夠上網
• b 不能上網，可是 a 和 b 經過網絡相鏈接
• 這時若是 b 想訪問外網，就能夠經過 a 來正向代理訪問外網
• 正向代理就是在內網中模擬目標服務器，把內網中其它機器的請求
• 轉發給外網中的真正的目標服務器
• 因此正向代理是接受內網其它機器的請求的
• 反向代理則是反過來
• 也是一個內網，有幾臺機器，只有其中一臺與外網鏈接
• 可是反向代理接受的不是內網機器的訪問請求
• 反向代理接受的是外網過來的訪問請求
• 而後把請求轉發到內網中的其它機器上去
• 外網發出請求的用戶並不知道反向代理的服務器把請求轉發給了誰
• 要在一臺機器上設置正向代理的功能
• 如圖，編輯一個nginx配置文件
• 上圖就是配置文件內容
• 若是配置一臺服務器做爲正向代理服務器
• 那麼這個虛擬主機配置文件就必須是默認虛擬主機
• 由於全部訪問這臺機器的網絡請求應該先訪問這個虛擬主機纔對
• 因此這裏要設置 default_server
• 而後還要把原來的 默認虛擬主機 配置文件名稱修改掉
• 如圖，把 default.conf 配置文件的名稱修改一下
• 這樣就取消了原來的默認虛擬主機配置文件了
• 由於默認的默認虛擬主機配置文件就是 default.conf
• 配置文件裏面的 resolver 119.29.29.29
• 意思是配置一個 dns 地址
• 由於是作正向代理，接受了內網請求的域名後
• 要把請求發送給真正要訪問的服務器
• 可是內網發送的域名是沒有包含 ip 地址的
• 因此還要把域名發送給 dns 服務器解析 ip 地址
• 拿到 ip地址後才能轉發到要訪問的服務器上去
• 因此這裏須要配置一個 dns 地址
• 接受了內網域名後，就會把域名發送到這個 dns 上去解析
• 下面的 location 按照圖中設置就能夠了
• 這樣正向代理服務器接受內網機器請求後
• 就會把域名發到配置的dns上解析，而後訪問真正的服務器
• 再把真正服務器返回的內容發送給發出請求的內網機器

nginx反向代理

• 作一個反向代理的例子
• 如圖創建一個測試的虛擬主機配置文件
• 監聽 8080 端口，域名爲 www.test.com
• 根目錄是 /data/wwwroot/test.com
• 訪問虛擬主機顯示的首頁文件是 index.html
• 如圖，建立虛擬主機的根目錄 /data/wwwroot/test.com
• 而後使用 echo "test.com_8080" > !$/index.html
• 建立一個內容爲 test.com_8080 的首頁文件
• 這個文件在 /data/wwwroot/test.com 目錄裏面
• 如圖，新建一個反向代理的虛擬主機配置文件
• 監聽 80 端口，域名爲 www.test.com
• 下面的 location / 裏面就是反向代理的配置
• 當訪問這個虛擬主機的時候，就會把訪問請求發送給 127.0.0.1:8080
• 如圖，使用 curl 訪問 127.0.0.1:8080 虛擬主機
• 成功返回了 test.com_8080 這說明這個虛擬主機可以被訪問
• 如圖，再建立一個虛擬主機配置文件
• 跟以前的 test 虛擬主機差很少
• 可是這個虛擬主機並無設置 域名
• location 設置返回的內容是 8080 default 字符串
• 保存退出，重載 nginx
• 還要把 test虛擬主機的 default server 設置取消掉
• 那麼如今 127.0.0.1:8080 對應兩個虛擬主機
• 一個是 test 虛擬主機，另一個是 8080 default 虛擬主機
• 這兩個虛擬主機的 ip 端口都是如出一轍的
• 它們的區別是 test 虛擬主機是有域名的
• 而 8080 default 虛擬主機是沒有域名的
• 如今已經設置了 8080 default 爲默認虛擬主機
• 因此若是隻訪問 127.0.0.1:8080 的話
• 訪問的必定是 8080 default 虛擬主機
• 若是想訪問 test 虛擬主機，就須要加上 test 虛擬主機的域名
• 才能成功訪問 test 虛擬主機
• 如圖，能夠看到訪問 curl 127.0.0.1:8080/ 返回的結果是 8080 default
• 使用 curl -x127.0.0.1:8080 www.test.com
• 這裏帶上了域名，返回的就是 test.com_8080
• 說明想訪問 test 虛擬主機，ip端口還須要綁定域名才行
• 如圖，curl 訪問 127.0.0.1:80 域名 www.test.com
• 返回的是 test.com_8080 說明這個反向代理成功了
• 咱們訪問的是 80 端口，實際卻返回了 8080 端口的虛擬主機的內容
• 如圖，這裏把反向代理虛擬主機裏面的 proxy_pass 行下面的都註釋掉
• 保存退出，重載 nginx
• 如圖，再使用 curl 訪問 127.0.0.1:80 域名 www.test.com
• 實際返回的倒是 8080 default
• 而咱們想訪問的倒是 test 虛擬主機
• 如圖，proxy_set_header Host $host;
• 這一行代碼就是指定訪問的域名
• 上面設置了 127.0.0.1:8080
• 反向代理的時候就會指向這個 ip端口
• 若是不設置 host 那就只會訪問 127.0.0.1:8080 的虛擬主機
• 若是設置了 host ，那麼就會指向跟指定的 host 綁定的 127.0.0.1:8080
• 這裏的 $host 是系統變量，實際的值就是當前的虛擬主機的 server_name
• 也就是 www.test.com ，server_name 是什麼，host的值就是什麼
• 這裏設置了 host 就至關於 curl -x127.0.0.1:8080 www.test.com
• 若是這裏不設置 host 那麼就只會訪問 127.0.0.1:8080
• 這樣就能夠把 域名 跟 ip端口進行綁定
• 如圖，除了寫 ip端口以外，proxy_pass 也能夠直接寫域名
• 這裏寫的是 www.123.com:8080/
• 可是這樣寫的話， nginx 並不知道這個域名指向哪裏
• 因此還須要在系統裏面綁定對應的 ip
• 例如在 /etc/hosts 文件裏面，寫入對應的 域名和 ip 進行綁定
• 這樣nginx 裏面的 proxy_pass 的域名系統就會解析出一個 Ip 地址
• 而後再訪問這個 ip端口
• 下面的 proxy_header Host 做用就是設置一個 域名
• 這個域名會與上面的 ip端口綁定訪問
• 若是上面的 ip端口 寫的不是 ip 而是域名
• 跟下面指定的域名是不衝突的，由於上面寫的域名的做用是用來解析ip的
• 下面指定的域名纔會跟上面解析出來的 ip端口進行綁定訪問
• 這個例子使用的是 $host 這是 nginx全局變量
• 這個變量實際是對應了一個值的，就是當前虛擬主機 server_name 的值
• 可是通常來講，仍是直接寫 ip 端口方便一些
• 上面就是指定 ip端口
• 下面指定跟 ip端口綁定的 host 域名

nginx反向代理02

• 如圖，proxy_pass 指令後面能夠跟 url
• 有三種格式，傳輸協議+域名+uri (訪問路徑)
• 傳輸協議+ip端口+uri
• 傳輸協議+socket
• 這裏 unix ，http ，https 都是傳輸協議的種類
• 域名+uri 和 ip端口+uri 還有 socket 都是訪問的路徑
• socket 通常是某個程序專用的訪問端口
• 訪問某個socket就是訪問某個特定的程序，因此不須要使用路徑
• 如圖，寫 proxy_pass 的時候，不一樣的寫法有不一樣的結果
• 好比 location /aming/
• 若是訪問的路徑包含 /aming/ 就會觸發
• 這裏的proxy_pass 就會執行
• 可是location 裏面的 proxy_pass 不一樣的寫法會致使實際訪問的路徑有差異
• 雖然由於訪問的路徑包含 /aming/ 目錄才執行 proxy_pass
• 可是實際訪問的路徑不必定包含 /aming/
• 這個例子是訪問虛擬主機內的 /aming/a.html 文件
• 根據 proxy_pass 的不一樣寫法實際上會訪問到不一樣的路徑去
• 若是 ip端口 後面沒有接任何目錄符號
• 就會訪問 /aming/a.html，這是咱們想要的
• 若是 ip端口後面接了根目錄符號 /
• 那麼就會直接訪問根目錄裏面的 a.html文件，這顯然不對
• ip端口後面接 /linux/ 那麼就會訪問 /linux/ 裏面的 a.html文件
• 若是 ip端口後面是 /linux 最後沒有跟目錄符號 /
• 就會訪問 /linuxa.html
• 因此若是想正確訪問 /aming/a.html
• 有兩種寫法，一種是 ip端口後面不要加任何目錄符號 /
• 第二種是完整的寫成 ip端口/aming/ 這樣寫
• 根據上面示例能夠發現，ip端口後面無論是什麼目錄
• 實際訪問路徑就會變成直接把最終要訪問的文件名稱 a.html
• 直接添加到 ip端口 後面的目錄上去
• 因此 ip端口後面不寫任何目錄符號的話，系統纔會本身添加 /aming/a.html 這個目錄路徑
• 一旦有任何目錄符號存在，就會直接把 a.html 放在這個目錄符號後面
• 第二種狀況是，ip端口+ /linux
• 實際結果是訪問 /linuxa.html
• 這多是由於 linux 後面沒有跟上任何目錄符號 /
• 因此係統把 linux 認爲是一個沒有寫完的文件名稱
• 而後就直接把 a.html 這個文件名稱跟 linux 粘貼在一塊兒
• 這樣就變成了要訪問的文件是 /linuxa.html 的形式
• 因此無論寫什麼路徑，後面必定要跟上目錄符號 /

反向代理03

• 如圖，proxy_set_header 是設置被代理的服務器能夠接收到的 header 信息的
• 好比有三臺電腦 a b c
• a 是咱們用來訪問的電腦，咱們從 a 發出訪問請求
• b 是反向代理服務器，b 接收咱們發出的訪問請求
• c 是被反向代理的服務器，也就是咱們真正要訪問的服務器
• b 會把咱們的訪問請求轉發給 c
• 若是不設置 proxy_set_header 的話，b 轉發請求給 c 的時候就不會帶上相應的 header 信息
• 若是設置了這個參數，在轉發請求的時候就會帶上對應的 header 信息
• 其中 $remote_addr 和 $proxy_add_x_forwarded_for 這兩個變量是 nginx 的內置變量
• $remote_addr 變量裏面保存的是 b 反向代理服務器自己的 ip 地址
• $proxy_add_x_forwarded_for 變量裏面保存的是 a 客戶端電腦的 ip 地址
• 若是不設置這個變量的話，c 服務器其實是不知道訪問請求的真實來源地址的
• 而設置了這個變量， c 服務器就能夠知道這個訪問請求是哪個ip地址發過來的
• 如圖，編輯 www.test.com 虛擬主機的配置文件
• 假設這個虛擬主機是咱們要訪問的 c 服務器
• location 裏面設置了兩個echo 顯示訪問請求的來源地址，和真實來源地址
• $remote_addr 記錄了反向代理服務器的地址
• $proxy_add_x_forwarded_for 記錄了訪問請求的真實來源地址，也就是客戶端的地址
• 這樣設置，訪問這個虛擬主機的時候，就會顯示這兩個變量裏面保存的值
• 保存退出，而後重載配置文件
• 如圖，編輯反向代理服務器虛擬主機的配置文件
• 如圖，能夠看到 location 裏面
• proxy_set_header X-Real-IP 和 proxy_set_header X-Forwarded-For 這兩行是被註釋掉的
• 先作個測試，保存退出重載配置文件
• 如圖，使用 curl 測試從 192.168.133.140:80 發出訪問請求
• 192.168.133.140 這個 ip 實際就是 客戶端 ip
• 由於訪問請求就是從這個 ip 發出來的
• 可是能夠看到，測試以後，實際顯示的倒是兩個 127.0.0.1 的迴環地址
• 並無 192.168.133.140 這個 ip
• 在這個測試裏面，反向代理服務器 和 真實服務器 都在本機上面
• 因此真實服務器 c 接收的訪問請求來源 ip 就是本機的迴環地址
• 反向代理服務 b 發送請求給 真實服務器 c 走的就是 127.0.0.1 的內部迴環地址
• 由於這兩個服務器都在本機上，本機上的程序之間通信基本都是走 127.0.0.1 迴環地址的
• 因此 c 的 $remote_addr 的值就是 127.0.0.1
• 由於反向代理服務器 b 沒有設置 $proxy_add_x_forwarded_for
• 因此真實服務器 c 的接收到的 $proxy_add_x_forwarded_for 變量值就是請求發送過來的 ip
• 也就是 127.0.0.1
• $proxy_add_x_forwarded_for 這個變量其實是記錄了從客戶端開始
• 請求總共通過了哪些 ip 地址的一個變量值，多個 ip 地址之間使用逗號分隔
• 若是發送的訪問請求沒有設置 $proxy_add_x_forwarded_for 這個變量的話
• 那麼接收方的這個變量的值就只是訪問請求發送過來的上一個 ip , 也就是跟 remote_addr 相同
• 好比訪問請求從 a 到 b 到 c
• 若是 b 設置了 $proxy_add_x_forwarded_for 的話
• 那麼這個變量的格式就是 a_ip, b_ip
• 也就是記錄了 a 的ip 和 b 的ip
• 若是中間還通過更多的服務器的話，那麼它們的 ip 也會被記錄下來，使用逗號分隔
• 固然每一臺代理服務器都須要設置 $proxy_add_x_forwarded_for 這個變量才行
• 否則下一臺代理服務器的 $proxy_add_x_forwarded_for 這個變量將不會記錄到以前通過的 ip
• 只可以記錄到上一臺服務器的 ip
• 因此在這個測試裏面，由於 b 沒有設置 $proxy_add_x_forwarded_for
• 因此 c 服務的 $proxy_add_x_forwarded_for 變量的值等於 $remote_addr 的值
• 如圖，第二次測試，編輯反向代理服務器 b 的配置文件
• 把 location 裏面的 X-Real-IP 和 X-Forwarded-For 兩行註釋去掉
• 保存退出重載配置文件
• 如圖，再次測試
• 能夠看到返回的結果，第一行 remote_addr 的值是 127.0.0.1
• 這是 代理服務器 b 的 ip
• 第二行 $proxy_add_x_forwarded_for 的值是兩個 ip
• curl 命令裏面，訪問請求是從 192.168.133.140 發出的
• 也就是說，客戶端 a 的 ip 就是 192.168.133.140
• b 的 ip 就是 127.0.0.1
• $proxy_add_x_forwarded_for 記錄的是到達 c 的訪問請求通過了哪些 ip
• 訪問請求是從 a 到 b 再從 b 到 c 的
• 因此 $proxy_add_x_forwarded_for 變量 記錄了 a 的 ip 和 b 的 ip
• 由於訪問請求在到達 c 以前通過了這兩個 ip 地址
• 因此之後作反向代理的時候，這幾行變量都要設置
• 後面的真實服務器纔可以獲取到訪問請求的真實 ip 地址

反向代理04

• 如圖，redirect 應用的場景很少，主要有三種寫法
• 功能是修改被代理的服務器返回的 location 和 refresh 頭域信息
• 第一種寫法，redirect 是返回的頭域信息
• replacement 是要修改的信息
• redirect 會被修改成 replacement
• 第二種寫法是 default 就是默認設置的意思
• 第三種 off 意思就是關閉 redirect功能
• 如圖，作一個測試，編輯代理服務器的配置文件
• 要測試成功有幾個條件要達成
• 首先，location 後面只能是根目錄 / 不能是加別的
• 第二個條件是proxy_pass後面的 url 後面不能加 / 符號
• 正常來講是要 / 結尾的，可是這裏不能用 / 結尾
• 而後訪問的目錄必須真實存在，若是不存在能夠建立一個
• 而後再目錄裏面也能夠建立一個 index.html 文件，裏面編輯一些字符串內容
• 保存退出重載一下配置文件
• 如圖，編輯被代理服務器的配置文件
• 寫成如圖所示的這種簡單格式
• 保存退出重載配置文件
• 如圖，curl 測試訪問的時候，若是 aming 後面加了 / 結尾，那麼就會訪問到 index.html 文件
• 可是咱們要訪問的是目錄自己，並非裏面的某個文件
• 因此 crul 的時候，訪問的地址結尾不能加上 / 符號
• 這樣就能夠訪問到 aming 目錄了
• 能夠看到，返回的代碼是 301 表示永久重定向
• 下面的 location 後面的字段，是帶端口8080 的訪問路徑
• 如圖，編輯被代理服務器的配置文件
• 添加 access_log /tmp/456.log
• 這樣就開啓了服務器的訪問日誌，檢查訪問日誌能夠更清晰的瞭解訪問過程
• 保存退出重載
• 如圖，從新 curl 測試一次，此次測試 aming 結尾是帶 / 符號的
• cat 查看 /tmp/456.log 訪問日誌
• 發現日誌信息沒有 host 和 端口 等信息
• 這種狀況能夠修改 nginx.conf 配置文件裏面的 format 配置
• 如圖，配置文件裏面 log_format main 這三行原本是被註釋掉的
• 如今把註釋去掉，讓這幾行產生做用，這個就是日誌返回信息的格式設置
• 如圖，在最後面添加兩個nginx變量 $host $server_port 這兩個變量
• 而後保存退出重載一下，這樣訪問日誌顯示的信息裏面，就會加上這兩個變量的信息了
• 如圖，編輯代理服務器配置文件，一樣添加 access_log 配置
• 日誌地址就是 /tmp/proxy.log
• 後面加上 main 由於 nginx.conf 裏面配置的格式是用 main 命名的
• 這裏加上main 表示使用 main 命名的格式來顯示日誌信息
• 如圖，一樣被代理服務器裏面的 access_log 後面也須要加上 main
• 表示使用 main 的格式顯示日誌信息
• 保存退出重載一下
• 如圖，curl 測試一下，此次測試是用 / 符號結尾的
• 查看 456.log 後端服務器的日誌，能夠看到，訪問的是 8080 端口
• 查看 proxy.log 代理服務器日誌，能夠看到，訪問的是 80 端口
• 網絡代碼都是 200 這樣是正常的
• 如圖，此次訪問 aming 結尾不帶 / 符號
• 能夠看到返回的是 301
• 查看 proxy.log 返回的也是 301
• 如圖，從新測試一下，再查看兩個日誌
• 看到 301 再到 200 的日誌信息
• 總之肯定了咱們訪問 80 端口，跳轉到了 8080 端口
• 可是客戶端是訪問不到 8080 端口的
• 如圖，解決這個問題可使用 proxy_redirect
• 這裏是 http://$host:8080/ /;
• 這樣寫能夠把原本返回的 8080 端口信息給去掉
• 保存退出重載
• 如圖，從新測試
• 能夠看到，返回的是 301
• 而後 location 後面的地址裏面，也沒有 8080 端口的信息存在了

反向代理05

• proxy_buffering 是緩衝的意思
• 緩衝就是在內存裏面劃一塊區域，在裏面寫數據
• 寫到必定量的時候，纔會把緩衝裏面的數據寫進硬盤中
• 這樣作的話，就能夠大大減小硬盤的讀寫頻率
• 若是不作緩衝，每產生一次數據都要讀寫一次硬盤，對於硬盤的負擔就會很大
• 假設有三個對象，客戶端 a 代理服務器 b 被代理服務器 c
• a 發出請求，b 接收請求，轉發給 c
• c 返回數據給 b ，而後 b 再把數據發給 a
• 這是通常的運做狀況，可是若是 a 發出許多訪問請求
• 或者有不少個客戶端發出訪問請求
• 那麼對於代理服務器 b 和 被代理服務器 c 來講
• 每一個請求都要按照這個流程處理一次，負擔就會很重
• proxy_buffering 就是在 代理服務器 b 的內存裏面設置一個或多個緩衝區域
• 當緩衝區域數據量滿了的時候，才把數據轉發給相應的客戶端
• 這樣代理服務器 b 的數據轉發次數就大大減小了，負擔就降低了
• 當 proxy_buffering 開啓的時候，由 proxy_busy_buffer_size 來決定什麼時候把數據發送給 a
• 在這個過程當中，若是 buffer 區域被寫滿，有數據溢出
• 多出來的數據會被寫入到 temp_file 也就是一個臨時文件中去，這個文件會存儲在硬盤上
• 若是 proxy_buffering 關閉的話，c 反饋的數據就直接由 b 轉發給 a
• 而不會有別的操做發生
• 如圖，無論 proxy_buffering 是 on 仍是 off 的狀態
• proxy_buffer_size 這個選項都是生效的，這個參數是用來設置一個 buffer
• 這個 buffer 存儲了服務器反饋的 header 信息
• 若是設置不夠大，存儲不了 header 信息的話，會出現 502 錯誤碼
• 因此建議設置爲 4k
• 如圖， proxy_buffers 是定義每一個請求的 緩衝區個數 和 每一個緩衝區的具體大小
• 這裏定義了 8 4k 意思就是有 8個緩衝區，每一個緩衝區的大小爲 4k
• 那麼總緩衝區的大小就是 8*4 = 32 k
• 假設有一萬個請求，那麼緩衝區就是 8 * 10000 個緩衝區了
• 由於這個設置是針對每一個請求來的，而不是總共只有 8 個緩衝區
• proxy_busy_buffer_size 定義的是達到多少數據量，就把數據傳輸給客戶端
• 這裏定義的是 16k ，那麼當 b 的屬於這個請求的緩衝區接收到 16k 的數據量的時候
• 就會把數據轉發給 a
• 這裏緩衝區有 8 個，總共 32k 的大小，緩衝區通常來講處於兩種狀態
• 一個是接收數據，一個是發送數據，並不能同時接收數據和發送數據
• proxy_busy_buffer_size 定義的就是 發送數據的緩衝區的大小
• 因此 proxy_busy_buffer_size 的大小要比緩衝區的總大小要小才行
• 接收的數據達到 proxy_busy_buffer_size 設置的數據量的時候
• 這些緩衝區就進入發送數據的狀態，剩下的緩衝區則是接收數據的狀態
• 若是請求反饋的數據總量小於 proxy_busy_buffer_size 設置的值
• 那麼 b 接收完成就會直接轉發爲 a
• 若是請求反饋的數據總量大於 proxy_busy_buffer_size 設置的值
• 那麼當緩衝區接收的數據量達到 proxy_busy_buffer_size設置的值的時候
• 就會把這部分的數據先發送給 a
• 如圖，proxy_temp_path 定義的是臨時文件存放目錄
• 舉例，a 發出請求，b代理服務器分配給 a 這個請求的 緩衝區 總大小爲 32k
• 可是 c 服務對這個請求反饋的數據量爲 100 MB 這麼大，遠遠超過緩衝區的大小
• 這種狀況下， b 接收 c 的數據的過程當中就會有不少數據溢出緩衝區
• 這些溢出的數據會被先保存到 b 的硬盤上的臨時文件裏面去
• proxy_temp_path 定義的就是這個臨時文件存放的路徑，還有子目錄層級
• 這裏定義的路徑是 /usr/local/nginx/proxy_temp 這是一個目錄名稱
• 臨時文件就會存放到這個目錄裏面去
• 後面的數字 1 2 表示子目錄層級
• 前面的目錄路徑是由咱們本身定義的，子目錄是系統自動建立的
• 建立多少個子目錄層級，能夠經過後面的數字設置
• 好比 只寫一個 1 就表示子目錄只有一層，子目錄的名稱爲 0-9 的命名方式
• 根據定義，proxy_temp_path 支持三級子目錄，也就是能夠寫 3 個數字
• 好比寫 1 子目錄數量和命名方式 就是 0- 9 共10個
• 若是寫 2 就是 00-99 共100個，若是寫 3 就是 000-999 共1000個子目錄
• 子目錄名稱也是根據這些數字來命名的
• 若是寫 1 3 就表示子目錄分兩層，第一層是 0-9 10個子目錄
• 第二層是 000-999 1000個子目錄，也能夠反過來寫 3 1
• 這樣第一層就是 1000 個子目錄，每一個目錄下面第二層又有 10 個子目錄
• proxy_max_temp_file_size 定義的是 臨時文件的總大小
• 好比這裏設置爲 100M 說明每一個臨時文件最大爲 100M
• 臨時文件的數據若是傳輸完成，就會自動刪除
• proxy_temp_file_write_size 定義的是同時寫入臨時文件數據量的總大小
• 這裏定義一個值好比 8k 或者 16k
• 若是同時寫入的數據量低於這個值，那麼就增長同時寫入的數據量
• 若是高於這個值，那麼就減小同時寫入的數據量
• 由於同時寫入的數據量過高，對於硬盤 IO 負擔太大，而過小則沒有充分用到硬盤的性能
• 因此設置一個值，既不會太快，也不會太慢，充分使用到硬盤的性能，又不會負擔太重
• 如圖，這是一個使用 proxy_buffering 的例子
• 首先是設置爲 on 的狀態，也就是打開 buffer 功能
• 頭文件存儲的 buffer區域大小爲 4k
• 而後是其它數據的 buffer 區域爲 2 個，每一個大小爲 4k
• 而後是 busy_buffers 的數據量爲 4k
• buffer 接收的數據量達到 4k 時就會發送數據
• 而後是臨時文件存放的路徑定義，定義了兩層子目錄
• 分別是 1 2 也就是 第一層有 0-9 10個子目錄
• 而後每一個子目錄下面 第二層有 00-99 100個子目錄
• 而後是每一個臨時文件的大小爲 20M
• 而後是臨時文件同時寫入的數據量定義爲 8k

反向代理06

• 如圖，要使用 proxy_cache 首先要打開 proxy_buffering 功能
• proxy_cache 就是緩存功能
• 客戶端 a 發出請求，若是 a 請求的數據已經保存到 代理服務器 b 的緩存裏面的話
• 那麼 b 會把相關數據直接發送給 a 而不會去向 服務器 c 請求數據
• 若是不開啓緩存功能，那麼 a 的每一次請求，代理服務器 b 都會向 服務器 c 請求獲取一次數據
• 若是 a 兩次請求的數據是同樣的，也會向 服務器 c 請求兩次數據
• 開啓緩存功能的話，第一次請求的數據已經被保存到 緩存裏面了，第二次若是請求一樣的數據
• b 就會直接從緩存裏面獲取，而不會去向 c 獲取數據，這樣就減輕了 服務器 c 的負擔
• 總結，緩衝能夠減輕 代理服務器b 的負擔，緩存能夠減輕 被代理服務器 c 的負擔
• 如圖，proxy_cache 功能的開啓與關閉
• proxy_cache off 意思就是關閉緩存功能
• proxy_cache zone 就是開啓緩存區，zone 就是緩存區的名稱
• 緩存區名稱是能夠任意命名的，能夠是 zone 也能夠是 123 等任意名稱
• 這裏寫一個緩存區名稱就表示了開啓一個以這個名稱命名的緩存區
• 從 nginx 0.7.66 版本開始，開啓 proxy_cache 以後
• 還會檢測被代理服務器的 http 響應頭中的 Cache-Control ，Expire 頭域
• 若是 cache-control 的值爲 no-cache 時，那麼這個請求的數據是不會被緩存的
• 如圖，curl -I 一個網站請求數據
• 能夠看到，返回的頭文件信息，Cache-Control 後面的值裏面
• 存在 no-cache ，表示這個請求返回的數據是不會被緩存的
• 如圖，proxy_cache_bypass 這個參數是設置某種狀況下
• 請求的數據不從 cache 中獲取，而是直接從後端服務器中獲取
• 這個參數後面的 string 通常爲 nginx 的一些變量
• 好比 proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
• 這樣設置就表示，這三個變量的值，任意一個不爲 0 或 空 的狀況下
• 響應數據就不會從 cache 中獲取，而是直接從後端服務器獲取
• 暫時不多用到，瞭解一下便可
• 如圖，proxy_no_cache 跟上面的參數用法類似
• 主要是設置某種狀況下，獲取的數據不進行緩存
• 示例 proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
• 這樣設置就表示，當後面這三個變量任意一項的值不爲 0 或者 空 的時候
• 獲取的數據都不進行緩存
• 如圖，這個參數格式跟上面的參數差很少，通常不須要設置，保持默認就能夠了
• 如圖，proxy_cache_path 是設置緩存區具體配置的參數
• 緩存除了內存中的空間外，還能夠在硬盤中劃出一塊空間來作緩存
• path 就是指定一個目錄路徑做爲緩存路徑，緩存會存放到這裏面
• levels=1:2 這個表示目錄層級，第一個數字設置的是第一層
• 第二個數字設置的是第二層
• 1 表示 0-9 a-f 總共16個字符，每一個目錄由單個字符組成，一共16個目錄
• 2 表示 0-9 a-f 總共16個字符，可是每一個目錄由兩個字符組成，00,01,04,2f 之類的，有兩百多種組合
• 總之這個參數是設置子目錄層級，第一個數字表示第一層
• 第二個數字表示第二層
• keys_zone 是設置內存zone 的名稱和大小
• keys_zone=my_zone:10m 就表示zone的名稱叫作 my_zone
• 而後 zone 的大小是 10MB
• inactive 是設置多長時間後，把緩存刪除
• 好比圖中設置爲 300s 意思就是，若是數據在 300秒內沒有被訪問過
• 那麼這個數據就會從緩存中刪除
• max_size 是設置硬盤中的緩存最多能夠存儲多少數據
• 好比這裏設置爲 5g ，上面設置的目錄 /data/nginx_cache/
• 這個硬盤上的目錄，最多能夠存放 5g 的數據，若是超過這個量
• 系統就會先把訪問量最少的數據刪除，再放新的數據進去
• proxy_cache_path 這行代碼不能寫在 配置文件的 server 括號內
• 要寫在 http 括號裏面
• 舉例說明，首先編輯 nginx.conf 配置文件
• 如圖，在 server 的外面添加 proxy_cache_path 代碼
• 如圖，由於指定的緩存目錄 /data/nginx_cache/ 不存在，因此這裏要建立一下
• 如圖，編譯一個虛擬主機的配置文件，在location 裏面添加 proxy_cache my_zone;
• 這樣這個虛擬主機接收請求的時候，就會使用 my_zone 這個緩存空間了
• 而 my_zone 緩存空間的具體定義已經在 nginx.conf 配置文件裏面做了定義
• nginx.conf 裏面的配置內容對全部虛擬主機都是有效的
• 因此在 nginx.conf 裏面定義了 my_zone 的話
• 那麼在全部虛擬主機配置文件裏面使用 proxy_cache my_zone
• 這些虛擬主機就均可以使用到 my_zone 這個緩存空間
• 而後保存退出重載配置文件就能夠生效了
• 平時使用，只須要添加這樣兩行代碼就成功配置好緩存了
• 如圖，還有一個問題就是，nginx 服務自己的權限是 nobody
• 剛纔的目錄是使用 root 權限建立的
• 因此這裏要把 緩存目錄 的全部者所屬組修改爲 nobody
• 這樣nginx 服務操做這個目錄的時候就不會有權限問題了
• 如圖，查看 /data/nginx_cache/ 目錄內容
• 能夠看到 0-9 a-f 的第一級目錄
• 進入 0 目錄內查看，能夠看到由兩位數構成的 第二級目錄
• 總結，緩存空間配置主要就是定義 proxy_cache_path
• 能夠在 nignx.conf 裏面定義，這樣任何虛擬主機均可以使用到
• 定義好 proxy_cache_path 後，在須要使用緩存的虛擬主機 server內
• 配置 proxy_cache zone_name
• zone_name 就是 proxy_cache_path 裏面定義好的緩存空間名稱
• 這樣對應的虛擬主機就可使用這個緩存空間了