1.SRT的前世今生

SRT是安全(Security)可靠IReliable)傳輸(Transport)的首字母組合，簡單來說SRT就是一個安全可靠的傳輸協議。

SRT源自UDT協議。UDT創建于2001年，其設計目標是在公共網絡上以最短的時間傳輸文件。UDT開發者向IETF提交過4份草案，其最終版本停留在了2013年。同樣是在2013年，Haivision（一家編碼器供應商）擴展了UDT的實時音視頻傳輸能力，并在4年后（2017年）將其開源并取名為SRT。

2.選擇TCP還是UDP？

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

我們通常所說的流媒體傳輸協議屬于應用層協議，而TCP、UDP則是屬于傳輸層協議，也就是說流媒體傳輸協議其實是依賴于傳輸層協議才能工作的，如圖1所示。因此所有的流媒體協議其底層都通過使用TCP或者UDP來實現網絡傳輸。

圖1

流媒體協議底層應該選擇TCP還是UDP？

主流的流媒體協議選擇TCP和UDP協議的都有，例如RTMP協議底層選擇的是TCP，而QUIC、SRT協議選擇的是UDP。但從趨勢來看，新的流媒體協議大都選擇UDP作為底層傳輸協議，其主要原因和流媒體業務本身的特性及TCP特性有關。

從流媒體最常見的業務直播來看，用戶需要直播出流快，延時低，不卡頓，在遇到弱網的情況下，能接受損失一部分畫面，但是希望能快速恢復。

但是這種要求對于TCP協議而言，則很難做到這些。

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

其次，由于TCP協議是一個高可靠且有序的協議，因此如果出現序號較低的數據包丟了，即使序號高的已經收到了，也要等序號低的重傳接收后才能使用，導致當前窗口阻塞在原地（TCP隊頭阻塞），要是重傳的數據包也丟失，觸發再次重傳需要等待的時間會加倍（重傳策略溫和），而這個機制會影響數據的傳輸效率，對于實時性要求較高的流媒體業務，是不可接受的。

最后，在遭遇弱網情況下，TCP協議的慢啟動和擁塞避免算法都會大幅度的降低自身的帶寬占用，從而保護整個通信鏈路的穩定（TCP是一個無私的協議），所以在這種策略下一旦遭遇弱網，表現出來就是直播畫面卡頓，基本沒有弱網對抗能力。

總結，基于以上幾點，TCP協議并不適合作為流媒體傳輸協議的底層協議，其協議在設計之初并沒有考慮實時性的要求，下面我們一起看一下SRT協議如何解決上面提到的問題

3.SRT協議詳解

SRT協議通過簡單的握手、固定的延時量、ARQ（自動重傳請求）、FEC（前向糾錯）以及ACK、NACK等策略解決TCP協議在流媒體業務上存在的問題。

3.1. SRT如何解決握手耗時長問題？

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

圖2

3.2. SRT如何實現可靠傳輸

從圖2流程圖中發現SRT握手結束之后，就可以發媒體數據和控制指令，媒體數據結構如圖3所示。

圖3

• 數據包序列號：數據包序號的初始值在握手時確定，之后每發一個數據包，數據包序號就會加1；
• 報文序號：報文序號從0開始，之后每發一個數據包，報文序號就會加1，報文序號前4個標志位功能如圖3所示；
• 時間戳：以建立時間為基準，單位為微秒；
• 目的地端口套接字ID：在多路復用的時候可以用來區分不同的SRT流。

ACK控制指令如圖4所示。

圖4

SRT通過數據包序列號和報文序號，能明確那些數據包已經被發送出去，通過接收端發送過來的ACK控制指令就知道發送出去的哪些數據已經被成功接收了。如果出現丟包等情況，接收端通過NAK控制指令（如圖5所示）通知發送端重傳數據。通過以上方式，SRT實現了可靠傳輸。

圖5

3.3. SRT如何實現解決隊頭阻塞問題

上文描述了SRT如何實現可靠傳輸，從實現來看，發送端必須有一個發送緩存區，接收端也需要一個接收緩沖區才能實現在丟包后數據重傳的機制（這和TCP的實現原理相似）。SRT協議通過設置固定延時量來統一規定發送緩沖區和接收緩沖區的大小。

發送緩沖區用來保存有可能需要重發的數據包，一旦數據包收到了肯定應答(ACK)，則該數據包會被清理出發送緩沖區（這點和TCP也類似），一旦發送緩沖區某個數據包一直收不到肯定應答，則該數據包在超過固定延時時間后也會被清理出發送緩沖區，SRT通過這種方式解決了TCP隊頭阻塞的問題。說到這里需要澄清一個事實，就是SRT雖然是可靠的傳輸協議，但是這個可靠是有條件的，只有在固定延時量下，數據的發送時可靠的，一旦超出固定延時時間，數據還是會被丟棄，其實這也符合媒體業務的特點（在異常情況下，允許丟失一部分數據，但是要能快速恢復）。

3.4. SRT如何實現實現自適應問題

從圖4的ACK內容可以發現，ACK中帶有許多網絡參數，例如RTT時間等。通過RTT時間和鏈路帶寬等參數，SRT就可以估計整個網絡狀態，從而實現自適應的調整。需要說明的是SRT的發送策略較為激進，不像TCP協議一樣是一個無私的協議。SRT在網絡較差的情況下依然會保持較大的發送速率，也正是因為這個特點，在網絡狀況不好的時候，SRT能夠占用更大的網絡帶寬實現媒體數據的發送，保證流暢度。

但是如果網絡中都是類似于SRT這種發送策略激進的協議，到后面會出現誰的數據也發不出去的情況，因此在業務的選擇上可以綜合考慮SRT和TCP協議的特點，優先保證重要業務占用網絡帶寬。

3.5. SRT得與失

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

SRT協議在有損網絡情況下表現也較其他流媒體協議更有優勢，除了上面闡述的機制之外，SRT協議中使用精準時間戳（如圖3所示）保證接收端收到的數據能準確的還原發送端的碼率特性和固定的幀間隔。

雖然SRT協議有很多優勢，但是有一些缺點也不容忽視。首先就是SRT協議帶寬占用高；其次SRT協議傳輸策略激進，會影響同網絡下的其他用戶；最后由于SRT底層是走的UDP，而防火墻對于UDP并不友好，會導致握手失敗。

4.如何評價一個新的流媒體協議？

通過對SRT協議的分析，我們了解到一個優秀的流媒體協議首先應該要能滿足以下要求??

1.能快速的和對方建立鏈接

2.能知道數據是否已經送達

3.能檢測數據是否丟失了，確認丟失后能及時重傳

4.能盡快的發送數據

5.能適應對方的接收能力變化，接收能力強是加快發送，接收能力弱時降低發送

6.能自動適應網絡變化，網絡差時降低發送，網絡好時增加發送，占用帶寬合理

將以上幾點進行總結，一個好的流媒體協議的評價方向有：

• 快速的連接速度
• 良好的確認機制
• 快速的發送機制
• 合理的重傳策略
• 優秀自適應能力

有了以上評價標準，我們就能快速的評價一個我們沒有接觸過的流媒體協議是否優秀，以及通過這種方式比較市面上常見的流媒體協議的優劣，評價五維圖如圖6所示。

圖6

5.總結

目前沒有一種流媒體協議在設計方面全方位領先其他協議，流媒體協議的選擇需要與具體的業務相結合，只有在確定了具體的業務之后，才有協議設計的優劣之分。同時，我們也必須清楚，協議設計的領先并不是選擇的這個協議的唯一標準，還需要考慮行業的現狀以及服務提供商的的狀況，正如RTMP協議雖然已經停更將近10年，但是由于大量的服務提供商還在使用這個協議，所以其兼容性特別好，一時半會不會消失。