一. SRT协议的介绍：
SRT网络传输协议，全称是(Secure Reliable Transport)安全可靠传输协议。 SRT协议是目前非常受欢迎的低延时的音视频传输协议，它成功解决了复杂的传输时序，丢包重传等问题，同时还拥有低延时传输的特点，所以在网络音视频传输中广泛使用。
二. SRT协议传输原理：
2.1. SRT协议和UDT协议的关系
SRT协议大部分原理是继承UDT协议(UDT协议是加强版的UDP协议，后面说到代码的时候会分析这个协议)，这其中包括加密控制、流量控制、丢包重传等。这使得SRT协议在传输音视频方面，既具有UDP低延时、效率高的特点，还具有高效的数据重传机制。更重要的是，SRT协议还可以传输高吞吐量和高流量的数据，所以它非常适合音视频的网络传输。下面，我们就用两张图来对比SRT协议传输的优势：
图1是SRT协议传输时的场景，图2是UDP协议传输的场景。可以看出，SRT传输音视频协议的时候，编码端的音视频数据和解码端的音视频数据几乎完全一样。而图2的情况，就有些不同了，编码端的音视频数据通过UDP传输到解码端的时候，整个数据很可能完全不一样。这是因为SRT协议具有一系列的丢包数据，数据恢复等机制，所以编码端和解码端的数据几乎保持一致。而用UDP由于它不具备任何的数据恢复机制，所以很可能会出现一系列的丢包或者乱序情况。
2.2. SRT协议的重传机制：
SRT重传协议一般分为两种，一种是FEC前向纠错机制、另外一种是ARQ自动重传请求机制。首先，我们来介绍一下ARQ的协议的工作原理。当Server端成功接收到数据的时候，它会发送ACK应答信号到Client端。若Server端超时没有收到Client的数据，Server端会发送一个NCK应答信号到Client端。此时Client会发送重传数据包到Server。
下图是ARQ的基本框图：
从这张图我们可以看出，Client端发送两个数据包给Server，分别是Data Packet、Data Packet02两个数据包，假设Data Packet成功发送到Server，则Server会发送一个ACK肯定应答信号到Client。而Data Packet02没有成功发送到Server，Server端会发送一个NACK否定应答信号给到Client。此时，Client端就会启动重传机制把丢失的数据包Data Packet02发送给Server。
而FEC是和ARQ完全不同的工作机制，它是一种前向纠错机制。它相当于在音视频数据送到传输通道之前，会按照预先设计的算法进行编码处理，加入一些冗余信息的数据。而Server端会根据相应的冗余算法对其进行解码，并在解码的过程中找到相对应的错误码进行纠错，让其数据量恢复正常。下面这张图是FEC的图解：
从这张图我们可以看出，Client端向Server端发送4个数据包，分别是Data1、Data2、Data3、Data4。而在每个数据包之前都添加FEC冗余数据。假设在传输过程中，Data4数据包在传输过程中出现了丢包情况、Server端会根据设计好的编码算法接收把丢失的数据包给纠错出来。FEC是不需要做任何重传机制，就可以把数据恢复出来。
ARQ和FEC的使用场景：很多人会问什么情况下用ARQ重传，什么情况情况下用FEC前向纠错？这个的话要看使用场景的网络环境如何。比方说：一个通信链路的单次往返时间(RTT)超过600ms，若此时使用ARQ进行重传则会出现网络超级延时。所以，此场景就需要利用FEC前向纠错技术把每个数据包提前进行冗余信息的添加，而Server就可以根据特定的编码技术把错误的信息给纠正。
而假设在一个网络实时传输音视频流的情况下，突然出现网络的抖动和丢包。此时的话，就应该使用ARQ进行丢包重传。因为在网络实时直播的场景下，RTT都是很小的，但是网络带宽有限，所以如果采用FEC前向纠错的话，它会给音视频网络通信带来额外的数据负载。所以，这种场景就适合用ARQ进行重传。下面我们用一个表格来总结一下：
