摘要:包頭格式老規矩,咱們先來看看頭的格式。給的確認信息發出后,遇到網絡不好的情況,也會出現丟包的情況。這是因為包頭里的生存時間。它是任何報文再網絡上存在的最長時間,超過這個時間的報文就會被丟棄。協議規定為分鐘,實際應用中常用的是秒分鐘和分鐘等。
網絡協議 1 - 概述
網絡協議 2 - IP 是怎么來,又是怎么沒的?
網絡協議 3 - 從物理層到 MAC 層
網絡協議 4 - 交換機與 VLAN:辦公室太復雜,我要回學校
網絡協議 5 - ICMP 與 ping:投石問路的偵察兵
網絡協議 6 - 路由協議:敢問路在何方?
網絡協議 7 - UDP 協議:性善碰到城會玩
????上次說了“性本善”的 UDP 協議,這哥們秉承“網之初,性本善,不丟包,不亂序”的原則,徜徉在網絡世界中。
????與之相對應的,TCP 就像是老大哥一樣,了解了社會的殘酷,變得復雜而成熟,秉承“性惡論”。它認為網絡環境是惡劣的,丟包、亂序、重傳、擁塞都是常有的事兒,一言不合可能就會丟包,送達不了,所以從算法層面來保證可靠性。
TCP 包頭格式????老規矩,咱們先來看看 TCP 頭的格式。
????從上面這個圖可以看出,它比 UDP 要復雜的多。而復雜的地方,也正是它為了解決 UDP 存在的問題所必需的字段。
????首先,源端口號和目標端口號是兩者都有,不可缺少的字段。
????接下來是包的序號。給包編號就是為了解決亂序的問題。老大哥做事,穩重為主,一件件來,面臨再復雜的情況,也臨危不亂。
????除了發送端需要給包編號外,接收方也會回復確認序號。做事靠譜,答應了就要做到,暫時做不到也要給個回復。
????這里要注意的是,TCP 是個老大哥沒錯,但不能說他一定會保證傳輸準確無誤的完成。從 IP 層面來講,如果網絡的確那么差,是沒有任何可靠性保證的,即使 TCP 老大哥再穩,他也管不了 IP 層丟包,他只能盡可能的保證在他的層面上的可靠性。
然后是一些狀態位。有以下常見狀態位:
SYN(Synchronize Sequence Numbers,同步序列編號):發起一個連接
ACK(Acknowledgement,確認字符):回復
RST(Connection reset):重新連接
FIN:結束連接
????從這些狀態位就可以看出,TCP 基于“性惡論”,警覺性就很高,不像 UDP 和小朋友似的,隨便一個不認識的小朋友都能玩到一起,他與別人的信任要經過多次交互才能建立。
????還有一個窗口大小。這個是 TCP 用來進行流量控制的。通信雙方各聲明一個窗口,標識自己當前的處理能力,讓發送端別發送的太快,要不然撐死接收端。也不能發送的太慢,要不然就餓死接收端了。
根據上述對 TCP 頭的分析,我們知道對于 TCP 協議要重點關注以下幾個問題:
順序問題,穩重不亂;
丟包問題,承諾靠譜;
連接偉豪,有始有終;
流量控制,把握分寸;
擁塞控制,知進知退。
TCP 的三次握手????了解完 TCP 頭,我們就來看下 TCP 建立連接的過程,這就是著名的“三次握手”。
三次握手,過程是這樣子的:
A:你好,我是 A(SYN)。
B:你好 A,我是 B(SYN,ACK)。
A:你好 B(ACK 的 ACK)。
????著重記憶上述過程,后續很多分析都是基于這個過程來的。
????記得剛接觸三次握手的時候,就一直很納悶,為啥一定要三次?兩次不行嗎?四次不行嗎?然后很多人就解釋,如果是兩次,就怎樣怎樣,四次,又怎樣怎樣?但這其實都是從結果推原因,沒有說明本質。
????我們應該知道,握手是為了建立穩定的連接,這個是最終目的。而要達到這個目的,就要通信雙方的交互形成一個確認的閉環。
????拿上述 A、B 通信的例子來看,A 給 B 發信息,B 要告訴 A 他收到信息了。這時候,算是一個確認閉環嗎?明顯不是,因為 B 沒有收到來自 A 的確認信息。
????所以,要達到我們上述的目標,還要 A 給 B 一個確認信息,這樣就形成了一個確認閉環。
????A 給 B 的確認信息發出后,遇到網絡不好的情況,也會出現丟包的情況。按理來說,還應該有個回應,但是,我們發現,好像這樣下去就沒玩沒了啦。
????所以,我們說,只要通信雙方形成一個確認閉環后,就認為連接已建立。一旦連接建立,A 會馬上發送數據,而 A 發送數據,后續的很多問題都得到了解決。
????例如 A 發給 B 的確認消息丟了,當 A 后續發送的數據到達的時候,B 可以認為這個連接已經建立。如果 B 直接掛了,A 發送的數據就會報錯,說 B 不可達,這樣,A 也知道 B 出事情了。
????三次握手除了通信雙方建立連接外,主要還是為了溝通 TCP 包的序號問題。
????A 要告訴 B,我發起的包的序號起始是從哪個號開始的,B 也要告訴 A,B 發起的包的序號的起始號。
????TCP 包的序號是會隨時間變化的,可以看成一個 32 位的計數器,每 4ms 加一。計算一下,這樣到出現重復號,需要 4 個多小時。但是,4 個小時后,還沒到達目的地的包早就死翹翹了。這是因為 IP 包頭里的 TTL(生存時間)。
????為什么序號不能從 1 開始呢?因為這樣會很容易出現沖突。
????例如,A 連上 B 之后,發送了 1、2、3 三個包,但是發送 3 的時候,中間丟了,或者繞路了,于是重新發送,后來 A 掉線了,重新連上 B 后,序號又從 1 開始,然后發送 2,但是壓根沒想發送 3,而如果上次繞路的那個 3 剛好又回來了,發給了 B ,B 自然就認為,這就是下一包,于是發生了錯誤。
????就這樣,雙方歷經千辛萬苦,終于建立了連接。前面也說過,為了維護這個連接,雙方都要維護一個狀態機,在連接建立的過程中,雙方的狀態變化時序圖就像下面這樣:
整體過程是:
客戶端和服務端都處于 CLOSED 狀態;
服務端主動監聽某個端口,處于 LISTEN 狀態;
客戶端主動發起連接 SYN,處于 SYN-SENT 狀態。
服務端收到客戶端發起的連接,返回 SYN,并且 ACK 客戶端的 SYN,處于 SYN-RCVD 狀態;
客戶端收到服務端發送的 SYN 和 ACK 之后,發送 ACK 的 ACK,處于 ESTABLISHED 狀態;
服務端收到 ACK 的 ACK 之后,處于 ESTABLISHED 狀態。
TCP 的四次揮手????說完了連接,接下來就來了解下 TCP 的“再見模式”。這也常被稱為四次揮手。
還拿 A 和 B 舉例,揮手過程:
A:B 啊,我不想和你玩了。
B:哦,你不想玩了啊,我知道了。這個時候,還只是 A 不想玩了,就是說 A 不會再發送數據,但是 B 此時還沒做完自己的事情,還是可以發送數據的,所以此時的 B 處于半關閉狀態。
B:A啊,好吧,我也不想和你玩了,拜拜。
A:好的,拜拜。
????這樣這個連接就關閉了。看起來過程很順利,是的,這是通信雙方“和平分手”的場面。
????A 開始說“不玩了”,B 說“知道了”,這個回合,是沒什么問題的,因為在此之前,雙方還處于合作的狀態。
????如果 A 說“不玩了”,沒有收到回復,那么 A 會重新發送“不玩了”。但是這個回合結束之后,就很可能出現異常情況了,因為有一方率先撕破臉。這種撕破臉有兩種情況。
????一種情況是,A 說完“不玩了”之后,A 直接跑路,這是會有問題的,因為 B 還沒有發起結束,而如果 A 直接跑路,B 就算發起結束,也得不到回答,B 就就不知道該怎么辦了。
????另一種情況是,A 說完“不玩了”,B 直接跑路。這樣也是有問題的,因為 A 不知道 B 是還有事情要處理,還是過一會發送結束。
????為了解決這些問題,TCP 專門設計了幾個狀態來處理這些問題。接下來,我們就來看看斷開連接時的狀態時序圖。
整體過程是:
A 說“不玩了”,就進入 FIN_WAIT_1 狀態;
B 收到 “A 不玩”的消息后,回復“知道了”,就進入 CLOSE_WAIT 狀態;
A 收到“B 說知道了”,進入 FIN_WAIT_2 狀態。這時候,如果 B 直接跑路,則 A 將永遠在這個狀態。TCP 協議里面并沒有對這個狀態的處理,但是 Linux 有,可以調整 tcp_fin_timeout 這個參數,設置一個超時時間;
B 沒有跑路,發送了“B 也不玩了”的消息,處于 LAST_ACK 狀態;
A 收到“B 說不玩了”的消息,回復“A 知道 B 也不玩了”的消息后,從 FINE_WAIT_2 狀態結束。
????最后一個步驟里,如果 A 直接跑路了,也會出現問題。因為 A 的最后一個回復,B 如果沒有收到的話就會重復第 4 步,但是因為 A 已經跑路了,所以 B 會一直重復第 4 步。
????因此,TCP 協議要求 A 最后要等待一段時間,這個等待時間是 TIME_WAIT,這個時間要足夠長,長到如果 B 沒收到 A 的回復,B 重發給 A,A 的回復要有足夠時間到達 B。
????A 直接跑路還有一個問題是,A 的端口就空出來了,但是 B 不知道,B 原來發過的很多包可能還在路上,如果 A 的端口被新的應用占用了,這個新的應用會受到上個連接中 B 發過來的包,雖然序列號是重新生成的,但是這里會有一個雙保險,防止產生混亂。因此也需要 A 等待足夠長的時間,等到 B 發送的所有未到的包都“死翹翹”,再空出端口。
????這個等待的時間設為 2MSL,MSL 是 Maximum Segment Lifetime,即報文最大生存時間。它是任何報文再網絡上存在的最長時間,超過這個時間的報文就會被丟棄。
????因為 TCP 報文基于 IP 協議,而 IP 頭中有一個 TTL 域,是 IP 數據報可以經過的最大路有數,每經過一個處理他的路由器,此值就減 1,當此值為 0 時,數據報就被丟棄,同時發送 ICMP 報文通知源主機。協議規定 MSL 為 2 分鐘,實際應用中常用的是 30 秒、1分鐘和 2 分鐘等。
????還有一種異常情況,B 超過了 2MS 的時間,依然沒有收到它發的 FIN 的 ACK。按照 TCP 的原理,B 當然還會重發 FIN,這個時候 A 再收到這個包之后,就表示,我已經等你這么久,算是仁至義盡了,再來的數據包我就不認了,于是直接發送 RST,這樣 B 就知道 A 跑路了。
TCP 狀態機????將連接建立和連接斷開的兩個時序狀態圖綜合起來,就是著名的 TCP 狀態機。我們可以將這個狀態機和時序狀態機對照看,就會更加明了。
圖中加黑加粗部分,是上面說到的主要流程,相關說明:
阿拉伯數字序號:建立連接順序;
大寫中文數字序號:斷開連接順序;
加粗實線:客戶端 A 的狀態變遷;
加粗虛線:服務端 B 的狀態變遷;
總結TCP 包頭很復雜,主要關注 5 個問題。順序問題、丟包問題、連接維護、流量控制、擁塞控制;
建立連接三次握手,斷開連接四次揮手,狀態圖要牢記。
參考:
百度百科-TCP 詞條;
劉超-趣談網絡協議系列課;
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/29696.html
摘要:包頭格式老規矩,咱們先來看看頭的格式。給的確認信息發出后,遇到網絡不好的情況,也會出現丟包的情況。這是因為包頭里的生存時間。它是任何報文再網絡上存在的最長時間,超過這個時間的報文就會被丟棄。協議規定為分鐘,實際應用中常用的是秒分鐘和分鐘等。 網絡協議 1 - 概述 網絡協議 2 - IP 是怎么來,又是怎么沒的? 網絡協議 3 - 從物理層到 MAC 層 網絡協議 4 - 交換機與 ...
摘要:收到了,發送,要求下一個是,不幸又丟了。在對于包的確認中,會同時攜帶一個窗口大小的字段。前面的滑動窗口是怕發送方把接收方緩存塞滿,而擁塞窗口,是怕把網絡塞滿。這里有一個公式可以看出,是擁塞窗口和滑動窗口共同控制發送的速度。 網絡協議 1 - 概述 網絡協議 2 - IP 是怎么來,又是怎么沒的? 網絡協議 3 - 從物理層到 MAC 層 網絡協議 4 - 交換機與 VLAN:辦公室太...
摘要:收到了,發送,要求下一個是,不幸又丟了。在對于包的確認中,會同時攜帶一個窗口大小的字段。前面的滑動窗口是怕發送方把接收方緩存塞滿,而擁塞窗口,是怕把網絡塞滿。這里有一個公式可以看出,是擁塞窗口和滑動窗口共同控制發送的速度。 網絡協議 1 - 概述 網絡協議 2 - IP 是怎么來,又是怎么沒的? 網絡協議 3 - 從物理層到 MAC 層 網絡協議 4 - 交換機與 VLAN:辦公室太...
閱讀 2066·2021-09-22 15:54
閱讀 1830·2021-09-04 16:40
閱讀 854·2019-08-30 15:56
閱讀 2623·2019-08-30 15:44
閱讀 2150·2019-08-30 13:52
閱讀 1120·2019-08-29 16:35
閱讀 3340·2019-08-29 16:31
閱讀 2562·2019-08-29 13:48