网站关键词在哪,wordpress cookies,企业官网网站建设,wordpress是服务器吗策略 1#xff0c;10 次
NACK 模块对同一包号的最大请求次数#xff0c;超过这个最大次数限制#xff0c;会把该包号移出 nack_list#xff0c;放弃对该包的重传请求。
策略 2#xff0c;20 毫秒
NACK 模块每隔 20 毫秒批量处理 nack_list#xff0c;获取一批请求包号…策略 110 次
NACK 模块对同一包号的最大请求次数超过这个最大次数限制会把该包号移出 nack_list放弃对该包的重传请求。
策略 220 毫秒
NACK 模块每隔 20 毫秒批量处理 nack_list获取一批请求包号存储到 nack_batch生成 nack 包并发送。
不过nack_list 的处理周期并不是固定的 20ms 而是基于 20ms 动态变化。
策略 3100 毫秒
NACK 模块默认 rtt 时间如果距离上次 nack 发送时间不到一个 rtt 时间那么不会发送 nack 请求。
从发送 nack 请求到接收重传包一般是一个 rtt 的时间也就是说重传包理论上应该在一个 rtt 时间内到来超过这个时间还未到来才会发送 nack 请求。
注意100ms 只是 rtt 的默认值在实际应用中rtt 应该要根据网络状况动态计算计算方式有很多种比如对于接收端来说可以通过发送 xr 包来计算 rtt。
策略 41000 个丢失包数量
nack_list 的最大长度即本次发送的 nack 包至多可以对 1000 个丢失的包进行重传请求。
如果丢失的包数量超过 1000会循环清空 nack_list 中关键帧之前的包直到其长度小于 1000。也就是说放弃对关键帧首包之前的包的重传请求直接而快速的以关键帧首包之后的包号作为重传请求的开始。
策略 510000 个包号跨度
nack_list 中包号的距离不能超过 10000 个包号。即 nack_list 中的包号始终保持 [cur_seq_num - 10000, cur_seq_num] 这样的跨度以保证 nack 请求列表中不会有太老旧的包号。
小结
策略 1 和策略 4 属于 nack 包发送的保护策略这非常关键比如有以下两种场景
场景 1服务器下行分发链路丢包率过高。
这会导致接收端对一些包的重传请求次数过高如果不对 nack 请求次数做限制那么接收端将无限循环发送 nack 请求。
场景 2服务器上行推流链路出现长时间抖动恢复后导致接收端 rtp 包号断层。
假如包号断层达到 1 万那么在抖动恢复的瞬间接收端会将 1 万个包号全部加入到 nack_list 。这会增加服务器生成 nack 包的负担而且生成的 nack 包将达到 2.3KB 大小推流端解析这个包同样也要耗费更多时间。
所以如果没有 1、4 这两条 nack 保护策略那么当拉流用户很多的时候上述两种场景会给服务器和端带来巨大的 cpu 性能损耗并会引起 nack 网络风暴。不过即使有这两条发送保护策略加持有时还是会产生很多问题比如下面这种场景。
场景 3上游服务器上行推流链路丢包引发下游服务器回源分发链路丢包。
存在这种情况上游服务器发送 nack 请求后rtx 重传包还未到来所以还未中继分发到下游服务器然而此时下游服务已经收到了下游用户连续的并发的 nack 请求。针对这种场景则需要对上行推流链路进行数据包排序只有组成完整的帧才会中继分发到下游服务器这样就避免了下游用户并发的 nack 请求。
其实nack 的发送保护策略还有一条收到一组连续且完整的帧之后会立即对 nack_list 执行部分清空操作避免无必要的再次重传请求接下来的源码分析部分会进一步介绍这个策略。
最后根据策略 1 和策略 3 的描述我们可以推断出这样的结论假设当前网络 rtt 为 100ms那么 100ms * 10 次恰好为 1s。也就是说包在 1s 内还没有重传回来那么就放弃它。
参考WebRTC QoS | NACK 格式与发送策略-阿里云开发者社区
