運用TCP協議原理解決音頻業務時延高問題

摘要：TCP協議是一種面向連接的傳輸層通信協議，被廣泛使用于互聯網應用中。其主要功能是在發送方和接收方之間建立可靠的連接，確保數據包有序、無差錯地傳輸。通過對TCP數據包交互的分析，可以發現和解決很多系統和網絡問題。本文針對在公有云上部署音頻業務出現的系統時延高問題進行了分析，并提出了相應的優化措施。具體包括解決發送窗口不足、緩解RTT對業務時延的影響、處理亂序數據包和TCP 0窗口等問題。通過針對性地優化，不僅有效地降低了業務平均時延，還提高了系統的效率和可用性。

關鍵字：TCP協議；滑動窗口；亂序；音頻；時延

一、問題背景

某個音頻業務從自有IDC機房分別“復制”部署到云上的北方資源池和南方資源池，部署后測試發現：業務系統在兩個資源池都出現了系統時延上升的情況，且南方資源池的時延比北方資源池更高。該業務部署在自有IDC時，監測數值是100毫秒以內，部署在北方資源池的時延增加到200+毫秒，部署在南方資源池的時延達到了400+毫秒。

系統的部署情況和業務邏輯如圖1所示，主要的步驟如下：

用戶通話結束后，平臺會生成錄音文件URL并推送給用戶；

用戶通過公網請求到平臺，以獲取錄音文件。

錄音下載請求經過平臺的SLB（Server Load Balancing，服務器負載均衡）后，分發到xfile服務器（錄音下載服務），xfile服務器從xmedia服務器（媒體服務）內存查詢錄音文件，如果不存在，則從存儲空間中查詢錄音文件。

音頻下載的業務流程：客戶→互聯網→云入口→SLB→xfile服務器→xmedia服務器（媒體服務）→xfileserver→SLB→云出口→互聯網→客戶。

根據初步判斷，此音頻業務在云資源池遇到了網絡或主機性能方面的瓶頸，需要盡快分析和解決該問題。

二、分析過程

為定位問題根因，獲取業務過程中的網絡數據包進行分析是一個明智的做法。根據數據包傳送情況和協議交互情況，可具體從數據包傳輸效率、高時延的組成、是否存在數據包亂序、是否存在TCP 0窗口四個因素進行分析。

（一）發送窗口不足影響傳輸效率

從網絡出口、SLB的數據監控點回溯網絡數據和交互情況，該業務使用TCP協議。因此可先從TCP協議的特性進行分析。在每次數據交互過程中，決定傳輸效率的要素有三個，分別是網絡時延、滑動窗口（發送窗口swnd，接收窗口rwnd）和擁塞窗口cwnd。其中：

擁塞窗口是數據發送端負責控制發送數據量的關鍵參數。

滑動窗口是數據接收端控制接收數據量的關鍵參數。

數據接收過程中滑動窗口可以近似約等于接收窗口，滑動窗口的數值可以從報文中的TCP選項參數中直接獲得，發送窗口數值無法從數據包中獲得信息，但可以從數據量的角度去評估。

回溯一次系統過程，可得圖2，從圖可知關鍵信息如下：一是網絡時延（RTT）45ms，表示來回傳輸數據所需的時間。二是數據接收方發起的最后一個應用請求包中通告的滑動窗口（近似于接收窗口）大小為42496字節，代表它在此刻通告對方，“這一次的傳輸中，我能接收42496B的數據”。

通過MTU協商后最大IP包載荷是1460字節，通過42496÷1460可得，接收方每次可以接收29個滿載荷的數據包，而實際上發送方只發送了不到10個滿載荷的數據包。具體如圖3所示。這表明初始發送方的擁塞窗口遠低于接收窗口的承載量，并且發送窗口爬升速度也非常緩慢，始終低于接收窗口。

在這種情況下，184KB的數據內容理論上只需要等待4～5次確認，消耗4～5個RTT的時間，但事實上卻消耗了9次等待時延，至少增加了4×45ms=180ms的時延影響。

（二）RTT對業務時延的影響

業務系統在原有IDC機房時，服務器之間的網絡時延為1ms，在北方資源池的網絡時延為20ms，在南方資源池的網絡時延為45ms。與原有IDC機房相比，南北資源池時延相繼差了19ms和25ms。

結合前文分析，用戶一項業務需要交互多次數據，也就是消耗多個RTT進行確認等待。即使交互較多，在原有IDC機房內，1ms的RTT乘以交互次數的整體時延不高，影響不大。但是在北方資源池，9次的等待確認時延，就會消耗9×19ms=171ms的時延，而在南方資源池，則會再增加9×25ms=225ms的時延。這也就解釋了問題背景中所提到的“業務部署在自有IDC時的監測數值是100毫秒以內，系統在北方資源池的時延增加到200+毫秒，在南方資源池則達到了400+毫秒”。

（三）亂序影響發送效率

繼續對比分析業務正常和業務時延高的數據包交互情況，并解釋數據包丟失的原因。

在業務正常時，會話交互開始時數據交互是正常的，第一批傳輸數據的過程中，完成了23個1448字節的數據報文傳輸。而后，傳輸到序號為第38個包時，接收窗口已滿，出現TCP window full，等待接收端確認。

在確認過程中，序號為第38個數據包提前出現，比第23個數據包還提前出現，這表明接收端無法及時處理數據，導致后續ACK包滯后。此時，接收端會發出多個帶有左右邊界的ACK包，以確認已經接收到的數據包時標識左邊界和右邊界。

客戶端隨后陸續發出相似的確認包，最終的ACK包中確認收到了前文的所有數據。但在這個過程中，服務端以為丟失了數據包，會同步重傳這部分數據。

上述的亂序問題在這個TCP會話中多次出現，讓服務端認為出現了丟包，基于TCP協議機制，服務端的擁塞窗口持續下降，傳輸的數據量也從原來的每次可傳23個數據包減少到每傳12個數據包就要等待一次確認，導致傳輸效率持續下降，業務時延隨之波動較大。

（四）TCP 0窗口影響SLB轉發性能

從數據交互中看到，SLB往后端xfileserver調用數據的過程中，SLB偶發性發出了TCP 0窗口的ACK報文。一般情況下，TCP 0窗口是否需要被關注和優化，需要結合時延進行分析和決策。如果恢復窗口（TCP windows Update）的ACK報文出現得快，業務也無實質影響，則可以忽略；但如果如圖4所示，SLB多次出現了接近200ms的0窗口延遲等待現象，那這種情況下的0窗口延遲就會影響業務的轉發效率，增加延遲，如此就需要對TCP 0窗口進行優化。

三、優化措施及效果

根據前文的4個瓶頸點分析，從實際影響來看，筆者提出了4個對應的優化措施：

①針對發送端擁塞窗口較小，可以調整初始發送數據大小。通過之前的分析可以看到，初始接收窗口穩定在40KB左右時，將SLB初始發送值修改為400000即可緩解發送端擁塞窗口小的問題。因此，修改SLB上的配置參數，將初始值調整為30倍的MSS，是較為合適的，可以滿足大部分TCP會話的需求。

②針對RTT較高，優化內網時延。公網的網絡時延一般不可控或不能調整，但是內網的網絡時延可以優化，通過路由調優、系統增強等方式，可以將xfileserver（音頻下載服務）--gt;xmedia（媒體服務）的平均時延從20ms降到10ms；將“網絡出口--gt;SLB”的平均時延從17ms降到10ms。

③針對亂序影響發送效率，將SLB的擁塞檢測算法從CUBIC切換到BBR。這里有兩點需要留意：①一般觀念里，BBR算法提升的是大流量場景下的吞吐量水平，但這對算法原理存在一些“偏見”，實際上BBR可對有丟包或亂序導致重傳影響的發送效率有較大的提升，能在少量丟包情況下保持業務的高效性，BBR算法可適用于全場景，而不僅是大流量場景。②一個TCP會話使用的擁塞控制算法只與局部有關，也就是說服務端管服務端的，客戶端管客戶端的，這個業務關系中，只需要調整SLB的擁塞檢測算法即可，不需要調整客戶端的配置。

④修改SLB上的接收窗口，減少TCP 0窗口引起的延遲。通過調整SLB的接收窗口大小，減少0窗口等待時間，提高數據傳輸的效率。

在完成上述優化措施后，可以觀察到系統的業務平均時延有明顯降低，整體效果明顯。在壓力測試場景下，業務時延也持續維持在較低水平，系統的效率和可用性都得到了較大的提升，具體如圖6所示。但需要進一步說明的是，在這些優化措施中，最重要的是修改SLB發送窗口和擁塞檢測算法的調整，其次是內網時延的優化，然后是修改SBL接收窗口。

四、經驗總結

在業務搬遷或業務上云的過程中，需要注意應用架構與新資源環境的適配，以及對服務端參數進行調優以適應互聯網的運行環境。有時候，可能需要采取一些定制化的優化措施。

同時筆者留意到，在很多企業將業務上云后，業務交互過程就進入了“黑盒”狀態，業務方和運維方難以了解業務交互細節，更無法知曉如何進行優化。回溯分析是確保業務可觀測性的一個重要手段。如上文所述，在網絡出口回溯“歷史”數據時，可以得知公有云內網存在可優化的時延問題；通過對比公有云出口和SLB的回溯數據，可以發現公網至客戶端的傳輸存在亂序問題，需要進行相應的調優。此外，回溯SLB的前后端流量還可以揭示前端發送窗口初始值不足導致延遲、后端出現的TCP 0窗口事件等諸多問題。這一系列問題都是影響業務性能的瓶頸點。通過根據業務表征找到這些問題，就可以針對性地進行優化，提升系統效率。

作者單位：燕杰 中移（蘇州）軟件技術有限公司

參" 考" 文" 獻

[1] James Pyles，Jeffrey L.Carrell， Ed Tittel，金名等（譯）.TCP/IP協議原理與應用（第5版）[M].北京：清華大學社出版，2018.

[2] Walter Goralski， 黃小紅等（譯） .現代TCP/IP網絡詳解[M].北京：電子工業出版社，2015.

[3]劉旻昊.TCP傳輸速率影響因素及優化方法[J]. 信息與電腦，2016（8）87-88