TCP 三異常報文分析

亂序與丟包

1、[tcp previous segment not captured]

[tcp previous segment not captured]報文指的是在tcp傳送端傳輸過程中，該seq前的報文缺失了。一般在網路擁塞的情況下，造成tcp報文亂序、丟包時，會出現該標誌。

需要注意的是，[tcp previous segment not captured]解析文字是wireshark新增的標記，並非tcp報文內容。

例子：流**伺服器39.135.135.81，埠80，傳送序號seq=147154的包，長度len=1360，那麼下乙個資料報序號應該為seq=147154+1360=148514，可以看到客戶端請求的也是ack=148514。而伺服器下乙個包序號為seq=149874，中間的包丟失了。

[tcp out-of-order]指的是tcp傳送端傳輸過程中報文亂序了。

例子：繼續上面的包分析，因為208142包序號為seq=148514，而前乙個序號為seq=149874，故有此錯誤標誌。

seq=148514實際是208139包的響應，因為網路擁塞的情況下，tcp包不能按順序到達，所以出現[tcp previous segment not captured] 和 [tcp out-of-order]標誌。

3、[tcp dup ack ***#x]

[tcp dup ack ***#x]表示第幾次重新請求某乙個包，#前***表示第幾個包（不是seq），#後的x表示第幾次請求。丟包或者亂序的情況下，會出現該標誌。

例子：下圖表示客戶端一直請求101261的包。

重傳1、[tcp fast retransmission]

快速重傳，一般快速重傳演算法在收到三次冗餘的ack，即三次[tcp dup ack ***#x]後，傳送端進行快速重傳。

為什麼是三次呢？因為兩次 duplicated ack 肯定是亂序造成的，丟包肯定會造成三次 duplicated ack。

參考例子：205113的包seq=11154，重複請求4次後，傳送端快速重傳。至於為什麼是4次，可能因為ack包也有丟失。

超時重傳，如果乙個包的丟了，又沒有後續包可以在接收方觸發[dup ack]，或者[dup ack]也丟失的情況下，tcp會觸發超時重傳機制。

tcp超時重傳參考

tcp window

1、[tcp zerowindow]

作為接收方發出現的標誌，表示接收緩衝區已經滿了，此時傳送方不能再傳送資料，一般會做流控調整。接收視窗，也就是接收緩衝區win=*** ，告訴對方接收視窗大小。

例子：傳輸過程中，接收方tcp視窗滿了，win=0，wireshark會打上[tcp zerowindow]標籤。

當接收端接收視窗大小發生變化，可以接收資料了，則有該標誌。

例子：接收方消耗緩衝資料後，更新tcp視窗，，可以看到從win=0逐漸變大，這時wireshark會打上[tcp window update]標籤。

作為傳送方的標識，當前傳送包的大小已經超過了接收端視窗大小，wireshark會打上此標識，標識不能在傳送。

例子：rsttcp異常終止的常見情形

我們在實際的工作環境中，導致某一方傳送reset報文的情形主要有以下幾種：

1，客戶端嘗試與伺服器未對外提供服務的埠建立tcp連線，伺服器將會直接向客戶端傳送reset報文。

3，接收端收到tcp報文，但是發現該tcp的報文，並不在其已建立的tcp連線列表內，則其直接向對端傳送reset報文，如下圖所示：

4，在互動的雙方中的某一方長期未收到來自對方的確認報文，則其在超出一定的重傳次數或時間後，會主動向對端傳送reset報文釋放該tcp連線，如下圖所示：

5，有些應用開發者在設計應用系統時，會利用reset報文快速釋放已經完成資料互動的tcp連線，以提高業務互動的效率，如下圖所示：

reset報文的利用

1 安全裝置利用reset報文阻斷異常連線

安全裝置（如防火牆、入侵檢測系統等）在發現某些可疑的tcp連線時，會構造互動雙方的reset報文發給對端，讓對端釋放該tcp連線。比如入侵檢測檢測到黑客攻擊的tcp連線，其構造成被攻擊端給黑客主機傳送reset報文，讓黑客主機釋放攻擊連線。

2 利用reset報文實施攻擊

安全裝置可以利用reset報文達到安全防護的效果，黑客和攻擊者也可以利用reset報文實現對某些主機的入侵和攻擊，最常見的就是tcp會話劫持攻擊。關於tcp會話劫持的相關知識請參考第三章《tcp會話劫持》一文

TCP 三 異常報文分析