嵌入式流媒体SRT协议：Packet Structure

SRT协议介绍：

SRT(Secure Reliable Transport Protocol)基于UDP数据传输协议派生出的SRT协议，是一个用户级协议，它保留了大部分核心概念和机制，同时引入了一些改进和增强，包括控制包的修改、改进的流控制以处理实时流媒体、增强的拥塞控制，以及加密数据包的机制。

他的源码仓库：

https://github.com/Haivision/srt

SRT是一种传输协议，它能够实现数据在不可预测的网络（例如互联网）上安全、可靠地传输。虽然SRT可以传输任何类型的数据，但它特别针对音频/视频流进行了优化。

SRT可以应用于视频流工作流程中的贡献和分发端点，以在任何时候提供最佳可能的质量和最低的延迟视频。当数据包从源设备流式传输到目标设备时，SRT会检测并适应两个端点之间的实时网络条件。SRT有助于补偿由于网络拥塞在嘈杂网络上引起的抖动和带宽波动。它的错误恢复机制最小化了互联网连接中典型的数据包丢失。而且，SRT支持AES加密，以实现端到端的安全性。

SRT起源于基于UDP的数据传输（UDT）协议。虽然UDT旨在实现公共网络上的高吞吐量文件传输，但它在直播视频方面表现不佳。SRT是一个显著修改过的版本，支持直播视频流。在基于IP的网络上进行低延迟视频传输通常采用MPEG-TS单播或多播流，使用UDP协议。这种解决方案非常适合受保护的网络，任何数据包丢失都可以通过启用前向纠错（FEC）来减轻。实现不同城市、国家甚至大洲之间的低延迟同样具有挑战性。虽然使用卫星链路或专用MPLS网络是可能的，但这些是昂贵的解决方案。使用更便宜的公共互联网连接虽然成本较低，但为了实现必要的数据包丢失恢复，需要显著增加带宽开销。尽管UDT并非为直播设计，其数据包丢失恢复机制提供了一个有趣的起点。SRT的原始版本包括了新的数据包重传功能，能够立即对数据包丢失做出反应，以实现直播流。为了实现低延迟流，SRT必须解决时序问题。通过公共互联网传输的源网络流的特性会完全改变，这引入了延迟、抖动和数据包丢失。这反过来又会导致解码问题，因为音频和视频解码器没有在预期的时间收到数据包。使用大缓冲区有所帮助，但会增加延迟。

SRT包含了一种机制，能够在接收端重现信号特性，极大地减少了缓冲的需求。这个功能是SRT协议本身的一部分，因此一旦数据通过接收端的SRT连接输出，流特性就已经被正确地恢复了。

最初由Haivision Systems Inc.开发，SRT协议于2017年4月与Wowza Media Systems Inc.合作以开源形式发布。开源SRT在MPL-2.0许可下分发，选择这个许可是因为它在推动开源SRT的采用和鼓励采用者社区通过贡献来改进它之间取得了平衡。任何第三方都可以自由地在更大的作品中使用SRT源代码，无论这个更大的作品是如何编译的。如果他们对源代码进行了更改，他们将有义务将这些更改提供给社区。2017年5月，Haivision和Wowza成立了SRT联盟（www.srtalliance.org），这是一个致力于该协议持续开发和采用的联盟。

Adaptation of UDT4 to SRT( 将 UDT4 适配到 SRT):

UDT ( UDP-based Data Transfer ， 即基于UDP的数据传输协议。UDT是一种专为高带宽长距离传输而设计的协议，它的全称是UDP-based Data Transfer Protocol，也称为UDT4 ) 是一种自动重传请求 (ARQ，Automatic Repeat reQuest) 协议。它实现了ARQ的第三代技术，即选择性重传 (Selective Repeat)。UDT的第4版 (UDT4) 实现被作为“信息性”提议提交给了IETF，但最终只停留在草案阶段 (草案编号为 draft-gg-udt-03)。

UDT 旨在最大化利用带宽，因此应用程序必须确保在需要发送数据时输入缓冲区始终可用。当以合理的比特率发送实时视频时，数据包生成的速度相比读取文件要慢。缓冲区的耗尽会导致 UDT 传输算法的一些重置。此外，当发生拥塞时，发送方算法可能会阻塞 UDT API，优先传输丢失列表中的数据包，这样新的视频帧就无法被处理。由于实时视频不能暂停，因此应用程序会丢弃数据包（因为传输 API 被阻塞）。与 UDT 不同，SRT 会在实时数据包和重传数据包之间共享可用带宽，优先丢弃或放弃较旧的数据包而不是较新的 。

SRT 的初始开发涉及对 UDT 第4版进行了一些更改和添加，主要包括以下内容：

• 1、 以字节为单位的统计计数器

• 2、 以毫秒为单位的缓冲区大小来控制延迟（以时间单位测量缓冲区大小更容易配置延迟，并且与流的比特率无关 ，换句话说， 采用时间单位（毫秒）来定义缓冲区的大小，而不是数据量（如字节），在控制延迟时更为方便。这样做的好处在于，它使得延迟的配置与流的比特率（即数据传输速度）无关，从而简化了配置过程。这意味着无论数据流的比特率如何变化，延迟配置都可以通过简单地调整以毫秒为单位的缓冲区大小来实现，而无需考虑比特率对缓冲区大小的直接影响 。

• 3、 ACK消息中的统计信息（接收速率和估算的链路容量）

• 4、 控制包的时间戳（这一点在 UDT 草案中有提到，但在 UDT4 的实现中没有）

• 5、 时间戳漂移校正算法

• 6、 周期性的NAK报告（UDT4禁用了这一草案中的功能，转而采用超时重传未确认的数据包，但这种方法会消耗过多的带宽，不适合实时流媒体应用),NAK 是 "Negative Acknowledgment" 的缩写，意思是“否定确认”或“负确认”。在网络通信中，当接收方检测到数据包丢失或错误时，会发送 NAK 消息通知发送方数据未正确接收，需要重新发送相应的数据包。与 ACK 相对应，ACK 表示数据包成功接收，而 NAK 表示接收失败，需要重传。

• 7、 基于时间戳的数据包传递（配置的延迟）

• 8、 SRT 握手基于 UDT 用户自定义控制包，用于交换对等方的配置和实现信息，以确保在协议演进过程中实现无缝升级，并保持向后兼容性

• 9、 基于配置值或测量输入速率的最大输出速率

• 10、 加密 :

  1、从密码短语生成密钥材料 
          
  2、使用 UDT 用户自定义控制包交换密钥材料和解密状态（发送方能够知道接收方是否可以正确解密流） 
          
  3、AES-CTR 加密/解密：重新分配数据头中消息编号的 2 位，用于指定加密使用的密钥（奇数/偶数/无）；类似于 DVB 的加扰控制字段”；AES-CTR 是指 Advanced Encryption Standard - Counter Mode，即高级加密标准的计数器模式。AES 是一种对称加密算法，而 CTR 模式是一种加密模式，它将一个计数器与明文块一起加密以生成密文。CTR 模式具有并行处理的优点，因此在需要高效加密的大数据流传输中经常使用。在这种模式下，加密和解密过程都是通过计数器逐步增加进行的，从而提供高效的流加密 。
         
  4、 确保在CTR（计数器模式）耗尽后平稳地重新生成密钥

SRT 的早期开发是在内部网络上使用硬件编码器和解码器（来自 Haivision 的 Makito X 系列）进行的，其中使用 netem 工具模拟了随机分布的数据包丢失。

在中度数据包丢失的情况下，解码器出现了缓冲区耗尽的情况（没有数据包可解码）。丢失的数据包未能及时重传。对此的解决方法是更早地触发未确认数据包的重传（即 ARQ 的自动重传）。然而，这导致了带宽使用的激增。超时重传发生在数据包未能足够快地得到确认时。在 UDT4 中，只有在丢失列表为空时才会进行重传。

重传所有超过确认时限的数据包（即发送时间超过 RTT 毫秒的包，RTT 是指 Round-Trip Time，即“往返时间”或“回程时间”。RTT 是网络通信中的一个重要指标，它表示从发送方发送数据包到接收方并收到接收方返回的确认（ACK）所经历的总时间。RTT 通常用毫秒 (ms) 作为单位，反映了网络延迟的程度。在数据传输过程中，RTT 越短，表示网络越快，延迟越低 ）解决了测试场景中的问题，因为在这种情况下没有发生拥塞，并且随机数据包丢失会影响不同的数据包。经过多次重传后，所有数据包最终都会被传递，接收方的队列得以解除阻塞。这是以带宽使用量巨大的代价实现的，因为当时没有发送速率控制。

Packet Structure:

SRT 保留了 UDT 的 UDP 数据包结构，但进行了某些修改。有关更多详细信息，请参考 UDT IETF 互联网草案的第2节（draft-gg-udt-03.txt） 。

Data and Control Packets:

每个承载 SRT 流量的 UDP 数据包都包含一个 SRT 头部（紧接在 UDP 头部之后）。在所有版本中，SRT 头部包含四个主要的 32 位字段 ：

• 1、PH_SEQNO（Packet Header Sequence Number，数据包序列号）：这是数据包的序列号，用于确保数据包的顺序传输。在SRT协议中，数据包是以序列号的方式进行传输的，接收端可以通过序列号检查数据包是否按顺序接收，或者是否有丢失的包。这对于可靠传输至关重要。

• 2、PH_MSGNO（Packet Header Message Number，消息号）：该字段表示消息的编号，SRT会将传输的数据划分为消息(Message)，而一个消息可能由多个数据包组成。消息号可以用于标识数据包属于哪个消息，确保接收端能够正确重组数据。

• 3、PH_TIMESTAMP（Packet Header Timestamp，时间戳）：时间戳用于记录数据包的发送时间，接收端可以利用这个时间戳来计算传输延迟，甚至做音视频的同步。在流媒体传输中，时间戳对于延迟优化、抖动缓冲、带宽控制等非常重要。

• 4、PH_ID（Packet Header ID，标识符）：这是数据包的标识符，通常用于区分不同类型的包（如数据包、控制包等）。PH_ID 可以帮助接收端识别不同类型的数据，并决定如何处理这些数据。

SRT 有两种类型的包，其中数据包头中的 PH_SEQNO 字段的第一位区分数据包（0）和控制包（1）。例如，下面是一个 SRT 数据包头的表示（其中“包类型”位 = 0）：

注意：在 SRT 版本 1.3.0 中引入了数据包结构的变更。为了促进与早期版本的兼容性，这里同时展示了旧的和新的数据包结构。本文件中的数据包图是按网络位序（大端）排列的 。

1、FF = （2位）消息中数据包的位置，其中：

● 10b = 1st：表示这是消息的第一个数据包。

● 00b = middle：表示这是消息中间的某个数据包。

● 01b = last：表示这是消息的最后一个数据包。

● 11b = single：表示这是单个数据包，即该消息只有这一个数据包

2、 O = （1位）指示消息是否应该按顺序传递：1表示按顺序传递，0表示不按顺序传递。在文件/消息模式下（即原始 UDT 使用 UDT_DGRAM 时），如果该位为0，则允许后发送的消息（但在较早的消息由于数据包丢失可能尚未完成时被重组）可以立即传递，而不必等待较早的消息完成。在实时模式下不使用此功能，因为当 TSBPD 模式开启时，数据提取使用的是完全不同的功能 。(UDT_DGRAM 是指 UDT 协议的数据报模式。在这种模式下，数据被视为独立的消息（或数据报），每个消息是一个独立的实体，具有明确的边界。这与流模式不同，后者将数据作为连续的字节流传输 . 在数据报模式下，数据包可以单独处理，即使有部分数据包丢失，接收方也可以处理已经接收到的消息，不需要等待整个消息序列完成。这使得 UDT_DGRAM 模式特别适合对传输延迟敏感的应用，尽管它在处理数据包丢失时的可靠性可能较低。)

TSBPD（ Time Stamped-Based Packet Delivery ,基于时间戳的数据包传递） 是一种用于实时数据传输的机制，通常与 UDT 协议的直播模式（Live mode）一起使用。TSBPD 的设计目标是确保接收到的媒体数据能够按发送的时间顺序重现，即使网络出现抖动（jitter）或时序问题，也可以保持传输的平滑和有序。

TSBPD 的关键功能包括：

● 基于时间戳的排序：每个数据包在发送时都会附带一个时间戳，接收方根据时间戳来排序和重新组装数据包，以确保数据能够按照原始发送顺序进行播放或处理。

● 缓冲和重排序：TSBPD 模式下，接收方会有一个缓冲区，用来存储暂时失序的数据包，然后根据时间戳进行重排序。这对于视频流或音频流等实时应用非常重要，能有效减少由于网络波动导致的播放不连贯现象。

● 与实时流传输的集成：在实时传输（Live mode）中，TSBPD 确保即使在网络状况不理想的情况下，数据流也能以尽可能平滑的方式进行传输和播放。

3、KK = （2位）指示数据是否加密：

● 00b：未加密

● 01b：使用偶数密钥加密

● 10b：使用奇数密钥加密

4、 R = （1位）重传数据包。当数据包第一次传输时，该标志位清除（0）；如果数据包被重传，则该标志位设置为（1）

在数据包中，第三个和第四个字段的解释如下：

● TIMESTAMP：通常表示数据包发送的时间，尽管实际解释可能会根据类型有所不同。

● ID：表示数据包应发送到的目标套接字ID，但当数据包是连接请求时，该字段可能具有特殊值0。数据包的更多详细信息将在本文档的后续部分讨论 。

SRT 控制包的包头（“包类型”位 = 1）具有以下结构（不显示 UDP 包头）：

对于控制包，前两个字段分别按以下方式解释（使用网络位序）：

1、字 0：

● 第 0 位：包类型（设置为 1 表示控制包）

● 第 1-15 位：消息类型

● 第 16-31 位：消息扩展类型

扩展消息机制理论上是开放的，以便进行进一步的扩展。SRT 使用其中的一些扩展来实现其自身的功能。这将在后面的 SRT 扩展握手部分中提到。
2、字 1：

● 附加信息——在某些控制消息中用作额外的数据空间。其解释取决于具体的消息类型。握手消息不使用该字段。