漫画 | Google：互联网太慢了，我要替换TCP！

今天换一下风格，尝试用一个短小的漫画讲一个小概念。

这个概念如此重要，以至于推动了HTTP甚至TCP的不断发展。

先从1989年蒂姆·伯纳斯·李设计的HTTP协议开始。

HTTP的特点是：发一个Http Request，然后等着Http Response回来，然后再发下一个Http Request....

蒂姆·伯纳斯·李想不到的是， 几十年以后， 页面变得非常复杂

HTTP协议这种请求->等待响应的模式，引发了队头阻塞的问题

这些HTTP请求组成了一个队列，如果队列头部的请求的响应不回来，后面的都得等着。

很明显， 一个很简单的解决方案是多建立几个队列：多建立几个TCP连接

另外一个方案就是多路复用 ：把每个请求和响应当成一个流(Stream) ，每个Stream都有一个ID。

每个Stream可以有多个帧(Frame)，Frame中保存数据。

在同一个TCP连接上，可以有多个多个帧混合着在“流动”。

HTTP 一下子发出3个请求， 它们的Stream次序是 1， 2， 3

但是返回的Stream次序是 2，1， 3， 1 ， 次序乱了。

但是没关系，有Stream ID做关联，浏览器很容易知道请求和响应的对应关系。

HTTP 升级成了 HTTP/2 。（详情参见《HTTP之大明邮差》）

问题似乎解决了 ？

不，站在TCP的角度看， 它不会意识到HTTP层有Stream的存在，一旦TCP层出现丢包，依然会出现队头阻塞的问题！

现在浏览器可以直接使用TCP#1 中的 b.js， 但是由于TCP#2丢了，按照TCP协议的要求，TCP#3中的数据是不能使用的， 虽然其中的数据是完整的h.css，还必须等待TCP#2重传。

问题的本质就是站在TCP的视角看，它看到数据是没有含义的二进制流而已。

如果修改一下TCP协议，让他理解这些“Stream”呢？

不行，TCP是在操作系统内核中实现的，想改TCP就得改操作系统，然后部署到全世界所有的网络设备上，这就难了。

所以现在只能调整一下操作系统中网络的参数而已。

既然改不了现有的TCP， 那我们就创造一个新的协议出来，让这个新协议能意识到“Stream”的存在

这个新协议，就是Google提出的QUIC！

如果浏览器收到了QUIC #1, #3, #4, 但是QUIC #2丢失了， 会发生什么情况呢？

#4 可以暂时保存，等待 #2的重新传输。

虽然QUIC不知道Stream中传输的数据到到底是什么含义，但是通过引入Stream , QUIC彻底解决了队头阻塞的问题！

当然，由于Stream的概念下移到了QUIC中，那HTTP中的Stream就不需要了。

HTTP/2就升级成了HTTP/3。

不过， QUIC是基于UDP实现的，TCP的那些优秀特性，它不得不重新实现一遍了。

QUIC不在操作系统内核中，意味着应用程序可以对它任意定制，例如轻松地控制各种拥塞算法的实现。

QUIC作为新协议，除了上面说的可以解决队头阻塞问题之外，还有很多优点：

1.减少RTT时间

2. 改善拥塞控制

3. 连接迁移

4. 集成TLS，更加安全

小结：TCP协议已经统治了世界50年，基于TCP的HTTP也30多岁了，在新的环境，它们的弊端逐渐暴露，一个突出的问题就是HTTP和TCP的队头阻塞问题，QUIC和HTTP/3有可能是解决之道。

不过想替换TCP可不是那么简单的事情，今年6月IETF 才发布了QUIC的规范RFC9000，根据w3techs的统计，至今只有5.8%的网站在使用QUIC，主要是Google的网站，QUIC任重而道远。

点击下方图片，查看更多文章吧 ！