這也能考慮到？TCP 有點牛逼

大家好，我是小林。

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

簡單點說，為什麼在 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 的博大精深