如今的直播市場非?;鸨泻芏嘀辈ピ品?wù)的提供商可供產(chǎn)品選擇。同時視頻直播產(chǎn)品噴涌而出,比如大家耳熟能詳?shù)挠晨?、YY,還有最近特別火爆的一直播。
眾所周知,直播中通用CDN大部分提供的是RTMP的方案以及HLS的方案。HLS在手機(jī)H5里面的兼容性非常好,而RTMP是Adobe的協(xié)議,它在延遲、穩(wěn)定性和分發(fā)質(zhì)量方面平衡得很不錯。但是當(dāng)涉及會議場景時,基于TCP的協(xié)議就不能完全滿足我們的要求了。
假設(shè)在沒有丟包的狀態(tài)下,正常設(shè)定傳輸是一個流媒體,同樣數(shù)據(jù)具有時效性,從而單位時間內(nèi)產(chǎn)生的數(shù)據(jù)有一個固定的量。固定量的數(shù)據(jù)在TCP協(xié)議站上有什么問題?TCP協(xié)議設(shè)計(jì)的目標(biāo)是為了最大化帶寬的利用率。它在傳輸?shù)倪^程中會衡量信道的寬度,認(rèn)為其所要達(dá)到的效果應(yīng)該是使用戶盡可能的高效使用網(wǎng)絡(luò)。丟包的狀態(tài)下,協(xié)議棧做出非常嚴(yán)厲的懲罰,降低它認(rèn)為信道的寬度,并認(rèn)為用戶已經(jīng)最大化的利用了這個網(wǎng)絡(luò),會認(rèn)為如果有丟包是用戶發(fā)多了或者是網(wǎng)絡(luò)出現(xiàn)了擁塞。通過發(fā)送數(shù)據(jù)的數(shù)量來減緩擁塞情況,最終讓它再回歸正常水平。比如丟下一個數(shù)據(jù),TCP做了一次懲罰,使后面的數(shù)據(jù)只能向后推,這個時間就是延遲的起點(diǎn)。
由此可以了解對丟包的處理是網(wǎng)絡(luò)協(xié)議對延遲影響最大的一個因素。可能有的協(xié)議或者有一些網(wǎng)絡(luò)對丟包不在乎,有一個包能夠到達(dá)目標(biāo)地點(diǎn)就足夠了,但并不是所有的協(xié)議都能這樣。
RTP(Real-Time Protocol)協(xié)議涵蓋所有實(shí)時相關(guān)的東西。可以支持實(shí)時數(shù)據(jù)端到端傳輸、載荷類型定義、為數(shù)據(jù)打上序號、時間校對以及分發(fā)監(jiān)控等。它不能保證及時發(fā)送以及質(zhì)量保證,比如讓協(xié)議給用戶發(fā)送一個數(shù)據(jù),其不保證發(fā)送的時間以及數(shù)量。它也不保證送達(dá),也沒有時序,如發(fā)的順序是12345,收到的順序可以是54321。這個協(xié)議聽上去幾乎不能用,但是這樣一個沒支持太多東西的協(xié)議實(shí)際上也給我們一個空間,致使我們可以在此個基礎(chǔ)上為它增加很多策略,如擁塞控制算法可以增加包括對于時序的處理和對于質(zhì)量的處理。
RTP頭
RTP協(xié)議的頭,左上第一行是版本號,表示的是協(xié)議標(biāo)準(zhǔn);第二行代表協(xié)議后面有沒有追加空白,然后X表示這個頭是不是有擴(kuò)展,CC是一個數(shù)量,M和PT其中有8個比特,表示數(shù)據(jù)類型,可以自定義,其次是一個序號,一個時間戳;下面的SSRC是同步源的標(biāo)識,它支持轉(zhuǎn)發(fā)和混合器的結(jié)構(gòu),混合器結(jié)構(gòu)的功能是把參與會議的多媒體混成一路,再轉(zhuǎn)給其它的聽眾。
RTP網(wǎng)絡(luò)樣例
RTP組織網(wǎng)絡(luò)的樣例,共分為三個角色:一個是終端,可以理解為每一位參與者,參與者既可以說話,也可以聽到其他與會者的內(nèi)容;第二個是混合器,其最直觀的體現(xiàn)在音頻領(lǐng)域,可以將多人說的話混成一路,首先它的帶寬減少了,同時時序自然對上,保持一致;第三個角色是一個轉(zhuǎn)發(fā)器,即把以上流轉(zhuǎn)出去。
如下圖所示,E1和E2經(jīng)過第一路混合器,轉(zhuǎn)出來即為SSRC值,它的值發(fā)生了改變。但是原來如E1:17,CSRC會體現(xiàn)在后面。通過這樣的網(wǎng)絡(luò),能夠組建一個支持會議場景的內(nèi)容分發(fā),尤其是流媒體的實(shí)時傳輸。
為彌補(bǔ)RTP的不足,或者RTP沒有保證的東西,我們設(shè)置了額外的協(xié)議即RTCP。RTCP共有5個類型數(shù)據(jù)包:發(fā)送方報告、接收方報告、源描述、結(jié)束通知、遠(yuǎn)程調(diào)用方法。
在發(fā)送方報告中,發(fā)送者真正關(guān)心是數(shù)據(jù)發(fā)送量、丟失情況、數(shù)據(jù)到達(dá)時間以及網(wǎng)絡(luò)過程中的抖動;
接收方的報告主要反應(yīng)發(fā)送方數(shù)據(jù)質(zhì)量的信息,RTP里包含序號,可以體現(xiàn)多少序號斷的、未收到。其中涉及到抖動和RTT的概念。
抖動
抖動指的發(fā)送方發(fā)兩個數(shù)據(jù)即A和B,第一秒發(fā)A,第二秒發(fā)B。對于接收方來說,比如接收方第三秒收到A,但不一定第四秒能夠收到B,可能第五秒才收到B。發(fā)送方隔1秒發(fā)送數(shù)據(jù),但是接收方那邊差2秒,這2秒和1秒稱之為抖動。通過以上事例,可以看出時延具有不確定性??梢酝ㄟ^以下的公式對抖動進(jìn)行平滑處理。
RRT
RRT(Round-Trip Time)描述的是一個數(shù)據(jù)包從發(fā)送方發(fā)送到接收者,接收者給出反饋,反饋再回到發(fā)送方,這時發(fā)送方識別到的時間差就是往返時間。其中計(jì)算用到的量包括DLSR和LSR。DLSR是距離上一個發(fā)送報告的時間。接收者可以使用DLSR,幫助發(fā)送者利用返回之后的報告算出來往返時間。RTT更像工程師日常使用網(wǎng)絡(luò)中的ping。
流媒體丟包一般有3種處理方案:重傳、前向糾錯、交叉?zhèn)鬏敗?/p>
重傳
第一個策略是重傳,很明確地丟什么數(shù)據(jù)重新傳什么數(shù)據(jù),不會浪費(fèi)資源。
前向糾錯(FEC,F(xiàn)orward Error Correction)
所謂前向糾錯,其實(shí)是數(shù)據(jù)冗余,是解決丟包問題的主要方案之一??梢苑殖蓛煞N類型:多媒體無關(guān)的前向糾錯和多媒體相關(guān)的。本文將主要介紹多媒體無關(guān)的前向糾錯,它更多會用在網(wǎng)絡(luò)上,同時該技術(shù)在存儲領(lǐng)域也有應(yīng)用。
在觀看實(shí)時場景時,正常情況下若出現(xiàn)丟包,比如上述的重傳,如果發(fā)送方想知道這個東西是否需要重傳,需要依賴往返時間。重傳非常依賴RTT值,RTT比較大,重傳策略很難設(shè)計(jì),因?yàn)椴恢浪莵G了,還是收到了但沒有來得及反饋。同樣的情況可以利用前向糾錯的技術(shù),很大程度上不依賴重傳,尤其是在會議的狀態(tài)下。因?yàn)樗难舆t一般是在250毫秒的量級,該量級下,重傳的效果并不會很理想。
分層數(shù)據(jù)保護(hù)是前向糾錯對于分層的方案。分層指的是數(shù)據(jù)包里面有不同重要程度的數(shù)據(jù),對于不同程度的數(shù)據(jù)分段對它進(jìn)行保護(hù)。
前向糾錯的數(shù)據(jù)包是基于RTP標(biāo)準(zhǔn)上設(shè)計(jì)的。前面是RTP包頭,后面是前向糾錯的數(shù)據(jù)包的格式。
FEC算法其中一個稱之為異或。假如有4個數(shù)據(jù),那么它們可以取4個異或值,其中每一個數(shù)據(jù)都可以由另外4個異或計(jì)算出來。還可以把ABCD和E想象成一個數(shù)據(jù)包,如果我們傳輸ABCD這四個數(shù)據(jù)包,第五個數(shù)據(jù)包傳輸?shù)氖荅,這五個數(shù)據(jù)包可以丟失任何1個數(shù)據(jù)包。接收方收到數(shù)據(jù)之后,能夠把它丟的數(shù)據(jù)恢復(fù)出來。前向糾錯算法能處理的是連續(xù)數(shù)據(jù)里只丟1個包。同時丟失A和B,這個算法不能解決。
因此這給予我們更多的操作空間。我們把將參數(shù)想成數(shù)據(jù)包,里面包含5個參數(shù)即5個數(shù)據(jù)包。左邊設(shè)8個方程,8個方程可以解出來該5個數(shù)據(jù)包的值,通過8個方程可以解出右邊的一個結(jié)果。在傳輸數(shù)據(jù)的時候,額外的幾個方程組,即冗余的數(shù)據(jù)。也就是說原來的數(shù)據(jù)傳的是12345這5個數(shù)據(jù)。然后又額外傳了C,假如這8個數(shù)據(jù)里面任意丟了三個數(shù)據(jù)C1、C2和C3,程序可以利用其他內(nèi)容額外把它們恢復(fù)出來,這個邏輯就是糾錯過程冗余,以及冗余可以在任意位置恢復(fù)出來的原因。該算法的好處是可以連續(xù)的丟數(shù)據(jù),比如網(wǎng)絡(luò)傳輸?shù)臅r候,傳1到10這樣數(shù)據(jù),這個時候我們使用冗余度是5,10個數(shù)據(jù)有5個是冗余的,既50%的冗余度。這5個數(shù)據(jù)當(dāng)中我們?nèi)我鈦G失5個數(shù)據(jù),接收方認(rèn)為這個數(shù)據(jù)包是完成的,沒有丟任何數(shù)據(jù),不需要重傳,也不需要多媒體相關(guān)的糾錯法。網(wǎng)絡(luò)傳輸過程當(dāng)中,每次發(fā)出去的數(shù)據(jù)不需要等待重傳的延遲,可以把冗余數(shù)據(jù)發(fā)送出去。對于接方來講,在帶寬可以接受的情況下,延遲仍然是最低的。
交叉?zhèn)鬏?/strong>
最后一個策略是交叉?zhèn)鬏敚覀內(nèi)粘?吹蕉嗝襟w可能是按照時序的,一個多媒體片斷是由1到10組成。如果此過程當(dāng)中有丟包,比如3456連續(xù)丟失,那么此次丟包的影響可能表現(xiàn)在視頻播放出現(xiàn)停頓。若丟的是關(guān)鍵幀那么影響非常大,會導(dǎo)致后面一大片的花屏。因此當(dāng)連續(xù)丟包對流媒體傷害特別大的情況下,可以采用交叉?zhèn)鬏敳呗浴?到10,原來是3個3個傳,如123、456、789各傳一次,那么現(xiàn)在可以改變傳輸策略,采用147、 280和369的傳輸策略,這樣一組數(shù)據(jù)丟掉,實(shí)際丟失在流媒體中間穿插的數(shù)據(jù),播放程序可以在幾乎不失真的狀態(tài)下把視頻恢復(fù)出來。
上述提到的RTP協(xié)議不僅可以基于UDP協(xié)議,也可以基于TCP協(xié)議。只是大部分利用RTP協(xié)議的場景實(shí)際上是基于UDP協(xié)議的。DCCP是一個擁塞控制的策略,里面包含4項(xiàng)內(nèi)容:首先是建立會話,像TCP的握手;第二是數(shù)據(jù)窗口,可能很多時候要處理一個數(shù)據(jù)序號的順序和整合一些數(shù)據(jù)碎片;第三是反饋,ACK就是關(guān)于數(shù)據(jù)到達(dá)反饋;最后是擁塞控制。其中數(shù)據(jù)窗口、反饋還有擁塞控制是影響傳輸質(zhì)量的關(guān)鍵。
數(shù)據(jù)窗口跟數(shù)據(jù)的時效性關(guān)系很大,使用TCP協(xié)議時大部分?jǐn)?shù)據(jù)長度跟時間關(guān)系不是那么強(qiáng)。但是會議場景對時效性要求較高。數(shù)據(jù)窗口里面時間很難超過1秒,1秒以后的數(shù)據(jù)其實(shí)就已經(jīng)不再有任何用處了。
在Ack里面,一般會有兩個策略:一種是直接告訴發(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則為我們提供一個方案,讓我們自己控制擁塞控制,傳輸延遲和數(shù)據(jù)質(zhì)量,對此我們可以有一個很強(qiáng)的掌控力。
聯(lián)系客服