本节书摘来自异步社区《大咖讲Wireshark网络分析》一书中的大客户的小问题，作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。

大客户的小问题
大咖讲Wireshark网络分析
最近我司的销售人员遇到了一件烦心事——有位每年采购额颇大的客户，屡次投诉同一个小问题。具体症状是这样的：用户编辑好一个比较大的Excel文件，然后点击保存，就有一定概率出现图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。正常情况下不需要读临时文件呀，为什么会多出这个行为呢？

我赶紧检查了在竞争对手的设备上抓到的包，也发现了类似的行为。唯一不同的是，客户端在我司的设备上读文件时，有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秒以上，是不是也会保存失败呢？

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

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

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

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。