Wireshark 学习

icecity1306 2014-09-01

展开全文

请教个问题：怎么升级/替换 wireshark里面的协议分析器？我用wireshark来抓cmpp（中国移动短消息协议）包，但是wireshark的协议分析器是cmpp1.0，现在网上通常都是2.0，这样我在分析cmpp包的时候，wireshark会说这是个malformed packet，因此就无法给出直观的解释。

另外，能推荐比较优秀的数据包协议分析器么？

这个好像挺复杂的，我没有替换过，找到一些信息供参考：

假设已经有了解析器源文件，

插件型

为了编译该解析器代码来创建该插件，除了解析器的源代码packet-foo.c外，还需要在该源代码文件所在目录下创建下列一些文件，其包含了windows平台与unix/linux平台下的各自所需文件。①makefile.am —— unix/linux的makefile模板；②makefile.common ——包含插件文件的名称；③makefile.nmake ——包含wireshark插件的windows平台下的makefile；④moduleinfo.h ——包含插件版本信息；⑤moduleinfo.nmake ——包含windows平台下动态链接库(dll)的版本信息；⑥packet-foo.c ——自定义协议解析器的源代码；⑦plugin.rc.in ——包含windows平台下的dll资源模板。

makefile.common与makefile.am文件必须修改，来反映相关的文件与解析器名称。moduleinfo.h与moduleinfo.nmake文件必须填写版本信息。把该解析器编译成一个动态连接库或共享库，并复制到已安装wireshark的plugin目录下，即可使用。

内置型

内置型协议解析器源代码都在目录wireshark-1.2.0\\epan\\dissectors下。此处，我们以添加udp协议为例，说明内置型添加协议解析器的步骤：

第一步：将要添加的协议解析器源文件packet-udp.c和头文件packet-udp.h放在此目录下；

第二步：在此目录下修改makefile.common文件，分别将源文件和头文件名添加到对应的dissector_src和dissector_include宏下面。

第三步：最后对整个工程进行编译连接，就可以把要添加的协议解析器，如同wireshark大多数内置解析器一起被整合编译到libwireshark中。

数据包协议分析器Capsa，这篇文章可以供参考：十大免费又好用的网络分析工具

这节很有实用意义（狙击网络高延时点）。正好最近处理问题用上了（非常感谢Zhang,Jiawen），分享下应用的思路（也有跟文中不同的地方）。

问题：业务突然变慢，客户端（确定）和服务端（应该）都没有改动。

问题定位：根据经验判断是网络质量变差，现在需要验证判断。（服务端无法协调联查，但服务端处理很多客户端，未见其他地方的客户端有同样问题）。

验证过程：首先断掉客户端重连，用wireshark抓包发现tcp三次握手都还行。客户端发数据包也很快，服务端回tcp的ack也挺快，但数据包的响应就慢了一些。客户端发大数据包的时候，干脆就没响应包回来（但也不是必然）。根据逻辑，服务端和网络都有可能有问题，客户端出问题的可能可以排除。不过业务的服务端是nb的中国移动，客户端所在的网络是中国电信的网络，因此我们基本可以把问题归结为网间互通。

有趣的问题是：小包看起来是ok的，大数据包延迟（或丢包）的现象很严重。

另外有三个问题想请教下Zhang,Jiawen：

1、在wireshark上，如何方便查一个tcp报对应的响应包（或响应包对应的原始包）。可以手工根据sequence id和ack id来判断，但是wireshark提供方便的工具么？----我们的业务是在一个tcp长连接中发很多包。

2、有没有技巧可以方便的统计延时的情况，例如某时间段中，发包到收到ack的延时超过1s的数据包数量？

3、有没有技巧可以方便的统计丢包的情况，例如某时间段中，发出去的包没收到ack的有多少？

问题：业务突然变慢，客户端（确定）和服务端（应该）都没有改动。
问题定位：根据经验判断是网络质量变差，现在需要验证判断。（服务端无法协调联查，但服务端处理很多客户端，未见其他地方的客户端有同样问题）。
验证过程：首先断掉客户端重连，用wireshark抓包发现tcp三次握手都还行。客户端发数据包也很快，服务端回tcp的ack也挺快，但数据包的响应就慢了一些。客户端发大数据包的时候，干脆就没响应包回来（但也不是必然）。根据逻辑，服务端和网络都有可能有问题，客户端出问题的可能可以排除。不过业务的服务端是nb的中国移动，客户端所在的网络是中国电信的网络，因此我们基本可以把问题归结为网间互通。
有趣的问题是：小包看起来是ok的，大数据包延迟（或丢包）的现象很严重。

非常感谢分享.很高兴这篇文章能帮到你.从现象来看像是服务器和客户端中间的某个环节出现了问题.不知道这个问题现在解决了没有,如果有进一步发现再来一起讨论~

关于这几个问题：

1、在wireshark上，如何方便查一个tcp报对应的响应包（或响应包对应的原始包）。可以手工根据sequence id和ack id来判断，但是wireshark提供方便的工具么？

可以参考楼下大牛的回答～

2、有没有技巧可以方便的统计延时的情况，例如某时间段中，发包到收到ack的延时超过1s的数据包数量？

添加一列按照每一个报文据上一个报文的延时来显示：

扩展TCP报文头。右键Time since previous frame in the TCP stream，然后选择Apply as a Column，这样产生新的一列。

如下图所示。就可以方便的看到每一个报文距离上一个报文的延时了。然后可以根据延时从大到小来排列。

样产生新的一列。

如下图所示。就可以方便的看到每一个报文距离上一个报文的延时了。然后可以根据延时从大到小来排列。

3、有没有技巧可以方便的统计丢包的情况，例如某时间段中，发出去的包没收到ack的有多少？

可以尝试应用display filter过滤条件，输入tcp.analysis，wireshark会列出关于TCP问题和性能的过滤条件，其中有关于重传报文(tcp.analysis.retransmission)的过滤：

另外给出一个TCP显示过滤条件的详细说明：

Wireshark · Display Filter Reference: Transmission Control Protocol

1， “业务突然变慢，客户端（确定）和服务端（应该）都没有改动。”

[沛满]：如果怀疑是网络有问题，可以在业务慢的时候抓个500MB左右的网络包分析一下。论坛可以上传的话我也可以帮忙分析。

2，“在wireshark上，如何方便查一个tcp报对应的响应包（或响应包对应的原始包）。可以手工根据sequence id和ack id来判断，但是wireshark提供方便的工具么？----我们的业务是在一个tcp长连接中发很多包。”

[沛满]：这个要从基本原理讲起。TCP的工作方式不是逐个包发送的，而是一口气发出多个包，从而提高传输效率。就像快递员会一次性携带很多包裹到我司前台一样，为的是减少消耗在路上的往返时间。接收方收到这些包之后有两个选择，既可以每个包都确认（也就是你提到的响应），也可以只确认最后一个来暗示所有包都收到了。举个例子，发送方发出了10个包，编号1至10，且没有一个丢失的，那接收方既可以回复10个确认包，也可以只回复“ack 11”，表示10以及10之前的所有包都收到了。当有丢包发生时，比如还是发送了10个包的情况，编号也是1至10，但其中10号包丢失了，那接收方可以回复9个确认包，也可以只回复“ack 10”，表示9以及9之前的包都收到了。

了解了这个原理，我们就知道在Wireshark上没有必要去对应每个ack和seq，因为大多数包即便正常收到后也不会有ack。

3，“有没有技巧可以方便的统计延时的情况，例如某时间段中，发包到收到ack的延时超过1s的数据包数量？”

[沛满]：如果你只是想了解网络延时状况，那用ping最简单准确了，没有必要用Wireshark。一般我们在乎的是应用层的延时，比如向一个服务器发送读请求，到收到读响应的时间差究竟有多少。Wireshark上有提供这个功能，比如CIFS协议那就可以用“smb.time > 1”来过滤出所有超过一秒钟的延时的CIFS操作。如果是NFS，就用rpc.time（因为NFS是基于RPC的协议）。HTTP也有http.time。

4，“有没有技巧可以方便的统计丢包的情况，例如某时间段中，发出去的包没收到ack的有多少？”

[沛满]：还是那句话，没有收到ack不一定是丢包了。如果是想看丢包重传的统计，那就Analyze-->Expert Info，然后看warnings or notes tab. 虽然要统计出结果很容易，不过使用者需要理解tcp的基础知识才能解读这个结果，比如一个超时重传，导致的后果远远超过一个快速重传。有启用SACK的时候，处理多个丢包的效率远高于没有启用SACK的……这个说起来太复杂了。

先回答这个问题：