简介： 家喻户晓，QUIC（Quick UDP Internet Connection）是谷歌制订的一种互联网传输层协定，它基于 UDP 传输层协定，同时兼具 TCP、TLS、HTTP/ 2 等协定的可靠性与安全性，能够无效缩小连贯与传输提早，更好地应答以后传输层与应用层的挑战。目前阿里云 CDN 线上提供 GQUIC 版本服务，曾经有 Tbps 级别的流量承载，并对客户来带了显著的提早收益。本文将由低向上分层探讨 QUIC 协定的特点。
家喻户晓，QUIC（Quick UDP Internet Connection）是谷歌制订的一种互联网传输层协定，它基于 UDP 传输层协定，同时兼具 TCP、TLS、HTTP/ 2 等协定的可靠性与安全性，能够无效缩小连贯与传输提早，更好地应答以后传输层与应用层的挑战。目前阿里云 CDN 线上提供 GQUIC 版本服务，曾经有 Tbps 级别的流量承载，并对客户来带了显著的提早收益。本文将由低向上分层探讨 QUIC 协定的特点。
作者：黎叔
QUIC 协定是一系列协定的汇合，次要包含：
- 传输协定（Transport）
- 丢包检测与拥塞管制（Recovery)
- 平安传输协定（TLS)
- HTTP3 协定
- HTTP 头部压缩协定（QPACK)
- 负载平衡协定（Load Balance)
本文针对 QUIC 的系列协定进行科普性简略介绍，细节读者依然须要通读协定原文。本文基于 quic 的探讨均基于 quic-34 系列版本。
QUIC 协定相似快递公司，在收到用户数据后，将数据打包，传输到对端，再进行拆包，将用户数据交给了最终目标用户。QUIC 是基于 UDP 协定，实现了相似 TCP 的牢靠传输，并在此基础上，联合 HTTP3/QPACK，更好地服务互联网上海量的 HTTP Request/Response 需要。如其名发音，QUIC(quick)，其指标就是心愿比基于 TCP 的 HTTP 交互有更好的体验。
QUIC/HTTP3 的特点：
- 有序传输：用 stream 的概念，确保数据有序。不同的 stream 或者 packet，不保障有序达到。
- 报文压缩，进步荷载比率：比方 QUIC 引入了 variable-length integer encoding。又比方引入 QPACK 进行头部压缩
- 牢靠传输：反对丢包检测和重传
- 平安传输：TLS 1.3 平安协定
分层的协定
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 的根底上，绝对于 HTTP1.1 和 HTTP2.0，HTTP3 提供更有效率的 HTTP 事务传输。HTTP3 中通过 QPACK 协定进行头部压缩
UDP 层
本章节探讨 QUIC 发包的 UDP 局部的相干问题。
UDP 荷载大小
荷载大小受限于 3 个对象：QUIC 协定规定；门路 MTU；终端承受能力
1、QUIC 不能运行在不反对 1200 字节的单个 UDP 传输网络门路上 QUIC 有规定 initial 包大小不得小于 1200，如果数据自身有余 1200（比方 initial ack)，那么须要用 padding 形式至多填充到 1200 字节
2、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，大于这个值，某些网络会存在丢包景象。
3、终端能承受 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 发送，势必会造成大量的零碎调用，影响吞吐
1、通过 sendmmsg 接口进行优化，sendmmsg 能够将用户态的多个 udp quic 包通过一次零碎调用发到内核态。内核态对于每个 udp quic 包独立作为 udp 包收回去
2、在 1.）解决了零碎调用次数问题，开启 GSO 能够提高一分包提早到发给网卡驱动前一刻，能够进一步提高吞吐，升高 CPU 耗费
3、在 2.）的根底上，当初支流网卡曾经反对硬件 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 利用及将来瞻望
目前阿里云 CDN 线上提供 GQUIC 版本服务，实用的产品蕴含动态内容散发（图片小文件、大文件下载、视音频点播）和动静内容散发（全站减速）。用户只需在 CDN、全站减速控制台对域名开启【QUIC 协定开关】性能，反对 QUIC 协定的客户端即可通过 QUIC 协定与阿里云 CDN 节点通信。
QUIC 利用场景
图片小文件：明显降低文件下载总耗时，晋升效率
视频点播：晋升首屏秒开率，升高卡顿率，晋升用户观看体验
动静申请：实用于动静申请，晋升访问速度，如网页登录、交易等交互体验晋升
弱网环境：在丢包和网络提早重大的状况下仍可提供可用的服务，并优化卡顿率、申请失败率、秒开率、进步连贯成功率等传输指标
大并发连贯：连贯可靠性强，反对页面资源数较多、并发连接数较多状况下的拜访速率晋升
加密连贯：具备平安、牢靠的传输性能
对于 QUIC 协定，目前阿里云 CDN 线上的 QUIC 曾经有了 Tbps 级别的大流量验证，并为客户来带了显著的提早收益。随着 IETF 规范的 QUIC 协定欠缺，阿里云也会尽快推出 ietf quic 服务，咱们置信 QUIC 将来会成为互联网流量的主力成员。
后续阿里云 CDN 会在“阿里云 Edge Plus”公众号中分享更多最新的产品能力、解决方案和技术实际，欢送大家关注，与咱们一起探讨。
援用：
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html
https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
https://quicwg.org/base-drafts/draft-ietf-quic-http.html
https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html
https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html
https://blog.cloudflare.com/accelerating-udp-packet-transmission-for-quic/
https://lore.kernel.org/netdev/0ff6df40-d9cc-0b4c-6f1f-df4b39c3f3e3@akamai.com/T/
https://interop.seemann.io/
https://developer.aliyun.com/article/770062
https://blog.cloudflare.com/accelerating-udp-packet-transmission-for-quic/
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。