自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

TCP 才不傻!聰明的很!

網(wǎng)絡(luò) 無線技術(shù)
我們在學 TCP 連接建立和斷開的時候,總是以為這些過程能如期完成??上Ю硐牒茇S滿,現(xiàn)實很骨感,事實預(yù)料呀。TCP 當然不傻,對以上這些異常場景都是有做處理的。

大家好,我是小林。

之前收到個讀者的問題,對于 TCP 三次握手和四次揮手的一些疑問:

  • 第一次握手,如果客戶端發(fā)送的SYN一直都傳不到被服務(wù)器,那么客戶端是一直重發(fā)SYN到永久嗎?客戶端停止重發(fā)SYN的時機是什么?
  • 第三次握手,如果服務(wù)器永遠不會收到ACK,服務(wù)器就永遠都留在 Syn-Recv 狀態(tài)了嗎?退出此狀態(tài)的時機是什么?
  • 第三次揮手,如果客戶端永遠收不到 FIN,ACK,客戶端永遠停留在 Fin-Wait-2狀態(tài)了嗎?退出此狀態(tài)時機是什么時候呢?
  • 第四次揮手,如果服務(wù)器永遠收不到 ACK,服務(wù)器永遠停留在 Last-Ack 狀態(tài)了嗎?退出此狀態(tài)的時機是什么呢?
  • 如果客戶端 在 2SML內(nèi)依舊沒收到 FIN,ACK,會關(guān)閉鏈接嗎?服務(wù)器那邊怎么辦呢,是怎么關(guān)閉鏈接的呢?

可以看到,這些問題都是關(guān)于 TCP 是如何處理這些異常場景的,我們在學 TCP 連接建立和斷開的時候,總是以為這些過程能如期完成。

可惜理想很豐滿,現(xiàn)實很骨感,事實預(yù)料呀。

TCP 當然不傻,對以上這些異常場景都是有做處理的。

這些內(nèi)容在我的「圖解網(wǎng)絡(luò) PDF」 也有說過。

當時也用做實驗的方式帶大家看 TCP 是如何處理這些異常場景的。

不過,當時這些知識分散到了多個章節(jié),這次就針對讀者問的這一系列問題,來詳細說說 TCP 是怎么處理這些異常的?

這些異常場景共分為兩大類,第一類是 TCP 三次握手期間的異常,第二類是 TCP 四次揮手期間的異常。

TCP 三次握手期間的異常

我們先來看看 TCP 三次握手是怎樣的。

第一次握手丟失了,會發(fā)生什么?

當客戶端想和服務(wù)端建立 TCP 連接的時候,首先第一個發(fā)的就是 SYN 報文,然后進入到 SYN_SENT 狀態(tài)。

在這之后,如果客戶端遲遲收不到服務(wù)端的 SYN-ACK 報文(第二次握手),就會觸發(fā)超時重傳機制。

不同版本的操作系統(tǒng)可能超時時間不同,有的 1 秒的,也有 3 秒的,這個超時時間是寫死在內(nèi)核里的,如果想要更改則需要重新編譯內(nèi)核,比較麻煩。

當客戶端在 1 秒后沒收到服務(wù)端的 SYN-ACK 報文后,客戶端就會重發(fā) SYN 報文,那到底重發(fā)幾次呢?

在 Linux 里,客戶端的 SYN 報文最大重傳次數(shù)由 tcp_syn_retries內(nèi)核參數(shù)控制,這個參數(shù)是可以自定義的,默認值一般是 5。

通常,第一次超時重傳是在 1 秒后,第二次超時重傳是在 2 秒,第三次超時重傳是在 4 秒后,第四次超時重傳是在 8 秒后,第五次是在超時重傳 16 秒后。沒錯,每次超時的時間是上一次的 2 倍。

當?shù)谖宕纬瑫r重傳后,會繼續(xù)等待 32 秒,如果服務(wù)端仍然沒有回應(yīng) ACK,客戶端就不再發(fā)送 SYN 包,然后斷開 TCP 連接。

所以,總耗時是 1+2+4+8+16+32=63 秒,大約 1 分鐘左右。

第二次握手丟失了,會發(fā)生什么?

當服務(wù)端收到客戶端的第一次握手后,就會回 SYN-ACK 報文給客戶端,這個就是第二次握手,此時服務(wù)端會進入 SYN_RCVD 狀態(tài)。

第二次握手的 SYN-ACK 報文其實有兩個目的 :

  • 第二次握手里的 ACK, 是對第一次握手的確認報文;
  • 第二次握手里的 SYN,是服務(wù)端發(fā)起建立 TCP 連接的報文;

所以,如果第二次握手丟了,就會發(fā)送比較有意思的事情,具體會怎么樣呢?

因為第二次握手報文里是包含對客戶端的第一次握手的 ACK 確認報文,所以,如果客戶端遲遲沒有收到第二次握手,那么客戶端就覺得可能自己的 SYN 報文(第一次握手)丟失了,于是客戶端就會觸發(fā)超時重傳機制,重傳 SYN 報文。

然后,因為第二次握手中包含服務(wù)端的 SYN 報文,所以當客戶端收到后,需要給服務(wù)端發(fā)送 ACK 確認報文(第三次握手),服務(wù)端才會認為該 SYN 報文被客戶端收到了。

那么,如果第二次握手丟失了,服務(wù)端就收不到第三次握手,于是服務(wù)端這邊會觸發(fā)超時重傳機制,重傳 SYN-ACK 報文。

在 Linux 下,SYN-ACK 報文的最大重傳次數(shù)由 tcp_synack_retries內(nèi)核參數(shù)決定,默認值是 5。

因此,當?shù)诙挝帐謥G失了,客戶端和服務(wù)端都會重傳:

  • 客戶端會重傳 SYN 報文,也就是第一次握手,最大重傳次數(shù)由 tcp_syn_retries內(nèi)核參數(shù)決定。;
  • 服務(wù)端會重傳 SYN-AKC 報文,也就是第二次握手,最大重傳次數(shù)由 tcp_synack_retries 內(nèi)核參數(shù)決定。

第三次握手丟失了,會發(fā)生什么?

客戶端收到服務(wù)端的 SYN-ACK 報文后,就會給服務(wù)端回一個 ACK 報文,也就是第三次握手,此時客戶端狀態(tài)進入到 ESTABLISH 狀態(tài)。

因為這個第三次握手的 ACK 是對第二次握手的 SYN 的確認報文,所以當?shù)谌挝帐謥G失了,如果服務(wù)端那一方遲遲收不到這個確認報文,就會觸發(fā)超時重傳機制,重傳 SYN-ACK 報文,直到收到第三次握手,或者達到最大重傳次數(shù)。

注意,ACK 報文是不會有重傳的,當 ACK 丟失了,就由對方重傳對應(yīng)的報文。

TCP 四次揮手期間的異常

我們再來看看 TCP 四次揮手的過程。

第一次揮手丟失了,會發(fā)生什么?

當客戶端(主動關(guān)閉方)調(diào)用 close 函數(shù)后,就會向服務(wù)端發(fā)送 FIN 報文,試圖與服務(wù)端斷開連接,此時客戶端的連接進入到 FIN_WAIT_1 狀態(tài)。

正常情況下,如果能及時收到服務(wù)端(被動關(guān)閉方)的 ACK,則會很快變?yōu)?FIN_WAIT2 狀態(tài)。

如果第一次揮手丟失了,那么客戶端遲遲收不到被動方的 ACK 的話,也就會觸發(fā)超時重傳機制,重傳 FIN 報文,重發(fā)次數(shù)由 tcp_orphan_retries 參數(shù)控制。

當客戶端重傳 FIN 報文的次數(shù)超過 tcp_orphan_retries 后,就不再發(fā)送 FIN 報文,直接進入到 close 狀態(tài)。

第二次揮手丟失了,會發(fā)生什么?

當服務(wù)端收到客戶端的第一次揮手后,就會先回一個 ACK 確認報文,此時服務(wù)端的連接進入到 CLOSE_WAIT 狀態(tài)。

在前面我們也提了,ACK 報文是不會重傳的,所以如果服務(wù)端的第二次揮手丟失了,客戶端就會觸發(fā)超時重傳機制,重傳 FIN 報文,直到收到服務(wù)端的第二次揮手,或者達到最大的重傳次數(shù)。

這里提一下,當客戶端收到第二次揮手,也就是收到服務(wù)端發(fā)送的 ACK 報文后,客戶端就會處于 FIN_WAIT2 狀態(tài),在這個狀態(tài)需要等服務(wù)端發(fā)送第三次揮手,也就是服務(wù)端的 FIN 報文。

對于 close 函數(shù)關(guān)閉的連接,由于無法再發(fā)送和接收數(shù)據(jù),所以FIN_WAIT2 狀態(tài)不可以持續(xù)太久,而 tcp_fin_timeout 控制了這個狀態(tài)下連接的持續(xù)時長,默認值是 60 秒。

這意味著對于調(diào)用 close 關(guān)閉的連接,如果在 60 秒后還沒有收到 FIN 報文,客戶端(主動關(guān)閉方)的連接就會直接關(guān)閉。

第三次揮手丟失了,會發(fā)生什么?

當服務(wù)端(被動關(guān)閉方)收到客戶端(主動關(guān)閉方)的 FIN 報文后,內(nèi)核會自動回復(fù) ACK,同時連接處于 CLOSE_WAIT 狀態(tài),顧名思義,它表示等待應(yīng)用進程調(diào)用 close 函數(shù)關(guān)閉連接。

此時,內(nèi)核是沒有權(quán)利替代進程關(guān)閉連接,必須由進程主動調(diào)用 close 函數(shù)來觸發(fā)服務(wù)端發(fā)送 FIN 報文。

服務(wù)端處于 CLOSE_WAIT 狀態(tài)時,調(diào)用了 close 函數(shù),內(nèi)核就會發(fā)出 FIN 報文,同時連接進入 LAST_ACK 狀態(tài),等待客戶端返回 ACK 來確認連接關(guān)閉。

如果遲遲收不到這個 ACK,服務(wù)端就會重發(fā) FIN 報文,重發(fā)次數(shù)仍然由 tcp_orphan_retries 參數(shù)控制,這與客戶端重發(fā) FIN 報文的重傳次數(shù)控制方式是一樣的。

第四次揮手丟失了,會發(fā)生什么?

當客戶端收到服務(wù)端的第三次揮手的 FIN 報文后,就會回 ACK 報文,也就是第四次揮手,此時客戶端連接進入 TIME_WAIT 狀態(tài)。

在 Linux 系統(tǒng),TIME_WAIT 狀態(tài)會持續(xù) 60 秒后才會進入關(guān)閉狀態(tài)。

然后,服務(wù)端(被動關(guān)閉方)沒有收到 ACK 報文前,還是處于 LAST_ACK 狀態(tài)。

如果第四次揮手的 ACK 報文沒有到達服務(wù)端,服務(wù)端就會重發(fā) FIN 報文,重發(fā)次數(shù)仍然由前面介紹過的 tcp_orphan_retries 參數(shù)控制。

是吧,TCP 聰明的很!

責任編輯:趙寧寧 來源: 小林coding
相關(guān)推薦

2013-06-07 10:13:51

JavaIDEIntellij ID

2016-02-29 11:54:11

手機屏幕尺寸iPone5se

2020-12-14 14:19:21

數(shù)據(jù)科學機器學習

2013-03-27 10:43:18

2018-08-26 15:26:34

機器學習統(tǒng)計學深度學習

2020-04-20 13:43:59

黑客聯(lián)網(wǎng)攻擊

2014-04-01 10:04:59

Dropbox

2020-07-23 10:00:50

AI 數(shù)據(jù)人工智能

2024-09-30 14:34:22

2017-12-28 15:20:50

2021-01-22 11:35:19

物聯(lián)網(wǎng)人工智能編程

2011-09-13 08:55:59

在這兒IM在這兒職業(yè)

2009-06-25 18:13:10

2022-02-17 07:54:55

VSCodeLinux內(nèi)核

2009-09-23 09:32:42

程序員被解雇

2014-06-05 09:23:47

程序員高效

2013-07-09 13:38:19

字符轉(zhuǎn)義

2011-04-25 13:44:03

iPad2蘋果聰明蓋兒

2011-04-25 13:56:09

iPad2聰明蓋兒

2012-11-08 00:46:00

AMD服務(wù)器芯片
點贊
收藏

51CTO技術(shù)棧公眾號