SRT协议详解四 应用场景

Chapter 3. 实际应用场景

在了解SRT协议的基本原理后，我们可以尝试使用高骏公司的互联网编解码器模拟来进行视频传输，感受一下协议中提到的参数是如何在实际应用中体现的。

3.1. 在公网环境下开启视频传输：Caller & Listener模式

让我们再来简单复习一下Caller和Listener模式建立SRT连接的工作机制。其实直接从字面含义就能够对他们的关系有所认识了，SRT握手模式设置为Caller模式的一端，需要负责“呼叫”预先选定的UDP端口（即向Listener端公网IP的这个UDP端口发送数据包），从而发起一个SRT握手以建立连接；而SRT握手模式设置为Listener的一端，则需要负责“监听”预先选定的UDP端口，时刻准备回应Caller端发来的建立SRT握手请求的数据包。

那么在实际应用时我们应该如何来将Caller + Listener模式的理论付诸实践呢？我们先来假设有这样一个应用场景：

某公司有固定的视频传输任务，需要将视频从广州办事处实时传输到北京总部，由于资源问题，只有北京总部可以提供公网IP以及可用的UDP端口，而办事处只能提供互联网连接。

图3-1 使用互联网将视频从广州实时传输到北京

根据现有的资源条件，我们可以这样设置SRT来建立视频传输连接：

由于北京总部可以提供公网IP（203.0.113.74）以及可用的UDP端口，这里假设防火墙打开的UDP端口号为12345，那么，我们就需要将北京的SRT设备（HDD-461）设置为Listener模式，并监听12345号UDP端口，准备建立SRT连接；相应的，广州的SRT 设备（HDE-650S）需要设置为Caller模式，只需要能够接入互联网即可，它将向北京总部的公网IP 203.0.113.74的UDP端口12345发送控制信息数据包，尝试通过此端口来建立SRT连接。

按照以上描述，我们就可以得到这样一个SRT源设备（HDE-650S）和SRT目标设备（HDD-461）的网络关系图：

图3-2 HDE-650S和HDD-461的网络关系图

那么我们应该如何在编解码器中设置这些SRT参数呢？

首先来看编码器HDE-650S，参考下图HDE-650S的SRT输出设置（编码器的其他参数设置不在此处表现）：
①打开SRT输出，将“Output Enable”设置为“Enable”；
②编码器使用Caller模式，将“Connection Mode”设置为“Caller”；
③“Address”一项填入北京总部提供的公网IP地址“203.0.113.74”；
④“Destination Port”一项填入北京总部提供的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-3 HDE-650S的SRT输出设置

然后我们再来看解码器HDD-461，参考下图HDD-461的输入设置（解码器的其他参数设置不在此处表现）：
①“Input Name”可以填写一个方便识别的任务名称，此处设置为“SRT_Listener”；
②“Input Source”选择“SRT”，设置为SRT模式；
③解码器使用Listener模式，“SRT Mode”设置为“Listener”；
④“Listener Port”一项填入选择的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-4 HDD-461的输入设置

正常情况下，完成上述配置后，编码器和解码器即可顺利完成SRT握手，并开始传输视频流，如下图，图中显示SRT状态为“Connected”，证明SRT连接正常，在解码器HDD-461中可以看到，正在对接收到的视频流进行解码。

图3-5 连接成功后的编解码器状态

3.2. 在公网环境下开启视频传输：Rendezvous模式

我们在上次的文章中说过，Rendezvous模式可以在两端防火墙都没有做端口转发规则时建立SRT连接，从而实现两点之间的视频传输。这时，需要在两端分别设置对方的出口公网IP以及相同的端口号，这样，两台设备将同时向对方的出口公网IP发送控制信息数据包，用来建立SRT连接。

我们继续使用前面的例子来模拟，但是更换一个使用场景：

某公司临时决定从广州办事处将视频信号实时传输到北京总部，来不及申请在防火墙中做端口转发规则，所以两端的设备都没办法通过对方公网IP的某个特定端口来直接找到对方。

这时，就可以使用Rendezvous模式来建立SRT连接，我们需要将北京的SRT设备（HDD-461）设置为Rendezvous模式，并写入广州办事处SRT设备的出口公网IP地址和一个没有被使用的UDP端口号，同时，再将广州的SRT 设备（HDE-650S）也设置为Rendezvous模式，并写入北京总部SRT设备的出口公网IP地址和相同的UDP端口号，这样就可以建立起SRT连接了，我们同样画出一个SRT源设备（HDE-650S）和SRT目标设备（HDD-461）的网络关系图：

图3-6 HDE-650S和HDD-461的网络关系图

按照图中的相互关系，我们继续使用编解码器来设置相应的参数。

首先来看编码器HDE-650S，参考下图HDE-650S的SRT输出设置（编码器的其他参数设置不在此处表现）：
①打开SRT输出，将“Output Enable”设置为“Enable”；
②编码器使用Rendezvous模式，将“Connection Mode”设置为“Rendezvous”；
③“Address”一项填入北京总部解码器HDD-461的出口公网IP地址“203.0.113.74”；
④“Destination Port”一项填入一个没有被使用的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-7 HDE-650S的SRT输出设置

然后我们再来看解码器HDD-461，参考下图HDD-461的输入设置（解码器的其他参数设置不在此处表现）：
①“Input Name”可以填写一个方便识别的任务名称，此处设置为“SRT_Rendezvous”；
②“Input Source”选择“SRT”，设置为SRT模式；
③解码器使用Rendezvous模式，“SRT Mode”设置为“Rendezvous”；
④“Address”一项填入广州办事处编码器HDE-650S的出口公网IP地址“198.51.100.182；
⑤“Listener Port”一项填入选择的UDP端口号“12345”；
⑥“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-8 HDD-461的输入设置

如果一切正常，完成这些配置后，这家公司北京的领导应该就能看到广州办的实时视频了。

3.3. 探讨：Rendezvous模式与防火墙

我们在前面的模拟场景中很轻松就完成了Rendezvous模式下的SRT连接，看似水到渠成，然而实际情况并不是这么简单，在这背后还隐藏着一些网络的相关知识，下面我们就来简单讨论一下SRT使用Rendezvous模式穿过防火墙建立连接的情况，毕竟知其然，也要知其所以然。

当然，网络安全与防火墙是一门很深奥的专业网络知识，我的能力有限，就不跟大家讨论深层次的内容了，这里只针对和SRT相关的知识做简单的分享。

图3-9 负责网络安全的防火墙
（图片来自网络）

首先，我们需要知道，在使用Rendezvous模式时，设备发出的控制信息数据包的源端口与目的端口都是一样的。在之前的例子中，编码器发出的控制信息数据包的源端口为12345，目标端口也是12345，同样的，解码器发出的控制信息数据包的源端口和目标端口也都是12345。换句话说，这“四个”端口号相同是Rendezvous模式穿越防火墙建立SRT连接的必要条件。

因此，在编解码器之间的防火墙就必须确保不转换数据包包头中的端口号。

图3-10 Rendezvous模式下两端使用相同的端口号穿过防火墙建立SRT连接

现在市场上能够见到的防火墙，基本都是能够进行状态检测的状态防火墙（stateful firewall，现在由于这个功能过于普遍，也就不再有人特意提出这个概念了），它能够进行状态数据包检查或状态查看，实现连接追踪（connection tracking）的功能，而Rendezvous模式正是倚靠这个功能来创建一个贯穿两个防火墙的网络通道，并在其中进行数据传输。

防火墙在工作时，会根据正在传输的流量，创建一个连接追踪表（connection tracking table），并保持动态更新。

例如在上图中，在防火墙A中的连接追踪表会记录下源设备HDE-650S的内网IP和端口号、NAT转换后的公网IP和端口号、以及访问的目标设备HDD-461防火墙的公网IP和端口，如下表：

这时，当对端发来数据包时，防火墙A的连接追踪表还会记录下另一条反向入站信息，如下表：

当反向的数据包到达防火墙A时，发送数据与接收数据相同的端口号会对防火墙A产生“欺骗”效果，让它认为收到的入站数据是对出站数据的回复消息，从而允许数据包通过防火墙，一直到这个传输会话断开，SRT连接也就这样建立起来了。

在大多数非专业场景中，我们用的网络设备都是使用PAT（NAT重载）进行公网IP到局域网IP的地址转换（如家用路由器等），这时，网络设备在转换地址时都会改变源端口号，所以Rendezvous模式大多无法使用，不如直接用路由器做静态端口映射规则来的方便，这样就可以在这端使用Listener的模式，监听映射的端口，另一端使用Caller模式建立连接；相比之下，Rendezvous模式反而是很少被用到。

原文链接：https://blog.csdn.net/weixin_42228920/article/details/90946259