# TIME_WAIT 這個是高并發服務端常見的一個問題，一般的做法是修改sysctl的參數來解決。但是，做為一個有追求的程序猿，你需要多問幾個為什么，為什么會出現TIME_WAIT？出現這個合理嗎？ 我們需要先回顧下tcp的知識，請看下面的狀態轉換圖（圖片來自[「The TCP/IP Guide」](http://www.tcpipguide.com/)）： 因為TCP連接是雙向的，所以在關閉連接的時候，兩個方向各自都需要關閉。先發FIN包的一方執行的是主動關閉；后發FIN包的一方執行的是被動關閉。**_主動關閉的一方會進入TIME_WAIT狀態，并且在此狀態停留兩倍的MSL時長。_** 修改sysctl的參數，只是控制TIME_WAIT的數量。你需要很明確的知道，在你的應用場景里面，你預期是服務端還是客戶端來主動關閉連接的。一般來說，都是客戶端來主動關閉的。 nginx在某些情況下，會主動關閉客戶端的請求，這個時候，返回值的connection為close。我們看兩個例子： - #### http 1.0協議 請求包： ~~~ GET /hello HTTP/1.0 User-Agent: curl/7.37.1 Host: 127.0.0.1 Accept: */* Accept-Encoding: deflate, gzip ~~~ 應答包： ~~~ HTTP/1.1 200 OK Date: Wed, 08 Jul 2015 02:53:54 GMT Content-Type: text/plain Connection: close Server: 360 web server hello world ~~~ 對于http 1.0協議，如果請求頭里面沒有包含connection，那么應答默認是返回Connection: close，也就是說nginx會主動關閉連接。 - #### user agent 請求包： ~~~ 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 ~~~ 應答包： ~~~ HTTP/1.1 200 OK Date: Mon, 06 Jul 2015 09:35:34 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: close Server: 360 web server Content-Encoding: gzip ~~~ 這個請求包是http1.1的協議，也聲明了Connection: Keep-Alive，為什么還會被nginx主動關閉呢？**_問題出在User-Agent_**，nginx認為終端的瀏覽器版本太低，不支持keep alive，所以直接close了。 在我們應用的場景下，終端不是通過瀏覽器而是后臺請求的，而我們也沒法控制終端的User-Agent，那有什么方法不讓nginx主動去關閉連接呢？可以用[keepalive_disable](http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable)這個參數來解決。這個參數并不是字面的意思，用來關閉keepalive，而是用來定義哪些古代的瀏覽器不支持keepalive的，默認值是MSIE6。 ~~~ keepalive_disable none; ~~~ 修改為none，就是認為不再通過User-Agent中的瀏覽器信息，來決定是否keepalive。 注：本文內容參考了[火丁筆記](http://huoding.com/2013/12/31/316)和[Nginx開發從入門到精通](http://tengine.taobao.org/book/chapter_02.html)，感謝大牛的分享。