TCP Wireshark网络抓包分析和问题解决说明

今天遇到问题，更新博客（20200520）：

一、数据包详细信息

---

Packet Details面板内容如下，主要用于分析封包的详细信息。

帧：物理层、链路层

包：网络层

段：传输层、应用层

1）Frame

物理层数据帧概况

2）Ethernet II

数据链路层以太网帧头部信息

3）Internet Protocol Version 4

互联网层IP包头部信息

IP包头：

4）Transmission Control Protocol

传输层数据段头部信息，此处是TCP协议

TCP包头：

5）Hypertext Transfer Protocol

应用层信息，此处是HTTP协议

 

二、着色规则

---

Wireshark默认有一组着色规则，可以在Packet Details面板中展开包的帧部分，查看着色规则。

在View | Coloring Rules中，打开着色规则窗口，可以自己创建、删除、选中、去除。

 

三、Wireshark提示

---

1. Tcp previous segment lost（tcp先前的分片丢失）
2. Tcpacked lost segment（tcp应答丢失）
3. Tcp window update（tcp窗口更新）
4. Tcp dup ack（tcp重复应答）
5. Tcp keep alive（tcp保持活动）
6. Tcp retransmission（tcp重传）
7. Tcp ACKed unseen segument （tcp看不见确认应答）
8. tcp port numbers reused（tcp端口重复使用）
9. tcp retransmission（tcp重传）
10. tcp fast retransmission (tcp快速重传)
11. TCP Previoussegment lost（发送方数据段丢失）
12. tcp spurious retransmission(tcp伪重传)

1）Packet size limited during capture

说明被标记的那个包没有抓全。一般是由抓包方式引起，有些操作系统中默认只抓每个帧的前96个字节。

4号包全长171字节，但只有96字节被抓到。

2）TCP Previous segment not captured

如果Wireshark发现后一个包的Seq大于Seq+Len，就知道中间缺失了一段。

如果缺失的那段在整个网络包中找不到（排除了乱序），就会提示。

6号包的Seq是1449大于5号包的Seq+Len=1+1=1，说明中间有个1448字节的包没被抓到，就是“Seq=1,Len=1448”。

‘

175: SEQ=4675 大于 174: SEQ=Seq(4381)+0 (len)

前一个TCP分段没有抓到。 
在TCP连接建立的时候，SYN包里面会把彼此TCP最大的报文段长度，即MSS标志，一般都是1460.如果发送的包比最大的报文段长度长的话就要分片了，被分片出来的包，就会被标记了“TCP segment of a reassembled PDU”，这些包分片存在同样的ack number，且每个分片的seq number不同。 

这些分片正常应该是连续接收的，即前一个分片指示的next seq number即为下一个收到的分片的seq number。假如收到的下一个分片的seq number与上一个比不连续的话，wireshark就会将该分片标记为TCP Previous segment not captured。如下图，ack number为705的TCP包被分为多个分片发送，其中有一个长度为1408的分片没有被抓到。 

 

 

3）TCP ACKed unseen segment

当Wireshark发现被Ack的那个包没被抓到，就会提示。

32号包的Seq+Len=6889+1448=8337，说明下一个包Seq=8337。

而我们看到的是35号包的Seq=11233，意味着8337~11232这段数据没抓到。

 

4）TCP Out-of-Order

一般来说是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元，因为他们可能是由不同的路径到达你的电脑上面。

当Wireshark发现后一个包的Seq号小于前一个包的Seq+Len时，就会认为乱序，发出提示。

3362号包的Seq小于3360包的Seq，所以就是乱序。

Wireshark判断TCP out-of-order是基于TCP包中SEQ number并非期望收到的下一个SEQ number，则判断为out-of-order。因此，出现TCP out-of-order时，很大可能是TCP存在乱序或丢包，导致接收端的seq number不连续。 
如下图，第4包数据，在客户端已经收到服务端的SYN ACK后，服务端再次发送了SYN ACK，wireshark将此包标记为out-of-order。

如下图，第7包数据，本应收到seq number为1366882的TCP包，但却收到了1044834的包，这包数据应该是晚到了，因此wireshark标记为out-of-order。 

 

5）TCP Dup ACK

TCP dup ack XXX#X：
就是接收端要求发送方重复应答XXX序号丢失的报文，#后面X的是表示第几次丢失。

当乱序或丢包发生时，接收方会收到一些Seq号比期望值大的包。没收到一个这种包就会Ack一次期望的Seq值，提现发送方。

7号包期望的下一个Seq=30763，但8号包Seq=32223，说明Seq=30763包丢失，9号包发了Ack=30763，表示“我要的是Seq=30763”。

10号、12号、14号也都是大于30763的，因此没收到一个就回复一次Ack。

重复ack。 
当网络中存在乱序或者丢包时，将会导致接收端接收到的seq number不连续。此时接收端会向发送端回复重复ack，ack值为期望收到的下一个seq number。重复ack数大于等于3次将会触发快速重传。如下图， 
315包，客户端向服务端发送ack=126951的反馈，期望下一包收到seq=126951的TCP包。但下一包接收到的却是seq=128211的TCP包，由于seq不连续，wireshark将该报标记为TCP Previous segment not captured。 
317包，客户端向服务端重复发送ack=126951的包，第一次重发，#后边带1。 
318包，客户端收到seq=126951的TCP包。 
319包，截止到seq=129471的所有TCP包全部收到，因此客户端回复了ack=129471的反馈。 

6）TCP Fast Retransmission

当发送方收到3个或以上的【TCP Dup ACK】，就意识到之前发的包可能丢了，于是快速重传它。

TCP快速重传。 
TCP协议设定了快速重传机制以避免过多的慢启动对传输速率的影响。快速重传通过接收到3个或3个以上重复的ack反馈触发。快速重传不需要等待RTO超时。如下图。 
325包，客户端向服务端反馈ack=133251，说明下一个期望收到服务端seq=133251的包； 
326包，服务端向客户端发送了seq=135771的数据包，与客户端的期望不符，因此客户端在327包重传了ack=133251的包，再次申明期望收到seq=133251的包。Wireshark将重复ack标记为TCP Dup ACK，#后边指明为第几次重传。 
328包，服务端向客户端发送了seq=137031的数据包，仍然与客户端期望不符，客户端在329包再次重传ack=133251的包。 
330包，服务端收到3次重复ack，触发快速重传，重传了seq=133251的TCP分片。 

 

7）TCP Retransmission

如果一个包真的丢了，又没有后续包可以在接收方触发【Dup Ack】就不会快速重传。

这种情况下发送方只好等到超时了再重传。

1053号包发出后，一直没有等到相应的Ack，只能在100多毫秒之后重传了。

TCP重传。 
当抓到2次同一包数据时，wireshark判断发生了重传，同时wireshark没有抓到初传包的反馈ack，因此，wireshark判定重传有效，标记为TCP Retransmission。基于软件的判定机制，如果抓包点在客户端的话，TCP重传一般为上行包，因为这时，客户端并没有收到服务端的反馈ack，无从知晓服务端是否收到了初传包，RTO超时后触发客户端重传。此时存在2种情况，即1）服务端收到了初传包，只是下发的反馈ack丢包，客户端没有收到；2）服务端没有收到初传包，因此也就没有下发反馈ack。对于第一种情况，如果抓包点在服务端的话，wireshark很有可能就会把来自客户端的重传包标记为TCP Spurious Retransmission。 
如下图，红线的TCP包为重传包，wireshark为该包添加了重传原因，是由于TRO超时导致，以及初传包序号45，并给出了当前的RTO超时时间。 

 

8）TCP zerowindow

包种的“win”代表接收窗口的大小，当Wireshark在一个包中发现“win=0”时，就会发提示。

TCP滑动窗口为0。 
当发送端发包速率大于接收端的接收速率时，会造成接收端TCP window越来越小，当接收端在反馈ack时携带的window size=0时，wireshark标记TCP Zero window。此时发送端将暂停发送数据，直到收到接收端window size!=0的标志。 

 

 

9）TCP window Full

此提示表示这个包的发送方已经把对方所声明的接收窗口耗尽了。

当Wireshark计算出Middle East已经有65535字节未被确认，就会发出此提示。

【TCP window Full】表示发送方暂时没办法再发送数据；

【TCP zerowindow】表示发送方暂时没办法再接收数据。

TCP window满。 
是指的发送端发送的数据已经达到的接受窗口的上限。发送端暂停发送，等待新的接收窗口的通告。 
如下图，客户端向服务端发送的ack反馈，期望下一包收到的seq=288961，但接收窗口仅有960，服务端在收到ack后发送了960字节的数据，TCP window full。注意，len=1004是整个IP包的长度，需要减去IP头44字节，即960字节。 

10）TCP segment of a reassembled PDU

Wireshark可以把属于同一个应用层的PDU的TCP包虚拟地集中起来。

TCP层收到上层大块报文后分解成段后发出去，主机响应一个查询或者命令时如果要回应很多数据（信息）而这些数据超出了TCP的最大MSS时，

主机会通过发送多个数据包来传送这些数据（注意：这些包并未被分片）。

11）Time-to-live exceeded（Fragment reassembly time exceeded）

表示这个包的发送方之前收到了一些分片，但由于某些原因迟迟无法组装起来。

12. TCP window update

TCP窗口更新。 
当接收方的TCP window发生突变时，接收方通过TCP window update消息告知对方当前的接收窗口大小。如下图，TCP window Update同时携带了反馈ack，ack序列号与前一个反馈ack序列号相同，但这并不是重复ack。 

109行：

服务端向客户端端发送 tcp window update，表示buffer已经清空。并提示服务端现在已经有足够的window 大小为 43320。

tcp window update是TCP通信中的一个状态，它可以发生的原因有很多，但最终归结于发送者传输数据的速度比接收者读取的数据还快，这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据，然后向发送者发送Windows Update，告诉给发送者应该以多大的速度发送数据，从而使得数据传输与接受恢复正常。

 

13. TCP acked unseen segment

反馈ACK指向了一个未知的TCP片段。 
这个意思是说ACK反馈的是一个wireshark上不存在的TCP包。很可能是wireshark漏抓了这个包，但却抓到了对端反馈的该报的ack包。如下图，标记为ack unseen segment的包反馈的ack=2721，看着像是反馈的seq=1361的包，但其实这个ack还反馈了seq=1的包，由于seq=1的包没有抓到，因此wireshark将反馈ack标记为ack unseen segment。从下面的图还可知，由于对端已经反馈了ack=2721，说明发端发送的seq=1的包，对端也收到了，只不过wireshark可能漏抓了而已。 

 

14. TCP RST

TCP 重置。 
是TCP协议结束异常连接的一种方式，通过flags中的reset=1标记。当TCP连接无法通过正常的4次挥手结束时，一方可以通过发送携带reset标志的TCP包结束TCP连接。 
如下图，发送方通过2个TCP流发送数据，截图中，接收方首先向发送方反馈了TCP window=0，让发送方暂缓发送数据，之后紧接着发送了TCP RST标记，释放了TCP连接。猜测可能接收方程序突然崩溃了，导致缓存区数据没法清空，之后接收方系统发送了TCP reset释放TCP连接。 

 

问题

---

我们遇到的问题:客户端边下载边播放音频, 在弱网的情况下出现严重的卡顿现象：

卡顿的原因：
1、http的MTU默认是1400，tcp每个包大小为1400，但是tcp无法确保数据先按序到达.  客户端接收完整个数据完成后，才对数据包进行排序，然后才把有序数据传送给应用层http
2、TCP包在网络不好的情况下会发生重传现象。
3、客户端是边接收边播放，即按数据包的seq来播放，如果某个包发生tcp重传，客户端要等到这个包接收了才能继续播放, 因此会发生卡顿现象。
4、我们wireshark没看到 seq=29401的包，并不一定是服务器没有下发。
     wireshark提示：TCP Previous segment not captured。
     wireshark可能没有抓到这个包。

解决办法：
目前边接收边播放，在弱网情况下，tcp发生重传概率很大，就会导致卡顿现象。
断电续传下载播放就会大大降低卡顿现象。

1、包丢失:

    首先wireshark抓包看到提示:TCP Previous segment not captured 说明有数据包缺失：

    501： seq=28001， ACK=140

    502:   seq=30801， ACK=140 (TCP Previous segment not captured) 

              即数据包seq=29401， ACK=140发生丢失了。

    503:   seq=40， ACK=29401 要求服务器发送这个包，

    504:   seq=32201， ACK=140  数据包到达，

    505、507、509（TCP Dup ACK）一直发送给服务器发，告知包已经丢失了，

2、重传数据包：    结果直到547，服务器才重传tcp包过来。

     等到的这段时间，播放音频肯定卡顿了。

3、继续要求重传：seq=30801， ACK=140，（550，552，554...TCP Dup ACK）.

     其实这个包之前已经发送过，客户端没有缓存这个数据。

4、再次重传数据包：    结果直到573，服务器才重传tcp包过来。

      客户端播放音频卡顿就发非常严重啦。