摘 要：本文從SRT協議的工作流程談起，著重介紹和解析了SRT協議的數據包結構，并舉例說明如何利用Wireshark抓包軟件進行鏈路故障分析，從而解決實際工作中的問題。

引 言

SRT（Secure Reliable Transport）協議即安全可靠傳輸協議，是一種新興的視音頻傳輸協議，能夠在公共互聯網環境下實現高質量低延時的實時視音頻傳輸。公網傳輸技術之SRT協議解析（上）著重討論了如何衡量SRT協議的可靠程度，以及如何在不同應用場景下配置SRT鏈路的參數。本文作為下篇，將從SRT協議的工作流程入手，對SRT協議的數據包結構進行解析，之后舉例介紹如何利用Wireshark軟件進行抓包分析，從而排除鏈路故障或者獲取鏈路信息。

1SRT協議工作流程

SRT協議中最常用的工作模式為“呼叫-監聽”（Caller-Listener）模式，監聽方（Listener）會持續監聽本方的固定UDP端口，呼叫方（Caller）通過訪問監聽方的公網IP地址和該固定端口來建立SRT連接。呼叫和監聽的角色主要在SRT協議握手階段起作用，無論是編碼端還是解碼端都可以擔任呼叫者或監聽者的角色。

圖1表示了SRT協議的工作流程，整個流程包括握手、參數交換、數據傳輸、連接關閉等步驟。另外在傳輸有效數據時，雙方會發送控制數據來完成丟包恢復、連接保持等功能。

圖1 SRT協議工作流程

2SRT數據包結構

SRT協議根據UDT協議（UDP-based Data Transfer Protocol）改進而來，已經在2020年3月10日向IETF提交了RFC草案，這也表示SRT協議進入了比較穩定的發展軌道。

眾所周知，SRT的傳統優勢領域是點對點的實時音視頻傳輸，而近兩年，SRT協議在上行推流方面有了迅速的發展，很多主流平臺和公司都支持使用SRT協議來代替RTMP協議進行上行推流，其中的關鍵點就是SRT的StreamID功能，而StreamID功能就包含在SRT握手數據包的配置擴展模塊中。

總的來說，SRT協議中包含兩類數據包：信息數據包（Data Packet）和控制數據包（Control Packet），他們通過SRT首部的最高位（標志位）來區分，0代表信息數據包，1代表控制數據包。控制數據包又包含了握手（Handshake）、肯定應答（ACK）、否定應答（NAK）、對肯定應答的應答（ACKACK），保持連接（Keepalive）、關閉連接（Shutdown）等多種類型。

2.1信息數據包結構

圖2展示了SRT信息數據包的結構，其承載了需要傳輸的有效數據。SRT首部長度為16字節，最高位為標志位，SRT信息數據包首部包含四個區域：數據包序列號、報文序號、時間戳、目的地端套接字ID。

數據包序列號：SRT使用基于序列號的數據包發送機制，發送端每發送一個數據包，數據包序列號加1。

報文序號：報文序號獨立計數，在它之前設置了四個標志位（見圖2）。

時間戳：以連接建立時間點（StartTime）為基準的相對時間戳，單位為微秒。

目的地端套接字ID：在多路復用時用來區分不同的SRT流。

圖2 SRT信息數據包

2.2握手數據包結構

握手數據包分為HSv4版本（SRT版本<1.3）和HSv5版本（SRT版本>=1.3），圖3為HSv5版本握手數據包的結構，HSv5握手數據包主要包含五個區域：SRT首部、握手控制信息（cif.hsv5）、握手請求/響應擴展模塊（hsreg/hsrsp）、加密擴展模塊（kmreg/kmrsp）、配置擴展模塊（config）。這里重點介紹前三個區域，握手數據包的結構參見圖3:

圖3 HSv5握手數據包

1.所有SRT控制數據包的首部是基本相同的，均包含四個區域：控制類型和保留區域、附加信息、時間戳、目的地端套接字，其中控制類型字段為0代表握手數據包。

2.握手控制信息區域（cif.hsv5）中比較重要的字段如下：

ISN：隨機生成的數據包初始序列號，之后所有的信息數據包以此為基準計數。

握手類型：該字段第一個作用是表示該握手數據包所處的握手階段（以“呼叫-監聽”模式為例，其握手分為誘導階段Induction和結尾階段Conclusion），第二個作用對于用戶來說更為重要，在握手失敗后“握手類型”字段會顯示相應的錯誤碼，錯誤碼所對應的錯誤類型見表1。

錯誤碼	錯誤類型	錯誤碼	錯誤類型
1000	未知原因	1008	對端版本過舊
1001	系統功能錯誤	1009	集合模式套接字沖突
1002	對端拒絕	1010	密碼錯誤
1003	資源分配問題	1011	需要密碼
1004	握手中的錯誤數據	1012	Stream標志位沖突
1005	監聽方Backlog溢出	1013	擁塞控制類型沖突
1006	內部程序錯誤	1014	包過濾器沖突
1007	該套接字已關閉	1015	組沖突

表1 錯誤碼和錯誤類型對應表1

SRT套接字ID：該字段需要和SRT首部中的目的地端套接字ID加以區分，該字段只作用于握手階段，而目的地端套接字ID作用于數據傳輸全過程。

同步cookie：在“呼叫-監聽”模式下，出于防止DoS攻擊的目的，只由監聽方生成同步cookie，該cookie由監聽方的主機、端口和當前時間生成，精確度為1分鐘。

3.握手請求擴展模塊（HSREG）中比較重要的字段如下：

SRT版本：只要有任何一方的SRT版本低于1.3，雙方就會以HSv4版本握手方式來建立連接，HSv4方式握手會有三次或四次往返，而最新的HSv5握手只需要兩次往返。出于兼容性的考慮，即使雙方的SRT版本都高于1.3，第一個握手請求信息也是HSv4格式。

SRT標志位：共有8位標志位，來實現SRT的不同模式和功能。

發送方向延時和接收方向延時：SRT協議1.3版本實現了雙向傳輸功能，雙向傳輸可以分別設定不同方向的固定延時。對于常規的單向傳輸，假設A向B發送數據，該方向的延時量Latency應該是A的發送方向延時（PeerLatency）和B的接收方向延時（RecLatency）的最大值，該延時量在握手階段就已由雙方協商確定。在單向傳輸時，有一些編解碼器將它的PeerLatency和RecLatency設置成統一的值，這種簡易設置方法并不會影響單向傳輸的工作。

4.加密擴展模塊KMREQ和配置擴展模塊CONFIG

由于篇幅的原因，最后兩個非必需的擴展模塊不再詳細討論。其中加密擴展模塊（KMREQ）主要負責SRT的AES128/AES192/AES256加密功能的實現。而配置擴展模塊（CONFIG）包含了四種：SRT_CMD_SID、SRT_CMD_CONGESTION、SRT_CMD_FILTER、SRT_CMD_GROUP，其中SRT_CMD_SID擴展模塊就是負責SRT上行推流中不可或缺的StreamID功能，有興趣的朋友可以自行抓包查看。

2.3ACK數據包結構

ACK數據包是由SRT接收端反饋給發送端的肯定應答，發送端收到ACK后便會認為相應數據包已經成功送達。ACK數據包中還包含了接收端估算的鏈路數據，可以作為發送端擁塞控制的參考。ACK數據包結構見圖4，其中幾個比較重要的字段如下：

圖4 ACK控制數據包

控制類型：該字段等于2便表示ACK數據包。

附加信息：其中包含了獨立計數的ACK序列號，該序列號主要用于ACK包和ACKACK包的一一對應。

最近一個已接收數據包的序列號+1：該字段的值等于最近一個已收到的信息數據包的序列號加1，例如ACK包中該字段為6，便表示前5個數據包均已收到，發送端可以將它們從緩沖區中踢出。需要注意本字段是和數據包序列號有關，與ACK序列號無關。

往返時延RTT估值：通過ACK數據包和ACKACK數據包估算出的鏈路往返時延。

往返時延RTT估值的變化量：該變化量能夠衡量RTT的波動程度，數值越大表示鏈路RTT越不穩定。

接收端可用緩沖數據：表示目前接收端緩沖區有多少緩沖數據可供解碼，該數值越大越好，其最大值由延時量參數（Latency）決定。

鏈路帶寬估值：對本次鏈路帶寬的估算值。

接收速率估值：接收端下行網絡帶寬的估算值。

2.4NAK數據包結構

當SRT接收端發現收到的數據包序列號不連續時，便會判斷有數據包丟失，并立刻向發送方回復否定應答（NAK）數據包。此外SRT接收端還會以一定間隔發送周期NAK報告，其中包括了間隔期的所有丟失包序列號，這種重復發送NAK的機制主要為了防止NAK數據包在反向傳輸中丟失。NAK數據包結構見圖5，其控制類型字段等于3，包內含有丟失數據包的序列號列表。

圖5 NAK控制數據包

2.5ACKACK數據包結構

ACKACK的主要作用是用來計算鏈路的往返時延（RTT），而RTT作為重要的鏈路信息會包含在ACK數據包中，ACKACK數據包結構參見圖6。首先ACK數據包和ACKACK數據包都包含有精準的時間戳和ACK序列號，當發送端傳輸給接收端ACK數據包時，接受端會立刻返回一個ACKACK數據包，之后發送端會根據“ACK序列號”將ACK包和ACKACK包一一對應起來，并通過將他們的時間戳相減從而得到鏈路的往返時延（RTT）。

圖6 ACKACK數據包結構

2.6連接保持和連接關閉數據包結構

SRT中最后兩個數據包類型是連接保持（Keepalive）數據包和連接關閉（Shutdown）數據包，它們的數據包結構參見圖7和圖8。

圖7 連接保持數據包結構

圖8 連接關閉數據包結構

3Wireshark抓包分析

Wireshark是被業界廣泛使用的開源數據包分析軟件，它可以截取各類網絡數據包，并顯示數據包的詳細信息。隨著廣電行業IP化的不斷推進，Wireshark的使用也越來越頻繁，其重要性可類比于波形監視器對于SDI信號的作用，以及碼流分析儀對于TS流信號的作用。

下面列舉了兩個利用Wireshark軟件進行鏈路分析的例子：

3.1場景一 連接失敗

在SRT鏈路的搭建過程中，難免會遇到連接失敗的情況，其原因是多種多樣的，這時我們便可以利用Wireshark的抓包分析功能來判斷錯誤的類型。

圖9是連接失敗后的抓包數據，抓包視頻可參見下方視頻。首先可以觀察到雙方在不停的交換握手數據包，說明握手沒有成功，但另一方面也說明IP地址和端口號是設置正確的，雙方能夠正常通信。

在雙方SRT版本都高于1.3的情況下，SRT握手過程需要兩次往返，既有四個握手數據包，并且第一個握手數據包一定是HSv4版本握手數據包，由此我們可以定位出第一個握手數據包。接著觀察到第四個握手數據包的“Handshake Type”字段是1002-Reject，含義是“對端拒絕”，這表示雙方可能在某個參數上不匹配而導致了握手失敗。

我們接著查看第二個握手包，這是監聽方發給呼叫方的響應，其中“Encryption Field”區域為AES-128，即要求對方以AES-128的方式響應加密。再查看第三個握手包，這是呼叫方發給監聽方的，其中“Extended Field”區域的KMREQ模塊為NOT，表示該握手包沒有加密擴展模塊，即沒有響應對方的加密要求。

經過以上的分析，我們可以得知這次連接失敗是因為Listener方要求對端以AES-128的方式響應加密要求，而Caller方并沒有做出加密的響應。如果要成功連接，我們就需要獲知Listener方的加密密碼，并在Caller方選擇AES-128的加密方式。

圖9 場景一：通過抓包分析找出故障原因

3.2場景二 獲取鏈路信息

互聯網鏈路中單次往返時延（RTT-Round Trip Time）表示了數據在發送端和接收端之間往返一次花費的時間。鏈路的RTT值以及RTT的波動程度決定了SRT鏈路延時量參數的設置，但實際工作中由于防火墻等原因往往難以直接獲得RTT值，這時我們可以通過Wireshark軟件對ACK數據包進行分析來獲得相應信息。

通過圖10可以看到，鏈路的RTT是20.61毫秒，而RTT的變化量是9.786毫秒，這也說明了該條鏈路的RTT并不穩定，而RTT波動意味著丟包重傳需要的時間也會隨之波動，從而帶來整條SRT鏈路差錯控制能力的波動，這也意味著我們必須依照該條鏈路的特性進行參數調整。

圖10 場景二：RTT估值和RTT估值的變化量

總 結

SRT協議由于其優異的性能、較低的軟硬件要求、開源免費的特性，在各個領域的應用越來越廣泛，最近兩年在上行推流方面也有了長足的發展。掌握好SRT協議的數據包結構能夠幫助我們使用抓包軟件進行故障分析和判斷，從而快速準確地解決實際工作中出現的問題，希望本文能夠給大家帶來一些幫助，也歡迎大家討論和交流。

原文標題：公網傳輸技術之SRT協議解析（下）

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關注！文章轉載請注明出處。