寫在開頭，大概 4 年前，聽到運維同學提到 TIME_WAIT 狀态的 TCP 連接配接過多的問題，但是當時沒有去細琢磨；最近又聽人說起，是一個新手進行壓測過程中，遇到的問題，是以，花點時間，細深究一下。
從這幾個方面着手：
問題描述：什麼現象？什麼影響？
問題分析
解決方案
底層原理
模拟高并發的場景，會出現批量的 TIME_WAIT 的 TCP 連接配接：
短時間後，所有的 TIME_WAIT 全都消失，被回收，端口包括服務，均正常。
即，在高并發的場景下，TIME_WAIT 連接配接存在，屬于正常現象。
線上場景中，持續的高并發場景
一部分 TIME_WAIT 連接配接被回收，但新的 TIME_WAIT 連接配接産生；
一些極端情況下，會出現大量的 TIME_WAIT 連接配接。
Think：
上述大量的 TIME_WAIT 狀态 TCP 連接配接，有什麼業務上的影響嗎？
Nginx 作為反向代理時，大量的短連結，可能導緻 Nginx 上的 TCP 連接配接處于 time_wait 狀态：
每一個 time_wait 狀态，都會占用一個「本地端口」，上限為 65535(16 bit，2 Byte)；
當大量的連接配接處于 time_wait 時，建立立 TCP 連接配接會出錯，address already in use : connect 異常
統計 TCP 連接配接的狀态：
Tips：TCP 本地端口數量，上限為 65535（6.5w），這是因為 TCP 頭部使用 16 bit，存儲「端口号」，是以限制上限為 65535。
大量的 TIME_WAIT 狀态 TCP 連接配接存在，其本質原因是什麼？
大量的短連接配接存在
特别是 HTTP 請求中，如果 connection 頭部取值被設定為 close 時，基本都由「服務端」發起主動關閉連接配接
而，TCP 四次揮手關閉連接配接機制中，為了保證 ACK 重發和丢棄延遲資料，設定 time_wait 為 2 倍的 MSL（封包最大存活時間）
TIME_WAIT 狀态：
TCP 連接配接中，主動關閉連接配接的一方出現的狀态；（收到 FIN 指令，進入 TIME_WAIT 狀态，并傳回 ACK 指令）
保持 2 個 MSL 時間，即，4 分鐘；（MSL 為 2 分鐘）
解決上述 time_wait 狀态大量存在，導緻新連接配接建立失敗的問題，一般解決辦法：
用戶端，HTTP 請求的頭部，connection 設定為 keep-alive，保持存活一段時間：現在的浏覽器，一般都這麼進行了
伺服器端
允許 time_wait 狀态的 socket 被重用
縮減 time_wait 時間，設定為 1 MSL（即，2 mins）
結論：幾個核心要點
time_wait 狀态的影響：
TCP 連接配接中，「主動發起關閉連接配接」的一端，會進入 time_wait 狀态
time_wait 狀态，預設會持續 2 MSL（封包的最大生存時間），一般是 2x2 mins
time_wait 狀态下，TCP 連接配接占用的端口，無法被再次使用
TCP 端口數量，上限是 6.5w（65535，16 bit）
大量 time_wait 狀态存在，會導緻建立 TCP 連接配接會出錯，address already in use : connect 異常
伺服器端，一般設定：不允許「主動關閉連接配接」
但 HTTP 請求中，http 頭部 connection 參數，可能設定為 close，則，服務端處理完請求會主動關閉 TCP 連接配接
現在浏覽器中， HTTP 請求 connection 參數，一般都設定為 keep-alive
Nginx 反向代理場景中，可能出現大量短連結，伺服器端，可能存在
解決辦法
伺服器端，
幾個方面：
TCP 連接配接狀态的查詢
MSL 時間
TCP 三次握手和四次握手
附錄 A：查詢 TCP 連接配接狀态
Mac 下，查詢 TCP 連接配接狀态的具體指令：
附錄 B：MSL 時間
MSL，Maximum Segment Lifetime，“封包最大生存時間”，
任何封包在網絡上存在的最長時間，超過這個時間封包将被丢棄。（IP 封包）
TCP封包 （segment）是ip資料報（datagram）的資料部分。
Tips：
RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。
2MSL，TCP 的 TIME_WAIT 狀态，也稱為2MSL等待狀态：
當TCP的一端發起主動關閉（收到 FIN 請求），在發出最後一個ACK 響應後，即第3次握 手完成後，發送了第四次握手的ACK包後，就進入了TIME_WAIT狀态。
必須在此狀态上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最後一個 ACK包對方沒收到，那麼對方在逾時後将重發第三次握手的FIN包，主動關閉端接到重發的FIN包後，可以再發一個ACK應答包。
在 TIME_WAIT 狀态時，兩端的端口不能使用，要等到2MSL時間結束，才可繼續使用。（IP 層）
當連接配接處于2MSL等待階段時，任何遲到的封包段都将被丢棄。
不過在實際應用中，可以通過設定 「SO_REUSEADDR選項」，達到不必等待2MSL時間結束，即可使用被占用的端口。
附錄 C：TCP 三次握手和四次握手，詳細細節，參考：TCP的三次握手與四次揮手
具體示意圖：
三次握手，建立連接配接過程
四次揮手，釋放連接配接過程
幾個核心疑問：
time_wait 是「伺服器端」的狀态？or 「用戶端」的狀态？
RE：time_wait 是「主動關閉 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 連接配接建立後，「主動關閉連接配接」的一端，收到對方的 FIN 請求後，發送 ACK 響應，會處于 time_wait 狀态；
time_wait 狀态，存在的必要性：
可靠的實作 TCP 全雙工連接配接的終止：四次揮手關閉 TCP 連接配接過程中，最後的 ACK 是由「主動關閉連接配接」的一端發出的，如果這個 ACK 丢失，則，對方會重發 FIN 請求，是以，在「主動關閉連接配接」的一段，需要維護一個 time_wait 狀态，處理對方重發的 FIN 請求；
處理延遲到達的封包：由于路由器可能抖動，TCP 封包會延遲到達，為了避免「延遲到達的 TCP 封包」被誤認為是「新 TCP 連接配接」的資料，則，需要在允許新建立 TCP 連接配接之前，保持一個不可用的狀态，等待所有延遲封包的消失，一般設定為 2 倍的 MSL（封包的最大生存時間），解決「延遲達到的 TCP 封包」問題；