亂序的網絡包為什么會導致重傳呢?下面簡單介紹一下：

在正常情況下，接收方收到包的Seq號總是順序的，比如在每個包長度為1460的情況下，Seq號可能是這樣的：0，1460，2920，4380…… (每個相差1460)。接收方知道下一個包的號碼應該是什么，比如4380之后應該是4380+1460=5840。如果收到的不是5840，接收方就知道包序亂了，它會回復一個包給發送方，說“我要的是5840(即Ack 5840)”。如果接下來收到的還不是5480，那接收方每收到一個包，就會發一次“我要的是5840”給發送方，直到收到5840為止(如下圖所示)。

對于發送方來說，持續收到“我要的是5840”不但意味著5840可能跑到其它包后面了，還可能意味著5840已經丟失。RFC里這樣定義: 如果發送方收到三次以上的“我要的是X”，即可認為包X丟失，立即啟動快速重傳。上圖演示了這個過程?？焖僦貍鞑坏匦聜鬏斄?可能)丟失的包，還會減小 TCP發送窗口，對性能的影響僅次于超時重傳。分析到這里，我仿佛看到一絲曙光。

亂序一般是由發送方或者網絡設備導致的。由于手頭只有在Windows客戶機抓的包，所以我無法進一步確認。便匆匆趕去機場，飛往北京了。在飛機上擬了一個計劃：

1. Isilon和其它服務器一樣，估計有類似Large Segment Offload的機制，也許關閉后能減少亂序。

2. 把Isilon和Windows客戶端連到同一臺空閑的Switch，盡量排除網絡設備導致的亂序。

3. 在Isilon上再抓個網絡包確認。

到了北京，已經是晚上了。和幾位來自香港，美國，北京等地的現場工程師在全聚德邊吃邊聊。原來他們已經做過很多方面的嘗試，包括我計劃中的第二點， 但客戶要求的80MB/s的讀性能一直無法達到?？蛻舳艘矒Q過幾臺，結果都差不多。目前看起來網絡設備和客戶端都沒有問題，難道根本原因出在Isilon 上了?這和我早上在網絡包里看到的現象倒是吻合的。也許明天把Isilon的網絡參數調一下，問題就解決了。到這個時候，我還是挺樂觀的。

第二天一早，便趕到了C電視臺的新大樓，比約定時間還早了2小時。更悲催的是比客戶早了3小時……第一次到現場，才體會到現場工程師的苦。搭個測試 環境也花了好長時間，等到真正可以測試，已經是下午了。令人興奮的是，Isilon上果然有Large Segment Offload的設置，我滿懷希望的關閉了這個功能?，F場工程師立即啟動一個新的讀測試……結果令我們大跌眼鏡，讀性能比之前還差一點，降到了 70MB/s以下。這究竟是怎么回事?還有哪些設置可能會導致亂序?LACP昨天被現場工程師關掉，沒什么好查的。我一下子不知道如何是好了。對著等我下 一步建議的幾位同事，不知道該說些什么?，F場工程師習慣性的抓了一個包，叫我過去看。這一看更是一身冷汗，果然沒有亂序的包了。我之前的猜測沒有錯，亂序 是由Large Segment Offload導致的。但為什么消除了亂序之后性能沒有得到改善呢?再看重傳率，還是一樣高。難道我從一開始就走錯胡同，重傳根本就不是亂序導致的?我不 得不一個人坐到角落里，再次打開昨天早上研究過的網絡包。一個一個的查看亂序的包，果然看到了一些很有趣的現象。如下圖所示，雖然亂序的比例很大，但是每 個亂序都是相鄰兩個包的顛倒，這樣接收方永遠不會發出三個以上的“我要的是X”，也不會觸發快速重傳。

再逐個分析重傳的網絡包，現象就更加有趣了。如下圖所示，接收方明明收到了Seq 20440(Frame No. 3)，但它發送了4個“Ack 20440”給發送方，觸發了發送方的快速重傳機制。這說明接收方的TCP層在收到20440之前，已經收到了 21900，23360，24820，26280。這個結果表明，客戶端在把包從網絡層交給TCP層的時候，自己把包打亂了。為什么我們知道客戶端只是打亂20440，而不是丟棄呢?在發送方重傳的Seq 20440(Frame No. 14)到達接收方之前，接收方又發送了“Ack 28900”，這表明接收方的TCP層收到了28900之前的所有包，包括20440。從以上分析可以得出，重傳的根本原因發生在操作系統或者網卡驅動，和Switch或者Isilon完全沒有關系。

這結果是何等出人意料，以至于我自己都難以接受。不但顛覆了我前一天早上的分析結果，而且無法說服同事和客戶：我們已經測試了7臺客戶端，結果都是 一樣的，難道7臺同時出問題了?這概率低得難以置信。接下來的就是一場辯論，C電視臺派出了一位網絡專家，企圖說服我客戶端沒有問題。我無法解釋為什么會 碰到如此低概率的事情，他也無法反駁我在網絡包中看到的問題。一直拉鋸到夜里12點，客戶才答應第二天提供另外7臺客戶端供我們測試，但是有一個要求，必 須給提供他們一個官方的分析報告，證明的確是客戶端導致的問題。

和客戶吃完晚飯，已經凌晨1點。JW萬豪非常貼心，準備好了巧克力，掀好被子，拆好拖鞋?？上覜]有機會享受，等寫完報告，已經到了凌晨3點半。沒 睡多久，morning call就來了……再次感嘆現場工程師真辛苦。這天我是真的信心滿滿的到C電視臺的，因為大多數重傳的包都被我逐一研究過?，F場工程師手腳麻利，很快就測 出結果，在7臺同時讀寫的情況下，每臺都到100MB/s以上，大大超過了客戶的期望值，甚至達到客戶機單網卡的理論極限了。在場的現場工程師們異常興 奮，給測試結果拍照，截屏，甚至拍了一段視頻。他們被這個項目壓抑太久了，需要好好慶祝。

而我也背起筆記本，揮手向這棟造型詭異的建筑，向這個詭異的問題告別。匆匆趕往首都機場，家里還有生病的老婆，斷奶的孩子，還要沒搬完的家……