QUIC（Quick UDP Internet Connection）协议概述

目录

1 前言

2 什么是QUIC

2.1 HTTP/1.0

2.2 HTTP/1.1

2.3 HTTP/2

2.4 TCP协议的阻塞问题

3 QUIC的协议栈

4 QUIC的报文结构

5 QUIC的核心技术

5.1 修改难度小

5.2 与TLS（Transport Layer Security）集成

5.3 建立连接低时延

5.4 连接迁移

5.5 多流复用，缓解队头阻塞

5.6 改进的拥塞控制机制

5.6.1 可插拔

5.6.2 单调递增的Packet Number

5.6.3 ACK Delay

5.6.4 不允许Reneging

5.6.5 更多ACK块

5.7 双层流量控制

5.7.1 stream级别

5.7.2 connection级别

6 QUIC的缺点

---

1 前言

作者在实习期间简单学习过QUIC协议的基本原理，也在GitHub上找过各类QUIC实现版本，具体的QUIC协议实现涉及到数据包、连接等多个状态机，想要深入研究的小伙伴可以去找些代码看。本篇仅做粗浅的简介。

2 什么是QUIC

QUIC（Quick UDP Internet Connection）是一种传输层协议，与TCP和UDP协议同运行在传输层。

QUIC协议起源于HTTP协议的需求。

2.1 HTTP/1.0

在HTTP/1.0中，客户端（Client）想要发送多个请求（Request）时，当前请求必须上一个请求对应的、来自服务器（Server）的响应（Response）到达之后才能发送。这样会导致完成多个任务的时间很长。

图1 HTTP/1.0

2.2 HTTP/1.1

因此，在HTTP/1.1中，提出了所谓的客户端可以管道化（pipelining）并行发送多个请求。

但是对于服务器而言，还是必须得将上一个响应发送完后，才能发送下一个响应，即在服务器端并没有实现“管道”发送。

图2 HTTP/1.1

2.3 HTTP/2

之后，在HTTP/2中，则实现了基于应用层（即HTTP协议）的“多流复用”，以缩小多个任务场景下的完成时间。

图3 HTTP/2

HTTP/2中，客户端和服务器将数据进行“分帧”，将不同资源请求通过消息中的“stream ID”来区分，即哪个响应对应哪个请求，以及可以区分同时到达的多个请求/响应。

这样，在应用层层面就解决了队头阻塞的问题，但是HTTP协议是基于TCP的，而TCP协议本身存在固有的阻塞问题。

2.4 TCP协议的阻塞问题

TCP协议是一种基于字节流传输数据的协议，无法区分上层业务逻辑的区别，对于来自多个应用程序的数据流，都通过同一个TCP滑动窗口来维护传输。

图4 TCP的阻塞

如图所示，如果对来自应用程序1（stream ID 为1）的数据Seq3的确认ACK丢失后，客户端的滑动窗口会不滑动，直至超时重传Seq3，而这也会导致来自应用程序2（stream ID 为2）和应用程序3（stream ID 为3）的数据传输都堵塞。

这就是TCP协议固有的队头阻塞问题。而UDP协议不需要维护连接和滑动窗口等，在这方面有很大的可拓展性。因此，在HTTP/3中提出了配合应用协议的传输层协议QUIC，即HTTP/3是基于QUIC传输层协议去传输数据的。

而现在，QUIC协议作为一个独立的传输层协议，可作为接口服务于各类应用协议（不仅限于HTTP）。这就是QUIC协议的来源。

3 QUIC的协议栈

QUIC协议在TCP/IP协议栈所处的位置如下图，位于应用层和UDP层之间。