致 QNAP 研發與網路工程團隊：
我正式來信，請貴團隊在 QTS/QuTS hero 中預設採用 Google 的 BBR（Bottleneck Bandwidth and Round-trip propagation time，瓶頸頻寬與往返延遲時間） 作為 TCP 壅塞控制演算法，或至少在「Network & Virtual Switch」圖形介面中新增用戶可切換的選項。
目前 QTS 預設使用 TCP CUBIC。雖然 CUBIC 曾是歷史標準，但由於其以封包遺失為核心原理，在現代 LFN（Long Fat Networks，長距高頻網路）與高延遲 WAN/VPN 場景下，效能明顯落後。
我的基礎建設與使用案例：
- NAS： QNAP TS-473A（16GB 記憶體，QTS 5.2.9）
- 網路路由： 兩端皆用 MikroTik RB5009
- 網路拓樸： 1 Gbps 光纖 FTTH，兩地點以 WireGuard VPN 直連（國際 ISP 節點，主要為 TIM/O2，延遲適中，偶有低量封包遺失）
- 主要工作負載： 高碼率媒體串流（Plex Direct Play），與經由 WireGuard 加密隧道的大檔案傳輸
CUBIC 的問題： 在一般操作時，WireGuard 隧道的吞吐量嚴重受限，僅約 39 Mbps。經詳細 iperf3 測試發現，CUBIC 因國際節點上不可避免的微量封包遺失，會激進地將壅塞窗口減半。這種以損失為本的機制壓制了可用頻寬，導致大量重傳，使高碼率串流必須轉碼播放（Ryzen V1500B 因無 iGPU，通通需 CPU 處理）。
解決方案與實證結果（BBR）： 為診斷此問題，我透過 SSH 手動調整核心參數：sysctl -w net.core.default_qdisc=fq 及 sysctl -w net.ipv4.tcp_congestion_control=bbr（為持久化，需 crontab 觸發自定義腳本，因 QTS 會在重開機時重設 sysctl.conf）。
結果極為顯著。由基於損失轉為基於延遲的演算法後：
- 吞吐量提升 10 倍： 從約 39 Mbps 直接提升至 380/400 Mbps，完全同一組 WireGuard 加密隧道。
- 穩定度： 封包傳輸極為順暢，4K 原生播放串流不再卡頓。
我的訴求： 現代 Linux 發行版、Windows 11 及主流雲端平台已普遍採用 BBR，因其能更佳地應對現實網路拓樸。QTS 本質上為堅固的 Linux 系統，核心早已支援 bbr 模組。
懇請工程團隊考慮：
- 直接將 TCP 壅塞控制預設從 CUBIC 換為 BBR。
- 或至少於 Network & Virtual Switch 介面開放簡易下拉選單，讓進階用戶可自由選擇 CUBIC 或 BBR，無須再透過 CLI/crontab 等會被韌體升級覆寫的繞道。
感謝團隊長期以來打造出色硬體，敬請考慮此架構改進建議，並靜候您的回饋。