QUIC 的死亡螺旋：一個 2017 年的 idle 修補如何在 2020 年埋下 CUBIC 陷阱

CUBIC 的 RFC 9438 §4.2-12 定義了 app-limited exclusion： 應用程式閒置期間，CUBIC 不應讓擁塞窗口因為沒有流量而產生不公平的暴衝。 2017 年 Linux 核心引入的修補正是要解決這個問題—— 但當 Cloudflare 在 2020 年把這個修補移植進使用者空間的 QUIC 實作 quiche 時， 少了核心的一個回呼，一個靜默的邊緣條件就此埋入。 六年後它在壓力測試裡以 61% 的失敗率現形， 修復只動了三行—— 但在它現形之前，這個 bug 在所有 happy path 測試裡完全不會浮現。

這不是 quiche 的咎責文，而是一個關於「語意等價」的故事： 把核心層的演算法直譯到使用者空間， 看似行為相同， 實際上時間點已經偏移一個 RTT； 而那個 RTT 在最壞情況下， 足以讓擁塞窗口永遠卡死。

2017 年的核心修補：為什麼 epoch 需要被推平

CUBIC 的擁塞窗口成長曲線是一條以三次多項式定義的時間函數：W(t) = C × (t − K)³ + W_max。 K 是「上次 congestion event 之後，要花多少時間才能回到 W_max」的常數； t 是從 epoch start（最近一次 congestion event 或 idle exit）到現在的時間。 換句話說，CUBIC 在內部維護一個時間原點，所有的窗口大小決策都從這個原點往前看。

2017 年之前，Linux CUBIC 的實作有一個尷尬的 corner case：如果應用程式長時間閒置——例如一個 HTTP keep-alive 連線在兩個請求之間靜默 30 秒——epoch 不會被更新。 當下一個請求送出時，delta_t = now − epoch_start 已經暴增到 30 秒級，代入三次多項式後 CUBIC 算出來的目標窗口會是不切實際的大值。 下一個 ACK 抵達時，CUBIC 試著把擁塞窗口拉高到那個目標，瞬間就把網路打爆。

這個問題的官方名稱是 idle application bursts。 它違反 RFC 5681 的 §4.1（restart-after-idle）：閒置之後不應該假設網路狀況跟閒置前一樣，新一輪傳送應該回到 slow start 而不是憑舊狀態暴衝。 Linux 的修補設計者——Eric Dumazet、Yuchung Cheng、Neal Cardwell——在 2017 年提出了一個比「重設 cwnd」更精緻的方案：保留 cwnd，但「把 epoch 向前平移閒置時長」。

具體做法很簡單：當偵測到應用程式從 idle 回來時，把 epoch_start 加上閒置時長。 這樣 delta_t 就會被歸回到「彷彿閒置從未發生」的值，CUBIC 的成長曲線形狀完整保留，但 burst 不會發生。 這個技巧在演算法上很巧妙——它沒有改動 CUBIC 的數學模型，只是調整時間軸的零點。

第一個修補的 commit 是 30927520dbae297182990bb21d08762bcc35ce1d，落在 net-next 樹上。 後續一個小修正 c2e7204d180f8efc80f27959ca9cf16fa17f67db 處理了 epoch 平移在「閒置之後立刻又進入 recovery」這種雙重邊界條件下的細節。 兩個 commit 在 Linux 4.13 mainline 釋出。

關鍵問題：核心怎麼知道「現在是 idle exit」？答案藏在 TCP stack 的呼叫順序裡。 Linux 的 tcp_cubic 模組（net/ipv4/tcp_cubic.c）導出一組回呼，由核心 TCP layer 在精確的時間點觸發：cubictcp_init 初始化、cubictcp_cong_avoid 在 congestion avoidance 時呼叫、cubictcp_cwnd_event 在事件發生時呼叫，cubictcp_state 在狀態切換時呼叫。 idle 偵測是透過 cwnd_event 接受 CA_EVENT_TX_START 這個事件——TCP layer 在「準備送出一段 burst」之前呼叫它。

這個觸發時機關鍵在於它發生在 ACK 處理路徑之外。 核心知道「真正的閒置開始於最後一個有效 ACK 之後（或者，連線剛建立時的 tp->lsndtime），閒置結束於應用程式呼叫 send() 而觸發新一輪傳送」。 delta_t 是用 tcp_jiffies32 − tp->lsndtime 計算的，lsndtime 在每次 tcp_event_data_sent 被呼叫時更新——但對 idle exit 而言，我們關心的是 上一次傳送對應的 ACK 路徑 是否已經 quiesce。 核心透過 icsk_ca_state 與 tp->packets_out 雙重檢查，確保 idle 判定不會被「已送出但還沒被 ACK」的封包誤觸發。

換句話說：核心擁有 ACK 處理路徑與傳送處理路徑兩端的精確控制。 idle 判定發生在「下次傳送之前」，但它衡量的時長是「上次成功 ACK 到現在」——這兩個時間錨點的差，正是真正的閒置。 在這個邊界條件下，delta_t 確實對應到網路上沒有任何 in-flight 資料的時長。

從 2017 到 2020，這個修補在 Linux mainline 跑了三年，穩定無事。 Google 的 BBR 後續演化也參考了同一個 epoch-shift 技巧。 Linux TCP 子系統的 maintainer 名單上有 Eric Dumazet 與 Neal Cardwell——他們對 CUBIC 與 BBR 的維護是同一條 codebase 的兩個分支，回呼語意在這條 codebase 內部完全一致。

核心的 idle exit 偵測依賴 TCP layer 在恰當時機呼叫 cwnd_event 回呼； TCP layer 握有 ACK 與 send 兩端的時間錨點，並且在 idle 真正結束的那一個瞬間呼叫 CUBIC。 這個 trusted base 在使用者空間 QUIC 裡並不存在——quiche 必須自己重建 idle exit 偵測，而它選擇的觸發點，剛好把核心抹掉的那個 RTT 偷渡回來。

2020 年的移植：少了一個回呼的後果

2020 年，Cloudflare 把 CUBIC 的 idle epoch 修補移植進 quiche——他們的 Rust QUIC 實作，使用者空間 library，用來取代 Linux 核心 TCP 在邊緣節點的角色。 quiche 從一開始就把 CUBIC 設計成一個 trait 介面，跟 Reno、BBR 並列； 移植 idle 修補只是「在 CUBIC 實作裡加幾行邏輯」這個層級的工作。 從 PR 的視角看，它確實只動了 CUBIC 那一個模組。

使用者空間的 QUIC 沒有 TCP 核心層那組 cwnd_event 回呼。 quiche 必須自己回答「現在算不算 idle exit」這個問題，而它的選擇是：在每次封包送出時——on_packet_sent() 進入點——檢查 bytes_in_flight == 0。 如果是，就認為這是 idle exit； 如果不是，就略過 idle 平移邏輯。

這個判定看似合理：bytes_in_flight == 0 確實意味著「沒有任何未確認的封包」，從應用層看就是「網路是空的」。 但這個判定發生在「送出封包之後」，而不是「最後一個 ACK 確認之後」。 閒置時長被計算為 now − last_sent_time。 在絕大多數真實場景下，這個值跟核心的 now − last_ack_time 幾乎一樣——因為 last_sent_time 與 last_ack_time 在穩定狀態下只差幾百微秒。 但在一個特定的邊界條件下，這兩個時間戳記會差一個完整的 RTT。

那個邊界條件就是 cwnd 已經被壓縮到最低點（QUIC 的 minimum congestion window 是兩個 MTU，約 2,700 位元組）的時刻。 當 cwnd = 2 時，每一個 RTT 內：傳送方送出兩個封包，等 ACK 回來，然後再送下兩個。 bytes_in_flight 在「ACK 抵達」與「下次傳送」之間短暫歸零——這是 cwnd 受限的正常運作，不是 idle。 但 quiche 的 on_packet_sent() 把這個 transient zero 解讀為閒置開始； 計算出的閒置時長就是上一個 RTT 的長度，約 14 毫秒。

從程式碼層面看，quiche 的 CUBIC 模組裡 on_packet_sent 大致長這樣：拿 bytes_in_flight，如果為零、且距離 last_sent_packet_time 超過閾值，就視為 idle exit，把 recovery_epoch_start 與 congestion_recovery_start_time 都加上 (now − last_sent_packet_time)。 核心邏輯來自 Linux cubictcp_cwnd_event，但呼叫時機差了一個 ACK round-trip。

// quiche 的 on_packet_sent（移植自 Linux 2017 修補，缺少 ACK-side 錨點）
fn on_packet_sent(&mut self, now: Instant, sent_bytes: usize) {
  if self.bytes_in_flight == 0 {
    let delta = now - self.last_sent_packet_time;   // ← 衡量的是「上次 send 到現在」
    self.recovery_epoch_start += delta;
    self.congestion_recovery_start_time += delta;   // ← 把 recovery 起點推到未來
  }
  self.bytes_in_flight += sent_bytes;
  self.last_sent_packet_time = now;
}

// 核心 Linux 版本對應的邏輯（簡化）：
// idle 偵測由 TCP layer 在 CA_EVENT_TX_START 呼叫；
// delta = now − tp->lsndtime，但 idle 真正的判斷依靠 tp->packets_out == 0
// 而 packets_out 是被 ACK 處理路徑減回零的——也就是說，核心隱含地用了「last_ack_time」
// 而非「last_sent_time」作為閒置起點，差別在最壞情況下是一個 RTT。

這個錯位在 happy path 上完全看不出來。 HTTP keep-alive 在兩個請求之間靜默幾秒到幾分鐘——這種情境下，now − last_sent_time 與真正的閒置時長幾乎相等（差幾百微秒），平移後的 recovery_epoch_start 不會比 now 多多少，CUBIC 的成長曲線正常運作。 所有的單元測試、所有的負載測試、所有的 happy path benchmark 都通過了。 修補上線。

隱藏的假設——「last_sent_time 跟 last_ack_time 在所有時刻幾乎相等」——在 99% 時刻正確，剩下 1% 剛好是「網路已經出問題、需要 CUBIC 表現得好」的時刻。 這段邏輯在 Cloudflare 生產環境跑了將近六年，絕大多數連線不會同時滿足「真實丟包、處於 congestion avoidance、cwnd 已被壓到 2」三個條件； 撞到的少數連線表現為「下載完不成、最後 timeout」，在 SLI 上顯示為「P99.9 完成時間異常」——一個經常被歸因為「網路波動」的訊號。

真正讓這個 bug 浮現的，是 Cloudflare 內部對 QUIC 表現的壓力測試套件。 這個套件刻意製造惡劣網路條件（人工注入丟包、抖動、頻寬限制），追蹤 quiche 在邊緣條件下的行為。 在這個套件下，61% 的測試 run 失敗——cwnd 被壓在最低點、連線在 10 秒逾時前無法完成下載。 同樣的測試在 Reno 下 100% 通過。 對比之強烈，使得 quiche 團隊立刻把懷疑焦點放在 CUBIC。

定位這個 bug 花了好幾週的 qlog 分析。 qlog 是 QUIC 的 structured logging 標準，記錄每個封包送出、ACK 抵達、cwnd 變化、recovery state 切換的時間戳記。 從 qlog 看，工程師發現了一個極為反常的訊號：cwnd 在 6.7 秒裡發生了 999 次 recovery / congestion avoidance 之間的切換。 每 ~14 毫秒一次——這個週期正好是測試環境的 RTT。 也就是說，每一個 RTT 都觸發了一次完整的「進入 recovery、退出 recovery」循環，但 cwnd 從來沒有真正成長過。

有了這個訊號之後，下一步是回答「為什麼每個 RTT 都進入 recovery 一次」。 答案藏在 in_congestion_recovery() 的判定裡——它檢查 now < congestion_recovery_start_time。 如果 congestion_recovery_start_time 被推到了未來，那麼從這個時刻往後直到那個未來時刻為止，in_congestion_recovery() 都會回傳 true。 而當這個函數回傳 true 時，CUBIC 跳過 cwnd 成長計算——cwnd 永遠停在進入 recovery 時的值，也就是最低點。

死亡螺旋：自我強化的時間錯位

死亡螺旋的特徵是它的自我強化。 一個一次性的時間錯位不可怕——它造成一個 RTT 的延誤就會被自然修正。 但這個 bug 把錯位放在一個會反覆被觸發的呼叫點上，每一次觸發都重新把 recovery 起點往未來推； 推得越遠，下一次觸發前 cwnd 越沒機會成長，越沒機會成長就越快回到 cwnd = 2 的狀態，越快觸發下一次錯位。

具體的循環是這樣：

第一步——連線進入 congestion avoidance，cwnd 已經被壓到 minimum（2 個封包）。 傳送方送出兩個封包。

第二步——一個 RTT 之後，兩個封包都被 ACK。 bytes_in_flight 從 2 個封包減到 0。 此時應用層還有更多資料要送（或 QUIC stack 自己有 stream data 排隊），所以 on_packet_sent() 立刻被呼叫，準備送下一輪。

第三步——on_packet_sent() 進入時，bytes_in_flight == 0。 判定為 idle exit。 計算 delta = now − last_sent_packet_time——這個值是剛剛那個 RTT 的長度，約 14 毫秒。

第四步——把 congestion_recovery_start_time 加上 delta。 原本 recovery 起點是 14 毫秒前（上一輪剛進入 recovery 的時刻），加上 14 毫秒之後變成「現在」——但因為 CPU 排程、計時器精度等因素，實際上會被推到「未來幾微秒」。 從這一刻起，in_congestion_recovery() 在接下來幾微秒到幾毫秒之間都會回傳 true。

第五步——下一輪 ACK 抵達。 CUBIC 走 on_packet_acked() 路徑，第一件事就是呼叫 in_congestion_recovery() 判斷是否處於 recovery。 回傳 true，於是 CUBIC 跳過 cwnd 成長計算——cwnd 維持 2，恰好是 minimum。

第六步——再下一輪 on_packet_sent() 被呼叫。 bytes_in_flight 又一次回到 0，循環從第二步開始。 每 RTT 一次，永遠卡死。

這個循環的關鍵性質是「congestion_recovery_start_time 永遠領先 now 一個 RTT」。 傳送方每送一輪、收一輪，把 recovery 起點再推一個 RTT； recovery 永遠在未來，永遠不會結束。 CUBIC 的成長曲線從此凍結。

RTT = 14 ms

每秒錯位次數 71 1 MB 下載理論時間 49 s 10 秒內 cwnd 成長 0 pkt

從外部觀察者看，這個現象有幾個特徵：

第一，cwnd 完美卡在 minimum（QUIC 1200 位元組 MTU 下大約 2,700 位元組）。 不是「卡在最低附近」，而是「精確等於最低值」——CUBIC 的成長被完全跳過，沒有任何 +1 的機會。

第二，吞吐量計算很簡單：每 RTT 兩個封包，每封包 1200 位元組，14 毫秒 RTT，得出 ~171 KB/s。 即便目標檔案只有 1-2 MB，要十幾秒到幾十秒才能下完。

第三，recovery state 切換頻率異常高。 正常情況下，一條穩定連線進出 recovery 是事件性的——丟包觸發進入，幾個 RTT 後退出。 在死亡螺旋下，每 RTT 一次切換，6.7 秒裡 999 次。 這是 qlog 裡最顯眼的訊號。

第四，這個現象不會自動恢復。 沒有 timer、沒有 timeout、沒有 reset 路徑會主動打破循環——除非應用層的 timeout 把整個連線砍掉重建。 對使用者來說，就是「下載卡住、最後失敗」。

▷ play ↺ reset ⤓ inject loss t = 0.00 s · buggy cwnd = 10 · fixed cwnd = 10

buggy (last_sent_time) fixed (last_ack_time) cwnd = 2 floor

定位的細節：qlog 揭露的訊號

從「測試失敗」到「修補上線」這幾週，最費時的不是寫程式碼，而是定位。 CUBIC 的內部狀態很多——cwnd、ssthresh、w_max、k、recovery_start_time、epoch_start——其中任何一個被誤算都能造成下載卡住的觀察現象。 要從這六七個變數裡指認出「recovery_start_time 是兇手」，需要的不是讀程式碼，而是讀資料。

qlog 是 QUIC 為這類定位設計的工具。 每個事件——封包送出、ACK 抵達、recovery 進入、recovery 退出、cwnd 變化——都會被記錄成一個時間戳記加上狀態快照的 JSON event。 對一條快速失敗的連線，10 秒裡可能會產生幾萬個 event； 用 qvis 之類的 viewer 把這些 event 畫成時序圖，反常之處會直接跳出來。

qvis 圖上最有指認力的訊號是第三個：recovery_start_time 在每個 qlog event 裡都領先「現在」0 到 14 毫秒，且這個 lead 在每個 send 之後被刷新。 看到這個訊號，工程師才把焦點從「進入 recovery 的條件」轉到「離開 recovery 的條件」——CUBIC 從來沒有錯誤地進入 recovery，它只是錯誤地不離開。

定位之後，回頭看程式碼，那段移植過來的 idle exit 邏輯就「跳出來了」。 修補的設計者立刻看出 last_sent_packet_time 不是正確的 anchor——但要先看出來，前提是先看到 qlog 裡那個 999 次切換的訊號。

這也是為什麼 happy path 測試完全抓不到這類 bug：happy path 不會把連線推到「cwnd = minimum」這個狀態，recovery_start_time 的錯位永遠不會被觸發。 要看到這個 bug，必須要有「同時滿足三個邊界條件」的測試 fixture——這在工程文化上很容易被忽略，因為它的 setup 看起來像是「故意把連線弄壞」，跟一般的功能驗證直覺相反。

Cloudflare 內部的壓力測試套件是這個 bug 能被抓到的關鍵基礎建設——它不是針對這個 bug 設計，而是針對「QUIC 在惡劣網路下的所有表現」設計的。 在這個套件下，bug 觸發的失敗率穩定在 61%——同樣設置下 Reno 100% 通過。 失敗率穩定在 61% 不是「不穩定」，而是「某個邊界條件以 61% 機率被滿足」——對應三個條件的聯合機率（loss × cwnd = min × CA 階段）。

修復、量化、與三個普遍結論

修復本身只動了三行：新增一個 last_ack_time 欄位到 CUBIC state，每次 ACK 抵達時更新（在 on_packet_acked() 裡），idle exit 的 delta 計算改為 now − max(last_ack_time, last_sent_time)。 三行程式碼，外加一行測試。

// 修復後的 on_packet_acked（加 last_ack_time 更新）
fn on_packet_acked(&mut self, now: Instant, acked_bytes: usize) {
  self.bytes_in_flight = self.bytes_in_flight.saturating_sub(acked_bytes);
  self.last_ack_time = now;                                  // ← 新增
  if !self.in_congestion_recovery(now) {
    self.cwnd_grow(now);
  }
}

// 修復後的 on_packet_sent（idle anchor 改成 max(last_ack, last_sent)）
fn on_packet_sent(&mut self, now: Instant, sent_bytes: usize) {
  if self.bytes_in_flight == 0 {
    let anchor = self.last_ack_time.max(self.last_sent_packet_time);   // ← 改了
    let delta = now - anchor;
    self.recovery_epoch_start += delta;
    self.congestion_recovery_start_time += delta;
  }
  self.bytes_in_flight += sent_bytes;
  self.last_sent_packet_time = now;
}

為什麼 max？因為這兩個錨點分別捕捉不同的事件：last_ack_time 抓「網路上最後一次有活動」，last_sent_packet_time 抓「應用層最後一次主動產生資料」。 真正的 idle 必須同時滿足「網路安靜」且「應用層安靜」——max 保證取兩者中最近的事件，這個事件之後才有可能是 idle 的起點。

修復後的測量數字：同樣的 100 個壓力測試 run，通過率從 39% 跳到 100%。 cwnd 曲線回到正常的 CUBIC 形狀——進入 recovery、降到 W_max × 0.7、然後沿三次曲線往上爬。 原本要 10 秒以上才能 timeout 的下載，現在 4-5 秒內完成。 recovery 切換頻率從 ~140 次/秒回到事件性的「每幾秒一次」——這對應 CUBIC 在這個網路條件下的真實 loss event 頻率。

觀察指標	buggy（last_sent_time）	fixed（max(last_ack, last_sent)）	變化
100 個壓力 run 通過率	39%	100%	+61 pp
穩定狀態 cwnd	2,700 B（2 MTU）	沿 CUBIC 曲線	恢復成長
recovery state 切換頻率	~149 Hz	事件性（≈ 0.1 Hz）	−3 個量級
6.7 秒內 state 轉換次數	999	< 5	−200×
10 MB 下載完成時間	timeout @ 10 s	4-5 s	2-2.5× 速度
程式碼變動行數	——	+3 行（含 1 行新欄位）	最小 patch
定位耗時	——	數週 qlog 分析	遠大於 patch 行數

程式碼變動行數與定位耗時的不對稱，是這類 bug 的標誌。 Fix 永遠很短——因為錯位本身就是一個 anchor 寫錯。 但發現它需要：第一，正確的壓力測試 fixture（沒有它，bug 不會浮現）； 第二，能讀的 qlog（沒有它，定位是猜謎）； 第三，對 CUBIC 內部狀態的熟悉度（沒有它，看著 qlog 也認不出哪個變數該起疑）。 三個都到位的團隊不多。

把這個故事抽出來，有三個對「核心 → 使用者空間」演算法移植普遍適用的結論：

結論一：trusted base 不是程式碼，是「呼叫時機」。 核心 TCP layer 提供給 CUBIC 的不只是 ACK 計數、in-flight bytes 這些 data； 它還提供「在恰當的時間點呼叫你」這個 contract。 當這些回呼被移植到不同的執行環境時，data 可以直譯，但 contract 必須重新驗證——「我是在 ACK 完成之後被呼叫，還是在 send 之前被呼叫？這兩者差一個 RTT 嗎？」是要明確問的問題。

結論二：隱含假設往往藏在「時間相等」上。 核心程式碼裡 last_ack_time 跟 last_sent_time 在大多數時刻幾乎相等——所以可以用任一個來估計 idle 開始時點。 這個「幾乎相等」是個 statistical truth，不是個 invariant。 invariant 是「真正的 idle 必須兩個 anchor 都安靜」； 隱含假設是「我可以省一個 anchor，反正它們大多時候相等」。 Bug 出現在 invariant 與 statistical truth 第一次分歧的時刻。

結論三：邊界條件測試是結構性的基礎建設。 61% 的失敗率不是「壞運氣」——它是「該被測試的條件以 61% 機率出現」的觀測值。 要把這類 bug 從生產環境裡擋下來，邊界條件測試必須是 CI 的一部分，跟 happy path 同等地位。 對 transport layer code、congestion control、queue management 這類「狀態空間大但 happy path 很單純」的領域尤其關鍵。

這個 bug 不是 quiche 獨有的——任何把 CUBIC 從核心移植到 userspace 的實作（picoquic、msquic、aioquic、quinn）都需要重新解決同一個 idle exit 偵測問題。 回呼語意的 trust 在每一個 port 都要重新被驗證一次。 對較小團隊而言，問題不是「要不要做壓力測試」而是「做到什麼覆蓋深度才合理」——但結構性的 stress test 應該永遠存在，哪怕只覆蓋幾個關鍵 callsite。

Take-away：把核心 TCP 修補移植到使用者空間 QUIC 時，每個「時間點回呼」都必須重新核對語意等價——last_sent_time 與 last_ack_time 在 happy path 差幾百微秒，但在 cwnd 跌到最低點那一刻它們差一整個 RTT，而那個 RTT 足以讓擁塞窗口永遠卡死。