題幹與適用場景
一個協作應用透過同一 QUIC 連線傳送可靠的工作階段設定、即時游標位置和短暫控制提示。游標的舊值很快失效，偶發丟包比排隊等待更好；設定則必須按序到達。請設計傳輸映射，並解釋為什麼不能把所有訊息都塞進可靠 stream，也不能把 DATAGRAM 當成「不會擁塞的 UDP」。
RFC 9221 定義 QUIC DATAGRAM 框架：資料使用 QUIC 的加密和連線脈絡，但不要求重傳；它仍受 QUIC 擁塞控制和路徑最大 UDP 負載限制。高品質回答必須說明應用層如何處理丟失、亂序和重連，而不是只比較 TCP 與 UDP。
面試官考察點
- 是否區分 stream 的可靠、有序位元組流與 DATAGRAM 的不可靠訊息邊界。
- 是否知道 DATAGRAM 共用握手、驗證和擁塞控制，不提供重傳，也不繞過接收端容量。
- 是否按訊息時效、可丟失性和副作用選擇承載，並保留可靠設定通道。
- 是否處理
max_datagram_frame_size、MTU、擁塞、重連和不支援 DATAGRAM 的回退。 - 是否設計序號、過期策略、統計和壓力測試來證明「丟舊值」是可接受的。
回答前需要釐清的問題
- 即時訊息是否允許亂序和丟失，還是需要至少一次、按序或去重？
- 單條訊息大小、傳送頻率、突發上限和路徑 MTU 是多少？
- 對端是否確認支援 DATAGRAM，是否經過 HTTP/3、代理或 CONNECT-UDP？
- 連線遷移、網路切換、重連後哪些狀態需要重新同步？
- 丟包時使用者體驗如何降級，哪些控制訊息必須改走 stream？
30 秒回答框架
「設定同步和需要確認的控制操作走可靠 stream；游標位置等短命更新走 QUIC DATAGRAM。DATAGRAM 仍使用 QUIC 加密、連線驗證和擁塞控制，但不重傳，應用用單調序號和過期時間丟棄舊值。建立連線時協商最大資料報大小，傳送端在 MTU 預算內編碼；若對端不支援或持續丟包，則降級為節流後的 stream 或只傳送關鍵快照。用丟包、擁塞、遷移和重連測試驗證。」
分步驟深入解答
第一步：建立可靠性與時效性矩陣
把設定、權限和提交結果標為可靠有序；把游標、即時位置和可重算提示標為短命可丟失。一個邏輯訊息不能因選擇 DATAGRAM 就自動獲得重傳；需要確認的副作用必須走 stream 或在應用層另建可靠協定。
第二步：協商路徑能力與尺寸
檢查對端通告的 max_datagram_frame_size。傳送端還要考慮 max_udp_payload_size、路徑 MTU、加密開銷和中間網路；超過預算的訊息應拆分到 stream、壓縮或丟棄，不能假設 IP 分片可靠。能力變化時快取設定要更新並記錄版本。
第三步：定義應用層丟包與亂序語義
每個短命更新攜帶工作階段 epoch、單調序號和過期時間。接收端只套用目前 epoch 且未過期、序號更新的值；缺失中間游標不觸發重傳，下一次新值會覆蓋它。控制提示若影響狀態，應攜帶冪等鍵並走可靠確認通道。
datagram: { epoch: 42, seq: 981, expires_at: 1753938001, cursor: [412, 208] }
stream: { epoch: 42, op_id: "cfg-17", version: 9, payload: ... }第四步：把擁塞和背壓納入傳送器
DATAGRAM 與 stream 共用 QUIC 的擁塞控制；大量即時資料會擠壓可靠資料。傳送器要限制每個工作階段和訊息類別的預算，偵測傳送失敗、排隊和 RTT，優先丟棄舊位置，保留設定和關鍵控制。不要用無界佇列把丟包變成延遲堆積。
第五步：設計回退、遷移與重連
握手或版本協商確認 DATAGRAM 可用後再啟用；HTTP Datagrams 情境還要遵循 RFC 9297 的 Capsule 協定和代理能力。對端不支援、路徑持續丟棄或重連後能力改變時，切換為降頻 stream 或只傳送最新快照。新連線必須重新確認 epoch，避免舊連線資料污染目前狀態。
第六步：驗證可接受的損失
用可控丟包、亂序、擁塞、MTU 變化、網路遷移和重連回放。檢查設定最終一致、游標延遲與新鮮度、關鍵操作無重複、可靠 stream 不被資料報洪峰餓死。記錄按訊息類別的傳送量、丟失率、過期丟棄、回退次數、RTT 和佇列深度；以使用者體驗門檻決定是否繼續使用 DATAGRAM。
高品質示範回答
「我把設定、權限和提交結果放在 stream，要求按序和確認；游標位置放在 DATAGRAM，因為舊值很快過期。每個位置訊息帶 epoch、序號和過期時間，接收端只接受目前 epoch 的最新值。傳送前依據 max_datagram_frame_size 和 MTU 限制大小，擁塞時優先丟舊游標，不能讓它占滿連線預算。」
「若對端沒有 DATAGRAM 能力、代理鏈路不支援或遷移後持續丟失，我切換為節流 stream 或最新快照。關鍵控制操作始終用冪等鍵和可靠確認。測試涵蓋 5%、20% 丟包、亂序、MTU 降低、網路切換和重連，驗收設定一致性、游標新鮮度、回退成功率與 stream 尾延遲。」
常見錯誤
- 把 DATAGRAM 當成無擁塞 UDP → 洪峰拖垮可靠資料 → 共用連線預算並做訊息級背壓。
- 在 DATAGRAM 上傳送不可重複的副作用 → 丟包後狀態不確定 → 改用可靠確認或冪等應用協定。
- 忽略
max_datagram_frame_size和 MTU → 訊息無法傳送或產生分片風險 → 協商並限制編碼大小。 - 丟包後無條件重傳所有舊值 → 延遲和擁塞累積 → 用序號與過期時間丟棄舊更新。
- 重連沿用舊 epoch → 舊連線資料污染新工作階段 → 在新連線重新建立 epoch 和快照。
- 只測吞吐不測新鮮度 → 平均指標正常但使用者看到舊狀態 → 測端到端時延、過期率和關鍵訊息尾延遲。
追問及應對
追問一：DATAGRAM 是否保證順序？
不保證。每個 DATAGRAM 有訊息邊界，但應用必須自行處理亂序、重複和丟失；短命資料通常用序號和過期時間，只保留最新值。
追問二：為什麼不用獨立 UDP 通道？
QUIC DATAGRAM 重用既有連線的握手、驗證、加密和擁塞控制，減少額外連線管理；代價是仍受 QUIC 路徑和擁塞約束，應用不能獲得裸 UDP 的語義。
追問三：DATAGRAM 能承載大檔案嗎？
不適合。大檔案需要可靠、有序、可恢復的 stream；資料報應限制在協商尺寸內，避免拆分後缺一片就無法使用。
追問四：如何判斷回退成功？
記錄能力協商、回退原因、回退後的訊息新鮮度、關鍵操作成功率、stream 尾延遲和佇列深度。故障演練應證明回退不會把短命更新無限排隊，也不會丟失必須確認的狀態。