SRT（Secure Reliable Transport）是新一代低延遲視頻傳輸協議，是一種開源、免費和應用靈活的規範，它的性能與專用的協議一樣優秀，同時能夠在不同製造商生產的產品之間工作。本文主要參考Haivision的SRT白皮書，概述了SRT的一些關鍵特性，並將SRT與常見傳輸格式及新一代傳輸協議QUIC進行比較，最後簡述SRT的發展現狀。
關鍵特性
直接建立連接
SRT允許直接在信號源和目標之間建立連接，這與許多現有的視頻傳輸系統形成了鮮明對比，這些系統需要一臺集中式服務器從遠程位置收集信號，並將其重定向到一個或多個目的地。基於中央服務器的體系結構有一個單點故障，在高通信量期間，這也可能成爲瓶頸。通過集線器傳輸信號還增加了端到端信號傳輸時間，並可能使帶寬成本加倍，因爲需要實現兩個鏈接:一個從源到中心集線器，另一個從中心到目的地。通過使用直接從源到目的地的連接，SRT可以減少延遲，消除中心瓶頸，並降低網絡成本。
使用ARQ機制進行包投遞
比較三種包投遞機制，頂部是一個未經糾正的數據流，每當包丟失時，輸出信號就會產生錯誤。中間按照前向糾錯 (Forward Error Correction，FEC)機制，它向流中添加固定數量的額外數據，可用於重新創建丟失的包。底部按照自動重傳請求（Automatic Repeat-reQuest，ARQ）機制，發送方根據接收方的請求重新發送丟失的包，從而避免了FEC的恆定帶寬消耗。
ARQ的工作原理是在視頻源和目標之間建立雙向連接。每個出站數據包被賦予一個唯一的序列號，而接收者使用這些序列號來確定是否以正確的順序正確地接收了所有傳入的數據包。如果數據包在網絡中丟失，接收方可以創建丟失信息包的序列號列表，並自動向發送方發送請求，以便重新傳輸。對於錯誤率高的網絡(特定時間或發生故障時的網絡)，這個過程可以重複多次。ARQ要求在發送位置進行緩存(爲了在需要重傳的情況下臨時存儲數據包)，在發送到視頻解碼器或其他接收器之前，在接收位置設置一個緩衝區，將數據包重新排列到正確的順序。
SRT使用ARQ機制主要是因爲它可以處理互聯網上最常見的錯誤類型，即損失主要是由隨機的丟包造成的。這些錯誤可以很容易地通過發送方對沒有到達接收方的任何數據包進行簡單的重傳來修復。如果包含位錯誤的信息包到達接收方，它們將被視爲丟失的信息包，發送方將被要求重新傳輸它們。另一個好處是，SRT爲每個包提供高分辨率的時間戳，以便在接收端輸出時精確地再現媒體流的時序。這有助於確保下游設備能夠正確解碼視頻和音頻信號。
而FEC只適用於能夠支持FEC數據所需額外帶寬的系統，以及能夠承受網絡錯誤率超過閾值時可能發生的信號中斷的系統。
使用UDP包格式
SRT會話期間發送的每個包都使用UDP(User Datagram Protocol)包格式，它提供了低開銷、低延遲的包投遞。大多數爲專業應用程序而設計的實時媒體傳輸網絡都使用UDP，因爲它提供了穩定的、可重複的包投遞系統，具有一致的吞吐量。
不使用TCP(Transmission Control Protocol)的原因在於TCP要求流的所有字節完全按照它們的原始順序交付。雖然這聽起來像是一種發送視頻的好方法，但經驗表明並非如此。有了視頻，一些丟失的字節可以被糾正，或者在最壞的情況下被忽略。使用TCP，不可能跳過壞字節;相反，只要它需要,協議將繼續重試發送丟失的數據。這是許多凍結幀的來源，也是在擁擠的網絡環境中出現“rebuffering”符號的原因，可能會對觀衆產生重大影響。TCP的第三個影響是微妙的，但對視頻傳輸很重要。TCP在網絡擁塞發生時自動降低包傳輸速率，雖然這種行爲有利於減少網絡中的總體擁塞，但它不適用於視頻信號，因爲視頻信號的速度不能低於其標稱比特率。
以握手和功能信息交換開始
SRT提供了三種不同的握手模式，讓設備相互聯繫，並設置發送和接收數據包所需的必要數據，例如IP地址。第一種是調用模式，其中SRT端點試圖連接到一個已知地址和UDP端口號的遠程設備。第二種是偵聽器模式，在這種模式下，SRT設備將持續監視傳入的通信流，以將其監視到定義的地址和端口號，以等待來自調用方設備的連接。第三種模式稱爲“匯聚”，其中兩個端點同時充當調用者和偵聽器，以便通過特定類型的防火牆更容易地建立連接。
每次握手都需要在繼續之前通過使用安全cookie對端點標識和密碼進行雙向確認。握手過程完成後，調用者和偵聽器交換它們的功能和配置。網絡的兩端都需要知道兩個端點之間的總體延遲，以便能夠建立正確的緩衝區大小來處理包重傳延遲。連接帶寬也可以估計和通信，以允許視頻被壓縮至適應網絡的容量。可以選擇在發送方和接收方之間交換加密密鑰，以使用AES 128/192/256位加密對IP包內的視頻和音頻內容進行加密，使傳輸更安全。
SRT與常見傳輸格式比較
SRT與目前市場上的大多數其他視頻流傳輸格式(如RTMP、HLS和MPEG-DASH)相比有幾個特點，包括:
非專有
SRT是一個開源解決方案，已經集成到多個平臺和體系結構中，包括基於硬件的可移植解決方案和基於軟件的雲解決方案。因爲所有的系統都依賴於相同的底層代碼庫，所以互操作性被簡化了。
能處理長時間的網絡延遲
由於其靈活的、自適應的緩衝區管理系統，SRT可以在幾毫秒到幾秒的延時之間的連接上很好地工作，因此可以處理任何可能在私有網絡或全球Internet上發現的東西。
支持多種流類型
與其他一些只支持特定視頻和音頻格式的解決方案不同，SRT與負載無關。任何類型的視頻或音頻媒體，或者實際上任何可以使用UDP發送的其他數據元素，都與SRT兼容。
支持多個併發流
多個不同的媒體流例如多個攝像機角度或可選音頻軌道，可以通過在一個點對點鏈接上共享相同UDP端口和地址的並行SRT流發送。這可以在保持每個信號的媒體格式和時序的同時實現，從而允許MP4視頻信號與JPEG2000流共享鏈接。這簡化了網絡配置和防火牆遍歷。
增強防火牆遍歷
任何現代組織，無論是基於媒體還是其他，都不允許企業系統無限制地訪問公共互聯網。防火牆保護私有網絡設備(如pc和服務器)免受不必要的外部連接和攻擊。SRT使用的握手過程支持出站連接，而不需要在防火牆中打開危險的永久外部端口，從而維護公司安全策略。
信號時間準確
許多壓縮視頻信號格式對信號不同元素之間的時序變化所造成的中斷非常敏感。使用SRT，每個數據包都有一個由發送方分配的高分辨率時間戳，接收方可以恢復該時間戳，以精確重建信號時序關係，而不考慮網絡延遲變化。此外，在握手過程中，SRT端點建立了穩定的端到端延遲概要，消除了下游設備需要有自己的緩衝區來應對不斷變化的信號延遲。
無需中央服務器
一些專有媒體傳輸系統需要在發送方和接收方之間使用集中式服務器，這會增加成本和延遲。SRT連接可以直接在設備之間進行，因此不需要中央服務器。此外，如果需要，可以使用集中式服務器和中繼點部署SRT，以便應用程序(如基於雲的內容收集系統和以集中式模型爲首選的剪輯分發網絡)。
成本低
SRT系統是使用免費的開放源代碼庫實現的，這有助於降低各方的成本。SRT部署不需要版稅、長期合同或每月訂閱費。
基於API
SRT技術包基於API，允許供應商與平臺和端點建立緊密的、可重複的集成。
擁有開源社區
SRT已被業界領先的開源項目所採用，例如:VideoLAN的VLC，免費的開源跨平臺多媒體播放器和框架;GStreamer是小型設備和移動設備的基礎流引擎;Wireshark，領先的網絡流分析儀;FFmpeg是世界上最流行的開源視頻壓縮工具包。
與QUIC比較
SRT和QUIC都旨在克服UDP的包丟失和測序問題，同時消除TCP(傳輸控制協議)常見的緩衝延遲。兩種協議都使用TLS 1.3提供安全傳輸，TLS 1.3是傳輸層安全協議的最新版本。
QUIC使用了許多技術來最小化阻塞，例如根據每個流所採取的路徑估計持久帶寬，根據帶寬判斷包生成的節奏，以及主動重傳支持錯誤糾正或開始加密等事情的最重要的包。
QUIC還通過減少建立連接所需的往返次數，以及避免在建立了主連接之後在Web頁面上與次要源建立連接，從而降低了延遲。與握手、加密設置和初始數據請求相關聯的多個步驟合併在初始設置中，而像HTTP/2所採用的壓縮和多路複用過程用於避免訪問頁面上的子源的單獨設置。
SRT使用了許多這些技術的變體，包括快速會話設置、帶寬估計和通過低延遲重傳技術處理包丟失恢復，它在擁塞高時通過丟包來緩和這種情況。但是，SRT不是依賴HTTP和ABR來改變比特率以適應帶寬可用性的變化，而是實時分析網絡條件並過濾掉抖動、噪聲和擁塞的影響。
由於SRT與HTTP Live streaming (HLS)、MPEG-DASH和其他ABR模式下的流媒體標準大相徑庭，因此在中段和終段應用程序中，它面臨着一場艱苦的戰鬥。
發展現狀
在今年5月舉行的plug-in大會上，15個聯盟成員成功完成了50多項測試，驗證了攝像頭、編碼器、解碼器、網關、多觀衆和玩家之間的SRT流。
Haivision 和 Wowza共同創建了SRT聯盟，自從SRT在2017年成爲一種開源技術以來，已有130多家公司通過支持SRT聯盟支持了該開源項目。他的供應商和終端用戶共同努力，以提高業界對SRT的認識，並將其作爲互聯網上低延遲視頻傳輸的通用標準。突出的SRT聯盟成員包括Ateme、Blonder Tongue、Brightcove、Ericsson、Eurovision、Haivision、Harmonic、Limelight,、Matrox、Sencore和Wowza。
現在，有超過50種支持SRT的產品已經上市，包括IP攝像機、編碼器、解碼器、網關、OTT平臺和CDNs。SRT協議在全球許多應用程序和市場上被數千個組織使用。最終用戶包括康卡斯特(Comcast)、ESPN、福克斯新聞(Fox News)、微軟(Microsoft)、NBC體育(NBC Sports)、美國橄欖球聯盟(NFL)和騰訊(Tencent)。
參考資料
[1]https://www.haivision.com/resources/white-paper/
[2]http://www.screenplaysmag.com/2018/08/14/udp-based-streaming-modes-battle-for-traction-as-paths-to-low-latency/