RACK (Recent ACK) 機制：為 BBR 提供持續動力的關鍵引擎

BBR 雖擁有精確管道模型，但若無封包持續發送與 ACK 回饋，模型無法更新、引擎將熄火。傳統快速重傳僅重傳一次，重傳再丟失會導致滑動窗口卡死，只能等待 RTO (超時重傳) — 代價極大。Linux 核心引入 RACK (Recent ACK) 機制，專門解決「重傳封包再次丟失」的快速恢復問題，為 BBR 提供源源不斷的可發送封包 (能量源)。

RACK 核心邏輯：基於時間而非序號的丟失判斷

• 傳統：依序號間隙 + 重複 ACK 計數判斷丟失
• RACK：記錄 被 ACK/SACK 確認的封包中，最晚發送時間 (rack.mstamp)，設定時間窗口 twin (預設 min_rtt/4)。
  凡 發送時間 ≤ rack.mstamp - twin 且未被確認的封包，直接標記為 LOST，交由發送邏輯重傳。

兩個核心函數 (net/ipv4/tcp_recovery.c)

// 1. 更新 rack.mstamp (處理每個 ACK/SACK 區塊)
void tcp_rack_advance(struct tcp_sock *tp, const struct skb_mstamp *xmit_time, u8 sacked);

// 2. 掃描重傳佇列，標記超過 twin 的封包為 LOST
int tcp_rack_mark_lost(struct sock *sk);

運作流程

1. 收到 ACK/SACK → tcp_ack() 呼叫 tcp_rack_advance() 更新 rack.mstamp
2. 非順序 ACK 觸發 tcp_fastretrans_alert() → 呼叫 tcp_rack_mark_lost()
3. tcp_rack_mark_lost() 掃描重傳佇列：
   if (rack.mstamp - skb->skb_mstamp > twin) → 標記 LOST
   關鍵：若該封包曾被重傳，清除重傳標記，讓它像新封包一樣被發送邏輯處理
4. 標記為 LOST 的封包進入發送佇列，配合 BBR 計算的 pacing_rate 發送
5. 收到對應 ACK → 更新 max_bw/min_rtt → BBR 模型持續精進

時間序列視角的直觀理解

假設發送順序 (含重傳) 為：1 | 2 | 3 | 7 | 8 | 6 | 4 | 5 (序號 4-8 為重傳，實際發送時間亂序)。
收到 ACK 確認 4 → rack.mstamp = 發送時間(4)。
封包 7,8,6 發送時間 早於 4，若 發送時間(4) - 發送時間(7) > twin → 判定 7 丟失，標記重傳。
完全忽略序號順序，只比較發送時間 — 解決重傳亂序導致的傳統邏輯失效。

twin 時間窗口設計智慧

• twin = min_rtt / 4：基於 真實測量的離散 min_rtt (滑動窗口採樣)，非平滑後的 SRTT
• 目的：主動過濾非擁塞抖動 (如 Bufferbloat)，而非鴕鳥式平滑掩蓋
• 亂序容忍：網路亂序通常在 min_rtt/4 內，超過則極大機率真丟失

# 核心參數 (4.1+ 預設啟用 RACK)
sysctl net.ipv4.tcp_recovery=1   # 1=啟用 RACK/THIN 等現代恢復邏輯

# 驗證 BBR + RACK 運行
ss -ti | grep -E "bbr|rack"