作者：王宇航，紅點直播聯合創始人&CTO。畢業于中國科學技術大學，風云直播創始團隊成員，曾參與逆向Adobe

來源：UPYUN Open Talk

聲明：本文已獲得授權。

?

Flash非公開加密網絡協議RTMFP，負責設計實現百萬同時在線的大規模視頻彈幕系統。2013年聯合創立紅點直播，現負責團隊管理、產品研發及架構設計等相關工作。?

?

如今的直播市場非?；鸨?#xff0c;有很多直播云服務的提供商可供產品選擇。同時視頻直播產品噴涌而出，比如大家耳熟能詳的映客、YY，還有最近特別火爆的一直播。

?

基于TCP的協議延遲不夠低

?

眾所周知，直播中通用CDN大部分提供的是RTMP的方案以及HLS的方案。HLS在手機H5里面的兼容性非常好，而RTMP是Adobe的協議，它在延遲、穩定性和分發質量方面平衡得很不錯。但是當涉及會議場景時，基于TCP的協議就不能完全滿足我們的要求了。

?

假設在沒有丟包的狀態下，正常設定傳輸是一個流媒體，同樣數據具有時效性，從而單位時間內產生的數據有一個固定的量。固定量的數據在TCP協議站上有什么問題？TCP協議設計的目標是為了最大化帶寬的利用率。它在傳輸的過程中會衡量信道的寬度，認為其所要達到的效果應該是使用戶盡可能的高效使用網絡。丟包的狀態下，協議棧做出非常嚴厲的懲罰，降低它認為信道的寬度，并認為用戶已經最大化的利用了這個網絡，會認為如果有丟包是用戶發多了或者是網絡出現了擁塞。通過發送數據的數量來減緩擁塞情況，最終讓它再回歸正常水平。比如丟下一個數據，TCP做了一次懲罰，使后面的數據只能向后推，這個時間就是延遲的起點。

?

由此可以了解對丟包的處理是網絡協議對延遲影響最大的一個因素?？赡苡械膮f議或者有一些網絡對丟包不在乎，有一個包能夠到達目標地點就足夠了，但并不是所有的協議都能這樣。

?

RTP

?

RTP（Real-Time Protocol）協議涵蓋所有實時相關的東西。可以支持實時數據端到端傳輸、載荷類型定義、為數據打上序號、時間校對以及分發監控等。它不能保證及時發送以及質量保證，比如讓協議給用戶發送一個數據，其不保證發送的時間以及數量。它也不保證送達，也沒有時序，如發的順序是12345，收到的順序可以是54321。這個協議聽上去幾乎不能用，但是這樣一個沒支持太多東西的協議實際上也給我們一個空間，致使我們可以在此個基礎上為它增加很多策略，如擁塞控制算法可以增加包括對于時序的處理和對于質量的處理。

?

RTP頭

?

RTP協議的頭，左上第一行是版本號，表示的是協議標準；第二行代表協議后面有沒有追加空白，然后X表示這個頭是不是有擴展，CC是一個數量，M和PT其中有8個比特，表示數據類型，可以自定義，其次是一個序號，一個時間戳；下面的SSRC是同步源的標識，它支持轉發和混合器的結構，混合器結構的功能是把參與會議的多媒體混成一路，再轉給其它的聽眾。

?

?

RTP網絡樣例

?

RTP組織網絡的樣例，共分為三個角色：一個是終端，可以理解為每一位參與者，參與者既可以說話，也可以聽到其他與會者的內容；第二個是混合器，其最直觀的體現在音頻領域，可以將多人說的話混成一路，首先它的帶寬減少了，同時時序自然對上，保持一致；第三個角色是一個轉發器，即把以上流轉出去。

?

如下圖所示，E1和E2經過第一路混合器，轉出來即為SSRC值，它的值發生了改變。但是原來如E1：17，CSRC會體現在后面。通過這樣的網絡，能夠組建一個支持會議場景的內容分發，尤其是流媒體的實時傳輸。

?

?

RTCP

?

為彌補RTP的不足，或者RTP沒有保證的東西，我們設置了額外的協議即RTCP。RTCP共有5個類型數據包：發送方報告、接收方報告、源描述、結束通知、遠程調用方法。

?

在發送方報告中，發送者真正關心是數據發送量、丟失情況、數據到達時間以及網絡過程中的抖動；

?

?

接收方的報告主要反應發送方數據質量的信息，RTP里包含序號，可以體現多少序號斷的、未收到。其中涉及到抖動和RTT的概念。

?

?

抖動

?

抖動指的發送方發兩個數據即A和B，第一秒發A，第二秒發B。對于接收方來說，比如接收方第三秒收到A，但不一定第四秒能夠收到B，可能第五秒才收到B。發送方隔1秒發送數據，但是接收方那邊差2秒，這2秒和1秒稱之為抖動。通過以上事例，可以看出時延具有不確定性?？梢酝ㄟ^以下的公式對抖動進行平滑處理。

?

?

RRT

?

RRT(Round-Trip Time)描述的是一個數據包從發送方發送到接收者，接收者給出反饋，反饋再回到發送方，這時發送方識別到的時間差就是往返時間。其中計算用到的量包括DLSR和LSR。DLSR是距離上一個發送報告的時間。接收者可以使用DLSR，幫助發送者利用返回之后的報告算出來往返時間。RTT更像工程師日常使用網絡中的ping。

?

?

流媒體丟包處理方案

?

流媒體丟包一般有3種處理方案：重傳、前向糾錯、交叉傳輸。

?

重傳

?

第一個策略是重傳，很明確地丟什么數據重新傳什么數據，不會浪費資源。

?

前向糾錯（FEC，Forward Error Correction）

?

所謂前向糾錯，其實是數據冗余，是解決丟包問題的主要方案之一?？梢苑殖蓛煞N類型：多媒體無關的前向糾錯和多媒體相關的。本文將主要介紹多媒體無關的前向糾錯，它更多會用在網絡上，同時該技術在存儲領域也有應用。

?

在觀看實時場景時，正常情況下若出現丟包，比如上述的重傳，如果發送方想知道這個東西是否需要重傳，需要依賴往返時間。重傳非常依賴RTT值，RTT比較大，重傳策略很難設計，因為不知道它是丟了，還是收到了但沒有來得及反饋。同樣的情況可以利用前向糾錯的技術，很大程度上不依賴重傳，尤其是在會議的狀態下。因為它的延遲一般是在250毫秒的量級，該量級下，重傳的效果并不會很理想。

?

• 分層數據保護

?

分層數據保護是前向糾錯對于分層的方案。分層指的是數據包里面有不同重要程度的數據，對于不同程度的數據分段對它進行保護。

?

?

• FEC數據包

?

前向糾錯的數據包是基于RTP標準上設計的。前面是RTP包頭，后面是前向糾錯的數據包的格式。

?

?

• FEC算法

?

FEC算法其中一個稱之為異或。假如有4個數據，那么它們可以取4個異或值，其中每一個數據都可以由另外4個異或計算出來。還可以把ABCD和E想象成一個數據包，如果我們傳輸ABCD這四個數據包，第五個數據包傳輸的是E，這五個數據包可以丟失任何1個數據包。接收方收到數據之后，能夠把它丟的數據恢復出來。前向糾錯算法能處理的是連續數據里只丟1個包。同時丟失A和B，這個算法不能解決。

?

?

因此這給予我們更多的操作空間。我們把將參數想成數據包，里面包含5個參數即5個數據包。左邊設8個方程，8個方程可以解出來該5個數據包的值，通過8個方程可以解出右邊的一個結果。在傳輸數據的時候，額外的幾個方程組，即冗余的數據。也就是說原來的數據傳的是12345這5個數據。然后又額外傳了C，假如這8個數據里面任意丟了三個數據C1、C2和C3，程序可以利用其他內容額外把它們恢復出來，這個邏輯就是糾錯過程冗余，以及冗余可以在任意位置恢復出來的原因。該算法的好處是可以連續的丟數據，比如網絡傳輸的時候，傳1到10這樣數據，這個時候我們使用冗余度是5，10個數據有5個是冗余的，既50%的冗余度。這5個數據當中我們任意丟失5個數據，接收方認為這個數據包是完成的，沒有丟任何數據，不需要重傳，也不需要多媒體相關的糾錯法。網絡傳輸過程當中，每次發出去的數據不需要等待重傳的延遲，可以把冗余數據發送出去。對于接方來講，在帶寬可以接受的情況下，延遲仍然是最低的。

?

?

交叉傳輸

?

最后一個策略是交叉傳輸，我們日?？吹蕉嗝襟w可能是按照時序的，一個多媒體片斷是由1到10組成。如果此過程當中有丟包，比如3456連續丟失，那么此次丟包的影響可能表現在視頻播放出現停頓。若丟的是關鍵幀那么影響非常大，會導致后面一大片的花屏。因此當連續丟包對流媒體傷害特別大的情況下，可以采用交叉傳輸策略。1到10，原來是3個3個傳，如123、456、789各傳一次，那么現在可以改變傳輸策略，采用147、 280和369的傳輸策略，這樣一組數據丟掉，實際丟失在流媒體中間穿插的數據，播放程序可以在幾乎不失真的狀態下把視頻恢復出來。

?

數據包擁塞控制協議(DCCP)

?

上述提到的RTP協議不僅可以基于UDP協議，也可以基于TCP協議。只是大部分利用RTP協議的場景實際上是基于UDP協議的。DCCP是一個擁塞控制的策略，里面包含4項內容：首先是建立會話，像TCP的握手；第二是數據窗口，可能很多時候要處理一個數據序號的順序和整合一些數據碎片；第三是反饋，ACK就是關于數據到達反饋；最后是擁塞控制。其中數據窗口、反饋還有擁塞控制是影響傳輸質量的關鍵。

?

數據窗口跟數據的時效性關系很大，使用TCP協議時大部分數據長度跟時間關系不是那么強。但是會議場景對時效性要求較高。數據窗口里面時間很難超過1秒，1秒以后的數據其實就已經不再有任何用處了。

?

在Ack里面，一般會有兩個策略：一種是直接告訴發送方未收到的數據；另一種是有選擇性的直接告知發送方收到的數據片斷所處的碎片狀態，讓發送方根據自己的情況，有選擇地重發一些數據，避免一些不必要的負擔。

?

眾所周知，關于TCP協議相關內容有很嚴格的擁塞控制措施，使用最大的帶寬下TCP傳輸超延遲內容不是很友好。DCCP則為我們提供一個方案，讓我們自己控制擁塞控制，傳輸延遲和數據質量，對此我們可以有一個很強的掌控力。

總結

以上是生活随笔為你收集整理的浅析低延迟直播协议设计：RTP/RTCP的全部內容，希望文章能夠幫你解決所遇到的問題。

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