如果你的 App,在不需要任何修改的情况下就能提升 15% 以上的访问速度。特别是弱网络的时候能够提升 20% 以上的访问速度。如果你的 App,在频繁切换 4G 和 WIFI 网络的情况下,不会断线,不需要重连,用户无任何感知。如果你的 App,既需要 TLS 的安全,也想实现 HTTP2 多路复用的强大。如果你刚刚才听说 HTTP2 是下一代互联网协议,如果你刚刚才关注到 TLS1.3 是一个革命性具有里程碑意义的协议,但是这两个协议却一直在被另一个更新兴的协议所影响和挑战。如果这个新兴的协议,它的名字就叫做“快”,并且正在标准化为新一代的互联网传输协议。你愿意花一点点时间了解这个协议吗?你愿意投入精力去研究这个协议吗?你愿意全力推动业务来使用这个协议吗?
目录
QUIC是什么?
QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于 UDP 的传输协议,它实现了 TCP + HTTPS + HTTP/2 的功能,目的是保证可靠性的同时降低网络延迟。因为 UDP 是一个简单传输协议,基于 UDP 可以摆脱 TCP 传输确认、重传慢启动等因素,建立安全连接只需要一的个往返时间,它还实现了 HTTP/2 多路复用、头部压缩等功能。
QUIC协议是一系列协议的集合,主要包括:
- 传输协议(Transport)
- 丢包检测与拥塞控制(Recovery)
- 安全传输协议(TLS)
- HTTP3协议
- HTTP头部压缩协议(QPACK)
- 负载均衡协议(Load Balance)
众所周知 UDP 比 TCP 传输速度快,TCP 是可靠协议,但是代价是双方确认数据而衍生的一系列消耗。其次 TCP 是系统内核实现的,如果升级 TCP 协议,就得让用户升级系统,这个的门槛比较高,而 QUIC 在 UDP 基础上由客户端自由发挥,只要有服务器能对接就可以。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势:
- 减少了 TCP 三次握手及 TLS 握手时间
- 改进的拥塞控制
- 避免队头阻塞的多路复用
- 连接迁移
- 前向冗余纠错
HTTP 协议发展
HTTP 历史进程
- HTTP 0.9(1991 年)只支持 get 方法不支持请求头;
- HTTP 1.0(1996 年)基本成型,支持请求头、富文本、状态码、缓存、连接无法复用;
- HTTP 1.1(1999 年)支持连接复用、分块发送、断点续传;
- HTTP 2.0(2015 年)二进制分帧传输、多路复用、头部压缩、服务器推送等;
- HTTP 3.0(2018 年)QUIC 于 2013 年实现;2018 年 10 月,IETF 的 HTTP 工作组和 QUIC 工作组共同决定将 QUIC 上的 HTTP 映射称为 “HTTP/3”,以提前使其成为全球标准。
HTTP1.0 和 HTTP1.1
- 队头阻塞:下个请求必须在前一个请求返回后才能发出,导致带宽无法被充分利用,后续请求被阻塞(HTTP 1.1 尝试使用流水线(Pipelining)技术,但先天 FIFO(先进先出)机制导致当前请求的执行依赖于上一个请求执行的完成,容易引起队头阻塞,并没有从根本上解决问题);
- 协议开销大:header 里携带的内容过大,且不能压缩,增加了传输的成本;
- 单向请求:只能单向请求,客户端请求什么,服务器返回什么;
- HTTP 1.0 和 HTTP 1.1 的区别:
- HTTP 1.0:仅支持保持短暂的 TCP 连接(连接无法复用);不支持断点续传;前一个请求响应到达之后下一个请求才能发送,存在队头阻塞。
- HTTP 1.1:默认支持长连接(请求可复用 TCP 连接);支持断点续传(通过在 Header 设置参数);优化了缓存控制策略;管道化,可以一次发送多个请求,但是响应仍是顺序返回,仍然无法解决队头阻塞的问题;新增错误状态码通知;请求消息和响应消息都支持 Host 头域
HTTP2
解决 HTTP1 的一些问题,但是解决不了底层 TCP 协议层面上的队头阻塞问题。
- 二进制传输:二进制格式传输数据解析起来比文本更高效;
- 多路复用:重新定义底层 http 语义映射,允许同一个连接上使用请求和响应双向数据流。同一域名只需占用一个 TCP 连接,通过数据流(Stream)以帧为基本协议单位,避免了因频繁创建连接产生的延迟,减少了内存消耗,提升了使用性能,并行请求,且慢的请求或先发送的请求不会阻塞其他请求的返回;
- Header 压缩:减少请求中的冗余数据,降低开销;
- 服务端可以主动推送:提前给客户端推送必要的资源,这样就可以相对减少一点延迟时间;
- 流优先级:数据传输优先级可控,使网站可以实现更灵活和强大的页面控制;
- 可重置:能在不中断 TCP 连接的情况下停止数据的发送。
缺点:HTTP 2中,多个请求在一个 TCP 管道中的,出现了丢包时,HTTP 2的表现反倒不如HTTP 1.1。因为 TCP 为了保证可靠传输,有个特别的“丢包重传”机制,丢失的包必须要等待重新传输确认,HTTP 2出现丢包时,整个 TCP 都要开始等待重传,那么就会阻塞该 TCP 连接中的所有请求。而对于HTTP 1.1来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
HTTP3 —— HTTP Over QUIC
HTTP 是建立在 TCP 协议之上,所有 HTTP 协议的瓶颈及其优化技巧都是基于 TCP 协议本身的特性,HTTP2 虽然实现了多路复用,底层 TCP 协议层面上的问题并没有解决(HTTP 2.0 同一域名下只需要使用一个 TCP 连接。但是如果这个连接出现了丢包,会导致整个 TCP 都要开始等待重传,后面的所有数据都被阻塞了),而 HTTP3 的 QUIC 就是为解决 HTTP2 的 TCP 问题而生。
QUIC/HTTP3的特点:
- 有序传输:用stream的概念,确保数据有序。不同的stream或者packet,不保证有序到达。
- 报文压缩,提高荷载比率:比如QUIC引入了variable-length integer encoding。又比如引入QPACK进行头部压缩
- 可靠传输:支持丢包检测和重传
- 安全传输:TLS 1.3安全协议
为什么需要 QUIC?
随着移动互联网快速发展以及物联网的逐步兴起,网络交互的场景越来越丰富,网络传输的内容也越来越庞大,用户对网络传输效率和 WEB 响应速度的要求也越来越高。
一方面是历史悠久使用广泛的古老协议,另外一方面用户的使用场景对传输性能的要求又越来越高。如下几个由来已久的问题和矛盾就变得越来越突出。
中间设备的僵化
可能是 TCP 协议使用得太久,也非常可靠。所以我们很多中间设备,包括防火墙、NAT 网关,整流器等出现了一些约定俗成的动作。
比如有些防火墙只允许通过 80 和 443,不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部,有可能导致双方无法使用新的传输格式。整流器和中间代理有时候出于安全的需要,会删除一些它们不认识的选项字段。
TCP 协议本来是支持端口、选项及特性的增加和修改。但是由于 TCP 协议和知名端口及选项使用的历史太悠久,中间设备已经依赖于这些潜规则,所以对这些内容的修改很容易遭到中间环节的干扰而失败。
而这些干扰,也导致很多在 TCP 协议上的优化变得小心谨慎,步履维艰。
依赖于操作系统的实现导致协议僵化
TCP 是由操作系统在内核西方栈层面实现的,应用程序只能使用,不能直接修改。虽然应用程序的更新迭代非常快速和简单。但是 TCP 的迭代却非常缓慢,原因就是操作系统升级很麻烦。
现在移动终端更加流行,但是移动端部分用户的操作系统升级依然可能滞后数年时间。PC 端的系统升级滞后得更加严重,windows xp现在还有大量用户在使用,尽管它已经存在快 20 年。
服务端系统不依赖用户升级,但是由于操作系统升级涉及到底层软件和运行库的更新,所以也比较保守和缓慢。
这也就意味着即使 TCP 有比较好的特性更新,也很难快速推广。比如 TCP Fast Open。它虽然 2013 年就被提出了,但是 Windows 很多系统版本依然不支持它。
QUIC 的关键特性
连接迁移
tcp 的连接重连之痛
一条 TCP 连接是由四元组标识的(源 IP,源端口,目的 IP,目的端口)。什么叫连接迁移呢?就是当其中任何一个元素发生变化时,这条连接依然维持着,能够保持业务逻辑不中断。当然这里面主要关注的是客户端的变化,因为客户端不可控并且网络环境经常发生变化,而服务端的 IP 和端口一般都是固定的。
比如大家使用手机在 WIFI 和 4G 移动网络切换时,客户端的 IP 肯定会发生变化,需要重新建立和服务端的 TCP 连接。又比如大家使用公共 NAT 出口时,有些连接竞争时需要重新绑定端口,导致客户端的端口发生变化,同样需要重新建立 TCP 连接。所以从 TCP 连接的角度来讲,这个问题是无解的。
基于 UDP 的 QUIC 的连接迁移实现
那 QUIC 是如何做到连接迁移呢?很简单,QUIC 是基于 UDP 协议的,任何一条 QUIC 连接不再以 IP 及端口四元组标识,而是以一个 64 位的随机数作为 ID 来标识,这样就算 IP 或者端口发生变化时,只要 ID 不变,这条连接依然维持着,上层业务逻辑感知不到变化,不会中断,也就不需要重连。由于这个 ID 是客户端随机产生的,并且长度有 64 位,所以冲突概率非常低。
低连接延时
0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢?这里面有两层含义。
- 传输层 0RTT 就能建立连接。
- 加密层 0RTT 就能建立加密连接。
比如上图左边是 HTTPS 的一次完全握手的建连过程,需要 3 个 RTT。就算是 Session Resumption,也需要至少 2 个 RTT。
而 QUIC 呢?由于建立在 UDP 的基础上,同时又实现了 0RTT 的安全握手,所以在大部分情况下,只需要 0 个 RTT 就能实现数据发送,在实现前向加密的基础上,并且 0RTT 的成功率相比 TLS 的 Sesison Ticket要高很多。
TLS 的连接时延问题
以一次简单的浏览器访问为例,在地址栏中输入https://www.abc.com,实际会产生以下动作:
- DNS 递归查询abc.com,获取地址解析的对应 IP;
- TCP 握手,我们熟悉的 TCP 三次握手需要需要 1 个 RTT;
- TLS 握手,以目前应用最广泛的 TLS 1.2 而言,需要 2 个 RTT。对于非首次建连,可以选择启用会话重用,则可缩小握手时间到 1 个 RTT;
- HTTP 业务数据交互,假设com 的数据在一次交互就能取回来。那么业务数据的交互需要 1 个 RTT;经过上面的过程分析可知,要完成一次简短的 HTTPS 业务数据交互,需要经历:新连接4RTT + DNS;会话重用 3RTT + DNS。
所以,对于数据量小的请求而言,单一次的请求握手就占用了大量的时间,对于用户体验的影响非常大。同时,在用户网络不佳的情况下,RTT 延时会变得较高,极其影响用户体验。
下图对比了 TLS 各版本与场景下的延时对比:
从对比我们可以看到,即使用上了 TLS 1.3,精简了握手过程,最快能做到 0-RTT 握手(首次是 1-RTT);但是对用户感知而言, 还要加上 1RTT 的 TCP 握手开销。Google 有提出 Fastopen 的方案来使得 TCP 非首次握手就能附带用户数据,但是由于 TCP 实现僵化,无法升级应用,相关 RFC 到现今都是 experimental 状态。这种分层设计带来的延时,有没有办法进一步降低呢? QUIC 通过合并加密与连接管理解决了这个问题,我们来看看其是如何实现真正意义上的 0-RTT 的握手, 让与 server 进行第一个数据包的交互就能带上用户数据。
真·0-RTT 的 QUIC 握手
QUIC 由于基于 UDP,无需 TCP 连接,在最好情况下,短连接下 QUIC 可以做到 0RTT 开启数据传输。而基于 TCP 的 HTTPS,即使在最好的 TLS1.3 的 early data 下仍然需要 1RTT 开启数据传输。而对于目前线上常见的 TLS1.2 完全握手的情况,则需要 3RTT 开启数据传输。对于 RTT 敏感的业务,QUIC 可以有效的降低连接建立延迟。
究其原因一方面是 TCP 和 TLS 分层设计导致的:分层的设计需要每个逻辑层次分别建立自己的连接状态。另一方面是 TLS 的握手阶段复杂的密钥协商机制导致的。要降低建连耗时,需要从这两方面着手。
QUIC 具体握手过程如下:
- 客户端判断本地是否已有服务器的全部配置参数(证书配置信息),如果有则直接跳转到(5),否则继续;
- 客户端向服务器发送 inchoate client hello(CHLO)消息,请求服务器传输配置参数;
- 服务器收到 CHLO,回复 rejection(REJ)消息,其中包含服务器的部分配置参数;
- 客户端收到 REJ,提取并存储服务器配置参数,跳回到(1) ;
- 客户端向服务器发送 full client hello 消息,开始正式握手,消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数,可以计算出初始密钥 K1;
- 服务器收到 full client hello,如果不同意连接就回复 REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥 K1,回复 server hello(SHLO)消息,SHLO 用初始密钥 K1 加密,并且其中包含服务器选择的一个临时公开数;
- 客户端收到服务器的回复,如果是 REJ 则情况同(4);如果是 SHLO,则尝试用初始密钥 K1 解密,提取出临时公开数;
- 客户端和服务器根据临时公开数和初始密钥 K1,各自基于 SHA-256 算法推导出会话密钥 K2;
- 双方更换为使用会话密钥 K2 通信,初始密钥 K1 此时已无用,QUIC 握手过程完毕。之后会话密钥 K2 更新的流程与以上过程类似,只是数据包中的某些字段略有不同。
可自定义的拥塞控制
Quic 使用可插拔的拥塞控制,相较于 TCP,它能提供更丰富的拥塞控制信息。比如对于每一个包,不管是原始包还是重传包,都带有一个新的序列号(seq),这使得 Quic 能够区分 ACK 是重传包还是原始包,从而避免了 TCP 重传模糊的问题。Quic 同时还带有收到数据包与发出 ACK 之间的时延信息。这些信息能够帮助更精确的计算 rtt。此外,Quic 的 ACK Frame 支持 256 个 NACK 区间,相比于 TCP 的 SACK(Selective Acknowledgment)更弹性化,更丰富的信息会让 client 和 server 哪些包已经被对方收到。
QUIC 的传输控制不再依赖内核的拥塞控制算法,而是实现在应用层上,这意味着我们根据不同的业务场景,实现和配置不同的拥塞控制算法以及参数。GOOGLE 提出的 BBR 拥塞控制算法与 CUBIC 是思路完全不一样的算法,在弱网和一定丢包场景,BBR 比 CUBIC 更不敏感,性能也更好。在 QUIC 下我们可以根据业务随意指定拥塞控制算法和参数,甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。
TCP 的拥塞控制实际上包含了四个算法:慢启动,拥塞避免,快速重传,快速恢复。
QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法,同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
从拥塞算法本身来看,QUIC 只是按照 TCP 协议重新实现了一遍,那么 QUIC 协议到底改进在哪些方面呢?主要有如下几点:
可插拔
什么叫可插拔呢?就是能够非常灵活地生效,变更和停止。体现在如下方面:
- 应用程序层面就能实现不同的拥塞控制算法,不需要操作系统,不需要内核支持。这是一个飞跃,因为传统的 TCP 拥塞控制,必须要端到端的网络协议栈支持,才能实现控制效果。而内核和操作系统的部署成本非常高,升级周期很长,这在产品快速迭代,网络爆炸式增长的今天,显然有点满足不了需求。
- 即使是单个应用程序的不同连接也能支持配置不同的拥塞控制。就算是一台服务器,接入的用户网络环境也千差万别,结合大数据及人工智能处理,我们能为各个用户提供不同的但又更加精准更加有效的拥塞控制。比如 BBR 适合,Cubic 适合。
- 应用程序不需要停机和升级就能实现拥塞控制的变更,我们在服务端只需要修改一下配置,reload 一下,完全不需要停止服务就能实现拥塞控制的切换。
单调递增的 Packet Number
TCP 为了保证可靠性,使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。
QUIC 同样是一个可靠的协议,它使用 Packet Number 代替了 TCP 的 sequence number,并且每个 Packet Number 都严格递增,也就是说就算 Packet N 丢失了,重传的 Packet N 的 Packet Number 已经不是 N,而是一个比 N 大的值。而 TCP 呢,重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变,也正是由于这个特性,引入了 Tcp 重传的歧义问题。
如上图所示,超时事件 RTO 发生后,客户端发起重传,然后接收到了 Ack 数据。由于序列号一样,这个 Ack 数据到底是原始请求的响应还是重传请求的响应呢?不好判断。
如果算成原始请求的响应,但实际上是重传请求的响应(上图左),会导致采样 RTT 变大。如果算成重传请求的响应,但实际上是原始请求的响应,又很容易导致采样 RTT 过小。
由于 Quic 重传的 Packet 和原始 Packet 的 Pakcet Number 是严格递增的,所以很容易就解决了这个问题。
如上图所示,RTO 发生后,根据重传的 Packet Number 就能确定精确的 RTT 计算。如果 Ack 的 Packet Number 是 N+M,就根据重传请求计算采样 RTT。如果 Ack 的 Pakcet Number 是 N,就根据原始请求的时间计算采样 RTT,没有歧义性。
但是单纯依靠严格递增的 Packet Number 肯定是无法保证数据的顺序性和可靠性。QUIC 又引入了一个 Stream Offset 的概念。
即一个 Stream 可以经过多个 Packet 传输,Packet Number 严格递增,没有依赖。但是 Packet 里的 Payload 如果是 Stream 的话,就需要依靠 Stream 的 Offset 来保证应用数据的顺序。如错误! 未找到引用源。所示,发送端先后发送了 Pakcet N 和 Pakcet N+1,Stream 的 Offset 分别是 x 和 x+y。
假设 Packet N 丢失了,发起重传,重传的 Packet Number 是 N+2,但是它的 Stream 的 Offset 依然是 x,这样就算 Packet N + 2 是后到的,依然可以将 Stream x 和 Stream x+y 按照顺序组织起来,交给应用程序处理。
不允许 Reneging
什么叫 Reneging 呢?就是接收方丢弃已经接收并且上报给 SACK 选项的内容。TCP 协议不鼓励这种行为,但是协议层面允许这样的行为。主要是考虑到服务器资源有限,比如 Buffer 溢出,内存不够等情况。
Reneging 对数据重传会产生很大的干扰。因为 Sack 都已经表明接收到了,但是接收端事实上丢弃了该数据。
QUIC 在协议层面禁止 Reneging,一个 Packet 只要被 Ack,就认为它一定被正确接收,减少了这种干扰。
更多的 Ack 块
TCP 的 Sack 选项能够告诉发送方已经接收到的连续 Segment 的范围,方便发送方进行选择性重传。
由于 TCP 头部最大只有 60 个字节,标准头部占用了 20 字节,所以 Tcp Option 最大长度只有 40 字节,再加上 Tcp Timestamp option 占用了 10 个字节 [25],所以留给 Sack 选项的只有 30 个字节。
每一个 Sack Block 的长度是 8 个,加上 Sack Option 头部 2 个字节,也就意味着 Tcp Sack Option 最大只能提供 3 个 Block。
但是 Quic Ack Frame 可以同时提供 256 个 Ack Block,在丢包率比较高的网络下,更多的 Sack Block 可以提升网络的恢复速度,减少重传量。
Ack Delay 时间
Tcp 的 Timestamp 选项存在一个问题 [25],它只是回显了发送方的时间戳,但是没有计算接收端接收到 segment 到发送 Ack 该 segment 的时间。这个时间可以简称为 Ack Delay。
这样就会导致 RTT 计算误差。如下图:
可以认为 TCP 的 RTT 计算:$RTT=timestamp2-timestamp1$
而 Quic 计算如下:$RTT=timestamp2-timestamp1-AckDelay$
当然 RTT 的具体计算没有这么简单,需要采样,参考历史数值进行平滑计算,参考如下公式:
$$SRTT=SRTT+\alpha(RTT-SRTT)$$
$$RTO=\mu * SRTT + \partial * DevRTT$$
无队头阻塞
TCP 的队头阻塞问题
虽然 HTTP2 实现了多路复用,但是因为其基于面向字节流的 TCP,因此一旦丢包,将会影响多路复用下的所有请求流。QUIC 基于 UDP,在设计上就解决了队头阻塞问题。
TCP 队头阻塞的主要原因是数据包超时确认或丢失阻塞了当前窗口向右滑动,我们最容易想到的解决队头阻塞的方案是不让超时确认或丢失的数据包将当前窗口阻塞在原地。QUIC 也正是采用上述方案来解决 TCP 队头阻塞问题的。
TCP 为了保证可靠性,使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。
如上图,应用层可以顺利读取 stream1 中的内容,但由于 stream2 中的第三个 segment 发生了丢包,TCP 为了保证数据的可靠性,需要发送端重传第 3 个 segment 才能通知应用层读取接下去的数据。所以即使 stream3 stream4 的内容已顺利抵达,应用层仍然无法读取,只能等待 stream2 中丢失的包进行重传。
在弱网环境下,HTTP2 的队头阻塞问题在用户体验上极为糟糕。
QUIC 的无队头阻塞解决方案
QUIC 同样是一个可靠的协议,它使用 Packet Number 代替了 TCP 的 Sequence Number,并且每个 Packet Number 都严格递增,也就是说就算 Packet N 丢失了,重传的 Packet N 的 Packet Number 已经不是 N,而是一个比 N 大的值,比如 Packet N+M。
QUIC 使用的 Packet Number 单调递增的设计,可以让数据包不再像 TCP 那样必须有序确认,QUIC 支持乱序确认,当数据包 Packet N 丢失后,只要有新的已接收数据包确认,当前窗口就会继续向右滑动。待发送端获知数据包 Packet N 丢失后,会将需要重传的数据包放到待发送队列,重新编号比如数据包 Packet N+M 后重新发送给接收端,对重传数据包的处理跟发送新的数据包类似,这样就不会因为丢包重传将当前窗口阻塞在原地,从而解决了队头阻塞问题。那么,既然重传数据包的 Packet N+M 与丢失数据包的 Packet N 编号并不一致,我们怎么确定这两个数据包的内容一样呢?
QUIC 使用 Stream ID 来标识当前数据流属于哪个资源请求,这同时也是数据包多路复用传输到接收端后能正常组装的依据。重传的数据包 Packet N+M 和丢失的数据包 Packet N 单靠 Stream ID 的比对一致仍然不能判断两个数据包内容一致,还需要再新增一个字段 Stream Offset,标识当前数据包在当前 Stream ID 中的字节偏移量。
有了 Stream Offset 字段信息,属于同一个 Stream ID 的数据包也可以乱序传输了(HTTP/2 中仅靠 Stream ID 标识,要求同属于一个 Stream ID 的数据帧必须有序传输),通过两个数据包的 Stream ID 与 Stream Offset 都一致,就说明这两个数据包的内容一致。
QUIC 协议组成
QUIC是在UDP的基础上,构建类似TCP的可靠传输协议。HTTP3则在QUIC基础上完成HTTP事务。网络总是分层讨论的,在此我们由低向上分层讨论quic协议:
- UDP层: 在UDP层传输的是UDP报文,此处关注的是UDP报文荷载内容是什么,以及如何高效发送UDP报文
- Connection层: Connection通过CID来确认唯一连接,connection对packet进行可靠传输和安全传输
- Stream层: Stream在相应的Connection中,通过StreamID进行唯一流确认,stream对stream frame进行传输管理
- HTTP3层:HTTP3建立在QUIC Stream的基础上,相对于1和HTTP2.0,HTTP3提供更有效率的HTTP事务传输。HTTP3中通过QPACK协议进行头部压缩
UDP层
本章节讨论QUIC发包的UDP部分的相关问题。
UDP荷载大小
荷载大小受限于3个对象:QUIC协议规定;路径MTU;终端接受能力
- QUIC不能运行在不支持1200字节的单个UDP传输网络路径上 QUIC有规定initial包大小不得小于1200,如果数据本身不足1200(比如initial ack),那么需要用padding方式至少填充到1200字节
- QUIC不希望出现IP层分片现象本要求意味着udp交给ip层的数据不会大于1个MTU,假设mtu为1500,ipv4场景下,udp的荷载上限为1472字节(1500-20-8),ipv6下,udp荷载上限为1452(1500-40-8)。QUIC建议使用PMTUD以及DPLPMTUD进行mtu探测。在实战中,我们建议设置IPv6的MTU为1280,大于这个值,某些网络会存在丢包现象。
- 终端能接受 transport paraments的max_udp_payload_size(0x03)的是终端接受单个udp包大小的能力,发送端应当遵从这一约定。
UDP荷载内容
- UDP荷载内容即为quic协议中的packet。协议规定,如果不超过荷载大小的限制,那么多个packet可以组成一个udp报文发出去。在quic实现中,如果每个udp报文只包含一个quic packet,会更容易出现乱序问题。
高效发UDP包
和tcp不同,quic需要在应用层就完成udp数据组装,且每个udp报文不大于1个mtu,如果不加以优化,比如每个包直接用sendto/sendmsg发送,势必会造成大量的系统调用,影响吞吐
- 通过sendmmsg接口进行优化,sendmmsg可以将用户态的多个udp quic包通过一次系统调用发到内核态。内核态对于每个udp quic包独立作为udp包发出去
- 在)解决了系统调用次数问题,开启GSO可以进步一分包延迟到发给网卡驱动前一刻,可以进一步提高吞吐,降低CPU消耗
- 在)的基础上,现在主流网卡已经支持硬件GSO offload方案,可以进一步提高吞吐,降低cpu消耗
上面介绍的发送方式,事实上可以理解为udp burst发送方式,这带来了一个问题,拥塞控制需要pacing能力!
Connection层
在我们讨论时,可知1个udp报文里传输的其实是一个或多个quic协议定义的packet。那么在Connection这一层面,其实是以packet为单位进行管理的。一个packet到来,终端需要解析出目标ConnectionID(DCID)字段,并将该packet交给找到对应的quic connection。一个packet是由header加payload两部分组成。
connection id
不同于tcp的4元组唯一确认一条连接的方式,QUIC定义了一个和网络路由无关的ConnectionID来确认唯一连接的。这带来一个好处,可以在四元组发生变化时(比如nat rebinding或者终端网络切换wifi->4G),依然保持连接。当然,虽然连接状态依然保持,但由于路径发生变化,拥塞控制也需要能够及时调整。
packet头部
IETF的quic header分为两种类型,long header, short header。其中long header有分为 initial, 0rtt, handshake, retry四种类型。类型的定义可以直接参考rfc文档,此处不再赘述。
quic规定packet number始终为自增的,就算某个packet的内容为重传的frame数据,其packet number也必须自增,这相对于TCP来说,带来一个优点,能够更加精确的采集到路径的RTT属性。
packet number编解码: packet number是一个0~262 -1的取值范围,quic为了节约空间,在计算packet number时,引入了unacked的概念,通过截断(只保留有效bit位)的方式,只用了1-4个字节,即可以encode/decode出正确的packet number。rfc文档中有附录详细讲解了enc/dec的过程。
packet头在安全传输中是被保护对象,这也意味着在没有ssl信息的情况下,无法使用wireshake对packet进行时序分析。中间网络设备也无法向TCP那样获得packet number进行乱序重组。
packet荷载
在对packet进行解密,且去除掉packet header后,packet的荷载里就都是frame了(至少包括1个)。
如果packet的荷载里,不包括ACK, PADDING, and CONNECTION_CLOSE这种三种类型的帧,那么这个packet则被定义为ack-eliciting,意味着对端必须对这种packet生成相应的ack通知发送方,以确保数据没有丢失。
packet的荷载里frames的类型在多达30种类型,每种类型都有自己的应用场景,如ACK Frame用于可靠传输(Recovery),Crypto用于安全传输(TLS握手),Stream Frame用于业务数据传递,MAX_DATA/DATA_BLOCKED用于流控,PING Frame可以用于mtu探测,具体描述参考rfc文档。
安全传输
QUIC的安全传输依赖TLS1.3,而boringssl是众多quic实现的依赖库。协议对Packet的头部以及荷载均进行了保护(包括packet number)。TLS1.3 0RTT的能力,在提供数据保护的同时,能在第一时间(服务端收到第一个请求报文时)就将Response Header发给客户端。大大降低了HTTP业务中的首包时间。为了支持0RTT,客户端需要保存PSK信息,以及部分transport parament信息。
安全传输也经常会涉及到性能问题,在目前主流的服务端,AESG由于cpu提供了硬件加速,所以性能表现最好。CHACHA20则需要更多的CPU资源。在短视频业务上,出于对首帧的要求,通常直接使用明文传输。
Transport Paramenter(TP)协商是在安全传输的握手阶段完成,除了协议规定的TP外,用户也可以扩展私有TP内容,这一特性带来了很大的便利,比如:客户端可以利用tp告知服务端进行明文传输。
可靠传输
QUIC协议是需要像TCP能够进行可靠传输,所以QUIC单独有一个rfc描述了丢包检测和拥塞控制的话题,
丢包检测:协议利用两种方式来判断丢包是否发生:一种是基于ack的检测,通过time threshold和packet threshold根据已经到达的packet,推断在此包之前发出去的包是否丢失。第二种,在失去了参考包的情况下,那么只能通过PTO的方式来推断包是否丢失。一般来说,大量被触发的应该是ACK的检测方式。如果PTO被大量触发,会影响发包效率。
拥塞控制:QUIC针对TCP协议中的一些缺陷,专门做了优化。比如始终递增的packet number,丰富的ack range,host delay计算等。同时tcp的拥塞控制需要内核态实现,而QUIC在用户态实现,这大大降低了研究高效率的可靠传输协议的门槛。Recovery协议中,描述了newReno的实现方式。在GOOGLE chrome中,实现了cubic, bbr, bbrv2,而mvfst项目则更为丰富,包括了ccp, copa协议。
Stream层
stream是一个抽象的概念,它表达了一个有序传输的字节流,而这些字节其实就是由Stream Frame排在一起构成。在一个quic connection上,可以同时传输多条流。
Stream头部
在Quic协议里,stream分为单向流或双向流,又分为客户端发起或服务端发起。stream的不同类型定义在HTTP3中得到了充分的利用。
Stream荷载
Stream的荷载即为一系列Stream Frame,通过Stream Frame头部的Stream ID来确认单个流。
在TCP里,如果一个segment传递丢失,那么后续segment乱序到达,也不会被应用层使用,只到丢失的segment重传成功为止,因此TCP实现的HTTP2的多路复用能力受到制约。在QUIC协议中,有序的概念仅维护在单个stream中,stream之间和packet都不要求有序,假设某个packet丢失,只会影响包含在这个包里的stream,其他stream仍然可以从后续乱序到达的packet中提取到自己所需要的数据交给应用层。
HTTP3层
stream分类
在引入HTTP3后,stream的单向流类型被扩展成:控制流,Push流和其他保留类型。其中HTTP3的setting则是在控制流中传输,而HTTP数据传输是在客户端发起的双向流中,所以读者会发现,HTTP数据传输的stream id都是模4等于0的。
在引入QPACK后,单向流被进一步扩展了两个类型,encoder流,decoder流,QPACK中动态表的更新则依赖这两个流。
QPACK
QPACK的作用是头部压缩。类似HPACK,QPACK定义了静态表,动态表用于头部索引。静态表是针对常见的头部,协议预先定义的。动态表则是在该QUIC Connection服务HTTP过程中,逐渐建立的。QPACK所建立的Encoder/Decoder流是伴随用于HTTP事务的QUIC Connection生命周期。
动态表不是HTTP3能够运行的必须项,所以在某些QUIC开源项目中,并没有实现复杂的动态表功能。
在QPACK的动态表业务中,数据流,编码流,解码流3种对象共同参与,编码流和解码流负责维护动态表变化,数据流则解析出头部的索引号,去动态表中查询,得到最终的头部定义。
其他
Flow Control 流控
QUIC协议引入了flow control的概念,用于表达接收端的接受能力。流控分两级,Connection级别,和Stream级别。发送端发送的数据偏移量不能超过流控的限制,如果达到限制,那么发送端应该通过 DATA_BLOCKED/STREAM_DATA_BLOCKED来通知接收端。如果为了传输性能,接收端应该尽量保持限制足够大,比如达到max_data的一半时,就及时更新max_data传给发送端。如果接收端不希望太快接受数据,也可以利用流控对发送端进行约束。
QUIC版本
QUIC一开始由google主导设计开发,在chromium项目中,可以看到google quic(GQUIC)版本号被定义为Q039,Q043,Q046,Q050等。
随着IETF版本的QUIC推出,ietf quic(IQUIC)也有很多版本,如29,30,34(最新版)等,不同版本可能是无法互通的,比如不同版本安全传输的salt变量规定不一样。所以IQUIC引入了版本协商的功能,用于不同的客户端和服务端协商出可以互通的版本。
在实践中,还会遇到一个需求,要求一个服务能够同时服务GQUIC的不同版本,又能服务IQUIC的不同版本。这就要求服务在收取到packet后,需要对packet作出判断,分析出它属于iquic的,还是gquic的,然后进行逻辑分流。
QUIC 的 packet 除了个别报文比如 PUBLIC_RESET 和 CHLO,所有报文头部都是经过认证的,报文 Body 都是经过加密的。这样只要对 QUIC 报文任何修改,接收端都能够及时发现,有效地降低了安全风险。
如图所示,红色部分是 Stream Frame 的报文头部,有认证。绿色部分是报文内容,全部经过加密。
- Flags: 用于表示 Connection ID 长度、Packet Number 长度等信息;
- Connection ID:客户端随机选择的最大长度为 64 位的无符号整数。但是,长度可以协商;
- QUIC Version:QUIC 协议的版本号,32 位的可选字段。如果 Public Flag & FLAG_VERSION != 0,这个字段必填。客户端设置 Public Flag 中的 Bit0 为 1,并且填写期望的版本号。如果客户端期望的版本号服务端不支持,服务端设置 Public Flag 中的 Bit0 为 1,并且在该字段中列出服务端支持的协议版本(0 或者多个),并且该字段后不能有任何报文;
- Packet Number:长度取决于 Public Flag 中 Bit4 及 Bit5 两位的值,最大长度 6 字节。发送端在每个普通报文中设置 Packet Number。发送端发送的第一个包的序列号是 1,随后的数据包中的序列号的都大于前一个包中的序列号;
- Stream ID:用于标识当前数据流属于哪个资源请求;
- Offset:标识当前数据包在当前 Stream ID 中的字节偏移量。
QUIC 报文的大小需要满足路径 MTU 的大小以避免被分片。当前 QUIC 在 IPV6 下的最大报文长度为 1350,IPV4 下的最大报文长度为 1370。
QUIC应用场景
- 图片小文件:明显降低文件下载总耗时,提升效率
- 视频点播:提升首屏秒开率,降低卡顿率,提升用户观看体验
- 动态请求:适用于动态请求,提升访问速度,如网页登录、交易等交互体验提升
- 弱网环境:在丢包和网络延迟严重的情况下仍可提供可用的服务,并优化卡顿率、请求失败率、秒开率、提高连接成功率等传输指标
- 大并发连接:连接可靠性强,支持页面资源数较多、并发连接数较多情况下的访问速率提升
- 加密连接:具备安全、可靠的传输性能
参考链接: