SRT协议详解二工作原理

2.1. SRT工作原理

要说SRT的工作原理，我们先从其纠错机制说起。

下图描述了在数据包传输过程中，不使用数据纠错，使用FEC（Forward Error Correction）纠错，和使用ARQ（Automatic Repeat request）纠错三种链路传输纠错方式的模式和结果。

如果没有数据纠错，结果自不必说，一旦发生丢包，得到的就是不完整的数据流，如下图。
在这里插入图片描述
图2-1 数据包传输时没有纠错机制
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

如果使用FEC纠错，则会在传输的数据流中加入一定比例的前向纠错数据，当发生丢包时，接收端就可以根据前向纠错数据，恢复丢掉的数据包，如下图。

但是使用FEC就必须面对这样的问题：无论是否产生丢包，前向纠错数据都需要占用一定的传输带宽；而且当丢包率超过前向纠错数据能够恢复的阈值时，FEC将无法恢复丢失的数据包。
在这里插入图片描述
图2-2 数据包传输时使用FEC纠错
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

如果使用ARQ纠错，就需要在发送端和接收端之间建立双向连接。在接收端收到数据包后，会按照数据包的顺序进行排序（传输过程中数据包可能会发生乱序），如果发现其中有丢失的数据包，就会向发送端发出重传请求，由发送端将丢失的数据包重新发送到接收端，从而实现数据包的恢复，如下图。

在这里插入图片描述
图2-3 数据包传输时使用ARQ纠错
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

而我们说的SRT技术，正是使用的ARQ纠错机制，这主要是因为在网络传输时，带宽抖动和丢包通常都是随机发生的，只有在网络出现问题的时候才需要纠错机制的介入，只需要在发生丢包之后让发送端重传丢失的数据包就可以了，这样既保证了传输的质量，同时又能减少无谓地消耗传输带宽；除此之外，SRT会为数据包提供更精准的时间戳，让接收端能够准确校准媒体流的包顺序，保证传输正常。

之前已经说过，SRT协议依靠双向传输的UDP流来保证公网环境下的视频传输质量。除了从SRT源设备到SRT目标设备持续发送视频数据外，在两台设备之间还会持续地交换SRT控制信息，以此来在两台设备之间实现以UDP为底层协议的连接，进行信息交互，确保视频数据能够准确地传输到接收端。

在这里插入图片描述
图2-4 SRT连接中的双向UDP流
＊注：

SRT源设备发送的UDP流包含数据业务流和SRT控制信息；
SRT目标设备接收源设备发来的UDP流，同时回复相应的SRT控制信息。

为了让SRT保持连接状态，必须确保控制信息数据包的发送间隔不超过10ms。每当SRT目标设备收到一个数据包后，都会回复一个“ACK”确认控制信息数据包，告诉SRT源设备已经收到这个数据包了，如果在10ms内收到多个数据包，则只回复一个“ACK”，确认这期间收到的所有数据包；然而，数据包的到达时间间隔难免会超过10ms，这时就需要增加“keep alive”控制信息数据包，确保SRT连接不会断开。

在SRT连接中，从目标设备返回源设备的控制信息通道也会占用一定的带宽。在业务数据完全正常传输的情况下（即没有错误信息需要返回到发送端），控制信息占用带宽大约为40Kbps；传输时丢失的数据包越多，目标设备发出的控制信息就越多，信息量会与丢包率线性相关，每丢失1个数据包，大约会消耗400bps的可用带宽。

2.2. SRT握手模式

现在我们已经知道SRT的工作原理了，那么一个SRT连接又是如何建立的呢？要清楚这个问题，我们就不得不了解SRT握手模式：Caller & Listener和Rendezvous。

在讨论建立SRT连接时，我们不需要区分SRT源设备和SRT目标设备，发送端和接收端都可以发起建立SRT连接，我们只要知道哪端的设备满足设置相应模式的网络需求即可。

2.2.1. Caller模式

✦ 功能：
设置Caller模式的设备将作为SRT会话的发起者，它必须知道对应设置Listener模式的设备的公网IP地址及其监听的UDP端口。

✦ 使用场景：
①让一台设备发起建立一个点对点传输的SRT连接；
②设备所在的网络有防火墙，但没有防火墙操作权限；
③设备的IP地址是DHCP动态获取的；
④设备没有固定的公网IP地址。

2.2.2. Listener模式

✦ 功能：
设置Listener模式的设备会监听发起SRT会话的请求，它需要知道应该使用的UDP端口（如网络管理员分配给SRT传输使用的UDP端口），并一直在这个端口上监听发起SRT会话的请求。

✦ 使用场景：
①让一台设备监听发起SRT会话的请求；
②设备所在的网络有防火墙，并且可以控制防火墙，打开需要的UDP端口；
③设备直接暴露在公网环境下。

2.2.3. Rendezvous模式

✦ 功能：
两台设置Rendezvous模式的设备会共同协商，通过相同的UDP端口号建立一个SRT会话。

✦ 使用场景：
①两台设备所在的网络都有防火墙，但是没有防火墙的操作权限，如果防火墙设置了适当的工作模式（将在Chapter 3.实际应用场景中详细介绍），可通过此模式建立SRT会话。

一旦完成SRT连接的建立，SRT源设备和SRT目标设备便开始交换控制信息，如网络状况信息、丢失的数据包等等，无论设备设置的是Caller、Listener还是Rendezvous模式都无关紧要了，直接利用建立起来的SRT通道去传输数据就可以了。

2.3. SRT如何建立连接

那么这三种握手模式实际又是如何把SRT会话建立起来的呢，下面我们通过简单的图示来了解这个过程。

2.3.1. 由SRT源设备发起建立SRT连接

如下图，将编码器HDE-650S设置为Caller模式，解码器HDD-461设置为Listener模式，编码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当解码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。
在这里插入图片描述
2.3.2. 由SRT目标设备发起建立SRT连接
如下图，将编码器HDE-650S设置为Listener模式，解码器HDD-461设置为Caller模式，解码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当编码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。

在这里插入图片描述
2.3.3. 使用Rendezvous模式建立SRT连接

如下图，SRT源设备和SRT目标设备同时设置为Rendezvous模式，两台设备一起向对方发送控制信息数据包，一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输。
在这里插入图片描述
2.4. SRT与防火墙

在实际使用场景中，特别是在通过互联网进行数据传输时，终端设备通常都会经过防火墙再连接到互联网，SRT流就必须穿过防火墙进行传输。这种情况下，我们就需要网络管理员来帮忙对防火墙进行适当的配置，尤其像网络地址转换（NAT）和数据包过滤的设置，防火墙的配置情况将会决定设备使用哪一种握手模式。
下图中，一台编码器尝试通过互联网将视频流发送给解码器，两台设备都在防火墙后。我们不妨假设编码器使用Caller模式，解码器使用Listener模式，为了使它们握手成功，并建立SRT会话，就必须满足下列条件：
① 解码器端的防火墙需要允许某个供SRT使用的UDP端口可以从互联网接入；
② 编码器必须知道解码器端防火墙的公网IP和开放的UDP端口；
③ 两端的防火墙都要允许双向UDP传输；
④ 两端的防火墙都要配置端口转发，允许编码器和解码器之间的数据流传输；
⑤ 两端的防火墙都要关闭数据包过滤功能，允许编码器和解码器之间的交互数据包通过。
在这里插入图片描述
图2-9 经过防火墙进行视频传输
转载至：
https://blog.csdn.net/weixin_42228920/article/details/90946259?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-8&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-8