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

引 言

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

1SRT協(xié)議工作流程

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

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

圖1 SRT協(xié)議工作流程

2SRT數(shù)據(jù)包結(jié)構(gòu)

SRT協(xié)議根據(jù)UDT協(xié)議（UDP-based Data Transfer Protocol）改進而來，已經(jīng)在2020年3月10日向IETF提交了RFC草案，這也表示SRT協(xié)議進入了比較穩(wěn)定的發(fā)展軌道。

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

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

2.1信息數(shù)據(jù)包結(jié)構(gòu)

圖2展示了SRT信息數(shù)據(jù)包的結(jié)構(gòu)，其承載了需要傳輸?shù)挠行?shù)據(jù)。SRT首部長度為16字節(jié)，最高位為標志位，SRT信息數(shù)據(jù)包首部包含四個區(qū)域：數(shù)據(jù)包序列號、報文序號、時間戳、目的地端套接字ID。

數(shù)據(jù)包序列號：SRT使用基于序列號的數(shù)據(jù)包發(fā)送機制，發(fā)送端每發(fā)送一個數(shù)據(jù)包，數(shù)據(jù)包序列號加1。

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

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

目的地端套接字ID：在多路復(fù)用時用來區(qū)分不同的SRT流。

圖2 SRT信息數(shù)據(jù)包

2.2握手數(shù)據(jù)包結(jié)構(gòu)

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

圖3 HSv5握手數(shù)據(jù)包

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

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

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

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

表1 錯誤碼和錯誤類型對應(yīng)表1

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

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

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

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

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

發(fā)送方向延時和接收方向延時：SRT協(xié)議1.3版本實現(xiàn)了雙向傳輸功能，雙向傳輸可以分別設(shè)定不同方向的固定延時。對于常規(guī)的單向傳輸，假設(shè)A向B發(fā)送數(shù)據(jù)，該方向的延時量Latency應(yīng)該是A的發(fā)送方向延時（PeerLatency）和B的接收方向延時（RecLatency）的最大值，該延時量在握手階段就已由雙方協(xié)商確定。在單向傳輸時，有一些編解碼器將它的PeerLatency和RecLatency設(shè)置成統(tǒng)一的值，這種簡易設(shè)置方法并不會影響單向傳輸?shù)墓ぷ鳌?/p>

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

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

2.3ACK數(shù)據(jù)包結(jié)構(gòu)

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

圖4 ACK控制數(shù)據(jù)包

控制類型：該字段等于2便表示ACK數(shù)據(jù)包。

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

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

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

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

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

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

接收速率估值：接收端下行網(wǎng)絡(luò)帶寬的估算值。

2.4NAK數(shù)據(jù)包結(jié)構(gòu)

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

圖5 NAK控制數(shù)據(jù)包

2.5ACKACK數(shù)據(jù)包結(jié)構(gòu)

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

圖6 ACKACK數(shù)據(jù)包結(jié)構(gòu)

2.6連接保持和連接關(guān)閉數(shù)據(jù)包結(jié)構(gòu)

SRT中最后兩個數(shù)據(jù)包類型是連接保持（Keepalive）數(shù)據(jù)包和連接關(guān)閉（Shutdown）數(shù)據(jù)包，它們的數(shù)據(jù)包結(jié)構(gòu)參見圖7和圖8。

圖7 連接保持數(shù)據(jù)包結(jié)構(gòu)

圖8 連接關(guān)閉數(shù)據(jù)包結(jié)構(gòu)

3Wireshark抓包分析

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

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

3.1場景一 連接失敗

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

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

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

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

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

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

3.2場景二 獲取鏈路信息

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

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

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

總 結(jié)

SRT協(xié)議由于其優(yōu)異的性能、較低的軟硬件要求、開源免費的特性，在各個領(lǐng)域的應(yīng)用越來越廣泛，最近兩年在上行推流方面也有了長足的發(fā)展。掌握好SRT協(xié)議的數(shù)據(jù)包結(jié)構(gòu)能夠幫助我們使用抓包軟件進行故障分析和判斷，從而快速準確地解決實際工作中出現(xiàn)的問題，希望本文能夠給大家?guī)硪恍椭?，也歡迎大家討論和交流。

原文標題：公網(wǎng)傳輸技術(shù)之SRT協(xié)議解析（下）

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。