WHIP 与 WHEP：WebRTC 直播的标准化入口与出口

在实时音视频领域，WebRTC 长期以来被视为“低延迟之王”，但它在广播级直播和大规模分发场景中始终面临一个尴尬现实：能力很强，接入很乱。各家厂商都有自己的信令协议、私有 WebSocket 接口和 SDK，导致编码器、播放器、媒体服务器之间难以互通。WHIP（WebRTC-HTTP Ingestion Protocol）和 WHEP（WebRTC-HTTP Egress Protocol）的出现，正是为了解决这个问题——它们为 WebRTC 定义了标准化的“推流入口”和“拉流出口”，让 WebRTC 从一套技术栈，变成一种可像 RTMP、HLS 一样被标准化使用的协议组合。

一、WHIP / WHEP 解决的核心问题

WebRTC 本身只规范了媒体传输层面的能力，包括 ICE/NAT 穿透、DTLS 加密、SRTP 媒体传输以及 SDP Offer/Answer 媒体协商机制，但它从未定义“信令应该走什么通道、长什么样”。在缺乏标准信令的情况下，行业形成了高度碎片化的实现方式：有的平台使用 WebSocket 自定义 JSON 信令，有的依赖 SIP 或 XMPP，有的直接绑定私有 SDK。这种碎片化直接抬高了接入成本，也让 WebRTC 难以像 RTMP 那样成为“即插即用”的广播级基础设施。

WHIP 和 WHEP 的设计思路非常直接：将信令交换简化为一次 HTTP POST 请求。客户端通过 HTTP 向服务端提交 SDP Offer，服务端返回 SDP Answer，完成会话协商后，媒体仍然走 WebRTC 原生的 UDP/SRTP 通道。HTTP 在这里只负责会话控制，不承载音视频数据，这一点非常关键——WHIP/WHEP 并不是“HTTP 传输视频”，而是“用 HTTP 把 WebRTC 会话建起来”。

二、WHIP：标准化的 WebRTC 推流协议

WHIP 全称为 WebRTC-HTTP Ingestion Protocol，已于 2025 年 3 月正式成为 IETF 标准（RFC 9725）。它的定位非常清晰：为编码器、OBS、FFmpeg、浏览器采集端等提供统一的 WebRTC 推流接口。

在 WHIP 流程中，客户端首先向服务端指定的 WHIP Endpoint 发起 POST 请求，Content-Type 为 application/sdp，请求体中携带一个 sendonly 的 SDP Offer。服务端收到后返回 201 Created 状态码，响应体中包含 recvonly 的 SDP Answer，并在响应头中通过 Location 字段返回该会话的资源地址。随后，客户端与服务端基于 ICE 和 DTLS 完成连接建立，音视频数据通过 SRTP 流向服务端。会话过程中，客户端可通过 PATCH 请求更新 ICE 候选，通过 DELETE 请求主动断流。

WHIP 的最大价值在于“简单”。它只需要一个 HTTPS 地址和可选的鉴权信息（如 Bearer Token），即可完成推流接入，无需 WebSocket、无需私有 SDK、无需复杂的信令握手逻辑。这种特性使得 WHIP 能够天然适配现有网络基础设施，包括 Nginx、Envoy、各类 API Gateway、CDN 以及 Kubernetes Ingress，同时也让硬件编码器、嵌入式设备更容易支持 WebRTC 推流。

当然，WHIP 的边界也非常明确。它不负责转码、录制、分发或大规模观众接入，这些能力仍然依赖媒体服务器、SFU 和 CDN。WHIP 只解决一件事：让 WebRTC 推流拥有一个像 RTMP 一样简洁、标准化的接入方式。

三、WHEP：标准化的 WebRTC 播放协议

WHEP 全称为 WebRTC-HTTP Egress Protocol，目前仍处于 IETF 草案阶段（draft-ietf-wish-whep）。它解决的是另一端的问题：如何让浏览器、APP、机顶盒或播放器以标准化方式从媒体服务器拉取 WebRTC 流。

WHEP 的流程与 WHIP 高度对称。播放器向 WHEP Endpoint 发起 POST 请求，携带 recvonly 的 SDP Offer，服务端返回 sendonly 的 SDP Answer 和会话资源地址，随后通过 ICE/DTLS 建立连接，媒体数据从服务端流向客户端。播放器通过 DELETE 请求结束会话。部分实现还支持服务端发起 counter-offer、通过 Server-Sent Events（SSE）推送观众数或码率层变化等扩展能力。

WHEP 的意义在于，它让 WebRTC 播放不再依赖厂商私有 SDK 或复杂的前端信令逻辑。任何兼容 WHEP 的播放器，都可以播放任何兼容 WHEP 的服务端流。对于浏览器场景而言，这意味着可以在不引入额外插件或 SDK 的情况下，实现亚秒级延迟的直播观看体验，非常适合体育赛事、在线拍卖、互动课堂、云游戏等低延迟需求强烈的场景。

四、WHIP / WHEP 与现有协议的定位关系

理解 WHIP 和 WHEP，必须厘清它们与 RTMP、HLS、SRT 等协议的关系。RTMP 仍然是成熟的推流协议，生态完善，但在延迟和安全性上已显老化；HLS 及其低延迟变体（LL-HLS）是大规模分发的事实标准，延迟通常在数秒级；SRT 则在公网长距离回传和演播室链路中表现优异。WHIP/WHEP 并不是为了取代这些协议，而是补齐 WebRTC 在广播级工作流中的标准化缺口。

在一个典型的现代直播系统中，WHIP 常用于编码器或 OBS 将低延迟流推入媒体服务器，媒体服务器再通过 WHEP 向少量互动观众或监看端提供超低延迟观看，同时通过 HLS/LL-HLS 向 CDN 分发，服务大规模普通观众。这种混合架构充分发挥了各协议的优势，而 WHIP/WHEP 则承担了“低延迟实时环”的标准接口角色。

五、常见误区与边界认知

关于 WHIP/WHEP，有几个常见误解需要澄清。首先，WHIP/WHEP 并不降低延迟，低延迟是 WebRTC 本身的能力，WHIP/WHEP 只是降低了接入 WebRTC 的复杂度。其次，WHEP 并非“HTTP 播放视频”，HTTP 仅用于 SDP 交换和会话控制，真正的音视频数据仍然走 UDP/SRTP。再次，WHIP/WHEP 不能替代 SFU 或 CDN，它们只负责会话建立，大规模分发、多码率适配、网络抗丢包等能力仍需依赖完整的媒体服务器和分发网络。最后，尽管 WHEP 尚未成为 RFC 标准，但 Cloudflare、Dolby、LiveKit、Ant Media、OvenMediaEngine 等平台已经在实际生产环境中支持 WHEP，生态成熟度足以支撑商用。

六、总结

WHIP 和 WHEP 的出现，标志着 WebRTC 从一套“前端黑魔法”走向可标准化、可工程化的广播级技术栈。WHIP 定义了“如何把流推给 WebRTC”，WHEP 定义了“如何从 WebRTC 拉流观看”。两者配合，让 WebRTC 终于拥有了类似 RTMP 的简洁接入体验和类似 HLS 的通用播放能力，而底层依然保持着亚秒级延迟和强实时性。

对于架构师和开发者而言，WHIP/WHEP 的价值不在于替代现有协议，而在于为实时音视频系统提供一套清晰、可互通的接口标准。在未来，随着 WHEP 标准的逐步冻结和 CDN 厂商的广泛支持，WebRTC 有望真正进入广播主链路，成为低延迟直播的默认选项之一。