ZLmediakit的SRT服务

SRT是一种UDP传输TS的支持丢包重传的低延时传输协议；

以流媒体服务ZLM为例，先分析它的SRT服务（listener端接收客户端的推流或者拉流请求），也就是接收其他客户端的SRT推流，和接收其他播放器的SRT拉流

1、ffmepg推流给ZLM协议阶段抓包分析

ffmpeg作为SRT caller，ZLM作为SRT Listerer;

• 通过抓包看到，传输直接使用UDP协议，内容是UDT协议，一种支持数据包重传的协议；没有TCP三次握手；图片中的Flow Window 是发送端的拥塞窗口大小；
• 首部的最高位表示：数据包还是控制包，从图中看是控制包；控制数据包又包含了握手（Handshake）、肯定应答（ACK）、否定应答（NAK）、对肯定应答的应答（ACKACK），保持连接（Keepalive）、关闭连接（Shutdown）等多种类型；

应答版本号V5，客户端又重新握手一次

 

 

 

• SRT套接字ID：该字段需要和SRT首部中的目的地端套接字ID加以区分，该字段只作用于握手阶段，而目的地端套接字ID作用于数据传输全过程。ID=125 是0x7D 
• 同步cookie：(SYN COOKIE)在“呼叫-监听”模式下，出于防止DoS攻击的目的，只由监听方生成同步cookie，该cookie由监听方的主机、端口和当前时间生成，精确度为1分钟。

数据包传输

 传输的数据是TS数据，但是并不是188字节传一次，一次会传输多个TS包即188的整数倍；如下数据包中的数据部分1316字节，看内容0x47是TS(PES)的起始字节；

 在数据包发送过程中会有应答数据包

 抓包中的数字含义

 肯定应答的应答即ACKACK；抓包显示ACK2；用来计算链路的往返时延（RTT）

 

NAK数据包结构

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

这里由于抓包中没有出现，就不提供了

 保持链接和关闭连接，字段格式

 2 、Listener端代码分析

创建一个UDP服务器，监听端口9000；接收到socket链接之后创建SRTsession；session就是服务端要创建的对象

 srtTransportimp里边判断数据包类型，进行分类处理

 创建新的socket，UDPserver启动时候创建SRTsession；数据传输过来先给srtsession （SrtSession::onRecv）再给srtTransport（_transport->inputSockData）

 在新创建的socket里传输信息之后经过transport

 对应函数执行

transport里的这些函数去做对应的处理，包括回复XML消息；UDP消息；比如ACK，NAK，keeplive

 数据过来要经过一下链路统计；

 处理数据的时候先走加解密，链路估计；然后处理数据

 这个recv_buf的输入是送到packetQueue里处理的，就是发送方和接收方都有的缓冲队列；用于检测不连续之后重传

 然后就是根据缓冲计算逻辑，推出前边的数据，送到ZLM原本的逻辑中转封装