1.SRT的前世今生

SRT是安全(Security)可靠IReliable)傳輸(Transport)的首字母組合，簡(jiǎn)單來(lái)說(shuō)SRT就是一個(gè)安全可靠的傳輸協(xié)議。

SRT源自UDT協(xié)議。UDT創(chuàng)建于2001年，其設(shè)計(jì)目標(biāo)是在公共網(wǎng)絡(luò)上以最短的時(shí)間傳輸文件。UDT開(kāi)發(fā)者向IETF提交過(guò)4份草案，其最終版本停留在了2013年。同樣是在2013年，Haivision（一家編碼器供應(yīng)商）擴(kuò)展了UDT的實(shí)時(shí)音視頻傳輸能力，并在4年后（2017年）將其開(kāi)源并取名為SRT。

2.選擇TCP還是UDP？

SRT作為流媒體傳輸協(xié)議中的一種，在詳細(xì)講解之前，需要先弄清楚流媒體傳輸協(xié)議和我們通常所說(shuō)的傳輸層協(xié)議TCP、UDP有什么不同？

我們通常所說(shuō)的流媒體傳輸協(xié)議屬于應(yīng)用層協(xié)議，而TCP、UDP則是屬于傳輸層協(xié)議，也就是說(shuō)流媒體傳輸協(xié)議其實(shí)是依賴于傳輸層協(xié)議才能工作的，如圖1所示。因此所有的流媒體協(xié)議其底層都通過(guò)使用TCP或者UDP來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)傳輸。

圖1

流媒體協(xié)議底層應(yīng)該選擇TCP還是UDP？

主流的流媒體協(xié)議選擇TCP和UDP協(xié)議的都有，例如RTMP協(xié)議底層選擇的是TCP，而QUIC、SRT協(xié)議選擇的是UDP。但從趨勢(shì)來(lái)看，新的流媒體協(xié)議大都選擇UDP作為底層傳輸協(xié)議，其主要原因和流媒體業(yè)務(wù)本身的特性及TCP特性有關(guān)。

從流媒體最常見(jiàn)的業(yè)務(wù)直播來(lái)看，用戶需要直播出流快，延時(shí)低，不卡頓，在遇到弱網(wǎng)的情況下，能接受損失一部分畫(huà)面，但是希望能快速恢復(fù)。

但是這種要求對(duì)于TCP協(xié)議而言，則很難做到這些。

首先，TCP協(xié)議需要經(jīng)過(guò)3次握手才能建立鏈接，如要通過(guò)TLS加密則還需要4次的握手，要是上層還有流媒體協(xié)議，則需要更多的交互流程，因此在建立鏈接方面，TCP協(xié)議交互流程太多，不適合快速出流。

其次，由于TCP協(xié)議是一個(gè)高可靠且有序的協(xié)議，因此如果出現(xiàn)序號(hào)較低的數(shù)據(jù)包丟了，即使序號(hào)高的已經(jīng)收到了，也要等序號(hào)低的重傳接收后才能使用，導(dǎo)致當(dāng)前窗口阻塞在原地（TCP隊(duì)頭阻塞），要是重傳的數(shù)據(jù)包也丟失，觸發(fā)再次重傳需要等待的時(shí)間會(huì)加倍（重傳策略溫和），而這個(gè)機(jī)制會(huì)影響數(shù)據(jù)的傳輸效率，對(duì)于實(shí)時(shí)性要求較高的流媒體業(yè)務(wù)，是不可接受的。

最后，在遭遇弱網(wǎng)情況下，TCP協(xié)議的慢啟動(dòng)和擁塞避免算法都會(huì)大幅度的降低自身的帶寬占用，從而保護(hù)整個(gè)通信鏈路的穩(wěn)定（TCP是一個(gè)無(wú)私的協(xié)議），所以在這種策略下一旦遭遇弱網(wǎng)，表現(xiàn)出來(lái)就是直播畫(huà)面卡頓，基本沒(méi)有弱網(wǎng)對(duì)抗能力。

總結(jié)，基于以上幾點(diǎn)，TCP協(xié)議并不適合作為流媒體傳輸協(xié)議的底層協(xié)議，其協(xié)議在設(shè)計(jì)之初并沒(méi)有考慮實(shí)時(shí)性的要求，下面我們一起看一下SRT協(xié)議如何解決上面提到的問(wèn)題

3.SRT協(xié)議詳解

SRT協(xié)議通過(guò)簡(jiǎn)單的握手、固定的延時(shí)量、ARQ（自動(dòng)重傳請(qǐng)求）、FEC（前向糾錯(cuò)）以及ACK、NACK等策略解決TCP協(xié)議在流媒體業(yè)務(wù)上存在的問(wèn)題。

3.1. SRT如何解決握手耗時(shí)長(zhǎng)問(wèn)題？

SRT握手如圖2所示，通過(guò)2次握手和參數(shù)交換即可快速建立起一個(gè)SRT鏈接（總耗時(shí)：2RTT），相比基于TCP的流媒體協(xié)議RTMP 3RTT的握手時(shí)間，總耗時(shí)減少1個(gè)RTT。

圖2

3.2. SRT如何實(shí)現(xiàn)可靠傳輸

從圖2流程圖中發(fā)現(xiàn)SRT握手結(jié)束之后，就可以發(fā)媒體數(shù)據(jù)和控制指令，媒體數(shù)據(jù)結(jié)構(gòu)如圖3所示。

圖3

• 數(shù)據(jù)包序列號(hào)：數(shù)據(jù)包序號(hào)的初始值在握手時(shí)確定，之后每發(fā)一個(gè)數(shù)據(jù)包，數(shù)據(jù)包序號(hào)就會(huì)加1；
• 報(bào)文序號(hào)：報(bào)文序號(hào)從0開(kāi)始，之后每發(fā)一個(gè)數(shù)據(jù)包，報(bào)文序號(hào)就會(huì)加1，報(bào)文序號(hào)前4個(gè)標(biāo)志位功能如圖3所示；
• 時(shí)間戳：以建立時(shí)間為基準(zhǔn)，單位為微秒；
• 目的地端口套接字ID：在多路復(fù)用的時(shí)候可以用來(lái)區(qū)分不同的SRT流。

ACK控制指令如圖4所示。

圖4

SRT通過(guò)數(shù)據(jù)包序列號(hào)和報(bào)文序號(hào)，能明確那些數(shù)據(jù)包已經(jīng)被發(fā)送出去，通過(guò)接收端發(fā)送過(guò)來(lái)的ACK控制指令就知道發(fā)送出去的哪些數(shù)據(jù)已經(jīng)被成功接收了。如果出現(xiàn)丟包等情況，接收端通過(guò)NAK控制指令（如圖5所示）通知發(fā)送端重傳數(shù)據(jù)。通過(guò)以上方式，SRT實(shí)現(xiàn)了可靠傳輸。

圖5

3.3. SRT如何實(shí)現(xiàn)解決隊(duì)頭阻塞問(wèn)題

上文描述了SRT如何實(shí)現(xiàn)可靠傳輸，從實(shí)現(xiàn)來(lái)看，發(fā)送端必須有一個(gè)發(fā)送緩存區(qū)，接收端也需要一個(gè)接收緩沖區(qū)才能實(shí)現(xiàn)在丟包后數(shù)據(jù)重傳的機(jī)制（這和TCP的實(shí)現(xiàn)原理相似）。SRT協(xié)議通過(guò)設(shè)置固定延時(shí)量來(lái)統(tǒng)一規(guī)定發(fā)送緩沖區(qū)和接收緩沖區(qū)的大小。

發(fā)送緩沖區(qū)用來(lái)保存有可能需要重發(fā)的數(shù)據(jù)包，一旦數(shù)據(jù)包收到了肯定應(yīng)答(ACK)，則該數(shù)據(jù)包會(huì)被清理出發(fā)送緩沖區(qū)（這點(diǎn)和TCP也類似），一旦發(fā)送緩沖區(qū)某個(gè)數(shù)據(jù)包一直收不到肯定應(yīng)答，則該數(shù)據(jù)包在超過(guò)固定延時(shí)時(shí)間后也會(huì)被清理出發(fā)送緩沖區(qū)，SRT通過(guò)這種方式解決了TCP隊(duì)頭阻塞的問(wèn)題。說(shuō)到這里需要澄清一個(gè)事實(shí)，就是SRT雖然是可靠的傳輸協(xié)議，但是這個(gè)可靠是有條件的，只有在固定延時(shí)量下，數(shù)據(jù)的發(fā)送時(shí)可靠的，一旦超出固定延時(shí)時(shí)間，數(shù)據(jù)還是會(huì)被丟棄，其實(shí)這也符合媒體業(yè)務(wù)的特點(diǎn)（在異常情況下，允許丟失一部分?jǐn)?shù)據(jù)，但是要能快速恢復(fù)）。

3.4. SRT如何實(shí)現(xiàn)實(shí)現(xiàn)自適應(yīng)問(wèn)題

從圖4的ACK內(nèi)容可以發(fā)現(xiàn)，ACK中帶有許多網(wǎng)絡(luò)參數(shù)，例如RTT時(shí)間等。通過(guò)RTT時(shí)間和鏈路帶寬等參數(shù)，SRT就可以估計(jì)整個(gè)網(wǎng)絡(luò)狀態(tài)，從而實(shí)現(xiàn)自適應(yīng)的調(diào)整。需要說(shuō)明的是SRT的發(fā)送策略較為激進(jìn)，不像TCP協(xié)議一樣是一個(gè)無(wú)私的協(xié)議。SRT在網(wǎng)絡(luò)較差的情況下依然會(huì)保持較大的發(fā)送速率，也正是因?yàn)檫@個(gè)特點(diǎn)，在網(wǎng)絡(luò)狀況不好的時(shí)候，SRT能夠占用更大的網(wǎng)絡(luò)帶寬實(shí)現(xiàn)媒體數(shù)據(jù)的發(fā)送，保證流暢度。

但是如果網(wǎng)絡(luò)中都是類似于SRT這種發(fā)送策略激進(jìn)的協(xié)議，到后面會(huì)出現(xiàn)誰(shuí)的數(shù)據(jù)也發(fā)不出去的情況，因此在業(yè)務(wù)的選擇上可以綜合考慮SRT和TCP協(xié)議的特點(diǎn)，優(yōu)先保證重要業(yè)務(wù)占用網(wǎng)絡(luò)帶寬。

3.5. SRT得與失

除了以上對(duì)于SRT的介紹之外，SRT還能實(shí)現(xiàn)媒體數(shù)據(jù)的多路復(fù)用，其原理是利用SRT數(shù)據(jù)包中的目的地端口套接字字段（如圖3所示），多個(gè)SRT端口套接字綁定在同一個(gè)UDP端口上即可實(shí)現(xiàn)SRT的多路復(fù)用。

SRT協(xié)議在有損網(wǎng)絡(luò)情況下表現(xiàn)也較其他流媒體協(xié)議更有優(yōu)勢(shì)，除了上面闡述的機(jī)制之外，SRT協(xié)議中使用精準(zhǔn)時(shí)間戳（如圖3所示）保證接收端收到的數(shù)據(jù)能準(zhǔn)確的還原發(fā)送端的碼率特性和固定的幀間隔。

雖然SRT協(xié)議有很多優(yōu)勢(shì)，但是有一些缺點(diǎn)也不容忽視。首先就是SRT協(xié)議帶寬占用高；其次SRT協(xié)議傳輸策略激進(jìn)，會(huì)影響同網(wǎng)絡(luò)下的其他用戶；最后由于SRT底層是走的UDP，而防火墻對(duì)于UDP并不友好，會(huì)導(dǎo)致握手失敗。

4.如何評(píng)價(jià)一個(gè)新的流媒體協(xié)議？

通過(guò)對(duì)SRT協(xié)議的分析，我們了解到一個(gè)優(yōu)秀的流媒體協(xié)議首先應(yīng)該要能滿足以下要求??

1.能快速的和對(duì)方建立鏈接

2.能知道數(shù)據(jù)是否已經(jīng)送達(dá)

3.能檢測(cè)數(shù)據(jù)是否丟失了，確認(rèn)丟失后能及時(shí)重傳

4.能盡快的發(fā)送數(shù)據(jù)

5.能適應(yīng)對(duì)方的接收能力變化，接收能力強(qiáng)是加快發(fā)送，接收能力弱時(shí)降低發(fā)送

6.能自動(dòng)適應(yīng)網(wǎng)絡(luò)變化，網(wǎng)絡(luò)差時(shí)降低發(fā)送，網(wǎng)絡(luò)好時(shí)增加發(fā)送，占用帶寬合理

將以上幾點(diǎn)進(jìn)行總結(jié)，一個(gè)好的流媒體協(xié)議的評(píng)價(jià)方向有：

• 快速的連接速度
• 良好的確認(rèn)機(jī)制
• 快速的發(fā)送機(jī)制
• 合理的重傳策略
• 優(yōu)秀自適應(yīng)能力

有了以上評(píng)價(jià)標(biāo)準(zhǔn)，我們就能快速的評(píng)價(jià)一個(gè)我們沒(méi)有接觸過(guò)的流媒體協(xié)議是否優(yōu)秀，以及通過(guò)這種方式比較市面上常見(jiàn)的流媒體協(xié)議的優(yōu)劣，評(píng)價(jià)五維圖如圖6所示。

圖6

5.總結(jié)

目前沒(méi)有一種流媒體協(xié)議在設(shè)計(jì)方面全方位領(lǐng)先其他協(xié)議，流媒體協(xié)議的選擇需要與具體的業(yè)務(wù)相結(jié)合，只有在確定了具體的業(yè)務(wù)之后，才有協(xié)議設(shè)計(jì)的優(yōu)劣之分。同時(shí)，我們也必須清楚，協(xié)議設(shè)計(jì)的領(lǐng)先并不是選擇的這個(gè)協(xié)議的唯一標(biāo)準(zhǔn)，還需要考慮行業(yè)的現(xiàn)狀以及服務(wù)提供商的的狀況，正如RTMP協(xié)議雖然已經(jīng)停更將近10年，但是由于大量的服務(wù)提供商還在使用這個(gè)協(xié)議，所以其兼容性特別好，一時(shí)半會(huì)不會(huì)消失。