Quic协议介绍和浅析

最新推荐文章于 2025-09-07 12:45:36 发布

原创最新推荐文章于 2025-09-07 12:45:36 发布 · 9.4k 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#http #quic

http 专栏收录该内容

4 篇文章

订阅专栏

一，Quic全称是什么？

QUIC 全称 Quick UDP Internet Connection, 是Google制定的一种基于 UDP 协议的低时延互联网应用层协议。

二，Quic的优势和应用场景

1，为什么需要Quic：

近三十年来，tcp协议发展得非常缓慢
很多网络中间层，比如防火墙、网关等，都强依赖于tcp指定的各类规则，所以tcp的修改很容易由于这些中间环节的存在而受到干扰。
tcp是由操作系统在内核层面实现的，导致tcp的迭代受限于操作系统的升级。

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

减少了 TCP 三次握手及 TLS 握手时间。
改进的拥塞控制。
避免队头阻塞。

3，应用场景

弱网环境的时候能够提升 20% 以上的访问速度。
频繁切换网络的情况下，不会断线，不需要重连，用户无任何感知。

三，Quic协议原理

1，0RTT 建连

在这里插入图片描述
先声明一点，如果一对使用QUIC进行加密通信的双方此前从来没有通信过，0RTT是不可能的。
所以第一次C和S建连还是会走正常的tls握手流程，但过了一会儿或者一段时间后，C又想和S通信，此时C已经有了刚刚和S协商出来的密钥（可能是存在内存or外存）。C就会利用刚刚的密钥K1来和S加密首次数据，在第二个RTT期间，S会和C协商出新的密钥K2，作为接下来的通信密钥。

2，没有歧义的重传

TCP 重传的包的 sequence number 和原始的包的 Sequence Number 是保持不变的，也正是由于这个特性，引入了 Tcp 重传的歧义问题。
在这里插入图片描述
超时事件 RTO 发生后，客户端发起重传，然后接收到了 Ack 数据。由于Sequence Number一样，这个 Ack 到底是原始请求的响应还是重传请求的响应呢？这就间接导致了RTT计算的歧义。

Quic 使用 Packet Number 代替了 TCP 的 sequence number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值，这就解决了RTT计算的歧义问题。

3，保证包的顺序

QUIC 引入了一个叫 Stream Offset 的概念。
在这里插入图片描述
假设 Packet N 丢失了，发起重传，重传的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，这样就算 Packet N + 2 是后到的，依然可以将 Stream x 和 Stream x+y 按照顺序组织起来。

4，解决ack delay

在这里插入图片描述
TCP 的 RTT 计算：

Quic的RTT计算：

5，队头阻塞

拿http2举例，
在这里插入图片描述
http2 在一个 TCP 连接上同时发送 4 个请求。其中请求1 已经正确到达，并被应用层读取。但是请求2 的第三个 tcp包丢失了，为了保证数据的顺序，需要发送端重传第 3 个包才能通知应用层读取接下去的数据，虽然这个时候请求3 和请求4 的全部数据已经到达了接收端，但都被阻塞住了。
在这里插入图片描述
Quic基于UDP，各个请求之间相互独立，比如请求2 丢了一个 Pakcet，不会影响请求3 和请求4，不存在 TCP 队头阻塞。

四，Quic和http3

QUIC 协议最初是由Google发起的项目，后面慢慢成为了 HTTP/2-encrypted-over-UDP 协议。
当 IETF 开始进行协议标准化工作时，协议被分为两层：传输部分和 HTTP 部分。这个想法的初衷是考虑到该传输协议也可用于传输其他数据，而不仅仅用于 HTTP 协议。
社区中大家使用 iQUIC 和 gQUIC 这样的非正式名称来引用这些不同版本的协议，以便将IETF 和 Google提出的QUIC 协议分开。
通过 iQUIC 发送 HTTP 请求的协议被称为HTTP-over-QUIC，即HTTP3。