1.7　其他直播技术

在WebRTC流行之前，低延迟的直播技术就已经普及了。这些技术一般包括用于互联网直播的RTMP协议、用于监控领域的RTSP协议，还有一些较新的协议，如SRT和QUIC。WebRTC由多个传输协议构成，实际上是一套实时通信技术的解决方案，而其他直播技术则大多以单独协议的形成存在。

1. 实时消息传输协议

实时消息传输协议（Real Time Messaging Protocol，RTMP）基于TCP，最初由Macro-media公司开发，并于2005年被Adobe收购。它包括RTMP基本协议及RTMPT、RTMPS、RTMPE等多个变种。RTMP是一种实时数据通信网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/服务器之间进行音视频和数据通信。RTMP与HTTP一样，都属于TCP/IP四层模型的应用层。

RTMP协议的应用非常广泛，至今仍是最常用的直播传输协议之一，大多数流媒体平台和软件都支持RTMP协议。

传统的RTMP延迟较高，通常延迟5～20s，经过优化，延迟可以降低到2～3s。如果想再进一步降低延迟时间，则需要改造RTMP协议，将其底层TCP协议改为UDP，如微信小程序使用了基于UDP协议的RTMP，其延迟可以降低到毫秒级。

RTMP协议的优点如下。

• 主流的CDN厂商都支持RTMP协议。
• 协议简单，在各平台均可实现。

这些优势使得基于RTMP协议的应用程序可以获得良好的基础设施支撑，而且开发及使用成本可控。

RTMP协议的缺点如下。

• 基于TCP导致传输延迟高，在弱网环境下问题尤为明显。
• 由于Flash技术即将被浏览器淘汰，主流浏览器都不支持推送RTMP协议。

2. RTSP实时流协议

实时流协议（Real Time Streaming Protocol，RTSP）是TCP/IP协议体系中的一个应用层协议。该协议定义了一对多应用程序该如何有效地通过IP网络传送多媒体数据。RTSP的协议层次位于RTP和RTCP之上，支持使用TCP或UDP传输数据。

RTSP中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种。RTSP是对称的协议，客户端和服务器都可以发送和回应请求。RTSP是一个基于文本的协议，它使用UTF -8编码（RFC2279）和ISO10646字符序列，采用RFC882定义通用消息的格式，每行语句以CRLF结束。

RTSP建立并控制一个或多个与时间同步的连续流媒体，负责定义具体的媒体控制信息、操作方法、状态码以及描述与RTP之间的交互操作，如播放、录制、暂停等。

RTSP不负责数据传输，这部分工作由RTP/RTCP协议完成。从这个层面来看，RTSP和WebRTC是类似的，都使用了RTP/RTCP协议完成媒体数据传输，但是WebRTC的功能更为丰富，技术栈也更为完善。

3. 安全可靠传输

安全可靠传输（Secure Reliable Transport，SRT）是流媒体前沿的后起之秀，支持在各种网络环境下进行低延迟、高质量的音视频传输。SRT协议可以为媒体数据提供高达256位的高级加密标准（AES）加密。

为了促进SRT技术的发展，SRT开放了源代码，开源社区成立了SRT联盟，包括众多行业领导者及开发人员。目前已经集成了SRT技术的流行软件有OBS Studio、GStreamer和VLC。

SRT被称为“卫星替代技术”，其低成本和实时通信能力为直播公司提供了一种替代卫星技术的方案。

SRT的优势如下。

• 可传输低延迟、高质量的视频和音频。
• 可在SRT源（编码器）和SRT目标（解码器）之间轻松穿越防火墙。
• 控制延迟以适应不断变化的网络状况。
• 使用多达256位AES加密的安全直播。

SRT基于UDP协议，在SRT源（编码器）和SRT目标（解码器）之间建立用于控制和恢复数据包的专用通信链路，目标可以是服务器、CDN或其他SRT设备。SRT使用自己的拥塞控制算法，该算法可以自动适应网络环境，并随着网络波动进行实时调整。

SRT和WebRTC都依赖于增强的UDP协议，能够提供实时通信的能力。但是WebRTC的优势在于它是一种基于浏览器的协议，可以在任何主流浏览器中使用，无须借助插件或硬件。

4. QUIC协议

快速UDP互联网连接（Quick UDP Internet Connection，QUIC）协议是谷歌制定的一种基于UDP的低时延互联网传输层协议。我们知道，TCP/IP协议簇是互联网的基础协议，其中传输层协议包括TCP和UDP。与TCP协议相比，UDP更为轻量，错误校验要少得多。这意味着虽然UDP的传输效率更高，但是传输可靠性不如TCP。通常游戏、流媒体等应用采用UDP，而网页、邮件、远程登录等大部分应用采用TCP。

QUIC同时具备TCP和UDP的优势，并弥补了它们的短板，很好地解决了网络连接安全性、可靠性和低延迟的问题。QUIC基于UDP传输，当客户端第一次连接服务器时，QUIC只需要1个往返时间（Round-Trip Time，RTT）的延迟就可以建立安全可靠的连接，相比于TCP+TLS建立连接需要1～3个RTT，QUIC要更加快捷。之后客户端可以在本地缓存加密的认证信息，再次与服务器建立连接时可以实现0～1个RTT的连接建立延迟。QUIC借用了HTTP/2协议的多路复用功能（Multiplexing），但由于QUIC基于UDP，所以避免了HTTP/2线头阻塞（Head-of-Line Blocking）的问题。因为QUIC运行在用户域而不是系统内核，所以QUIC协议可以快速更新和部署到生产环境中，从而解决了TCP协议部署及更新较为困难的问题。

2016年11月，国际互联网工程任务组召开了第一次QUIC工作组会议，这意味着QUIC开始了它的标准化过程，成为新一代传输层协议。

由于QUIC工作在传输层，与WebRTC没有竞争关系，所以实际上WebRTC也可以使用QUIC作为底层传输协议，在新的WebRTC规范草案中已经提供了对QUIC的支持。