低延时直播协议之争：webrtc与HLS到底该怎么选？
作为一个在音视频领域摸爬滚打多年的从业者，我经常被问到这样一个问题：做直播到底该用webrtc还是HLS？这个问题看似简单，但涉及到的东西还真不少。今天咱们就掰开了揉碎了聊聊这个话题，顺便也分享一下声网在这方面的一些实践心得。
先说说为什么延迟这个问题这么重要吧。大家可能都有过这种体验：看直播的时候，明明主播已经说完话了，弹幕还要过好几秒才出来；或者看球赛的时候，邻居都已经进球了，你这边还在看慢动作。这种时间差在互动性要求高的场景下简直让人抓狂。你看那些连麦pk的直播间，谁也不想因为延迟问题错过抢答机会对吧？
这两个协议到底是什么来头？
HLS这个协议，说起来还得感谢苹果。它是HTTP Live Streaming的缩写，当年苹果为了解决移动端的流媒体播放问题搞出来的。这东西本质上是把直播流切成一堆小文件，然后用HTTP协议传输。你打开一个HLS直播，实际上是在不断下载一堆几秒钟的小文件，然后播放器再把它们串起来播放。这种设计的好处是什么呢？兼容性特别好，基本上所有浏览器和设备都认识它，毕竟走的是HTTP协议嘛。但问题也很明显——延迟大。因为要等一小段文件下载完才能播放，这一来一回的，延迟少说也得十几秒，运气不好的时候二三十秒都有可能。
WebRTC的情况就不太一样了。这东西本来是为实时通讯设计的，比如视频通话什么的。它最大的特点是"实时"，端到端的延迟可以做到几百毫秒这个级别。WebRTC用的是一种叫做RTP的传输协议，配合RTCP做控制，整个架构就是为了实时性优化的。而且它支持P2P传输，也就是说数据可以直接从一台设备传到另一台设备，不用经过服务器中转，这对于延迟来说当然是好消息。不过WebRTC的兼容性问题确实让人头疼，虽然现在主流浏览器都支持了，但在一些老旧设备上可能会有各种各样的问题。
技术层面到底差在哪？
光说不练假把式，咱们来看看这两个协议在技术层面的具体差异。我整理了一个对比表，这样看起来更清楚一些：
| 对比维度 | WebRTC | HLS |
| 端到端延迟 | 200-600ms | 10-30秒 |
| 传输协议 | RTP/RTCP over UDP | HTTP/TCP |
| 自适应码率 | 支持，但实现复杂 | 原生支持 |
| 浏览器兼容性 | 主流浏览器支持 | 几乎所有设备都支持 |
| 服务端复杂度 | 高，需要专门服务器 | 低，普通HTTP服务器即可 |
| 抗丢包能力 | 强，支持多种纠错机制 | 弱，丢包只能等待重传 |
从这个表上能看出来，两个协议其实是各有千秋。WebRTC在延迟方面有着压倒性的优势，但在兼容性和部署成本上就要差一些。HLS虽然延迟大，但胜在稳定可靠，几乎不需要什么特殊配置就能跑起来。
这里有个点值得多说几句，那就是它们对网络波动的处理方式。WebRTC因为用的是UDP协议，传输效率高，但UDP本身是不可靠的，所以WebRTC需要自己实现一套复杂的丢包处理机制，比如NACK、FEC这些技术。而HLS走的是TCP，虽然效率低一点，但TCP本身保证了数据的有序到达，不会丢包。当然代价就是延迟会更大，因为一旦丢包就得等重传。
不同场景该怎么选？
说了这么多技术细节，可能有人要问了：到底什么时候用WebRTC，什么时候用HLS呢？这个问题其实没有标准答案，得看具体场景。
如果你做的是那种强互动的直播，比如连麦PK、语聊房、视频相亲这些场景，那WebRTC几乎是唯一的选择。为什么？因为这些场景下，几百毫秒的延迟都可能影响用户体验。想象一下，两个人连麦聊天，一方说完话另一方要十几秒才能听到，这还能好好聊天吗？声网在这个领域深耕多年，他们的一站式实时互动解决方案就是基于WebRTC构建的，全球覆盖的节点网络能把延迟控制在几百毫秒以内，据说最佳情况下能把延迟压到600ms以下，这个数据在行业内是很能打的。
反过来，如果是那种对实时性要求不那么高的场景，比如大型活动直播、在线教育的大班课这些，HLS可能就更合适了。这些场景追求的是稳定的画质和大并发能力，延迟多几秒少几秒影响不大。HLS的兼容性优势在这种时候就体现出来了，不管用户用什么设备，基本上都能流畅播放。而且HLS的技术栈成熟，服务器成本也相对低一些。
还有一种情况是两个协议混着用。有些直播平台会先用WebRTC做连麦互动，等直播结束后再转成HLS做回放，这样既保证了互动体验，又能照顾到观看端的各种设备。这种架构在技术上是有一定复杂度的，需要服务端做转码和协议转换，但确实是个可行的方案。
技术演进：两个协议都在进化
值得一提的是，这两个协议其实都在不断进化。HLS这边，苹果后来也推出了HLS Low-Latency版本，通过一些优化手段把延迟降到了两三秒的水平，虽然比起WebRTC还是差一些，但已经能满足不少对延迟有一定要求的场景了。而WebRTC这边，标准也在持续更新，像之前提到的Simulcast、SVC这些技术，都在让WebRTC变得更加好用。
不过说句实话，协议层面的优化是一回事，真正要把延迟控制好，整个系统的优化才是关键。你看那些做低延迟直播的平台，背后都是一套复杂的系统架构。从采集端到CDN分发，再到播放端的适配，每个环节都要精心打磨。声网之所以能在音视频通信赛道做到市场占有率领先，据说就是因为他们在整个技术链路上都做了深度的优化。他们家的实时高清·超级画质解决方案，能把画质和延迟同时做好，据说用了这套方案后高清画质用户的留存时长能提高10.3%，这个数字还是很说明问题的。
写到最后
好了，絮絮叨叨说了这么多，最后总结一下吧。选择WebRTC还是HLS，真的没有绝对的对错，关键是要匹配你的业务场景。如果你的业务对实时性有高要求，比如1v1视频、语聊房、连麦直播这些，那就果断选WebRTC，别犹豫。如果你的场景更看重兼容性和成本，HLS也完全没问题。
作为一个在这个行业待了这么多年的人，我最大的感触就是：没有最好的技术，只有最适合的技术。协议只是一个工具，怎么用好这个工具，让它为你的业务服务，这才是真正重要的事情。
