首先，要對tcp通信有一定的了解，如何分析包seq，ack等。
不會的點這里

抓包出現(xiàn) spurious retransmission

指實際上并沒有超時，但看起來超時了，導(dǎo)致虛假超時重傳的原因有很多種：

原因

（1）對于部分移動網(wǎng)絡(luò)，當(dāng)網(wǎng)絡(luò)發(fā)生切換時會導(dǎo)致網(wǎng)絡(luò)延時突增
（2）當(dāng)網(wǎng)絡(luò)的可用帶寬突然變小時，網(wǎng)絡(luò)rtt會出現(xiàn)突增的情況，這會導(dǎo)致虛假超時重傳
（3）網(wǎng)絡(luò)丟包（原始和重傳的包都有可能丟包）會導(dǎo)致虛假重傳超時。

tcp虛假重傳分析(摘自網(wǎng)絡(luò))

分析

當(dāng)Client端收到Server的SYN+ACK應(yīng)答后，其狀態(tài)變?yōu)镋STABLISHED，并發(fā)送ACK包給Server；
如果此時ACK在網(wǎng)絡(luò)中丟失，那么Server端該TCP連接的狀態(tài)為SYN_RECV，并且依次等待3秒、6秒、12秒后重新發(fā)送SYN+ACK包，以便Client重新發(fā)送ACK包，以便Client重新發(fā)送ACK包。
Server重發(fā)SYN+ACK包的次數(shù)，可以通過設(shè)置/proc/sys/net/ipv4/tcp_synack_retries修改，默認值為5。
如果重發(fā)指定次數(shù)后，仍然未收到ACK應(yīng)答，那么一段時間后，Server自動關(guān)閉這個連接。
但是Client認為這個連接已經(jīng)建立，如果Client端向Server寫數(shù)據(jù)，Server端將以RST包響應(yīng)，方能感知到Server的錯誤。

抓包結(jié)果

其他原因：
與網(wǎng)卡驅(qū)動能力有關(guān)，業(yè)務(wù)功能bug導(dǎo)致發(fā)出的包有細微差異，wireshark沒有很直觀地展現(xiàn)

WireShark出現(xiàn)的常見提示

TCP Out_of_Order的原因分析

一般來說是網(wǎng)絡(luò)擁塞，導(dǎo)致順序包抵達時間不同，延時太長，或者包丟失，需要重新組合數(shù)據(jù)單元，因為他們可能是由不同的路徑到達你的電腦上面。

TCP Retransmission原因分析

很明顯是上面的超時引發(fā)的數(shù)據(jù)重傳

TCP dup ack XXX#X原因分析

就是重復(fù)應(yīng)答#前的表示報文到哪個序號丟失，#后面的是表示第幾次丟失

TCP previous segment not captured原因分析

意思就是報文沒有捕捉到，出現(xiàn)報文的丟失

下面就詳細的報文進行分析

示例
點擊進去，看最下面的異常情況分析即可。

?
?
報文分析時遇到的英文縮寫
SLE: Sequence Left Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp數(shù)據(jù)的左邊界。
SRE: Sequence Right Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp數(shù)據(jù)的右邊界。

?
?
?
?

本文來自：
https://www.cnblogs.com/stupidbug/articles/8144236.html
https://blog.csdn.net/huaishu/article/details/93739446
https://blog.csdn.net/chenfengdejuanlian/article/details/53761004
https://blog.csdn.net/season_hangzhou/article/details/48318599

總結(jié)

以上是生活随笔為你收集整理的TCP 之 抓包分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。