[TOC] 轉載：https://www.modb.pro/db/29292 ## TCP的三次握手和四次揮手  ## TIME_WAIT概述 TIME_WAIT 狀態： * TCP 連接中，**主動關閉連接**的一方出現的狀態；（收到 FIN 命令，進入 TIME\_WAIT 狀態，并返回 ACK 命令） * 保持 2 個?`MSL` ?時間，即，`4 分鐘` ；（MSL 為 2 分鐘） >TCP 連接建立后，「**主動關閉連接**」的一端，收到對方的 FIN 請求后，發送 ACK 響應，會處于 time\_wait 狀態； 在高并發的場景下，`TIME_WAIT` ?連接存在，屬于正常現象。 線上場景中，持續的高并發場景 * 一部分?`TIME_WAIT` ?連接被回收，但新的?`TIME_WAIT` ?連接產生； * 一些極端情況下，會出現**大量**的?`TIME_WAIT` ?連接。 ## 大量的time_wait狀態TCP連接，有什么業務上的影響 * TCP 連接中，「主動發起關閉連接」的一端，會進入 time\_wait 狀態 * time\_wait 狀態，默認會持續?`2 MSL` （報文的最大生存時間），一般是 2x2 mins * time\_wait 狀態下，TCP 連接占用的端口，無法被再次使用 * 每一個 time\_wait 狀態，都會占用一個「本地端口」，上限為?`65535` (16 bit，2 Byte)； * 當大量的連接處于?`time_wait` ?時，新建立 TCP 連接會出錯，**address already in use : connect**?異常 >TCP 本地端口數量，上限為?`65535` （6.5w），這是因為 TCP 頭部使用?`16 bit` ，存儲「**端口號**」，因此約束上限為?`65535` 。 ## 現實場景 * 服務器端，一般設置：**不允許**「主動關閉連接」，但 HTTP 請求中，http 頭部 connection 參數，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接 。現在瀏覽器中， HTTP 請求?`connection` ?參數，一般都設置為?`keep-alive` * Nginx 反向代理場景中，可能出現大量短鏈接，服務器端，可能存在 ## 問題分析 大量的TIME_WAIT狀態TCP連接存在，其本質原因是什么？ * 大量短鏈接存在 * 特別是http請求中，如果connection頭部取值被設置為close時，基本都由【服務端】發起主動關閉連接，而TCP四次揮手關閉連接機制中，為了保證ACK重發和丟棄延遲數據，設置TIME_WAIT為2倍的MSL（報文存活最大時間） ## 解決time_wait的辦法 解決上述?`time_wait` ?狀態大量存在，導致新連接創建失敗的問題，一般解決辦法： 1、**客戶端**，HTTP 請求的頭部，connection 設置為 keep-alive，保持存活一段時間：現在的瀏覽器，一般都這么進行了 2、**服務器端**， * 允許?`time_wait` ?狀態的 socket 被**重用** * 縮減?`time_wait` ?時間，設置為?`1 MSL` （即，2 mins） ## 幾個核心問題 ### ?**time\_wait 是「服務器端」的狀態？or 「客戶端」的狀態？** * RE：time\_wait 是「主動關閉 TCP 連接」一方的狀態，可能是「客服端」的，也可能是「服務器端」的 * 一般情況下，都是「客戶端」所處的狀態；「服務器端」一般設置「不主動關閉連接」 ### **服務器在對外服務時，是「客戶端」發起的斷開連接？還是「服務器」發起的斷開連接？** * 正常情況下，都是「客戶端」發起的斷開連接 * 「服務器」一般設置為「不主動關閉連接」，服務器通常執行「被動關閉」 * 但 HTTP 請求中，http 頭部 connection 參數，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接 ### 關于 HTTP 請求中，設置的主動關閉 TCP 連接的機制：TIME\_WAIT的是主動斷開方才會出現的，所以主動斷開方是服務端？ * 是的。在HTTP1.1協議中，有個 Connection 頭，Connection有兩個值，close和keep-alive，這個頭就相當于客戶端告訴服務端，服務端你執行完成請求之后，是關閉連接還是保持連接，保持連接就意味著在保持連接期間，只能由客戶端主動斷開連接。還有一個keep-alive的頭，設置的值就代表了服務端保持連接保持多久。 * HTTP默認的Connection值為close，那么就意味著關閉請求的一方幾乎都會是由服務端這邊發起的。那么這個服務端產生TIME\_WAIT過多的情況就很正常了。 * 雖然HTTP默認Connection值為close，但是，現在的瀏覽器發送請求的時候一般都會設置Connection為keep-alive了。所以，也有人說，現在沒有必要通過調整參數來使TIME\_WAIT降低了。 ### 為什么需要time_wait * **可靠的實現 TCP 全雙工連接的終止**：四次揮手關閉 TCP 連接過程中，最后的 ACK 是由「主動關閉連接」的一端發出的，如果這個 ACK 丟失，則，對方會重發 FIN 請求，因此，在「主動關閉連接」的一段，需要維護一個 time\_wait 狀態，處理對方重發的 FIN 請求； * **處理延遲到達的報文**：由于路由器可能抖動，TCP 報文會延遲到達，為了避免「延遲到達的 TCP 報文」被誤認為是「新 TCP 連接」的數據，則，需要在允許新創建 TCP 連接之前，保持一個不可用的狀態，等待所有延遲報文的消失，一般設置為 2 倍的 MSL（報文的最大生存時間），解決「延遲達到的 TCP 報文」問題； ## linux下解決TIME_WAIT 編輯內核文件/etc/sysctl.conf，加入以下內容： ``` net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉； net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉； net.ipv4.tcp_tw_recycle = 0 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。 net.ipv4.tcp_fin_timeout = 30修改系默認的 TIMEOUT 時間 ``` 然后執行 /sbin/sysctl -p 讓參數生效. ``` /etc/sysctl.conf是一個允許改變正在運行中的Linux系統的接口，它包含一些TCP/IP堆棧和虛擬內存系統的高級選項，修改內核參數永久生效。 ``` 簡單來說，就是打開系統的TIMEWAIT重用和快速回收。 如果以上配置調優后性能還不理想，可繼續修改一下配置： ``` $ vi /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200 #表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為20分鐘。 net.ipv4.ip_local_port_range = 1024 65000 #表示用于向外連接的端口范圍。缺省情況下很小：32768到61000，改為1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數。 net.ipv4.tcp_max_tw_buckets = 5000 #表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除并打印警告信息。 默認為180000，改為5000。對于Apache、Nginx等服務器，上幾行的參數可以很好地減少TIME_WAIT套接字數量，但是對于 Squid，效果卻不大。此項參數可以控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死。 ```