HTTP的前世今生详解( 三 ) _网络教程

我们可以看到，HTTP/2 在性能上对 HTTP 有质的提高，所以，HTTP/2 被采用的也很快，所以，如果你在你的公司内负责架构的话，HTTP/2 是你一个非常重要的需要推动的一个事，除了因为性能上的问题，推动标准落地也是架构师的主要职责，因为，你企业内部的架构越标准，你可以使用到开源软件，或是开发方式就会越有效率，跟随着工业界的标准的发展，你的企业会非常自然的享受到标准所带来的红利。
HTTP/3然而，这个世界没有完美的解决方案，HTTP/2 也不例外，其主要的问题是：若干个 HTTP 的请求在复用一个 TCP 的连接，底层的 TCP 协议是不知道上层有多少个 HTTP 的请求的，所以，一旦发生丢包，造成的问题就是所有的 HTTP 请求都必需等待这个丢了的包被重传回来，哪怕丢的那个包不是我这个 HTTP 请求的。因为 TCP 底层是没有这个知识了。
这个问题又叫 Head-of-Line Blocking 问题，这也是一个比较经典的流量调度的问题。这个问题最早主要的发生的交换机上。下图来自 Wikipedia 。

图中，左边的是输入队列，其中的 1，2，3，4 表示四个队列，四个队列中的 1，2，3，4 要去的右边的 output 的端口号。此时，第一个队列和第三个队列都要写右边的第四个端口，然后，一个时刻只能处理一个包，所以，一个队列只能在那等另一个队列写完后。然后，其此时的 3 号或 1 号端口是空闲的，而队列中的要去 1 和 3 号端号的数据，被第四号端口给 block 住了。这就是所谓的 HOL blocking 问题。
HTTP/1.1 中的 pipeline 中如果有一个请求 block 了，那么队列后请求也统统被 block 住了；HTTP/2 多请求复用一个 TCP 连接，一旦发生丢包，就会 block 住所有的 HTTP 请求。这样的问题很讨厌。好像基本无解了。
是的 TCP 是无解了，但是 UDP 是有解的！于是 HTTP/3 破天荒地把 HTTP 底层的 TCP 协议改成了 UDP！
然后又是 Google 家的协议进入了标准 – QUIC （Quick UDP Internet Connections）。接下来是 QUIC 协议的几个重要的特性，为了讲清楚这些特性，我需要带着问题来讲（注：下面的网络知识，如果你看不懂的话，你需要学习一下《TCP/IP 详解》一书（在我写 blog 的这 15 年里，这本书推荐了无数次了），或是看一下本站的《TCP 的那些事》。）：

首先是上面的 Head-of-Line blocking 问题，在 UDP 的世界中，这个就没了。这个应该比较好理解，因为 UDP 不管顺序，不管丢包（当然，QUIC 的一个任务是要像 TCP 的一个稳定，所以 QUIC 有自己的丢包重传的机制）
TCP 是一个无私的协议，也就是说，如果网络上出现拥塞，大家都会丢包，于是大家都会进入拥塞控制的算法中，这个算法会让所有人都“冷静”下来，然后进入一个“慢启动”的过程，包括在 TCP 连接建立时，这个慢启动也在，所以导致 TCP 性能迸发地比较慢。QUIC 基于 UDP，使用更为激进的方式。同时，QUIC 有一套自己的丢包重传和拥塞控制的协，一开始 QUIC 是重新实现一 TCP 的 CUBIC 算法，但是随着 BBR 算法的成熟（BBR 也在借鉴 CUBIC 算法的数学模型），QUIC 也可以使用 BBR 算法。这里，多说几句，从模型来说，以前的 TCP 的拥塞控制算法玩的是数学模型，而新型的 TCP 拥塞控制算法是以 BBR 为代表的测量模型，理论上来说，后者会更好，但 QUIC 的团队在一开始觉得 BBR 不如 CUBIC 的算法好，所以没有用。现在的 BBR 2.x 借鉴了 CUBIC 数学模型让拥塞控制更公平。这里有文章大家可以一读“TCP BBR : Magic dust for network performance.”
接下来，现在要建立一个 HTTPS 的连接，先是 TCP 的三次握手，然后是 TLS 的三次握手，要整出六次网络交互，一个链接才建好，虽说 HTTP/1.1 和 HTTP/2 的连接复用解决这个问题，但是基于 UDP 后，UDP 也得要实现这个事。于是 QUIC 直接把 TCP 的和 TLS 的合并成了三次握手（对此，在 HTTP/2 的时候，是否默认开启 TLS 业内是有争议的，反对派说，TLS 在一些情况下是不需要的，比如企业内网的时候，而支持派则说，TLS 的那些开销，什么也不算了）。
- 上一页
- 1
- 2
- 3
- 4
- 下一页
推荐阅读