0 引言

视音频的信号传输技术作为广电领域的重要技术之一，保障了传输的安全和质量。传统的信号传输手段也许可以用三句话来概括：“天上一颗星，地下一根缆，中间面对面的微波”。

“天上一颗星”指的是卫星传输，优点是灵活安全可靠并且对于直播现场的条件没有特殊要求，但其设备投资和费用非常昂贵。“地下一根缆”指的是光纤传输，优点是安全可靠并且延时极低，但它很依赖光缆链路的基础建设，灵活性较差。“中间面对面的微波”最初指的是通视条件下的定向微波，后来又发展出长距离的U波段“大微波”和短距离的2G波段“小微波”。随着5G和互联网技术的飞速发展，通过公共互联网安全可靠的传输视音频信号已经成为一种可能，实际上我们的传输手段又多了一种：“无需面对面的公网传输”。

然而公共互联网中普遍存在着不同程度的丢包、抖动、延时和带宽波动，这就需要一种可靠的传输协议来保证传输链路的可靠性。SRT（Secure Reliable Transport）协议-即安全可靠传输协议，是一种新兴的视音频传输协议，在视音频的点对点实时传输方面有着非常好的应用效果，近年来其在广电领域的发展也呈现出多点开花的趋势，在现场直播、远程制作、远距离传输、上行推流等多方面都有着广泛的应用。

在实际工作中，理解和掌握SRT协议的数据包结构能够帮助我们完成链路架设和调试，本文从SRT协议的工作流程入手，对SRT协议的数据包结构进行解析，之后举例介绍如何利用Wireshark软件进行抓包分析，从而排除链路故障或者获取链路信息。

1 SRT协议工作流程

SRT协议中最常用的工作模式为“呼叫-监听”模式，监听方(Listener)会持续监听本方的固定UDP端口，呼叫方(Caller)通过访问监听方的公网IP地址和该固定端口来建立SRT连接。呼叫和监听的角色主要在SRT协议握手阶段起作用，无论是编码端还是解码端都可以担任呼叫者或监听者的角色。

图1表示了SRT协议的工作流程，整个流程包括握手、参数交换、数据传输、连接关闭等步骤。另外在传输有效数据时，双方会发送控制数据来完成丢包恢复、连接保持等功能。

图1 SRT协议工作流程

2 SRT数据包结构

SRT协议根据UDT协议(UDP-based Data Transfer Protocol)改进而来，已经在2020年3月10日向IETF提交了RFC草案，这也表示SRT协议进入了比较稳定的发展轨道。

进入2021年之后，SRT协议在上行推流方面有了迅速的发展，很多主流平台和公司都支持使用SRT协议来代替RTMP协议进行上行推流，其中的关键点就是SRT的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)。这里重点介绍前三个区域：

1.所有SRT控制数据包的首部是基本相同的，均包含四个区域：控制类型和保留区域、附加信息、时间戳、目的地端套接字，其中控制类型字端为0代表握手数据包。

2.握手控制信息区域(cif.hsv5)中比较重要的字段如下：

ISN：随机生成的数据包初始序列号，之后所有的信息数据包以此为基准计数。
握手类型：该字段第一个作用是表示该握手数据包所处的握手阶段（以“呼叫-监听”模式为例，其握手分为诱导阶段Induction和结尾阶段Conclusion），第二个作用对于用户来说更为重要，在握手失败后“握手类型”字段会显示相应的错误码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的AES123/AES192/AES256加密功能的实现。而配置扩展模块(CONFIG)包含了四种：SRT_CMD_SID、SRT_CMD_CONGESTION、SRT_CMD_FILTER、SRT_CMD_GROUP，其中SRT_CMD_SID扩展模块就是负责SRT上行推流中不可或缺的StreamID功能，有兴趣的朋友可以自行抓包查看。

图3 HSv5握手数据包

2.3 ACK数据包结构

ACK数据包是由SRT接收端反馈给发送端的肯定应答，发送端收到ACK后便会认为相应数据包已经成功送达。ACK数据包中还包含了接收端估算的链路数据，可以作为发送端拥塞控制的参考。ACK数据包结构见图4，其中几个比较重要的字段如下：

控制类型：该字段等于2便表示ACK数据包。
附加信息：其中包含了独立计数的ACK序列号，该序列号主要用于ACK包和ACKACK包的一一对应。
最近一个已接收数据包的序列号+1：该字段的值等于最近一个已收到的信息数据包的序列号加1，例如ACK包中该字段为6，便表示前5个数据包均已收到，发送端可以将它们从缓冲区中踢出。需要注意本字段是和数据包序列号有关，与ACK序列号无关。
往返时延RTT估值：通过ACK数据包和ACKACK数据包估算出的链路往返时延。
往返时延RTT估值的变化量：该变化量能够衡量RTT的波动程度，数值越大表示链路RTT越不稳定。
接收端可用缓冲数据：表示目前接收端缓冲区有多少缓冲数据可供解码，该数值越大越好，其最大值由延时量参数(Latency)决定。
链路带宽估值：对本次链路带宽的估算值。
接收速率估值：接收端下行网络带宽的估算值。

图4 ACK控制数据包

2.4 NAK数据包结构

当SRT接收端发现收到的数据包序列号不连续时，便会判断有数据包丢失，并立刻向发送方回复否定应答(NAK)数据包。此外SRT接收端还会以一定间隔发送周期NAK报告，其中包括了间隔期的所有丢失包序列号，这种重复发送NAK的机制主要为了防止NAK数据包在反向传输中丢失。NAK数据包结构见图5，其控制类型字段等于3，包内含有丢失数据包的序列号列表。

图5 NAK控制数据包

3 Wireshark抓包分析

Wireshark是被互联网业界广泛使用的开源数据包分析软件，它可以截取各类网络数据包，并显示数据包的详细信息。随着广电行业IP化的不断推进，Wireshark的使用也越来越频繁，其重要性可类比于波形监视器对于SDI信号的作用，以及码流分析仪对于TS流信号的作用。

下面列举了两个利用Wireshark软件进行链路分析的例子：

3.1 场景一连接失败

在SRT链路的搭建过程中，难免会遇到连接失败的情况，其原因是多种多样的，这时我们便可以利用Wireshark的抓包分析功能来判断错误的类型。

图6是连接失败后的抓包数据，抓包视频可参见视频一。首先可以观察到双方在不停的交换握手数据包，说明握手没有成功，但另一方面也说明IP地址和端口号是设置正确的，双方能够正常通信。

在双方SRT版本都高于1.3的情况下，SRT握手过程需要两次往返，既有四个握手数据包，并且第一个握手数据包一定是HSv4版本握手数据包，由此我们可以定位出第一个握手数据包。接着观察到第四个握手数据包的“握手类型”字段是1002，含义是“对端拒绝”，这表示双方可能在某个参数上不匹配而导致了握手失败。

我们接着查看第二个握手包，这是监听方发给呼叫方的响应，参考图3，其中“加密标志位”数值为2，表示监听方要求对端使用AES-128的方式加密。再查看第三个握手包，这是呼叫方发给监听方的，其中“扩展标志位”数值为1，表示该握手包之后并没有附带加密扩展模块。

经过以上的分析，我们可以得知这次连接失败是因为监听方要求对端以AES-128的方式响应加密要求，而呼叫方并没有做出加密的响应。如果要成功连接我们就需要获知监听方的加密密码，并在呼叫方选择AES-128的加密方式。该场景的具体操作视频5可参见参考文献5。

图6 场景一：通过抓包分析找出故障原因

【点击观看演示视频】

3.2 场景二获取链路信息

互联网链路中单次往返时延(RTT-Round Trip Time)表示了数据在发送端和接收端之间往返一次花费的时间。链路的RTT值以及RTT的波动程度决定了SRT链路延时量参数的设置，但实际工作中由于防火墙等原因往往难以直接获得RTT值，这时我们可以通过Wireshark软件对ACK数据包进行分析来获得相应信息。

通过图7可以看到，链路的RTT是20.61毫秒，而RTT的变化量是9.786毫秒，这也说明了该条链路的RTT并不稳定，而RTT波动意味着丢包重传需要的时间也会随之波动，从而带来整条SRT链路差错控制能力的波动，这也意味着我们必须依照该条链路的特性进行参数调整。