TCP，QUIC and HTTP/3

HTTP/2 的目的主要是通过允许单个多路复用连接来改善 HTTP 协议固有的效率低下问题。在 HTTP/1.1，该连接没有得到充分利用，因为一次只能用于一种资源。如果在响应请求时存在时延（比如因为服务器正忙于生成该资源），连接被 blocked 并且没有被使用。HTTP/2 允许多个资源使用同一个连接，因此在这种情况下其他资源可以使用该连接。

除了避免浪费连接之外，HTTP/2 还提高了性能，因为 HTTP 连接本书效率较低。建立 HTTP 连接需要一定的成本；否则多路复用不会得到真正的好处。成本不是由 HTTP 本身引起的，而是由用于建立此连接的两种基础技术决定的：HTTPS 中使用 TCP 和 TLS。

在本章中，我们讨论这些低效的问题，并表明尽管 HTTP/2 可以更好地处理这些低效的问题，但是某些情况下，由于这些问题，HTTP/2 可能比 HTTP/1.1 更慢。然后我们讨论 QUIC，看看如何针对这些问题进行改进。

9.1 TCP inefficiencies and HTTP

HTTP 依赖网络连接保证数据的可靠传递和有序性。直到最近，这种可靠连接使用 TCP 来保证。TCP 连接两个端（典型的是浏览器和 Web 服务器）然后确保消息传递的可靠性，如果消息丢失就重传，并且保证消息在传递给应用层（HTTP）时保持有序性。HTTP 不需要实现这些复杂的内容，而是假定已经满足这些条件。协议建立在这些假设之上。

TCP 通过给每个 TCP 包分配一个序列号，然后再接收端重排数据包（如果没有按序到达）或者要求重传丢失序列号的包（如果包丢失）。TCP 在 CWND 的基础上工作（这也构成了 HTTP/2 的流控制工作方式；参阅第 7 章），由此确定可发送的最大数据量（CWND 大小），已发送的消息减少了窗口大小，已确认的消息增大了窗口的大小。窗口开始时很小，但是随着时间推移而增长，因为网络容量表示可以承载更多的数据。如果客户端无法跟上进度，窗口也会缩小。这个过程运行得很好，TCP/IP 也因此成为 Internet 的基石。但是 TCP 的工作基本模式还是导致了五个主要问题，至少在 HTTP 方面是问题：

  • 启动延迟。发送方和接收方必须在连接开始时就序列号达成协议。
  • TCP 慢启动算法限制了 TCP 的性能，因为这会保守发送数据以尽可能避免重传
  • 连接的使用不足会导致 TCP 的窗口回退。如果连接没有充分使用，TCP 降低 CWND 的大小，因为无法确定网络是不是有变更
  • 丢包会使 TCP 性能下降。TCP 假设所有丢包是由于网络拥塞，但是不总是这样
  • 数据包可能会排队，接收到乱序数据包会推迟传递到应用层来确保有序

这些问题在 HTTP/2 没有得到改善，其中有些问题是为什么使用单条 TCP 连接性能更好的原因。最后的两个问题，还会在有损条件下导致 HTTP/2 比 HTTP/1.1 性能更弱。