題干與適用場景
這道 HTTP 與安全基礎題適合後端、平台、SRE 與基礎設施職位。場景是 TLS 1.3 0-RTT 請求到達閘道：早期資料降低握手等待，卻可能被重播。回答要把 425 語義、業務冪等與逐跳策略連起來。
面試官考察點
- 是否理解 0-RTT 的效能收益與重播風險。
- 能否準確解釋 425、429、503 與 408 的邊界。
- 是否會用冪等鍵、去重帳本與狀態查詢保護副作用。
- 能否讓閘道、源站與多實例對早期資料採用一致策略。
回答前需要釐清的問題
先確認請求是否真的包含早期資料證據、方法會不會產生副作用、閘道是否保留 Early-Data，以及用戶端是否支援在完整握手後重試。再問是否存在冪等鍵、唯一約束、去重記錄與跨實例共享狀態。GET 也可能觸發業務副作用，不能只按方法名稱判斷安全性。
30 秒回答框架
TLS 1.3 0-RTT 允許用戶端在握手完成前傳送早期資料，但這些資料可能被重播。若請求尚未證明可安全處理，服務端回傳 425 Too Early，要求用戶端完成握手後重試；重試不得再次使用早期資料。可重播、冪等且有去重保護的操作才考慮接受。閘道與源站必須一致識別 Early-Data: 1，並監控重試放大。
分步驟深入解答
- 說明風險。 0-RTT 早期資料仍受加密保護，但攻擊者可能複製並重播有效請求。風險核心是重複副作用，不是機密性直接曝光。
- 說明 425。 當請求在早期資料階段不宜處理時回傳 425。服務端不應在沒有證據時濫發 425；回應本身預設不可快取。
- 判定可接受操作。 讀取操作也要檢查真實副作用；支付、出貨、配額變更等寫入預設等待完整握手。若接受早期資料，必須有冪等鍵、唯一約束或去重帳本。
- 定義重試。 傳送早期資料的用戶端收到 425 後，在完整握手完成後重試，重試不能再放入早期資料。服務端應限制重試次數與總期限。
- 保持逐跳一致。 中介層可加入或轉送
Early-Data: 1。閘道、負載平衡器與源站必須使用相同信任邊界；否則一個實例等待，另一個實例可能先執行副作用。 - 控制放大。 過載時 425 與握手重試會放大流量。限制早期資料大小與並發，監控 425 比例、重試率、重複業務鍵與握手延遲。
高品質示範回答
我會先把 Early-Data: 1 當作重播風險訊號，而不是把 0-RTT 當作普通已確認請求：
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123如果支付操作尚未證明可重播，我回傳 425 Too Early，並讓用戶端完成 TLS 握手後使用同一個冪等鍵重試；重試不能再次使用早期資料。若操作確實可重播，我仍會用唯一約束或去重帳本防止重複執行。425 不表示限流（429）、整體暫時不可用（503）或用戶端逾時（408）。閘道與源站統一策略，記錄請求 ID、早期資料標記、重試次數與重複鍵，避免重試把過載放大。
常見錯誤
- 說「0-RTT 未加密」 → TLS 仍提供加密 → 風險是請求可重播。
- 收到 425 後原樣再次發送 0-RTT → 風險仍在 → 完整握手後再重試。
- 看到 POST 就永遠回傳 425 → 某些寫入有可靠去重 → 按副作用與證據判斷。
- 把 425 當作 429 → 425 處理早期資料，429 表示速率限制 → 分開退避與告警。
- 只在閘道判斷，源站沒有相同策略 → 多實例可能執行不一致 → 統一信任邊界與狀態。
追問及應對
425 與 503 如何區分？
425 針對早期資料階段的重播風險；503 針對服務暫時無法處理請求。只有請求帶有早期資料證據且策略要求等待握手時才選 425。
為什麼不能只允許 GET？
HTTP 方法名稱不保證業務沒有副作用。某些 GET 會觸發計數、預取或狀態變更，仍需按實際副作用與去重能力評估。
閘道如何傳遞早期資料資訊？
受信任中介層可加入或轉送 Early-Data: 1，但必須防止不可信用戶端偽造訊號，並讓源站知道標記來源與策略。
如何驗證不會重複扣款？
用同一個冪等鍵執行唯一插入或去重帳本，記錄最終狀態；重試前先查詢，事後對帳支付流水與業務訂單。