我在網站看到一位老哥問了個問題。
我說回 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 的博大精深
審核編輯 :李倩
-
TCP
+關注
關注
8文章
1353瀏覽量
79055 -
RFC
+關注
關注
0文章
16瀏覽量
10101 -
服務端
+關注
關注
0文章
66瀏覽量
7004
原文標題:這也能考慮到?TCP 有點牛逼
文章出處:【微信號:小林coding,微信公眾號:小林coding】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論