SRT(Secure Reliable Transport)是一种开源的网络传输协议,专为实时音视频数据传输设计,具有低延迟、高可靠性和安全性等特点。
核心功能
SRT协议旨在解决实时音视频传输中的网络抖动、丢包、延迟和安全问题,提供以下核心功能:
低延迟
- 基于UDP传输,避免了TCP的握手和慢启动等机制导致的高延迟问题。
- 使用了基于UDP的可靠性机制(ARQ,Automatic Repeat Request)来实现可靠的包传输,同时保持低延迟。
高可靠性
- 包重传:SRT协议会检测丢包并触发重传机制,确保所有数据包最终传输到目标。
- 网络抖动缓冲区(Jitter Buffer):用于吸收网络延迟的抖动,保证播放流的平滑性。
- FEC(Forward Error Correction,前向纠错):在部分丢包情况下,接收端可通过冗余数据恢复原始数据。
安全性
- 支持AES(Advanced Encryption Standard)加密,确保数据在传输过程中的安全性。
技术特点
基于UDP的传输协议
- SRT利用UDP提供快速的数据传输能力,同时结合其自定义的控制机制(如握手、丢包重传)实现高可靠性。
时钟同步
动态链路调整
- 根据网络状况(如丢包率、延迟、带宽)动态调整传输速率,适应复杂网络环境。
拥塞控制
- 类似于TCP的拥塞控制机制,但更优化于实时流传输。
工作流程
建立连接
- 双方通过握手(Handshake)建立连接,类似于TCP三次握手。
- 支持多种握手模式,包括主叫(Caller)、被叫(Listener)和对等模式(Rendezvous)。
数据传输
- 数据以UDP包的形式传输,传输过程中添加SRT头部信息(如序列号、时间戳等)。
- 使用ARQ机制检测丢包并进行重传。
链路维护
- 通过定期发送心跳包维持连接。
- 动态调整传输参数以适应网络状况。
连接终止
- 双方完成数据传输后关闭连接。
数据包结构
基本结构
| SRT Header | Payload |
SRT Header(头部)
SRT的头部用于携带控制信息、时间戳、序列号等,是实现可靠性和低延迟传输的关键部分。
数据包头部结构
数据包的头部长度为16字节,具体字段如下:
字节偏移 | 字段名 | 长度(字节) | 描述 |
---|---|---|---|
0-3 | Sequence Number | 4 | 数据包的序列号,用于重排序和丢包检测。 |
4-7 | Packet Timestamp | 4 | 数据包的发送时间戳(相对于连接建立时的时间偏移量)。 |
8-11 | Destination Socket ID | 4 | 目标Socket的唯一标识,用于区分不同的连接。 |
12-15 | Type/Control Info | 4 | 标志位字段,包含数据包类型、丢包请求等信息(详见控制包结构部分)。 |
控制包头部结构
控制包的头部用于携带控制指令,格式为20字节,字段如下:
字节偏移 | 字段名 | 长度(字节) | 描述 |
---|---|---|---|
0-3 | Control Type | 4 | 控制类型标志,例如握手、丢包通知(NAK)、ACK确认等。 |
4-7 | Subtype | 4 | 控制子类型,用于进一步区分具体的控制指令。 |
8-11 | Timestamp | 4 | 发送该控制包时的时间戳。 |
12-15 | Destination Socket ID | 4 | 目标Socket的标识符。 |
16-19 | Additional Info | 4 | 额外的控制信息,例如NAK中指示丢失包的范围。 |
Payload(负载)
负载部分承载实际传输的数据,例如音视频流。其内容没有固定格式,由发送方根据应用需求组织。
- 数据包负载通常是应用层的音视频数据块。
- 控制包负载可能包含额外的控制信息,例如丢包范围、握手参数等。
数据包分类
数据包
- 用于传输实际音视频数据。
- 包含数据序列号和时间戳,以确保接收端能够重排序和按时间播放数据。
- 数据包头部固定为16字节,后跟实际数据。
控制包
- 用于维护连接状态和网络可靠性。
- 控制包种类包括:
- 握手(Handshake):用于建立连接和协商参数。
- ACK(Acknowledgement):确认接收到的数据包序列。
- NAK(Negative Acknowledgement):通知发送方哪些数据包丢失需要重传。
- Keep-alive:心跳包,用于维持连接。
- Shutdown:用于关闭连接。
数据包头部内容
假设有一个SRT数据包,头部的16字节内容如下(以十六进制表示):
复制代码
0x00 0x00 0x00 0x05 0x00 0x00 0x1F 0x40 0x12 0x34 0x56 0x78 0x01 0x00 0x00 0x00
解析如下:
- Sequence Number:
0x00000005
(序列号为5)。 - Packet Timestamp:
0x00001F40
(时间戳为8000,即8秒)。 - Destination Socket ID:
0x12345678
(Socket ID为0x12345678)。 - Type/Control Info:
0x01000000
(数据包类型标志)。
控制包的常见类型
以下是部分控制包的类型和用途:
类型代码 | 控制包类型 | 描述 |
---|---|---|
0x0000 | Handshake | 用于连接建立时的握手操作。 |
0x0001 | Keep-alive | 保持连接的心跳包。 |
0x0002 | Acknowledgement | 确认接收的数据包序列号。 |
0x0003 | Negative ACK | 通知发送方丢失的包序列号范围。 |
0x0004 | Shutdown | 表示连接终止的通知包。 |
数据包和控制包的对比
特性 | 数据包 | 控制包 |
---|---|---|
功能 | 传输音视频等实际数据 | 维护连接、可靠性和状态 |
头部长度 | 16字节 | 20字节 |
负载内容 | 实际数据 | 控制信息 |
应用场景
与其他协议对比
特性 | SRT | RTMP | WebRTC |
---|---|---|---|
传输协议 | UDP | TCP | UDP |
延迟 | 低延迟(<1秒) | 较高(>3秒) | 超低延迟(毫秒级) |
可靠性 | 高 | 较低 | 高 |
安全性 | 支持AES加密 | 无原生加密 | 支持SRTP加密 |
复杂性 | 中等 | 简单 | 较高 |
优势与不足
优势
- 低延迟:适合对实时性要求高的场景。
- 高可靠性:即使在网络抖动和丢包严重的情况下,仍能保持较好的传输质量。
- 安全性:内置加密功能,适合敏感数据传输。
不足
- 相比TCP,SRT对网络环境的要求较高,复杂的协议实现增加了开发难度。
- 在极端丢包率下可能会导致更高的延迟。