漫畫:一招學會TCP的三次握手和四次揮手

codeGoogle發表於2019-04-19

TCP三次握手和四次揮手的問題在面試中是最為常見的考點之一。很多讀者都知道三次和四次,但是如果問深入一點,他們往往都無法作出準確回答。

本篇嘗試使用動畫來對這個知識點進行講解,期望讀者們可以更加簡單地地理解TCP互動的本質。

image

TCP/IP代表傳輸控制協議/網際協議,指的是一系列協組。

可分為四個層次

  • 1、資料鏈路層、網路層、傳輸層和應用層。

  • 2、 在網路層:有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。

  • 3、在傳輸層:中有TCP協議與UDP協議。

  • 4、在應用層:有FTP、HTTP、TELNET、SMTP、DNS等協議。

TCP和UDP使用IP協議從一個網路傳送資料包到另一個網路。把IP想像成一種高速公路,它允許其它協議在上面行駛並找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”,它們攜帶的貨物就是像HTTP,檔案傳輸協議FTP這樣的協議等。

TCP和UDP是FTP,HTTP和SMTP之類使用的傳輸層協議。雖然TCP和UDP都是用來傳輸其他協議的,它們卻有一個顯著的不同:TCP提供有保證的資料傳輸,而UDP不提供。這意味著TCP有一個特殊的機制來確保資料安全的不出錯的從一個端點傳到另一個端點,而UDP不提供任何這樣的保證。

TCP 三次握手

TCP 三次握手就好比兩個人在街上隔著50米看見了對方,但是因為霧霾等原因不能100%確認,所以要通過招手的方式相互確定對方是否認識自己。

image
640

相互擁抱

image

我們看到這個過程中一共是四個動作,招手–點頭微笑–招手–點頭微笑。其中連續進行了2個動作,先是點頭微笑(回覆對方),然後再次招手(尋求確認),實際上可以將這兩個動作合一,招手的同時點頭和微笑(syn+ack)。於是四個動作就簡化成了三個動作,招手–點頭微笑並招手–點頭微笑。這就是三次握手的本質,中間的一次動作是兩個動作的合併。

我們看到有兩個中間狀態,syn_sent和syn_rcvd,這兩個狀態叫著「半開啟」狀態,就是向對方招手了,但是還沒來得及看到對方的點頭微笑。syn_sent是主動開啟方的「半開啟」狀態,syn_rcvd是被動開啟方的「半開啟」狀態。客戶端是主動開啟方,伺服器是被動開啟方。

  • syn_sent: syn package has been sent

  • syn_rcvd: syn package has been received

TCP 資料傳輸

TCP 資料傳輸就是兩個人隔空對話,差了一點距離,所以需要對方反覆確認聽見了自己的話。

image
6402

客戶端喊了一句話(data),接收方聽見了之後要回復自己聽見了(ack)。

如果喊了一句,半天沒聽到對方回覆,就認為自己的話被大風吹走了,沒聽見,所以需要重新喊話,這就是tcp重傳。

也有可能是服務端聽到了客戶端的話,但是Server向Client的回覆被大風吹走了,以至於Client沒聽見Server的回覆。Client並不能判斷究竟是自己的話被大風吹走了還是Server的回覆被大風吹走了,Client也不用管,重傳一下就是。

image
6403

Client可以向Server喊話,同樣Server也可以向Client喊話,因為tcp連結是「雙工的」,雙方都可以主動發起資料傳輸。不過無論是哪方喊話,都需要收到對方的確認才能認為對方收到了自己的喊話。

Client可能是個高射炮,一說連說了八句話,這時候Server可以不用一句一句回覆,而是連續聽了這八句話之後,一起向對方回覆說前面你說的八句話我都聽見了,這就是批量ack。但是Client也不能一次性說了太多話,Server的腦子短時間可能無法消化太多,兩人之間需要有協商好的合適的傳送和接受速率,這個就是「TCP視窗大小」。

TCP三次連線總結

(1**) 第一次握手:**建立連線時,客戶端A傳送SYN包(SYN=j)到伺服器B,並進入SYN_SEND狀態,等待伺服器B確認。

**(2) 第二次握手:**伺服器B收到SYN包,必須確認客戶A的SYN(ACK=j+1),同時自己也傳送一個SYN包(SYN=k),即SYN+ACK包,此時伺服器B進入SYN_RECV狀態。

**(3) 第三次握手:**客戶端A收到伺服器B的SYN+ACK包,向伺服器B傳送確認包ACK(ACK=k+1),此包傳送完畢,客戶端A和伺服器B進入ESTABLISHED狀態,完成三次握手。

image

完成三次握手,客戶端與伺服器開始傳送資料。

TCP 四次揮手

TCP斷開連結的過程和建立連結的過程比較類似,只不過中間的兩部並不總是會合成一步走,所以它分成了4個動作,Client揮手(fin)——Server傷感地微笑(ack)——Server揮手(fin)——Client傷感地微笑(ack)。

image

之所以中間的兩個動作沒有合併,是因為tcp存在「半關閉」狀態,也就是單向關閉。Client已經揮了手,可是人還沒有走,只是不再說話,但是耳朵還是可以繼續聽,Server呢繼續喊話。等待Server累了,也不再說話了,超Client揮了揮手,Client傷感地微笑了一下,才徹底結束了。

image
6405

上面有一個非常特殊的狀態time_wait,它是主動關閉的一方在回覆完對方的揮手後進入的一個長期狀態,這個狀態標準的持續時間是4分鐘,4分鐘後才會進入到closed狀態,釋放套接字資源。不過在具體實現上這個時間是可以調整的。

它就好比主動分手方要承擔的責任,是你提出的要分手,你得付出代價。這個後果就是持續4分鐘的time_wait狀態,不能釋放套接字資源(埠),就好比守寡期,這段時間內套接字資源(埠)不得回收利用。

它的作用是重傳最後一個ack報文,確保對方可以收到。因為如果對方沒有收到ack的話,會重傳fin報文,處於time_wait狀態的套接字會立即向對方重發ack報文。

同時在這段時間內,該連結在對話期間於網際路由上產生的殘留報文(因為路徑過於崎嶇,資料包文走的時間太長,重傳的報文都收到了,原始報文還在路上)傳過來時,都會被立即丟棄掉。4分鐘的時間足以使得這些殘留報文徹底消逝。不然當新的埠被重複利用時,這些殘留報文可能會干擾新的連結。

4分鐘就是2個MSL,每個MSL是2分鐘。MSL就是maximium segment lifetime——最長報文壽命。這個時間是由官方RFC協議規定的。至於為什麼是2個MSL而不是1個MSL,我還沒有看到一個非常滿意的解釋。

四次揮手也並不總是四次揮手,中間的兩個動作有時候是可以合併一起進行的,這個時候就成了三次揮手,主動關閉方就會從fin_wait_1狀態直接進入到time_wait狀態,跳過了fin_wait_2狀態。

TCP四次分手總結

由於TCP連線是全雙工的,因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動,一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。

image

  1. **客戶端A傳送一個FIN,**用來關閉客戶A到伺服器B的資料傳送(報文段4)。

  2. 伺服器B收到這個FIN,它發回一個ACK,確認序號為收到的序號加1(報文段5)。和SYN一樣,一個FIN將佔用一個序號。

  3. 伺服器B關閉與客戶端A的連線,傳送一個FIN給客戶端A(報文段6)。

  4. 客戶端A發回ACK報文確認,並將確認序號設定為收到序號加1(報文段7)。

總結

TCP狀態轉換是一個非常複雜的過程,本文僅對一些簡單的基礎知識點進行了類比講解。關於TCP的更多知識還需要讀者去搜尋相關技術文章進入深入學習。如果讀者對TCP的基礎知識掌握得比較牢固,高階的知識理解起來就不會太過於吃力。

補充

最近作為面試管在面試的時候,發現很多人框架很強,java基礎的時候就有些薄弱了,很多童鞋們對於HTTP、TCP、UDP以及SOCKET的概念不是很清楚,傻傻的分不清楚,這裡我們也簡單的提一下

HTTP本身就是一個協議,是從Web伺服器傳輸超文字到本地瀏覽器的傳送協議。

HTTP(超文字傳輸協議)是利用TCP在兩臺電腦(通常是Web伺服器和客戶端)之間傳輸資訊的協議。客戶端使用Web瀏覽器發起HTTP請求給Web伺服器,Web伺服器傳送被請求的資訊給客戶端。

HTTP協議是建立在請求/響應模型上的。首先由客戶建立一條與伺服器的TCP連結,併傳送一個請求到伺服器,請求中包含請求方法、URL、協議版本以及相關的MIME樣式的訊息。伺服器響應一個狀態行,包含訊息的協議版本、一個成功和失敗碼以及相關的MIME式樣的訊息。

HTTP/1.0為每一次HTTP的請求/響應建立一條新的TCP連結,因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP連結。一次TCP連結的建立將需要3次握手。

另外,為了獲得適當的傳輸速度,則需要TCP花費額外的迴路連結時間(RTT)。每一次連結的建立需要這種經常性的開銷,而其並不帶有實際有用的資料,只是保證連結的可靠性,因此HTTP/1.1提出了可持續連結的實現方法。HTTP/1.1將只建立一次TCP的連結而重複地使用它傳輸一系列的請求/響應訊息,

因此減少了連結建立的次數和經常性的連結開銷。

雖然HTTP本身是一個協議,但其最終還是基於TCP的。

SOCKET:TCP/IP網路的API。

Socket是應用層與TCP/IP協議族通訊的中間軟體抽象層,它是一組介面。在設計模式中,Socket其實就是一個門面模式,它把複雜的TCP/IP協議族隱藏在Socket介面後面,對使用者來說,一組簡單的介面就是全部,讓Socket去組織資料,以符合指定的協議。

Socket 介面是TCP/IP網路的API,Socket介面定義了許多函式或例程,用以開發TCP/IP網路上的應用程式。

這是為了實現以上的通訊過程而建立成來的通訊管道,其真實的代表是客戶端和伺服器端的一個通訊程式,雙方程式通過socket進行通訊,而通訊的規則採用指定的協議。socket只是一種連線模式,不是協議,tcp,udp,簡單的說(雖然不準確)是兩個最基本的協議,很多其它協議都是基於這兩個協議如,http就是基於tcp的,用socket可以建立tcp連線,也可以建立udp連線**,這意味著,用socket可以建立任何協議的連線,因為其它協議都是基於此的。

image

**綜上所述:**需要IP協議來連線網路;TCP是一種允許我們安全傳輸資料的機制,使用TCP協議來傳輸資料的HTTP是Web伺服器和客戶端使用的特殊協議。HTTP基於TCP協議,但是卻可以使用socket去建立一個TCP連線。

更多參考

Android外掛包換膚(高仿網易雲音樂換膚)

Android中Application是單例,正確嗎?

Android App瘦身新姿勢——Android App Bundle

關於Java中的不可變性

最後如果對技術比較感興趣,歡迎關注我的微信公眾號:終端研發部,id:codeGooger,一起進階技術

相關文章