nginx反向代理時保持長鏈接

·【場景描述】

HTTP1.1以後，HTTP協議支持持久鏈接，也就是長鏈接，優勢在於在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。

若是咱們使用了nginx去做爲反向代理或者負載均衡，從客戶端過來的長鏈接請求就會被轉換成短鏈接發送給服務器端。

爲了支持長鏈接，咱們須要在nginx服務器上作一些配置。

   

·【要求】

使用nginx時，想要作到長鏈接，咱們必須作到如下兩點：

1. 從client到nginx是長鏈接
2. 從nginx到server是長鏈接

   

對於客戶端而言，nginx其實扮演着server的角色，反之，之於server，nginx就是一個client。

   

·【保持和 Client 的長鏈接】

咱們要想作到Client與Nginx之間保持長鏈接，須要：

1. Client發送過來的請求攜帶"keep-alive"header。
2. Nginx設置支持keep-alive

   

【HTTP配置】

默認狀況下，nginx已經開啓了對client鏈接的 keepalive 支持。對於特殊場景，能夠調整相關參數。

http { keepalive_timeout 120s;        #客戶端連接超時時間。爲0的時候禁用長鏈接。 keepalive_requests 10000;    #在一個長鏈接上能夠服務的最大請求數目。                                                   #當達到最大請求數目且全部已有請求結束後，鏈接被關閉。                                                   #默認值爲100 }

   

大多數狀況下，keepalive_requests = 100也夠用，可是對於 QPS 較高的場景，很是有必要加大這個參數，以免出現大量鏈接被生成再拋棄的狀況，減小TIME_WAIT。
 

QPS=10000 時，客戶端每秒發送 10000 個請求 (一般創建有多個長鏈接)，每一個鏈接只能最多跑 100 次請求，意味着平均每秒鐘就會有 100 個長鏈接所以被 nginx 關閉。

一樣意味着爲了保持 QPS，客戶端不得不每秒中從新新建 100 個鏈接。

   

所以，若是用netstat命令看客戶端機器，就會發現有大量的TIME_WAIT的socket鏈接 (即便此時keep alive已經在 Client 和 NGINX 之間生效)。

   

·【保持和Server的長鏈接】

想讓Nginx和Server之間維持長鏈接，最樸素的設置以下：

http { upstream backend {   server 192.168.0.1：8080 weight=1 max_fails=2 fail_timeout=30s;   server 192.168.0.2：8080 weight=1 max_fails=2 fail_timeout=30s;   keepalive 300; // 這個很重要！ }    server { listen 8080 default_server; server_name "";     location / { proxy_pass http://backend; proxy_http_version 1.1;                         # 設置http版本爲1.1 proxy_set_header Connection "";      # 設置Connection爲長鏈接（默認爲no）} } } }

   

【upstream配置】

upstream中，有一個參數特別的重要，就是keepalive。

這個參數和以前http裏面的 keepalive_timeout 不同。

這個參數的含義是，鏈接池裏面最大的空閒鏈接數量。

   

不理解？不要緊，咱們來舉個例子：

場景：

有一個HTTP服務，做爲upstream服務器接收請求，響應時間爲100毫秒。

要求性能達到10000 QPS，咱們須要在nginx與upstream服務器之間創建大概1000條HTTP請求。（1000/0.1s=10000）

   

最優狀況：

假設請求很是的均勻平穩，每個請求都是100ms，請求結束會被立刻放入鏈接池並置爲idle（空閒）狀態。

咱們以0.1s爲單位：

1. 咱們如今keepalive的值設置爲10，每0.1s鐘有1000個鏈接

2. 第0.1s的時候，咱們一共有1000個請求收到並釋放

3. 第0.2s的時候，咱們又來了1000個請求，在0.2s結束的時候釋放

   

請求和應答都比較均勻，0.1s釋放的鏈接正好夠用，不須要創建新鏈接，且鏈接池中沒有idle狀態的鏈接。

   

第一種狀況：

應答很是平穩，可是請求不平穩的時候

4. 第0.3s的時候，咱們只有500個請求收到，有500個請求由於網絡延遲等緣由沒有進來

這個時候，Nginx檢測到鏈接池中有500個idle狀態的鏈接，就直接關閉了（500-10）個鏈接

5. 第0.4s的時候，咱們收到了1500個請求，可是如今池裏面只有（500+10）個鏈接，因此Nginx不得不從新創建了（1500-510）個鏈接。

若是在第4步的時候，沒有關閉那490個鏈接的話，只須要從新創建500個鏈接。

   

第二種狀況：

請求很是平穩，可是應答不平穩的時候

4. 第0.3s的時候，咱們一共有1500個請求收到

可是池裏面只有1000個鏈接，這個時候，Nginx又建立了500個鏈接，一共1500個鏈接

5. 第0.3s的時候，第0.3s的鏈接所有被釋放，咱們收到了500個請求

Nginx檢測到池裏面有1000個idle狀態的鏈接，因此不得不釋放了（1000-10）個鏈接

   

形成鏈接數量反覆震盪的一個推手，就是這個keepalive 這個最大空閒鏈接數。

上面的兩種狀況說的都是 keepalive 設置的不合理致使Nginx有屢次釋放與建立鏈接的過程，形成資源浪費。

   

keepalive 這個參數設置必定要當心，尤爲是對於 QPS 要求比較高或者網絡環境不穩定的場景，通常根據 QPS 值和 平均響應時間能大體推算出須要的長鏈接數量。

而後將keepalive設置爲長鏈接數量的10%到30%。

   

【location配置】

http { server { location / { proxy_pass http://backend; proxy_http_version 1.1;                         # 設置http版本爲1.1 proxy_set_header Connection "";      # 設置Connection爲長鏈接（默認爲no） } } }

HTTP 協議中對長鏈接的支持是從 1.1 版本以後纔有的，所以最好經過 proxy_http_version 指令設置爲 1.1。

HTTP1.0不支持keepalive特性，當沒有使用HTTP1.1的時候，後端服務會返回101錯誤，而後斷開鏈接。

   

而 "Connection" header 能夠選擇被清理，這樣即使是 Client 和 Nginx 之間是短鏈接，Nginx 和 upstream 之間也是能夠開啓長鏈接的。

   

【另一種高級方式】

http { map $http_upgrade $connection_upgrade { default upgrade; '' close; }    upstream backend { server 192.168.0.1：8080 weight=1 max_fails=2 fail_timeout=30s; server 192.168.0.2：8080 weight=1 max_fails=2 fail_timeout=30s; keepalive 300; }    server { listen 8080 default_server; server_name ""; location / { proxy_pass http://backend;     proxy_connect_timeout 15;       #與upstream server的鏈接超時時間（沒有單位，最大不能夠超過75s） proxy_read_timeout 60s;           #nginx會等待多長時間來得到請求的響應 proxy_send_timeout 12s;           #發送請求給upstream服務器的超時時間    proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } }

   

http裏面的map的做用是：

讓轉發到代理服務器的 "Connection" 頭字段的值，取決於客戶端請求頭的 "Upgrade" 字段值。

若是 $http_upgrade沒有匹配，那 "Connection" 頭字段的值會是upgrade。

若是 $http_upgrade爲空字符串的話，那 "Connection" 頭字段的值會是 close。

   

【補充】

NGINX支持WebSocket。

對於NGINX將升級請求從客戶端發送到後臺服務器，必須明確設置Upgrade和Connection標題。

這也算是上面狀況所很是經常使用的場景。

HTTP的Upgrade協議頭機制用於將鏈接從HTTP鏈接升級到WebSocket鏈接，Upgrade機制使用了Upgrade協議頭和Connection協議頭。

爲了讓Nginx能夠將來自客戶端的Upgrade請求發送到後端服務器，Upgrade和Connection的頭信息必須被顯式的設置。

   

【注意】

在nginx的配置文件中，若是當前模塊中沒有proxy_set_header的設置，則會從上級別繼承配置。

繼承順序爲：http, server, location。

   

若是在下一層使用proxy_set_header修改了header的值，則全部的header值均可能會發生變化，以前繼承的全部配置將會被丟棄。

因此，儘可能在同一個地方進行proxy_set_header，不然可能會有別的問題。

   

·【參考】

Nginx中文官方文檔： http://www.nginx.cn/doc/

測試參考文檔： https://www.lijiaocn.com/問題/2019/05/08/nginx-ingress-keep-alive-not-work.html

keep-alive參考文檔： https://wglee.org/2018/12/02/nginx-keepalive/