前言
介紹
本篇文章是使用wireshrak對某個https請求的tcp包進行分析。
目的
通過抓包實際分析了解tcp包。
准備工作
在我自己機子上安裝的是wireshark2.2.6版本，隨機查找了某個TCP連接，並跟蹤流。
傳輸
創建連接
- No58: 10.60.45.187:17932(后面簡稱客戶端)向131.25.61.68:443(后面簡稱服務端)發送了
SYN請求連接，此時客戶端發送的seq=0，ack=0。 - No79：服務端向客戶端發送了
SYN+ACK確認連接，此時服務端發送的seq=0,ack=1。 - No81：客戶端接收到服務端的
SYN+ACK向服務端響應ACK包，此時客戶端發送的seq=1，ack=1。
由於抓到的tcp是使用了https協議，建里連接需要先進行認證,步驟如下圖所示。
握手
- No84: 客戶端向服務端發起握手請求，具體包格式及內容這里不做詳細分析。
這里SSL總長度為239字節(其中
ContentType為1字節，Version為2字節,Length為2字節，再加上后續握手協議長度234。)。
-
No103: 服務端接收到客戶端握手請求后響應
ACK包，此時seq=1,ack=1。這個發送的是一個特殊的TCP Window Update,服務端告知客戶端服務端有足夠的緩存大小(8192)，可以正常接收客戶端數據。若出現了TCP Window Full包表示緩存區已滿，客戶端會停止發送，直到接收到了TCP Window Update包。(Window值表示滑動窗口[1]，允許接收到多個包同時響應一個ACK包) -
No104: 服務器向客戶端發送握手，由於服務端需要返回證書、算法等信息,因此包可能會大於1460字節，會發生拆包現象(No136可看到該包總大小為5984KB,拆分了5個包發送)。當前服務端發送的seq=1,ack=240(當前包大小為1460，No84說明客戶端包大小為239。)
-
No105: 服務器向客戶端發送握手數據，這個包標記的是
TCP Previous segment not captured，說明發送包可能出現了亂序或丟包現象，這個包的seq=2921，而No104的下一個包seq應該為1461，No104和No105中間seq=1461的包可能丟包或亂序傳輸。
-
No106: 服務器向客戶端發送握手數據，這個包的seq=4381，因為No105的下一個包的seq和這個包一樣，所以這兩個包是按順序傳輸的。當前包的下一個包seq=5841。
-
No108: 這個包是客戶端向服務端發送的一個
ACK其中ack=1461，表示客戶端確認收到了No104這個包。
-
No118: 服務器向客戶端發送
ACK包，這個包標記的是TCP Out-Of-Order，由於No105包顯示出現了丟包現象，因此tcp將No104以前的包全部重傳，這個包實際就是No104。
-
No119: 客戶端向服務端發送
ACK包，這個包標記的是TCP Dup ACK 108#1,表示重傳ACK包，這個包是由於No118包引起的(#N表示重傳N次，這里重傳了1次)，因為No118包服務端向客戶端發送了一個亂序的包，而客戶端在No108包已經確認接收到No104這個包，seq應該為1461，所以，客戶端再一次重傳108包告知服務端客戶端已經接收到No104包，這個包實際服務端已經接收到了因此會被丟棄。 -
No123和No124: 服務器向客戶端發送握手數據，包標記的是
TCP Retransmission,兩個包的seq分別為1461和2921，由於服務端認為已經發了這兩個包(實際seq=1461的包沒發，由No105可看出，seq=2921的包發了，但是客戶端沒有響應響應的ACK包)，然后長時間收不到客戶端的ACK包，因此服務端會重發這兩個包。
-
No127: 客戶端向服務端發送
ACK包。seq=240，ack=5841，表示已經接收到服務端seq=5841以前的所有包。 -
No132: 服務器向客戶端發送握手數據，包標記的是
TCP Spurious Retransmission，表示這個包已經發送過。該報的seq=1461,即No123重傳的包，雖然客戶端向服務端發送了ACK包收到了seq=5841以前的包，但是服務端可能沒有收到這個ACK包。
-
No133: 客戶端向服務端發送
ACK包。seq=240，ack=5841。包標記的是TCP Dup ACK 127#1。由於客戶端在No127已經返回了ack=5841，但是服務端在No132還是重傳了之前已經傳過的包，所以客戶端認為No127包可能服務端沒有收到，所有這里重傳了No127這個ACK包，這個包服務端已經接收到了，因此會被丟棄。 -
No136: 服務端向客戶端發送的最后一個握手包。seq=5841。下個包seq=5985，在這包匯總了5個分段包內容和信息。
-
No140:客戶端向服務端發送
ACK包。seq=240，ack=5985。
生成密鑰
- No141: 客戶端接收到服務端的握手請求后，生成密鑰對發送給服務端。由於No103開始的包都是服務端向客戶端發送數據，因此客戶端的seq一直是240。
- No147: 服務端向客戶端重發No136包。因為No140這個包客戶已經確認收到seq=5985以前的包了，因此服務端發的這個包發生了虛假重傳。
- No148: 客戶端向服務端發送
ACK包。這個包標記為TCP Dup ACK 140#1是由於No147這個包服務端發生虛假重傳，因此客戶端重新發送No140包。 - No152: 服務端向客戶端發送，包標記為
Change Cipher Spec, Encrypted Handshake Message,這是對握手信息進行加密。 - No153: 客戶端向服務端發送ACK包，接收到了No152包。
發送數據
-
No154-No159: 客戶端向服務端發送數據。
-
No166和No167: 服務端向客戶端發送了2個ACK包。
-
No170: 服務端向客戶端發送數據。
-
No171: 客戶端發送給服務端ACK包，確認收到No170這個包。
-
No178: 服務端向客戶端發送數據，這個包是No170分段后剩余的數據。
-
No179: 客戶端發送給服務端ACK包，seq=8331，ack=8770，確認收到No178這個包。
No152到No179都是正常傳輸的包，這里不做詳細分析了。
斷開連接
- No180: 客戶端接收完服務端數據后就斷開連接了，所以發送了一個
FIN包,同時客戶端進入到FIN_WAIT_1狀態。
理論上服務端發送完就主動關閉http連接， 但是抓包看確是客戶端先發送的
FIN+ACK包，因此說明服務端發送的FIN+ACK的包可能丟包，客戶端沒收到或收到慢了。
- No187: 服務端發送客戶端
FIN+PSH+ACK，seq=7552,ack=8331。這包不但傳了FIN關閉連接，又傳了PSH。說明No178包服務端發出來，客戶端返回的ACK包(No179以及No180)服務端沒收到（這中間可能網絡處理問題）。 - No188: 由於No187包標記為
TCP Out-Of-Order,因此客戶端認為服務端的包亂序了，因此，因此客戶端重傳No179。
- No189: 服務端接收到客戶端的
FIN包,也接受到No188包，返回客戶端一個ACK包，seq也更新成最新的8770,客戶端進入FIN_WAIT_2狀態。
- No198: 服務端發送給客戶端RST重置連接，可能是由於No179到No187之間網絡出現了問題，導致連接異常，因此服務端發送了一個RST重置連接。
結論
上面抓的包經分析可能出現多次網絡異常或網絡波動，出現了亂序，重傳，虛假重傳及連接重置等TCP包。
若分析有誤，希望加以指正。
參考文獻
- 《TCP-IP詳解卷1：協議》18~20章
- 常見的TCP信息
- https建立連接
- https建立連接的過程
本文地址：https://www.cnblogs.com/Jack-Blog/p/8486792.html
作者博客：傑哥很忙
歡迎轉載，請在明顯位置給出出處及鏈接
使用TCP的滑動窗口協議時，接收方不必確認每一個收到的分組。在TCP中，ACK是累積的—它們表示接收方已經正確收到了一直到確認序號減1的所有字節。 ↩︎