轉：https://www.cnblogs.com/liuxia912/p/11075630.html
·【場景描述】
HTTP1.1之後，HTTP協議支持持久連接，也就是長連接，優點在於在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。
如果我們使用了nginx去作爲反向代理或者負載均衡，從客戶端過來的長連接請求就會被轉換成短連接發送給服務器端。
爲了支持長連接，我們需要在nginx服務器上做一些配置。
·【要求】
使用nginx時，想要做到長連接，我們必須做到以下兩點：
- 從client到nginx是長連接
- 從nginx到server是長連接
對於客戶端而言，nginx其實扮演着server的角色，反之，之於server，nginx就是一個client。
·【保持和 Client 的長連接】
我們要想做到Client與Nginx之間保持長連接，需要：
- Client發送過來的請求攜帶"keep-alive"header。
- 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/