QUIC的出现和逆袭
QUIC的出现和逆袭
简介
基于UDP的低时延的互联网传输层协议。
注: 图片来源于The QUIC Transport Protocol: Design and Internet-Scale Deployment
逐步发展
- QUIC在2013年就被 Google 提出，并且被逐步应用到自有的服务中。
- 至2017年QUIC协议的流量约占Google总出口流量的30％以上， 因此，估计约占全球互联网流量的7％。
注: 图片来源于The QUIC Transport Protocol: Design and Internet-Scale Deployment - 2015年被提议作为 IETF 的标准草案，并在一年之后，就是 2016 年 7 月，提出了 HTTP-over-QUIC。
- 在2018年重命名为 HTTP/3.0， 自此， HTTP-over-QUIC 成为 HTTP 协议的下一个主要版本中。
为什么会出现、为什么会这样出现
随着互联网的发展，对于网络的延迟问题要求越来越高。另一方面对于安全的访问网络这一问题，越来越重视，HTTPS已经成为标配。但是TLS和TCP在减少底层延迟方面有一定的局限性。
协议的固化
TCP，UDP，HTTP的出现
-
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议，在1981年，由IETF的RFC 793 定义。 -
UDP为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。在1980年RFC 768描述了 UDP。 - 在
1982年，TimBerners-Lee提出了HTTP/1.0。在此后的不断丰富和发展中，HTTP/1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响应建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。
通过上面可以看出，其实TCP，UDP，HTTP出现的很早。由于时代的久远，它们的上下游出现了一些中间设备（路由器等）和软件（浏览器等）。软件层面的更改比较方便，比如现在浏览器都出现了支持[IPFS](https://ipfs.io/)（类似P2P的分布式网络）协议的插件。但是硬件层面的变动就比较麻烦了，这就相当于让所有人一起换路由器（或其它中间设备），应该只能停留在想一想的阶段。
所以，QUIC使用UDP的协议来进行传输是在主动适配中间商。其实还有一个没有火起来的反例，SCTP，当然也不排除其它的原因。
实现的固化
TCP通常都是在操作系统内核中实现的，这就限制了协议更改的部署速度。尤其是现在手机设备的增多，这种系统升级更加困难。服务端的升级相对简单，但是对于比较复杂的业务来讲，虽然有云和k8s的加持，升级还是比较麻烦的。
握手延迟
TCP的连接通常需要一个往返延迟，TLS的连接通常需要在延迟之上需要额外的两个往返延迟。并且大多数的网络请求一般是短时间的传输较多，所以握手延迟的问题就会更加明显。而且这种问题通过传统加带宽的方式并不能解决，另一方面我们离量子传输的时代应该还比较远。
TLS握手：
注: 图片来源于cloudflare
- HTTP/1.0
HTTP/1.0时代，每次发送请求都需要进行TCP握手。这样握手延迟的问题就非常严重了。当时也是没有想到互联网会发展如此迅速，在短短的三年之后就升级到了HTTP/1.1。
在一个
TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
问题：服务器必须安装请求的顺序来响应。即后续请求的响应必须等到第一个响应发送之后才能发送，即使后续响应已经完成。这就是HTTP头阻塞的由来。
HTTP2.0增加了一层二进制分帧层，引入了帧，消息，流的概念。每个请求/响应成为消息，消息可分为多帧，每个帧在流中进行传输，一个TCP连接可以有多个流。各个帧在到达之后重组为消息，这样就避免了请求队头阻塞。
多路复用虽然解决了HTTP的头阻塞，但是TCP层面的阻塞，应用并不能控制，所以必须等待前面丢失的段重传。
它出现了
QUIC通过加密传输头（不需要多次握手），并且以UDP协议进行传输，避免中间商赚差价，并且将传输的控制权（流量控制等）交给了应用。