再逐个分析重传的网络包，现象就更加有趣了。如下图所示，接收方明明收到了Seq 20440（Frame No.3），但它发送了4个“Ack20440”给发送方，触发了发送方的快速重传机制。这说明接收方的TCP层在收到20440之前，已经收到了21900，23360，24820，26280。这个结果表明，客户端在把包从网络层交给TCP层的时候，自己把包打乱了。为什么我们知道客户端只是打乱20440，而不是丢弃呢？在发送方重传的Seq20440（Frame No. 14）到达接收方之前，接收方又发送了“Ack28900”，这表明接收方的TCP层收到了28900之前的所有包，包括20440。从以上分析可以得出，重传的根本原因发生在操作系统或者网卡驱动，和Switch或者Isilon完全没有关系。
这结果是何等出人意料，以至于我自己都难以接受。不但颠覆了我前一天早上的分析结果，而且无法说服同事和客户：我们已经测试了7台客户端，结果都是一样的，难道7台同时出问题了？这概率低得难以置信。接下来的就是一场辩论，C电视台派出了一位网络专家，企图说服我客户端没有问题。我无法解释为什么会碰到如此低概率的事情，他也无法反驳我在网络包中看到的问题。一直拉锯到夜里12点，客户才答应第二天提供另外7台客户端供我们测试，但是有一个要求，必须给提供他们一个官方的分析报告，证明的确是客户端导致的问题。
和客户吃完晚饭，已经凌晨1点。JW万豪非常贴心，准备好了巧克力，掀好被子，拆好拖鞋。可惜我没有机会享受，等写完报告，已经到了凌晨3点半。没睡多久，morning call就来了……再次感叹现场工程师真辛苦。这天我是真的信心满满的到C电视台的，因为大多数重传的包都被我逐一研究过。现场工程师手脚麻利，很快就测出结果，在7台同时读写的情况下，每台都到100MB/s以上，大大超过了客户的期望值，甚至达到客户机单网卡的理论极限了。在场的现场工程师们异常兴奋，给测试结果拍照，截屏，甚至拍了一段视频。他们被这个项目压抑太久了，需要好好庆祝。
而我也背起笔记本，挥手向这栋造型诡异的建筑，向这个诡异的问题告别。匆匆赶往首都机场，家里还有生病的老婆，断奶的孩子，还要没搬完的家……