![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014202545.jpg)
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014244239.jpg)
大家好,我是Twitch的视频工程师,今晚我的演讲主题是SRT协议的内幕。在过去,我看过许多关于支持SRT功能的软解的精彩演讲以及它的各种潜能。但是今天,我将掀开幕布,看看SRT协议背后的东西。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014245987.jpg)
此SRT(Secure Reliable Transport)非彼SRT(SubRip Subtitle:它是一种字幕格式),这个视频传输协议可以在具有挑战性的网络之下进行直播。它基于UDP的单播(一对一的形式),注重contribution而不是delivery。此外,它也带来亚秒可调的constant latency。
这么说吧,可调(tunable)意味着你可以配置协议并调整延迟,可以在数据包的丢失与延迟中做出权衡(trade-off)。一旦开始广播的时候,延迟即被锁定,所以不会因为不同的网络的情况而累积更多的延迟,同时,该系统也提供content encryption。
这么说吧,可调(tunable)意味着你可以配置协议并调整延迟,可以在数据包的丢失与延迟中做出权衡(trade-off)。一旦开始广播的时候,延迟即被锁定,所以不会因为不同的网络的情况而累积更多的延迟,同时,该系统也提供content encryption。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014246256.jpg)
为什么我觉得SRT有趣?我们知道RTMP是公共互联网上直播视频的事实标准;但RTMP已经存在了很长一段时间,其标准在2012年最后一次更新过后就被放弃了。新的Codec标准诸如HEVC或AV1一般都没有RTMP标准支持。退一步来说,即使有人在RTMP中hack了这些Codec的支持,在移动网络上RTMP仍然工作的不大好。
SRT作为RTMP潜在替换技术的一种,最近正获得不错的增长势头。SRT联盟现在有250多名成员,而在最近的一些展会上,似乎每个展位都具有 SRT 联盟成员或 SRT-Ready贴纸。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014248634.jpg)
SRT功能在VLC,Gstreamer和Ffmpeg中基本开箱即用,对于 OBS Studio 等工具则有些patches正在流程中。SRT 的源于一个称为 UDT 的旧协议。UDT在2001年创建,仍然在Source Forge上有网页,但UDT的设计目标是在公共网络上以最短时间传输大型的文件。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014249367.jpg)
UDT开发者向IETF提交过几份草案去描述UDT工作原理。总共有四份草案,最终的IETF草案是在2010年发布的。之后,UDT的主要开发者继续在此协议工作了3年,其实现的最终版本停留在了2013年。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014522978.jpg)
Haivision,一家编码器供应商,采用UDT且将它由file protocol变成一个live video协议。在2013年,他们首次在 IBC大会上使用了UDT,主要是为了演示HEVC的编码器。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014523246.jpg)
过了四年,他们觉得自己的自定义协议可能不是创建interoperable ecosystem的最好方式。因此在2017年,他们开源了SRT。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014525875.jpg)
Haivision 与Wowza 联合创建了SRT联盟,以促进发展及开发SRT。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014526123.jpg)
2018年初,他们发布了SRT的v1.3.0更新版本。这是自最初的开源以来,对protocol最大型的修改。同时,其版权协议改成了MPL(Mozilla public license);重新把文件传输模式加了回来。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014528749.jpg)
在2018年,他们也发布了SRT Technical Overview(SRT技术概述),但实际上更像规范(specification)。该文档共有89页,与此对应的RTMP Spec则是52页。该文档描述了各种细节信息,即使是一些竞争对手也承认SRT规范做得非常不错。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014529387.jpg)
从高层看,SRT使用的一个双向UDP socket,它可以通过同一个socket复用数据和控制流。因为没有使用TCP,SRT自行实现了可靠性、有序性和拥塞控制。SRT使用 selective retransmit的方式处理数据包丢失,另外了基于标准加密原语(standard primitives)(而不是DTLS)构建了其独特的 “unique”加密系统,
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014520524.jpg)
SRT Data Payload支持可分片的有效负载(payload)。在实践中,我仅仅看过它与MPEG transport stream一起使用。整个传输流引入SRT包,每个传输流包都有自己的同步字节和传输流头。我确信这些sync byte 用以对抗丢包以及重新同步。
在1500-byte Ethernet MTU情况下,如果你试图放入188-byte的数据包,会发现并没有足够的空间可以容纳8个TS包,这也是使用7个TS包的原因。与此同时,这也可以给SRT Header留出足够的空间。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014820649.jpg)
上图概述了SRT数据包的布局。初起是UDP header, 还有UDT header,实际上SRT header改自UDT header。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014822375.jpg)
第一bit是0,表示的是数据包,之后是packet sequence number,它是从握手过程中确定的random value开始的,随后每一个packet值都会增加1。该值用于标识数据包、packet acknowledgement和数据包丢失消息。有个message number, message number从0算起,会在我的视频中每增加一条消息时候加一,但看起来没什么用,怎么回事呢?
我们可以看见一个微秒单位的时间戳,这是发送端的运行时间(elapsed time)。在接收端,它将这个packet从SRT的缓冲区中播放到下游的TST MUX RN 视频解码器中。这个实时视频的片段与顺序总会是“1 1 0”。1 1 指的的是独立编号,而消息编号是针对跨多个数据包分段的信息。但在实时视频模式下,我们只需要尽可能多地填充TS,我们称之为standalone message。
Ordering flag下的两个标志是encryption和retransmission flags;如果出现了什么问题,ordering flag可以将其信息无序交付。Encryption flag会提醒你正使用的key,而retransmit flag会告诉你这是否是第一次发送还是一个重复的步骤。Retransmitted packets 通常会保留原始序列号,原始信息号和原始时间戳。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014824636.jpg)
SRT的核心理念是发送方和接收方都同意延迟缓冲时间,并且他们试图在数据包开始流出接收方时同步其内容。目前VLC支持现成的SRT,OBS也有了SRT的patch,发送方所创建的数据包,同时会将其放在延迟缓冲区,因为在网络中,该包到达接收方需要一段时间。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014825100.jpg)
发送方不断生成数据包,接收方最终获得数据包。发送方再不断地生成,接收方也继续接收。如此往复。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014826483.jpg)
这里展示了一个不妙的情况,上图的packet 3已被丢失,到目前为止,没人发现了数据的差错。本来期待packet 3,竟然收取了packet 4,它随即生成negative acknowledgement packet,将packet 4 放入缓冲区,为packet 3 留下一个空位(hole)。
发送方继续分发packet,直到下一个packet送达。突然间sender得到NACK,它发现接受者丢失了packet 3,因为它把之前发送的数据包都保存在了buffer,结果,发送方重新发送数据包3,它继续生成数据包;接收方继续接收数据包。注意,此时发送者的buffer现在已装满了数据包。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014828798.jpg)
Packet 1被吐出,直接被丢掉。接收端终于收取到packet 3,它马上填补之前的空洞(hole),操作恢复正常。接收端buffer最终填满了指定的packet,随后把packet 1给了 TS deuxers 和解码器。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210014829949.jpg)
这是协议概述中Nak的表示图。首先有SRT header,因为它是一个控制包所以1开头,最后是丢失包的列表。
每一个丢失list包含一个或多个条目。每个条目要么是一个single packet,要么是一个范围(range),你可在一条消息内说丢失了packet 5、9以及11直到15的所有包。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015156509.jpg)
除了negative acknowledgment,SRT也有positive acknowledgment。接收器每10毫秒发送一次acknowledgment。每一次收到 ACK,发送者立即确认ACK以响应之前的ACK,你可以据此估算往返时间。如果确认之间的数据速率超过64个数据包,则接收器将发送lightweight acknowledgement。此Ack不会被重新确认,也不包含Ack所接受的元数据类型。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015158270.jpg)
RTT有点不寻常,因为似乎没有办法在不启动新广播的情况下调整延迟缓冲区的大小,所以对于广播场景有些限制。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015159862.jpg)
以上是acknowledgement packet所显示的Ack/AckAck包。最重要的是最后接收到的packet包序列号,当然还有的是往返时间,往返时间的方差,缓冲统计available size和packets,数据包接受速率及数据接收速率。在lightweight Ack,你只需得到序列号,Ack的acknowledgment将会显示它正在确认的Ack,以便于你知道在正确的时间戳做出扣除。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015201370.jpg)
我们都知道握手(handshake)非常简单。在这个GIF中,Bill Maher 不断地误读Snoop Dogg (史努比。狗狗)的手势,Snoop Dogg也不断地尝试配合Bill,这场景是body language misinterpretation的一个例子,我认为它适合隐喻SRT handshake的过程。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015202413.jpg)
SRT在sender和receiver之间有四次handshakes(因为后向兼容,所以所有版本都支持)。V4 和V5的rendezvous handshake (汇合握手)比较特殊,不在这次讲解。
V5 以及v4最大的区别在于数据包交换的数量。v4共有四次往返;在v5只有两次往返。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015204228.jpg)
图中是packets的布局,其核心思想是左边的v4使用了未修改的UDT包加上SRT扩展,接着是一个包含所需延迟和初始序列号的SRT握手包,其后的密钥素材用于对于数据有效载荷进行加密,右边的v5则更将这些信息smush (合拼) 到一个包中(指V5直接修改了原始UDT包的布局)。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015204342.jpg)
之后,我们将看到两方尝试v5握手,发起方创建handshake induction packet (握手感应包)。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015838422.jpg)
其版本号设置为4,但cookie字段并未设置,它将提示初始端在短时间内获得cookie,使得响应端不必处理混乱的数据包,而是需要解析其数据包以将某些内容发送回去;实际上,响应端接收到该包之后,创建一个版本5的induction packet,并设置Cookie。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015840961.jpg)
此时,v4 initiator将忽略v5,并继续填充v4以及重复改cookie。但是,如果initiator是通过v5运行,所以它会在version字段中填写 v5程序,加上SRT handshake extension values包括延迟值等。
Initiator可能在握手的第二个包产生stream ID,首先填充加密握手,然后responder会使用latency value 和cyypto handshake进行响应。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015842933.jpg)
在于Stream ID,这是在handshake的第二个包中所发送的可选标识符,因为第一个包是有可能被抛弃掉的。在此会有个application-specific parameter,用于通知你initiator想干什么。
这与RTMP形成一些对比,在RTMP中,你执行TCP握手和RTMP握手。然后,执行带宽估计之后调用一组RPCs来设置RTMP媒体流。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015844163.jpg)
我之前提到过SRT不使用DTLS。它以自定义方式使用industry standard primitives,可看见它受到到了DVB scrambling的重大影响。DVB是欧洲广播标准,keying material是由共享密码短语生成。随着这些retransmits和密钥旋转,一次有两个密钥有效。你有一个偶数键和一个奇数键,在这两个键中你交替使用哪一个,你就在更新。如果你得到重发,你可以参考旧的密钥。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015846813.jpg)
规范中的小注释说:‘嘿,全数据包加密看起来是最安全的选择,但实际上,加密header在暴力破解时候却有点脆弱。最初的MPEG TS 同步字节,其设计可能是不让你把TS头加密。事实上,我们会尝试使用快速的key rotation来获得更高的加密强度。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015848662.jpg)
你可以使用Wireshark 来分析包,我们会有个加密数据包,有效载荷的第一个字节是12(十六进制)。你可能已知道如果是一个未加密的TS 同步字节,那它将是47(十六进制)。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210015850134.jpg)
如果想进一步了解其中的协议,你可以前往SRT GitHub repository,以及technical overview Wireshark的SRT解析器。
![](http://www.ctiforum.com/uploadfile/2019/1210/20191210020123674.jpg)
如果你想了解更多关于SRT生态系统,或者有关于SRT的产品或信息请前往srtalliance.org。