SPDY 线头阻塞

Question

我无法理解 SPDY 如何解决 HOL 阻塞问题。

引用自：http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HOL

要理解为什么会这样，回想一下，每个 TCP 数据包在连接到网络时都带有一个唯一的序列号，并且数据必须按顺序传递给接收器（图 2-8）。如果其中一个数据包在发送到接收器的途中丢失，则所有后续数据包都必须保存在接收器的 TCP 缓冲区中，直到丢失的数据包被重新传输并到达接收器。因为这项工作是在 TCP 层内完成的，所以我们的应用程序无法看到 TCP 重传或排队的数据包缓冲区，并且必须等待完整序列才能访问数据。相反，它只是在尝试从套接字读取数据时看到了传递延迟。这种影响称为 TCP 线头 (HOL) 阻塞。

因此存在 HOL 阻塞是因为 TCP 保证按顺序交付。但是here 用户igrigorik 说SPDY 允许数据包以不同的顺序出现。但是，SPDY 不只是 HTTP 的替代品吗？这意味着它仍然通过 TCP 运行（来自here）。

Answer 1

HOLB 有多种原因，其中数据包重传是其中之一，但与 HTTP 和 SPDY 无关。 与 HTTP 和 SPDY 相关的是，在 HTTP 1.x 中，必须按顺序响应多个请求。

想象一个 HTTP 客户端通过同一个 TCP 连接向服务器发送 2 个请求，并且第一个响应的内容长度“大”，而第二个响应的内容长度“小”。

由于 HTTP 1.x 协议的性质，第二个响应必须等待第一个响应完成。第二个响应被第一个响应阻塞。

对于像 SPDY 和 HTTP 2 这样的多路复用协议，这种类型的 HOLB 不存在，因为第二个“小”响应可以在第一个“大”响应之前到达客户端（它们甚至可以交错）。

question you referenced above 的图表以图形方式解释它。

Ilya 在他的回复中不是指 TCP 数据包，而是指 HTTP“数据包”，当时他说它们可能会出现故障。想象一个由 HTTP 标头组成的“数据包”，以及一个由要上传到服务器的 POST 数据组成的“数据包”（或者，在响应中，由要下载到客户端的数据组成的“数据包”）。 在 HTTP 1.x 中，这些 HTTP“数据包”必须按顺序排列（首先是请求 1 的所有 HTTP“数据包”，然后是请求 2 的所有 HTTP“数据包”；或者首先是所有 HTTP响应 1 的“数据包”，然后是响应 2 的所有 HTTP“数据包”），而在 SPDY 和 HTTP 2 中，它们可能是无序的，甚至是交错的。

SPDY 和 HTTP 2 中缺少这种 HOLB 使得这些协议比 HTTP 1.x 更高效。

由 TCP 重传引起的 HOLB 会影响任何基于 TCP 的协议，包括 SPDY 和 HTTP 2 等多路复用协议，以及 HTTP 1.x 等双工协议。