題幹與適用場景
服務啟用了 TLS 1.3 的 0-RTT，以降低恢復連線的首包延遲。某些請求可能在握手完成前到達，而早期資料可能在另一條連線被重播。請說明 API 何時應回傳 425 Too Early、用戶端如何重試，以及閘道與所有服務實例如何保持一致。
這道題適合後端、網路、基礎設施與安全職位。重點不是背狀態碼，而是把傳輸層的重播風險映射到具體資源與副作用，明確 425、延遲處理、停用早期資料、冪等鍵與稽核之間的邊界。
面試官考察點
強回答會指出 425 表示伺服器不願冒險處理可能被重播的請求，不是一般過載、驗證失敗或業務校驗錯誤。它會區分安全方法與有副作用的方法，說明只有來源站知道資源是否能接受早期資料，並解釋 Early-Data 標頭、用戶端重試、閘道轉發與多實例一致性。最後還要涵蓋重試風暴、跨實例狀態與不可逆副作用。
回答前需要釐清的問題
- 請求是否真的來自 early data，或是否帶有可信的
Early-Data: 1？ - 操作是否改變狀態、扣款、出貨、發訊息或觸發外部副作用？
- 用戶端是否能在握手完成後安全重試，是否有冪等鍵與去重儲存？
- 中間閘道是否理解 425 與 Early-Data，所有來源站實例的策略是否一致？
- 連線恢復、負載、逾時與重試預算如何影響安全與可用性？
30 秒回答框架
「425 是對可能重播的 early-data 請求做的安全拒絕，不是一般限流。來源站按資源風險決定：無副作用或可證明冪等的請求可以延遲或繼續處理，扣款、寫入與其他不可逆動作應等待握手完成，必要時回傳 425。用戶端收到 425 後只能在握手完成後重試；閘道必須保留訊號，所有實例採用一致策略，並用冪等鍵與伺服器端去重保護重複請求。」
分步驟深入解答
第一步：辨識 early data 與重播模型
TLS 1.3 0-RTT 讓用戶端在握手完成前傳送應用資料。握手完成只能說明目前連線上的資料沒有被重播，不能證明另一條連線沒有收到同一份資料。因此服務不能只看連線成功，就假設請求唯一。
第二步：按資源副作用分類
來源站最清楚資源的重播後果。讀取、查詢或沒有狀態變化的操作通常風險較低，但仍要確認回應與計費邏輯沒有隱藏副作用。建立訂單、扣款、發放優惠、修改權限與發送訊息都可能重複執行，應拒絕或延遲到握手完成後處理。
第三步：選擇延遲、拒絕或關閉 0-RTT
RFC 8470 給出三類保護：在 TLS 層拒絕早期資料、等待握手完成後再處理，或用 425 要求用戶端稍後重試。三者都能降低重播風險；選擇取決於資源級策略、記憶體預算、用戶端能力與負載。不要把 425 當成每次握手失敗的替代錯誤碼。
第四步：正確回傳 425
當請求來自 early data 或帶有 Early-Data: 1 且不能安全處理時，來源站回傳 425。425 預設不可快取，回應內容不是某個資源的表示。來源站不應在用戶端沒有重試能力或請求不是 early data 時任意回傳 425，否則用戶端可能無法恢復。
第五步：定義用戶端重試邊界
使用 early data 的用戶端收到 425 後應重試，但重試不能再次使用 early data。用戶端應保留請求語義、限制次數、使用退避並遵守取消與逾時。若請求本身不可安全重試，用戶端應向呼叫方回報失敗，而不是無限重播。
第六步：讓閘道轉發訊號
閘道通常不知道某個資源是否允許 early data。轉發可能有重播風險的請求時，它必須保留或補上 Early-Data: 1，不能刪除這個訊號。若來源站不支援該機制，閘道應等待握手完成或直接拒絕；只有明確知道重試安全時才可以代替用戶端重試。
第七步：保證多實例一致
所有來源站實例、邊緣節點與非同步處理器都要採用一致的早期資料策略。一個實例延遲而另一個實例直接扣款，會讓攻擊者或網路路徑利用差異製造重複副作用。策略版本、冪等鍵、去重紀錄與可觀測欄位應跨實例共享。
第八步：驗證重試與高負載行為
測試完整握手、重播到另一實例、部分請求在握手前到達、閘道轉發、用戶端逾時與伺服器過載。記錄 early-data 命中率、425 比例、重試次數、重複鍵、重複副作用與佇列增長。高負載時，反覆回傳 425 或 503 都可能放大重試流量，應設定預算並可整體關閉 0-RTT。
設計取捨與邊界
0-RTT 的收益是降低恢復連線的首包等待，代價是服務必須承擔重播分析、策略一致性與額外去重。按方法名稱判斷安全不夠，因為安全方法也可能觸發計費、稽核或快取寫入；按資源設定風險更可靠。
冪等鍵能減少重複副作用，但不能讓任意請求自動適合 early data。去重狀態必須有足夠保留期、跨實例可見，並明確鍵衝突、重試逾時與儲存故障時的行為。對不可逆動作，等待握手完成通常比依賴複雜補償更清楚。
落地計畫與證據
先為每類資源登記 early-data 策略：允許、延遲或 425。為寫入操作增加冪等鍵與去重紀錄，閘道統一傳遞 Early-Data，來源站在日誌中記錄連線狀態、策略版本與重試關聯。接著做跨實例重播演練，驗證訂單、扣款與訊息不會重複。
上線後按資源與用戶端版本觀察 425、重試與副作用指標。若用戶端不遵守重試約束，優先修復用戶端或在邊緣關閉 0-RTT，而不是放寬來源站保護。RFC 8470 也要求閘道與來源站保持一致，發布檢查應涵蓋每個入口。
常見誤區與追問
把 425 當成限流或服務過載
425 針對可能被重播的 early-data 請求；並發過高、依賴不可用或資源配額不足應使用各自的錯誤語義與退避策略。
看到 POST 就一定回傳 425
方法名稱只是線索。真正判斷依據是資源是否能承受重播，以及是否有可靠的冪等與去重。某些可證明冪等的寫入操作可以延遲處理或採用資源級策略。
回傳 425 後又用 0-RTT 重試
RFC 8470 要求收到 425 的重試不能再次使用 early data。否則用戶端會把伺服器的保護變成新的重播機會。
閘道刪除 Early-Data 標頭
閘道刪除訊號會讓來源站誤以為請求未經歷 early data。它應保留或補上該標頭，並確認來源站理解 425；不確定時等待握手完成。
如何證明沒有重複扣款？
用跨實例共享的冪等鍵、請求指紋與扣款狀態機做一次重播演練，核對每個業務操作只產生一個最終結果。還要測試去重儲存不可用、用戶端逾時後重試與訊息下游重複投遞，不能只看 HTTP 狀態碼。