這也能考慮到?TCP 有點牛
大家好,我是小林。
我在網(wǎng)站看到一位老哥問了個問題。
簡單點說,為什么在 TCP 三次握手過程中,如果客戶端收到的 SYN-ACK 報文的確認號不符合預(yù)期的話,為什么是回 RST,而不是丟棄呢?
我說回 RST 就回 RST 嗎?
當(dāng)然不是,我也是看 RFC 標(biāo)準(zhǔn)確認過。
我來先描述下這個場景吧:
- 客戶端向服務(wù)端發(fā)送 SYN 報文(seq=100),但是網(wǎng)絡(luò)中有個不速之客,一個歷史的 SYN 報文(seq=90)先抵達服務(wù)端;
- 服務(wù)端收到歷史的 SYN 報文,就會對此 SYN 報文做了確認,回了 SYN-ACK 報文,確認號為 90+1;
- 客戶端收到 SYN-ACK 報文后,誒發(fā)現(xiàn)不對勁,他明明發(fā)的是 SYN 報文(seq=100),按道理 SYN-ACK 報文中的確認號是 100+1,可現(xiàn)在收到的確認號為 90+1 的 SYN-ACK 報文,所以禮貌地回了 RST 給服務(wù)端;
- 服務(wù)端收到 RST 報文后,服務(wù)端就斷開處于 SYN_RECEVIED 狀態(tài)的連接;
- 最后正常的 SYN 報文(seq=100)終于抵達了服務(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ā)超時重傳,直到達到最大的重傳次數(shù)才會進入 CLOSE 狀態(tài),這個過程需要持續(xù) 10-20 秒。
從客戶端的角度看,就是遲遲與服務(wù)端建立不來連接,因為服務(wù)端這邊已經(jīng)存在一個相同四元組的舊連接,如果不把服務(wù)端這個連接干掉,那么是無法確認客戶端新的連接(SEQ=100),因為非 LISTEN 狀態(tài)下,如果收到 SYN,都是回 challenge ack,這個 ack 并不是對收到 SYN 報做確認,而是繼續(xù)回復(fù)上一次已發(fā)送 ACK。
是不是有種服務(wù)端的舊連接(SEQ=90)占著茅坑不拉屎的感覺?
所以啊,干掉服務(wù)端的舊連接的工作,就交給了客戶端來做了。
當(dāng)處于 SYN_SENT 狀態(tài)連接的客戶端,在收到不符合期望的 SYN-ACK 報文時,就直接 RST 給服務(wù)端,干掉服務(wù)端的舊連接,這樣客戶端的新連接才能快速建立。
怎么樣,TCP 處處是細節(jié)啊!