我在網(wǎng)站看到一位老哥問了個問題。

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

我說回 RST 就回 RST 嗎？

當(dāng)然不是，我也是看 RFC 標(biāo)準(zhǔn)確認(rèn)過。

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

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

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

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

現(xiàn)在我們來假設(shè)是丟棄處理，看看會發(fā)生什么？

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

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

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

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

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

怎么樣，TCP 處處是細(xì)節(jié)啊！

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

審核編輯 ：李倩