辰东,完美世界txt下载

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

TCP三次握手，四次揮手，你真的懂嗎？

記得剛畢業(yè)找工作面試的時候，經(jīng)常會被問到：你知道“三次握手，四次揮手”嗎?

成都創(chuàng)新互聯(lián)長期為成百上千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為古塔企業(yè)提供專業(yè)的網(wǎng)站制作、成都網(wǎng)站制作，古塔網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

本文來自于作者投稿，公眾號：碼農(nóng)桃花源

這時候我會“胸有成竹”地“背誦”前期準備好的“答案”，第一次怎么怎么，第二次……答完后就沒有下文了，面試官貌似也沒有深入下去的意思，深入下去我也不懂，皆大歡喜!

作為程序員，要有“刨根問底”的精神，知其然，更要知其所以然。這篇文章希望能抽絲剝繭，還原背后的原理。

什么是“三次握手，四次揮手”

TCP 是一種面向連接的單播協(xié)議，在發(fā)送數(shù)據(jù)前，通信雙方必須在彼此間建立一條連接。

所謂的“連接”，其實是客戶端和服務(wù)器的內(nèi)存里保存的一份關(guān)于對方的信息，如 IP 地址、端口號等。

TCP 可以看成是一種字節(jié)流，它會處理 IP 層或以下的層的丟包、重復以及錯誤問題。

在連接的建立過程中，雙方需要交換一些連接的參數(shù)。這些參數(shù)可以放在 TCP 頭部。

TCP 提供了一種可靠、面向連接、字節(jié)流、傳輸層的服務(wù)，采用三次握手建立一個連接。采用四次揮手來關(guān)閉一個連接。

TCP 服務(wù)模型

在了解了建立連接、關(guān)閉連接的“三次握手和四次揮手”后，我們再來看下 TCP 相關(guān)的東西。

一個 TCP 連接由一個 4 元組構(gòu)成，分別是兩個 IP 地址和兩個端口號。一個 TCP 連接通常分為三個階段：啟動、數(shù)據(jù)傳輸、退出(關(guān)閉)。

當 TCP 接收到另一端的數(shù)據(jù)時，它會發(fā)送一個確認，但這個確認不會立即發(fā)送，一般會延遲一會兒。

ACK 是累積的，一個確認字節(jié)號 N 的 ACK 表示所有直到 N 的字節(jié)(不包括 N)已經(jīng)成功被接收了。

這樣的好處是如果一個 ACK 丟失，很可能后續(xù)的 ACK 就足以確認前面的報文段了。

一個完整的 TCP 連接是雙向和對稱的，數(shù)據(jù)可以在兩個方向上平等地流動，給上層應用程序提供一種雙工服務(wù)。

一旦建立了一個連接，這個連接的一個方向上的每個 TCP 報文段都包含了相反方向上的報文段的一個 ACK。

序列號的作用是使得一個 TCP 接收端可丟棄重復的報文段，記錄以雜亂次序到達的報文段。

因為 TCP 使用 IP 來傳輸報文段，而 IP 不提供重復消除或者保證次序正確的功能。

另一方面，TCP 是一個字節(jié)流協(xié)議，絕不會以雜亂的次序給上層程序發(fā)送數(shù)據(jù)。

因此 TCP 接收端會被迫先保持大序列號的數(shù)據(jù)不交給應用程序，直到缺失的小序列號的報文段被填滿。

TCP 頭部

源端口和目的端口在 TCP 層確定雙方進程，序列號表示的是報文段數(shù)據(jù)中的第一個字節(jié)號，ACK 表示確認號。

該確認號的發(fā)送方期待接收的下一個序列號，即最后被成功接收的數(shù)據(jù)字節(jié)序列號加 1，這個字段只有在 ACK 位被啟用的時候才有效。

當新建一個連接時，從客戶端發(fā)送到服務(wù)端的第一個報文段的 SYN 位被啟用，這稱為 SYN 報文段。

這時序列號字段包含了在本次連接的這個方向上要使用的第一個序列號，即初始序列號 ISN，之后發(fā)送的數(shù)據(jù)是 ISN 加 1。

因此 SYN 位字段會消耗一個序列號。這意味著使用重傳進行可靠傳輸，而不消耗序列號的 ACK 則不是。

頭部長度(圖中的數(shù)據(jù)偏移)以 32 位字為單位，也就是以 4bytes 為單位，它只有 4 位，最大為 15，因此頭部最大長度為 60 字節(jié)，而其最小為 5，也就是頭部最小為 20 字節(jié)(可變選項為空)。

ACK —— 確認，使得確認號有效。
RST —— 重置連接(經(jīng)?？吹降?reset by peer)就是此字段搞的鬼。
SYN —— 用于初如化一個連接的序列號。
FIN —— 該報文段的發(fā)送方已經(jīng)結(jié)束向?qū)Ψ桨l(fā)送數(shù)據(jù)。

當一個連接被建立或被終止時，交換的報文段只包含 TCP 頭部，而沒有數(shù)據(jù)。

狀態(tài)轉(zhuǎn)換

三次握手和四次揮手的狀態(tài)轉(zhuǎn)換如下圖：

為什么要“三次握手，四次揮手”

三次握手

換個易于理解的視角來看為什么要三次握手。

客戶端和服務(wù)端通信前要進行連接，“三次握手”的作用就是雙方都能明確自己和對方的收、發(fā)能力是正常的。

第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。

第二次握手：服務(wù)端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。

從客戶端的視角來看，我接到了服務(wù)端發(fā)送過來的響應數(shù)據(jù)包，說明服務(wù)端接收到了我在第一次握手時發(fā)送的網(wǎng)絡(luò)包，并且成功發(fā)送了響應數(shù)據(jù)包，這就說明，服務(wù)端的接收、發(fā)送能力正常。

而另一方面，我收到了服務(wù)端的響應數(shù)據(jù)包，說明我第一次發(fā)送的網(wǎng)絡(luò)包成功到達服務(wù)端，這樣，我自己的發(fā)送和接收能力也是正常的。

第三次握手：客戶端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力，服務(wù)端的發(fā)送、接收能力是正常的。

第一、二次握手后，服務(wù)端并不知道客戶端的接收能力以及自己的發(fā)送能力是否正常。

而在第三次握手時，服務(wù)端收到了客戶端對第二次握手作的回應。從服務(wù)端的角度，我在第二次握手時的響應數(shù)據(jù)發(fā)送出去了，客戶端接收到了。所以，我的發(fā)送能力是正常的。而客戶端的接收能力也是正常的。

經(jīng)歷了上面的三次握手過程，客戶端和服務(wù)端都確認了自己的接收、發(fā)送能力是正常的。之后就可以正常通信了。

每次都是接收到數(shù)據(jù)包的一方可以得到一些結(jié)論，發(fā)送的一方其實沒有任何頭緒。

我雖然有發(fā)包的動作，但是我怎么知道我有沒有發(fā)出去，而對方有沒有接收到呢?

而從上面的過程可以看到，最少是需要三次握手過程的。兩次達不到讓雙方都得出自己、對方的接收、發(fā)送能力都正常的結(jié)論。

其實每次收到網(wǎng)絡(luò)包的一方至少是可以得到：對方的發(fā)送、我方的接收是正常的。

而每一步都是有關(guān)聯(lián)的，下一次的“響應”是由于第一次的“請求”觸發(fā)，因此每次握手其實是可以得到額外的結(jié)論的。

比如第三次握手時，服務(wù)端收到數(shù)據(jù)包，表明看服務(wù)端只能得到客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。

但是結(jié)合第二次，說明服務(wù)端在第二次發(fā)送的響應包，客戶端接收到了，并且作出了響應，從而得到額外的結(jié)論：客戶端的接收、服務(wù)端的發(fā)送是正常的。

用表格總結(jié)一下：

四次揮手

TCP 連接是雙向傳輸?shù)膶Φ鹊哪Ｊ剑褪钦f雙方都可以同時向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)。

當有一方要關(guān)閉連接時，會發(fā)送指令告知對方，我要關(guān)閉連接了。這時對方會回一個 ACK，此時一個方向的連接關(guān)閉。

但是另一個方向仍然可以繼續(xù)傳輸數(shù)據(jù)，等到發(fā)送完了所有的數(shù)據(jù)后，會發(fā)送一個 FIN 段來關(guān)閉此方向上的連接。接收方發(fā)送 ACK 確認關(guān)閉連接。

注意，接收到 FIN 報文的一方只能回復一個 ACK, 它是無法馬上返回對方一個 FIN 報文段的，因為結(jié)束數(shù)據(jù)傳輸?shù)摹爸噶睢笔巧蠈討脤咏o出的，我只是一個“搬運工”，我無法了解“上層的意志”。

“三次握手，四次揮手”怎么完成?

其實三次握手的目的并不只是讓通信雙方都了解到一個連接正在建立，還在于利用數(shù)據(jù)包的選項來傳輸特殊的信息，交換初始序列號 ISN。

三次握手是指發(fā)送了 3 個報文段，四次揮手是指發(fā)送了 4 個報文段。注意，SYN 和 FIN 段都是會利用重傳進行可靠傳輸?shù)摹?/p>

三次握手原理：

客戶端發(fā)送一個 SYN 段，并指明客戶端的初始序列號，即 ISN(c)。
服務(wù)端發(fā)送自己的 SYN 段作為應答，同樣指明自己的 ISN(s)。為了確認客戶端的 SYN，將 ISN(c)+1 作為 ACK 數(shù)值。這樣，每發(fā)送一個 SYN，序列號就會加 1，如果有丟失的情況，則會重傳。
為了確認服務(wù)器端的 SYN，客戶端將 ISN(s)+1 作為返回的 ACK 數(shù)值。

四次揮手原理：

客戶端發(fā)送一個 FIN 段，并包含一個希望接收者看到的自己當前的序列號 K。同時還包含一個 ACK 表示確認對方最近一次發(fā)過來的數(shù)據(jù)。
服務(wù)端將 K 值加 1 作為 ACK 序號值，表明收到了上一個包。這時上層的應用程序會被告知另一端發(fā)起了關(guān)閉操作，通常這將引起應用程序發(fā)起自己的關(guān)閉操作。
服務(wù)端發(fā)起自己的 FIN 段，ACK=K+1, Seq=L。
客戶端確認。ACK=L+1

為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢?這是因為服務(wù)端在 LISTEN 狀態(tài)下，收到建立連接請求的 SYN 報文后，把 ACK 和 SYN 放在一個報文里發(fā)送給客戶端。

而關(guān)閉連接時，當收到對方的 FIN 報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方是否現(xiàn)在關(guān)閉發(fā)送數(shù)據(jù)通道，需要上層應用來決定，因此，己方 ACK 和 FIN 一般都會分開發(fā)送。

“三次握手，四次揮手”進階

ISN

三次握手的一個重要功能是客戶端和服務(wù)端交換 ISN(Initial Sequence Number), 以便讓對方知道接下來接收數(shù)據(jù)的時候如何按序列號組裝數(shù)據(jù)。

如果 ISN 是固定的，攻擊者很容易猜出后續(xù)的確認號：

 
 
 
 
  
  
  
  ISN = M + F(localhost, localport, remotehost, remoteport)

M 是一個計時器，每隔 4 毫秒加 1。F 是一個 Hash 算法，根據(jù)源 IP、目的 IP、源端口、目的端口生成一個隨機數(shù)值。要保證 Hash 算法不能被外部輕易推算得出。

序列號回繞

因為 ISN 是隨機的，所以序列號容易就會超過 2^31-1。而 TCP 對于丟包和亂序等問題的判斷都是依賴于序列號大小比較的。

此時就出現(xiàn)了所謂的 TCP 序列號回繞(sequence wraparound)問題怎么解決?

 
 
 
 
  
  
  
  /*   
  
  
  * The next routines deal with comparing 32 bit unsigned ints   
  
  
  * and worry about wraparound (automatic with unsigned arithmetic).   
  
  
  */   
  
  
  static inline int before(__u32 seq1, __u32 seq2)   
  
  
  {   
  
  
      return (__s32)(seq1-seq2) < 0;   
  
  
  }   
  
  
     
  
  
  #define after(seq2, seq1) before(seq1, seq2)

上述代碼是內(nèi)核中的解決回繞問題代碼。__s32 是有符號整型的意思，而 __u32 則是無符號整型。

序列號發(fā)生回繞后，序列號變小，相減之后，把結(jié)果變成有符號數(shù)了，因此結(jié)果成了負數(shù)。

 
 
 
 
  
  
  
  假設(shè)seq1=255， seq2=1（發(fā)生了回繞）。   
  
  
  seq1 = 1111 1111 seq2 = 0000 0001   
  
  
  我們希望比較結(jié)果是   
  
  
  seq1 - seq2=   
  
  
  1111 1111   
  
  
  -0000 0001   
  
  
  -----------   
  
  
  1111 1110   
  
  
     
  
  
  由于我們將結(jié)果轉(zhuǎn)化成了有符號數(shù)，由于最高位是1，因此結(jié)果是一個負數(shù)，負數(shù)的絕對值為   
  
  
  0000 0001 + 1 = 0000 0010 = 2   
  
  
     
  
  
  因此seq1 - seq2 < 0

SYN Flood 攻擊

最基本的 DoS 攻擊就是利用合理的服務(wù)請求來占用過多的服務(wù)資源，從而使合法用戶無法得到服務(wù)的響應。SYN Flood 屬于 Dos 攻擊的一種。

如果惡意的向某個服務(wù)器端口發(fā)送大量的 SYN 包，則可以使服務(wù)器打開大量的半開連接，分配 TCB(Transmission Control Block), 從而消耗大量的服務(wù)器資源，同時也使得正常的連接請求無法被響應。

當開放了一個 TCP 端口后，該端口就處于 Listening 狀態(tài)，不停地監(jiān)視發(fā)到該端口的 SYN 報文，一旦接收到 Client 發(fā)來的 SYN 報文，就需要為該請求分配一個 TCB。

通常一個 TCB 至少需要 280 個字節(jié)，在某些操作系統(tǒng)中 TCB 甚至需要 1300 個字節(jié)，并返回一個 SYN ACK 命令，立即轉(zhuǎn)為 SYN-RECEIVED 即半開連接狀態(tài)，系統(tǒng)會為此耗盡資源。常見的防攻擊方法有：

①無效連接的監(jiān)視釋放

監(jiān)視系統(tǒng)的半開連接和不活動連接，當達到一定閾值時拆除這些連接，從而釋放系統(tǒng)資源。

這種方法對于所有的連接一視同仁，而且由于 SYN Flood 造成的半開連接數(shù)量很大，正常連接請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬于入門級的 SYN Flood 方法。

②延緩 TCB 分配方法

消耗服務(wù)器資源主要是因為當 SYN 數(shù)據(jù)報文一到達，系統(tǒng)立即分配 TCB，從而占用了資源。

而 SYN Flood 由于很難建立起正常連接，因此，當正常連接建立起來后再分配 TCB 則可以有效地減輕服務(wù)器資源的消耗。常見的方法是使用 Syn Cache 和 Syn Cookie 技術(shù)。

③Syn Cache 技術(shù)

系統(tǒng)在收到一個 SYN 報文時，在一個專用 Hash 表中保存這種半連接信息，直到收到正確的回應 ACK 報文再分配 TCB。這個開銷遠小于 TCB 的開銷。當然還需要保存序列號。

④Syn Cookie 技術(shù)

Syn Cookie 技術(shù)則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成 Sequence Number。

這種算法考慮到了對方的 IP、端口、己方 IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息。

如 MSS(Maximum Segment Size，最大報文段大小，指的是 TCP 報文的最大數(shù)據(jù)報長度，其中不包括 TCP 首部長度。)、時間等。

在收到對方的 ACK 報文后，重新計算一遍，看其是否與對方回應報文中的(Sequence Number-1)相同，從而決定是否分配 TCB 資源。

⑤使用 SYN Proxy 防火墻

一種方式是防止墻 dqywb 連接的有效性后，防火墻才會向內(nèi)部服務(wù)器發(fā)起 SYN 請求。

防火墻代服務(wù)器發(fā)出的 SYN ACK 包使用的序列號為 c, 而真正的服務(wù)器回應的序列號為 c',。

這樣，在每個數(shù)據(jù)報文經(jīng)過防火墻的時候進行序列號的修改。另一種方式是防火墻確定了連接的安全后，會發(fā)出一個 safe reset 命令，Client 會進行重新連接，這時出現(xiàn)的 SYN 報文會直接放行。

這樣不需要修改序列號了。但是，Client 需要發(fā)起兩次握手過程，因此建立連接的時間將會延長。

連接隊列

在外部請求到達時，被服務(wù)程序最終感知到前，連接可能處于 SYN_RCVD 狀態(tài)或是 ESTABLISHED 狀態(tài)，但還未被應用程序接受。

對應地，服務(wù)器端也會維護兩種隊列，處于 SYN_RCVD 狀態(tài)的半連接隊列，而處于 ESTABLISHED 狀態(tài)但仍未被應用程序 Accept 的為全連接隊列。

如果這兩個隊列滿了之后，就會出現(xiàn)各種丟包的情形：

 
 
 
 
  
  
  
  查看是否有連接溢出   
  
  
  netstat -s | grep LISTEN

半連接隊列滿了

在三次握手協(xié)議中，服務(wù)器維護一個半連接隊列，該隊列為每個客戶端的 SYN 包開設(shè)一個條目(服務(wù)端在接收到 SYN 包的時候，就已經(jīng)創(chuàng)建了request_sock結(jié)構(gòu)，存儲在半連接隊列中)。

該條目表明服務(wù)器已收到 SYN 包，并向客戶發(fā)出確認，正在等待客戶的確認包。

這些條目所標識的連接在服務(wù)器處于 Syn_RECV 狀態(tài)，當服務(wù)器收到客戶的確認包時，刪除該條目，服務(wù)器進入 ESTABLISHED 狀態(tài)。

目前，Linux 下默認會進行 5 次重發(fā) SYN-ACK 包，重試的間隔時間從 1s 開始，下次的重試間隔時間是前一次的雙倍，5 次的重試時間間隔為 1s, 2s, 4s, 8s, 16s, 總共 31s，稱為指數(shù)退避。

第 5 次發(fā)出后還要等 32s 才知道第 5 次也超時了，所以，總共需要 1s + 2s + 4s + 8s + 16s + 32s = 63s，TCP 才會斷開這個連接。

由于，SYN 超時需要 63 秒，那么就給攻擊者一個攻擊服務(wù)器的機會，攻擊者在短時間內(nèi)發(fā)送大量的 SYN 包給 Server(俗稱 SYN Flood 攻擊)，用于耗盡 Server 的 SYN 隊列。

對于應對 SYN 過多的問題，Linux 提供了幾個 TCP 參數(shù)來調(diào)整應對：

tcp_syncookies
tcp_synack_retries
tcp_max_syn_backlog
tcp_abort_on_overflow

全連接隊列滿了

當?shù)谌挝帐謺r，當 Server 接收到 ACK 包之后，會進入一個新的叫 Accept 的隊列。

當 Accept 隊列滿了之后，即使 Client 繼續(xù)向 Server 發(fā)送 ACK 的包，也會不被響應。

此時 ListenOverflows+1，同時 Server 通過 tcp_abort_on_overflow 來決定如何返回，0 表示直接丟棄該 ACK，1 表示發(fā)送 RST 通知 Client。

相應的，Client 則會分別返回 read timeout 或者 connection reset by peer。

另外，tcp_abort_on_overflow 是 0 的話，Server 過一段時間再次發(fā)送 SYN+ACK 給 Client(也就是重新走握手的第二步)，如果 Client 超時等待比較短，就很容易異常了。

而客戶端收到多個 SYN ACK 包，則會認為之前的 ACK 丟包了。于是促使客戶端再次發(fā)送 ACK ，在 Accept 隊列有空閑的時候最終完成連接。

若 Accept 隊列始終滿員，則最終客戶端收到 RST 包(此時服務(wù)端發(fā)送 SYN+ACK 的次數(shù)超出了 tcp_synack_retries)。

服務(wù)端僅僅只是創(chuàng)建一個定時器，以固定間隔重傳 SYN 和 ACK 到服務(wù)端：

命令

 
 
 
 
  
  
  
  [root@server ~]#  netstat -s | egrep "listen|LISTEN"   
  
  
  667399 times the listen queue of a socket overflowed   
  
  
  667399 SYNs to LISTEN sockets ignored

上面看到的 667399 times ，表示全連接隊列溢出的次數(shù)，隔幾秒鐘執(zhí)行下，如果這個數(shù)字一直在增加的話肯定全連接隊列偶爾滿了。

查看 Accept queue 是否有溢出：

 
 
 
 
  
  
  
  [root@server ~]#  netstat -s | grep TCPBacklogDrop

ss 命令：

 
 
 
 
  
  
  
  [root@server ~]#  ss -lnt   
  
  
  State Recv-Q Send-Q Local Address:Port Peer Address:Port   
  
  
  LISTEN     0      128 *:6379 *:*   
  
  
  LISTEN     0      128 *:22 *:*

如果 State 是 Listen 狀態(tài)，Send-Q 表示第三列的 Listen 端口上的全連接隊列最大為 50，第一列 Recv-Q 為全連接隊列當前使用了多少。

非 LISTEN 狀態(tài)中 Recv-Q 表示 receive queue 中的 bytes 數(shù)量;Send-Q 表示 send queue 中的 bytes 數(shù)值。

小結(jié)：當外部連接請求到來時，TCP 模塊會首先查看 max_syn_backlog，如果處于 SYN_RCVD 狀態(tài)的連接數(shù)目超過這一閾值，進入的連接會被拒絕。

根據(jù) tcp_abort_on_overflow 字段來決定是直接丟棄，還是直接 reset。

從服務(wù)端來說，三次握手中，第一步 Server 接受到 Client 的 SYN 后，把相關(guān)信息放到半連接隊列中，同時回復 SYN+ACK 給 Client。第三步當收到客戶端的 ACK，將連接加入到全連接隊列。

一般，全連接隊列比較小，會先滿，此時半連接隊列還沒滿。如果這時收到 SYN 報文，則會進入半連接隊列，沒有問題。

但是如果收到了三次握手中的第 3 步(ACK)，則會根據(jù) tcp_abort_on_overflow 字段來決定是直接丟棄，還是直接 reset。

此時，客戶端發(fā)送了 ACK, 那么客戶端認為三次握手完成，它認為服務(wù)端已經(jīng)準備好了接收數(shù)據(jù)的準備。

但此時服務(wù)端可能因為全連接隊列滿了而無法將連接放入，會重新發(fā)送第 2 步的 SYN+ACK，如果這時有數(shù)據(jù)到來，服務(wù)器 TCP 模塊會將數(shù)據(jù)存入隊列中。

一段時間后，Client 端沒收到回復，超時，連接異常，Client 會主動關(guān)閉連接。

“三次握手，四次揮手”Redis 實例分析

①我在 dev 機器上部署 Redis 服務(wù)，端口號為 6379，通過 tcpdump 工具獲取數(shù)據(jù)包，使用如下命令：

 
 
 
 
  
  
  
  tcpdump -w /tmp/a.cap port 6379 -s0   
  
  
  -w把數(shù)據(jù)寫入文件，-s0設(shè)置每個數(shù)據(jù)包的大小默認為68字節(jié)，如果用-S0則會抓到完整數(shù)據(jù)包

②在 dev2 機器上用 redis-cli 訪問 dev：6379, 發(fā)送一個 ping, 得到回復 pong，停止抓包，用 tcpdump 讀取捕獲到的數(shù)據(jù)包：

 
 
 
 
  
  
  
  tcpdump -r /tmp/a.cap -n -nn -A -x| vim -   
  
  
  （-x 以16進制形式展示，便于后面分析）

共收到了 7 個包。

抓到的是 IP 數(shù)據(jù)包，IP 數(shù)據(jù)包分為 IP 頭部和 IP 數(shù)據(jù)部分，IP 數(shù)據(jù)部分是 TCP 頭部加 TCP 數(shù)據(jù)部分。

IP 的數(shù)據(jù)格式為：

它由固定長度 20B+ 可變長度構(gòu)成。

對著 IP 頭部格式，來拆解數(shù)據(jù)包的具體含義。

剩余的數(shù)據(jù)部分即為 TCP 協(xié)議相關(guān)的。TCP 也是 20B 固定長度+可變長度部分。

可變長度部分，協(xié)議如下：

這樣第一個包分析完了。dev2 向 dev 發(fā)送 SYN 請求。也就是三次握手中的第一次了。

 
 
 
 
  
  
  
  SYN seq(c)=4133153791

第二個包，dev 響應連接，ack=4133153792。表明 dev 下次準備接收這個序號的包，用于 tcp 字節(jié)注的順序控制。dev(也就是 server 端)的初始序號為 seq=4264776963, syn=1。

 
 
 
 
  
  
  
  SYN ack=seq(c)+1 seq(s)=4264776963

第三個包，client 包確認，這里使用了相對值應答。seq=4133153792，等于第二個包的 ack. ack=4264776964。

 
 
 
 
  
  
  
  ack=seq(s)+1, seq=seq(c)+1

至此，三次握手完成。接下來就是發(fā)送 ping 和 pong 的數(shù)據(jù)了。

接著第四個包：

tcp 首部長度為 32B，可選長度為 12B。IP 報文的總長度為 66B，首部長度為 20B，因此 TCP 數(shù)據(jù)部分長度為 14B. seq=0xf65a ec00=4133153792。

ACK, PSH. 數(shù)據(jù)部分為 2a31 0d0a 2434 0d0a 7069 6e67 0d0a：

 
 
 
 
  
  
  
  0x2a31         -> *1   
  
  
  0x0d0a         -> \r\n   
  
  
  0x2434         -> $4   
  
  
  0x0d0a         -> \r\n   
  
  
  0x7069 0x6e67  -> ping   
  
  
  0x0d0a         -> \r\n

dev2 向 dev 發(fā)送了 ping 數(shù)據(jù)，第四個包完畢。第五個包，dev2 向 dev 發(fā)送 ack 響應。

序列號為 0xfe33 5504=4264776964，ack 確認號為 0xf65a ec0e=4133153806=(4133153792+14)。

第六個包，dev 向 dev2 響應 pong 消息。序列號 fe33 5504，確認號 f65a ec0e，TCP 頭部可選長度為 12B，IP 數(shù)據(jù)報總長度為 59B，首部長度為 20B，因此 TCP 數(shù)據(jù)長度為 7B。

數(shù)據(jù)部分 2b50 4f4e 470d 0a，翻譯過來就是+PONG\r\n。至此，Redis 客戶端和 Server 端的三次握手過程分析完畢。

總結(jié)

“三次握手，四次揮手”看似簡單，但是深究進去，還是可以延伸出很多知識點的，比如半連接隊列、全連接隊列等等。

以前關(guān)于 TCP 建立連接、關(guān)閉連接的過程很容易就會忘記，可能是因為只是死記硬背了幾個過程，沒有深入研究背后的原理。所以，“三次握手，四次揮手”你真的懂了嗎?

本文標題：TCP三次握手，四次揮手，你真的懂嗎？
分享網(wǎng)址：http://www.fisionsoft.com.cn/article/djoghij.html

新聞中心

其他資訊