大咖讲Wireshark网络分析pdf/doc/txt格式电子书下载

书名：大咖讲Wireshark网络分析pdf/doc/txt格式电子书下载

推荐语：

作者：林沛满著

出版社：人民邮电出版社

出版时间：2017-07-01

书籍编号：30394796

ISBN：

正文语种：中文

字数：82449

版次：

所属分类：互联网+-互联网思维

版权信息

书名：大咖讲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预测到，

....