QUIC：协议原理、优势

Quic 全称 quick udp internet connection “快速 UDP 互联网连接”，由 google 提出的使用 udp 进行多路并发传输的协议.

 

为什么需要QUIC

1. 协议历史悠久导致中间设备僵化

2. 依赖于操作系统的实现导致协议本身僵化

3. 建立连接的握手延迟大

　　a. HTTPS 和 HTTP2 还需要使用 TLS 协议来进行安全传输。这就出现了两个握手延迟：

　　　　i. TCP 三次握手导致的 TCP 连接建立的延迟

　　　　ii. TLS 完全握手需要至少 2 个 RTT 才能建立，简化握手需要 1 个 RTT 的握手延迟

　　b. 对于很多短连接场景，这样的握手延迟影响很大，且无法消除

4. 队头阻塞

　　a. 队头阻塞主要是 TCP 协议的可靠性机制引入的。TCP 使用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会通知应用层来处理

　　b. 另外 TLS 协议层面也有一个队头阻塞，因为 TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也会导致整个 record 无法正确处理

　　c. QUIC 协议选择了 UDP，因为 UDP 本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制

 

优势

Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：

1 减少了 TCP 三次握手及 TLS 握手时间

　　a. 0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势

　　　　i. 传输层 0RTT 就能建立连接

　　　　ii. 加密层 0RTT 就能建立加密连接

 

 

2 改进的拥塞控制

　　a. TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复

　　b. QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法

　　c. 从拥塞算法本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，那么 QUIC 协议到底改进在哪些方面呢？主要有如下几点:

　　　　i. 可插拔

　　　　ii. 单调递增的Packet Number

　　　　iii. 不允许 Reneging

　　　　iv. 更多的 Ack 块

　　　　v. Ack Delay 时间

　　　　vi. 基于 stream 和 connecton 级别的流量控制

　　　　vii. 加密认证的报文

 

3 避免队头阻塞的多路复用

　　a. HTTP2多路复用

　　　　i. 多路复用是 HTTP2 最强大的特性 [7]，能够将多条请求在一条 TCP 连接上同时发出去。但也恶化了 TCP 的一个问题，队头阻塞

　　　　ii. 由于 HTTP2 强制使用 TLS，还存在一个 TLS 协议层面的队头阻塞

　　b. QUIC多路复用

　　　　i. QUIC 最基本的传输单元是 Packet，不会超过 MTU 的大小，整个加密和认证过程都是基于 Packet 的，不会跨越多个 Packet。这样就能避免 TLS 协议存在的队头阻塞。

　　　　ii. Stream 之间相互独立，比如 Stream2 丢了一个 Pakcet，不会影响 Stream3 和 Stream4。不存在 TCP 队头阻塞。

连接迁移

　　a. 当其中任何一个元素发生变化时，这条连接依然维持着，能够保持业务逻辑不中断。当然这里面主要关注的是客户端的变化，因为客户端不可控并且网络环境经常发生变化，而服务端的 IP 和端口一般都是固定的

　　b. 那 QUIC 是如何做到连接迁移呢？

　　　　i. 很简单，任何一条 QUIC 连接不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识，这样就算 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连。

　　　　ii. 由于这个 ID 是客户端随机产生的，并且长度有 64 位，所以冲突概率非常低

 

前向冗余纠错

　　在重要的包比如握手消息发生丢失时，能够根据冗余信息还原出握手消息

 

证书压缩，减少证书传输量，针对包头进行验证