后端面试：如何设计安全的 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 建立和首包设置独立超时。WHIP 规范指出，带凭证的攻击者可以反复 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 后释放资源；跨区复制凭证状态要避免扩大泄露面。