Page 33 - AV_202111

技术

发送方计算的结果。计算的输入由帧中的所有字段 延迟也是 AV 行业中讨论最广泛的一个问题。
组成，每个交换机、路由器和终端站都会重新计算 延迟对基于 TCP 的视频流的影响有哪些呢？这些
FCS。如果结果与帧中记录的结果不同，则丢弃该 视频流包括自适应比特率流，例如 HLS、DASH 和
帧。如果只有一位被损坏，则该值与接收器的计算 NDI。由于它们是基于 TCP 的，所以它们的传输
结果匹配的可能性大大低于十亿分之一。该过程中 速率、频率和重传规则都受 TCP 算法的约束。这
的一个假设是更高层将处理重传问题。 是我们需要更仔细地观察的地方。
IP 字段还包含一个称为校验和的错误校验码， TCP 有三个流行版本：TCP Reno、Cubic 和
该值是通过使用 IP 标头中的所有字段计算得出的。
Compound。
但是，与以太网不同的是，数据不包括在计算中。
它们的基本操作是相似的，因此为简单起见，
IP 不负责检测损坏的有效负载数据。由于计算使用
我们将基于 TCP Reno 进行讨论。当设备有 TCP
跳数字段，该字段随每个路由器而变化，因此每次
流要传输时，它会与建议的接收器协商，并被告
路由数据包时 IP 校验和都会更改。如果报头中的
知伙伴设备将使用的接收窗口，这是它可以在其
代码与它计算的校验和不匹配，下一个路由器将丢
接收缓冲区中保存的字节数。常见的窗口大小为
弃该数据包。
128kB、256kB 或这些大小的倍数。发送方还发起
第四层协议 TCP 和 UDP 有不同的方法来处理
发送块大小，通常用术语 cwnd 表示，通常是四个
数据包中的错误。在目的地，TCP 会根据 TCP 标
TCP 段。当传输开始时，所有四个段都被发送。
头、有效载荷数据和 IP 标头中的关键字段进行计
发送方等待对该四块的确认。接收者的行为完全不
算，这些字段有时被称为 IP 伪标头。然而，如果
同，它确认所有其他段。因此，它将确认第二段，
计算与校验和字段中存储的值不匹配，TCP 将简单
然后是第四段。
地丢弃数据包。与流行的看法相反，TCP 没有明确
在确保接收方拥有所有四个段的情况下，发送
通知发送方丢弃，它只是不确认收到该段。由于段
方将 cwnd 提高到 8，或者是其先前值的两倍，它
的排序，发送方最终将意识到该段没有被正确接收
立即发送所有八个段并等待该组的确认。接收方再
并且将被重传。
UDP 不提供重传，但它执行错误检查。 如果 次确认收到每隔一段。遵循相同的模式，发送方
报头中有错误，UDP 不想将数据段向上传递到应用 将继续加倍 cwnd 并等待整个数据块的确认。当
层。 这一点尤其重要，因为该标头包含正确识别正 cwnd 达到接收者通告窗口的一半时，快速升级会
确接收应用程序的端口。 变慢。然后发送方将 cwnd 增加 1。请注意，如果
当不包括有效载荷数据的错误检查时，接收器 cwcn 为 8，并且只有一个段丢失、丢弃或只是在
将获得无效数据。 这在 VoIP 中会变得很明显，尤 繁忙缓冲区中延迟，则发送方必须等待块中每个段
其是在使用压缩时：用户可能会听到声音失真。 相 的确认。
反，在诸如 Apple 的 HLS 之类的自适应比特率视 此过程的目的是使发送方和接收方之间的链接
频中，正在使用 TCP。 损坏的数据将在播放前重新 逐渐饱和。当发送方收到网络或接收方丢弃数据包
传输。 因此，虽然延迟可能会增加，但视频应该正 的通知时，它会降低其传输速率。虽然这是另一课
确播放。 的主题，但我们有足够的理解来评估延迟对 TCP
进程的影响。
延迟如何产生的？ 延迟会影响传输速率，因为发送方必须等待在
当前 cwnd 下发送的所有数据包都得到确认。同样
重要的是要注意返回路径中的延迟很关键，如果确
认返回给发送方的速度很慢，则发送方将继续等待
整个块的确认。TCP 操作的这一方面通常被忽视。
这可能是出售给消费者的非对称带宽链路的一个重
大问题。电信、DSL 和电缆链路的下行方向通常是
上行方向的 10倍。在接收ABR视频时，承载确认
的是上行连接，上行链路上的高流量（例如视频上
传）将导致任何下载速度显着减慢。

33