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

引 言

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

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

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

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

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

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

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

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

總的來說，SRT協(xié)議中包含兩類數(shù)據(jù)包：信息數(shù)據(jù)包（Data Packet）和控制數(shù)據(jù)包（Control Packet），他們通過SRT首部的最高位（標(biāo)志位）來區(qū)分，0代表信息數(shù)據(jù)包，1代表控制數(shù)據(jù)包。控制數(shù)據(jù)包又包含了握手（Handshake）、肯定應(yīng)答（ACK）、否定應(yīng)答（NAK）、對(duì)肯定應(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é)，最高位為標(biāo)志位，SRT信息數(shù)據(jù)包首部包含四個(gè)區(qū)域：數(shù)據(jù)包序列號(hào)、報(bào)文序號(hào)、時(shí)間戳、目的地端套接字ID。

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

報(bào)文序號(hào)：報(bào)文序號(hào)獨(dú)立計(jì)數(shù)，在它之前設(shè)置了四個(gè)標(biāo)志位（見圖2）。

時(shí)間戳：以連接建立時(shí)間點(diǎn)（StartTime）為基準(zhǔn)的相對(duì)時(shí)間戳，單位為微秒。

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

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

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

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

圖3 HSv5握手?jǐn)?shù)據(jù)包

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

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

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

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

表1 錯(cuò)誤碼和錯(cuò)誤類型對(duì)應(yīng)表1

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

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

3.握手請(qǐng)求擴(kuò)展模塊（HSREG）中比較重要的字段如下：

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

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

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

4.加密擴(kuò)展模塊KMREQ和配置擴(kuò)展模塊CONFIG

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

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

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

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

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

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

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

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

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

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

鏈路帶寬估值：對(duì)本次鏈路帶寬的估算值。

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

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

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

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

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

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

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

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

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

圖7 連接保持?jǐn)?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ù)包的詳細(xì)信息。隨著廣電行業(yè)IP化的不斷推進(jìn)，Wireshark的使用也越來越頻繁，其重要性可類比于波形監(jiān)視器對(duì)于SDI信號(hào)的作用，以及碼流分析儀對(duì)于TS流信號(hào)的作用。

下面列舉了兩個(gè)利用Wireshark軟件進(jìn)行鏈路分析的例子：

3.1場(chǎng)景一 連接失敗

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

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

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

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

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

圖9 場(chǎng)景一：通過抓包分析找出故障原因

3.2場(chǎng)景二 獲取鏈路信息

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

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

圖10 場(chǎng)景二：RTT估值和RTT估值的變化量

總 結(jié)

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

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

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