Linux 2.6.16 TCP鏈接速度異常的問題分析

版權聲明：本文由余子軍原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/104

來源：騰雲閣 https://www.qcloud.com/community

 

發現訪問公司某些業務時，速度很是不穩定，而且總體慢於競爭對手。分析認爲SESU10母盤上內核TCP擁塞控制算法和Windows的Ack頻率控制的策略存在不兼容狀況。

目前至少確認 2.6.16內核版本存在此問題；打TCP優化補丁或者更換Tlinux之後能夠解決問題。

問題現象：

在體驗網環境下測試：大文件下載的狀況下，百度的下載速度平均在600KBPS，咱們的下載速度平均低於100Kbps；互娛Webgame狀況下，TNT業務下載速度大約是DDT的25%。

這裏是一個典型的下載速度曲線：

咱們的服務器的曲線：（縱軸單位：包/s）

百度的服務器下載的曲線：

重現該問題的測試環境：

網絡： 公司體驗網，普通聯通4M ADSL

服務器：Linux64位服務器, 深圳機房。

服務器程序： Apache，nws（自研webserver）

客戶端： Windows XP， Windows7，任意瀏覽器或者旋風（單線程下載）

測試工具：wireshark， httpwatch

測試鏈接：分別是自建CDN、百度下載、深圳DC+Apache

問題分析：

經過客戶端抓包分析發現速度很慢的段有兩個問題：

1. 服務器端老是等到前面的數據包確認之後才發送第二個包

2. Windows老是等到200ms左右才發送ACK確認。
   
   

對於Windows端的行爲， 爲了防止ACK過多致使網絡壓力，Ms TCP協議棧在每收到一個數據包時，啓動一個200ms定時器，直到收到其餘數據包或者定時器過時時才發送ACK包。

經過設置註冊表選項 TcpAckFrequency 參數爲1關閉 Ack delay之後，實驗發現下載速度恢復正常，沒法重現下載速度慢的問題。

To configure the max outstanding ACKs in Windows XP/2003/Vista/2008:

[HKEYLOCALMACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters \Interfaces \{Adapter-id}]

TcpAckFrequency = 1 (Default=2, 1=Disables delayed ACK, 2-n = If n outstanding ACKs before timed interval, sent ACK)

由於沒法強制用戶經過修改註冊表避免問題，而且競爭對手也沒有看到相似問題，所以只能從linux端解決。

Linux這一端，首先懷疑和nagle算法有關係，在nws服務器上設置TCP_NODELAY之後仍然能夠重現，能夠排除Nagle算法的影響。 （實際上nws每次發送大數據包或者直接使用sendfile，不太會收到nagle算法影響） 其次Apache，nws均可以重現這個問題，比較懷疑操做系統自己有缺陷。

由於每次linux僅發送一個數據包，所以懷疑擁塞窗口的問題，推測問題以下：

初始狀況下，客戶端回覆一個ACK時，擁塞窗口增大，每次發送多個數據包，所以剛開始能夠有較快的傳輸速度；由於網絡延時抖動或丟包致使服務器協議棧斷定數據包超時，重置擁塞窗口爲1，每次僅發送一個數據包，收到客戶端200ms回包，時仍然認爲超時，同時調整RTT；直到RTT增大到200ms不算超時爲止，擁塞窗口得以擴大，能夠發送多個數據包，傳輸速度增快，如此循環。

經過測試增大初始擁塞窗口爲10 （更換內核加載架平新技術組的TCP優化模塊實現），下載速度恢復正常。

附旋風測試選項：

參考：
http://smallvoid.com/article/winnt-nagle-algorithm.html
http://support.microsoft.com/kb/214397/en-us