http1.1流水线传输方式

这是一个非常重要但又经常被误解的概念，因为它在实践中很少被使用，但理解它能帮助我们更好地理解 HTTP 的演进。

HTTP/1.1 流水线是一种在同一个持久的 TCP 连接上发送多个 HTTP 请求，而无需等待每个相应响应的技术。

我们可以用三种模式来对比理解：

HTTP/1.0 非持久连接
- 过程：建立连接 -> 发送请求1 -> 接收响应1 -> 关闭连接 -> 建立新连接 -> 发送请求2 -> 接收响应2 -> ...
- 比喻：打电话。问一个问题，得到答案，挂断。再打一次电话问下一个问题。
- 缺点：每次请求都伴随 TCP 连接/断开的开销，非常低效。
HTTP/1.1 持久连接
- 过程：建立连接 -> 发送请求1 -> 接收响应1 -> 发送请求2 -> 接收响应2 -> ... -> 关闭连接。
- 比喻：打电话不挂断。问第一个问题，等待答案；得到答案后，再问第二个问题。
- 优点：减少了 TCP 握手和慢启动的开销，这是现代浏览器的默认行为。
HTTP/1.1 流水线持久连接
- 过程：建立连接 -> 连续发送请求1、请求2、请求3... -> 按顺序接收响应1、响应2、响应3... -> 关闭连接。
- 比喻：打电话不挂断，并且一口气把问题清单上的所有问题都念给对方听，然后等待他按顺序一个一个地回答你。
- 目标：进一步减少网络延迟，提高连接利用率。

FIFO（先进先出）：请求必须按照发送的顺序被处理，响应也必须按照请求的顺序返回。这是流水线最核心的规则，也是其最大问题的根源。
客户端行为：
- 只有在确认连接是持久的情况下才可以使用流水线。
- 客户端必须准备好接收比它期望的更早到来的响应（例如，在它发送完所有请求之前就可能开始收到响应）。
服务器行为：
- 服务器必须能够按照接收到的请求顺序来发送响应。
- 如果一个请求在处理过程中花费了很长时间，它后面的所有响应的发送都会被阻塞，这被称为 队头阻塞。

尽管流水线在理论上很美好，但在现实世界中却充满了问题，导致它在绝大多数浏览器和服务器中默认被禁用。

主要问题：

队头阻塞
- 这是流水线的“致命伤”。想象一下，你连续请求了 image1.jpg、image2.jpg 和 image3.jpg。如果 image1.jpg 的处理非常慢（比如服务器需要从很慢的磁盘读取），那么即使 image2.jpg 和 image3.jpg 已经准备好了，它们也必须等在 image1.jpg 的响应后面，无法被发送。
- 这严重降低了性能，尤其是在有慢请求的网络环境中。
代理服务器的兼容性问题
- 在客户端和服务器之间可能存在多个代理服务器。即使客户端和最终服务器都支持流水线，但只要路径上有一个代理服务器不能正确处理流水线请求（例如，它不遵守 FIFO 规则），就会导致通信失败。
- 这种“中间盒子”问题使得部署流水线变得非常困难。
错误处理复杂
- 如果一个流水线中的请求失败了，客户端很难判断服务器已经处理了哪些请求。由于 TCP 连接可能仍然完好，但应用层协议已经混乱，客户端唯一安全的选择就是重新建立连接并重发所有请求，这反而降低了效率。

正是因为 HTTP/1.1 流水线的这些根本性缺陷，HTTP/2 采用了一种完全不同的、更优秀的方案来解决同一个问题：多路复用。

特性	HTTP/1.1 流水线	HTTP/2 多路复用
核心机制	在一个连接上按顺序发送和接收多个请求/响应。	将请求和响应分解为二进制帧，并为每个帧分配一个流ID。
顺序问题	严格 FIFO。响应必须按请求顺序返回。	完全解耦。帧可以乱序发送和接收，接收方通过流ID重新组装。
队头阻塞	存在应用层队头阻塞。一个慢请求会阻塞其后所有请求。	不存在应用层队头阻塞。一个流的阻塞不会影响其他流。
实现复杂度	相对简单，但错误处理复杂。	实现更复杂，但提供了更好的性能和健壮性。