QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协议，因其高效的传输效率和多路并发的能力，已经成为下一代互联网协议HTTP/3的底层传输协议。除了应用于Web领域，它的优势同样适用于一些通用的需要低延迟、高吞吐特性的传输场景。本文从QUIC的由来和优势出发，分享实际项目中需要考虑的问题和解决思路，通过测试对比QUIC和TCP的实际传输能力，希望有助于大家理解和实践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协议是实现在操作系统内核内，但是用户端的操作系统版本升级非常困难，很多老旧的系统像WindowsXP还有大量用户使用，因此TCP协议的一些更新很难被快速推广。
正是考虑到以上的这些问题，QUIC在应用层之上基于UDP实现丢包恢复，拥塞控制，加解密，多路复用等功能，既能优化握手延迟，同时又完全解决内核协议更新滞后问题。
这里列举下QUIC的主要优势。
握手建连更快
QUIC建连时间大约0~1 RTT，
