大咖讲Wireshark网络分析

版权信息

书名：大咖讲Wireshark网络分析

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

大客户的小问题

最近我司的销售人员遇到了一件烦心事——有位每年采购额颇大的客户，屡次投诉同一个小问题。具体症状是这样的：用户编辑好一个比较大的Excel文件，然后点击保存，就有一定概率出现图1这样的报错。体积小的文件则从来没有发生过这类报错。

图1

这些文件是保存在我司的网盘设备上的，可是我们的技术人员研究了半天也没有发现原因。有一点可以确定的，就是保存时并没有其他人在使用该文件，肯定是哪里出问题了。于是客户就去找了微软的技术支持，技术支持发现把文件保存在本地硬盘都能成功，算是排除了Excel的因素，又把问题踢回给了我们。

客户被夹在中间非常郁闷，虽然不是什么大问题，但也不能一直拖着吧！便买了一台我司竞争对手的网盘设备来试用。试出来的结果可把我们的销售人员愁死了，不但图1的报错从来没有出现过，而且保存速度还比我们的快得多。假如因为这样一个小问题而丢了大客户，那真是亏大了。于是销售找到我这里来，说无论如何要帮客户把问题解决掉，同时非常贴心地附上了在两个网盘（即我司和竞争对手的产品）上抓到的包。

读过《Wireshark网络分析就这么简单》的读者都知道，Excel保存文件的过程是比较奇葩的。这里再概括一下，保存一个叫abc.xls的文件时底层发生的步骤如下：

1．创建一个临时文件，比如叫123.tmp。

2．文件内容被写进123.tmp中。

3．原文件abc.xls被重命名，比如叫abc.tmp。

4．123.tmp被重命名成原文件的名字，即abc.xls。

5．abc.tmp被删除。

大多在网络上发生的问题，都可以通过Wireshark来排查。我们接下来要做的，就是在网络包中把这5个动作找出来，看看哪一步出现了异常。我先打开了在我司设备上抓到的包，果然很快就发现了异常。图2显示客户端正在读文件， “FID： 0x00a7”指的就是步骤2中的123.tmp。正常情况下不需要读临时文件呀，为什么会多出这个行为呢？

图2

我赶紧检查了在竞争对手的设备上抓到的包，也发现了类似的行为。唯一不同的是，客户端在我司的设备上读文件时，有SET_FILE_INFO这个动作（即图2中的11750号包），而在竞争对手的设备上读文件时，就只是纯粹的读而已。这就是我们从网络包上所能看到的一切了，接下来全靠推理和想象。

• 读临时文件本身似乎不会导致保存失败，因为竞争对手的设备上也有这个现象，关键点就在于SET_FILE_INFO这个动作上。貌似客户端在此修改了临时文件的属性，导致Excel以为该文件正被别人使用。

• 读临时文件和SET_FILE_INFO的行为是由客户端发起的。可见根本原因还是在客户端上，如果能让它们停止这个行为，可能问题就解决了。

考验想象力的时候到了，客户端在什么情况下会发起SET_FILE_INFO来修改文件属性？上文已经提到过，文件保存到竞争对手的设备上时，速度比我们的设备快得多，而且这个问题只发生在大文件上，这给了我们一个启示——如果读临时文件的时间足够长，客户端就会修改其属性？我找到了第一个读请求发生在66.77秒（见图3），SET_FILE_INFO在70.00秒（见图2），中间相差3.23秒。假如临时文件足够大，大到在竞争对手的设备上也需要读3.23秒以上，是不是也会保存失败呢？

图3

我计算了一下，然后生成一个400 MB的Excel让客户测试，果然在竞争对手的设备上也保存失败了。于是这个症状就转变成性能问题——为什么我们的设备比人家的慢？仔细一打听，原来竞争对手的设备和客户端都在上海，而我们的设备却在北京，跨城市时带宽和往返时间都会制约性能（从图4底部就可以看到往返时间，即RTT）。我让北京的客户端尝试了一下，果然得到了相反的结果。

图4

做到这里，我司的销售人员终于松了一口气，这客户算是保住了。然而事情并没有结束，我们总得帮他彻底解决啊，是什么触发了客户端去读临时文件呢？

这又是一个考验想象力的问题，我研究了很久还是没有答案。后来有位做IT Admin的同事想到了，原来他们在杀毒软件McAfee上勾选了”On network drives”，去掉就好了，见图5。

图5

再来一个很“妖”的问题

有读者问，“叔叔，你那些很“妖”的网络问题是在哪找的？我也很感兴趣，但是从来没有遇到过。” 叔叔听完这句话，顿时觉得心里好苦——都是这些“妖怪”自己找上门的，我想躲都来不及，哪会主动去找啊！我们全球有几千用户，假如每位用户每年遇到一次网络故障，我就有看不完的包了。《Wireshark网络分析的艺术》中讲到的那些案例，其实只占极小部分，公司电脑里还躺着几百个案例等着整理呢。既然你们对“妖怪”问题有兴趣，我就再分享一个吧。

上个月有个项目组找到我，说他们的客户端往服务器写数据很慢，但是从服务器读数据却一直很快。该环境中的客户端、服务器和交换机分别属于不同厂商，三家人已经合作排查了一个月，实在没有头绪了，就来找我看看。作为一个叔叔，我要插播一点人生的经验——凡是影响严重，大老板非常关注，却迟迟未能解决的难题，你要尽一切可能承担下来。要知道你平时处理一百件小事都不会有人注意，个人技术也不会提高多少，但是解决掉一个大问题就足以令人刮目相看，自己的技术也会大有长进。

项目组其实已经做了不少有价值的测试，总结如下：

1．如果跳过交换机，直接把客户端和服务器用网线连起来，问题仍然存在。这说明交换机可以排除掉，只需专注客户端和服务器。

2．该客户端写数据到其他类型的设备时速度很快，似乎说明了客户端是好的。

3．其他类型的设备写数据到该服务器上时速度也很快，似乎说明了服务器也是好的。

综上所述，这一对客户端和服务器就像命理相克似的，平时双方都是工作正常的，但是碰到一起就出问题。我的老读者们可能已经想到了一些可能性：是不是有Delayed Ack和Nagle算法的冲突啊？还是网口的Speed/Duplex不一致啊？可惜都不是，项目组早就查遍了。事到如今，只好抓个网络包来分析了。

这个项目团队实在给力，在两边分别抓了几十个 tcpdump文件，合起来有 100 GB。解压缩的时候我的内心是崩溃的，他们说之所以抓了这么多，是因为该症状只是偶尔出现，所以不得不抓了很长时间。要想在 100 GB的网络包里找到偶尔发作的性能问题，对眼睛和耐心都是挑战，幸好Wireshark有个功能在此时可以派上用场：

打开从客户端抓到的包，单击菜单Statistics→TCP StreamGraph→Time-Sequence Graph (Stevens)，就可以生成一个传输状态图了（不要问我“Stevens”是什么意思，我猜这是Wireshark在向伟大的技术作家Richard Stevens致敬）。

在理想状况下，随着数据的匀速传输， Sequence应该逐渐增加，从而形成一根较直的斜线。这次抓到的大多数tcpdump的确都是这样的，如图1所示。

图1

Note：中间有一小段空白，表示那段时间的网络包没有抓到，这种现象可以忽视。

检查了几个tcpdump后，我终于遇到一个异常的，请看图2。大约从 3.0 秒到 11.0 秒之间，Sequence几乎没有增加，这说明当时传输几乎停滞了。我们只要找到当时发生了什么，就能解决问题。

图2

在图2中单击Sequence曲线的 3.0 秒处，就能定位到相应的包号了。请看图3，定位到了No.264536上。

图3

仔细来分析一下图3，服务器在No.264535中声明它的TCP接收窗口有 3145728 字节，可是客户端在No.264536中只发了9657个字节就停下来了，这说明它的拥塞窗口只有 9657 个字节，是客户端的拥塞窗口限制了传输速度，而不是服务器的接收窗口。接下来的包也类似，服务器在No.264537中声明了接收窗口仍然是 3145728 字节，然后客户端在No.264538中发出了 9874 个字节，只比上一次增加了 9874 - 9657 = 217 字节。如此反复，后面的包你们自己看吧。

注意：

本环境中客户端和服务器的MSS都是1460，我们之所以能看到大于 1460 字节的包，是因为客户端启用了LSO（Large Segment Offload）。

可见当时之所以传得这么慢，是因为客户端的拥塞窗口一直很小，而且增长得特别慢。学过TCP协议的读者应该都知道，在慢启动阶段虽然拥塞窗口很小，但是增长得很快，呈翻倍式增长。比如上一次发了 9657 字节，那下一次就应该是 9657 × 2 = 19314 字节。而拥塞避免阶段的拥塞窗口一般已经比较大，而且是以MSS（在此连接中为 1460 字节）增长的，再怎么样也不会只增长 217 个字节。图4表示了拥塞窗口在不同阶段的增长方式（横轴的单位是往返时间，纵轴的单位是MSS）：

图4

那么这问题就应该由客户端来负责了，他们的TCP算法肯定有问题。在“罪证”面前，客户端的厂商也承认了，不过他们也说了，协议栈的问题研究起来没那么快，说不定要几个月。而且为什么这台客户端写到别的服务器就没有问题呢？会不会是服务器上的其他问题触发的？

好人做到底。我觉得他们说的也有点道理，那就继续研究吧。仔细看图3，每当客户端收到服务器的确认包，就立即把数据发出去，比如No.264535和No.264536之间的时间差几乎可以忽略。而客户端发出数据之后，要等很久才能收到服务器的确认，比如No.264536和No.264537之间的时间差竟然有40毫秒。这个延迟在局域网中算是很可观的，为什么会这样呢？我也看不出来。

目前为止，我们分析的网络包都是在客户端抓的，接下来就去分析一下服务器上抓的tcpdump吧。可惜的是项目组在服务器上抓包时，并没有重现出性能问题，也就是说我手头这些包都是好的，只能死马当活马医，尽可能看看了。请看图5，在正常情况下，服务器的响应速度很快，客户端的拥塞窗口增长得也很快（4344724010136），包与包之间几乎都没有时间差。

图5

这图是否能给我们一些启示呢？还真的能。如前面所说，客户端和服务器的MSS都是 1460 字节，我有TCP三次握手过程为证（见图6）。

图6

这说明一个数据包从客户端的网卡发出来时，TCP层最多携带 1460 字节的数据。而从图5却可以看到，服务器收到包的时候，居然是 4344 字节、7240 字节、10136 字节……这是怎么回事呢？我在上本书里只介绍过LSO的工作原理，但没有介绍过LRO（large receive offload）。它是网卡上的一个功能，可以帮助服务器接收偏小的TCP包，缓冲处理成偏大的TCP包再交给服务器。也就是说，客户端收到的那些确认包，其实是服务器网卡缓冲处理了数据包之后才发出的。会不会是网卡缓冲处理时出了bug，导致多花了40毫秒呢？我们只需要在网卡上关闭LRO就知分晓了。我跟项目组打了个电话，让他们执行以下命令来关闭：

ethtool -K eth3 lro off

果然从此之后，他们就再也无法重现那个性能问题了，可以喝啤酒吃炸鸡庆祝了。看到这里你也许会问，客户端的协议栈算法问题不是还没有解决吗？为什么症状就消失了呢？这个问题的精妙之处就在此处：图3中服务器的响应很慢，客户端的拥塞窗口增加得也很慢；而图5中服务器的响应很快，客户端的拥塞窗口增加得也很快。这是否说明客户端其实采用了一种特殊的TCP算法，使拥塞窗口和响应时间挂钩呢？直到问题解决之后，我才意识到这一点。其实我在《Wireshark网络分析就这么简单》中介绍的TCP Vegas就是类似的，摘录如下：

“……Vegas则引入了一个全新的理念。本书之前介绍过的所有算法，都是在丢包后才调节拥塞窗口的。Vegas却独辟蹊径，通过监控网络状态来调整发包速度，从而实现真正的'拥塞避免'。它的理论依据也并不复杂：当网络状况良好时，数据包的RTT（往返时间）比较稳定，这时候就可以增大拥塞窗口；当网络开始繁忙时，数据包开始排队，RTT就会变大，这时候就需要减小拥塞窗口了。该设计的最大优势在于，在拥塞真正发生之前，发送方已经能通过RTT预测到，并且通过减缓发送速度来避免丢包的发生。

与别的算法相比，Vegas就像一位敏感、稳重、谦让的君子。我们可以想象当环境中所有发送方都使用Vegas时，总体传输情况是更稳定、更高效的，因为几乎没有丢包会发生。而当环境中存在Vegas和其他算法时，使用Vegas的发送方可能是性能最差的，因为它最早探测到网络繁忙，然后主动降低了自己的传输速度。这一让步可能就释放了网络的压力，从而避免其他发送方遭遇丢包。这个情况有点像开车，如果路上每位司机的车品都很好，谦让守规矩，则整体交通状况良好；而如果一位车品很好的司机跟一群车品很差的司机一起开车，则可能被频繁加塞，最后成了开得最慢的一个。”

在本案例中，由于服务器上LRO导致的 40 毫秒延迟，使得客户端以为网络上存在拥塞，所以就放慢了速度。而在LRO工作正常的环境中，自然不会有问题。前面说它们命理相克，正是出于这个原因。

从一道面试题开始说起

我每次当面试官，都要伪装成无所不知的大牛。

这当然是无奈的选择——现在每封简历都那么耀眼，不装一下简直镇不住场面。比如尚未毕业的本科生，早就拿下CCIE认证；留欧两年的海归，已然精通英、法、德三门外语；最厉害的一位应聘者，研究生阶段就在国际上首次提出了计算机和生物学的跨界理论……可怜我这个老实人在一开场还能装装，到了技术环节就忍不住提问基础知识，一下子把气氛从学术殿堂拉到建筑工地。不过就是这些最基础的问题，却常常把简历精英们难住。本文要介绍的便是其中的一道。

问题：两台服务器A和B的网络配置如下（见图1），B的子网掩码本应该是255.255.255.0，被不小心配成了255.255.255.224。它们还能正常通信吗？

服务器A：

服务器B：

图1

很多应聘者都会沉思良久（他们一定在心里把我骂了很多遍了），然后给出下面这些形形色色的答案。

答案1：“A和B不能通信，因为……如果这样都行的话，子网掩码还有什么用？”（这位的反证法听上去很有道理！）

答案2：“A和B能通信，因为它们可以通过ARP广播获得对方的MAC地址。”（那子网掩码还有什么用？楼上的反证法用来反驳这位正好。）

答案3：“A和B能通信，但所有包都要通过默认网关192.168.26.2转发。”（请问这么复杂的结果你是怎么想到的？）

答案4：“A和B不能通信，因为ARP不能跨子网。”（这个答案听上去真像是经过认真思考的。）

以上哪个答案是正确的？还是都不正确？如果这是你第一次听到这道题，不妨停下来思考一下。

真相只有一个，应聘者的答案却是五花八门。可见对网络概念的理解不容含糊，否则差之毫厘，谬以千里。要知道，这还只是基本的路由交换知识，假如涉及复杂概念，结果就更不用说了。

问题是即便我们对着教材咬文嚼字，也不一定能悟出正确答案。这个时候，就可以借助Wireshark的抓包与分析功能了。我手头就有两台Windows服务器，已经按照面试题配好网络。如果你以前没有用过Wireshark，就开始第一次亲密接触吧。

1．从http://www.wireshark.org/download.html免费下载安装包，并在服务器B上装好（把所有可选项都装上）。

2．启动Wireshark软件，单击菜单栏上的Capture，再单击Interfaces按钮（见图2）。

图2

3．服务器B上的所有网卡都会显示在弹出的新窗口上（见图3），在要抓包的网卡上单击Start按钮。

图3

4．在服务器B上ping A的IP地址，结果是通的（见图4）。该操作产生的网络包已经被Wireshark捕获。

图4

5．在Wireshark的菜单栏上，再次单击Capture，然后单击Stop。

6．在Wireshark的菜单栏上，单击File，再单击Save，把网络包保存到硬盘上（这一步并非必需，但存档是个好习惯）。

7．收集每台设备的MAC地址以备分析。

• 服务器A: 00:0c:29:0c:22:10
• 服务器B: 00:0c:29:51:f1:7b
• 默认网关: 00:50:56:e7:2f:88

现在可以分析网络包了。如图5所示，Wireshark的界面非常直观。最上面是Packet List窗口，它列出了所有网络包。在Packet List中选定的网络包会详细地显示在中间的Packet Details窗口中。由于我在Packet List中选定的是3号包，所以图5中看到的就是Frame 3的详情。最底下是Packet Bytes Details窗口，我们一般不会用到它。

图5

接下来看看每个包都做了些什么。

1号包（见图6）：

图6

服务器B通过ARP广播查询默认网关192.168.26.2的MAC地址。为什么我ping的是服务器A的IP，B却去查询默认网关的MAC地址呢？这是因为B根据自己的子网掩码，计算出A属于不同子网，跨子网通信需要默认网关的转发。而要和默认网关通信，就需要获得其MAC地址。

2号包（见图7）：

图7

默认网关192.168.26.2向B回复了自己的MAC地址。为什么这些MAC地址的开头明明是“00:50:56”或者“00:0c:29”，Wireshark上显示出来却都是“Vmware”？这是因为MAC地址的前3个字节表示厂商。而00:50:56和00:0c:29都被分配给Vmware公司。这是全球统一的标准，所以Wireshark干脆显示出厂商名了。

3号包（见图8）：

图8

B发出ping包，指定Destination IP为A，即192.168.26.129。但Destination MAC却是默认网关的00:50:56:e7:2f:88（Destination MAC可以在图8中的Packet Details中看到）。这表明B希望默认网关把包转发给A。至于默认网关有没有转发，我们目前无从得知，除非在网关上也抓个包。

4号包（见图9）：

图9

B收到了A发出的ARP广播，这个广播查询的是B的MAC地址。这是因为在A看来，B属于相同子网，同子网通信无需默认网关的参与，只要通过ARP获得对方MAC地址就行了。这个包也表明默认网关成功地把B发出的ping请求转发给A了，否则A不会无缘无故尝试和B通信。

5号包（见图10）：

图10

B回复了A的ARP请求，把自己的MAC地址告诉A。这说明B在执行ARP回复时并不考虑子网。虽然ARP请求来自其他子网的IP，但也照样回复。

6号包（见图11）：

图11

B终于收到了A的ping回复。从MAC地址00:0c:29:0c:22:10可以看出，这个包是从A直接过来的，而不是通过默认网关的转发。

7、8、9、10号包（见图12）：

图12

都是重复的ping请求和ping回复。因为A和B都已经知道对方的联系方式，所以就没必要再发ARP了。

分析完这几个包，答案出来了。原来通信过程是这样的：B先把ping请求交给默认网关，默认网关再转发给A。而A收到请求后直接把ping回复给B，形成图13所示的三角形环路。不知道你答对了吗？

通过这道题，不知道你是否已经感受到了Wireshark的神奇？如果有兴趣进一步练习，不妨也搭个环境，把这道题里A和B的掩码互换一下。看看这次还能ping通吗？如果不能，原因又在哪里？

图13

其实做题对Wireshark只是大材小用，它还可以用于学习复杂的协议，或者解决隐蔽的难题。在下文中，我们将体验Wireshark在实际工作中的应用。

你一定会喜欢的技巧

我开始学习Wireshark的时候，到处碰壁，差点就放弃了。那时最希望的是有前辈能指点迷津，可惜四处求教却鲜有收获。即便多年后的今天，网络上能找到的中文资料还是寥寥无几，少之又少。所以我总结了一些自认为称得上技巧的东西，希望能帮初学者少走一点弯路。

一、抓包

拿到一个网络包时，我们总是希望它尽可能小。因为操作一个大包相当费时，有时甚至会死机。如果让初学者分析1GB以上的包，估计会被打击得信心全无。所以抓包时应该尽量只抓必要的部分。有很多方法可以实现这一点。

1．只抓包头。一般能抓到的每个包（称为“帧”更准确，但是出于表达习惯，本书可能会经常用“包”代替“帧”和“分段”）的最大长度为1514字节，启用了Jumbo Frame（巨型帧）之后可达9000字节以上，而大多数时候我们只需要IP头或者TCP头就足够分析了。在Wireshark上可以这样抓到包头：单击菜单栏上的Capture-->Options，然后在弹出的窗口上定义“Limit each packet to”的值。我一般设个偏大的数字：80字节，也就是说每个包只抓前80字节。这样TCP层、网络层和数据链路层的信息都可以包括在内（见图1）。

图1

如果问题涉及应用层，就应该再加上应用层协议头的长度。如果你像我一样经常忘记不同协议头的长度，可以输入一个大点的值。即便设成200字节，也比1514字节小多了。

以上是使用Wireshark抓包时的建议。用tcpdump命令抓包时可以用“-s”参数达到相同效果。比如以下命令只抓eth0上每个包的前80字节，并把结果存到/tmp/tcpdump.cap文件中。

 [root@server_1 /]# tcpdump -i eth0 -s 80 -w /tmp/tcpdump.cap

2．只抓必要的包。服务器上的网络连接可能非常多，而我们只需要其中的一小部分。Wireshark的Capture Filter可以在抓包时过滤掉不需要的包。比如在成百上千的网络连接中，我们只对IP为10.32.200.131的包感兴趣，那就可以在Wireshark上这样设置：单击菜单栏上的Capture-->Options，然后在Capture Filter中输入“host 10.32.200.131”（见图2）。

图2

如果对更多filter表达式感兴趣，请参考http://wiki.wireshark.org/CaptureFilters。

用tcpdump命令抓包时，也可以用“host”参数达到相同效果。比如以下命令只抓与10.32.200.131通信的包，并把结果存到/tmp/tcpdump.cap文件中。

[root@server_1 /]# tcpdump-i eth0 host 10.32.200.131-w /tmp/tcpdump.cap

注意：

设置Capture Filter之前务必三思，以免把有用的包也过滤掉，尤其是容易被忽略的广播包。当然有时候再怎么考虑也会失算，比如我有一次把对方的IP地址设为filter，结果一个包都没抓到。最后只能去掉filter再抓，才发现是NAT（网络地址转换）设备把对方的IP地址改掉了。

抓的包除了要小，最好还能为每步操作打上标记。这样的包一目了然，赏心悦目。比如要在Windows上抓一个包含三步操作的问题，我会这样抓。

（1）ping <IP> -n 1 -l 1

（2）操作步骤1

（3）ping <IP> -n 1 -l 2

（4）操作步骤2

（5）ping <IP> -n 1 -l 3

（6）操作步骤3

如图3所示，如果我需要分析步骤1，则只要看146～183之间的包即可。注意到146号包最底下的“Data（1 byte）”了吗？byte的数目表示是第几步，这样就算在步骤很多的情况下也不会混乱。

抓包的技巧还有很多，比如可以写一个脚本来循环抓包，等侦察到某事件时自动停止。一位工程师即便不懂网络分析，但如果能抓得一手好包，也是一项很了不起的技能了。

图3

二、个性化设置

Wireshark的默认设置堪称友好，但不同用户的从事领域和使用习惯各有不同，所以有时需要根据自己的情况对配置略作修改。

1．我经常需要参照服务器上的日志时间，找到发生问题时的网络包。所以就把Wireshark的时间调成跟服务器一样的格式。单击Wireshark的View-->Time Display Format-->Date and Time of Day，就可以实现此设置（见图4）。

图4

2．不同类型的网络包可以自定义颜色，比如网络管理员可能会把OSPF等协议或者与Spanning Tree Protocol（生成树协议）相关的网络包设成最显眼的颜色。而文件服务器的管理员则更关心FTP、SMB和NFS协议的颜色。我们可以通过View -->Coloring Rules来设置颜色。如果同事已经有一套非常适合你工作内容的配色方案，可以请他从Coloring Rules窗口导出，然后导入到你的Wireshark里（见图5）。记得下次和他吃饭时主动买单，要知道配一套养眼的颜色可要花不少时间。

图5

3．更多的设置可以在Edit-->Preferences窗口中完成。这个窗口的设置精度可以达到一些协议的细节。比如在此窗口单击Protocols-->TCP就可以看到多个TCP相关选项，将鼠标停在每一项上都会有详细介绍。假如经常要对Sequence Number做加减运算，不妨选中Relative sequence numbers（见图6），这样会使Sequence number看上去比实际小很多。

图6

4．如果你在其他时区的服务器上抓包，然后下载到自己的电脑上分析，最好把自己电脑的时区设成跟抓包的服务器一样。这样，Wireshark显示的时间才能匹配服务器上日志的时间。比如说，服务器的日志显示2/13/2014 13:01:32有一个错误信息。那我们要在自己电脑上调整时区之后，才能到Wireshark上检查2/13/2014 13:01:32左右的包，否则就得先换算时间。

三、过滤

很多时候，解决问题的过程就是层层过滤，直至找到关键包。前面已经介绍过抓包时的Capture Filter功能了。其实在包抓下来之后，还可以进一步过滤，而且这一层的过滤功能更加强大。图7表示一个“IP为10.32.106.50，且TCP端口为445”的过滤表达式。

图7

要说过滤的作用与技巧，就算专门写一本小册子都不为过。篇幅所限，本文只能“过滤”出最适合初学者的部分。

1．如果已知某个协议发生问题，可以用协议名称过滤一下。以Windows Domain的身份验证问题为例，如果已知该域的验证协议是Kerberos，那么就在Filter框输入Kerberos作为关键字过滤。除了纯粹的Kerberos包，你还将得到Session Setup之类包含Kerberos的包（见图8）。

图8

用协议过滤时务必考虑到协议间的依赖性。比如NFS共享挂载失败，问题可能发生在挂载时所用的mount协议，也可能发生在mount之前的portmap协议。这种情况下就需要用“portmap || mount”来过滤了（见图9）。如果不懂协议间的依赖关系怎么办？我也没有好办法，只能暂时放弃这个技巧，等熟悉了该协议后再用。

图9

2．IP地址加port号是最常用的过滤方式。除了手工输入ip.addreq<IP地址> &&tcp.porteq<端口号>之类的过滤表达式，Wireshark还提供了更快捷的方式：右键单击感兴趣的包，选择Follow TCP/UDP Stream（选择TCP还是UDP要视传输层协议而定）就可以自动过滤（见图10）。而且该Stream的对话内容会在新弹出的窗口中显示出来。

图10

经常有人在论坛上问，Wireshark是按照什么过滤出一个TCP/UDP Stream的？答案就是：两端的IP加port。单击Wireshark的Statistics-->Conversations，再单击TCP或者UDP标签就可以看到所有的Stream（见图11）。

图11

3．用鼠标帮助过滤。我们有时因为Wireshark而苦恼，并不是因为它功能不够，而是强大到难以驾驭。比如在过滤时，有成千上万的条件可供选择，但怎么写才是合乎语法的？虽然http://www.wireshark.org/docs/dfref/ 提供了参考，但经常查找毕竟太费时费力了。Wireshark考虑到了这个需求，右键单击Wireshark上感兴趣的内容，然后选择Prepare a Filter-->Selected，就会在Filter框中自动生成过滤表达式。在有复杂需求的时候，还可以选择And、Or等选项来生成一个组合的过滤表达式。

假如右键单击之后选择的不是Prepare a Filter，而是Apply as Filter-->Selected，则该过滤表达式生成之后还会自动执行。图12显示了在一个SMB包的SMB Command: Read AndX上右键单击，并选择Selected之后，所有的Read包都会被过滤出来。

图12

4．我们可以把过滤后得到的网络包存在一个新的文件里，因为小文件更方便操作。单击Wireshark的File-->Save As，选中Displayed单选按钮再保存，得到的新文件就是过滤后的部分（见图13）。

图13

有时候你会发现，保存后的文件再打开时会显示很多错误。这是因为过滤后得到的不再是一个完整的TCP Stream，就像抓包时漏抓了很多一样。所以选择Displayed选项时要慎重考虑。

注意：

有些Wireshark版本把这个功能移到了菜单File-->Export Specified Packets…选项中，如图14所示。

图14

总体来说，过滤是Wireshark中最有趣，最难，也是最有价值之处，值得我们用心学习。

四、让Wireshark自动分析

有些类型的问题，我们根本不需要研究包里的细节，直接交给Wireshark分析就行了。

1．单击Wireshark的Analyze-->Expert Info Composite，就可以在不同标签下看到不同级别的提示信息。比如重传的统计、连接的建立和重置统计，等等。在分析网络性能和连接问题时，我们经常需要借助这个功能。图15是TCP包的重传统计。

图15

2．单击Statistics-->Service Response Time，再选定协议名称，可以得到响应时间的统计表。我们在衡量服务器性能时经常需要此统计结果。图16展示的是SMB2读写操作的响应时间。

图16

3．单击Statistics-->TCP Stream Graph，可以生成几类统计图。比如我曾经用Time-Sequence Graph (Stevens)生成了图17。

图17

从图16中可以看出25～40秒，以及65～75秒之间没有传输数据。进一步研究，发现发送方内存不足，所以偶尔出现暂停现象，添加内存后问题就解决了。

为什么Wireshark要把这个图称为“Stevens”呢？我猜是为了向《TCP/IP Illustrated》的作者Richard Stevens致敬。这也是我非常喜欢的一套书，在此推荐给所有读者。

4．单击Statistics-->Summary，可以看到一些统计信息，比如平均流量等，这有助于我们推测负载状况。比如图18中的网络包才1.594Mbit/s，说明流量低得很。

图18

五、最容易上手的搜索功能

与很多软件一样，Wireshark也可以通过“Ctrl+F”搜索关键字。假如我们怀疑包里含有“error”一词，就可以按下“Ctrl+F”之后选中“String”单选按钮，然后在Filter中输入“error”进行搜索（见图19）。很多应用层的错误都可以靠这个方法锁定问题包。

图19

一篇文章不可能涵盖所有技巧，本文就到此为止。最后要分享的，是我认为最“笨”但也是最重要的一个技巧——勤加练习。只要练到这些技巧都变成习惯，就可以算登堂入室了。