AV已经融合到了网络的大潮流中，对于AV人来说了解和精通更多的IT知识势在必行。Phil Hippensteel为我们带来了一些常见的网络问题分析。
带宽
在 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视频时，承载确认的是上行连接，上行链路上的高流量（例如视频上传）将导致任何下载速度显着减慢。