半夜里，手机突然响起。恍惚中按下接听键，传来的竟然是老板的声音……一番寒暄之后（半夜跑到阳台接电话是挺寒的）：
老板：我司在为C电视台实施Isilon，被一个读性能的问题卡了好几天。希望能派一位网络方面的专家，尽快飞到北京，你……
阿满：我们team有那么多CCIE，能不能派他们去？我老婆正在生病，明天还约好了搬家公司。
老板：#￥%*@$^&……你不用担心，我可以安排几个人帮你搬家。
阿满：（赶在老板安排人帮我照顾老婆之前）好吧，我赶紧准备一下。
回到房间，才想起以前完全没接触过Isilon。Google了一下，才知道是EMC收购的NAS产品，性能卓越，怎么现场工程师们会被卡了好几天？看看表，已经夜里2点了，还是先睡吧。
5点起床，司机已经等在楼下了。飞驰到了办公室，现场工程师上传的网络包也已经准备完毕。粗略一看，有很多包发生了重传（Retransmission），而且有大量乱序（Out-Of-Order）。我的第一反应就是，乱序导致了重传，从而影响了性能。由于时间有限，我随机挑了几个重传的包检查一下，发现重传的方向都是从Isilon到Windows，这倒是符合读慢写快的症状。下图是Wireshark的分析结果。
乱序的网络包为什么会导致重传呢？下面简单介绍一下：
在正常情况下，接收方收到包的Seq号总是顺序的，比如在每个包长度为1460的情况下，Seq号可能是这样的：0，1460，2920，4380……(每个相差1460)。接收方知道下一个包的号码应该是什么，比如4380之后应该是4380+1460=5840。如果收到的不是5840，接收方就知道包序乱了，它会回复一个包给发送方，说“我要的是5840（即Ack5840）”。如果接下来收到的还不是5480，那接收方每收到一个包，就会发一次“我要的是5840”给发送方，直到收到5840为止（如下图所示）。
对于发送方来说，持续收到“我要的是5840”不但意味着5840可能跑到其它包后面了，还可能意味着5840已经丢失。RFC里这样定义:如果发送方收到三次以上的“我要的是X”，即可认为包X丢失，立即启动快速重传。上图演示了这个过程。快速重传不但重新传输了（可能）丢失的包，还会减小TCP发送窗口，对性能的影响仅次于超时重传。分析到这里，我仿佛看到一丝曙光。
乱序一般是由发送方或者网络设备导致的。由于手头只有在Windows客户机抓的包，所以我无法进一步确认。便匆匆赶去机场，飞往北京了。在飞机上拟了一个计划：
1． Isilon和其它服务器一样，估计有类似Large Segment Offload的机制，也许关闭后能减少乱序。
2． 把Isilon和Windows客户端连到同一台空闲的Switch，尽量排除网络设备导致的乱序。
3． 在Isilon上再抓个网络包确认。
到了北京，已经是晚上了。和几位来自香港，美国，北京等地的现场工程师在全聚德边吃边聊。原来他们已经做过很多方面的尝试，包括我计划中的第二点，但客户要求的80MB/s的读性能一直无法达到。客户端也换过几台，结果都差不多。目前看起来网络设备和客户端都没有问题，难道根本原因出在Isilon上了？这和我早上在网络包里看到的现象倒是吻合的。也许明天把Isilon的网络参数调一下，问题就解决了。到这个时候，我还是挺乐观的。
第二天一早，便赶到了C电视台的新大楼，比约定时间还早了2小时。更悲催的是比客户早了3小时……第一次到现场，才体会到现场工程师的苦。搭个测试环境也花了好长时间，等到真正可以测试，已经是下午了。令人兴奋的是，Isilon上果然有Large Segment Offload的设置，我满怀希望的关闭了这个功能。现场工程师立即启动一个新的读测试……结果令我们大跌眼镜，读性能比之前还差一点，降到了70MB/s以下。这究竟是怎么回事？还有哪些设置可能会导致乱序？LACP昨天被现场工程师关掉，没什么好查的。我一下子不知道如何是好了。对着等我下一步建议的几位同事，不知道该说些什么。现场工程师习惯性的抓了一个包，叫我过去看。这一看更是一身冷汗，果然没有乱序的包了。我之前的猜测没有错，乱序是由Large Segment Offload导致的。但为什么消除了乱序之后性能没有得到改善呢？再看重传率，还是一样高。难道我从一开始就走错胡同，重传根本就不是乱序导致的？我不得不一个人坐到角落里，再次打开昨天早上研究过的网络包。一个一个的查看乱序的包，果然看到了一些很有趣的现象。如下图所示，虽然乱序的比例很大，但是每个乱序都是相邻两个包的颠倒，这样接收方永远不会发出三个以上的“我要的是X”，也不会触发快速重传。