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