图4. LL HLS的运行原理

在CDN和播放器完全支持该规范的情况下，预计延迟时间小于3秒。HLS由于其出色的可扩展性、加密和自适应比特率支持跨平台功能以及向后兼容，非常广泛地用于开放网络的广播，如果播放器不支持LL HLS，这一点很有用。

WebRTC

WebRTC（网络实时通信）是由谷歌在2011年开发的一个开源协议。它被用于Google Hangout、Slack、BigClueButton和YouTube Live。WebRTC是一套标准、协议和JavaScript编程接口，并且使用DTLS-SRTP在点对点连接中实现了端到端的加密。此外，该技术不使用第三方插件或软件，可以在不损失质量和延迟的情况下通过防火墙（例如，在浏览器的视频会议期间）。在播放视频时，通常使用基于UDP的WebRTC实现。

该协议的工作原理如下：一台主机向要连接的对等客户发送一个连接请求。在对等客户之间的连接建立之前，它们通过第三方信号服务器相互通信。然后，每个对等客户都向STUN服务器询问 "我是谁？" (如何从外面找到我？)。

同时，有公共的谷歌STUN服务器（例如stun.l.google.com:19302）。STUN服务器提供一个IP和端口的列表，通过这个列表可以到达当前的主机。ICE候选者是由这个列表形成的。第二个客户也进行相同的操作。ICE候选者通过信号服务器进行交换，正是在这个阶段建立了点对点的连接，即形成了一个点对点的网络。

如果不能建立直接连接，那么一个所谓的TURN服务器就充当中继/代理服务器，它也被列入ICE候选名单。

SCTP（应用数据）和SRTP（音频和视频数据）协议负责多路复用、发送、拥塞控制和可靠交付。对于“握手”交换和进一步的流量加密，使用了DTLS。

图5. WebRTC协议栈

使用Opus和VP8作为编解码器。最大支持的分辨率为720p，30fps，比特率最高到2Mbps。

WebRTC技术在安全方面的一个缺点是，即使在NAT后面和使用Tor网络或代理服务器时，也要定义一个真实的IP。由于连接结构的原因，WebRTC不适合大量同时观看的对等客户（难以扩展），而且目前CDN也很少支持它。最后，WebRTC在编码质量和最大传输数据量方面不如其他协议。

WebRTC在Safari中不可用，在Bowser和Edge中部分不可用。谷歌声称其延迟不到一秒。同时，该协议不仅可用于视频会议，也可用于文件传输等应用。

SRT

SRT（Secure Reliable Transport，安全可靠传输）是由Haivision在2012年开发的一个协议。该协议在UDT（基于UDP的数据传输协议）和ARQ数据包恢复技术的基础上运行。它支持AES-128和AES-256加密。除了监听（服务器）模式，它还支持呼叫（客户端）和会合（当双方启动连接时）模式，这使得连接可以通过防火墙和NAT建立。SRT的“握手”过程是在现有的安全策略中进行的，因此允许外部连接，而不需要在防火墙中打开永久的外部端口。

SRT在每个数据包内都包含时间戳，这就允许以与流编码速率相等的速度播放，而不需要大量的缓冲，同时使抖动（不断变化的数据包到达率）和传入的比特率保持一致。与TCP中一个数据包的丢失可能会导致重新发送整个数据包链不同，从丢失的数据包开始，SRT通过其编号识别一个特定的数据包，并只重新发送这个数据包。这对延迟和冗余有积极作用。

重发的数据包比标准广播的优先级更高。与标准的UDT不同，SRT完全重新设计了重发数据包的架构，一旦数据包丢失，就立即做出反应。这项技术是选择性重复/拒绝ARQ的一个变种。值得注意的是，一个特定的丢失的数据包可能只被重新发送固定的次数。当数据包上的时间超过总时延的125%时，发送方会跳过该数据包。SRT支持FEC，用户自己决定使用这两种技术中的哪一种（或同时使用两种），以平衡最低延迟和最高传输可靠性。

图6. SRT在开放网络上的运行原理

SRT中的数据传输可以是双向的：两点都可以同时发送数据，也可以同时作为监听和发起连接的一方。当双方都需要建立连接时，可以使用会合模式。该协议有一个内部复用机制，允许将一个会话的几个流复用到使用一个UDP端口的一个连接中。SRT也适用于快速文件传输，这个应用在UDT中首次引入。

SRT有一个网络拥堵控制机制。每隔10毫秒，发送方就会收到关于RTT及其变化的最新数据、可用的缓冲区大小、数据包接收率和当前链接的大致大小。SRT对连续发送的两个数据包之间的最小延时有限制。如果它们不能及时送达，就会从队列中删除。

开发者声称，在封闭网络中短距离传输中设置缓冲区为最小，使用SRT可能实现的最小延迟是120毫秒。建议稳定广播的总延迟是3-4个RTT。此外，SRT在长距离（几千公里）和高比特率（10Mbps及以上）的传输方面比其竞争对手RTMP处理得更好。

图7. SRT广播延迟测试

在上面的例子中，实验室测量的SRT广播的延迟在25fps的条件下是3帧。也就是40ms*3=120ms。由此我们可以得出结论，在UDP广播中可以达到的0.1秒的超低延迟，在SRT广播中也是可以实现的。SRT的可扩展性与HLS或DASH/CMAF不在同一水平上，但SRT得到CDN和转发者(restreamer)的大力支持，也支持通过媒体服务器以监听模式直接广播给终端客户。

2017年，Haivision披露了SRT库的源代码，并创建了SRT联盟，该联盟包括350多个成员。

总结

作为总结，下表展示了各个协议的对比：