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的支持。