還是老規矩把三次握手和四次揮手的狀態圖貼出來，多看幾遍就記住了。
可以用下面兩種方式控制服務器的TIME_WAIT數量：
- 修改tcp_max_tw_buckets：
- tcp_max_tw_buckets 控制併發的TIME_WAIT的數量，默認值是180000。如果超過默認值，內核會把多的TIME_WAIT連接清掉，然後在日誌裡打一個警告。官網文檔說這個選項只是為了阻止一些簡單的DoS攻擊，平常不要人為的降低它；
- 利用RST包從外部清掉TIME_WAIT鏈接：
- 根據TCP規範，收到任何的發送到未偵聽端口、已經關閉的連接的數據包、連接處於任何非同步狀態（LISTEN, SYS-SENT, SYN-RECEIVED）並且收到的包的ACK在窗口外，或者安全層不匹配，都要回執以RST響應(而收到滑動窗口外的序列號的數據包，都要 丟棄這個數據包， 並回復一個ACK包)，內核收到RST將會產生一個錯誤並終止該連接。我們可以利用RST包來終止掉處於TIME_WAIT狀態的連接，其實這就是所謂的RST攻擊了。
- 為了描述方便：假設Client和Server有個連接Connect1，Server主動關閉連接並進入了TIME_WAIT狀態，我們來描述一下怎麼從外部使得Server的處於 TIME_WAIT狀態的連接Connect1提前終止掉。要實現這個RST攻擊，首先我們要知道Client在Connect1中的端口port1(一般這個端口是隨機的，比較難猜到，這也是RST攻擊較難的一個點)，利用IP_TRANSPARENT這個socket選項，它可以bind不屬於本地的地址，因此可以從任意機器綁定Client地址以及端口port1，然後向Server發起一個連接，Server收到了窗口外的包於是響應一個ACK，這個ACK包會路由到Client處，這個時候99%的可能Client已經釋放連接connect1了，這個時候Client收到這個ACK包，會發送一個RST包，server收到RST包然後就釋放連接connect1提前終止TIME_WAIT狀態了。提前終止TIME_WAIT狀態是可能會帶來(問題二、)中說的三點危害，具體的危害情況可以看下RFC1337。RFC1337中建議，不要用RST過早的結束TIME_WAIT狀態。
至此，上面的疑症都解析完畢，然而細心的同學會有下面的疑問：
- 1）TCP的可靠傳輸是確認號來實現的，那麼TCP的確認機制是怎樣的呢？是收到一個包就馬上確認，還是可以稍等一下在確認呢？
- 2）假如發送一個包，一直都沒收到確認呢？什麼時候重傳呢？超時機制的怎樣的？
- 3）TCP兩端Peer的處理能力不對等的時候，比如發送方處理能力很強，接收方處理能力很弱，這樣發送方是否能夠不管接收方死活狂發數據呢？如果不能，流量控制機制的如何的？
- 4）TCP是端到端的協議，也就是TCP對端Peer只看到對方，看不到網絡上的其他點，那麼TCP的兩端怎麼對網絡情況做出反映呢？發生擁塞的時候，擁塞控制機制是如何的？
同學們，可以看我之前的文章，如果還有不懂，請留言之！我會採集大家的意見，下次講解，謝謝大家！
喜歡我的文章的話，就關注我吧！不要只收藏和轉發哦，每天至少兩篇編程知識給大家，都是本人多年的經驗總結！
分享到:
閱讀更多 cpp軟件架構獅 的文章
