背景
公司近期開通了一條訪問美國機房的 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)
。
由於 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/2tcp_adv_win_scale 記憶體空間給未讀報文。這也是tcp_rmem
的初始預設值比tcp_wmem
大的原因。
根據 sysctl 給出的結果,我們需要調整有:
- net.core.wmem_max = BDP = 26214400
- net.core.rmem_max = BDP/(1-1/2tcp_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 連線提升傳輸速率,提高通訊效率。
根據實現方式不同,擁塞演算法可以分為兩類:基於丟包反饋 與 基於延時策略。
其最終目的是找到一個適合當前網路狀況的最佳擁塞視窗 Wbest。
基於丟包反饋
基於丟包反饋的擁塞演算法是目前應用最廣泛且較為成熟的演算法。
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
需要很長時間才能達到 Wbest。實際上受限於丟包率,reno
的另一個典型問題就是還沒等 cwnd 增長到 Wbest,就已經發生丟包並削減cwnd了。
BIC 演算法
為了提高 TCP 在 LFN 上的傳輸效率,後續提出了 bic
擁塞演算法:
bic
也採用乘法減小的方式減小視窗,並引入一個引數 β 作為減窗因子。若發生丟包時的 cwnd 大小為 Wmax,則減小後的視窗大小為 W = β * Wmax。
bic
假定 W < Wbest < Wmax,因此在恢復階段 bic
是一個變速過程:
- 在遠離 Wmax 時,快速增大視窗,使 cwnd 儘快恢復至 Wbest(對應圖中的
Addtitive Increase
過程) - 在靠近 Wmax 時,緩慢增大視窗,使 cwnd 儘可能長期保持在 Wbest 附近(對應圖中的
Binary Search
過程) - 當到達 Wmax 時,如果仍未發生丟包,那麼網路是空閒的,應該積極地去搶佔網路資源。此時 TCP 連線會嘗試增加擁塞視窗大小,並且增加速度越來越快,直到發現新的 Wmax 為止(對應圖中的
Max Probing
過程)
CUBIC 演算法
然而在 RTT 較小的非 LFN 環境中,bic
的增長策略顯得過於激進,會搶佔其他其他擁塞演算法的 TCP 連線資源。後來,該演算法的作者提出了普適性更好的 cubic
演算法。
為了減少 RTT(受物理裝置影響)對演算法的影響,cubic
會記錄最近一次發生網路擁塞的時間 treduce,距離最近一次擁塞發生的時間可以表示為 t = tnow - treduce。
cubic
的減窗與增窗過程可以簡化為一個的與時間 t 為自變數的視窗增長函式 W(t):
cubic
的視窗增長函式僅僅取決於與擁塞事件的時間間隔,從而將視窗增長獨立於網路的時延RTT,因而能夠在多條共享瓶頸鍊路的 TCP 連線之間保持良好的RTT公平性。
cubic
與 reno
的擁塞視窗行為比較:
cubic
保證了 TCP 儘可能的長時間保持在 Wbest,從而避免了 reno
演算法漫長增窗過程導致傳輸效率低下的問題。
Bufferbloat 現象
隨著記憶體越來越便宜,TCP 鏈路上的網路裝置的 Buffer 傾向於配置的特別大。但這一做法對於基於丟包反饋的 TCP 擁塞演算法相當不友好:
- 傳送方無法及時感知到擁塞:當資料開始在佇列排隊時,鏈路已經出現擁塞,但因為 Buffer 很大,資料包不會被丟棄,傳送端根本無法感知到擁塞的發生。
- 無效的資料包占用網路資源:等真的出現丟包時候,重傳的包放在鏈路上還得等之前積壓在 Buffer 的資料包都送達接收端後才能被處理,對網路網路資源造成了浪費。
- 接收方隊頭阻塞並丟棄資料:接收端在等待重傳的過程中,如果 Buffer 不足夠大,大量資料送達接收端後都會被丟棄,無形中增加了重傳率,極大增加傳輸延遲。
Bufferbloat 造成的高重傳率,無形中增加了網路傳輸的延遲,並且還會導致網路傳輸不穩定,有時候延遲很小,有的時候延遲又很大。這一表現正好符合我們之前的 iperf3 的測試結果:
- 較長的 RTT 導致網路非擁塞時頻繁丟包,基於丟包反饋的擁塞演算法的視窗會比較小,對頻寬的利用率很低,吞吐量下降很明顯,但是實際上網路負載並不高。
- 在網路擁塞但無丟包情況下演算法一直加窗,丟包事件很快就發生了,乘性減窗使傳送速率迅速降低,造成整個網路的瞬時抖動性,總體呈現較大的鋸齒狀波動。
基於時延策略
下圖是 TCP 傳輸鏈路上某個快取佇列,根據網路狀況變化,佇列可能處於以下 3 種狀態之一:
- State 1: 網路空閒,沒有排隊的資料。網路延遲最低
- State 2: 網路佔滿,資料開始排隊,網路延遲開始增大
- State 3: 佇列溢位,網路出現丟包
cubic
的擁塞避免策略是讓擁塞視窗儘可能保持在上一個 Wmax 附近,即 State 2 與 State 3 之間的狀態。相當於儘可能把鏈路資源(線路頻寬+中繼Buffer)佔滿,也因此造成了較高的網路延遲。
而理想狀態是維持在 State 1 和 State 2 之間,即沒有出現排隊導致延遲升高,又能完全佔滿鏈路頻寬傳送資料,高效且低延遲。為了實現這一點,需要使用 基於時延策略 的擁塞避免演算法:
- 速率提高後 RTT 不變(無需排隊),則此時鏈路處於 State 1,可以繼續提高傳送速率
- 速率提高後 RTT 升高(開始排隊),說明此時鏈路從 State 1 切換到了 State 2,需要降低傳送效率,使其恢復到 State 1
最優控制點
下面通過一張圖直觀地感受一下網路擁塞的變化過程:
- 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 的變化情況:
- 將最近一個時間視窗 WR(一般是在幾十秒到幾分鐘之間)內監控到的 RTT 最小值作為近似的 RTprop
- 將最近一個時間視窗 WB(一般是 10 個 RRT)內監控到的 送達率 最大值作為近似的 BtlBw
bbr
演算法可以分為 4 個階段:
StartUp
bbr
發現增大速率後,送達率沒有明顯上升時,會認為鏈路上的 Buffer 已經開始積壓,於是認為已經探測到 BtlBw。
Drain
bbr
會監控在途資料量 Inflight,當 Inflight 與估計的 BDP 接近時,會進入穩定狀態。
ProbeBW
bbr
的主要階段。
ProbeBW 狀態分為兩個週期:
- 增週期:提高傳送率到穩定期的 1.25 倍,直到出現丟包或 Inflight 達到 1.25 倍 BDP 為止。如果觀察到延遲升高且送達率不變,說明鏈路上頻寬沒有變化且產生了佇列堆積。
- 減週期:降低傳送率到穩定期的 0.75 倍,等待一個 RTprop 或 Inflight低於 BDP 為止。讓鏈路上在增週期出現堆積的佇列清空。
ProbeRTT
bbr
執行了很長時間一直沒有更新 RTprop 時,會進入 ProbeRTT 狀態並試圖探測到更小 RTprop。探測完成之後再根據最新資料來確定進入 StartUp 還是 ProbeBW 階段。
cubic
、reno
與 bbr
的擁塞視窗行為比較:
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 基本上可以跑滿整個專線,優化目標達成。
參考資料與圖片來源
- https://blog.csdn.net/zhangskd/article/details/6715751
- https://blog.csdn.net/zk3326312/article/details/91375314
- https://blog.csdn.net/dog250/article/details/81393009
- https://blog.csdn.net/m0_37055174/article/details/102548937
- https://blog.csdn.net/c359719435/article/details/8815499
- https://zhuanlan.zhihu.com/p/64797781
- https://www.cnblogs.com/lshs/p/6038663.html
- https://www.sohu.com/a/388805449_100081454
- https://nextfe.com/tcp-congestion-control
- https://blog.apnic.net/2017/05/09/bbr-new-kid-tcp-block/
- https://www.cs.princeton.edu/courses/archive/fall16/cos561/papers/Cubic08.pdf
- https://wiki.untangle.com/index.php/Bufferbloat
- https://web.cs.wpi.edu/~claypool/papers/bbr-prime/claypool-final.pdf