淺析低延遲直播協(xié)議設(shè)計(jì)：RTP/RTCP

作者：王宇航执赡，紅點(diǎn)直播聯(lián)合創(chuàng)始人&CTO镰踏。畢業(yè)于中國科學(xué)技術(shù)大學(xué)，風(fēng)云直播創(chuàng)始團(tuán)隊(duì)成員沙合，曾參與逆向Adobe

來源：UPYUN Open Talk

聲明：本文已獲得授權(quán)奠伪。

Flash非公開加密網(wǎng)絡(luò)協(xié)議RTMFP，負(fù)責(zé)設(shè)計(jì)實(shí)現(xiàn)百萬同時(shí)在線的大規(guī)模視頻彈幕系統(tǒng)首懈。2013年聯(lián)合創(chuàng)立紅點(diǎn)直播绊率，現(xiàn)負(fù)責(zé)團(tuán)隊(duì)管理、產(chǎn)品研發(fā)及架構(gòu)設(shè)計(jì)等相關(guān)工作究履。

如今的直播市場非陈朔瘢火爆，有很多直播云服務(wù)的提供商可供產(chǎn)品選擇最仑。同時(shí)視頻直播產(chǎn)品噴涌而出藐俺，比如大家耳熟能詳?shù)挠晨痛都住Y，還有最近特別火爆的一直播欲芹。

基于TCP的協(xié)議延遲不夠低

眾所周知蜜葱，直播中通用CDN大部分提供的是RTMP的方案以及HLS的方案。HLS在手機(jī)H5里面的兼容性非常好耀石，而RTMP是Adobe的協(xié)議牵囤，它在延遲、穩(wěn)定性和分發(fā)質(zhì)量方面平衡得很不錯(cuò)滞伟。但是當(dāng)涉及會(huì)議場景時(shí)揭鳞，基于TCP的協(xié)議就不能完全滿足我們的要求了。

假設(shè)在沒有丟包的狀態(tài)下梆奈，正常設(shè)定傳輸是一個(gè)流媒體野崇，同樣數(shù)據(jù)具有時(shí)效性，從而單位時(shí)間內(nèi)產(chǎn)生的數(shù)據(jù)有一個(gè)固定的量亩钟。固定量的數(shù)據(jù)在TCP協(xié)議站上有什么問題乓梨？TCP協(xié)議設(shè)計(jì)的目標(biāo)是為了最大化帶寬的利用率。它在傳輸?shù)倪^程中會(huì)衡量信道的寬度清酥，認(rèn)為其所要達(dá)到的效果應(yīng)該是使用戶盡可能的高效使用網(wǎng)絡(luò)扶镀。丟包的狀態(tài)下，協(xié)議棧做出非常嚴(yán)厲的懲罰焰轻，降低它認(rèn)為信道的寬度臭觉，并認(rèn)為用戶已經(jīng)最大化的利用了這個(gè)網(wǎng)絡(luò)，會(huì)認(rèn)為如果有丟包是用戶發(fā)多了或者是網(wǎng)絡(luò)出現(xiàn)了擁塞辱志。通過發(fā)送數(shù)據(jù)的數(shù)量來減緩擁塞情況蝠筑，最終讓它再回歸正常水平。比如丟下一個(gè)數(shù)據(jù)揩懒，TCP做了一次懲罰什乙，使后面的數(shù)據(jù)只能向后推，這個(gè)時(shí)間就是延遲的起點(diǎn)已球。

由此可以了解對丟包的處理是網(wǎng)絡(luò)協(xié)議對延遲影響最大的一個(gè)因素臣镣。可能有的協(xié)議或者有一些網(wǎng)絡(luò)對丟包不在乎和悦，有一個(gè)包能夠到達(dá)目標(biāo)地點(diǎn)就足夠了退疫，但并不是所有的協(xié)議都能這樣。

RTP

RTP（Real-Time Protocol）協(xié)議涵蓋所有實(shí)時(shí)相關(guān)的東西鸽素。可以支持實(shí)時(shí)數(shù)據(jù)端到端傳輸亦鳞、載荷類型定義馍忽、為數(shù)據(jù)打上序號棒坏、時(shí)間校對以及分發(fā)監(jiān)控等。它不能保證及時(shí)發(fā)送以及質(zhì)量保證遭笋，比如讓協(xié)議給用戶發(fā)送一個(gè)數(shù)據(jù)坝冕，其不保證發(fā)送的時(shí)間以及數(shù)量。它也不保證送達(dá)瓦呼，也沒有時(shí)序喂窟，如發(fā)的順序是12345，收到的順序可以是54321央串。這個(gè)協(xié)議聽上去幾乎不能用磨澡，但是這樣一個(gè)沒支持太多東西的協(xié)議實(shí)際上也給我們一個(gè)空間，致使我們可以在此個(gè)基礎(chǔ)上為它增加很多策略质和，如擁塞控制算法可以增加包括對于時(shí)序的處理和對于質(zhì)量的處理稳摄。

RTP頭

RTP協(xié)議的頭，左上第一行是版本號饲宿，表示的是協(xié)議標(biāo)準(zhǔn)厦酬；第二行代表協(xié)議后面有沒有追加空白，然后X表示這個(gè)頭是不是有擴(kuò)展瘫想，CC是一個(gè)數(shù)量仗阅，M和PT其中有8個(gè)比特，表示數(shù)據(jù)類型国夜，可以自定義霹菊，其次是一個(gè)序號，一個(gè)時(shí)間戳支竹；下面的SSRC是同步源的標(biāo)識(shí)旋廷，它支持轉(zhuǎn)發(fā)和混合器的結(jié)構(gòu)，混合器結(jié)構(gòu)的功能是把參與會(huì)議的多媒體混成一路礼搁，再轉(zhuǎn)給其它的聽眾饶碘。

RTP網(wǎng)絡(luò)樣例

RTP組織網(wǎng)絡(luò)的樣例，共分為三個(gè)角色：一個(gè)是終端馒吴，可以理解為每一位參與者扎运，參與者既可以說話，也可以聽到其他與會(huì)者的內(nèi)容饮戳；第二個(gè)是混合器豪治，其最直觀的體現(xiàn)在音頻領(lǐng)域，可以將多人說的話混成一路扯罐，首先它的帶寬減少了负拟，同時(shí)時(shí)序自然對上，保持一致歹河；第三個(gè)角色是一個(gè)轉(zhuǎn)發(fā)器掩浙，即把以上流轉(zhuǎn)出去花吟。

如下圖所示，E1和E2經(jīng)過第一路混合器厨姚，轉(zhuǎn)出來即為SSRC值衅澈，它的值發(fā)生了改變。但是原來如E1：17谬墙，CSRC會(huì)體現(xiàn)在后面今布。通過這樣的網(wǎng)絡(luò)，能夠組建一個(gè)支持會(huì)議場景的內(nèi)容分發(fā)拭抬，尤其是流媒體的實(shí)時(shí)傳輸部默。

RTCP

為彌補(bǔ)RTP的不足，或者RTP沒有保證的東西玖喘，我們設(shè)置了額外的協(xié)議即RTCP甩牺。RTCP共有5個(gè)類型數(shù)據(jù)包：發(fā)送方報(bào)告、接收方報(bào)告累奈、源描述贬派、結(jié)束通知、遠(yuǎn)程調(diào)用方法澎媒。

在發(fā)送方報(bào)告中搞乏，發(fā)送者真正關(guān)心是數(shù)據(jù)發(fā)送量、丟失情況戒努、數(shù)據(jù)到達(dá)時(shí)間以及網(wǎng)絡(luò)過程中的抖動(dòng)请敦；

接收方的報(bào)告主要反應(yīng)發(fā)送方數(shù)據(jù)質(zhì)量的信息，RTP里包含序號储玫，可以體現(xiàn)多少序號斷的侍筛、未收到。其中涉及到抖動(dòng)和RTT的概念撒穷。

抖動(dòng)

抖動(dòng)指的發(fā)送方發(fā)兩個(gè)數(shù)據(jù)即A和B匣椰，第一秒發(fā)A，第二秒發(fā)B端礼。對于接收方來說禽笑，比如接收方第三秒收到A，但不一定第四秒能夠收到B蛤奥，可能第五秒才收到B佳镜。發(fā)送方隔1秒發(fā)送數(shù)據(jù)，但是接收方那邊差2秒凡桥，這2秒和1秒稱之為抖動(dòng)蟀伸。通過以上事例，可以看出時(shí)延具有不確定性⊥可以通過以下的公式對抖動(dòng)進(jìn)行平滑處理唤崭。

RRT

RRT(Round-Trip Time)描述的是一個(gè)數(shù)據(jù)包從發(fā)送方發(fā)送到接收者拷恨，接收者給出反饋脖律，反饋再回到發(fā)送方，這時(shí)發(fā)送方識(shí)別到的時(shí)間差就是往返時(shí)間腕侄。其中計(jì)算用到的量包括DLSR和LSR小泉。DLSR是距離上一個(gè)發(fā)送報(bào)告的時(shí)間。接收者可以使用DLSR冕杠，幫助發(fā)送者利用返回之后的報(bào)告算出來往返時(shí)間微姊。RTT更像工程師日常使用網(wǎng)絡(luò)中的ping。

流媒體丟包處理方案

流媒體丟包一般有3種處理方案：重傳分预、前向糾錯(cuò)兢交、交叉?zhèn)鬏敗?/p>

重傳

第一個(gè)策略是重傳，很明確地丟什么數(shù)據(jù)重新傳什么數(shù)據(jù)笼痹，不會(huì)浪費(fèi)資源配喳。

前向糾錯(cuò)（FEC，F(xiàn)orward Error Correction）

所謂前向糾錯(cuò)凳干，其實(shí)是數(shù)據(jù)冗余晴裹，是解決丟包問題的主要方案之一【却停可以分成兩種類型：多媒體無關(guān)的前向糾錯(cuò)和多媒體相關(guān)的涧团。本文將主要介紹多媒體無關(guān)的前向糾錯(cuò)，它更多會(huì)用在網(wǎng)絡(luò)上经磅，同時(shí)該技術(shù)在存儲(chǔ)領(lǐng)域也有應(yīng)用泌绣。

在觀看實(shí)時(shí)場景時(shí)，正常情況下若出現(xiàn)丟包预厌，比如上述的重傳阿迈，如果發(fā)送方想知道這個(gè)東西是否需要重傳，需要依賴往返時(shí)間配乓。重傳非常依賴RTT值仿滔，RTT比較大，重傳策略很難設(shè)計(jì)崎页，因?yàn)椴恢浪莵G了，還是收到了但沒有來得及反饋腰埂。同樣的情況可以利用前向糾錯(cuò)的技術(shù)飒焦，很大程度上不依賴重傳，尤其是在會(huì)議的狀態(tài)下。因?yàn)樗难舆t一般是在250毫秒的量級牺荠，該量級下翁巍，重傳的效果并不會(huì)很理想。

分層數(shù)據(jù)保護(hù)

分層數(shù)據(jù)保護(hù)是前向糾錯(cuò)對于分層的方案休雌。分層指的是數(shù)據(jù)包里面有不同重要程度的數(shù)據(jù)灶壶，對于不同程度的數(shù)據(jù)分段對它進(jìn)行保護(hù)。

FEC數(shù)據(jù)包

前向糾錯(cuò)的數(shù)據(jù)包是基于RTP標(biāo)準(zhǔn)上設(shè)計(jì)的杈曲。前面是RTP包頭驰凛，后面是前向糾錯(cuò)的數(shù)據(jù)包的格式。

FEC算法

FEC算法其中一個(gè)稱之為異或担扑。假如有4個(gè)數(shù)據(jù)恰响，那么它們可以取4個(gè)異或值，其中每一個(gè)數(shù)據(jù)都可以由另外4個(gè)異或計(jì)算出來涌献。還可以把ABCD和E想象成一個(gè)數(shù)據(jù)包胚宦，如果我們傳輸ABCD這四個(gè)數(shù)據(jù)包，第五個(gè)數(shù)據(jù)包傳輸?shù)氖荅燕垃，這五個(gè)數(shù)據(jù)包可以丟失任何1個(gè)數(shù)據(jù)包枢劝。接收方收到數(shù)據(jù)之后，能夠把它丟的數(shù)據(jù)恢復(fù)出來利术。前向糾錯(cuò)算法能處理的是連續(xù)數(shù)據(jù)里只丟1個(gè)包呈野。同時(shí)丟失A和B，這個(gè)算法不能解決印叁。

因此這給予我們更多的操作空間被冒。我們把將參數(shù)想成數(shù)據(jù)包，里面包含5個(gè)參數(shù)即5個(gè)數(shù)據(jù)包轮蜕。左邊設(shè)8個(gè)方程昨悼，8個(gè)方程可以解出來該5個(gè)數(shù)據(jù)包的值，通過8個(gè)方程可以解出右邊的一個(gè)結(jié)果跃洛。在傳輸數(shù)據(jù)的時(shí)候率触，額外的幾個(gè)方程組，即冗余的數(shù)據(jù)汇竭。也就是說原來的數(shù)據(jù)傳的是12345這5個(gè)數(shù)據(jù)葱蝗。然后又額外傳了C，假如這8個(gè)數(shù)據(jù)里面任意丟了三個(gè)數(shù)據(jù)C1细燎、C2和C3两曼，程序可以利用其他內(nèi)容額外把它們恢復(fù)出來，這個(gè)邏輯就是糾錯(cuò)過程冗余玻驻，以及冗余可以在任意位置恢復(fù)出來的原因悼凑。該算法的好處是可以連續(xù)的丟數(shù)據(jù)，比如網(wǎng)絡(luò)傳輸?shù)臅r(shí)候，傳1到10這樣數(shù)據(jù)户辫，這個(gè)時(shí)候我們使用冗余度是5渐夸，10個(gè)數(shù)據(jù)有5個(gè)是冗余的，既50%的冗余度渔欢。這5個(gè)數(shù)據(jù)當(dāng)中我們?nèi)我鈦G失5個(gè)數(shù)據(jù)墓塌，接收方認(rèn)為這個(gè)數(shù)據(jù)包是完成的，沒有丟任何數(shù)據(jù)膘茎，不需要重傳桃纯，也不需要多媒體相關(guān)的糾錯(cuò)法酷誓。網(wǎng)絡(luò)傳輸過程當(dāng)中披坏，每次發(fā)出去的數(shù)據(jù)不需要等待重傳的延遲，可以把冗余數(shù)據(jù)發(fā)送出去盐数。對于接方來講棒拂，在帶寬可以接受的情況下，延遲仍然是最低的玫氢。

交叉?zhèn)鬏?/b>

最后一個(gè)策略是交叉?zhèn)鬏斨闾耄覀內(nèi)粘？吹蕉嗝襟w可能是按照時(shí)序的漾峡，一個(gè)多媒體片斷是由1到10組成攻旦。如果此過程當(dāng)中有丟包，比如3456連續(xù)丟失生逸，那么此次丟包的影響可能表現(xiàn)在視頻播放出現(xiàn)停頓牢屋。若丟的是關(guān)鍵幀那么影響非常大，會(huì)導(dǎo)致后面一大片的花屏槽袄。因此當(dāng)連續(xù)丟包對流媒體傷害特別大的情況下烙无，可以采用交叉?zhèn)鬏敳呗浴?到10，原來是3個(gè)3個(gè)傳遍尺，如123截酷、456、789各傳一次乾戏，那么現(xiàn)在可以改變傳輸策略迂苛，采用147、 280和369的傳輸策略鼓择，這樣一組數(shù)據(jù)丟掉三幻，實(shí)際丟失在流媒體中間穿插的數(shù)據(jù)，播放程序可以在幾乎不失真的狀態(tài)下把視頻恢復(fù)出來惯退。

數(shù)據(jù)包擁塞控制協(xié)議(DCCP)

上述提到的RTP協(xié)議不僅可以基于UDP協(xié)議赌髓，也可以基于TCP協(xié)議。只是大部分利用RTP協(xié)議的場景實(shí)際上是基于UDP協(xié)議的。DCCP是一個(gè)擁塞控制的策略锁蠕，里面包含4項(xiàng)內(nèi)容：首先是建立會(huì)話夷野，像TCP的握手；第二是數(shù)據(jù)窗口荣倾，可能很多時(shí)候要處理一個(gè)數(shù)據(jù)序號的順序和整合一些數(shù)據(jù)碎片悯搔；第三是反饋，ACK就是關(guān)于數(shù)據(jù)到達(dá)反饋舌仍；最后是擁塞控制妒貌。其中數(shù)據(jù)窗口、反饋還有擁塞控制是影響傳輸質(zhì)量的關(guān)鍵铸豁。

數(shù)據(jù)窗口跟數(shù)據(jù)的時(shí)效性關(guān)系很大灌曙，使用TCP協(xié)議時(shí)大部分?jǐn)?shù)據(jù)長度跟時(shí)間關(guān)系不是那么強(qiáng)。但是會(huì)議場景對時(shí)效性要求較高节芥。數(shù)據(jù)窗口里面時(shí)間很難超過1秒在刺，1秒以后的數(shù)據(jù)其實(shí)就已經(jīng)不再有任何用處了。

在Ack里面头镊，一般會(huì)有兩個(gè)策略：一種是直接告訴發(fā)送方未收到的數(shù)據(jù)蚣驼；另一種是有選擇性的直接告知發(fā)送方收到的數(shù)據(jù)片斷所處的碎片狀態(tài)，讓發(fā)送方根據(jù)自己的情況相艇，有選擇地重發(fā)一些數(shù)據(jù)颖杏，避免一些不必要的負(fù)擔(dān)。

眾所周知坛芽，關(guān)于TCP協(xié)議相關(guān)內(nèi)容有很嚴(yán)格的擁塞控制措施留储，使用最大的帶寬下TCP傳輸超延遲內(nèi)容不是很友好。DCCP則為我們提供一個(gè)方案靡馁，讓我們自己控制擁塞控制欲鹏，傳輸延遲和數(shù)據(jù)質(zhì)量，對此我們可以有一個(gè)很強(qiáng)的掌控力臭墨。

版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)赔嚎，版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn)胧弛，我們都會(huì)標(biāo)明作者及出處尤误，如有侵權(quán)煩請告知，我們會(huì)立即刪除并表示歉意结缚。謝謝损晤。