站長資訊網(wǎng)【場景描述】
HTTP1.1之后，HTTP協(xié)議支持持久連接，也就是長連接，優(yōu)點(diǎn)在于在一個(gè)TCP連接上可以傳送多個(gè)HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。
如果我們使用了nginx去作為反向代理或者負(fù)載均衡，從客戶端過來的長連接請求就會被轉(zhuǎn)換成短連接發(fā)送給服務(wù)器端。
為了支持長連接，我們需要在nginx服務(wù)器上做一些配置。
【要求】
使用nginx時(shí)，想要做到長連接，我們必須做到以下兩點(diǎn)：
1.從client到nginx是長連接
2.從nginx到server是長連接
對于客戶端而言，nginx其實(shí)扮演著server的角色，反之，之于server，nginx就是一個(gè)client。
【保持和 Client 的長連接】
我們要想做到Client與Nginx之間保持長連接，需要：
1.Client發(fā)送過來的請求攜帶”keep-alive”header。
2.Nginx設(shè)置支持keep-alive
【HTTP配置】
默認(rèn)情況下，nginx已經(jīng)開啟了對client連接的 keepalive 支持。對于特殊場景，可以調(diào)整相關(guān)參數(shù)。
http {
keepalive_timeout 120s; #客戶端鏈接超時(shí)時(shí)間。為0的時(shí)候禁用長連接。
keepalive_requests 10000; #在一個(gè)長連接上可以服務(wù)的最大請求數(shù)目。
#當(dāng)達(dá)到最大請求數(shù)目且所有已有請求結(jié)束后，連接被關(guān)閉。
#默認(rèn)值為100
}
大多數(shù)情況下，keepalive_requests = 100也夠用，但是對于 QPS 較高的場景，非常有必要加大這個(gè)參數(shù)，以避免出現(xiàn)大量連接被生成再拋棄的情況，減少TIME_WAIT。
QPS=10000 時(shí)，客戶端每秒發(fā)送 10000 個(gè)請求 (通常建立有多個(gè)長連接)，每個(gè)連接只能最多跑 100 次請求，意味著平均每秒鐘就會有 100 個(gè)長連接因此被 nginx 關(guān)閉。
同樣意味著為了保持 QPS，客戶端不得不每秒中重新新建 100 個(gè)連接。
因此，如果用netstat命令看客戶端機(jī)器，就會發(fā)現(xiàn)有大量的TIME_WAIT的socket連接 (即使此時(shí)keep alive已經(jīng)在 Client 和 NGINX 之間生效)。
·【保持和Server的長連接】
想讓Nginx和Server之間維持長連接，最樸素的設(shè)置如下：
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; // 這個(gè)很重要！
}
server {
listen 8080 default_server;
server_name “”;
location / {
proxy_pass http://backend;
proxy_http_version 1.1; # 設(shè)置http版本為1.1
proxy_set_header Connection “”; # 設(shè)置Connection為長連接（默認(rèn)為no）}
}
}
}
【upstream配置】
upstream中，有一個(gè)參數(shù)特別的重要，就是keepalive。
這個(gè)參數(shù)和之前http里面的 keepalive_timeout 不一樣。
這個(gè)參數(shù)的含義是，連接池里面最大的空閑連接數(shù)量。
不理解？沒關(guān)系，我們來舉個(gè)例子：
場景：
有一個(gè)HTTP服務(wù)，作為upstream服務(wù)器接收請求，響應(yīng)時(shí)間為100毫秒。
要求性能達(dá)到10000 QPS，我們需要在nginx與upstream服務(wù)器之間建立大概1000條HTTP請求。（1000/0.1s=10000）
最優(yōu)情況：
假設(shè)請求非常的均勻平穩(wěn)，每一個(gè)請求都是100ms，請求結(jié)束會被馬上放入連接池并置為idle（空閑）狀態(tài)。
我們以0.1s為單位：
1. 我們現(xiàn)在keepalive的值設(shè)置為10，每0.1s鐘有1000個(gè)連接
2. 第0.1s的時(shí)候，我們一共有1000個(gè)請求收到并釋放
3. 第0.2s的時(shí)候，我們又來了1000個(gè)請求，在0.2s結(jié)束的時(shí)候釋放
請求和應(yīng)答都比較均勻，0.1s釋放的連接正好夠用，不需要建立新連接，且連接池中沒有idle狀態(tài)的連接。
第一種情況：
應(yīng)答非常平穩(wěn)，但是請求不平穩(wěn)的時(shí)候
4. 第0.3s的時(shí)候，我們只有500個(gè)請求收到，有500個(gè)請求因?yàn)榫W(wǎng)絡(luò)延遲等原因沒有進(jìn)來
這個(gè)時(shí)候，Nginx檢測到連接池中有500個(gè)idle狀態(tài)的連接，就直接關(guān)閉了（500-10）個(gè)連接
5. 第0.4s的時(shí)候，我們收到了1500個(gè)請求，但是現(xiàn)在池里面只有（500+10）個(gè)連接，所以Nginx不得不重新建立了（1500-510）個(gè)連接。
如果在第4步的時(shí)候，沒有關(guān)閉那490個(gè)連接的話，只需要重新建立500個(gè)連接。
第二種情況：
請求非常平穩(wěn)，但是應(yīng)答不平穩(wěn)的時(shí)候
4. 第0.3s的時(shí)候，我們一共有1500個(gè)請求收到
但是池里面只有1000個(gè)連接，這個(gè)時(shí)候，Nginx又創(chuàng)建了500個(gè)連接，一共1500個(gè)連接
5. 第0.3s的時(shí)候，第0.3s的連接全部被釋放，我們收到了500個(gè)請求
Nginx檢測到池里面有1000個(gè)idle狀態(tài)的連接，所以不得不釋放了（1000-10）個(gè)連接
造成連接數(shù)量反復(fù)震蕩的一個(gè)推手，就是這個(gè)keepalive 這個(gè)最大空閑連接數(shù)。
上面的兩種情況說的都是 keepalive 設(shè)置的不合理導(dǎo)致Nginx有多次釋放與創(chuàng)建連接的過程，造成資源浪費(fèi)。
keepalive 這個(gè)參數(shù)設(shè)置一定要小心，尤其是對于 QPS 要求比較高或者網(wǎng)絡(luò)環(huán)境不穩(wěn)定的場景，一般根據(jù) QPS 值和 平均響應(yīng)時(shí)間能大致推算出需要的長連接數(shù)量。
然后將keepalive設(shè)置為長連接數(shù)量的10%到30%。
【location配置】
http {
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1; # 設(shè)置http版本為1.1
proxy_set_header Connection “”; # 設(shè)置Connection為長連接（默認(rèn)為no）
}
}
}
HTTP 協(xié)議中對長連接的支持是從 1.1 版本之后才有的，因此最好通過 proxy_http_version 指令設(shè)置為 1.1。
HTTP1.0不支持keepalive特性，當(dāng)沒有使用HTTP1.1的時(shí)候，后端服務(wù)會返回101錯(cuò)誤，然后斷開連接。
而 “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的連接超時(shí)時(shí)間（沒有單位，最大不可以超過75s）
proxy_read_timeout 60s; #nginx會等待多長時(shí)間來獲得請求的響應(yīng)
proxy_send_timeout 12s; #發(fā)送請求給upstream服務(wù)器的超時(shí)時(shí)間
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
}
http里面的map的作用是：
讓轉(zhuǎn)發(fā)到代理服務(wù)器的 “Connection” 頭字段的值，取決于客戶端請求頭的 “Upgrade” 字段值。
如果 $http_upgrade沒有匹配，那 “Connection” 頭字段的值會是upgrade。
如果 $http_upgrade為空字符串的話，那 “Connection” 頭字段的值會是 close。
【補(bǔ)充】
NGINX支持WebSocket。
對于NGINX將升級請求從客戶端發(fā)送到后臺服務(wù)器，必須明確設(shè)置Upgrade和Connection標(biāo)題。
這也算是上面情況所非常常用的場景。
HTTP的Upgrade協(xié)議頭機(jī)制用于將連接從HTTP連接升級到WebSocket連接，Upgrade機(jī)制使用了Upgrade協(xié)議頭和Connection協(xié)議頭。
為了讓Nginx可以將來自客戶端的Upgrade請求發(fā)送到后端服務(wù)器，Upgrade和Connection的頭信息必須被顯式的設(shè)置。
【注意】
在nginx的配置文件中，如果當(dāng)前模塊中沒有proxy_set_header的設(shè)置，則會從上級別繼承配置。
繼承順序?yàn)椋篽ttp, server, location。
如果在下一層使用proxy_set_header修改了header的值，則所有的header值都可能會發(fā)生變化，之前繼承的所有配置將會被丟棄。
所以，盡量在同一個(gè)地方進(jìn)行proxy_set_header，否則可能會有別的問題。
