一简介

QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协议，因其高效的传输效率和多路并发的能力，已经成为下一代互联网协议HTTP/3的底层传输协议。除了应用于Web领域，它的优势同样适用于一些通用的需要低延迟、高吞吐特性的传输场景。本文从QUIC的由来和优势出发，分享实际项目中需要考虑的问题和解决思路，通过测试对比QUIC和TCP的实际传输能力，希望有助于大家理解和实践QUIC协议

在这里插入图片描述

二为什么需要QUIC？

众所周知，HTTP从最初的HTTP/0.9，经历了HTTP/1.x，HTTP/2到最新的HTTP/3这几个大的更新版本。在HTTP/3版本之前，HTTP底层都是用TCP传输数据，而伴随着移动互联网的发展，网络交互场景越来越丰富并要求及时性，传统TCP固有的性能瓶颈越来越不能满足需求，原因有以下几点：

2.1 建立连接的握手延迟大

HTTPS包含两个握手：1）TCP三次握手，1个RTT；2）TLS握手，2个RTT。完整握手总共需要3个RTT，对于直播等需要首帧秒开场景，握手延迟太大

2.2 多路复用的队首阻塞

以HTTP/2多路复用为例，多个数据请求作为不同的流，共用一条TCP连接发送，所有的流应用层都必须按序处理。若某个流的数据丢失，后面其他流的数据都会被阻塞，直到丢失的流数据重传完成其他流才能被继续传输。即使接收端已经收到之后流的数据包，HTTP协议也不会通知应用层去处理。

2.3 TCP协议的更新滞后

TCP协议是实现在操作系统内核内，但是用户端的操作系统版本升级非常困难，很多老旧的系统像WindowsXP还有大量用户使用，因此TCP协议的一些更新很难被快速推广。
正是考虑到以上的这些问题，QUIC在应用层之上基于UDP实现丢包恢复，拥塞控制，加解密，多路复用等功能，既能优化握手延迟，同时又完全解决内核协议更新滞后问题

三 QUIC的优势

这里列举下QUIC的主要优势。

3.1 握手建连更快

QUIC建连时间大约0~1 RTT，在两方面做了优化：
1）传输层使用了UDP，减少了1个RTT三次握手的延迟。
2）加密协议采用了TLS 协议的最新版本TLS 1.3，相对之前的TLS 1.1-1.2，TLS1.3允许客户端无需等待TLS握手完成就开始发送应用程序数据的操作，可以支持1 RTT和0RTT。
对于QUIC协议，客户端第一次建连的握手协商需1-RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复TLS连接，仅需0-RTT时间。因此QUIC建连时间大部分0-RTT、极少部分1-RTT，相比HTTPS的3-RTT的建连，具有极大的优势。

3.1 避免队首阻塞的多路复用

QUIC同样支持多路复用，相比HTTP/2，QUIC的流与流之间完全隔离的，互相没有时序依赖。如果某个流出现丢包，不会阻塞其他流数据的传输和应用层处理，所以这个方案并不会造成队首阻塞。

3.2 支持连接迁移

什么是连接迁移？举个例子，当你用手机使用蜂窝网络参加远程会议，当你把网络切换到WLAN时，会议客户端会立马重连，视频同时出现一瞬间的卡顿。这是因为，TCP采用四元组（包括源IP、源端口、目标地址、目标端口）标识一个连接，在网络切换时，客户端的IP发生变化，TCP连接被瞬间切断然后重连。连接迁移就是当四元组中任一值发生变化时，连接依旧能保持，不中断业务。QUIC支持连接迁移，它用一个（一般是64位随机数）ConnectionID标识连接，这样即使源的IP或端口发生变化，只要ConnectionID一致，连接都可以保持，不会发生切断重连