wireshark数据包分析

最近有很多同事开始学习Wireshark，他们遇到的第一个困难就是理解不了主界面上的提示信息，因而跑来问我。问的人多了，我也总结成一篇文章，但愿对你们有所帮助。Wireshark的提示但是其最有价值之处，对于初学者来讲，若是能理解这些提示所隐含的意义，学起来定能事半功倍。

1．[Packet size limited during capture]

当你看到这个提示，说明被标记的那个包没有抓全。以图1的4号包为例，它全长有171字节，但只有前96个字节被抓到了，所以Wireshark给了此提示。

图1

 

这种状况通常是由抓包方式引发的。在有些操做系统中，tcpdump默认只抓每一个帧的前96个字节，咱们能够用“-s”参数来指定想要抓到的字节数，好比下面这条命令能够抓到1000字节。

[root@my_server /]# tcpdump -i eth0 -s 1000 -w /tmp/tcpdump.cap

 

 

2．［TCP Previous segment not captured］

在TCP传输过程当中，同一台主机发出的数据段应该是连续的，即后一个包的Seq号等于前一个包的Seq+Len（三次握手和四次挥手是例外）。若是Wireshark发现后一个包的Seq号大于前一个包的Seq+Len，就知道中间缺失了一段数据。假如缺失的那段数据在整个网络包中都找不到（即排除了乱序），就会提示［TCP Previous segment not captured］。好比在图2这个例子中，6号包的Seq号1449大于5号包的Seq+Len=1+0=1，说明中间有个携带1448字节的包没被抓到，它就是“Seq=1, Len=1448”。

图2

 

网络包没被抓到还分两种状况：一种是真的丢了；另外一种是实际上没有丢，但被抓包工具漏掉了。在Wireshark中如何区分这两种状况呢？只要看对方回复的确认（Ack）就好了。若是该确认包含了没抓到的那个包，那就是抓包工具漏掉而已，不然就是真的丢了。

顺便分析一下图2这个网络包，它是HTTPS传输异常时在客户端抓的。由于“Len: 667”的小包（即6号包）能够送达，但“Len: 1448”的大包却丢了，说明路径上可能有个网络设备的MTU比较小，会丢弃大包。后来的解决方式证明了这个猜想，只要把整个网络路径的MTU保持一致，问题就消失了。

 

3．[TCP ACKed unseen segment]

当Wireshark发现被Ack的那个包没被抓到，就会提示 [TCP ACKed unseen segment］。这多是最多见的Wireshark提示了，幸亏它几乎是永远能够忽略的。以图3为例，32号包的Seq+Len=6889+1448=8337，说明服务器发出的下一个包应该是Seq=8337。而咱们看到的倒是35号包的Seq=11233，这意味着8337～11232这段数据没有被抓到。这段数据本应该出如今34号以前，因此Wireshark提示了[TCP ACKed unseen segment]。

图3

 

不难想象，在一个网络包的开头会常常看到这个提示，由于只抓到了后面的Ack但没抓到前面的数据包。

4．[TCP Out-of-Order]

在TCP传输过程当中（不包括三次握手和四次挥手），同一台主机发出的数据包应该是连续的，即后一个包的Seq号等于前一个包的Seq+Len。也能够说，后一个包的Seq会大于或等于前一个包的Seq。当Wireshark发现后一个包的Seq号小于前一个包的Seq+Len时，就会认为是乱序了，所以提示 [TCP Out-of-Order] 。如图4所示，3362号包的Seq=2685642小于3360号包的Seq=2712622，因此就是乱序。

图4

 

小跨度的乱序影响不大，好比本来顺序为1、2、3、4、5号包被打乱成2、1、3、4、5就没事。但跨度大的乱序却可能触发快速重传，好比打乱成2、3、4、5、1时，就会触发足够多的Dup ACK，从而致使1号包的重传。

5．[TCP Dup ACK]

当乱序或者丢包发生时，接收方会收到一些Seq号比指望值大的包。它每收到一个这种包就会Ack一次指望的Seq值，以此方式来提醒发送方，因而就产生了一些重复的Ack。Wireshark会在这种重复的Ack上标记[TCP Dup ACK] 。

以图5为例，服务器收到的7号包为“Seq=29303, Len=1460”，因此它指望下一个包应该是Seq+Len=29303+1460=30763，没想到实际收到的倒是8号包Seq=32223，说明Seq=30763那个包可能丢失了。所以服务器当即在9号包发了Ack=30763，表示“我要的是Seq=30763”。因为接下来服务器收到的10号、12号、14号也都是大于Seq=30763的，所以它每收到一个就回复一次Ack=30763，从图中可见Wireshark在这些回复上都标记了[TCP Dup ACK]。

图5

 

6．[TCP Fast Retransmission]

当发送方收到3个或以上[TCP Dup ACK]，就意识到以前发的包可能丢了，因而快速重传它（这是RFC的规定）。以图6为例，客户端收到了4个Ack=991851，因而在1177号包重传了Seq=991851。

图6

 

7．[TCP Retransmission]

若是一个包真的丢了，又没有后续包能够在接收方触发[Dup Ack]，就不会快速重传。这种状况下发送方只好等到超时了再重传，此类重传包就会被Wireshark标上[TCP Retransmission]。以图7为例，客户端发了原始包（包号1053）以后，一直等不到相应的Ack，因而只能在100多毫秒以后重传了（包号1225）。

图7

 

超时重传是一个很是有技术含量的知识点，好比等待时间的长短就大有学问，本文就不细说了，毕竟须要懂这个的人不多。

8．[TCP zerowindow]

TCP包中的“win=”表明接收窗口的大小，即表示这个包的发送方当前还有多少缓存区能够接收数据。当Wireshark在一个包中发现“win=0”时，就会给它打上“TCP zerowindow”的标志，表示缓存区已满，不能再接受数据了。好比图8就是服务器的缓存区已满，因此通知客户端不要再发数据了。咱们甚至能够在3258～3263这几个包中看出它的窗口逐渐减小的过程，即从win=15872减少到win=1472。

图8

 

9．[TCP window Full]

当Wireshark在一个包中打上[TCP window Full]标志时，就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。以图9为例，Britain一直声明它的接收窗口只有65535，意味着Middle East最多能给它发送65535字节的数据而无需确认，即“在途字节数”最多为65535字节。当Wireshark在包中计算出Middle East已经有65535字节未被确认时，就会发出此提示。至于Wireshark是怎么计算的，请参考本书的《计算“在途字节数”》一文。

图9

 

[TCP window Full]很容易跟［TCP zerowindow］混淆，实际上它们也有类似之处。前者表示这个包的发送方暂时没办法再发送数据了，后者表示这个包的发送方暂时没办法再接收数据了，也就是说二者都意味着传输暂停，都必须引发重视。

10．[TCP segment of a reassembled PDU]

• 当你收到这个提示，确定已经在EditàPreferencesààTCP菜单里启用了Allow sub dissector to reassemble TCP streams。它表示Wireshark能够把属于同一个应用层PDU（好比SMB的Read Response和Write Request之类）的TCP包虚拟地集中起来。如图10所示，这一个SMB Read Response由39～48号包共同完成，所以Wireshark在最后一个包中虚拟地把全部包集中起来。这样作有个好处，就是能够右键点击图10底部的方框，选择CopyàBytesàPrintable Text Only，从而复制整个应用层的PDU。作研发的同窗可能比较须要这个功能。

图10

 

11．［Continuation to #］

• 你看到这个提示，说明已经在EditàPreferencesàProtocolsàTCP菜单里关闭了Allow sub dissector to reassemble TCP streams。好比图10的那些包，一关闭就变成图11这样。

图11

 

仔细对比图10和图11，你会发现Read Response在图10中被算在了48号包头上，而在图11中被算到了39号包头上。这样会带来一个诡异的结果：图10的读响应时间为2.528毫秒（38号包和48号包的时间差），而图11的读响应时间为2.476毫秒（38号包和39号包的时间差）。究竟哪一个算正确呢？这个问题很难回答，若是在意的是实际的总性能，那就看前者；若是想忽略TCP/IP协议的损耗，单看服务器的响应速度，那就看后者。在某些特殊状况下，这二者相差很是大，因此必须搞清楚。

12．［Time-to-live exceeded (Fragment reassembly time exceeded)］

ICMP的报错有好多种，大都不难理解，因此咱们只举其中的一种为例。 [Fragment reassembly time exceeded]表示这个包的发送方以前收到了一些分片，可是因为某些缘由迟迟没法组装起来。好比在图12中，因为上海发往北京的一些包被分片传输，且有一部分在路上丢失了，因此北京方没法组装起来，便只好用这个ICMP报错告知上海方。

图12