RTMP協議存在累計延遲與加密方面的問題，為適應互聯網視頻低延時，高質量的要求，以UDP為核心，具有創造性的SRT，QUIC等流媒體視頻方式將成為新的選擇。本文來自NGCodec官方博客，由LiveVideoStack進行摘譯。

原文?

https://ngcodec.com/news/2018/11/5/is-the-death-of-rtmp-imminent-the-advance-of-srt

RTMP協議(實時消息傳輸協議)最初是由Macromedia為通過互聯網在Flash播放器與一個服務器之間傳輸流媒體音頻、視頻和數據而開發的協議。隨著視頻直播領域的興起，也成為業內廣泛使用的協議。

RTMP是基于TCP的協議，存在著累積延遲和加密方面的問題。而伴隨著互聯網視頻低延時，高質量的要求逐漸提升，相對而言，以UDP為核心的流媒體視頻方式成為新的選擇，包括SRT，QUIC等。

TCP和UDP是用于通過Internet發送數據位（稱為數據包）的協議，但它們以不同的方式工作。?

TCP（傳輸控制協議）常用于日常互聯網應用，以保證通過發送方和接收方之間的握手機制來傳送分組。如果未收到數據包，則重新發送它們。雖然保證了數據包的真實傳輸，但速度非常慢，并且不會在波動的網絡上進行優化。RTMP和其他基于HTTP流的協議（包括MPEG-DASH和HLS）依靠TCP / IP進行握手并替換傳輸中丟失的數據包。這意味著潛在的延遲問題對高性能視頻流無效。

另一方面，UDP沒有握手機制。它基本上發送數據包并希望最好。但就延遲而言，大大減少，實際上成為視頻流的理想解決方案。

SRT最初由Haivision和Wowza開發，目前聯盟由150多家公司組成，包括Bitmovin，Brightcove，Canal Cable，Comcast Technology Services，Cinergy，Deluxe，Ericsson，Harmonic和NGCodec等少數知名公司以及數十家小型供應商。

SRT使用UDP協議，旨在利用有損網絡來確保可靠性。它通過使用“高性能”發送器和接收器模塊來實現這一點 - 該模塊不會通過握手確認來阻塞網絡。這允許它擴展并最大化可用帶寬。SRT保證發送的分組節奏（壓縮視頻信號）與解碼器接收的分組節奏相同。

SRT增加了專為高效安全的視頻流而設計的其他功能：

• 128/256 AES加密，通過公共網絡在鏈路級提供安全性

• 內容不可知，并在單個SRT流中匯集多個視頻，音頻和數據（元數據）流，使其能夠輕松支持高度復雜的工作流程?

• 支持發送和接收模式（與僅支持單一模式的RTMP和HTTP相反），對于傳遞防火墻非常有用

• 在發送器/接收器模塊內，可以檢測網絡性能，并使用一種自適應比特率和糾正延遲，丟包和抖動

• 可支持當前和下一代壓縮技術，即H264（AVC），H265（HEVC），AV1，VP9

• SRT是開源的，免版稅的，可在Github平臺上使用

QUIC（Quick UDP Internet Connection）是谷歌制定的一種基于UDP的低時延的互聯網傳輸層協議。QUIC很好地解決了當今傳輸層和應用層面臨的各種需求，包括處理更多的連接，安全性，和低延遲。QUIC融合了包括TCP，TLS，HTTP/2等協議的特性，但基于UDP傳輸。

QUIC的一個主要目標就是減少連接延遲，當客戶端第一次連接服務器時，QUIC只需要1RTT（Round-Trip Time）的延遲就可以建立可靠安全的連接,相對于TCP+TLS的1-3次RTT要更加快捷。之后客戶端可以在本地緩存加密的認證信息，在再次與服務器建立連接時可以實現0-RTT的連接建立延遲。

因為QUIC基于UDP，運行在用戶域而不是系統內核，使得QUIC協議可以快速的更新和部署，從而很好地解決了TCP協議部署及更新的困難。

精品文章推薦

技術干貨：

• 誰是最好的WebRTC SFU？

• 基于HLS格式的低延時互動直播技術

• FFmpeg在Intel GPU上的硬件加速與優化

• UDP成為低延時流媒體關鍵 選SRT還是QUIC？

• 下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC

人物專訪：

• Akamai首席架構師Will：WebRTC、QUIC、DASH、AV1都前景可觀

• 馬思偉：視頻領域是個海洋，可以游泳、沖浪、潛水和遠航

• 吳濤 ：低延遲傳輸協議和新Codec將成為熱點

• 雷輝：讓視頻會議conferencing like TV

總結

以上是生活随笔為你收集整理的RTMP之后，SRT与QUIC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。