無線速度不符合預期？了解 TCP BBR！

假設有來自 ISP 的 1Gbps 下載/上傳寬頻連接，一台具有 1Gbps 有線網路和 AX200/AX201/AX210/AX211 Wi-Fi 6 無線網卡的電腦經過以下測試：

數據機---電腦，使用ookla app測速，下載940Mbps，上傳940Mbps。

數據機---Deco X90---電腦，我們得到了 940Mbps 的下載和 940Mbps 的上傳。

數據機---Deco X90 )))((電腦，但當電腦無線連線時，下載只有300-400Mbps，上傳還可以，900Mbps+。

Deco是否設定錯誤？

然後我們做了以下對比測試，看看可能是什麼問題。

數據機---Deco---交換器---電腦1，電腦2與Deco無線連線。

我們使用iperf3進行本地測試，運行電腦1到電腦2的流量，從中我們可以看到Deco和電腦2之間的無線效能。

下載為940Mbps+，上傳為940Mbps+，這表示無線部分沒有任何瓶頸。

那麼這個問題是怎麼發生的呢？

我們在實驗室中使用以下測試拓撲進行了另一項測試：

我司自建測速伺服器---Deco X90 )))((( 電腦（無線）

在自建的測速伺服器上，我們使用一些工具設定了一定的丟包率，這幫助我們重現了上述現象，結果如下：

伺服器端設定不丟包的情況：下載947Mbps，上傳939Mbps。

伺服器端設定0.5%丟包率：下載646Mbps，上傳937Mbps。

可以看到，雖然丟包率不大，但效能差異很大。

不過，在伺服器上稍微調整一下，將伺服器上的TCP擁塞協定從預設的Cubic改為TCP BBR，我們又得到了不錯的結果，比較如下表：

此外，為了驗證上述結論，我們在實際環境中又進行了一次測試，在新加坡的實際家庭寬頻上進行了測試，方法與上述相同。

運行公共測速伺服器的 Amazon AWS 虛擬機器 --- 網路 --- 家庭寬頻 --- Deco X90 --- 電腦1（有線）和 電腦2（無線）

那麼問題來了：什麼是TCP BBR？

TBBR（Bottleneck Bandwidth and Round-trip propagation time）是Google的一種壅塞控制演算法，在網路連結的電腦或行動裝置中運行，可決定數據發送的速度，旨在解決網路壅塞問題。在啟用BBR前，自1980年代起，TCP/IP ( TCP/IP Protocol Suite ) 的演算法大多都是先觀測傳輸時封包是否有丟失狀況，如果有丟失則認識此為網路壅塞，而處理方式是全面降速，直到丟失的封包成功傳出，此舉會導致緩衝區不斷擴大，在傳輸大量資料時速度越來越慢、最後卡死。

這樣，當您發現 Deco 的無線速度較慢時，有一些建議：

如果您遇到此類問題，請嘗試：

1. 對比有線和無線的結果，只有無線測試有問題，有線不受影響或影響較小。
2. 使用 iperf3（或其他自訂速度測試工具）執行本地速度測試，以驗證無線部分是否為瓶頸。
3. 如果無線部分不是瓶頸，您將必須尋找啟用 TCP BBR 的良好速度測試伺服器。
4. 不幸的是，我們無法直接獲取特定伺服器的訊息，因此您可以使用ookla應用程式測速並嘗試您附近的不同伺服器，我們相信您會找到適合您寬頻的伺服器。