企业官网建设流程全解析

1. 先想清楚：我们在讨论“取代”时，到底在讨论什么

前两天我把一台摄像头、一台笔记本编码器、两个手机浏览器和一台 SmartMediaKit 服务器串起来做了一组实验，目标很简单：回答那个被反复问的问题——WHIP/WHEP 到底能不能取代 RTSP、RTMP？

跑了几天之后，我得出的结论不算中庸：能，但只会在它该取代的地方取代。这不是和稀泥，而是因为这三套协议背后的生态位完全不同。RTSP 是监控和广电设备之间的“手拉手”协议，RTMP 是 CDN 分发链路里的老黄牛，WHIP/WHEP 则是浏览器原生实时互动时代的新入场者。它们看起来都在传视频，实际上各自解决的问题差异非常大，讨论取代之前必须先把这些差异拆开。

先说清楚三个基本事实。第一，RTSP 和 RTMP 都是上个时代的产物，设计时根本没考虑“浏览器可以直接播放”这件事；RTSP 依赖大量附加信令和多端口传输，RTMP 虽然走单一 TCP 端口，但播放端一直以来强依赖 Flash 或专用播放器。第二，WHIP/WHEP 的本质不是新编码，而是把 WebRTC 里复杂的 SDP 协商过程压缩成一条 HTTP 请求，让任何支持 WebRTC 的浏览器都能以极低的门槛推流和拉流。第三，SmartMediaKit 这类流媒体服务器做的事情，是把几套协议统一收编成内部媒体流，再按需分发出去，所以它天然是观察这场“取代”的最佳试验台。

这篇文章我会用我实际搭建 SmartMediaKit 的配置、推拉流命令、延迟测试数据和踩坑记录，尽量把这个问题讲透。适合正在做低延迟直播、WebRTC 接入、安防流媒体平台，或者在纠结要不要把现有 RTMP 架构改造成 WHIP/WHEP 的开发者看。

1.1 两个新协议到底解决了谁的痛点

WHIP 是 WebRTC-HTTP Ingestion Protocol，WHEP 是 WebRTC-HTTP Egress Protocol，看名字就知道它们是一对：一个负责推流，一个负责拉流。它们做的事情可以理解成“给 WebRTC 装了一个极简 HTTP 门把手”。

以前要在浏览器里推流，最痛苦的不是编码，而是信令。WebRTC 本身是一套点对点媒体传输体系，两个端必须交换 SDP（Session Description Protocol），交换 ICE candidate，处理 NAT 穿透，维护 PeerConnection 状态。这些术语听着就头大，实际调试起来更是能熬掉半条命。WHIP 把“创建 offer -> 交换 -> 拿到 answer”这一整套流程收敛成了一个 POST 请求：你把本地生成的 SDP 作为请求体发给服务器，服务器把 answer SDP 作为响应体返回，推流通道就建立起来了。整个过程浏览器原生 API 就能跑，不用引入任何 SDK。

WHEP 同理，拉流端拿到一个播放地址后，通过一条 HTTP 请求和服务器完成协商，然后直接消费 WebRTC 媒体流。对前端工程师来说，这意味着不再需要搞清楚什么叫 DTLS，什么叫 SRTP，只需要知道 fetch 一个地址、拿回一个 answer、把媒体流怼给 video 标签。

所以 WHIP/WHEP 真正解决的痛点是“浏览器到媒体服务器之间最后那一公里的接入成本”。以前这一公里要么靠 Flash，要么靠 WebSocket 中转视频数据，要么靠插件，体验和工程成本都一言难尽。现在浏览器里直接跑 WebRTC，延迟又是毫秒级，这在交互直播、在线教育连麦、远程操控这些场景里是刚需。

1.2 RTSP 和 RTMP 最核心的“家底”在哪里

RTSP 活了这么多年，最大的家底是安防设备生态。市面上绝大多数网络摄像头、NVR、视频编码器都把 RTSP 作为默认输出协议，很多监控平台的标准接入规范也建立在 RTSP/RTP 基础上。它采用 C/S 模式，信令走 RTSP，媒体走 RTP，传输可以选 UDP 或 TCP，而且天然支持回放控制：PLAY、PAUSE、TEARDOWN 这些命令就是干这个的。只要你想做摄像头接入、录像回放、PTZ 控制这类功能，RTSP 依然是绕不开的存在，WHIP/WHEP 目前根本覆盖不了这个领域。

RTMP 的家底则在 CDN 分发链路和推流终端上。直播平台的老架构里，OBS 推流到边缘节点、节点之间转推、源站接入，绝大多数走的是 RTMP。虽然近年来很多平台把播放侧换成了 HTTP-FLV、HLS，但“推流进入直播网络”这一步，RTMP 依然是大规模使用的方案。大量硬件编码器、无人机遥控端、嵌入式设备把 RTMP 当作标准能力在做，这个存量市场非常庞大。

换句话说，RTSP 统治着“设备到设备”的专网世界，RTMP 统治着“采集端到分发网络”的传统互联网直播世界，而 WHIP/WHEP 目前主要拿下的是“浏览器到服务器”的实时互动世界。三个世界有交集，但远没到完全重叠的程度，这就是我开头说“只能在该取代的地方取代”的原因。

2. 协议对比：浏览器、延迟、NAT穿越，三个维度看差别

要判断能不能取代，最直接的办法是把它们放在同一个维度上量。我把 SmartMediaKit 作为共同的中转点，让同一路视频分别走 RTSP、RTMP 和 WHIP/WHEP 拉流，记录端到端延迟、接入复杂度、NAT 表现，下面这张表是我这套环境的实测结果和长期经验值。

2.1 最直观的差别在延迟与媒体协商方式

延迟差异是最能给人直观冲击的部分。我在同一台服务器上，用同一路 ffmpeg 编码的视频流分别验证：RTSP 走 TCP 时延大约在 180ms 上下，WHIP/WHEP 在 Chrome 里实测约 220ms，这两者基本处于同一个量级，都属于“实时”范畴。RTMP 转 HTTP-FLV 则通常在 1 到 3 秒，主要瓶颈是播放器为防抖动设置的缓冲，以及 RTMP 本身偏重稳定性的传输设计。

媒体协商方式的对比更有意思。RTSP 的会话过程是先 OPTIONS 探测、DESCRIBE 拿描述、SETUP 建立传输通道、PLAY 开始播放，一套组合拳打下来，服务端还要在额外端口上跑 RTP/RTCP。RTMP 走 1935 端口，握手之后在一个长连接里复用 chunk，逻辑上简单，但协议格式非常繁琐，靠道听途说很难调通，必须啃规范。到了 WHIP/WHEP 这里，整个过程简化成人类一眼能懂的行为：发一个 POST 请求，拿到一个 SDP answer，完事。

打个比方，RTSP 是去政务大厅办事，每个窗口都要排队交材料；RTMP 是拿了号在一个窗口把所有事办完，但那个窗口的业务员规矩特别多；WHIP/WHEP 是全程线上点一个按钮，后台自己把事办了。这也是为什么大量前端团队接触 WebRTC 时容易一头雾水，但封装一层 WHIP/WHEP 之后，接入成本能大幅下降。

2.2 真正决定选型的是应用场景而不是协议性能

很多人对比协议时喜欢把延迟和吞吐量当成唯一标准，我觉得这是误区。实际决定你选哪套方案的，是你手里最核心的应用场景。

如果你做的是监控和安防，摄像头设备固定支持 RTSP，平台还要做录像、回放、报警联动，那 WHIP/WHEP 现阶段根本替代不了。最多是上层用 WHEP 做 Web 端低延迟预览，底层接入依然是 RTSP。如果你做的是秀场直播、赛事直播这种传统 CDN 分发模式，RTMP 推流 + HTTP-FLV/HLS 播放的组合极其稳定，整个链路都有非常成熟的运维体系，没必要为了“新协议”三个字去重构。但如果你做的是在线教育、视频连麦、远程操控、网页端低延迟监控这类强互动场景，用户就是用浏览器打开网页，那 RTSP 和 RTMP 都差点意思，而 WHIP/WHEP 几乎是为这个场景量身定做的。

还有个容易被忽略的点是网络穿越能力。WHIP/WHEP 底层是 WebRTC，自带 ICE 框架，通过 STUN 服务器发现公网地址，通过 TURN 服务器在点对点失败时中继流量，所以在复杂的家庭网络、企业 NAT、4G/5G 移动网络下更容易连通。RTSP 要穿透 NAT 非常痛苦，通常得给摄像头做端口映射，或者依赖流媒体服务器主动从内网拉流；RTMP 虽然只要放行一个 TCP 端口，但在一些限制严格的办公网络里，非标准端口经常被掐。别小看这一层，很多项目跨公网联调时，最后都被卡在网络穿透上。

3. SmartMediaKit 是怎么同时扛下四路协议的

光谈协议不落到服务器上没有意义。我选择用 SmartMediaKit 做这个对比实验，主要是看中它比传统流媒体服务器的协议面更宽：RTSP 拉流推流、RTMP 推流、HTTP-FLV/HLS 分发、WebRTC 推拉流都能接，内部有一套统一媒体流转发机制。简单说，它把输入协议和输出协议解耦了，你从任何一路推进去，都可以从任何一路拉出来，这正好用来验证“一条输入，多条输出”的场景。

它的核心设计思路可以概括成三层：接入层负责接收各种协议的推拉流请求，内部媒体层是统一轨道抽象和流转发逻辑，输出层再根据请求协议把媒体流重新封装分发。这样做的好处是，上游新增一种采集协议不需要重写下游所有播放能力，反之亦然。当你需要同时服务 RTSP 播放器、浏览器播放器和移动端 App 时，这种分层的价值会非常明显。

3.1 选择 WebRTC 承载 WHIP/WHEP 的底层逻辑

WHIP/WHEP 只是信令层协议，真正的媒体传输是 WebRTC。所以 SmartMediaKit 要支持它们，本质上是要做好一个 WebRTC 网关。WebRTC 的核心能力是 P2P，但服务器端介入时通常是 SFU 或网关角色，把每个端过来的 RTP 包接收、重写、转发。

这里有几个关键点。第一，编解码器协商必须灵活。WebRTC 的 SDP 里会带 PT（Payload Type）映射、H264 profile-level-id、VP8/VP9 支持情况等一堆参数，网关需要能正确解析并且把参数透传给其他端。实际项目里我踩过最深的一个坑就是 H264 的 profile 协商不一致，推流端是 High Profile，拉流端只支持 Baseline，画面直接绿屏或黑屏。第二，SIMULCAST 和 RTX 机制要处理好。分辨率高、码率大的推流端如果开了 Simulcast，会同时发多路不同质量的流，网关要么做多路转发，要么做降级选择。第三，WebRTC 的丢包重传机制和 JitterBuffer 策略会影响上行带宽占用，网关在转发时要平衡延迟和稳定性。

SmartMediaKit 把 WebRTC 网关跟其他协议模块放在同一个进程里，意味着数据可以不经外部转码直接在内存里从 RTMP 流转换到 WebRTC 流。这个架构对延迟控制非常友好，因为少了跨进程、跨网络的拷贝和封装开销。

3.2 搭建和跑通一次真实的推拉流测试

我把我这版的搭建方式写一下，配置可能随着版本更新有变化，但大体流程是一样的。服务端我用二进制包直接启动，配置主体大致如下：

# 按官方仓库 examples 目录调整 [rtmp] addr = ":1935" [rtsp] addr = ":8554" [http] addr = ":8080" [rtc] enable = true # 如果跑在NAT后面，把这里改成服务器公网IP externalIP = "1.2.3.4"

启动服务后，先用 ffmpeg 推一路本地视频流到 RTMP：

ffmpeg -re -stream_loop -1 -i test.mp4 \ -c:v libx264 \ -c:a aac \ -f flv rtmp://127.0.0.1/live/test

然后从三个不同的口子同时拉流。第一个口子走 RTSP，用 ffplay 播放：

ffplay -fflags nobuffer -analyzeduration 1000000 \ -rtsp_transport tcp rtsp://127.0.0.1:8554/live/test

第二个口子走 HTTP-FLV，也就是 RTMP 进来的流重新封装成 FLV 分发，地址直接是 http://127.0.0.1:8080/live/test.flv，用浏览器或 VLC 打开都能放。第三个口子走 WHEP，我写了一个最简页面，用浏览器原生 API 去拉流。

这里要强调一个细节：RTSP 端口我用的是 8554，不是默认的 554，因为很多服务器上 554 需要 root 权限，容易被防火墙盯上，开发环境用 8554 省事得多。RTMP 的 1935 是常规端口，只要保持默认就行。WHEP 的地址格式一般是 http://127.0.0.1:8080/live/test/whep，具体路径要看版本规则，拉流端直接 fetch 这个地址拿 SDP answer。

我拉流时的关键 JS 逻辑大概是这个思路：

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:127.0.0.1:3478' }] }); const offer = await pc.createOffer(); await pc.setLocalDescription(offer); const resp = await fetch(whepUrl, { method: 'POST', headers: { 'Content-Type': 'application/sdp' }, body: pc.localDescription.sdp }); const answerSdp = await resp.text(); await pc.setRemoteDescription({ type: 'answer', sdp: answerSdp }); pc.ontrack = (evt) => { video.srcObject = evt.streams[0]; };

这段逻辑不复杂，但很多新手会挂在本地 SDP 和远端 answer 的先后顺序上。要注意在 createOffer 之后必须先 setLocalDescription 拿到本地 SDP，才能把这个 SDP 发出去；应答回来之后还要 setRemoteDescription，整个协商才算闭环。

3.3 一次公网 NAT 穿透实验带来的意外收获

初次公网联调时，我图省事把 SmartMediaKit 直接跑在一台云主机上，云主机安全组放行了所有 UDP 端口，但浏览器那边一直黑屏，PeerConnection 的 ICE 状态停在 checking 不往下走。

排查链路是这样的：先看信令层，拉流页面已经成功拿到 answer SDP，说明 HTTP 交互没问题；再看媒体层，浏览器控制台没有明显的报错；最后打开 WebRTC 的 candidate 日志，发现拉流端拿到的 answer 里，candidate 全是云主机内网地址 10.x.x.x，而浏览器尝试去连这个内网地址当然连不上。

问题根源是，SmartMediaKit 跑在 NAT 后面，它给自己上报的候选地址是内网网卡地址，STUN 没有拿到正确的公网映射。解决办法有两个：一是把服务配置里的 externalIP 改成云主机公网地址，让它在生成 SDP 时直接携带公网 candidate；二是架设 TURN 服务，在用户网络无法点对点穿透时走中继流量。我两个方案都试过，发现 local 场景下 externalIP 配置最立竿见影，而公网跨运营商、跨地域场景下 TURN 才是最稳妥的兜底方案。

这个坑几乎人人会踩。尤其是在 Docker 里跑流媒体服务时，容器网络默认是 NAT，服务对外看到的网卡地址和宿主机公网地址完全不同，不显式指定 externalIP 就一定会出现候选地址错误。我的习惯是无论本地还是云上，只要部署环境存在 NAT，就一定要检查服务产生的 SDP 里的 candidate 是不是可达地址。

4. 从实测看延迟：把参数调到可用级别

WHIP/WHEP 被吹得最多的就是低延迟，但“低延迟”三个字不是白来的。WebRTC 的优势是传输层实时性好，但推流端、服务器、拉流端任何一个环节没调好，延迟照样飙升。这一节我把测试方法和细节参数讲透。

4.1 延迟到底能压到多少，怎么量的

我测延迟的方法很朴素但很准确：推流端电脑屏幕放一个毫秒级计时器页面，拉流端设备拍一张照片，两边计时器差值就是端到端延迟。同一局域网环境下，剔除首帧加载影响后的稳态延迟数据大概是这样的：

注意这里说的“HTTP-FLV 延迟 1 秒以上”不代表所有 RTMP 场景都这样，它在弱网下的抗抖动能力是通过缓冲区换来的。如果你把播放器的 buffer 调小，也能把 HTTP-FLV 的延迟压到 500ms 左右，但弱网下卡顿会明显加剧。而 WHEP 的延迟能稳定在 200ms 左右，主要得益于 WebRTC 自身的 JitterBuffer 算法和丢包重传机制是动态适应的。

如果你也想做一轮对比测试，我的建议是严格控制变量：同一台推流端、同一路由网络、同一个视频源、同一台服务器，只切换拉流协议。测的时候不要把首帧时间和稳态延迟混在一起统计，首帧时间受播放器初始化影响大，稳态延迟才代表协议的实时性能。

4.2 那些让延迟失控的隐藏因素

参数调对之后，延迟还可能被几个隐藏因素拉爆。第一个是编码器的 GOP 设置。如果推流端的关键帧间隔太大，拉流端加入会话后必须等下一个关键帧才能出画面，轻则黑屏几秒，重则一直卡在缓冲。对低延迟场景，我建议把关键帧间隔设置到 1 到 2 秒，比如 30fps 下 GOP 给 30 或 60。第二个是 B 帧。WebRTC 的实时传输对帧顺序很敏感，B 帧依赖后续帧才能解码，在弱网下会显著增加延迟和花屏概率。ffmpeg 推流时我通常加-bf 0强制关闭 B 帧，x264 编码参数里再补上-x264-params keyint=60:scenecut=0固定关键帧间隔。

第三个隐藏因素是播放端自动协商的拥塞控制策略。WebRTC 的 GCC（Google Congestion Control）会动态调节码率，如果推流端码率设置过高，网络出现拥塞时它会经历一段下行码率退化过程，画面会突然模糊，延迟反而轻微上升，等拥塞缓解后再尝试恢复。以前在固定码率场景下没有这种动态反馈，很多从 RTMP 转过来的人会不适应这种“码率会自动降”的行为，其实这是为了保住实时性。

第四个因素是服务端的转发策略。如果服务器支持转码，转码本身会引入几十到几百毫秒的额外延迟；如果只是纯转发，延迟基本可以控制在 10ms 以内。SmartMediaKit 这类支持协议转换但不强制转码的架构，在延迟控制上天然有优势。我的建议是，能不改编码就尽量不改编码，转码留给你真正必须处理的时候。

5. 关于“取代”的结论：路线选择与避坑清单

到这你可能已经发现了，我的核心判断是：WHIP/WHEP 的核心战场是“网页端实时互动”，RTSP 的核心战场是“设备接入与监控”，RTMP 的核心战场是“传统直播分发”。三者短期不冲突，但长期看，凡是需要在浏览器里实现实时视频的领域，WHIP/WHEP 确实会逐步吃掉 RTSP 和 RTMP 的地盘。具体到业务决策，我给你一套比较实用的判断方法。

5.1 什么业务适合现在就切 WHIP/WHEP

如果你的产品形态是用户用浏览器就能完成的视频操作，那现在切换是性价比最高的时机。典型场景包括视频面试、在线医疗问诊、直播连麦、远程摄像头网页预览、大屏监控、无人驾驶远程操控等。这类业务有几个共同特点：用户不能安装任何软件、延迟要求低于 1 秒、播放端可能是五花八门的终端设备。

我经常给团队的建议是，用 WHIP/WHEP 可以大幅降低前端的播放器集成成本。以前安卓端要缓存 RTSP 流，得集成 VLC 或者 ExoPlayer 做一堆适配，iOS 端又要考虑 HLS 的延迟问题；现在只要用 WebView 打开一个 WHEP 页面，原生播放能力直接被浏览器接管了，这在“只说给内部做工具”的项目里尤其爽，前端一个人就能扛起来。

SmartMediaKit 这类服务器在这里的角色就是一个统一的媒体入口：采集端不管是摄像头推送 RTSP，还是编码器推送 RTMP，进到服务器之后，浏览器用户统一用 WHEP 拉流。这样既能继续吃存量设备，又能给用户提供实时互动的体验。

5.2 什么业务暂时不切也不要焦虑

如果你做的是广电级的直播转播、大规模赛事、秀场直播，传统的 RTMP 推流加 CDN 分发链路已经非常成熟，我确实不推荐为了追新而追新。RTMP 生态的好处是每个环节都有完整的监控、限流、转码、录制方案，而这些能力在 WHIP/WHEP 的世界里还在慢慢积累中。

你在做监控存储与回放这种偏后端能力的需求时，也暂时不需要过多考虑 WHIP/WHEP。RTSP 的 PLAY/PAUSE/SEEK 控制非常成熟，录像回放和按时间定位播放都有现成机制；WebRTC 不是为文件回放设计的，要在 WHIP/WHEP 之上实现真正的录像控制，得自己在外层补一套信令逻辑，性价比不高。

还有一类大规模观众场景要提醒你：WebRTC 虽然低延迟，但它是为点对点或小规模互动设计的，大规模分发如果要靠服务器逐路转发，带宽和性能成本会爆炸。真正的大规模低延迟直播通常还是要回到 CDN 或 MESH 方案，WHIP/WHEP 可以在入口和出口处做接入，中间分发层依然需要传统架构。

5.3 我在实践中踩过最深的三个坑

第一个坑是浏览器 H264 编解码兼容性。WHIP 推流天然支持 VP8/VP9/H264，但不同浏览器支持情况完全不一样：Chrome 对 H264 的支持受限于授权，Firefox 在部分平台只支持 VP8/VP9，iOS Safari 只硬解 H264，软解 VP8 性能很差。我的解决办法是把 H264 作为首选编码，同时服务端做编解码能力协商，在 SDP 层面保证拉流端能正确解析。如果你不做协商就把 H264 强制推给 Firefox，黑屏是大概率事件。

第二个坑是云服务器公网部署时的 candidate 配置。我在 3.3 里说过，Docker 容器和 NAT 环境里的流媒体服务，如果不显式配置公网 IP，SDP 里的 candidate 全是内网地址。这里有个更隐蔽的分支情况：即便你配了 externalIP，如果云主机没有放行对应 UDP 端口范围，浏览器侧仍然会在 STUN 协商阶段失败。排查时建议先用 WebRTC 的 ICE candidate 日志确认双方地址可达性，再检查安全组和防火墙，别一上来就怀疑代码。

第三个坑是嵌入式设备推流的兼容性。有人问我“ESP32 这类板子能不能直接支持 WHIP”，现实是嵌入式端做 WebRTC 集成非常吃力，码率、内存、音视频同步都很难做。实际项目中更好的做法是让嵌入式设备继续走 RTMP 推流到 SmartMediaKit，服务器转成 WHIP/WHEP 给浏览器播放。这样既保住了嵌入式开发成本，又让 Web 端获得了低延迟体验。我在测试时踩过的是，这类设备推流时码率波动大，服务端如果不做码率缓冲，WebRTC 侧会出现间歇性卡顿，给推流加上平滑缓冲参数之后明显好转。

5.4 回到标题的问题：我的判断

绕了一圈，最后还是那句话：WHIP/WHEP 不会把 RTSP、RTMP 彻底打死，但会吃掉一大块“实时网页互动”的戏份。RTSP 在监控和广电设备侧的地位短期内依旧稳固，RTMP 在存量 CDN 和采集端生态里还能服役很多年，但新一代业务只要面向浏览器，选择 WHIP/WHEP 基本都是少走弯路的方向。SmartMediaKit 这类能同时在四套协议之间自由转换的服务器，会是这个过渡期里最实用的润滑剂——你不用一次性推翻老架构，只需要在最需要实时互动的接入点上，逐步把它们切到 WHIP/WHEP 上。

我在实际调试里最大的体会是：别被新协议的光环冲昏头，也别被老协议的惯性锁死。判断的依据永远是你自己的用户在哪里打开你的视频：如果他们都在浏览器里，那就放心往 WHIP/WHEP 靠。最后再分享一个小技巧，如果你也想快速验证一条流的多协议表现，不要到处找公开的测试地址，自己用 ffmpeg 往本地 SmartMediaKit 推一路循环视频，三分钟就能得到一条稳定可控的测试流，比在公网上一遍遍试别人的源舒服太多。