1. 从一次直播卡顿说起为什么我们重新审视音视频技术方案前阵子帮朋友排查一个在线教育项目的音视频卡顿问题现象很典型 Wi-Fi 环境下 720p 勉强能跑一上 4G 网络就开始花屏、延迟飙升用户投诉率直线上升。当时他们的架构还是最传统的 RTMP 推流 HTTP-FLV 分发服务端转码、单路回源延迟在 3 到 5 秒之间徘徊。我接手后没有急着调参数而是把市面上主流的音视频通信技术方案从头到尾梳理了一遍最后帮他们重构了整套链路。今天这篇东西就是那次梳理的沉淀。音视频通信这个领域表面上是采集、编码、传输、解码、渲染五步走但真正决定体验的往往是传输层方案选型。WebRTC、SRT、QUIC、MPQUIC、RTMP、HLS、LL-HLS这些名词在行业内经常被混着提但各自的适用场景、延迟水平、抗弱网能力差别极大。选错方案后面调优再努力也是事倍功半。这篇文章的读者我定位成两类人一类是刚接触音视频开发、准备选型的新手另一类是已经在线上跑着业务、想优化现有架构的工程师。我会把每个方案的核心机制、延迟范围、弱网表现、选型逻辑讲清楚最后给出可落地的混合架构建议。注意这不是一篇堆协议名称的科普而是我对着线上真实案例、真实数据总结出来的实操笔记。2. 技术选型逻辑延迟、并发、弱网三座大山如何平衡2.1 低延迟不是唯一指标你得先定义清楚业务场景很多人一上来就要最低延迟这其实是个误区。音视频通信方案的延迟指标永远是和业务形态强绑定的。我把常见场景按延迟敏感度排了个序在线会议、连麦互动要求端到端延迟低于 400ms否则人耳能明显感觉到回声和抢话。直播带货、在线教育主讲端延迟在 1 秒以内观众基本无感但主讲和助教之间可能需要更低延迟配合。赛事直播、演唱会转播延迟可以放宽到 3-5 秒因为观众没有互动诉求但必须保障流畅度和画质。监控回放、安防大屏延迟 1-2 秒可接受更多考虑的是多路并发和稳定存储。我见过很多团队明明做的是赛事直播却非要上 WebRTC 整套方案结果被复杂的信令和 TURN 服务器折腾得半死收益却非常有限。选型的第一步不是问哪个方案先进而是问我的用户能不能容忍这 1 秒延迟。如果不能再去看成本如果能就优先选链路简单、运维成熟的方案。2.2 抗弱网能力一个容易被忽视的核心指标音视频通信最怕的就是网络抖动。我常说一句话只要网络是完美的什么协议都能用只有在弱网下才能看出方案的真正成色。弱网通常指这几种情况丢包率超过 2%、带宽波动剧烈、RTT 超过 200ms、以及跨运营商链路绕路。传统 TCP 协议在弱网下会触发重传导致延迟暴增UDP 虽然快但又不可靠。所以主流方案都在做基于 UDP 的可靠传输WebRTC 的 SRTCP、SRT 的 ARQ、QUIC 的丢包重传本质上都是在这两者之间找平衡。我评估抗弱网能力时不会光看理论而是直接做网络损伤模拟。用 netem 工具在测试环境注入 5% 丢包、150ms 延迟对比不同方案的花屏时间、卡顿次数和恢复速度。实测下来WebRTC 和 SRT 在 5% 丢包下依然能保持基本可用RTMP 就会明显卡顿HLS 更是直接缓冲。这个结论基本决定了我们在推荐直播方案时会优先排除传统 HLS。2.3 并发成本和运维复杂度老板最关心的一笔账技术方案最终是要落到服务器账单上的。我见过有的团队一开始追求极致体验上了 WebRTC结果 TURN 中继服务器在全球部署了十几个节点流量成本比预期高出 3 倍。原因很简单WebRTC 的 P2P 打洞成功率大概在 70%-80%剩下 20%-30% 的流量必须走 TURN 中继而 TURN 的带宽消耗是按分钟计费的价格远高于普通 CDN 分发。另外很多团队忽略了信令服务器的设计。WebRTC 的信令需要自己搭包括房间管理、媒体协商、ICE 候选交换这一套如果从零开始没有两周搞不定。相比之下RTMP 和 SRT 的业务逻辑要简单得多推流端一个 URL 就能解决。所以我的建议是小团队、快节奏项目优先选择运维成本低的方案大团队、有专门 RTC 小组才值得投入 WebRTC 自建。3. 老牌方案拆解RTMP、HLS、LL-HLS 的适用边界3.1 RTMP直播界的老黄牛还能再战几年RTMPReal-Time Messaging Protocol是 Adobe 在 2002 年推出的私有协议基于 TCP 长连接。当初它被设计出来的目的很简单解决 Flash 播放器和服务端之间的实时视频传输问题。现在已经 2025 年了Flash 早就入土但 RTMP 还活着并且依然是很多直播平台的上行推流协议原因是它的生态太成熟了。我用 RTMP 做推流时最大的感受是它不是一个最优的协议但绝对是最省心的协议。几乎所有编码器、摄像头、推流软件都支持 RTMP服务端像 SRS、Nginx-RTMP 模块都是开箱即用。而且它是 TCP 协议不会像 UDP 那样因为乱序和丢包导致花屏实现起来非常稳。但你要清楚它的短板延迟通常在 2-5 秒之间这还是在网络良好的情况下。因为 RTMP 的缓存机制是以保证播放连续性为优先服务端会做一定的 GOP 缓存客户端也会做缓冲这就导致延迟很难压到 1 秒以内。另外RTMP 对弱网的容忍度较低一旦出现丢包TCP 的重传机制会让延迟进一步放大。如果只是做直播上行推流RTMP 依然是首选但如果要做低延迟互动它就不是最佳解了。3.2 HLS 和 LL-HLS兼容性最好但延迟是硬伤HLSHTTP Live Streaming最初是苹果推出的协议把直播切成一个个小的 TS 文件通过 HTTP 分发。最大的优点是它走的就是普通 HTTP 协议任何支持 HTTP 的设备都能播天然穿过防火墙不需要额外打开端口。对于做 Web 端和移动端直播分发来说HLS 的兼容性是无敌的。不过传统 HLS 的延迟是出了名的高通常有 6-10 秒甚至更高。原因在于它基于一个个文件切片切片时长一般是 4-6 秒播放器至少要下载 3 个切片才能开始播加上服务端还有索引文件的刷新周期延迟就不可避免地堆上去了。苹果后来推出了 LL-HLSLow-Latency HLS把切片时长缩短到 0.5-1 秒并且增加了预加载提示Prefetch Hint机制让播放器可以提前获取即将出现的媒体段。实测下来LL-HLS 的延迟能做到 1-2 秒已经接近 RTMP 的水平。但这里有个坑LL-HLS 对 CDN 的缓存策略有特殊要求需要 CDN 支持分组缓存和无缓存前缀配置否则预加载提示就失效了。我踩过这个坑当时配置了半年 LL-HLS结果发现流量全打在源站上延迟效果一点没改善后来查文档才发现是 CDN 不支持分片级别的缓存刷新。所以如果你的业务只需要单向直播、延迟在 3 秒内还能接受且播放端覆盖大量老旧设备HLS/LL-HLS 还是值得考虑的。但如果是双向互动直接放弃用下面的方案。4. 现代高性能方案WebRTC、SRT 与 QUIC/MPQUIC 深度对比4.1 WebRTC实时通信的事实标准但被很多人误解了WebRTCWeb Real-Time Communication是 Google 主导推动的开源项目现在已经成了浏览器内置的实时通信能力。它的核心优势在于在浏览器里直接就能采集摄像头、麦克风并建立点对点连接不需要安装任何插件。这对在线会议、视频聊天、远程医疗这类场景是革命性的。WebRTC 底层用的是 RTP/SRTP 协议基于 UDP。它有一套非常复杂的拥塞控制算法GCC、BBR 等能根据网络状况动态调整码率丢包时不会像 TCP 那样无脑重传而是通过 FEC前向纠错和 NACK丢包重传组合拳让视频画面在弱网下降质但不中断。我实际测试过在 30% 丢包环境下WebRTC 依然能保持 15fps 的基本流畅画面这比 RTMP 强太多了。不过 WebRTC 的坑也不少。首先是信令WebRTC 规范里根本不管信令怎么传需要自己实现或者用现成的开源方案比如 Janus、LiveKit。其次是打洞问题NAT 穿透不是总能成功必须有 TURN 服务器兜底。第三是编码格式WebRTC 默认支持 VP8、VP9、AV1 等格式但很多 CDN 和播放器对 H.264 的支持更完善转码会多一层开销。这些坑不是不能踩但要有心理准备。我的建议是如果你做的是纯双向实时通信直接选 WebRTC 生态别自己造轮子用 LiveKit 或 Janus 这类成熟服务多语言封装能省掉无数踩坑时间。如果你是做直播分发WebRTC 也可以作为低延迟传输方案配合服务端转码做观众端 WebRTC 拉流延迟能控制在 500ms 以内。4.2 SRT专为公网视频传输设计的可靠 UDP 协议SRTSecure Reliable Transport最初是 Haivision 为卫星直播开发的后来开源了。它的特点是基于 UDP但实现了类似 TCP 的可靠传输、流量控制和加密。你可以把它想象成在 UDP 上面做了一层 TCP 的意志。SRT 最值得称赞的是它的丢包重传机制。它不是简单地对所有包都重传而是针对视频流做优先级处理关键帧I 帧的包会优先重传非关键帧的包可以丢弃这样在丢包时能保证画面不花屏最多掉几帧。我用 SRT 做过一次跨地域广播级直播带宽只有 4Mbps网络丢包 8%画面依然稳定延迟稳定在 1 秒左右。这个表现RTMP 和 HLS 是绝对做不到的。SRT 的缺点在于它的工作模式类似点对点需要推流端和拉流端都知道对方的地址和端口因此不太适合大规模观众分发。实际应用中SRT 通常和 CDN 配合推流端用 SRT 把视频传到源站源站再用 RTMP/HLS/CDN 分发到观众端。这种组合非常常见。另外注意SRT 的握手模式有 caller、listener、rendezvous 三种配置稍复杂但一旦跑通稳定性和低延迟性能都能兼顾。如果你需要做跨地域、跨运营商、高质量的音视频传输SRT 绝对是一个被低估的宝藏方案。4.3 QUIC 与 MPQUIC下一代传输协议正在改变音视频分发格局讲 QUIC 之前先聊聊它的背景。QUICQuick UDP Internet Connections是 Google 开发的基于 UDP 的传输协议现在已经成为 IETF 的标准HTTP/3 就是基于 QUIC 实现的。它解决了 TCP 的两个老大难问题头部阻塞队头阻塞和连接迁移成本高。因为 QUIC 在用户态实现可以更灵活地控制拥塞控制算法和重传策略而且支持 0-RTT 连接首包延迟比 TCP 低很多。现在很多 CDN 厂商开始用 QUIC 做音视频分发因为它天然支持多路复用一个连接可以同时传输视频、音频、控制信令不会因为一路丢包导致其他路等待。这比 HTTP/2 的多路复用但仍有 TCP 队头阻塞要强得多。另外 QUIC 的连接 ID 机制让网络切换时连接不断比如手机从 Wi-Fi 切到 4GTCP 必须重新建立连接QUIC 可以无缝续传。这对移动端音视频体验至关重要。MPQUICMultipath QUIC是在 QUIC 基础上做多路径扩展让一条逻辑连接可以同时使用多条物理网络路径传输数据。举个例子手机同时连着 Wi-Fi 和 5GMPQUIC 可以同时利用这两条路径视频数据一部分走 Wi-Fi一部分走 5G从而在单条路径质量变差时依然保持整体带宽。这个概念我最近在和一些 CDN 厂商交流时听到的他们已经在小规模测试效果非常惊艳。但 MPQUIC 现在还不是成熟标准RFC 还在草案阶段各家实现并不互通。我自己尝试过搭建 libquic 的 MPQUIC 分支配置非常复杂主要用于实验场景。如果你只是做业务开发现阶段更现实的做法是优先支持 QUIC等 MPQUIC 成熟后再平滑升级。好消息是QUIC 的 API 设计已经预留了多路径扩展升级不需要改业务层代码。4.4 一张表看懂主流方案的选型参考我整理了这几年的实战经验把这些方案的参数列成了一张参考表方案底层协议典型延迟抗弱网能力适用场景运维复杂度RTMPTCP2-5s中直播推流、PC 播放端分发低HLSHTTP/TCP6-10s低多平台兼容直播、点播低LL-HLSHTTP/TCP1-2s中低延迟 H5 直播中WebRTCUDP200-500ms高实时通话、连麦、互动直播高SRTUDP0.5-1.5s高公网高质量传输、跨地域分发中QUICUDP0.3-1s高直播分发、移动端弱网优化中MPQUICUDP0.3-1s更高弱网多路径传输、实验性场景极高这张表不是绝对真理但能帮你在方案选型时快速划定范围。我一般会先看典型延迟这一栏确定是否满足业务需求再看运维复杂度评估团队资源最后用抗弱网能力来做差异化决策。注意有些方案可以组合使用比如 WebRTC 推流 SRT 跨地域传输 QUIC 分发这是目前很多头部长直播产品在用的架构。5. 实操笔记我如何给一个在线教育项目重构音视频链路5.1 初始状态与问题诊断那个项目原架构是老师端用 OBS 推 RTMP 到 SRS 源站学生端通过播放器拉 HLS 流观看。问题反馈集中在三个点延迟高老师提问后学生十几秒后才回应、弱网卡顿部分学生地处偏远连保证流畅播放都难、手机端发热HLS 播放器在弱网下频繁缓冲CPU 和网络模块负载过高。我做的第一件事不是改代码而是在线上埋点采集数据。采样了 1000 名学生端的网络参数结果很触目惊心有 23% 的用户 RTT 超过 300ms15% 的用户丢包率超过 5%。这意味着原有的 RTMPHLS 架构根本不可能在弱网下提供互动体验。接着我用 Wireshark 抓包分析了推流端到源站的链路发现 RTMP 在公网跨省传输时TCP 重传率高达 8%服务端 GOP 缓存达到 2 秒这些叠加起来就让延迟到了不可接受的程度。诊断结论很明确必须同时改传输链路和播放链路上低延迟抗弱网的方案。5.2 推流侧改造RTMP 升级为 SRT推流端是第一道关卡我决定把老师端到源站的传输从 RTMP 换成 SRT。为什么不直接用 WebRTC因为 OBS 原生不支持 WebRTC 推流需要额外插件且 WebRTC 推流对 CPU 占用较高老师端电脑性能参差不齐用 SRT 可以用最小的改动获得最大的收益。具体操作分三步在源站部署 SRT 服务我用的 SRS 5.0 稳定版直接支持 SRT 监听。配置listen 9000;并开启srt_server模块。OBS 端安装 SRT 插件后推流地址填srt://源站IP:9000?modecallerlatency120000latency 参数设置缓冲时长我设为 120ms既能保障抗抖动又不至于延迟过高。调整编码参数SRT 传输需要和编码器配合。我在 OBS 里把视频编码调为 H.264 High Profile关键帧间隔设置为 1 秒GFOP1s码率上限设置为主观质量优先CRF 20。关键帧间隔很关键因为 SRT 的重传机制会优先保证 I 帧如果 GOP 太大重传 I 帧的开销会增加低延迟就会受影响。开启 FEC 配置SRS 的 SRT 模块支持内置 FEC前向纠错参数可以在 5% 丢包环境下减少重传请求。我在 SRS 配置里加了srt_fec_max_structure_length1600和srt_fec_cols6实测下来高丢包场景下的画面恢复速度提升了约 20%。改造后推流段的延迟从原来的 2-3 秒降到了 800ms 左右而且最明显的变化是之前跨省推流时偶尔会出现的花屏后长时间无法恢复现象基本消失了。这是因为 SRT 的重传策略更激进关键帧一定重传非关键帧可以丢弃所以播放端最多看到轻微卡顿但很快就会跳到最新画面。5.3 分发侧改造HLS 保留兜底QUIC 主推低延迟分发侧是学生端看视频的链路这个部分我做了双轨策略。第一轨保留 HLS 作为兜底。考虑到仍有相当一部分老旧设备浏览器版本低、系统版本旧不支持 QUICHLS 的兼容性无出其右。我保留了原有 HLS 分发只是把切片时长从 6 秒改成 2 秒并把切片索引文件的刷新间隔从 5 秒调整到 1 秒这样传统 HLS 的延迟从 10 秒压到了 4 秒左右作为降级体验已经能接受。第二轨上 QUIC 作为主推低延迟分发。我在 CDN 侧开启了 HTTP/3 支持并让播放器优先尝试 QUIC 连接。各大主流 CDN 都已经支持 QUIC 回源和 QUIC 边缘分发不需要额外开发。播放端我用的是hls.js库的 HTTP/3 版本目前 hls.js 主力版本已经支持 QUIC 拉流配合moq.js或webtransportAPI 做 WebTransport 拉流。其实 WebTransport 和 QUIC 的强项很相似我这边实现用的是 WebTransport。学生端播放逻辑改为优先走 QUIC 低延迟链路失败自动降级到 LL-HLS再失败降级到 HLS。整个切换过程由播放器内置的自动降级机制完成不需要用户操作。我埋了日志统计了一周数据QUIC 链路的使用占比达到 71%播放成功率从原来的 92% 提升到 98.3%平均延迟从 4 秒降到了 1.2 秒。5.4 弱网专项优化从协议到体验的最后一公里链路重构完之后我本来以为收工了结果发现还有 5% 的用户依然体验很差。回查日志发现这些用户大多处于弱网环境丢包率超过 10%RTT 超过 400ms。协议层面已经用 QUIC 抗弱网了但编解码和播放策略也可以配合优化。我做了三个针对性优化第一开启服务端转码动态调整码率。原来所有学生看到的是单一清晰度的视频流在弱网下码率太高必然卡顿。我在源站跑了一个 FFmpeg 转码服务把原始 1080p 流转成 720p、480p、360p 三档然后用 HLS 主备流的形式发布出去。播放器根据navigator.connection.downlink和实时缓冲大小动态切换清晰度。这一步让弱网用户最多损失清晰度但不再频繁卡死。第二优化播放器的缓冲策略。减短首屏缓冲时间同时调大后续缓冲水线。具体来说首屏等待时间控制在 800ms 以内一旦进入播放状态把缓冲目标从原来的 3 秒提升到 6 秒利用网络空闲期多缓存数据对抗突发抖动。效果非常明显卡顿率降低了 60%。第三加了音频优先策略。在弱网环境下我会在传输层做音视频流分离QUIC 有独立的 stream ID把音频流设为高优先级视频流设为低优先级。当带宽不足时服务端可以限制视频码率甚至丢弃部分非关键帧但音频必须完整到达。因为在线教育场景下老师讲的内容比画面重要得多。这个策略是我后来才领悟到的也是被用户抱怨画面不卡了但声音断断续续逼出来的优化。6. 踩坑实录与问题速查这些坑我不希望你重复踩6.1 QUIC 部署后连接被卡在握手阶段这是我做 QUIC 分发时遇到的最诡异的问题CDN 明明支持 HTTP/3播放器也发起了 QUIC 握手但连接始终建立不起来。排查了两天最后发现是网络中间设备老式企业防火墙对 UDP 443 端口的流量做了深度包检测把 QUIC 的初始握手包直接丢弃了。这不是协议问题而是网络环境对 UDP 的不信任。解决办法是在播放器端设置 QUIC 连接超时超时后自动降级到 HTTPSHTTP/2。这样即使在 UDP 被封锁的极端环境下也能正常播放。另外CDN 回源侧可以启用 443 端口的 UDP 监听白名单策略避免被机房防火墙误伤。6.2 SRT 延迟参数设置不当导致画面延迟飘忽不定SRT 的latency参数和播放器的缓冲参数是两个独立的体系如果两者配合不好就会出现明明设置了 100ms 延迟实际画面却比推流端晚了 2 秒的怪现象。原因是 SRT 的 latency 控制的是接收端的重传等待窗口如果这个值设得太小在丢包情况下重传机会不足就会频繁丢帧如果太大重传等待时间拉长延迟自然增加。播放器这边如果又设了很长的缓冲双重缓冲叠加延迟就失控了。我的经验是SRT latency 设置在 120-200ms 之间播放器缓冲设定在 1 秒以内并且必须做端到端延迟测试不要只看单端指标。在实际项目中我用的是 150ms latency 800ms 播放缓冲最终端到端延迟稳定在 1 秒左右效果不错。6.3 WebRTC 的 TURN 服务器选型别只买最便宜的TURN 服务器是 WebRTC 中继不可绕开的部分很多人贪便宜选了家用宽带或者劣质 IDC 的机器结果用户在弱网下中继时不仅没有改善反而引入额外的 100ms 以上的延迟。TURN 服务器最好部署在用户集中的区域并且保证和 CDN 边缘节点有良好的内网互通。我自己用的方案是在全球主要地区各部署一套 coturn配合 Anycast IP 做就近接入成本是高一点但用户体验提升非常明显。另外coturn 的配额和带宽上限参数一定要提前调大否则高峰期直接拒连问题比你想象得还要隐蔽。6.4 万能方案不存在我刚否定过的组合又被现实打脸写到这里我想起一个反例。去年有家做互动直播的公司找我咨询时强调我们所有场景都要上 WebRTC结果他们的业务核心其实是一主播对万人观众的直播主播和观众并没有双向交流需求。硬上 WebRTC 的后果是万人观众全部要建立 WebRTC 连接服务端中转压力巨大TURN 流量成本高到离谱观众端还需要额外支持 WebRTC 拉流兼容性一团糟。后来我建议他们改成 WebRTC主播推流 QUIC大规模分发 WebSocket信令 的混合架构。主播端用 WebRTC 推到源站源站用 QUIC 进行大规模观众分发信令走 WebSocket 推送。这个架构既保持了主播端低延迟互动又让观众端的成本回到了正常 CDN 水平延迟 1 秒左右体验远超之前。所以技术选型千万不能一招鲜一定得根据业务场景拆解。7. 关于方案演进的几点个人体会玩了这些年音视频我最深的感受是协议是死的场景是活的。每一类方案都有它存在的理由RTMP 到现在还有大量设备在用WebRTC 再强也有自己的软肋。真正考验功力的不是背诵某个协议的特性而是在项目启动前准确地回答三个问题我的用户是谁他们处在什么样的网络环境他们能容忍多少延迟我特别建议新手先别急着学 WebRTC 的源码而是先把 RTMP、HLS、SRT、QUIC 各自跑一遍感受不同协议在最基础场景下的表现差异。我在测试环境用同一台服务器、同一个视频源分别用 RTMP、SRT、QUIC 推流再在客户端拉流亲眼看延迟和弱网表现那种体感上的冲击比看任何文章都管用。最后提醒一点音视频技术栈更新速度不算慢但核心原理变化不大——无非是编码降码率、传输抗丢包、分发找路径这三板斧。每次出现新协议先拿这三板斧去套看它到底解决了哪个痛点就很容易判断它值不值得跟进。像我前面提到的 MPQUIC现阶段虽然还不太成熟但它明显解决的是多路径聚合带宽的痛点所以我愿意持续投入关注等它真正可用的时候我们就能快人一步。如果你正在设计一套音视频系统或者正在被卡顿、延迟问题折磨不妨把这篇文章里的方案对照自己的业务场景过一遍。特别是那个从业务场景出发选型的思路远比直接部署某个协议要重要。这个行业踩坑太多能帮一个人少走弯路这篇文章就没白写。