半夜里，手機突然響起。恍惚中按下接聽鍵，傳來的竟然是老板的聲音……一番寒暄之后(半夜跑到陽臺接電話是挺寒的)：
老板：我司在為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(即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的讀性能一直無法達到。客戶端也換過幾臺，結果都差不多。目前看起來網絡設備和客戶端都沒有問題，難道根本原因出在Isilon上了?這和我早上在網絡包里看到的現象倒是吻合的。也許明天把Isilon的網絡參數調一下，問題就解決了。到這個時候，我還是挺樂觀的。
第二天一早，便趕到了C電視臺的新大樓，比約定時間還早了2小時。更悲催的是比客戶早了3小時……第一次到現場，才體會到現場工程師的苦。搭個測試環境也花了好長時間，等到真正可以測試，已經是下午了。令人興奮的是，Isilon上果然有Large Segment Offload的設置，我滿懷希望的關閉了這個功能。現場工程師立即啟動一個新的讀測試……結果令我們大跌眼鏡，讀性能比之前還差一點，降到了70MB/s以下。這究竟是怎么回事?還有哪些設置可能會導致亂序?LACP昨天被現場工程師關掉，沒什么好查的。我一下子不知道如何是好了。對著等我下一步建議的幾位同事，不知道該說些什么。現場工程師習慣性的抓了一個包，叫我過去看。這一看更是一身冷汗，果然沒有亂序的包了。我之前的猜測沒有錯，亂序是由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電視臺的，因為大多數重傳的包都被我逐一研究過。現場工程師手腳麻利，很快就測出結果，在7臺同時讀寫的情況下，每臺都到100MB/s以上，大大超過了客戶的期望值，甚至達到客戶機單網卡的理論極限了。在場的現場工程師們異常興奮，給測試結果拍照，截屏，甚至拍了一段視頻。他們被這個項目壓抑太久了，需要好好慶祝。
而我也背起筆記本，揮手向這棟造型詭異的建筑，向這個詭異的問題告別。匆匆趕往首都機場，家里還有生病的老婆，斷奶的孩子，還要沒搬完的家……
京公網安備 11010502049343號