一、http 協議反向代理
(一)反向代理示例:緩存功能
緩存功能可以加速訪問,如果沒有緩存關閉后端服務器后,圖片將無法訪問,緩存功能默認關閉,需要開啟。
?
proxy_cache zone_name | off; 默認off
#指明調用的緩存,或關閉緩存機制;Context:http, server, location
#zone_name 表示緩存的名稱.需要由proxy_cache_path事先定義proxy_cache_key string;
#緩存中用于“鍵”的內容,默認值:proxy_cache_key $scheme$proxy_host$request_uri;proxy_cache_valid [code ...] time;
#定義對特定響應碼的響應內容的緩存時長,定義在http{...}中proxy_cache_path;
#定義可用于proxy功能的緩存;Context:http 必須放在http語句中#調用緩存功能,需要定義在相應的配置段,如server{...};或者location等
proxy_cache proxycache;
proxy_cache_key $request_uri; #對指定的數據進行MD5的運算做為緩存的key
proxy_cache_valid 200 302 301 10m; #指定的狀態碼返回的數據緩存多長時間
proxy_cache_valid any 1m; ? #除指定的狀態碼返回的數據以外的緩存多長時間,必須設置,否則不會緩存proxy_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ; #默認是off
#在被代理的后端服務器出現哪種情況下,可直接使用過期的緩存響應客戶端
#示例:在http配置定義緩存信息proxy_cache_path /var/cache/nginx/proxy_cache #定義緩存保存路徑,proxy_cache會自動創建levels=1:2:2 #定義緩存目錄結構層次,1:2:2可以生成2^4x2^8x2^8=2^20=1048576個目錄keys_zone=proxycache:20m #指內存中緩存的大小,主要用于存放key和metadata(如:使用次數),一般1M可存放8000個左右的keyinactive=120s ?#緩存有效時間 ?max_size=10g; #最大磁盤占用空間,磁盤存入文件內容的緩存空間最大值
proxy_cache zone_name | off; 默認off #指明調用的緩存,或關閉緩存機制;Context:http, server, location #zone_name 表示緩存的名稱.需要由proxy_cache_path事先定義proxy_cache_key string; #緩存中用于“鍵”的內容,默認值:proxy_cache_key $scheme$proxy_host$request_uri;proxy_cache_valid [code ...] time; #定義對特定響應碼的響應內容的緩存時長,定義在http{...}中示例:proxy_cache_valid 200 302 10m;proxy_cache_valid 404 1m;proxy_cache_path; #定義可用于proxy功能的緩存;Context:http 必須放在http語句中 proxy_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=zone_name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];#示例:在http配置定義緩存信息proxy_cache_path /var/cache/nginx/proxy_cache #定義緩存保存路徑,proxy_cache會自動創建levels=1:2:2 #定義緩存目錄結構層次,1:2:2可以生成2^4x2^8x2^8=2^20=1048576個目錄keys_zone=proxycache:20m #指內存中緩存的大小,主要用于存放key和metadata(如:使用次數),一般1M可存放8000個左右的keyinactive=120s ?#緩存有效時間 ?max_size=10g; #最大磁盤占用空間,磁盤存入文件內容的緩存空間最大值#調用緩存功能,需要定義在相應的配置段,如server{...};或者location等 proxy_cache proxycache; proxy_cache_key $request_uri; #對指定的數據進行MD5的運算做為緩存的key proxy_cache_valid 200 302 301 10m; #指定的狀態碼返回的數據緩存多長時間 proxy_cache_valid any 1m; ? #除指定的狀態碼返回的數據以外的緩存多長時間,必須設置,否則不會緩存proxy_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ; #默認是off #在被代理的后端服務器出現哪種情況下,可直接使用過期的緩存響應客戶端#示例 proxy_cache_use_stale error http_502 http_503;proxy_cache_methods GET | HEAD | POST ...; #對哪些客戶端請求方法對應的響應進行緩存,GET和HEAD方法總是被緩存
實驗:
①?主配置文件的http模塊中添加配置?
proxy_cache_path /data/nginx/proyxcache levels=1:1:1 keys_zone=proxycache:20m inactive=120s max_size=1g;
?7-1代理服務器
[root@localhost ~]# vim /apps/nginx/conf/nginx.conf
proxy_cache_path /data/nginx/proyxcache levels=1:1:1 keys_zone=proxycache:20m inactive=120s max_size=1g;
#開啟緩存 緩存路徑 生成文件夾比例是3級 從內存中借調20M專門存放緩存 有效期120秒 最大存儲空間為1g
[root@localhost ~]# mkdir /data/nginx/
[root@localhost ~]# nginx -t
② 子配置文件添加配置
proxy_cache proxycache;proxy_cache_key $request_uri;#proxy_cache_key $host$uri$is_args$args;proxy_cache_valid 200 302 301 10m;proxy_cache_valid any 5m;
去7-3配置拖入圖片:
③ 去瀏覽器訪問代理端:
去7-1代理服務器查看緩存
如果把真實服務器關掉
再去瀏覽器訪問,還是可以訪問到的,這就是緩存用處哦
(1)如何清理nginx代理服務器緩存
方法1: rm -rf 緩存目錄
方法2: 第三方擴展模塊ngx_cache_purge
(2)自定義添加響應報文頭部信息
Syntax: add_header name value [always];
Default;
Context: http,server,location,if in location#添加響應報文的自定義首部:
add_header name value [always];#示例:
add_header X-Via $server_addr; #當前nginx主機的IP
add_header X-Cache $upstream_cache_status; #是否緩存命中
add_header X-Accel $server_name; #客戶訪問的FQDNadd_header X-Via
add_header X-Cache
add_header X-Accel
小插曲:虛擬機要在主配置文件夾寫子配置,子配置才可用
實驗1:自定義添加響應報文頭部信息
add_header X-Via ? ? $server_addr; ? ? ? ? ? ? #當前nginx主機ip
add_header X-Cache $upstream_cache_status; ? #是否緩存命中,hit命中,miss未命中add_header X-Accel ? $server_name; ? ? ? ? ? ? #客戶端訪問的FQDN
add_header X-Via $server_addr;add_header X-Cache $upstream_cache_status;add_header X-Accel $server_name;
server {listen 80;server_name www.lucky.com;root /data/;proxy_cache proxycache;proxy_cache_key $request_uri;#proxy_cache_key $host$uri$is_args$args;proxy_cache_valid 200 302 301 10m;proxy_cache_valid any 5m;add_header X-Via $server_addr;add_header X-Cache $upstream_cache_status;add_header X-Accel $server_name;add_header cxk hero;location ~* /api {proxy_pass http://192.168.246.8;}location ~* \.(jpg|jpeg|png|gif|bmp)$ {proxy_pass http://192.168.246.9;}
}
① 添加子配置文件
②?查看新增頭部字段信息
(二)實現反向代理客戶端 IP 透傳
IP透傳的定義:Client客戶端通過http服務訪問192.168.246.7的代理服務器,代理服務器通過proxy跳轉至192.168.246.8后端真實服務器,最后在Web后端真實服務器應該可以看到真實客戶端的訪問IP和代理服務器的IP。
實驗1:IP透傳-------單向透傳? ? ?7-1用nginx? ? 7-2用apache
①在代理服務器7-1寫配置文件:
server{ listen 80; root /data/;server_name www.lucky.com;add_header X-Via $server_addr;add_header X-Cache $upstream_cache_status;add_header X-Accel $server_name;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;location / {proxy_pass http://192.168.246.8;}
}
當前訪問192.168.246.7代理服務器跳轉的是192.168.246.8后端真實服務器
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客戶端IP和反向代理服務器IP到請求報文頭部
②在后端服務器(真實服務器)配置:開啟httpd服務,關閉防火墻,并實時查看訪問日志
解釋:
③ 客戶端7-3訪問代理服務器
我們使用第三臺機器作為客戶端,通過代理服務器去訪問后端真實服務器?
再去查看日志:
顯示了真實的訪問主機的ip地址,開啟ip透傳后可以查看到客戶端ip
實驗2:IP透傳----------多級代理? ? ?三臺主機均為nginx服務
①去7-1代理服務器配置:
server{listen 80;root /data/;server_name www.lucky.com;add_header X-Via $server_addr;add_header X-Cache $upstream_cache_status;add_header X-Accel $server_name;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;location / {proxy_pass http://192.168.246.8;}
}
②去7-2代理服務器配置:
[root@zzzcentos2 ~]#systemctl stop httpd
[root@zzzcentos2 ~]#yum install epel-release -y
[root@zzzcentos2 ~]#yum install nginx -y
[root@zzzcentos2 ~]#systemctl restart nginx
[root@zzzcentos2 ~]#systemctl stop firewalld
[root@zzzcentos2 ~]#setenforce 0
[root@zzzcentos2 ~]#systemctl stop httpd
[root@zzzcentos2 ~]#systemctl restart nginx
[root@zzzcentos2 ~]#vim /etc/nginx/nginx.conf
[root@zzzcentos2 ~]#nginx -s reload
[root@zzzcentos2 ~]#systemctl restart nginx
[root@zzzcentos2 ~]#
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;?
#添加客戶端IP和反向代理服務器IP到請求報文頭部
③ 后端服務器7-3新建web文件
[root@zzzcentos3 html]#cd /usr/share/nginx/html
[root@zzzcentos3 html]#echo welcome 7-3 > index.html
[root@zzzcentos3 html]#cat index.html
welcome 7-3
④檢測:
⑤查看日志
(三)http反向代理負載均衡
在上一個節中Nginx可以將客戶端的請求轉發至單臺后端服務器但是無法轉發至特定的一組的服務器,而且不能對后端服務器提供相應的服務器狀態監測
Nginx 可以基于ngx_http_upstream_module模塊提供服務器分組轉發、權重分配、狀態監測、調度算法等高級功能
配置格式:
#自定義一組服務器,配置在http塊內
upstream web { server 192.168.91.100 調度算法server 192.168.91.101
}location / {
pass_proxy http://web/
}
官方文檔: https://nginx.org/en/docs/http/ngx_http_up
server address [parameters];
#配置一個后端web服務器,配置在upstream內,至少要有一個server服務器配置。
#server支持的parameters如下:
weight=number #設置權重,默認為1,實現類似于LVS中的WRR,WLC等
max_conns=number ?#給當前后端server設置最大活動鏈接數,默認為0表示沒有限制
max_fails=number ?#后端服務器的下線條件,當客戶端訪問時,對本次調度選中的后端服務器連續進行檢測多少次,如果都失敗就標記為不可用,默認為1次,當客戶端訪問時,才會利用TCP觸發對探測后端服務器健康性檢查,而非周期性的探測
fail_timeout=time #后端服務器的上線條件,對已經檢測到處于不可用的后端服務器,每隔此時間間隔再次進行檢測是否恢復可用,如果發現可用,則將后端服務器參與調度,默認為10秒
backup ?#設置為備份服務器,當所有后端服務器不可用時,才會啟用此備用服務器 sorry server 自己不能轉自己
down ? ?#標記為down狀態
resolve #當server定義的是主機名的時候,當A記錄發生變化會自動應用新IP而不用重啟Nginxhash KEY [consistent];
#基于指定請求報文中首部字段或者URI等key做hash計算,使consistent參數,將使用ketama一致性hash算法,適用于后端是Cache服務器(如varnish)時使用,consistent定義使用一致性hash運算,一
致性hash基于取模運算
hash $request_uri consistent; #基于用戶請求的uri做hash
hash $cookie_sessionid ?#基于cookie中的sessionid這個key進行hash調度,實現會話綁定ip_hash;
#源地址hash調度方法,基于的客戶端的remote_addr(源地址IPv4的前24位或整個IPv6地址)做hash計算,以實現會話保持least_conn;
#最少連接調度算法,優先將客戶端請求調度到當前連接最少的后端服務器,相當于LVS中的WLC
實驗拓樸草圖
我們做實驗,為了看到效果,所以內容不一樣
真實環境中,內容是一樣的
負載均衡? 實驗拓樸圖:
apache后端服務器開啟httpd服務,關閉防火墻,分別建立web文件
[root@zzzcentos3 ~]#systemctl stop nginx
[root@zzzcentos3 ~]#systemctl start httpd
[root@zzzcentos3 ~]#cd /var/www/html/
[root@zzzcentos3 html]#echo welcome to 7-3 > index.html
[root@zzzcentos3 html]#cat index.html
welcome to 7-3
調度算法 :
①實驗:輪詢算法?(一人一次)? ?
默認算法是輪詢算法即反向代理服務器處理用戶請求時,每個后端服務器都輪流提供響應?
(1)7-1代理服務器編輯主配置文件
(2)apache后端服務器開啟httpd服務,關閉防火墻,分別建立web文件
檢測:
如果有一天服務器宕機
那么只會跳轉好的那一臺服務器
當其中一臺宕機,就不去訪問他了,直接跳過
那是因為 nginx 有?健康性檢測 機制?就不去壞的服務器了
nginx服務較為只能,通過tcp三次握手可以檢查服務器健康性,當無法完成連通性,默認將不會訪問從而提示報錯。當故障服務器恢復正常后,再次輪巡調度。
② 加權輪詢算法
在默認輪詢的基礎上增加權重,weight=number。如果后端有2個服務器其中一個配置權重為weight=5另外一個不配置默認是1,則有用戶訪問時分配給給有權重的服務器和不配置權重的服務器的比例為5:1
修改7-1代理服務器配置
檢測:客戶端7-1訪問代理服務器
?③最大鏈接數、連續檢測和延遲上線
max_fails=3 ###連你3次,沒反應就認為你宕機了
fail_timeout=30 ###上線后,給一個延遲時間30s,然后再連你
max_conns=10 ###最大連接數,只給你連10個
backup ?#設置為備份服務器,當所有后端服務器不可用時,才會啟用此備用服務器 sorry server ? 自己不能轉自己?
20 upstream web {21 server 192.168.246.8;22 server 192.168.246.9 max_conns=10 max_fails=3 fail_timeout=30s;23 }
#max_conns=number #給當前后端server設置最大活動鏈接數,默認為0表示沒有限制
#max_fails=number 后端服務器的下線條件,當客戶端訪問時,對本次調度選中的后端服務器連續進行檢測多少次,如果都失敗就標記為不可用,默認為1次,當客戶端訪問時,才會利用TCP觸發對探測后端服務器健康性檢查,而非周期性的探測
#fail_timeout=time 后端服務器的上線條件,對已經檢測到處于不可用的后端服務器,每隔此時間間隔再次進行檢測是否恢復可用,如果發現可用,則將后端服務器參與調度,默認為10秒。這樣避免服務器剛上線不穩定再次導致業務失敗
④備份服務器
當所有后端服務器不可用時,才會啟用此備用服務器sorry server,自己不能轉自己。
?
upstream web {hash $remote_addr;server 192.168.246.8;server 192.168.246.9 backup;}?
檢測:客戶端7-3訪問代理服務器7-2? ? (7-2或7-1做客戶機都可以)
如果服務器宕機,就會啟用備用服務器
如果需要維護,具體看看在哪臺寫,可以寫入寫內容
⑤hash調度操作
(1)ip hash根據客戶端ip:
ip hash??$remote_addr? 客戶端真實ip
基于客戶端IP地址的負載均衡算法。它會根據客戶端的IP地址,將該客戶端的所有請求都發送到同一個后端服務器上。這樣可以保證同一個客戶端的所有請求都被發送到同一個后端服務器,從而保證了會話的一致性。
upstream web {hash $remote_addr;server 192.168.246.8;server 192.168.246.9;}
① 修改代理服務器配置
② 客戶端訪問
hash算法會將Web頁面訪問的緩存定在某一個代理服務器;但是hash算法有一個缺點就是hash還要除以權重,下次重載配置會更換Web服務的代理服務器
(2)?url hash
20 upstream web { 21 hash $request_uri; #發送請求的地址,一旦確定不會輕易改變22 server 192.168.246.8;23 server 192.168.246.9;24 }
① 修改代理服務器配置
② 客戶端訪問
(3)cookie??
upstream web {hash $cookie_hello;server 192.168.246.8;server 192.168.246.9;}
① 修改代理服務器配置
② 客戶端模擬加上cookie訪問
也是固定會話
(4) fair
基于后端服務器的負載均衡算法。它會根據后端服務器的響應時間,將請求發送到響應時間最短的服務器上。這樣可以保證請求被發送到處理能力最強的服務器上,從而提高系統的性能
二、總結
1、負載均衡
http {upstream web {server 192.168.246.8;server 192.168.246.9;}server {location / {proxy_pass http://web/;}
}
}
2、調度算法? ??
3、ip透傳
4、httpd服務和nginx服務開啟問題
三、stream 服務模塊
官網
stream? 實現反向代理功能, 是四層模塊,只能控制tcp、udp
(實現反向代理功能,包括TCP協議代理)
?stream和http模塊是同級
四層代理和七層代理的區別:
4層是指傳輸層的 TCP/UDP 協議7層是指應用層的 HTTP 協議
代理原理:
? ? ?4層代理:使用 NAT(Network Address Translation)技術,即網絡地址轉換。即請求進來的時候,nginx 只修改數據包里面的目標IP、源IP、端口,然后就直接把數據包發給目標服務器(即nginx不知道請求的具體內容),目標服務器處理完成后,發給 nginx,nginx 數據包再做一次類似的修改,就返回給請求的客戶端了。
? ? ?7層代理:nginx 讀取并解析 Http 請求內容,然后將具體內容(請求行、請求頭、空行、請求數據)轉發到相應的服務器,轉發的過程是:建立和目標機器的連接,然后轉發請求,收到響應數據再轉發給請求客戶端。