在本书的《一篇关于VMware的文章》一文中，已经介绍过延迟确认是如何影响性能的。不难理解，它也会严重影响RTT的统计。我们需要精确地监测延迟时间来预防拥塞，就必须在两边都启用TCP Timestamps（见RFC 1323的RTTM一节）来排除延迟确认等因素的干扰。这也是双边加速的好处之一，在服务器上单边加速时很难排除客户端的干扰。

版权信息
大客户的小问题
再来一个很“妖”的问题
从一道面试题开始说起
你一定会喜欢的技巧
一、抓包
二、个性化设置
三、过滤
四、让Wireshark自动分析
五、最容易上手的搜索功能
Patrick的故事
Wireshark的前世今生
TCP的连接启蒙
快递员的工作策略—TCP窗口
百家争鸣
剖析CIFS协议
网络江湖
DNS小科普
无懈可击的Kerberos
TCP/IP的故事
深藏功与名
一个技术男的自白
被误解的TCP
最经典的网络问题
虚惊一场
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号包），而在竞争对手的设备上读文件时，就只是纯粹的读而已。这就是我们从网络包上所能看到的一切了，接下来全靠推理和想象。