在低延迟HLS或是WebRTC之间做选择时，哪种协议能够带来最佳的实时流体验？因为协议决定了编码视频数据通过网络连接传输的速度，所以在两者之间做出选择是非常重要的。
Wowza最近发表了一篇包含关于WebRTC和低延迟HLS错误信息的文章。尽管正确地说明了WebRTC是提供实时延迟的唯一办法，它们还是重复了一些很普遍的误解，特别是一个经常被提及的神话：WebRTC没有扩展性。该说法也被Red5 Pro以及其他人完全否定了。
进一步的分析之后，在Red5 Pro的调查者提出了选择协议时我们需要考虑的五个主要因素。这些因素也正好是Wowza大部分搞错的。它们包括：延迟、可扩展性、多设备兼容性、较差直播条件下的性能，以及安全性。让我们从实时流中最重要的延迟这一方面来深入讨论这些因素的细节。
1 延迟
延迟对于实时流来说至关重要。从简单直接的视频对话到更精确的事情，例如控制无人机，这些实时用例只能允许500毫秒的延迟。任何高于500毫秒的延迟都难以被接受。正如Wowza所说的：“低延迟非常重要。[…] WebRTC的构建采用了双向实时通信，使其成为了市场上最快的协议。”这也是我们所同意的地方。WebRTC确实是现今最快的、得到最广泛支持的协议。
HLS基于长期建立并且根深蒂固的HTTP基础结构，导致其当前得到了广泛的使用。这种老式的基础结构也解释了为什么HLS会有10-40秒的延迟。
然而，有一些方法可以修改HLS来达到降低延迟的目的。Apple公司有自己的Apple Low Latency HLS （LL-HLS）工具，类似于开源的Low-Latency HLS（LHLS）。它们都能够将延迟降低到2到3秒左右。虽然它们降低了延迟，但是他们都没有办法享受标准HLS的广泛兼容性。
为了提高LLHLS的兼容性，Apple在2020年初宣布废除超文本传输协议第2版（HTTP/2） 推送要求。这样的话，看起来整个HLS规范将最终达到3秒左右的延迟。尽管这已然不是完全实时的，但肯定比40秒的延迟要好。
作为一个基于UDP，并且为完全适应现代互联网所搭建的协议，WebRTP支持500毫秒的实时延迟。这也意味着它是现今唯一收到广泛支持，并且能够能够提供实时延迟的协议。
2 可拓展性
WebRTC比HLS难扩展得多。但是这并不意味着它没有扩展性，特别是考虑到它已经被实现过。
微软就是一个扩展WebRTC的成功案例。2016年八月，微软收购了Beam。Beam是一个基于WebRTC的实时游戏直播方法，旨在解决直播延迟问题并且在Twitch平台上提供更好的体验。一年之后，微软将Beam改名为Mixer。尽管他们最终关闭了Mixer游戏直播平台，但这只是因为无法吸引足够多的用户，而不是没有能力支持大量用户。一位受欢迎的，名叫Ninja的游戏主播在Mixer上主持的直播吸引了85000名观众同时观看，并在8.5小时内吸引了总共220万观众。
根据Wowza所说，“如果您需要将观众规模扩大到50以上，则需要三思而后行。”他们还声称，在最好的情况下，Wowza流媒体引擎能够扩展到多达300个基于WebRTC的观众。使用他们的系统时，如果超过了这个范围，就需要将WebRTC转为HLS或者DASH，导致延迟增加。
Wowza在扩展中遇到的困难是来自他们对WebRTC的实现，而不是协议本身。在这种情况下，Wowza的流媒体引擎本质上充当了一个单一服务器的SFU。其实，它只使用了一台机器来处理所有的工作，这意味着他在连接、RAM以及CPU等方面不能超出单一服务器可以处理的范围。广播或发布流会被传到一个单一的SFU服务器，所以一旦该SFU中所有的资源都被消耗掉时，它就不能再增加任何信息了。
无论使用什么协议，应用程序的扩展都会增加其消耗的CPU和RAM。当您的主机提供商使用固定的数据中心（如CDN）时，实现这种增加的需求代表着增加额外的服务器或者增加服务器容量。如果需求高于预期，或者仅仅是需要一点额外的容量，都可能成为一个问题，因为您最终可能会支付比您需要的大得多的服务器。当然，对于使用CDN服务的开发者来说，这一切都是抽象的，这也是为什么使用这类设置如此吸引人的原因。问题是，如果CDNS使用HTTP来扩展，会带来巨大的延迟。
这就是为什么您需要以WebRTC为协议的集群解决方案。如果它能根据云基础设施进行自动扩展就更好了。这类的自我扩展方案，涉及到从基于数据中心的静态CDN模型转变为一个基于云的更加灵活的模型。当网络流量增加，服务器集群可以被设置为动态地旋转新的服务器。当不再需要它们时，可以将这些服务器旋转回来。这种方法缓解了很多支付不需要的服务器容量的问题。
3 多设备兼容性
确保您的应用能在各种设备上运行当然是非常重要的。无论是移动设备、笔记本还是平板电脑，您都需要完整的浏览器和平台支持。
它唯一支持的本地桌面浏览器是Safari。其他所有的浏览器都需要使用JavaScript编写的自定义播放器。虽然有像JWPlayer这样的商业产品作为选择，开源的hls.js也是一个可选的解决方案。然而，目前为止，只有很少的播放器已经更新支持苹果新推出的低延迟HLS协议。
作为一种新的网络标准，WebRTC被所有主流浏览器的最新版本完全支持。其中包括Chrome、Safari、Firefox、Edge还有Opera。不仅如此，它还可以在本地浏览器中运行，并不需要插件的帮助。这其中包括了为IOS和Android设计的移动浏览器。当然，利用移动SDK创建专门的应用也是没有问题的。
就像其他事一样，所有浏览器的实现都会略有差别，但没有一样差别会完全阻止其兼容性。Wowza并没有想办法创造跨浏览器的兼容性，而是简单地指责了Safari的不稳定性。作为WebRTC的提供者，我们有责任去想办法让跨浏览器的兼容性发挥作用。完全兼容是绝对可能的，因为包括在Red5 Pro在内的其他组都能够完全支持Safari。我们同意，在保持完整规范的条件下与多种浏览器实现兼容性是很困难的，但这并不意味着做不到。
4 恶劣直播条件下的性能
在质量和性能方面，LL-HLS和WebRTC具有相似的特点，因为他们都支持转码和自适应比特率（ABR）。
ABR允许客户端请求一个更适合他们当时所经历的连接环境的较低比特率。这样做可以确保在连接不良的状态下保持顺利连接。HLS和他的新“表兄”LL-HLS在规范中内置了ABR。这是由一个包含了变量的主清单文件来实现的。当播放器检测到视频传输速度不够快，从而检测到带宽不足时，它可以很容易地请求清单中的某个低流变量。接着，它就可以以比较低的比特率下载新的视频片段。
对于WebRTC来说，情况就大不一样了。在WebRTC中，您会有一个单一的UDP连接，并且视频的传输是通过SRTP进行的。这就代表您不能请求不同的段文件，因为一开始并没有任何段文件。相反地，我们的方法是在边缘服务器上提供多种比特率，这样可以允许客户端请求正确的视频质量。该请求本身是通过RTCP通道，一个用于发送WebRTC会话中每个对等体实时状态信息的双向控制通道。我们接受的具体信息是REMB，其中包含了对等体（在这种情况下是用户客户端）请求的推荐带宽。根据该信息，边缘服务器节点就可以做出响应，转而提供带宽需求的最佳流。
作为补充，HLS和WebRTC都可以依靠流媒体的事实转码来生成这些多比特率变体。转码将流媒体分成了不同的质量等级（例如高、中、低），这样允许了支持最高质量的用户订阅该媒体，并且连接较差的用户也仍然可以观看。
虽然HLS仅限于ABR，但WebRTC还有能够提高质量和性能的其他功能。
鉴于WebRTC是一个基于UDP的协议，其最关键的功能之一就是NACK，它是一种重新发送关键数据包的方法。不好的网络连接很有可能导致客户端丢包。NACK并不会一直尝试重新发送每一个数据包，而是识别出最重要的数据包并试图重新发送。这可以防止因过多请求而导致的网络超载。这种方法会帮助保持流的流动，即使在恶劣的网络条件下也能保持良好的状态，并且也不会被基于TCP系统中数据包备份的缺点所影响。而且，和REMB一样，ACK也是一种通过RTCP通道发送到边缘服务器的消息类型。边缘服务器也会负责重新发送这些重要的数据包。WebRTC还支持许多其他策略来保持高视频质量并且确保视频高效传输。FEC、FIR和PLI这样的策略也正好可以通过RTCP通道工作。
WebRTC是一个复杂的规范，它拥有很多的移动部分。这也可能是为什么Wowza在他们关于ABR如何在WebRTC上工作的帖子中弄错了很多东西。具体来讲，我们参考以下内容：
另一方面，WebRTC在建设时没有考虑到质量的问题。WebRTC的首要任务一直是点对点浏览器连接的实时延迟。传统来讲，质量问题是次要的。您可能会对WebRTC支持ABR感到惊讶，但有一个警告。俗话说：“链条的强度取决于它最薄弱的一环。”而这一点对于WebRTC的质量也是一样。WebRTC内置的ABR只在订阅用户端。如果有多个订阅用户，那么就会产生问题。您可能会遇到其中一个订阅用户网络连接不良的状况。这将迫使发布者切换到较低质量的流媒体，导致每个订阅用户都只能以低质量观看。”
Wowza似乎并没有理解点对点视频会议的场景，这种情况下，拥有最低带宽的人将决定了所有用户的观看质量。当然，这种设定和可扩展的源服务器-边缘服务器集群模型有很大的不同。边缘服务器节点处理每个客户端的唯一对等连接。其实，在Wowza的SFU案例中，他们也有这类情况。从我们的阅读以及其他人的说法来看，Wowza其实根本没有针对WebRTC的ABR策略。
5 安全性
确保您的数据和流被保护也是非常重要的。防止未经授权的用户创建流并对它进行加密，使其无法被拦截，以确保敏感的信息不会被泄露。
就像之前所说，LL-HLS将被纳入HLS规范。这也意味着LL-HLS的安全功能，如DRM、令牌认证以及密钥轮换等功能都将被实现。但是，这些额外的功能只能等到供应商可以在系统中配置他们之后才能实现。等待别人为您提供安全服务可能是一个问题。
HLS有一个很突出的安全特性，那就是它可以被加密。WebRTC是默认加密的，这代表了您的流媒体不会被黑客非法访问。除此之外，用户认证、文件认真以及往返认证等功能能进一步保护流媒体的安全。
关于DRM系统，很多情况下，WebRTC提供的基本安全性足以保护您的数据。意为，内容所有者和发行商在有法律权限的条件下，都可以放心地省去签订DRM合同的成本和麻烦。
WebRTC还享有很强大的安全功能，内置的设备兼容性，以及无论网络强度如何都能保持高质量的性能。当然，必须承认的是，WebRTC是将实时延迟控制在500ms以内的唯一方式。
当问到直播视频时使用低延迟HLS还是WebRTC，WebRTC显然是赢家。
