W3Cschool
恭喜您成為首批注冊用戶
獲得88經(jīng)驗值獎勵
這個是高并發(fā)服務(wù)端常見的一個問題,一般的做法是修改 sysctl 的參數(shù)來解決。 但是,做為一個有追求的程序猿,你需要多問幾個為什么,為什么會出現(xiàn) TIME_WAIT?出現(xiàn)這個合理嗎?
我們需要先回顧下 tcp 的知識,請看下面的狀態(tài)轉(zhuǎn)換圖(圖片來自「 The TCP/IP Guide 」):
因為 TCP 連接是雙向的,所以在關(guān)閉連接的時候,兩個方向各自都需要關(guān)閉。 先發(fā) FIN 包的一方執(zhí)行的是主動關(guān)閉;后發(fā) FIN 包的一方執(zhí)行的是被動關(guān)閉。 主動關(guān)閉的一方會進入 TIME_WAIT 狀態(tài),并且在此狀態(tài)停留兩倍的 MSL 時長。
修改 sysctl 的參數(shù),只是控制 TIME_WAIT 的數(shù)量。你需要很明確的知道,在你的應(yīng)用場景里面,你預(yù)期是服務(wù)端還是客戶端來主動關(guān)閉連接的。一般來說,都是客戶端來主動關(guān)閉的。
Nginx 在某些情況下,會主動關(guān)閉客戶端的請求,這個時候,返回值的 connection 為 close。我們看兩個例子:
請求包:
GET /hello HTTP/1.0
User-Agent: curl/7.37.1
Host: 127.0.0.1
Accept: */*
Accept-Encoding: deflate, gzip
應(yīng)答包:
HTTP/1.1 200 OK
Date: Wed, 08 Jul 2015 02:53:54 GMT
Content-Type: text/plain
Connection: close
hello world
對于 HTTP 1.0 協(xié)議,如果請求頭里面沒有包含 connection,那么應(yīng)答默認是返回 Connection: close, 也就是說 Nginx 會主動關(guān)閉連接。
請求包:
POST /api/heartbeat.json HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: Keep-Alive
Content-Length: 0
應(yīng)答包:
HTTP/1.1 200 OK
Date: Mon, 06 Jul 2015 09:35:34 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: close
Content-Encoding: gzip
這個請求包是 HTTP 1.1 的協(xié)議,也聲明了 Connection: Keep-Alive,為什么還會被 Nginx 主動關(guān)閉呢? 問題出在 User-Agent,Nginx 認為終端的瀏覽器版本太低,不支持 keep alive,所以直接 close 了。
在我們應(yīng)用的場景下,終端不是通過瀏覽器而是后臺請求的, 而我們也沒法控制終端的 User-Agent,那有什么方法不讓 Nginx 主動去關(guān)閉連接呢? 可以用keepalive_disable這個參數(shù)來解決。這個參數(shù)并不是字面的意思,用來關(guān)閉 keepalive, 而是用來定義哪些古代的瀏覽器不支持 keepalive 的,默認值是 MSIE6。
keepalive_disable none;
修改為 none,就是認為不再通過 User-Agent 中的瀏覽器信息,來決定是否 keepalive。
注:本文內(nèi)容參考了火丁筆記和Nginx 開發(fā)從入門到精通,感謝大牛的分享。
Copyright©2021 w3cschool編程獅|閩ICP備15016281號-3|閩公網(wǎng)安備35020302033924號
違法和不良信息舉報電話:173-0602-2364|舉報郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號
聯(lián)系方式:
更多建議: