記一次 tcpdump 抓包分析，Dup Ack

起因是 docker pull 映象時有時卡住，然而 registry 一切正常，無奈只好一試抓包。

tcpdump -n -i en0 host 10.116.58.41 -w pull.pcap

引數說明：

-n 不轉換 ip 位址為 hostname -i 網絡卡 host 過濾條件，抓符合 host 位址的包 -w 將抓包結果保留到檔案

下文的 sender、receiver 分別代表資料的傳送方和接收方。在此處 registry 即為 sender，docker client 為 receiver。

在建立 tcp 鏈結協議後，sender 開始傳送資料，receiver 接收到資料後會給 sender 傳送確認的包。通常傳輸的資料較大，tcp 會將其分片傳輸，並且資料報是順序傳送的，每乙個資料報都會有相應的序號 seq。如果 recevier 發現收到的資料報的 seq 不對，則會拋棄該包，並且給 sender 傳送前乙個確認包，此時確認包的 ack 跟上乙個相同，故為 dup ack。

receiver 的確認包的 ack 計算公式如下，而該 ack 也是 sender 下乙個資料報的 seq

ack = seq + bytes of date received # seq 為 sender 傳送的資料報的報文 seq

這個值在 wireshark 檢視這個很方便，會自動幫我們計算出來，如圖：

進一步分析發現，dup ack 通常以乙個 fast retransmission 結束，然後恢復正常。這是什麼原理呢？

這是因為 sender 在收到超過 3 個相同的 ack 時，此時 sender 認為 receiver 沒有收到相應的包，快速再次傳送此丟失包則為 fast retransmission。

那為何是有個 fast 呢？

在 sender 傳送乙個包後，如果超出一定時間沒有收到返回的確認包 ack，sender 則認為 receiver 沒有收到，再次傳送此包即為 retransmission。而 fast retransmission 是 sender 收到超過3個相同的 ack 包時立即發出，可能還沒有到超時時間，故 fast 。

嘛。。。知道來 dup ack 和 fast retransmission ，那我們的網路是啥問題呢？

首先，有太多的 dup ack，說明丟失很多的 sender 的包，網路肯定有問題，不太好。但具體是啥問題，我已經無能為力了。。。。?

記一次 tcpdump 抓包分析，Dup Ack

記一次 Hook 與抓包

tcpdump 抓包與分析

tcpdump抓包分析利器 wireshark

記一次 tcpdump 抓包分析，Dup Ack

記一次 Hook 與 抓包

tcpdump 抓包與分析

tcpdump抓包分析利器 wireshark

相關推薦

記一次 Hook 與抓包