赞
踩
在了解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
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。