队列|漫画 | Google（互联网太慢了，我要替换TCP！）
今天换一下风格，尝试用一个短小的漫画讲一个小概念。
这个概念如此重要，以至于推动了HTTP甚至TCP的不断发展。
先从1989年蒂姆·伯纳斯·李设计的HTTP协议开始。
HTTP的特点是：发一个Http Request，然后等着Http Response回来，然后再发下一个Http Request....
文章图片
【队列|漫画 | Google（互联网太慢了，我要替换TCP！）】蒂姆·伯纳斯·李想不到的是， 几十年以后， 页面变得非常复杂
文章图片
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任重而道远。
文章图片
点击下方图片，查看更多文章吧 ！
文章图片
文章图片
文章图片
文章图片
推荐阅读
- 漫画初学者如何学习漫画背景的透视画法（这篇教程请收藏好了！）
- 随笔（二）
- 《数据结构与算法之美》——队列
- Redis——发布订阅/消息队列
- 为Google|为Google Cloud配置深度学习环境（CUDA、cuDNN、Tensorflow2、VScode远程ssh等）
- MQ（消息队列）功能介绍
- 17个搜索引擎
- Google|Google - 1
- Java深入了解数据结构之栈与队列的详解
- Android基础-Fragment