nginx反向代理下的長連接實現(xiàn)
一、nginx使用場景
大型應用架構中,一般會使用nginx反向代理,分為三層:
1.調(diào)用層,瀏覽器或APP;
2.中間層,反向代理nginx;
3.服務層,server一般是apche、tomcat

請求調(diào)用過程:
1.瀏覽器/app發(fā)起請求
2.DNS解析網(wǎng)址為ip地址
3.通過外網(wǎng)ip訪問nginx
4.nginx發(fā)送請求給內(nèi)網(wǎng)ip的server

上面架構,要想支持全鏈路的長連接,需要做到兩點:
1.從client到nginx的連接是長連接;
2.從nginx到server的連接是長連接;
二、長連接設置
1.client到nginx的長連接:
由于目前瀏覽器默認使用HTTP/1.1,請求header中默認設置Connection:keep-alive,所以只需在nginx配置中做如下配置:
http {
keepalive_timeount 120s 120s;
keepalive_requests 10000;
}#語法
keepalive_timeout timeout [header_timeout]
第一個參數(shù)(timeout):設置keep_alive客戶端(瀏覽器)連接在服務端(nginx端)保持開啟的超時值(默認75s);值為0會禁用keep_alive客戶端連接;
第二個參數(shù)(header_timeout):可選,在響應的header中設置值“Keep-Alive:timeout=time”;通??梢圆挥迷O置;
keepalive_requests這個配置項用于設置一個keep-alive連接上可以服務的請求最大數(shù)量,當達到配置的最大請求數(shù)時,連接會被關閉,默認值為100.具體過程時指一個keep-alive連接建立之后,nginx會為這個連接設置一個計數(shù)器,記錄這個長連接上已經(jīng)接收并處理的客戶端請求的數(shù)量,一旦達到設置的最大值時,nginx會強行關閉這個長連接,此時如果客戶端有新請求,就需要重新建立新的長連接。
注:在QPS較高的場景下,服務端需要將keepalive_requests設置大一些,默認數(shù)值就不夠了,否則服務端可能會出現(xiàn)大量的TIME_WAIT狀態(tài)的TCP連接數(shù)異常!另外nginx(version 1.15.3)在Upstream內(nèi)增加了keepalive_requests配置項,默認值也是100,也是需要手動設置,而且這兩個數(shù)量可以不一致,一般服務端要設置的大些,因為多數(shù)情況是一個nginx代理對應多個服務端。
2.nginx和server的長連接
默認情況下,nginx訪問后端都是用的短連接(HTTP/1.0)一個請求來了,nginx會新開一個端口和后端建立連接,后端執(zhí)行完畢后主動關閉該tcp連接。為了讓nginx和后端server(nginx稱之為upstream)之間保持長連接,典型設置如下:
http {
upstream http_backend {
server 192.168.2.154:8080;
server 192.168.2.109:8080;
keepalive 32; # 長連接緩存池大小為32
keepalive_timeout 120s; # 長連接失效時間
keepalive_requests 2000; # 每條長連接最大復用請求數(shù)為2000
}
server {
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1; # 啟用HTTP/1.1版本與被代理服務器建立連接
proxy_set_header Connection "Keep-Alive"; # 設置發(fā)送被代理服務器請求頭屬性字段Connection
}
}nginx 與被代理服務器間建立的長連接是通過啟用 HTTP/1.1 版本協(xié)議實現(xiàn)的。由于 HTTP 代理模塊默認會將發(fā)往被代理服務器的請求頭屬性字段 Connection 的值設置為 Close,因此需要通過配置指令設置請求頭屬性字段 Connection 的內(nèi)容為“Keep-Alive”或者空值。
另外upstream中的keepalive_timeout和keepalive_requests參數(shù)與上面的含義一樣,不做過多解析,需要重點關注keepalive參數(shù),他的含義是指設置到upstream服務器的空閑keepalive連接的最大數(shù),當這個數(shù)量被突破時,最近最少使用的連接將被關閉,另外這個參數(shù)不會限制一個nginx worker進程到upstream服務器連接的總數(shù)量,有點像線程池中的核心線程數(shù)。
注:keepalive參數(shù)設置一定要合理,尤其對于QPS比較高的場景,推薦做一下估算,根據(jù)QPS和平均響應時間大概計算出需要長連接的數(shù)量,盡量避免系統(tǒng)運行時產(chǎn)生連接數(shù)量的反復震蕩,比如keepalive設置為10,前一秒系統(tǒng)qps較低,只需50個長連接,用完立馬關閉其中50-10=40個連接,而后一秒系統(tǒng)qps突增,需要150個連接,空缺了150-10=140個連接,此時nginx不得不新建140個新連接來滿足要求。
三、問題總結
綜上所述,nginx反向代理的情況下,tcp長連接設置完成。在實際系統(tǒng)應用長連接的場景中,可能會出現(xiàn)大量TIME_WAIT的情況,這里簡單做個總結:
1.導致nginx端出現(xiàn)大量TIME_WAIT的情況有兩種:
a.keepalive_requests設置比較小,高并發(fā)下超過此值后nginx會強制關閉和客戶端的長連接;(主動關閉連接后導致nginx出現(xiàn)TIME_WAIT)
b.keepalive設置比較?。臻e數(shù)太?。?,導致高并發(fā)下nginx會頻繁出現(xiàn)連接數(shù)震蕩,不停的關閉、開啟和后端server的長連接;
2.導致后端server端出現(xiàn)大量TIME_WAIT的情況:
nginx沒有打開和后端的長連接,即:沒有設置proxy_http_version 1.1和proxy_set_header Connection "Keep-Alive",從而導致后端server每次請求后就關閉連接,高并發(fā)下就會出現(xiàn)server端的大量TIME_WAIT.
到此這篇關于nginx反向代理下的長連接實現(xiàn)的文章就介紹到這了,更多相關nginx反向代理長連接內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

