跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

buttercup發表於2020-10-14

背景

公司近期開通了一條訪問美國機房的 1G 專線，用於提供行情資料備源，並基於 TCP 建立了一套資料傳輸服務。上線後發現一個嚴重的問題：應用程式傳送佇列中的資料大量積壓，最終導致程式 OOM Kill，但觀察監控發現專線頻寬利用率只有 50% - 60%。

經過溝通，發現運維同事當時使用 iperf3 測試專線頻寬使用的是 UDP 協議，於是在運維同事協助下使用 TCP 進行二次測試，發現了比較嚴重的問題：

在國內機房使用 iperf3 測試單個 socket 流量，在同機房內部（1G交換機）可以達到的最大頻寬約為 110Mb（對照組）
在跨境專線使用 iperf3 測試單個 socket 流量，發現極不穩定

Connecting to host US_NY_VM_01, port 5001
[  4] local HK_QW_VM_01 port 58341 connected to US_NY_VM_01 port 5001
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 KBytes   892 Kbits/sec    0   42.4 KBytes       
[  4]   1.00-2.00   sec  1.04 MBytes  8.75 Mbits/sec    0    324 KBytes       
[  4]   2.00-3.00   sec  5.45 MBytes  45.7 Mbits/sec    0   1.52 MBytes       
[  4]   3.00-4.00   sec  7.50 MBytes  62.9 Mbits/sec    6   1.88 MBytes       
[  4]   4.00-5.00   sec  10.0 MBytes  83.9 Mbits/sec    0   2.10 MBytes       
[  4]   5.00-6.00   sec  11.2 MBytes  94.4 Mbits/sec    0   2.27 MBytes       
[  4]   6.00-7.00   sec  8.75 MBytes  73.4 Mbits/sec    0   2.38 MBytes       
[  4]   7.00-8.00   sec  12.5 MBytes   105 Mbits/sec    0   2.48 MBytes       
[  4]   8.00-9.00   sec  12.5 MBytes   105 Mbits/sec    0   2.56 MBytes       
[  4]   9.00-10.00  sec  11.2 MBytes  94.4 Mbits/sec    0   2.62 MBytes       
[  4]  10.00-11.00  sec  11.2 MBytes  94.4 Mbits/sec    0   2.65 MBytes       
[  4]  11.00-12.00  sec  12.5 MBytes   105 Mbits/sec    3   1.93 MBytes       
[  4]  12.00-13.00  sec  7.50 MBytes  62.9 Mbits/sec   92   1.42 MBytes       
[  4]  13.00-14.00  sec  6.23 MBytes  52.3 Mbits/sec    0   1.51 MBytes       
[  4]  14.00-15.00  sec  7.50 MBytes  62.9 Mbits/sec    0   1.58 MBytes       
[  4]  15.00-16.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.63 MBytes       
[  4]  16.00-17.00  sec  6.25 MBytes  52.4 Mbits/sec    0   1.66 MBytes       
[  4]  17.00-18.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.68 MBytes       
[  4]  18.00-19.00  sec  7.50 MBytes  62.9 Mbits/sec    0   1.69 MBytes       
[  4]  19.00-20.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.69 MBytes       
[  4]  20.00-21.00  sec  6.25 MBytes  52.4 Mbits/sec    0   1.69 MBytes       
[  4]  21.00-22.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.69 MBytes       
[  4]  22.00-23.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.70 MBytes       
[  4]  23.00-24.00  sec  6.25 MBytes  52.4 Mbits/sec    0   1.71 MBytes       
[  4]  24.00-25.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.73 MBytes       
[  4]  25.00-26.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.77 MBytes       
[  4]  26.00-27.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.82 MBytes       
[  4]  27.00-28.00  sec  7.50 MBytes  62.9 Mbits/sec    0   1.88 MBytes       
[  4]  28.00-29.00  sec  10.0 MBytes  83.9 Mbits/sec    0   1.99 MBytes       
[  4]  29.00-30.00  sec  10.0 MBytes  83.9 Mbits/sec    0   2.12 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec   249 MBytes  69.6 Mbits/sec  101             sender
[  4]   0.00-30.00  sec   248 MBytes  69.3 Mbits/sec                  receiver

iperf Done.

從上圖可以觀察到存在以下問題：

網路狀況不穩定，低速率時也會偶爾會出現 TCP 重傳
傳輸速率波動較大，無法長時間維持在最佳的 105M 頻寬，導致頻寬利用率低

長肥管道 (LFN)

跨境專線具有較長的往返時間RTT與較高頻寬 Bandwidth，這類具有大管道容量 BDP = RTT * Bandwidth 的網路我們稱之為長肥管道LFN (Long Fat Networks)。

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

由於 LFN 的 RTT 較長，因此一個包從傳送到接收到 ACK 需要經歷的時間比普通的網路更長。由於 TCP 滑動視窗的特性，網路會存在較長的空閒時間，導致網路的利用率不高。這篇文章中的動畫很好的展示了這一點，推薦觀看。因此一個簡單的方案就是：增大在途未確認資料量amount inflight，使其填滿整個管道。

決定在途資料量的因素有以下幾個方面：

傳送端：擁塞視窗大小 cwnd 以及傳送緩衝大小
接收端：接收視窗大小 rwnd 以及接收緩衝大小

由於 cwnd 和 rwnd 大小是系統根據網路狀況進行自適應調整的，無法無法直接干預。因此決定先嚐試調整 TCP 緩衝配置，觀察傳輸效果是否有提升。

TCP 緩衝調參

首先計算管道容量：已知專線頻寬為 1Gb，通過 ping 檢視專線 RTT 約為 210ms，據此計算專線 BDP 約為 25MB。

做過 TCP 開發的同學應該都熟悉 SO_RECVBUF 和 SO_SENDBUF 這兩個 socekt 選項，我們可以通過這兩個引數來設定接收與傳送緩衝區的大小。如果我們在建立連線 TCP 時指定了這兩個引數，那麼作業系統就不會使用一個固定的緩衝區大小，而不再會根據網路進行動態調整，因此這兩個選項要慎用。

然而當指定引數過後，會發現實際的 TCP 緩衝區大小與引數有所出入。這是什麼原因造成的呢？首先來看幾個重要的核心引數：

[lhop@localhost ~]$ sysctl -a  2>&1 | egrep 'core.wmem_max|core.rmem_max|ipv4.tcp_wmem|ipv4.tcp_rmem|tcp_adv_win_scale|tcp_moderate_rcvbuf'
net.core.wmem_max = 124928
net.core.rmem_max = 124928
net.ipv4.tcp_wmem = 4096	16384	4194304
net.ipv4.tcp_rmem = 4096	87380	4194304
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_moderate_rcvbuf = 1

net.ipv4.tcp_wmem 與 net.ipv4.tcp_rmem 是單個 tcp socket 緩衝區的最小值min、預設值default、最大值max，單位為位元組。
net.core.wmem_max 與 net.core.rmem_max 是單個 socket 所能使用的緩衝區大小上限，單位為位元組。該引數的優先順序高於 tcp_wmem 與 tcp_rmem 的最大值，調整引數時需要注意兩者的對應關係。
net.ipv4.tcp_moderate_rcvbuf 是否允許作業系統動態調整 tcp 緩衝。開啟後，系統會根據當前可用資源對接收緩衝進行動態調整，此時接收緩衝的大小會在 tcp_rmem 最大與最小值之間浮動。當 tcp socket 連線較多時，可以系統會酌情減少每個連線的快取記憶體，避免資源耗盡。
net.ipv4.tcp_adv_win_scale 是單個 tcp socket 接收緩衝預留給應用的比例。tcp 的接收緩衝可以分為兩部分，一部分是用作接收視窗儲存未確認報文，另一部分則是快取未被應用程式讀取的已確認報文，因此需要預留 1/2^{tcp_adv_win_scale} 記憶體空間給未讀報文。這也是 tcp_rmem 的初始預設值比 tcp_wmem 大的原因。

根據 sysctl 給出的結果，我們需要調整有：

net.core.wmem_max = BDP = 26214400
net.core.rmem_max = BDP/(1-1/2^{tcp_adv_win_scale}) = 34952000

[lhop@localhost ~]$ cat <<EOF>> /etc/sysctl.conf
net.core.wmem_max = 26214400
net.core.rmem_max = 34952000
net.ipv4.tcp_wmem = 4096 87380 26214400
net.ipv4.tcp_rmem = 4096 87380 34952000
EOF
sysctl -p

調整後重新使用 ipref3 進行測試，發現測試結果基本上沒有變化。基本可以斷定：快取不足不是造成 TCP 流量瓶頸的主因。

從前面的 iperf3 結果中可以看出，當出現重新傳時，擁塞視窗急劇縮小，最終導致了傳輸速度的下降。決定擁塞視窗大小的就是擁塞控制演算法，因此我們將目光轉移到擁塞演算法上。

擁塞控制

TCP擁塞控制演算法的目的可以簡單概括為：公平與效率。

當網路擁塞時，TCP 連線降低傳輸速率，減少由於競爭導致的網路資源浪費。
當網路空閒時，TCP 連線提升傳輸速率，提高通訊效率。

根據實現方式不同，擁塞演算法可以分為兩類：基於丟包反饋 與 基於延時策略。
其最終目的是找到一個適合當前網路狀況的最佳擁塞視窗 W_best。

基於丟包反饋

基於丟包反饋的擁塞演算法是目前應用最廣泛且較為成熟的演算法。

Linux 系統中預設的擁塞演算法 reno 與 cubic 都屬於這類：

[lhop@localhost ~]$ sysctl -a  2>&1 | egrep 'tcp_available_congestion_control|tcp_congestion_control'
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_available_congestion_control = cubic reno

Reno 演算法

reno 是最經典的擁塞演算法，其核心是基於 加性增窗/乘性減窗 AIMD 的反饋控制：當檢測到通道擁塞時，擁塞視窗會呈指數級快速減小（減少效能下降），然後視窗緩慢地線性增長（避免再次擁塞）。
演算法流程如下圖所示：

然而加性增窗的特性決定了 reno 存在一個明顯缺點：如果演算法進入擁塞避免與快速恢復狀這兩個階段時，每經過一個 RTT 才會將視窗大小加1，假設我們鏈路狀況好，但如果RTT很長的話，reno 需要很長時間才能達到 W_best。實際上受限於丟包率，reno 的另一個典型問題就是還沒等 cwnd 增長到 W_best，就已經發生丟包並削減cwnd了。

BIC 演算法

為了提高 TCP 在 LFN 上的傳輸效率，後續提出了 bic 擁塞演算法：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

bic 也採用乘法減小的方式減小視窗，並引入一個引數 β 作為減窗因子。若發生丟包時的 cwnd 大小為 W_max，則減小後的視窗大小為 W = β * W_max。

bic 假定 W < W_best < W_max，因此在恢復階段 bic 是一個變速過程：

在遠離 W_max 時，快速增大視窗，使 cwnd 儘快恢復至 W_best（對應圖中的 Addtitive Increase 過程）
在靠近 W_max 時，緩慢增大視窗，使 cwnd 儘可能長期保持在 W_best 附近（對應圖中的 Binary Search 過程）
當到達 W_max 時，如果仍未發生丟包，那麼網路是空閒的，應該積極地去搶佔網路資源。此時 TCP 連線會嘗試增加擁塞視窗大小，並且增加速度越來越快，直到發現新的 W_max 為止（對應圖中的 Max Probing 過程）

CUBIC 演算法

然而在 RTT 較小的非 LFN 環境中，bic 的增長策略顯得過於激進，會搶佔其他其他擁塞演算法的 TCP 連線資源。後來，該演算法的作者提出了普適性更好的 cubic 演算法。
為了減少 RTT（受物理裝置影響）對演算法的影響，cubic 會記錄最近一次發生網路擁塞的時間 t_reduce，距離最近一次擁塞發生的時間可以表示為 t = t_now - t_reduce。

cubic 的減窗與增窗過程可以簡化為一個的與時間 t 為自變數的視窗增長函式 W(t)：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

\[W(t) = C(t-K)^3 + W_{max} \\ K=\sqrt[3]{\frac{W_{max}\beta}{C}}\\ \beta = 0.2 \quad C = 0.4 \]

cubic 的視窗增長函式僅僅取決於與擁塞事件的時間間隔，從而將視窗增長獨立於網路的時延RTT，因而能夠在多條共享瓶頸鍊路的 TCP 連線之間保持良好的RTT公平性。

cubic 與 reno 的擁塞視窗行為比較：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

cubic 保證了 TCP 儘可能的長時間保持在 W_best，從而避免了 reno 演算法漫長增窗過程導致傳輸效率低下的問題。

Bufferbloat 現象

隨著記憶體越來越便宜，TCP 鏈路上的網路裝置的 Buffer 傾向於配置的特別大。但這一做法對於基於丟包反饋的 TCP 擁塞演算法相當不友好：

傳送方無法及時感知到擁塞：當資料開始在佇列排隊時，鏈路已經出現擁塞，但因為 Buffer 很大，資料包不會被丟棄，傳送端根本無法感知到擁塞的發生。
無效的資料包占用網路資源：等真的出現丟包時候，重傳的包放在鏈路上還得等之前積壓在 Buffer 的資料包都送達接收端後才能被處理，對網路網路資源造成了浪費。
接收方隊頭阻塞並丟棄資料：接收端在等待重傳的過程中，如果 Buffer 不足夠大，大量資料送達接收端後都會被丟棄，無形中增加了重傳率，極大增加傳輸延遲。

Bufferbloat 造成的高重傳率，無形中增加了網路傳輸的延遲，並且還會導致網路傳輸不穩定，有時候延遲很小，有的時候延遲又很大。這一表現正好符合我們之前的 iperf3 的測試結果：

較長的 RTT 導致網路非擁塞時頻繁丟包，基於丟包反饋的擁塞演算法的視窗會比較小，對頻寬的利用率很低，吞吐量下降很明顯，但是實際上網路負載並不高。
在網路擁塞但無丟包情況下演算法一直加窗，丟包事件很快就發生了，乘性減窗使傳送速率迅速降低，造成整個網路的瞬時抖動性，總體呈現較大的鋸齒狀波動。

基於時延策略

下圖是 TCP 傳輸鏈路上某個快取佇列，根據網路狀況變化，佇列可能處於以下 3 種狀態之一：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

State 1: 網路空閒，沒有排隊的資料。網路延遲最低
State 2: 網路佔滿，資料開始排隊，網路延遲開始增大
State 3: 佇列溢位，網路出現丟包

cubic 的擁塞避免策略是讓擁塞視窗儘可能保持在上一個 W_max 附近，即 State 2 與 State 3 之間的狀態。相當於儘可能把鏈路資源（線路頻寬+中繼Buffer）佔滿，也因此造成了較高的網路延遲。

而理想狀態是維持在 State 1 和 State 2 之間，即沒有出現排隊導致延遲升高，又能完全佔滿鏈路頻寬傳送資料，高效且低延遲。為了實現這一點，需要使用 基於時延策略 的擁塞避免演算法：

監控每個資料包的 RTT，先盡力增大 CWND 提高傳送率：

速率提高後 RTT 不變（無需排隊），則此時鏈路處於 State 1，可以繼續提高傳送速率
速率提高後 RTT 升高（開始排隊），說明此時鏈路從 State 1 切換到了 State 2，需要降低傳送效率，使其恢復到 State 1

最優控制點

下面通過一張圖直觀地感受一下網路擁塞的變化過程：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

RTprop round-trip propagation time：鏈路固有的傳播時延
BtlBw bottleneck bandwidth：鏈路的頻寬上限
Amount Inflight：在途資料量
Delivery Rate：資料送達速率

橫向將網路狀態分為 3 個階段：

app limited：效能瓶頸是應用本身（網路空閒）
bandwidth limited：效能瓶頸是網路頻寬（網路擁塞）
buffer limit：效能瓶頸是中繼 buffer 容量（網路耗盡）

縱向兩幅圖分別描繪了網路延遲與吞吐量的變化：

上圖展示了 RTT 與 在途資料量 的之間的關係：
- app limited：網路空閒時，RTT 大小僅取決於 線路 RTprop
- bandwidth limited：網路擁塞時，RTT 大小取決於 網路頻寬 BtlBw 與 buffer 資料量（BtlBw限制了佇列的消費速率）
- buffer limit：網路資源耗盡，開始丟包
下圖展示了 送達率 與 在途資料量 的之間的關係：
- app limited：網路空閒時，送達速率取決於 應用傳送速率 與 線路 RTprop（RTprop限制了ACK響應速率）
- bandwidth limited：網路擁塞時，送達速率僅取決於 網路頻寬 BtlBw
- buffer limit：網路資源耗盡，開始丟包

注意圖中的兩個點：

最優點optimum operating point is here：理想的擁塞演算法應該將在途資料量控制在 BDP 附近。
丟包點loss-based congestion control opreates here：基於丟包的擁塞演算法將在途資料量控制在 BDP + BtlneckBufSize 附近。

在最優點附近，傳送速率達到 BltBw，從而佔滿鏈路頻寬，最高效的利用頻寬；在途資料量不能超過鏈路的 BDP = BtlBw * RTprop，從而有最優的延遲。

當鏈路上 Buffer 較小時，最優點與丟包點十分接近，此時基於丟包的演算法延遲就不會很高。當鏈路上 Buffer 很大時，基於丟包的擁塞演算法就容易導致將 Buffer 佔滿，就容易出現 BufferBloat。

反過來說，如果鏈路的 BtlBw 與 RTprop 已知，那麼擁塞控制演算法就可以根據這兩個值，計算得出最優的傳送速率 BDP。這也為擁塞演算法的開發提供了新的思路。

BBR 演算法

bbr 是 Google 開源的擁塞演算法，其目的就是為了解決基於丟包的擁塞控制演算法存在的弊端：

在 Buffer 較大的鏈路中，容易造成 BufferBloat，增加了傳輸延遲
在 Buffer 較小的長距離鏈路中，會對突發流量造成的丟包反應過度，導致吞吐量極低

其核心理念就是建立一套探測模型，動態評估鏈路上 BtlBw 與 RTprop 的變化情況：

將最近一個時間視窗 W_R（一般是在幾十秒到幾分鐘之間）內監控到的 RTT 最小值作為近似的 RTprop
將最近一個時間視窗 W_B（一般是 10 個 RRT）內監控到的 送達率 最大值作為近似的 BtlBw

\[\hat{RT_{prop}} = min(RTT_t) \quad \forall t \in [T-W_R,T] \\ \hat{BltBw} = max(deliveryRate_t) \quad \forall t \in [T-W_B,T] \]

bbr 演算法可以分為 4 個階段：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

StartUp

剛啟動時，BBR 以指數形式增大傳送速率，每經過一個 RTT 傳送速率會增大 $2/ln(2)$ 倍，從而保證能夠在 O(log(BDP)) 個 RRT 內找到 BtlBw。當bbr發現增大速率後，送達率沒有明顯上升時，會認為鏈路上的 Buffer 已經開始積壓，於是認為已經探測到 BtlBw。

Drain

完成 BtlBw 探測後，會將傳送速率增速調整為 $ln(2)/2$，等待鏈路上的佇列積壓資料清空，避免發生丟包。 bbr會監控在途資料量 Inflight，當 Inflight 與估計的 BDP 接近時，會進入穩定狀態。

ProbeBW

經過 StartUp 和 Drain 之後，傳送方進入穩定狀態進行資料的傳送。由於網路頻寬的變化要比RTT更為頻繁，因此 ProbeBW 階段也是bbr的主要階段。

ProbeBW 狀態分為兩個週期：

增週期：提高傳送率到穩定期的 1.25 倍，直到出現丟包或 Inflight 達到 1.25 倍 BDP 為止。如果觀察到延遲升高且送達率不變，說明鏈路上頻寬沒有變化且產生了佇列堆積。
減週期：降低傳送率到穩定期的 0.75 倍，等待一個 RTprop 或 Inflight低於 BDP 為止。讓鏈路上在增週期出現堆積的佇列清空。

ProbeRTT

前面 3 個階段在執行過程中，都可能進入 ProbeRTT 階段。如果bbr執行了很長時間一直沒有更新 RTprop 時，會進入 ProbeRTT 狀態並試圖探測到更小 RTprop。探測完成之後再根據最新資料來確定進入 StartUp 還是 ProbeBW 階段。

cubic、reno 與 bbr 的擁塞視窗行為比較：

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

bbr 保證了 TCP 儘可能的長時間保持對網路的 100% 的利用率，規避了 cubic 過分佔用網路資源引起 Bufferbloat 現象。

優化效果

經過前面的分析，發現 bbr 演算法對於正好能夠解決之前 ipref3 測試中發現的問題。於是跟運維同時協商將 CentOS6 升級為高核心版本的 CentOS7，並開啟 bbr 演算法：

[lhop@localhost ~]$ sysctl -a  2>&1 | egrep 'tcp_available_congestion_control|tcp_congestion_control|default_qdisc'
net.core.default_qdisc = fq
net.ipv4.tcp_available_congestion_control = reno cubic bbr
net.ipv4.tcp_congestion_control = bbr

再次使用 iperf3 進行測試，結果如下：

Connecting to host US_NY_VM_01, port 5001
[  4] local HK_QW_VM_01 port 58341 connected to US_NY_VM_01 port 5001
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   740 KBytes  6.06 Mbits/sec    0   97.6 KBytes       
[  4]   1.00-2.00   sec  4.17 MBytes  35.0 Mbits/sec    0   1.89 MBytes       
[  4]   2.00-3.00   sec  12.5 MBytes   105 Mbits/sec    0   8.76 MBytes       
[  4]   3.00-4.00   sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]   4.00-5.00   sec  11.2 MBytes  94.4 Mbits/sec    3   8.79 MBytes       
[  4]   5.00-6.00   sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]   6.00-7.00   sec  15.0 MBytes   126 Mbits/sec    0   8.79 MBytes       
[  4]   7.00-8.00   sec  12.5 MBytes   105 Mbits/sec    0   8.79 MBytes       
[  4]   8.00-9.00   sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]   9.00-10.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  10.00-11.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  11.00-12.00  sec  12.5 MBytes   105 Mbits/sec    0   8.79 MBytes       
[  4]  12.00-13.00  sec  15.0 MBytes   126 Mbits/sec    0   8.79 MBytes       
[  4]  13.00-14.00  sec  8.75 MBytes  73.4 Mbits/sec    0   8.79 MBytes       
[  4]  14.00-15.00  sec  15.0 MBytes   126 Mbits/sec    0   8.79 MBytes       
[  4]  15.00-16.00  sec  12.5 MBytes   105 Mbits/sec    0   8.79 MBytes       
[  4]  16.00-17.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  17.00-18.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  18.00-19.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  19.00-20.00  sec  12.5 MBytes   105 Mbits/sec    0   8.79 MBytes       
[  4]  20.00-21.00  sec  15.0 MBytes   126 Mbits/sec    0   8.79 MBytes       
[  4]  21.00-22.00  sec  13.8 MBytes   115 Mbits/sec    0   8.79 MBytes       
[  4]  22.00-23.00  sec  12.5 MBytes   105 Mbits/sec    0   8.79 MBytes       
[  4]  23.00-24.00  sec  11.2 MBytes  94.4 Mbits/sec    3   8.79 MBytes       
[  4]  24.00-25.00  sec  11.2 MBytes  94.4 Mbits/sec    0   7.44 MBytes       
[  4]  25.00-26.00  sec  11.2 MBytes  94.4 Mbits/sec    0   6.30 MBytes       
[  4]  26.00-27.00  sec  12.5 MBytes   105 Mbits/sec    0   6.30 MBytes       
[  4]  27.00-28.00  sec  11.2 MBytes  94.4 Mbits/sec    0   6.30 MBytes       
[  4]  28.00-29.00  sec  12.5 MBytes   105 Mbits/sec    0   6.30 MBytes       
[  4]  29.00-30.00  sec  11.2 MBytes  94.4 Mbits/sec    0   6.30 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec   365 MBytes   102 Mbits/sec    6             sender
[  4]   0.00-30.00  sec   364 MBytes   102 Mbits/sec                  receiver

iperf Done.

觀察測試結果發現網路的吞吐量明顯上升，並且重傳率保持在一個較低的水平。

並且擁塞視窗變化也更穩定，不再出現之前劇烈波動的情況。

使用 10 個 socket 基本上可以跑滿整個專線，優化目標達成。

參考資料與圖片來源

據說這款軟體能解決98%以上的跨境資料傳輸問題
2020-03-26
TCP傳輸協議詳解
2019-04-08
TCP協議
Oracle Pipe解決實時輸出問題
2013-11-07
Oracle
Java傳輸檔案使用Base64優化傳輸速率。
2020-10-09
Java優化
1 Million TCP Connection 問題解決
2011-03-23
TCP
關於印度跨境資料傳輸，印度放寬了跨境資料傳輸
2023-03-07
鐳速-跨國車企資料高速、安全跨境傳輸解決方案
2023-01-30
TCP通訊之經典問題解決
2024-08-21
TCP
Java 使用 TCP 和 UDP 傳輸檔案
2013-12-23
JavaTCPUDP
優化-mysql子查詢索引失效問題解決
2020-11-05
優化MySql索引
TCP可靠傳輸原理
2021-09-12
TCP
為實現跨境檔案高速傳輸，鐳速傳輸都用了哪些技術？
2020-09-27
為實現跨境檔案高速傳輸，鐳速傳輸都用了哪些技術
2023-02-14
TCP 粘包 - 拆包問題及解決方案
2021-10-21
TCP
cat 輸出亂碼問題解決
2021-03-30
base64碼通過http傳輸 +號變空格問題解決
2020-04-05
HTTP
使用with as優化sql解決filter
2013-04-06
優化SQLFilter
Android如何實現TCP和UDP傳輸
2015-03-16
AndroidTCPUDP
Spark效能優化的10大問題及其解決方案
2016-03-14
Spark優化
數值最優化—優化問題的解(二)
2020-09-24
優化
遺傳演算法解決函式最佳化問題
2022-12-31
演算法函式
詳說TCP重傳問題的排查思路與實踐
2020-01-04
TCP
傳輸軟體如何幫助外貿人解決檔案傳輸難題？
2020-03-05
iOS9.3.4仍未解決藍芽傳輸問題：已存在8個月
2016-08-09
iOS藍芽
實用TCP協議（2）：TCP 引數優化
2022-03-07
TCP協議優化
Swoole - TCP流資料邊界問題解決方案
2020-05-19
TCP
跨境檔案傳輸換上鐳速傳輸，看看能提速多少？
2020-10-27
使用 TCP 時序圖解釋 BBR 擁塞控制演算法的幾個細節
2017-05-18
TCP時序圖圖解演算法
Shiro效能優化：解決Session頻繁讀寫問題
2020-09-24
優化Session
踩坑CBO，解決那些坑爹的SQL優化問題
2017-06-12
SQL優化
MyEclipse8.5優化，解決卡死無響應問題
2013-06-08
Eclipse優化
跨境電商ERP能解決的那些問題
2022-11-15
用python實現TCP協議傳輸功能
2020-09-30
PythonTCP協議
Netty中使用MessagePack時的TCP粘包問題與解決方案
2021-09-09
NettyTCP
ajax使用url傳遞中文引數亂碼問題解決
2017-02-10
stream不能實時傳送standby redo log問題的解決
2012-02-13
TCP/IP 通訊傳輸流
2019-05-08
TCP
TCP傳輸資料長度
2024-04-17
TCP

跨境 TCP 傳輸優化實錄 — 使用 BBR 解決 LFN 問題

背景

長肥管道 (LFN)

TCP 緩衝調參

擁塞控制

基於丟包反饋

Reno 演算法

BIC 演算法

CUBIC 演算法

Bufferbloat 現象

基於時延策略

最優控制點

BBR 演算法

StartUp

Drain

ProbeBW

ProbeRTT

優化效果

參考資料與圖片來源

相關文章