後端面試：如何設計安全的 WHIP WebRTC 推流入口？

題幹與適用場景

你要為編碼器或媒體生產者提供 WHIP（WebRTC-HTTP Ingestion Protocol）入口。客戶端以 HTTP POST 傳送 application/sdp 的 offer，伺服器完成 ICE 與 DTLS 會話協商並回傳 SDP answer。請說明介面、會話生命週期、驗證、資源保護與可觀測性。假設單一推流是單向媒體上行，暫不討論錄製與轉碼。

面試官考察點

• 是否把 HTTP 訊令資源與 WebRTC 媒體資源分開建模。
• 是否能從一次 POST 推導驗證、限流、逾時與清理順序。
• 是否理解 HTTPS、ICE、DTLS-SRTP 與瀏覽器 API 的邊界，而非把 WHIP 當成媒體傳輸協定。
• 是否涵蓋重試、重複建立、半連線與惡意 SDP 等失敗路徑。

回答前需要釐清的問題

• 推流者是受控編碼器還是開放使用者？驗證憑證能否短期且單流使用？
• 需要單一區域入口還是跨區接入？會話狀態是否允許跨區轉移？
• 目標是低延遲優先，還是必須保證錄製完整性與回放可追溯？
• 是否啟用 trickle ICE 或其他 WHIP 擴充？若啟用，擴充協商與權限由誰負責？

30 秒回答框架

我會把 WHIP 入口分成驗證閘道、會話控制面與 WebRTC 媒體節點。閘道先驗證短期憑證、請求大小與租戶配額，再把 SDP offer 交給會話服務；會話服務建立具逾時的候選資源，完成 ICE/DTLS 協商後回傳 201 Created、SDP answer 與會話 Location。所有未完成協商都必須釋放資源，DELETE 要具備冪等性，限流要同時看租戶與來源。指標要分開記錄 HTTP 訊令結果、ICE/DTLS 狀態與媒體首包時間，不能只看 POST 成功率。

分步驟深入解答

1. 劃定協定邊界。 WHIP 負責一次 HTTP offer/answer 交換；真正媒體由 WebRTC 協定堆疊承載。瀏覽器能力由 W3C WebRTC API 暴露，伺服器仍需處理 ICE、DTLS 與媒體接收。
2. 先做低成本檢查。 在分配 ICE 或媒體節點前檢查 HTTPS、驗證、租戶狀態、Content-Type: application/sdp、請求大小、頻道與速率配額。拒絕路徑不得觸發昂貴的 SDP 解析或連線配置。
3. 建立會話狀態。 使用隨機且不可枚舉的會話 URL 記錄 pending → connected → closing → closed。建立操作回傳 201 Created、Location 與 SDP answer；失敗只回傳可診斷但不暴露內部拓撲的資訊。
4. 限制半連線。 為 SDP 解析、ICE/DTLS 建立與首包設定獨立逾時。RFC 9725 指出，持有驗證憑證的攻擊者可反覆 POST，迫使伺服器配置資源並等待 ICE/DTLS 逾時，因此閘道要限速，會話層要有並發配額，逾時要回收節點。
5. 處理重試與刪除。 網路重試可能產生多個 offer。憑證應綁定頻道或冪等鍵；無法安全判斷重複時可建立新會話，但必須限制並發。對 DELETE /session 做冪等，重複刪除回傳相同終態，不重新配置資源。
6. 安全傳輸與憑證。 RFC 9725 要求使用 HTTPS 以維持 WebRTC 安全模型；憑證不放在查詢字串，日誌只記錄雜湊後的會話識別。媒體節點只接受會話服務簽發的短期授權，避免頻道金鑰散落到所有節點。
7. 擴充必須明確協商。 若支援 trickle ICE 或伺服器事件等擴充，透過回應的 Link 等機制宣告能力；客戶端不應假設所有 WHIP 伺服器都支援擴充。擴充失敗要回到基礎一次性交換或明確終止，不能靜默改變語意。
8. 驗證可用性。 記錄租戶級 POST 接受率、SDP 解析失敗、ICE 成功率、DTLS 建立時間、媒體首包延遲、逾時回收數與 DELETE 延遲。用故障注入驗證重複 POST、惡意大 SDP、ICE 永不連通、節點重啟與憑證撤銷。

高品質示範回答

我會先確認這是控制面入口：HTTP POST 只負責把 SDP offer 交給會話服務，媒體隨後由 WebRTC 連線承載。入口收到請求後先驗證 HTTPS、短期憑證、頻道權限、內容類型、大小與租戶並發，再解析 SDP；所有拒絕都發生在配置媒體資源之前。成功時建立不可枚舉的會話資源，回傳 201 Created、Location 與 answer，並讓會話進入有逾時的 pending。ICE 或 DTLS 遲遲不成功時主動釋放資源，避免攻擊者用大量半連線耗盡節點。DELETE 必須冪等，重試則透過短期憑證與冪等鍵限制重複建立。最後把 HTTP、ICE/DTLS 與媒體首包指標分層，分別壓測 POST 洪泛、惡意 SDP、節點重啟與憑證撤銷，證明入口安全且故障可復原。

常見錯誤

• 把 WHIP 當成媒體通道 → 忽略 ICE、DTLS 與媒體節點狀態 → 明確區分控制面與媒體面。
• 收到 POST 就立即配置完整節點 → 惡意請求堆積半連線 → 先做低成本檢查並設定分階段配額。
• 只使用全域限流 → 大租戶或單一頻道互相影響 → 同時按租戶、憑證、頻道與來源限流。
• 把 SDP 原文寫入日誌 → 可能洩露地址與拓撲 → 記錄摘要、錯誤類別與關聯 ID。
• DELETE 不具冪等性 → 網路重試造成重複清理或 404 噪音 → 設計明確終態並重複回傳。
• 用 HTTP 200 表示所有結果 → 客戶端無法區分建立、拒絕與重試 → 依介面語意回傳狀態碼與安全錯誤內容。

追問及應對

攻擊者拿到有效憑證後持續 POST，如何保護系統？

把憑證綁定租戶、頻道與過期時間，在邊緣做令牌桶與並發上限；會話服務再限制 pending 數量與總等待時間。持續觸發門檻時撤銷憑證並保留稽核證據。

ICE 成功但 DTLS 一直失敗，應該重試還是回傳成功？

不能把 ICE 成功當成媒體可用。保持 pending 直到 DTLS 與媒體首包達到就緒條件；逾時則關閉會話並回傳可重試的失敗類別，同時釋放候選與節點資源。

客戶端重複傳送同一個 SDP offer，如何避免重複推流？

優先要求客戶端提供短期冪等鍵，將鍵綁定憑證、頻道與 offer 摘要；重複請求回傳原會話結果。無法證明語意相同時建立新會話，但必須受並發配額限制。

區域入口故障時能否把 WHIP 會話遷移到另一區域？

基礎會話通常不能無縫遷移已建立的 ICE/DTLS 狀態。應讓新入口簽發新會話 URL，客戶端重新 POST，並在舊會話逾時或明確 DELETE 後釋放資源；跨區複製憑證狀態要避免擴大洩露面。