QUIC协议初探-iOS实践

关注

VIP免费原创最新推荐文章于 2026-09-07 16:51:49 发布 8k 阅读 AI 写同款· GEO 优化 ›

谷歌出品!读懂 QUIC 协议:更快、更高效的通信协议在TCP里，如果一个segment传递丢失，那么后续segment乱序到达，也不会被应用层使用，只到丢失的segment重传成功为止，因此TCP实现的HTTP2的多路复用能力受到制约。QUIC解决了上面的歧义问题。与采用Sequence Number 标记不同的是，其使用的Packet Number标记严格单调递增，如果 Packet N 丢失了，那么重传时 Packet 的标识不会是 N，而是比 N 大的数字，比如N+M，这样发送方接收到确认消息时就能方便地知道 ACK 对应的是原始请求还是重传请求。阅读详情

本文来自于腾讯Bugly公众号（weixinBugly），作者：emilymmwang,未经作者同意，请勿转载，原文地址：https://mp.weixin.qq.com/s/NbewZ1NU49qSjIcdFrpotw

| 导语本文主要介绍了QUIC协议，以及初步研究的过程，用实践证明了QUIC协议在iOS平台的可行性

1、QUIC介绍

（1）QUIC（Quick UDP Internet Connections）协议

是一种全新的基于UDP的web开发协议。可以用一个公式大致概括：

TCP + TLS + HTTP2 = UDP + QUIC + HTTP2’s API

从公式可看出：QUIC协议虽然是基于UDP，但它不但具有TCP的可靠性、拥塞控制、流量控制等，且在TCP协议的基础上做了一些改进，比如避免了队首阻塞；另外，QUIC协议具有TLS的安全传输特性，实现了TLS的保密功能，同时又使用更少的RTT建立安全的会话。

（2）QUIC协议的主要目的

是为了整合TCP协议的可靠性和UDP协议的速度和效率。

QUIC的维基百科页面的介绍：

QUIC是快速UDP网络连接（英语：Quick UDP Internet Connections）的缩写，这是一种实验性的传输层网络传输协议，由Google公司开发，在2013年实现。QUIC使用UDP协议，它在两个端点间创建连接，且支持多路复用连接。在设计之初，QUIC希望能够提供等同于SSL/TLS层级的网络安全保护，减少数据传输及创建连接时的延迟时间，双向控制带宽，以避免网络拥塞。Google希望使用这个协议来取代TCP协议，使网页传输速度加快，计划将QUIC提交至互联网工程任务小组（IETF），让它成为下一代的正式网络规范。

（3）QUIC的特性

1）低延迟连接的建立 (Connection Establishment Latency)

这对已建立的连接很有好处。

众所周知，建立一个TCP连接需要进行三次握手，这意味着每次连接都会产生额外的RTT，从而给每个连接增加了显著的延迟（如下图1所示）。

另外，如果还需要TLS协商来创建一个安全的、加密的https连接，那么就需要更多的RTT，无疑会产生更大的延迟（如下图所示）。
这里写图片描述

首次，QUIC协议可以在1个RTT中启动一个连接并且获取完成握手所需的必要信息。

QUIC 1 RTT

如果连接的是一个新的服务器，这时候client是没有server的任何信息的，当然也不知道用那种密钥交换算法，没有公钥信息，就不可能实现0 RTT握手，所以，对于新的QUIC连接至少需要1 RTT才能完成握手。

在QUIC中，服务器的配置是完全静态的，而且配置是有过期时间的，由于服务器配置是静态的，因而不是每个连接都需要重新进行签名操作，一个签名可以适用于多个连接。

另外，QUIC采用了两级密钥机制：初始密钥和会话密钥。QUIC在握手过程中使用Diffie-Hellman 算法协商初始密钥。初始密钥协商完毕后，服务器会提供一个临时随机数，会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效。

具体握手过程如图（图片引用daveywu的文章）所示：
这里写图片描述

QUIC 0 RTT

客户端在缓存了ServerConfig的情况下，客户端根据缓存的ServerConifg获取到密钥交换算法及公钥，同时生成一个全新的密钥，直接向服务器发送full Client hello消息，开始正式握手，消息中包括客户端选择的公开数。服务器收到full Client hello，不同意回复REJ；同意连接，则根据客户端的公开数计算出初始密钥，回复SHLO消息。

客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥。双方更换会话密钥通信，初始密钥已无用，至此，QUIC握手过程结束。

2）改进的拥塞控制 (Improved Congestion Control)
QUIC协议当前默认使用TCP协议的Cubic拥塞控制算法。看似QUIC协议只是吧TCP的拥塞算法重新实现了一遍，其实不然。QUIC协议在TCP拥塞算法基础上做了些改进：

1.可插拔

应用程序层面就能实现不同的拥塞控制算法，不需要操作系统或内核支持。
单个应用程序的不同连接也能支持配置不同的拥塞控制。
不需要停机和升级就能实现拥塞控制的变更。

2.单调递增的Packet Number

QUIC并没有使用TCP的基于字节序号及ACK来确认消息的有序到达，QUIC使用的是Packet Number，每个Packet Number严格递增，所以如果Packet N丢失了，重传Packet N的Packet Number已不是N，而是一个大于N的值。这样就很容易解决TCP的重传歧义问题。

3.更多的ACK块