TCP協議的性能評測工具 — Tcpdive開源啦

Github地址：https://github.com/fastos/tcpdive

為什么要開發Tcpdive

在過去的幾年里，隨著移動互聯網的飛速發展，整個基礎網絡已經發生了翻天覆地的變化。
用戶接入網絡的方式，除了寬帶和光纖之外，還有2G/3G/4G/WiFi，5G也已經在路上了。
作為使用范圍最廣的傳輸層協議，TCP誕生于固網時代，在設計之初并沒有考慮到上述種種情況，
這導致了它在某些場景下，性能并不是最優的。因此大多數的CDN廠商和一些規模較大的互聯網公司都會
進行TCP協議的優化，以提供更好的用戶體驗，如更快的訪問速度，更低的訪問失敗率，更流暢的視頻播放等。

而當我們嘗試優化TCP協議時，卻面臨著不少難點：

• 可用的工具少。
  和TCP相關的工具，比如tcpdump，netstat和ss，雖然很好用，但是使用場景并不是TCP協議的性能評測，
  能夠提供的性能信息實在有限。

• 依靠個人感覺，進行盲試。
  不知道瓶頸在哪，盲目修改，或者直接套用已有的優化方法。
  盲目修改常導致徒勞無功，直接套用現成的方法，由于大家的應用場景不盡相同，也不一定有效。

• 測試成本高。
  對TCP協議的性能評測主要采用兩種方法。
  一種是通過對上層應用的測試，來評估TCP協議的性能。這種方法的評價指標有限，而且是上層應用相關的。
  另一種是依靠第三方測試服務。這種方式的樣本量有限，且成本較高。

• 無法準確地評價優化效果。
  上述的兩種測試方法，都涉及到應用層面，因此測量的不僅僅是TCP協議本身，還參雜了干擾因素。

Tcpdive的設計目標

針對上述問題，我們決定設計一個專門的TCP協議性能評測工具，也就是Tcpdive。
之所以起這個名字，是因為dive有深入研究的意思：）

Tcpdive具有一些特性，實際上也是我們的設計目標：

• 對TCP協議的性能進行較為全面的刻畫，有助于發現瓶頸。
  如此一來，就能找到痛點，不用再盲目地進行優化。

• 易于部署和使用，無需改動生產環境，使用成本低。
  這一點非常重要，因為不需要修改內核或者應用程序，比較容易推廣。

• 獨立于上層應用，能夠準確地評價優化效果。
  直接對TCP協議的性能進行刻畫，而不依賴于具體的應用。
  因此能夠排除上層應用的干擾，量化地評價優化效果。

Tcpdive的基本原理

Tcpdive是基于linux內核的探測點機制，使用systemtap腳本語言和內嵌C代碼來實現的。
通過定義幾類相互關聯的探測點和庫函數，來收集和處理運行中內核的數據，以及修改內核的處理邏輯。

為什么要基于systemtap呢？systemtap的神奇之處在于，不修改內核的情況下就能獲取內核中的任何信息，
還可以修改內核的處理邏輯。所以雖然被它虐了千百遍，但還是覺得這套探測點機制非常有用。當然它也不是
十全十美的，比如作為一種調試語言，它是夠用的，但是把它用作一種開發語言，則會遇到不少問題。通過不
斷的嘗試，大多數問題最終都獲得比較好的解決。

目前Tcpdive已經部署到作為流量入口的負載均衡服務器上，在新浪的線上環境7*24h運行，可以說是比較穩定的。

Tcpdive的主要功能

作為一個TCP協議的性能評測工具，Tcpdive提供了大量的性能指標，從以下維度來對每條TCP連接進行刻畫：

• 傳輸情況
• 丟包和重傳
• 擁塞控制
• HTTP處理

1. 傳輸情況

使用如下性能指標來描繪一條TCP連接的傳輸情況，是默認啟用的功能。關于每個性能指標的含義可參考Github。

2. 丟包和重傳

TCP主要使用了兩種丟包的檢測和重傳機制：

• 快速重傳，由重復的ACK觸發
• 超時重傳，由定時器觸發

當收到一定數量的重復ACK后，TCP會判斷有丟包發生了，馬上重傳丟失的數據包。從發送原始數據包，
到發送重傳包，一般在1個RTT以內，所以稱為快速重傳。如果沒有收到足夠多的重復ACK，或者快速
重傳失敗了，就會使用超時重傳。在等待RTO時間后，TCP才判斷發生了丟包，接著會重傳丟失的數據包。
作為快速重傳的failover，超時重傳會耗費更多的時間。

Tcpdive能夠區分快速重傳和超時重傳，在一條TCP連接的生命周期內，分別統計這兩種重傳機制的觸發次數、
重傳的數據包個數、總的等待時間、總的恢復時間、虛假重傳的次數。通過這些性能指標，我們能夠清楚的描述
丟包和重傳對一條TCP連接的影響。這部分功能是可選的，關于每個性能指標的含義可參考Github。

3. 擁塞控制

目前Linux內核默認使用的擁塞控制算法為Cubic。
顧名思義，Cubic的擁塞控制窗口的增長曲線是一個條三次曲線，主要由三部分構成：

• 第一個部是上凸的，擁塞控制窗口快速增長，以接近上次丟包時的大小，稱之為查找階段。
• 第二部分是平緩的，擁塞控制窗口的增長非常緩慢，基本上保持不變，稱之為平穩階段。
• 第三部分是下凹的，擁塞控制窗口快速增長，用于探索可用帶寬的上限，稱之為探索階段。

Tcpdive通過一些針對Cubic的性能指標，來評測當前TCP協議的擁塞控制性能。這部分功能是可選的，關于每個
性能指標的含義可參考Github。

上圖中的性能指標，很多都是一條TCP連接生命周期內的平均值。如果我們想更加準確的描繪一條TCP連接的具體波動呢？
這時候另外一種方法就派上用場了，我們稱之為Advanced CC。和之前基于連接的性能指標不同，它是基于數據包的，
通過記錄5種不同類型的關鍵點，來描繪一條連接的具體波動。關于關鍵點的定義可參考Github。
（下圖是手繪的，Tcpdive目前不支持自動畫圖… )

4. HTTP處理

HTTP是一個基于請求和響應的協議，通常是客戶端先發送一個請求，然后服務器返回一個響應（暫不考慮HTTP/2）。
Tcpdive能夠在TCP層面上，對每個HTTP request和response進行監測，因而獨立于具體的HTTP應用。
Tcpdive支持Per request級別的刻畫，支持HTTP Keep-Alive，這部分功能是可選的。

在服務器端，把每個HTTP請求所花費的時間劃分為三部分：等待請求的到來，服務器的處理時間，響應的傳輸時間。
對于每對HTTP request/response，都提供了如下性能指標：

當進行TCP協議優化時，我們關注的是響應文件的傳輸時間。值得注意的是，從傳統的Web服務器中，是無法獲取這
部分時間的，因為應用層只負責把響應數據交給TCP層，至于TCP層什么時候才把數據傳完，應用程序并不知情。
至于其它兩部分時間，作為干擾因素，是要剔除掉的。通過這一功能，Tcpdive可以準確的評價優化效果，并且做到了
獨立于上層的具體應用。

Tcpdive的使用

如果你看到這里，說明對Tcpdive還是比較感興趣的，趕緊用起來吧：）
關于Tcpdive的使用方法，在Github項目的README中寫的比較詳細，使用方法也不復雜，這里就不再贅述了。

Tcpdive的性能

關于Tcpdive的性能消耗，我們分別在實驗室環境、新浪的線上環境進行了評測，具體可看Github項目的README。