Debian 13 啟用 BBR 加速 + 網路效能優化

Debian 13 啟用 BBR 加速 + 網路效能優化

-----------
前言
-----------

本文旨在透過啟用Google BBR擁塞控制演算法，搭配一系列核心網路參數調校，最大化伺服器的網路傳輸效率與連線處理能力


適合以下使用情境：

高延遲、高封包遺失率的網路環境 (如跨國傳輸、衛星網路)

VPS、雲端主機、CDN節點、遊戲伺服器

高併發連線的Web服務、反向代理、資料庫主從同步


雲端平台注意：AWS、GCP、Azure 等雲端平台可能已預設啟用BBR或使用自訂的擁塞控制演算法。建議先確認現有設定，再決定是否覆蓋



-----------------
什麼是BBR？
-----------------

BBR (Bottleneck Bandwidth and Round-trip propagation time) 是由Google開發的TCP擁塞控制演算法，首次併入Linux 核心 4.9版 (2016年)

相較於傳統的 CUBIC 演算法，BBR的核心差異在於：CUBIC以「封包遺失」作為壅塞信號被動反應，BBR則主動探測「可用頻寬」與「最小 RTT」

因此在封包遺失率較高或延遲較大的環境下，仍能維持相對穩定的吞吐量


適合啟用BBR的場景：

跨國或跨洲的遠距離連線

高延遲網路 (如衛星連線、行動網路回程)

VPS伺服器對外提供服務

需要大量資料傳輸的應用 (備份、影音串流、大型檔案傳輸)

補充說明：BBR 對「上行頻寬受限」的場景效益最為明顯。若你的伺服器主要作為靜態網站或僅有少量連線，BBR帶來的提升幅度可能不那麼顯著，但開啟也無害




雖然Debian 13的核心版本 (如 6.12+) 已原生支援BBR，但我們仍需確認環境

uname -r


應返回 6.12.73+deb13-cloud-amd64


核心版本需 ≥ 4.9 才支援 BBR。Debian 13預設核心通常為 6.1x 或更高，完全符合需求


-----------------------------------
確認目前使用的擁塞控制演算法
-----------------------------------

在進行任何變更前，先記錄現有設定以利未來對比或復原：

sysctl net.ipv4.tcp_congestion_control

sysctl net.core.default_qdisc



-------------------------------------------
建立 啟用BBR設定檔 + 網路優化設定檔
-------------------------------------------

建議在 /etc/sysctl.d/ 目錄下建立 獨立設定檔，而非直接修改 /etc/sysctl.conf。好處是：

模組化管理，易於維護或回滾

系統升級時不易被覆蓋

數字前綴 99 確保此設定在所有同目錄設定檔中最後載入，優先級最高


建立並編輯設定檔
vi /etc/sysctl.d/99-network-optimization.conf



貼上以下內容




# ============================================
# Debian 13 網路效能優化設定檔
# 適用於 BBR + 高併發 + 高吞吐場景
# ============================================

# ── TCP BBR 擁塞控制 ──────────────────────────

# 設定佇列規則為 fq (公平佇列)，為BBR的官方建議搭配
net.core.default_qdisc = fq

# 啟用 BBR 作為 TCP 擁塞控制演算法
net.ipv4.tcp_congestion_control = bbr

# ── 緩衝區調校 ───────────────────────────────

# Socket 接收/傳送緩衝區上限 (64 MB)
# 對大量資料傳輸或高延遲長肥管道 (Long Fat Network) 有顯著幫助
# TCP 接收/傳送緩衝區最大值 (單位: bytes)
net.core.rmem_max = 67108864    # 64MB
net.core.wmem_max = 67108864    # 64MB

# TCP 接收緩衝區自動調整範圍 (最小值 / 預設值 / 最大值，單位：bytes)
net.ipv4.tcp_rmem = 4096 87380 67108864

# TCP 傳送緩衝區自動調整範圍 (最小值 / 預設值 / 最大值，單位：bytes)
net.ipv4.tcp_wmem = 4096 65536 67108864

# ── 連線佇列與併發效能 ────────────────────────

# 最大 listen() 佇列長度，影響高併發時新連線的接受速度
# 注意：應用程式 (如 Nginx) 本身的 backlog 設定也需同步調高
# 最大監聽 socket 佇列長度 (提高高併發連線處理能力)
net.core.somaxconn = 65535

# 網路介面接收封包的軟體佇列長度
# 適用於高流量場景，避免核心側封包丟失
net.core.netdev_max_backlog = 65535

# TCP SYN 半連線佇列長度 (防禦 SYN Flood 攻擊的第一道防線)
net.ipv4.tcp_max_syn_backlog = 65535

# ── TIME_WAIT 與連線關閉行為 ──────────────────

# 縮短 FIN_WAIT2 逾時 (秒)
# 預設 60 秒，調為 30 秒可加快連線資源釋放
net.ipv4.tcp_fin_timeout = 30

# 允許 TIME_WAIT 狀態的連接埠被新連線重用 (僅適用於非 NAT 環境)
# 注意：若此伺服器位於 NAT 後方，可能導致連線混淆，請謹慎評估
net.ipv4.tcp_tw_reuse = 1

# 停用 tcp_tw_recycle (Linux 4.12 後已移除此參數，保留此行為相容舊版核心)
# net.ipv4.tcp_tw_recycle = 0

# ── 臨時埠範圍 ───────────────────────────────

# 擴大可用的臨時 (Ephemeral) 連接埠範圍，避免高併發時連接埠耗盡
# 預設通常為 32768 60999，擴大至 1024 65535
net.ipv4.ip_local_port_range = 1024 65535

# ── 可靠性與進階 TCP 功能 ─────────────────────

# TCP 選擇性確認 (SACK)：提高封包遺失後的復原效率，減少不必要的重傳
net.ipv4.tcp_sack = 1

# TCP 時間戳記：協助準確計算 RTT，並防止序列號繞回 (PAWS 機制)
# 注意：若啟用 tcp_tw_reuse，時間戳記需一併啟用才能正確運作
net.ipv4.tcp_timestamps = 1

# TCP 視窗縮放 (Window Scaling)：允許接收視窗超過 64KB，高頻寬長距離傳輸必備
net.ipv4.tcp_window_scaling = 1

# 網路設備每次 NAPI poll 最大處理封包數，預設 64，適當調高可提升高流量效能
net.core.dev_weight = 64

# TCP 資料傳輸失敗後的最大重傳次數 (對應約 100 秒逾時)
# 預設值 15 過高，調為 8 可更快感知連線斷線
net.ipv4.tcp_retries2 = 8

# TCP SYN 握手重試次數 (用於主動發起連線)
net.ipv4.tcp_syn_retries = 3

# TCP SYN-ACK 回應重試次數 (用於被動接受連線)
net.ipv4.tcp_synack_retries = 3

# ── TCP Keepalive 保活機制 ────────────────────

# 連線閒置多久後開始發送 keepalive 探測 (秒)
# 預設 7200 (2小時)，調為 600 (10分鐘)可更早偵測到斷線的殭屍連線
# 衛星或高延遲網路建議調高至 1200 或以上
net.ipv4.tcp_keepalive_time = 600

# 每次 keepalive 探測的間隔時間 (秒)
net.ipv4.tcp_keepalive_intvl = 30

# 連續幾次探測無回應後判定連線斷線
net.ipv4.tcp_keepalive_probes = 3









儲存檔案並離開vi編輯器
按 Esc，輸入 :wq，按 Enter






------------------
套用設定
------------------

即時套用 (無需重啟)
sysctl -p /etc/sysctl.d/99-network-optimization.conf


若無任何錯誤輸出，表示設定已成功套用

若看到類似 No such file or directory 或 Invalid argument，請檢查對應參數名稱是否有拼寫錯誤



注意：tcp_tw_recycle 在 Linux 4.12 後已從核心移除

若你的核心版本為 4.12 以上 (Debian 13 完全符合)，套用時可能出現 sysctl: setting key "net.ipv4.tcp_tw_recycle": No such file or directory 的警告

此為正常現象，該行可直接從設定檔刪除或註解掉

---------------
永久生效
---------------

設定檔放置於 /etc/sysctl.d/ 目錄下，系統重啟後會自動載入，無需額外操作

若想手動重新套用全部 sysctl 設定 (例如測試時)：

sysctl --system



---------------------
重開機，再次驗證
---------------------

重開機
reboot




-----------------------
驗證BBR是否成功啟用
-----------------------


確認擁塞控制演算法
sysctl net.ipv4.tcp_congestion_control


預期輸出 net.ipv4.tcp_congestion_control = bbr




查看系統支援的演算法清單
sysctl net.ipv4.tcp_available_congestion_control


輸出中應包含 bbr

例如：net.ipv4.tcp_available_congestion_control = reno cubic bbr




確認佇列規則
sysctl net.core.default_qdisc


預期輸出 net.core.default_qdisc = fq



------------------------------
確認即時連線是否套用BBR
------------------------------

確認目前TCP連線是否真正套用BBR，可觀察即時封包

ss -ti | grep bbr


結果說明：

有輸出：顯示正在使用BBR的連線資訊，表示BBR正常運作

無輸出：目前沒有活動的TCP連線，或連線數極少。這是正常的，不代表設定失敗


測試建議：可以產生一些網路流量 (如下載檔案) 後再次執行此指令



-----------------------
驗證其他網路參數
-----------------------

sysctl net.core.somaxconn


sysctl net.ipv4.ip_local_port_range


sysctl net.ipv4.tcp_rmem


sysctl net.ipv4.tcp_wmem





---------------
常見問題
---------------


Q：套用時出現 No such file or directory 錯誤

A：最常見原因是核心版本過新，移除了某些舊參數 (如 tcp_tw_recycle)。找到對應行並加上 # 註解即可

查詢哪些核心參數實際存在
sysctl -a 2>/dev/null | grep tcp_tw




Q：重開機後設定消失

A：確認設定檔位於 /etc/sysctl.d/ 且副檔名為 .conf：

ls -la /etc/sysctl.d/99-network-optimization.conf




Q：Docker 或 Kubernetes 環境下 BBR 沒有效果

A：容器網路 (CNI 如 Flannel、Calico) 可能有自己的 qdisc 或網路命名空間，sysctl 設定未必能透傳進容器

建議在容器的 securityContext 中允許 NET_ADMIN，或於 Pod 啟動時以 Init Container 套用設定




Q：如何回滾所有設定？

A：刪除設定檔後重新套用即可：

rm /etc/sysctl.d/99-network-optimization.conf

sysctl --system




----------------------------
針對特殊場景的調校建議
----------------------------

高延遲衛星網路

將 keepalive 閒置時間調高，避免正常使用中的連線被誤判為斷線：

net.ipv4.tcp_keepalive_time = 1200

net.ipv4.tcp_keepalive_intvl = 60




極高併發短連線 (如 HTTP API 服務)

縮短 FIN 等待時間並搭配更大的埠範圍，加速連線資源回收：

net.ipv4.tcp_fin_timeout = 15

net.ipv4.ip_local_port_range = 1024 65535


同時確認應用程式層 (如 Nginx) 的 worker_connections 和 backlog 設定也一併調高




----------------
優化效益總結
----------------

傳輸效率：BBR + fq --> 提升吞吐量，降低延遲

緩衝區：rmem / wmem --> 支援大流量、高延遲傳輸

連線容量：somaxconn / backlog --> 提升高併發接受能力

資源回收：fin_timeout / tw_reuse --> 加速連線關閉與埠號釋放

連線偵測：keepalive系列 --> 及早清除殭屍連線

可靠性：SACK / timestamps --> 改善封包遺失後的重傳效率




----------------
注意事項
----------------

核心升級後：升級 Linux 核心後，建議重新執行驗證步驟，確認BBR仍為預設演算法

NAT環境：若此伺服器位於 NAT 之後 (如家用路由器後方)，tcp_tw_reuse 可能造成連線混淆，建議設為 0

應用層設定需同步：somaxconn 僅是核心層上限，應用程式 (Nginx、Node.js 等) 本身的 backlog 設定也必須對應調高，否則效果有限

不要在生產環境直接大幅改動：建議先在測試環境驗證，確認效能改善或無副作用後，再部署至生產機器

監控：調整後建議使用 iperf3、nload、sar 等工具監控實際效果，數據說話

本帖最后于3月10日3月10日，由Jack编辑