Part 01
什么是QUIC
QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协议，因其高效的传输效率和多路并发的能力，已经成为下一代互联网协议HTTP/3的底层传输协议，2021年5月IETF公布RFC9000，QUIC规范推出了标准化版本。除了应用于Web领域，它的优势同样适用于一些通用的需要低延迟、高吞吐特性的传输场景。
从协议栈可以看出：QUIC = HTTP/2 + TLS + UDP
Part 02
为什么要有QUIC
HTTP从最初的HTTP/0.9，经历了HTTP/1.x，HTTP/2到最新的HTTP/3这几个大的迭代。在HTTP/3版本之前，HTTP底层都是用TCP传输数据，而伴随着移动互联网的发展，网络交互场景越来越丰富并要求及时性，传统TCP固有的性能瓶颈越来越不能满足需求，原因有以下几点：
- 建立连接的握手延迟大
HTTPS包含两个握手：1）TCP三次握手，1个RTT；2）TLS握手，2个RTT。完整握手总共需要3个RTT，对于直播等需要首帧秒开场景，握手延迟太大。
- 多路复用的队首阻塞
以HTTP/2多路复用为例，多个数据请求作为不同的流，共用一条TCP连接发送，所有的流应用层都必须按序处理。若某个流的数据丢失，后面其他流的数据都会被阻塞，直到丢失的流数据重传完成其他流才能被继续传输。即使接收端已经收到之后流的数据包，HTTP协议也不会通知应用层去处理。
- TCP协议的更新滞后
TCP协议实现在操作系统内核内，但是用户端的操作系统版本升级非常困难，很多老旧的系统还有大量用户使用，因此TCP协议的一些更新很难被快速推广。
正是考虑到以上的这些问题，QUIC在应用层之上基于UDP实现丢包恢复，拥塞控制，加解密，多路复用等功能，既能优化握手延迟，同时又完全解决内核协议更新滞后问题。
Part 03
QUIC建立连接的过程
QUIC建立连接步骤比较简单，流程如下：
1）客户端发起Inchoate client hello；
2）服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端；
3）客户端发起client hello，包括客户端公钥信息。
此时，双方各自计算出了对称密钥。QUIC的1次RTT建连过程结束，平均只耗时100ms以内。后续发起连接的过程中，一旦客户端缓存或持久化了server config，就可以复用并结合本地生成的私钥进行加密数据传输，不需要再次握手，从而实现0次RTT建立连接。
Part 04
QUIC的优缺点
4.1 QUIC的优势体现在如下方面：
（1）可扩展性强。更改TCP并不容易，因为其中的中间件抗拒更新，而且TCP 40字节的可选位几乎全部填满。TCP没有任何版本协商(version negotiation)扩展位，相比之下，QUIC有32位，所以它有很多空间部署新版本，厂商也可以利用这些空间定义自己的专属版本。
（2）用户空间实现容易。QUIC能够在应用层实现，与在操作系统内核中实现的TCP相比，它可以更快地进行更新。这进一步提高了QUIC的可扩展性，使得服务可以非常快速地演进，从而新的特性每天都能得到部署。同时它还能在上下文切换时通过调用较少的开销而实现更高的响应能力。
（3）建立连接更加快速。Web浏览特别需要快速建立连接，因为用户通常会开启多个、短暂的连接。当使用HTTPS时，TCP在建立连接前，需要“三次握手”以及后续的TLS协议设置。QUIC（基于UDP）不需要三次握手，加上它会在初次握手时交换安全密钥，从而使它在建立加密连接时速度提升了一倍。
（4）丢包敏感度较低。使用TCP时，如果丢失一个数据包，接下来所有的数据包都会停止传输，直到丢失的那个数据包被发送，这种现象被称为“队头阻塞”，它会导致延迟明显增加。相比之下，QUIC使用的是类似HTTP/2的多路复用模式，可以同时支持多个数据流。如果一个数据流发送错误，导致丢包，那么其他数据流会继续发送数据包，而不会阻塞传输。
（5）切换网络时的性能提升较高。切换网络时，QUIC可以实现平稳过渡。比如，当你使用家里的Wi-Fi观看手机上的视频，然后你走出家门，家里的Wi-Fi便切换到LTE；或者当你一直忙于观看视频，在不同的移动基站间移动时；在以上这些场景中，TCP将切断连接，并通过新的网络创建新的连接，进而影响到你的观看体验，而QUIC则能够实现无缝连接。
（6）安全性和隐私保护较高。QUIC在传输层中内置了加密功能，从而验证整个负载（包括header）。TCP在header中不包含加密，使它非常容易受到攻击。QUIC默认支持安全的TLS，意味着端到端完全安全。
4.2 QUIC的劣势体现在如下方面：
TCP发明时，网络都是有线连接，而且相当可靠，QUIC对非可靠、无法预测的无线连接进行了改进，但并没有改变互联网传输的本质，它的局限性导致它只能改变某些特定使用场景。下面列举了一些额外的QUIC局限性：
（1）迁移app面临巨大挑战。将app从HTTP/2迁移到HTTP/3（或者从TCP迁移到UDP）要费很大力气。整个过程需要将应用层实现和传输层实现转移到UDP，并在服务端和客户端构建全新的解决方案。这对于流媒体领域中资源相对有限的小厂商而言无疑挑战重重，同时也解释了谷歌和微软这样的科技巨头可以率先采用QUIC协议的原因。
（2）采用受限。QUIC的最大问题就是它的采用依然受限。几乎每个浏览器都接受使用QUIC进行简单的网页浏览，但是除了chromium，没有浏览器将它设置为默认选项。除此之外，在流媒体领域，除了谷歌和Facebook之外，少有公司使用QUIC。只有少数CDN提供商支持QUIC，而其中的一些也只是验证了QUIC的实现，并没有为大规模部署准备好。这就带来了问题：如果你推出了使用multi-CDN并基于QUIC的新服务，那么将只有20%的访问使用QUIC，因为你无法向用户证明它对用户体验的显著影响。
（3）QUIC包含TCP回退。QUIC之所以被构建在UDP之上，部分原因是极少有中间件和网络设备拦截UDP。但确实存在被拦截的风险，所以基于QUIC的app必须设计成能够回退到TCP，以防万一。这意味着app（基于QUIC）的开发者要同时开发和维护两个不同的版本（由于TCP回退和受到限制的采用率），导致他们的负担很重。好消息是，随着最新的DEVOPS结构与HTTP的Alt-Svc标签的使用，支持两种协议要比以前简单得多。
（4）无法检查数据包。网络防火墙无法解密QUIC流量来检查数据包，所以潜在的恶意流量非常有可能没有被标准安全功能检测出来而进入网络。因此，思科和Palo Alto Networks等安全厂商通常会在端口80（Web服务器）和443(TSL)拦截QUIC数据包（认为它们包含恶意软件），迫使客户端回退使用HTTP/2和TCP协议。但上述操作并不会显著影响内容用户体验，因为正确实现的流媒体服务会默认回退到TCP+TLS，但这种操作可能会阻止率先部署QUIC的想法。只有解决这一挑战，QUIC才能被各大企业广泛接受。
Part 05
QUIC在实际场景中的使用
5.1 QUIC在MQTT通信场景中的应用前景
MQTT是基于TCP的物联网通信协议，紧凑的报文结构能够在严重受限的硬件设备和低带宽、高延迟的网络上实现稳定传输；心跳机制、遗嘱消息、QoS质量等级等诸多特性能够应对各种物联网场景。尽管如此，由于底层TCP传输协议限制，某些复杂网络环境下 MQTT 协议存在固有的弊端：
- 网络切换导致经常性连接中断；
- 断网后重新建立连接困难：断网后操作系统释放资源较慢，且应用层无法及时感知断开状态，重连时Server/Client开销较大；
- 弱网环境下数据传输受限于拥塞、丢包侦测和重传机制。
例如车联网用户通常会面对类似的问题：车辆可能会运行在山区、矿场、隧道等地方，当进入到信号死角或被动切换基站时会导致连接中断，频繁连接中断与较慢的连接恢复速度会导致用户体验变差。在一些对数据传输实时性和稳定性要求较高的业务，如L4级别的无人驾驶中，客户需要花费大量的成本来缓解这一问题。
在上述这类场景中，QUIC低连接开销和多路径支持的特性就显示出了其优势，基于QUIC 0 RTT/1 RTT重连/新建能力，能够在弱网与不固定的网络通路中有效提升用户体验。
5.2 QUIC协议在CDN加速方面的应用
传统CDN会有多级结构，每一级结构会有不同热度数据。在CDN节点之间有大量的通讯数据，这些数据进行分布式存储时的路径对最终CDN服务质量有着非常重要的影响。通常来说影响通讯质量的因素通常会受到缓存业务内容的性质、节点间的网络连接和Client-server侧的传输架构和机制的影响。这些层级间的数据拉取性能会直接影响到整体CDN的下发响应速度。通常可以通过TCP优化手段（数据连接池、TCP优化）、缓存数据分块、高层级向低层次的数据推送、缓存数据预拉取、数据压缩等手段实现超远节点之间的进一步传输。
在这种情况下，QUIC的优势就展现出来了。CDN QUIC服务针对业务场景进行了全面优化，包括4个方面：
- 连接优化0-RTT连接复用率，降低连接的延迟。
- 加解密优化明文传输，可以减少加解密造成的一些影响。
- 传输优化乱序报文缓存，针对特殊数据优先级需求进行调整。
- 针对线上的不同业务场景调整参数，利用拥塞算法，提升在不同业务场景下的效果。
Part 06
总结
本文主要对QUIC协议概念背景以及该协议的优缺点进行了简要的概述，同时举例了该协议的应用场景，方便大家对该协议有一个初步的了解。目前该协议大型互联网公司都有在不同的业务场景中使用，得到了不错的性能提升。中国移动也在积极探索新技术，用技术改变生活。
