AV/IP环境中的网络问题

　　带宽

　　在 AV 行业中，带宽是我们常用的术语。提到 带宽，当它与频谱和信令一起使用时，往往都具有 明确的含义。但是，当它在IP环境中使用时，如 “网络带宽”中的含义就很大差异。这在音视频行 业的培训和学习课程中尤为常见。

　　使用术语“网络带宽”时，通常指的是单个链 接可以支持的最大比特率或最大比特率之一。 例 如，假设我们有一个包含所有千兆以太网交换机的 音频网络， 您可能会说正在使用千兆网络。如果 1 Gbps 和 10 Gbps 交换机都在网络中，您可以说它 是 1G 或 10G 网络。

　　但是，在IT行业，对于网络可以承载多少信 息，通常有几种描述。事实上，术语“网络”可能 用于指代两个终端设备之间的连接。假设服务器通过 1G 网络连接到交换机，并且到客户端的路径 中，接下来的几个交换机通过 10G 链路连接。最 后，假设最后一个交换机通过 1G 链路连接到客户 端。网络管理员可能会将此客户端—服务器连接称 为 1G 连接，因为它可以在两个终端设备之间承载 1 Gbps 的理论负载。

　　通常，两个此类设备之间的路径描述由两个 相关术语描述。首先，术语“吞吐量”通常用于 描述实际通过路径的位数。因此，在前面描述的 情况下，测量时的吞吐量可能是 600 Mbps 或 850 Mbps。它肯定永远不会是 1 Gbps，即理论上的最 大速率。

　　这是由于以太网帧之间的时间间隔、交换机的 存储和转发操作以及许多其他因素造成的。最后， IT 行业中的一些人使用术语“goodput”。该术 语是指通过设备之间的路径传输的实际应用程序数 据量。Goodput 将始终低于最低带宽链路并低于 吞吐量。

　　我们来举个例子，假设摄像机使用1 Gbps以太 网交换机，通过路径连接到查看设备，我们可以说 路径的带宽是 1Gbps。但是，另外假设摄像机输出 是SRT，它是基于UDP的，并且实际视频是MPEG 传输的形式。

　　现在，每个发送的数据包至少有58字节的协议 头开销，此类数据包的长度通常约为1,372字节。因此，我们的有效吞吐量已降至最大比特率的 95% 左右，即 950 Mbps 左右。即使链路中没有其他流 量，这也几乎不可能实现。

　　最后，MPEG 传输数据部分中的实际视频和 音频每个以太网帧 1,316 字节,由于 UDP 不涉及重 传，并且 SRT 通过前向纠错处理一些错误，因此吞 吐量可能接近吞吐量。另一方面，如果传输是 NDI 或自适应比特率，两者都允许重传，则在存在丢失 的情况下吞吐量会更低。

　　HTTP

　　万维网在超文本传输协议 (HTTP) 和 TCP 上运 行。从 1990 年代初期开始，作为网络一部分的服 务器已经使用这两种协议的一个版本建立连接和提 供信息。作为AV人，我们应该熟悉 HTTP 有三个 重要原因。

　　首先，几乎所有 AV 行人每天都使用网络来接 收信息。 其次，视频通常使用 HTTP 传送。 第三， 也是最重要的一点，HTTP 和 TCP 都在进行重大修 改。TCP 可能接近其生命周期结束状态，替换它可 能会导致 HTTP 和 Web 本身发生重大变化。

　　在其标题中使用术语“文本”是因为原始0.9 版本旨在允许仅使用文本进行请求和响应。请求/ 响应字符保留在最初广泛采用的 1.0 版和后续协议 HTTP 1.1 中。由于 1.1 版是在 1.0版 之后的六个 月内采用的，并且非常相似，我们来看看最广泛的 HTTP 1.1版本。

　　客户端使用称为“get”的命令发出请求，该 命令标识它需要的一个或多个文件。 Web 服务器 通常以“OK”响应，然后发送资源。如果资源不 可用或位于其他地方，它可能会以错误代码“404 Resource Not Found”或指示所需资源位置的重 定向进行响应。 1.1 版的问题之一是队头 (HOL) 阻 塞，必须以特定顺序接收开始呈现网页所需的资 源，当资源被无序接收时发生 HOL。

　　大约十年前，Ilya Gregorik 讨论了一个问 题，即典型的网页检索涉及客户端向 15 个或更多 不同主机发出 90 次访问。显然，可变延迟可能会 对需要资源的顺序造成严重破坏，并减慢页面的构 建速度。通常，每个请求都是在单独的 TCP 连接 中进行的。这意味着每个会话的三向握手以及在接 收到每个资源后适当的会话关闭。其中许多会话也 将从 DNS 请求开始，所有这些都是相当低效的。 尝试使用称为保活、流水线和持久连接的技术来纠 正这些问题。然而，他们取得了不同的成功。 HTTP 2.0 正在逐步部署，它对协议进行了重 大更改，包括：

　　• HTTP 标头的数据压缩；

　　• HTTP/2 服务器推送；

　　• 请求流水线；

　　• 单个 TCP 会话中的多个请求。

　　虽然基本每个主流浏览器都支持 HTTP/2，但 即使得到了 HTTP/2 的广泛支持，TCP 性能问题 依然存在，目前很难将较差的 TCP 性能与较差的 HTTP 性能区分开来。但一群有影响力的研究人员 正在推动采用谷歌的 QUIC（不再用作首字母缩写 词）作为 TCP 的替代品。这将为互联网用户和开 发人员创造一个全新的环境。

　　丢包控制

　　我们经常讨论被丢弃的错误数据包，而不了解 决定数据包被丢弃原因的底层技术，有几个协议层 的错误检查，因此，当数据包在目的地被接收时， 会在网络中的多个点以及不同级别检查数据包是否 存在问题。

　　我们基本上在第二层对所有数据包进行的第一 次检查，它被称为帧校验序列（FCS）。每个以太 网帧都有一个四字节字段附加到帧的末尾，这是发送方计算的结果。计算的输入由帧中的所有字段 组成，每个交换机、路由器和终端站都会重新计算 FCS。如果结果与帧中记录的结果不同，则丢弃该 帧。如果只有一位被损坏，则该值与接收器的计算 结果匹配的可能性大大低于十亿分之一。该过程中 的一个假设是更高层将处理重传问题。

　　IP 字段还包含一个称为校验和的错误校验码， 该值是通过使用 IP 标头中的所有字段计算得出的。 但是，与以太网不同的是，数据不包括在计算中。 IP 不负责检测损坏的有效负载数据。由于计算使用 跳数字段，该字段随每个路由器而变化，因此每次 路由数据包时 IP 校验和都会更改。如果报头中的 代码与它计算的校验和不匹配，下一个路由器将丢 弃该数据包。

　　第四层协议 TCP 和 UDP 有不同的方法来处理 数据包中的错误。在目的地，TCP 会根据 TCP 标 头、有效载荷数据和 IP 标头中的关键字段进行计 算，这些字段有时被称为 IP 伪标头。然而，如果 计算与校验和字段中存储的值不匹配，TCP 将简单 地丢弃数据包。与流行的看法相反，TCP 没有明确 通知发送方丢弃，它只是不确认收到该段。由于段 的排序，发送方最终将意识到该段没有被正确接收 并且将被重传。

　　UDP 不提供重传，但它执行错误检查。 如果 报头中有错误，UDP 不想将数据段向上传递到应用 层。 这一点尤其重要，因为该标头包含正确识别正 确接收应用程序的端口。

　　当不包括有效载荷数据的错误检查时，接收器 将获得无效数据。 这在 VoIP 中会变得很明显，尤 其是在使用压缩时：用户可能会听到声音失真。 相 反，在诸如 Apple 的 HLS 之类的自适应比特率视 频中，正在使用 TCP。 损坏的数据将在播放前重新 传输。 因此，虽然延迟可能会增加，但视频应该正 确播放。

　　延迟如何产生的？

　　延迟也是 AV 行业中讨论最广泛的一个问题。 延迟对基于 TCP 的视频流的影响有哪些呢？这些 视频流包括自适应比特率流，例如 HLS、DASH 和 NDI。由于它们是基于 TCP 的，所以它们的传输 速率、频率和重传规则都受 TCP 算法的约束。这 是我们需要更仔细地观察的地方。

　　TCP 有三个流行版本：TCP Reno、Cubic 和 Compound。

　　它们的基本操作是相似的，因此为简单起见， 我们将基于 TCP Reno 进行讨论。当设备有 TCP 流要传输时，它会与建议的接收器协商，并被告 知伙伴设备将使用的接收窗口，这是它可以在其 接收缓冲区中保存的字节数。常见的窗口大小为 128kB、256kB 或这些大小的倍数。发送方还发起 发送块大小，通常用术语 cwnd 表示，通常是四个 TCP 段。当传输开始时，所有四个段都被发送。 发送方等待对该四块的确认。接收者的行为完全不 同，它确认所有其他段。因此，它将确认第二段， 然后是第四段。

　　在确保接收方拥有所有四个段的情况下，发送 方将 cwnd 提高到 8，或者是其先前值的两倍，它 立即发送所有八个段并等待该组的确认。接收方再 次确认收到每隔一段。遵循相同的模式，发送方 将继续加倍 cwnd 并等待整个数据块的确认。当 cwnd 达到接收者通告窗口的一半时，快速升级会 变慢。然后发送方将 cwnd 增加 1。请注意，如果 cwcn 为 8，并且只有一个段丢失、丢弃或只是在 繁忙缓冲区中延迟，则发送方必须等待块中每个段 的确认。

　　此过程的目的是使发送方和接收方之间的链接 逐渐饱和。当发送方收到网络或接收方丢弃数据包 的通知时，它会降低其传输速率。虽然这是另一课 的主题，但我们有足够的理解来评估延迟对 TCP 进程的影响。

　　延迟会影响传输速率，因为发送方必须等待在 当前 cwnd 下发送的所有数据包都得到确认。同样 重要的是要注意返回路径中的延迟很关键，如果确 认返回给发送方的速度很慢，则发送方将继续等待 整个块的确认。TCP 操作的这一方面通常被忽视。 这可能是出售给消费者的非对称带宽链路的一个重 大问题。电信、DSL 和电缆链路的下行方向通常是 上行方向的 10倍。在接收ABR视频时，承载确认 的是上行连接，上行链路上的高流量（例如视频上 传）将导致任何下载速度显着减慢。

关注读览天下微信， 100万篇深度好文， 等你来看……