在網路傳輸中，發送端不能盲目地將資料全部塞進網路，否則會導致網路設備緩衝區溢滿而造成大量丟包。為了平衡傳輸速度與網路承載能力，我們需要擁塞控制演算法（Congestion Control Algorithm），其核心邏輯很簡單：如果沒丟包就增加發送速度以利用頻寬；一旦發現丟包，就認為網路已達上限，必須降低速度（Back off）以緩解壓力。
Cloudflare 最近在他們的開源 QUIC 實作 quiche 中發現了一個嚴重的 Bug。這個 Bug 發生在 CUBIC 演算法的實作上。CUBIC 是目前 Linux 核心預設且廣泛使用的擁塞控制演算法，旨在優化高延遲、高頻寬網路的吞吐量。
問題的起因是 Cloudflare 的整合測試管線中，部分測試案例意外失敗。這些失敗的案例有一個共同點：它們都在測試連線初期面臨嚴重丟包（Heavy Packet Loss）時，CUBIC 演算法是否能正常恢復傳輸速度。
為了還原問題，工程師建立了一個模擬環境，使用 HTTP/3 協議下載 10MB 的檔案，並在連線前兩秒隨機注入 30% 的丟包率。在正常情況下，這個過程應該在 5 秒內完成，但測試結果顯示，約 60% 的執行次數在 10 秒的超時限制內都無法完成傳輸。
透過詳細的儀表化監控（Instrumentation），工程師發現了一個詭異的現象：當丟包階段結束、網路恢復正常後，擁塞視窗（Congestion Window，決定一次能發送多少資料的指標）並沒有像預期地成長，反而陷入了一種快速切換的循環。系統在擁塞避免狀態（Congestion Avoidance）與恢復狀態（Recovery State）之間瘋狂跳轉，每 14 毫秒就切換一次，而這個頻率與當時設定的 10 毫秒往返時間（RTT）非常接近。
為了確認這是否為 CUBIC 特有的問題，團隊將演算法更換為較早期的 Reno 演算法，結果發現 Reno 能夠 100% 通過測試。這證明問題出在 CUBIC 處理閒置時間（Idle Time）的邏輯上。
具體來說，當連線處於雜訊較多的慢啟動（Slow Start）階段，且接收到的確認包（ACK）將在途資料量（In-flight bytes）降至零時，CUBIC 的閒置時間優化邏輯會產生誤判。這導致系統陷入一個無限的恢復循環：它不斷地將恢復時間設定在遙遠的未來，從而有效地封鎖了擁塞視窗的增加。
這個問題的根源可以追溯到 Linux 核心為了修復 TCP 相關問題而做出的變更，而 quiche 在實作 CUBIC 時參考了這些邏輯。
最終，Cloudflare 以一個非常簡潔的方案解決了這個複雜的行為。原本的實作僅根據最後一次發送資料的時間來計算閒置時間，而修正後的版本改為同時參考最後一次接收到 ACK 的時間。這個小小的變動打破了死循環，讓擁塞視窗能重新正常成長，使測試通過率回升至 100%。
這次事件提醒我們，即使是成熟的網路協議實作，在極端邊界條件（如高丟包率與低視窗大小的交接點）下，微小的邏輯偏差也可能導致整個傳輸效能崩潰。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。