简述
快速UDP网络连接 ( Quick UDP Internet Connections),基于UDP的多路复用安全传输协议。是由 Google 提出的实验性网络传输协议 ，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议， 以减少数据传输，降低连接建立延迟时间，加快网页传输速度。
简单来说QUIC就是UDP之上的快速握手+TLS+HTTP/2（流）
主要特点
多流控制设计；
低等待延迟；
加密性能更优；
前向纠错；
连接保持；
0-RTT
说到QUIC，就不得不提0-RTT，QUIC的设置之初，就是为了减少http请求过程中握手的消耗。传统的http基于tcp协议，每次创建连接，都需要进行三次握手。对于很多短连接场景，这样的握手延迟影响很大，且无法消除。
stream
应用程序协议通过流（按字节顺序排列）在QUIC连接上交换信息。可以创建两种类型的流：
双向流，允许两个端点发送数据；
单向流，允许单个端点发送数据。基于信任的方案可以用于限制流的创建并限制可以发送的数据量。
拥塞控制
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复 。
相比于TCP，QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
从拥塞算法本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，关于改进我们后面详细深入了解。
安全性
QUIC默认支持TLS1.3版本，相比于TCP来说，TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。
QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。
应用场景
HTTP3
5分钟看懂HTTP3-InfoQ
SDK和支持
C/C++
| Name | Version | Roles | Handshake | GitHub |
|---|---|---|---|---|
| Microsoft's MsQuic | draft-29/v1 | client, server | TLS 1.3 RFC | https://github.com/microsoft/msquic |
| Facebook's mvfst | draft-29 | library, client, server | TLS 1.3 | https://github.com/facebookincu |
Rust
| Name | Version | Roles | Handshake | GitHub |
|---|---|---|---|---|
| Cloudflare's quiche | draft-27, draft-28, draft-29 | library, client, server | TLSv1.3 (RFC8446) | https://github.com/cloudflare/quiche |
| Mozilla/Firefox's Neqo | draft-27 through version 1 | library, client, server | TLS 1.3 | https://github.com/mozilla/neqo |
| Quinn | draft-28 | library, client, server | TLS 1.3 | https://github.com/djc/quinn |
Go
| Name | Version | Roles | Handshake | GitHub |
|---|---|---|---|---|
| quic-go | always the current draft | library, client, server | TLS 1.3 RFC | https://github.com/lucas-clemente/quic-go |
参考：RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport (rfc-editor.org)
