|SRT协议在电视直播中的应用( 四 )
MTU字段:最大数据包长度 。
FC字段:滑动窗口的大小 。
握手类型字段:在连接成功的时候意义不大 , 但是在连接失败的时候会给出错误码 , 告诉我们为什么失败 , 图左下角是错误码对照表 。
同步cookie字段:由listener的主机、端口和当前时间生成 , 精度1分钟 。
握手请求和握手响应拓展模块是比较重要的扩展模块 , 其字段含义如下:
SRT版本:可以是1.3、1.4或者更老的版本 。
SRT标志位:8个标志位实现了SRT的不同模式和功能 。
发送方向延时和接收方向延时:SRT协议1.3版本实现了双向传输功能 , 双向传输可以分别设定不同方向的延时量 。 对于常规的单向传输 , 假设A向B发送数据 , 该方向的延时量Latency应该是A的发送方向延时(PeerLatency)和B的接收方向延时(RecLatency)的最大值 , 该延时量在握手阶段就已由双方协商确定 。
2.7.3 ACK包
本文插图
ACK数据包最初是为了返回肯定应答 , 但SRT中添加了许多链路信息和对链路的预测 。 这里控制类型为2便表示ACK包 。
附加信息字段:包含有单独的ACK序列号 , 用于让ACK包和ACKACK包一一对应 , 从而计算出RTT(链路往返时延) 。
最近一个已接收数据包的序列号+1:如该字段为6 , 便表示前5个包都已收到 。
RTT估值字段:SRT会估算RTT 。
RTT变化量:SRT会对一段RTT进行统计 , 估算出RTT估值的变化量 , 这个变化量也显示了RTT的波动程度 , 一个良好链路的RTT一般相对稳定 。
接收端的可用缓冲数据:接收端缓冲区中可用的数据越大越好 。
ACK数据包还会对链路带宽和接收端的下行带宽进行估算 。
ACK里的链路数据非常丰富 , 对于使用者和开发者来说都是非常好的 。 使用者可以通过此获得很多有用的信息 , 开发者可以依此做一些拥塞控制 。
2.7.4 NAK包
本文插图
控制类型为3代表NAK数据包 。 NAK包中的丢失列表有两种信息:单个丢包序列号和连续丢包序列号 , 如果是连续丢包 , 就需要列出起始序列号和截至序列号 。
值得注意的一点是 , SRT协议中的NAK都是发两次的 , 一般情况是在丢包时就发送NAK , 但是还会定期重发NAK队列 , 这样做主要是为了防止在反向传输中NAK包丢包的概率 。
2.7.5 实际运用
以上说了那么多枯燥的数据包结构知识 , 主要是为了能在实际工作中运用 。 下面我们使用一个视频来说明怎样判断一个链路的故障 。 当出现链路没联通的情况 , 我们可以使用Wireshark进行抓包分析 。 当发现里面全是握手包之后 , 说明握手没有成功 , 但另外一个方面也说明了IP和端口号设置是正确的 。
在握手中出了问题 , 我们首先要找到第一个握手包 。 在SRT中所有的第一个握手包 , 出于兼容性问题的考虑都是HSv4版本的握手包 。 在找到第一个握手包之后 , 由于是两次往返 , 所以需要往下数第四个握手包 , 可以看到错误类型是1002 , 1002表示对端拒绝 。 当然这个错误码给的是比较含糊的 , 我们还要继续分析 。
在第二个监听方发给呼叫方的握手包里面看到了要求 。 可以看到这里它的加密标志位是02 , 02表示AES-128 , 即要求对方以AES-128方式来加密 。
接下来我们在下一个握手包里看有没有响应 , 也就是看握手包里有没有加密的扩展模块 。 扩展标志位是01 , 01表示只有响应扩展模块 , 没有加密扩展模块 , 也没有配置扩展模块 。
这里其实就破案了 , Listener要求加密 , 但Caller并没有以加密的形式做响应 。 之后我们要做的Caller以AES-128的模式进行加密 , 并且需要知道对方的密码 。 以上是一个非常简单的例子 , 演示了了我们在实际工作中怎样运用数据包结构的知识进行故障分析 。
推荐阅读
- 行业互联网|大华股份与大连量天科技签署战略合作协议
- 中年|宿迁深圳招商再结硕果,签约项目19个,协议总投资158亿元
- 互联网|重磅!广东光大与华为签署战略合作协议
- 行业互联网|西商联合会与三彩家有限公司签约战略合作协议
- 行业互联网,工业互联网|中国联通与青岛四大机构签署工业互联网战略合作协议
- |胖协议概念四年后,学院派公链兴起
- 融资并购|宁波三生签订战略投资协议,投资金额近2亿
- 物联网|广大通与机智云正式签署SD-WAN物联网边缘计算网关战略合作框架协议
- Triller|TikTok对手Triller与印度企业签订协议 在当地推广
- 行业互联网,阿里巴巴|中国银行 、阿里巴巴和蚂蚁集团正式签订全面深化战略合作协议