Page 32 - AV_202111

技术

因此，我们的有效吞吐量已降至最大比特率的 95% 大约十年前，Ilya Gregorik 讨论了一个问
左右，即 950 Mbps 左右。即使链路中没有其他流 题，即典型的网页检索涉及客户端向 15 个或更多
量，这也几乎不可能实现。 不同主机发出 90 次访问。显然，可变延迟可能会
最后，MPEG 传输数据部分中的实际视频和 对需要资源的顺序造成严重破坏，并减慢页面的构
音频每个以太网帧 1,316 字节,由于 UDP 不涉及重 建速度。通常，每个请求都是在单独的 TCP 连接
传，并且 SRT 通过前向纠错处理一些错误，因此吞 中进行的。这意味着每个会话的三向握手以及在接
吐量可能接近吞吐量。另一方面，如果传输是 NDI 收到每个资源后适当的会话关闭。其中许多会话也
或自适应比特率，两者都允许重传，则在存在丢失 将从 DNS 请求开始，所有这些都是相当低效的。
的情况下吞吐量会更低。 尝试使用称为保活、流水线和持久连接的技术来纠
正这些问题。然而，他们取得了不同的成功。
HTTP HTTP 2.0 正在逐步部署，它对协议进行了重
大更改，包括：
• HTTP 标头的数据压缩；
• HTTP/2 服务器推送；
• 请求流水线；
• 单个 TCP 会话中的多个请求。
虽然基本每个主流浏览器都支持 HTTP/2，但
即使得到了 HTTP/2 的广泛支持，TCP 性能问题
依然存在，目前很难将较差的 TCP 性能与较差的
HTTP 性能区分开来。但一群有影响力的研究人员
正在推动采用谷歌的 QUIC（不再用作首字母缩写
万维网在超文本传输协议 (HTTP) 和 TCP 上运 词）作为 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) 阻 我们基本上在第二层对所有数据包进行的第一
塞，必须以特定顺序接收开始呈现网页所需的资 次检查，它被称为帧校验序列（FCS）。每个以太
源，当资源被无序接收时发生 HOL。 网帧都有一个四字节字段附加到帧的末尾，这是

32