tcp通信數據流分析--tcpdump

Socket中TCP的建立（三次握手）

TCP協議通過三個報文段完成連接的建立，這個過程稱為三次握手(three-way handshake)，過程如下圖所示。

 

第一次握手：建立連接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；SYN：同步序列編號(Synchronize Sequence Numbers)。

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
一個完整的三次握手也就是： 請求---應答---再次確認。

對應的函數接口：
       

 

從圖中可以看出，當客戶端調用connect時，觸發了連接請求，向服務器發送了SYN J包，這時connect進入阻塞狀態；服務器監聽到連接請求，即收到SYN J包，調用accept函數接收請求向客戶端發送SYN K ，ACK J+1，這時accept進入阻塞狀態；客戶端收到服務器的SYN K ，ACK J+1之后，這時connect返回，並對SYN K進行確認；服務器收到ACK K+1時，accept返回，至此三次握手完畢，連接建立。

 

我們可以通過網絡抓包的查看具體的流程：

比如我們服務器開啟9502的端口。使用tcpdump來抓包：

 

 tcpdump -iany tcp port 9502

 

然后我們使用telnet 127.0.0.1 9502開連接.:

telnet 127.0.0.1 9502

 

14:12:45.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378, win 32792, options [mss 16396,sackOK,TS val 255474104 ecr 0,nop,wscale 3], length 0 （1）
14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379, win 32768, options [mss 16396,sackOK,TS val 255474104 ecr 255474104,nop,wscale 3], length 0   （2）
14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1, win 4099, options [nop,nop,TS val 255474104 ecr 255474104], length 0   （3）

14:13:01.415407 IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7
14:13:01.415432 IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0
14:13:01.415747 IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18
14:13:01.415757 IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0

 

• 114:12:45.104687 時間帶有精確到微妙
• localhost.39870 > localhost.9502 表示通信的流向，39870是客戶端，9502是服務器端
• [S] 表示這是一個SYN請求
• [S.] 表示這是一個SYN+ACK確認包: 
• [.] 表示這是一個ACT確認包， (client)SYN->(server)SYN->(client)ACT 就是3次握手過程
• [P] 表示這個是一個數據推送，可以是從服務器端向客戶端推送，也可以從客戶端向服務器端推
• [F] 表示這是一個FIN包，是關閉連接操作，client/server都有可能發起
• [R] 表示這是一個RST包，與F包作用相同，但RST表示連接關閉時，仍然有數據未被處理。可以理解為是強制切斷連接
• win 4099 是指滑動窗口大小
• length 18指數據包的大小

 

我們看到  （1）（2）（3）三步是建立tcp：

第一次握手：

14:12:45.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378

客戶端IP localhost.39870 (客戶端的端口一般是自動分配的) 向服務器localhost.9502 發送syn包(syn=j)到服務器》

syn包(syn=j) ： syn的seq= 2927179378  （j=2927179378）

 

第二次握手：

14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379,

收到請求並確認：服務器收到syn包，並必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包：
此時服務器主機自己的SYN：seq：y= syn seq 1721825043。
ACK為j+1 =（ack=j+1）=ack 2927179379 

第三次握手：

14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,

客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)

 

客戶端和服務器進入ESTABLISHED狀態后，可以進行通信數據交互。此時和accept接口沒有關系，即使沒有accepte，也進行3次握手完成。

連接出現連接不上的問題，一般是網路出現問題或者網卡超負荷或者是連接數已經滿啦。

 

紫色背景的部分：

IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7

客戶端向服務器發送長度為7個字節的數據，

 

IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0

服務器向客戶確認已經收到數據

 

 IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18

然后服務器同時向客戶端寫入數據。

 

 IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0

客戶端向服務器確認已經收到數據

 

這個就是tcp可靠的連接，每次通信都需要對方來確認。

 

 

6. TCP連接的終止（四次握手釋放）

建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉(half-close)造成的，如圖：

 

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

（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）。

對應函數接口如圖：

 

過程如下：

• 某個應用進程首先調用close主動關閉連接，這時TCP發送一個FIN M；
• 另一端接收到FIN M之后，執行被動關閉，對這個FIN進行確認。它的接收也作為文件結束符傳遞給應用進程，因為FIN的接收意味着應用進程在相應的連接上再也接收不到額外數據；
• 一段時間之后，接收到文件結束符的應用進程調用close關閉它的socket。這導致它的TCP也發送一個FIN N；
• 接收到這個FIN的源發送端TCP對它進行確認。

這樣每個方向上都有一個FIN和ACK。

1．為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。

 

2．為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？

這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。