騰訊雲企業帳號代開 提升騰訊雲海外伺服器網路吞吐量的內核優化參數

序：為什麼吞吐量會“卡住”在內核

海外場景的網路吞吐量看起來像是“帶寬不夠”，但在很多實際部署裡，真正在拖後腿的往往是內核層面的行為：TCP擁塞控制如何探測、滑動視窗怎麼擴展、緩衝區是否過小或過大、隊列和排程如何承載突發流量、封包處理是否被錯誤的中斷/親和性分配打斷，以及擁塞或丟包如何被偵測與反饋。

尤其在跨洲或跨國鏈路上，RTT更長、抖動更明顯，對擁塞控制與緩衝策略更敏感。你可能已經在應用層做了連線池、壓縮與重試，但如果內核層不能讓資料更有效地“在時間內被推過去”，吞吐就會在某個區間後長期停滯。

本文以“提升騰訊雲海外伺服器網路吞吐量的內核優化參數”為主線，討論的是一套能被工程團隊落地的思路：先定位瓶頸，再選擇參數調整；不迷信單一係數，而是關注互相制約的整體行為；並且用可觀測性確保改動可回滾、可驗證。

第一章：先把問題定性——吞吐瓶頸常見來源

1.1 路徑與隊列：吞吐像被“排隊時間”限制

跨海鏈路的吞吐不是只取決於物理帶寬，還取決於封包在各層排隊的時間：NIC隊列、宿主機網卡隊列、虛擬化網路層緩衝、Linux排程與qdisc（隊列規則）。如果qdisc設得不合適，或隊列過小，突發流量就會丟包；如果隊列過大，則可能形成延遲膨脹，讓應用等待更久，吞吐反而變差。

因此在調整TCP參數前，先問三個問題：

• 是否存在丟包或重傳上升？
• 延遲是否顯著拉長或抖動加劇？
• 是否因為緩衝/隊列配置導致“填不滿管道”？

1.2 TCP視角：窗口、擁塞控制與重傳是核心三件套

吞吐大多是TCP“在一個RTT周期內能送出去多少資料”決定的。長RTT環境下，如果可用的接收/發送緩衝不足，或窗口成長受限，就會出現“帶寬沒有被用滿”的現象。

另一方面，擁塞控制演算法對丟包的反應會影響吞吐維持能力。當鏈路抖動或中間設備造成的丟包較頻繁時，錯誤的演算法或錯誤的參數組合會讓吞吐在每次事件後低谷很久。

1.3 UDP與應用流：吞吐可能由丟包直接決定

若海外服務大量使用UDP（例如某些實時傳輸、採集上報、遊戲狀態更新或自定義協定），吞吐可能主要受限於：

• socket緩衝過小導致丟包
• 網卡接收隊列與中斷處理無法跟上
• 應用層讀取/寫入頻率與內核緩衝策略不匹配

這時內核參數調整的重點會轉向：rmem/wmem上限、net.core.netdev_max_backlog、NIC多隊列、以及中斷親和與軟中斷處理。

第二章：建立驗證基線——不先測就很難“知道變好”

2.1 先看指標：用什麼判斷“吞吐變好了”

你要定義清楚“變好”的指標。常見可用的驗證維度包括：

• 應用層吞吐：每秒完成的請求數/資料量（以服務日誌或metrics為準）
• 傳輸層吞吐：例如iperf、或抓包估算（要注意環境一致性）
• TCP層：重傳率、重傳次數、SACK使用、RTT變化、擁塞窗口行為
• 系統層：網卡丟包、緩衝丟棄、softnet_stat的drop、CPU使用分佈

2.2 建立基線建議：同一時間、同一流量特徵、同一路徑

改參數後不能只看“峰值吞吐”。如果你能，至少做兩次測試：

• 平穩流：接近平均負載，觀察是否因緩衝調整改善了窗口成長
• 突發流：模擬業務尖峰或上傳/下載波段，觀察丟包和延遲

此外要確保網路路徑一致：同一地區間的鏈路、同樣的對端（至少類似的ISP/路由策略）、同樣的協定版本與加密配置（TLS握手影響初始階段行為）。

騰訊雲企業帳號代開 第三章：TCP參數調優——讓“長RTT的管道”跑滿

3.1 緩衝不是越大越好：核心是讓窗口能長到足夠

在Linux下，TCP的發送與接收緩衝會受到net.ipv4.tcp_rmem、net.ipv4.tcp_wmem與socket層緩衝上限影響。長RTT環境中，若上限過低，窗口無法擴展，就會導致鏈路“用不到”。

但過大的緩衝又可能造成延遲膨脹與更長的恢復時間。合理策略通常是：把“上限”抬高到能覆蓋你的帶寬-延遲積（BDP），同時依靠擁塞控制與隊列管理避免無限膨脹。

騰訊雲企業帳號代開 工程上更實用的做法是：先估算BDP，然後給出可觀測的上限。例如你預估RTT約100ms、帶寬目標約200Mbps，BDP約=0.1s * 200Mbps = 20Mb ≈ 2.5MB。那麼socket緩衝需要至少能支撐相應量級（具體換算到字節並考慮協定開銷）。

在不破壞可用性的情況下，常見調整方向包括：

• 提高net.core.rmem_max與net.core.wmem_max
• 提高net.ipv4.tcp_rmem與net.ipv4.tcp_wmem的最大值
• 必要時調整自動調整行為，使其更貼近高帶寬鏈路

3.2 拒絕誤解：tcp_window_scaling不用“瞎關”

在現代環境，TCP窗口縮放（window scaling）是常態。如果你遇到某些自帶模板把它關掉，可能會立刻限制窗口成長，導致吞吐上不去。一般情況下應確保窗口縮放保持啟用，並由緩衝配置提供足夠上限。

3.3 擁塞控制選型：不同演算法對“長肥管道”反應不同

騰訊雲企業帳號代開 海外場景通常丟包成因複雜：可能來自鏈路抖動，也可能是中間設備隊列溢出。因此擁塞控制策略需要兼顧吞吐與恢復速度。

工程上常見的選擇包括在Linux上使用不同的congestion control模組（例如CUBIC、BBR家族等）。選擇哪一個不是“照搬”，而是要看你的業務流模式：

• 若是短連線/短下載為主，擁塞控制在慢啟階段的行為更重要
• 若是長連線/大文件傳輸，擁塞控制的穩態維持與對丟包的恢復時間更重要
• 若是混合流量，應考慮公平性與與其他連線的互相影響

建議做法是：以同一套壓測腳本、同一套流量並行度，對比至少兩種演算法的吞吐曲線與RTT/重傳行為。不要只看“平均吞吐”，也要看抖動和尾延遲。

3.4 SACK、時間戳、以及重傳觸發：降低無效重傳

重傳是否頻繁，會直接侵蝕吞吐。你通常希望在丟包或亂序時，TCP能快速定位丟失段並選擇合適的重傳策略。

騰訊雲企業帳號代開 一些常見的檢查點：

• 是否啟用了SACK，讓接收端能更準確反饋失序段
• 時間戳選項是否會在某些場景帶來額外開銷（一般可接受），但要確保沒有被不當關閉
• RTO（重傳超時）與恢復機制是否符合你的鏈路波動特徵

如果你看到重傳率在特定時間段暴增，配合抓包/系統指標定位是“真的丟包”還是“應用讀寫造成的緩衝耗盡”，再決定要調的是TCP參數還是應用模型。

第四章：隊列與qdisc——把突發流量變成可承載的連續吞吐

騰訊雲企業帳號代開 4.1 net.core.netdev_max_backlog：軟中斷接收隊列的上限

在高吞吐場景，網卡接收後的資料會先進入內核緩衝與softnet隊列。若處理不及時，隊列會積壓，最終丟棄。這種丟棄不一定會像“明顯的網路丟包”那樣在統計中顯著體現，但會在應用吞吐上反映出來。

提高net.core.netdev_max_backlog通常能緩解突發接收造成的drop，但前提是CPU與中斷處理能跟上。否則隊列越大，延遲越高，只會把問題“往後拖”。

4.2 qdisc與隊列管理：避免在擁塞時被平均化處理吞噬

Linux的qdisc會影響排隊策略與丟棄行為。海外鏈路長RTT與抖動讓排隊控制更關鍵。某些隊列策略可能在突發時放大延遲，而某些則能更快丟棄低優先級流量，保護吞吐和延遲。

但這一塊容易踩坑：你不應該在沒有觀測的情況下把qdisc亂換。較穩妥的路徑是：先確定是否存在明顯隊列丟棄（例如查看介面丟包、錯誤計數、以及softnet drop），再選擇和服務特性匹配的隊列管理策略。

第五章：中斷親和與CPU資源——讓網卡把資料送到“對的地方”

5.1 RSS、多隊列與中斷分佈：吞吐常常卡在“搬運能力”

網卡通常支援多接收隊列（Receive Side Scaling, RSS）。若中斷分佈與CPU調度不合理，你會看到CPU某些核心負載很高，而其他核心閒著；或軟中斷在不合適的核上處理，導致延遲與drop。

因此，內核優化不只有參數，也包含“映射與親和性”的設定思路：

• 確認NIC隊列數是否與CPU核數/NUMA拓撲合理匹配
• 檢查中斷是否被集中在少數核心
• 對高吞吐服務，必要時做IRQ affinity綁核或調整中斷處理策略

在跨國環境里，這些問題更常被放大：因為流量更接近“長距離、長時間”的持續狀態，中斷處理的微小低效會長期累積成可觀的吞吐損失。

5.2 RPS/XPS：把處理從單核瓶頸中解放出來

RPS（Receive Packet Steering）與XPS（Transmit Packet Steering）可以在一定程度上把封包處理分散到多核，避免單核成為瓶頸。但這同樣有代價：上下文切換與cache miss可能增加。

最佳做法仍是觀測：看softnet的drop、看CPU分佈和上下文切換。當你確認接收側處理跟不上，RPS或許能改善；但若你已經被CPU cache miss或其他瓶頸困住，就不該盲目加大分散程度。

第六章：UDP與通用socket緩衝——把丟包率壓下去

6.1 提高rmem/wmem上限：讓socket有足夠“緩衝窗”

騰訊雲企業帳號代開 UDP吞吐受限的最直接原因是接收緩衝不足。當應用讀取不及時，內核緩衝滿了就丟包。對於長距離鏈路，丟包即使不高，也可能讓應用層重傳或前向糾錯成本上升，等效吞吐下降。

調整方向通常是：

• 提高net.core.rmem_max與net.core.wmem_max
• 提高應用或系統可用的socket緩衝（以實際程式讀寫行為為準）
• 對特定應用使用setsockopt提高緩衝，而不是只靠全域參數

6.2 檢查應用讀取模型：吞吐不是只靠緩衝撐

即便你把緩衝開到很大，如果應用處理單執行緒或事件迴圈太慢，丟包依舊會出現。此時你需要的是：更合理的併發模型、批量處理、或降低每包的處理成本。

內核參數只能把“緩衝期”延長，但不能替代應用的吞吐能力。

第七章：避免“看似提升實則惡化”的常見誤區

7.1 緩衝越大越好？忽略延遲與公平性會翻車

吞吐提升的同時，延遲可能惡化。對海外場景來說，長RTT本就拉高延遲底色，過大的緩衝會讓隊列在擁塞時被拉得更長。這會導致尾延遲（例如95/99分位）顯著上升。

更糟的是，對共享資源的環境，緩衝放大可能讓某些流量佔用隊列更久，影響同宿主或同節點其他業務。

7.2 只調一兩個參數：忽略互相制約的閉環

TCP的吞吐是一個閉環：丟包/延遲的反饋影響擁塞控制；擁塞控制影響窗口大小；窗口影響是否能填滿鏈路；隊列與qdisc又影響丟包發生的位置與方式。只調單點參數，常常會讓結果變得不穩定。

7.3 不做回歸測試：改完只看到“平均變好”，後面卻出問題

內核參數改動可能在特定並發度、特定時間段、特定資料特性下才顯現。工程上要建立回歸測試，包括：

• 延遲分位：至少監控P50/P95/P99
• 錯誤率與超時：TCP重置、應用超時、請求失敗率
• 資源：CPU、context switch、softnet drop

任何“平均吞吐變高但錯誤率也上升”的改動，都應視為未通過。

第八章：可落地的調參流程——從觀測到驗證的工程路徑

8.1 第一步：收集現狀快照（不要只盯吞吐數字）

建議在變更前記錄以下類型資訊：

• 介面統計：丟包、錯誤、重傳相關（用系統工具或介面計數）
• TCP狀態：重傳率、RTT樣本、擁塞窗口行為（可用對應診斷工具）
• 軟中斷與drop：softnet相關指標
• CPU與中斷：是否單核瓶頸

8.2 第二步：先用小步調整縮小範圍

不要一次性把所有上限翻倍。推薦順序：

• 先確定是否存在softnet/backlog相關drop：若有，優先處理netdev_max_backlog與中斷分佈
• 若丟包不明顯但窗口不成長：優先檢查tcp/wmem/rmem上限與擁塞控制行為
• 若是UDP主導：先調socket緩衝與應用讀取模型，再考慮系統上限

每次改動都要能回滾，最好做到“單變更可驗證”。

8.3 第三步：用對照測試證明收益，而不是感覺

至少做A/B對照：同流量、同並發、同時間段。吞吐提升可以用帶寬利用率或應用完成量來衡量。

同時要看是否引入新問題：延遲分位、重傳率、丟包率、CPU飽和度。只要有一項顯著惡化而沒有業務可接受的交換關係，就應回退或調整方向。

第九章：一個典型案例思路（不給“神參數”，給可推導的方法）

騰訊雲企業帳號代開 9.1 症狀：海外下載吞吐在中段平台後停滯，重傳率中等偏高

某海外節點承載大量下載/上傳，初始階段吞吐上來後很快進入平台期；同時觀測到TCP重傳率比預期高，但介面丟包計數不一定很夠“解釋”全部現象。這常見於：隊列延遲或擁塞控制過於保守，導致窗口成長不足。

工程團隊做法：

• 先核對socket緩衝上限是否能支撐BDP
• 檢查qdisc與隊列是否造成不必要排隊
• 確認擁塞控制是否與鏈路特性匹配

接著用小步方式增加TCP緩衝上限，並在擁塞控制上做對照。若延遲未惡化且重傳率下降或重傳分佈更集中，吞吐平台期通常會被拉高。

9.2 症狀：高併發下吞吐抖動，softnet drop上升，CPU某些核飆升

另一類常見症狀是：吞吐不是“上不去”，而是“時高時低”。softnet drop上升顯示接收處理延遲或堆積。此時就不應首先大幅調TCP緩衝，而應：

• 檢查netdev_max_backlog是否過低
• 優化中斷親和與RSS隊列分配
• 評估是否需要RPS/XPS把處理分散開

在實施中通常會看到：一旦drop降低，吞吐抖動明顯改善，且重傳/應用超時也隨之下降。

第十章：長期運維與風險控制——讓優化能“活下去”

10.1 參數管理：用版本化與分批灰度

內核參數屬於高影響配置。建議把變更納入版本管理：每次調整記錄動機、涉及參數、目標指標與驗證結果。對於大規模節點，採用灰度方式，先在少量節點觀測，通過後再推廣。

10.2 可觀測性：把“能不能更快”變成“能不能更穩”

吞吐提升很容易被看到，但穩定性與延遲退化常常滯後。建議持續監控：

• 騰訊雲企業帳號代開 延遲分位與超時率
• 丟包/重傳（或等效指標）
• CPU與softnet drop

此外，建立“回歸事件”的自動告警閾值，能讓回退更及時。

10.3 灰盒與黑盒：內核調優要能被“解釋”

很多內核調優在工程上會陷入“玄學”。要避免這種情況，你應該能用觀測數據解釋每次調整：

• 為什麼調緩衝：因為窗口或drop證據存在
• 為什麼調擁塞控制：因為重傳/RTT反饋顯示保守或不匹配
• 為什麼調隊列或中斷：因為softnet drop或CPU分佈證據明確

當解釋成立，調優就不只是“碰運氣”，而是可複用的工程方法。

騰訊雲企業帳號代開 結語：提升吞吐不是追一個參數，而是優化整個閉環

面向騰訊雲海外伺服器的吞吐提升，內核優化的價值不在於找到某個“萬能係數”，而在於建立一套可驗證的閉環：用可觀測指標定位瓶頸，選擇對應層面的調整方向（TCP緩衝/擁塞、隊列管理、接收處理與中斷分佈、UDP緩衝與應用讀寫），最後用A/B對照與回歸測試證明收益。

只要遵循這套方法，吞吐提升就會從“偶然有效”變成“在特定條件下穩定有效”，並能在長期運維中保持可控的風險與可持續的效能收益。