題干與適用場景
你的代理希望在 HTTP/1.1 協定升級確認前就傳送後續資料以降低延遲。請說明風險、適用邊界，以及如何修改客戶端和代理實作。
面試官考察點
- 是否理解 HTTP/1.1 升級在收到確認前仍可能被拒絕，不能把歷史成功當作安全保證。
- 是否能解釋攻擊者控制的資料如何在拒絕分支被重新解析為 HTTP 請求。
- 是否區分 Upgrade、CONNECT、WebSocket 與 HTTP/2/3 的不同約束。
- 是否給出等待 2xx、關閉連線、停用樂觀傳送和可觀測回退等工程措施。
回答前需要釐清的問題
- 使用的是 Upgrade 還是 CONNECT，升級目標協定和 HTTP 版本是什麼？
- 後續位元組是否可能由不可信應用程式、使用者或第三方 origin 控制？
- 連線是否帶有客戶端憑證、代理認證或其他連線級信任？
- 目標是降低握手延遲，還是必須保持 HTTP/1.1 相容和連線複用？
30 秒回答框架
我會預設禁止 HTTP/1.1 在確認前傳送不可信後續資料。客戶端等待升級回應；CONNECT 代理至少等待 2xx，或傳送 Connection: close 並在失敗後關閉連線。拒絕時不能複用已混入未知協定位元組的連線。對 HTTP/2/3 個別驗證多路復用語意，記錄升級結果和回退原因，先在測試代理中做請求走私和解析差異測試。
分步驟深入解答
1. 識別樂觀傳送的前提
HTTP/1.1 客戶端可用 Upgrade 或 CONNECT 請求切換協定，但伺服器可能拒絕。客戶端若在收到狀態碼前傳送新協定位元組，實際上同時面對兩種解析：接受時按新協定處理，拒絕時按 HTTP/1.1 處理。不能用「上次成功」推斷本次一定接受。
2. 解釋請求走私路徑
當後續資料由不可信來源控制時，拒絕分支可能把這些位元組解釋為額外 HTTP 請求。若連線級認證已通過，代理可能把攻擊者構造的請求誤認為客戶端已認證請求。代理和客戶端解析邊界不一致，還可能觸發請求解析器漏洞。
3. 選擇安全實作策略
最穩妥的策略是收到確認後再傳送後續資料。RFC 9931 對 HTTP/1.1 CONNECT 要求代理客戶端等待 2xx，或帶 Connection: close；代理在拒絕未滿足安全條件的 CONNECT 時應關閉底層連線。若確實需要低延遲，優先使用 HTTP/2 或更高版本的明確串流語意，並驗證目標協定自己的握手規則。
4. 做回退、監控與測試
升級失敗時把連線標記為不可複用，重新建立 HTTP/1.1 請求；不能把已傳送的未知位元組當作可重試請求。指標記錄升級接受率、拒絕原因、連線關閉和重試次數，日誌不記錄憑證和請求內文。測試涵蓋不可信 payload、代理認證、401/407、重新導向、逾時、解析差異和 HTTP/2/3 回退。
高品質示範回答
我不會把樂觀傳送當成普遍優化。HTTP/1.1 的 Upgrade 或 CONNECT 在確認前仍可能被拒絕；如果後續位元組受攻擊者控制，拒絕分支可能按 HTTP/1.1 把它們解析為額外請求，形成請求走私，連線級認證會放大影響。因此預設等待伺服器確認。CONNECT 代理至少等待 2xx，或使用 Connection: close 並在拒絕後關閉連線；Upgrade 失敗的連線不複用。需要更低延遲時評估 HTTP/2/3 的串流語意和目標協定約束。透過不可信 payload、認證代理、錯誤狀態、重新導向和重試測試驗證，監控接受率與關閉原因，保證回退不會洩露請求或憑證。
常見錯誤
- 看到近期升級成功就提前傳送任意後續位元組。
- 只驗證伺服器端，忽略客戶端、代理和第三方資料源的解析邊界。
- CONNECT 被拒絕後繼續複用連線或轉發已緩衝 payload。
- 把 WebSocket 的握手規則套用到所有 Upgrade token。
- 只用 HTTP/1.1 測效能，未區分 HTTP/2/3 的串流和連線語意。
- 重試時複用含有未知位元組的請求，或把內文寫入診斷日誌。
追問及應對
為什麼 Connection: close 能降低風險？
它要求連線在請求處理後關閉，拒絕升級時不會繼續在同一連線解析可能混入的後續位元組。它犧牲連線複用，應結合等待 2xx 的策略選擇。
WebSocket 可以樂觀傳送嗎？
WebSocket 握手規則要求客戶端等待伺服器回應後再傳送後續資料，不能把其他協定的經驗直接泛化。每個 Upgrade token 都應遵守自身規範。
如何兼顧延遲與安全？
先量測等待確認的真實成本，再優先使用 HTTP/2 或 HTTP/3；若必須支援 HTTP/1.1，就等待確認並做連線關閉回退。任何最佳化都不能讓不可信資料跨越未確認的解析邊界。