我在網站看到一位老哥問了個問題。

簡單點說，為什么在 TCP 三次握手過程中，如果客戶端收到的 SYN-ACK 報文的確認號不符合預期的話，為什么是回 RST，而不是丟棄呢？

我說回 RST 就回 RST 嗎？

當然不是，我也是看 RFC 標準確認過。

我來先描述下這個場景吧：

• 客戶端向服務端發送 SYN 報文（seq=100），但是網絡中有個不速之客，一個歷史的 SYN 報文（seq=90）先抵達服務端；
• 服務端收到歷史的 SYN 報文，就會對此 SYN 報文做了確認，回了 SYN-ACK 報文，確認號為 90+1；
• 客戶端收到 SYN-ACK 報文后，誒發現不對勁，他明明發的是 SYN 報文（seq=100），按道理 SYN-ACK 報文中的確認號是 100+1，可現在收到的確認號為 90+1 的 SYN-ACK 報文，所以禮貌地回了 RST 給服務端；
• 服務端收到 RST 報文后，服務端就斷開處于 SYN_RECEVIED 狀態的連接；
• 最后正常的 SYN 報文（seq=100）終于抵達了服務端，經過三次握手后，雙方的 TCP 連接都建立完成。

上面這個過程，就是 TCP 三次握手防止歷史連接建立的過程，之所以 TCP 需要三次握手，首要原因是為了防止舊的重復連接初始化造成混亂，其次原因是可靠的同步雙方的序列號。

那為什么要設計成，當客戶端收到不符合期望的 SYN-ACK 報文，是回 RST，而不是丟棄呢？

現在我們來假設是丟棄處理，看看會發生什么？

可以看到，當處于 SYN_SENT 狀態連接的客戶端收到不符合期望的 SYN-ACK 報文時，如果選擇的處理是「丟棄」，那么雙方都會觸發超時重傳，直到達到最大的重傳次數才會進入 CLOSE 狀態，這個過程需要持續 10-20 秒。

從客戶端的角度看，就是遲遲與服務端建立不來連接，因為服務端這邊已經存在一個相同四元組的舊連接，如果不把服務端這個連接干掉，那么是無法確認客戶端新的連接（SEQ=100），因為非 LISTEN 狀態下，如果收到 SYN，都是回 challenge ack，這個 ack 并不是對收到 SYN 報做確認，而是繼續回復上一次已發送 ACK。

是不是有種服務端的舊連接（SEQ=90）占著茅坑不拉屎的感覺？

所以啊，干掉服務端的舊連接的工作，就交給了客戶端來做了。

當處于 SYN_SENT 狀態連接的客戶端，在收到不符合期望的 SYN-ACK 報文時，就直接 RST 給服務端，干掉服務端的舊連接，這樣客戶端的新連接才能快速建立。

怎么樣，TCP 處處是細節啊！

再次感受到了 TCP 的博大精深

審核編輯 ：李倩