工作中無論是開發環境還是線上環境，我們都出現過大量的 timewait 狀態的連接，例如下面這個例子

服務端簡單的開闢一個 web server 監聽 9966 端口

客户端進行瘋狂的請求服務端

瞬間就可以看到咱們服務端的出現大量的 TIME_WAIT 狀態的連接

這個時候，如果客户端再不停的請求服務端的話，我們就可以看到會出現這樣的一個錯誤 address already in use : connect

這個時候是表示咱們已經沒有可以使用的端口， 地址都在被使用中

那我們來看一下為什麼會出現上述這種情況，以及我們如何去解決他呢？

為什麼會出現這麼多的 TIME_WAIT 狀態

上面其實咱們也看到了，出現大量 TIME_WAIT 狀態，一般是出現在高併發場景，同時有多個請求進來， 如果基本都是短連接，那麼服務端處理完畢請求之後就會關閉連接，那麼服務端就會出現大量的 TIME_WAIT 狀態的連接，需要等待 2 MSL 的報文最大存活時間，才會被系統釋放回收，回收哦，又空餘出連接數，來進行服務

簡單的咱們可以使用如下命令來查看我們的 TIME_WAIT 狀態的連接數

netstat -antp|grep TIME_WAIT |wc -l 

上述這種情況，在併發的時候，我們的某些請求可能沒有辦法得到處理，這是為什麼呢？

有一點網絡基本知識的我們知道，咱們的 TCP 結構是這樣的：

對於目的端口和源端口，在 tcp 包頭上都是佔用 16 bit ，那麼就是分別 65535 個端口，此處客户端請求服務端，那麼源端口最多也就是 65535 個連接

而當我們請求服務端時，報錯地址正在被使用，咱們就需要等待最大 2MSL 的時間，才能正常連接服務端了

我們如何處理 TIME_WAIT 大量存在的情況

我們如何處理 TIME_WAIT 大量存在的情況呢？前提是我們先知道這個 TIME_WAIT 是產生在哪一邊的，一般情況下多數是發生在服務端

對於 TCP 的三次握手和四次揮手就不在此處做詳細闡述了，對於基本 TCP 原理中，客户端和服務端，哪一端先發起關閉連接，那麼 TIME_WAIT 就會出現在哪一端，例如下面這個簡圖：

那麼，我們可以知道上述例子，TIME_WAIT 是出現在服務端的，這是為什麼呢？

因此客户端的請求連接頭部中 connection 設置的一般是 close 字段，此時服務端的處理是一個短連接，服務端處理完畢之後，就會主動關閉連接

TIME_WAIT 含義是，我這邊主動關閉連接， 我不會主動發送信息給你了，但是你發送的信息，我是可以正常接收的

其實咱們一般是可以這樣來解決上述大量 TIME_WAIT 存在的情況的：

咱們簡單思考一下，解決這個問題，要麼是不產生這麼多 TIME_WAIT 狀態的連接，要麼就是這個 TIME_WAIT 狀態的連接能夠更快的被釋放掉，好空出閒置的端口來進行使用

對於這個思路的第一點：

客户端請求服務端的時候，頭部的 connection 設置為 keep-alive，和服務端保持長連接的特性，保持存活一段時間

那麼，對於思路的第二點：

那麼是長連接，也是會有斷開的時候，那麼，如果是服務端這邊主動斷開的話，仍然會在服務端上出現 TIME_WAIT，我們是否可以考慮能夠將這個TIME_WAIT 的時間縮短一點，就是去對 2MSL 做文章了

這個時間，可以根據咱們自身的設計來調整成 例如 1MSL 也是可以的，這並不完全是死的

注意哦：一般 1 個 MSL 是 120 秒，也就是 2 分鐘

今天就是這樣，下一次分享一波為什麼需要 TIME_WAIT 狀態

感謝閲讀，歡迎交流，點個贊，關注一波 再走吧

歡迎點贊，關注，收藏

朋友們，你的支持和鼓勵，是我堅持分享，提高質量的動力

好了，本次就到這裏

技術是開放的，我們的心態，更應是開放的。擁抱變化，向陽而生，努力向前行。

我是阿兵雲原生，歡迎點贊關注收藏，下次見~