6張動態圖輕鬆學習TCP三次握手和四次揮手

收藏

分享

技術沙龍 | 8月25日與多位資深技術大咖探討小程序電商實戰

6張動態圖輕鬆學習TCP三次握手和四次揮手

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

TCP 三次握手

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

6張動態圖輕鬆學習TCP三次握手和四次揮手

張三首先向李四招手(syn),李四看到張三向自己招手後,向對方點了點頭擠出了一個微笑(ack)。

張三看到李四微笑後確認了李四成功辨認出了自己(進入 estalished 狀態)。

但是李四還有點狐疑,向四周看了一看,有沒有可能張三是在看別人呢,他也需要確認一下。

所以李四也向張三招了招手(syn),張三看到李四向自己招手後知道對方是在尋求自己的確認。

於是也點了點頭擠出了微笑(ack),李四看到對方的微笑後確認了張三就是在向自己打招呼(進入 established 狀態)。

於是兩人加快步伐,走到了一起,相互擁抱。

6張動態圖輕鬆學習TCP三次握手和四次揮手

我們看到這個過程中一共是如下四個動作:

  • 張三招手
  • 李四點頭微笑
  • 李四招手
  • 張三點頭微笑

其中李四連續進行了 2 個動作,先是點頭微笑(回覆對方),然後再次招手(尋求確認),實際上可以將這兩個動作合一,招手的同時點頭和微笑(syn+ack)。

於是四個動作就簡化成了三個動作,張三招手→李四點頭微笑並招手→張三點頭微笑。這就是三次握手的本質,中間的一次動作是兩個動作的合併。

我們看到有兩個中間狀態,syn_sent 和 syn_rcvd,這兩個狀態叫做「半打開」狀態,就是向對方招手了,但是還沒來得及看到對方的點頭微笑。

syn_sent 是主動打開方的「半打開」狀態,syn_rcvd 是被動打開方的「半打開」狀態。客戶端是主動打開方,服務器是被動打開方。

  1. syn_sent:syn package has been sent
  2. syn_rcvd:syn package has been received

TCP 數據傳輸

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

6張動態圖輕鬆學習TCP三次握手和四次揮手

張三喊了一句話(data),李四聽見了之後要向張三回覆自己聽見了(ack)。

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

也有可能是李四聽到了張三的話,但是李四向張三的回覆被大風吹走了,以至於張三沒聽見李四的回覆。

張三並不能判斷究竟是自己的話被大風吹走了還是李四的回覆被大風吹走了,張三也不用管,重傳一下就是。

既然會重傳,李四就有可能同一句話聽見了兩次,這就是「去重」。「重傳」和「去重」工作在操作系統的網絡內核模塊都已經幫我們處理好了,用戶層是不用關心的。

6張動態圖輕鬆學習TCP三次握手和四次揮手

張三可以向李四喊話,同樣李四也可以向張三喊話,因為 TCP 鏈接是「雙工的」,雙方都可以主動發起數據傳輸。

不過無論是哪方喊話,都需要收到對方的確認才能認為對方收到了自己的喊話。

張三可能是個高射炮,一連說了八句話,這時候李四可以不用一句一句回覆,而是連續聽了這八句話之後,一起向對方回覆說前面你說的八句話我都聽見了,這就是批量 ACK。

但是張三也不能一次性說太多話,李四的腦子短時間可能無法消化太多,兩人之間需要有協商好的合適的發送和接受速率,這個就是「TCP 窗口大小」。

網絡環境的數據交互同人類之間的對話還要複雜一些,它存在數據包亂序的現象。

同一個來源發出來的不同數據包在「網際路由」上可能會走過不同的路徑,最終達到同一個地方時,順序就不一樣了。

操作系統的網絡內核模塊會負責對數據包進行排序,到用戶層時順序就已經完全一致了。

TCP 四次揮手

TCP 斷開鏈接的過程和建立鏈接的過程比較類似,只不過中間的兩步並不總是會合成一步走。

所以它分成了如下 4 個動作:

  • 張三揮手(fin)
  • 李四傷感地微笑(ack)
  • 李四揮手(fin)
  • 張三傷感地微笑(ack)
6張動態圖輕鬆學習TCP三次握手和四次揮手

之所以中間的兩個動作沒有合併,是因為 TCP 存在「半關閉」狀態,也就是單向關閉。

張三已經揮了手,可是人還沒有走,只是不再說話,但是耳朵還是可以繼續聽,李四呢繼續喊話。

等待李四累了,也不再說話了,朝張三揮了揮手,張三傷感地微笑了一下,才徹底結束了。

6張動態圖輕鬆學習TCP三次握手和四次揮手

上面有一個非常特殊的狀態 time_wait,它是主動關閉的一方在回覆完對方的揮手後進入的一個長期狀態。

這個狀態標準的持續時間是 4 分鐘,4 分鐘後才會進入到 Closed 狀態,釋放套接字資源。不過在具體實現上這個時間是可以調整的。

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

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

同時在這段時間內,該鏈接在對話期間於網際路由上產生的殘留報文(因為路徑過於崎嶇,數據報文走的時間太長,重傳的報文都收到了,原始報文還在路上)傳過來時,都會被立即丟棄掉。

4 分鐘的時間足以使得這些殘留報文徹底消逝。不然,當新的端口被重複利用時,這些殘留報文可能會干擾新的鏈接。

4 分鐘就是 2 個 MSL,每個 MSL 是 2 分鐘。MSL 就是 Maximum Segment Lifetime——最長報文壽命。

這個時間是由官方 RFC 協議規定的。至於為什麼是 2 個 MSL 而不是 1 個 MSL,我還沒有看到一個非常滿意的解釋。

四次揮手也並不總是四次揮手,中間的兩個動作有時候是可以合併一起進行的。

這個時候就成了三次揮手,主動關閉方就會從 fin_wait_1 狀態直接進入到 time_wait 狀態,跳過了 fin_wait_2 狀態。

總結

TCP 狀態轉換是一個非常複雜的過程,本文僅對一些簡單的基礎知識點進行了類比講解。

關於 TCP 的更多知識還需要讀者去搜尋相關技術文章進入深入學習。如果讀者對 TCP 的基礎知識掌握得比較牢固,高級的知識理解起來就不會太過於吃力。

錢文品(老錢),互聯網分佈式高併發技術十年老兵,目前任掌閱服務端技術專家。熟練使用 Java、Python、Golang 等多種計算機語言,開發過遊戲,製作過網站,寫過消息推送系統和 MySQL 中間件,實現過開源的 ORM 框架、Web 框架、RPC 框架等。運營個人公眾號碼洞(ID:codehole)。


分享到:


相關文章: