STGW：为自研业务和腾讯云 CLB 客户提供 QUIC 的统一接入和优化

QUIC 作为互联网下一代标准传输协议，能够明显提升业务访问速度，提升弱网请求成功率以及改善网络变化场景下的平滑体验。

STGW 作为公司级的 7 层接入网关以及腾讯云 CLB(负载均衡器)的底层支撑框架，每天都为公司内部业务和腾讯云外部客户提供数万亿次的请求服务，对请求处理的性能、传输效率、运营的可靠性都有非常严苛的要求。

本文主要介绍 STGW 大规模运营 QUIC 过程中的一些经验和开发工作。

QUIC 简介 QUIC 的诞生和发展

在 QUIC 诞生之前，HTTP 协议经历了几次重要的升级：

HTTP1.0 -> HTTP1.1：增加了长连接支持，大大提升了长连接场景下的性能。

HTTP -> HTTPS：增加安全特性，对请求的性能综合来看会有一定的影响。

HTTP1.1 -> HTTP2：主要特性是多路复用与头部压缩，提高了单连接的并发能力。

这些重要变化都是围绕安全与性能展开，对 HTTP 协议的应用和发展起到了很重要的作用。但是，它没有绕开内核 TCP 的限制，导致其协议的发展终究存在瓶颈。

GOOGLE 在引领业界从 HTTP1.1 迈向 HTTP2(GOOGLE SPDY 协议的标准版)后，再一次走在了前头，在 2012 年提出了实验性的 QUIC 协议，首次使用 UDP 重构了 TLS 和 TCP 协议。QUIC 协议不仅仅只应用于 HTTP，QUIC 在设计时除了考虑 HTTP 外，更是设计作为一个通用的传输层协议。在安全性上，GOOGLE 设计了 QUIC 加密协议作为握手协议以解决 QUIC 协议上的安全问题。一般来说，QUIC 握手协议+QUIC 传输层+HTTP2 就是我们常说的 GQUIC(这里指 web 部分)。GQUIC 协议的版本不断演化，从 Q46 开始，GQUIC 协议也不断向 IETF QUIC 和 HTTP3 靠拢。

2015 年，QUIC 的网络草案被正式提交至互联网工程任务组，这意味着新的 QUIC 协议标准将要诞生。在标准 QUIC 协议起草过程中，QUIC 协议上的标准 HTTP 协议作为 HTTP3 也同时被起草。而作为 QUIC 的标准握手协议，IETF 将 TLS1.3 应用其中。TLS1.3+QUIC+HTTP3，这就是我们常说的 IETF QUIC(这里指 web 部分)。截止目前，QUIC 标准的草案已经更新到 34 版，仍没形成正式的 RFC。但是，QUIC 已进入 IETF 最后征求意见，预计标准 QUIC/HTTP3 协议会很快问世。

QUIC 的关键特性

关于 QUIC 的原理，相关介绍的文章很多，这里再列举一下 QUIC 的重要特性。这些特性是 QUIC 得以被广泛应用的关键。不同业务也可以根据业务特点利用 QUIC 的特性去做一些优化。同时，这些特性也是我们去提供 QUIC 服务的切入点。

低连接延时：QUIC 由于基于 UDP，无需 TCP 连接，在最好情况下，短连接下 QUIC 可以做到 0RTT 开启数据传输。而基于 TCP 的 HTTPS，即使在最好的 TLS1.3 的 early data 下仍然需要 1RTT 开启数据传输。而对于目前线上常见的 TLS1.2 完全握手的情况，则需要 3RTT 开启数据传输。对于 RTT 敏感的业务，QUIC 可以有效的降低连接建立延迟。

可自定义的拥塞控制：QUIC 的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上，这意味着我们根据不同的业务场景，实现和配置不同的拥塞控制算法以及参数。GOOGLE 提出的 BBR 拥塞控制算法与 CUBIC 是思路完全不一样的算法，在弱网和一定丢包场景，BBR 比 CUBIC 更不敏感，性能也更好。在 QUIC 下我们可以根据业务随意指定拥塞控制算法和参数，甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。

无队头阻塞：虽然 HTTP2 实现了多路复用，但是因为其基于面向字节流的 TCP，因此一旦丢包，将会影响多路复用下的所有请求流。QUIC 基于 UDP，在设计上就解决了队头阻塞问题。同时，IETF 设计了 QPACK 编码替换 HPACK 编码，在一定程度上也减轻了 HTTP 请求头的队头阻塞问题。无队头阻塞使得 QUIC 相比 TCP 在弱网和一定丢包环境上有更强大的性能。

连接迁移：当用户的地址发生变化时，如 WIFI 切换到 4G 场景，基于 TCP 的 HTTP 协议无法保持连接的存活。QUIC 基于连接 ID 唯一识别连接。当源地址发生改变时，QUIC 仍然可以保证连接存活和数据正常收发。

QUIC 协议栈的选择

对于协议的实现，STGW 与 CDN 业务团队在 LEGO(STGW 与 CDN 自研的高性能转发框架)上实现过完整的 HTTP2 协议。同时，STGW 也在业界最早实现了 TLS 异步代理计算的方案。对于 HTTP1.1/2 和 TLS 协议有不少工程和优化经验。QUIC 协议栈的自研目前也在按计划展开，但尚不成熟。

本文就基于开源方案，给大家简单介绍一下 QUIC 协议栈的深度定制和优化工作。

关于 QUIC 协议栈的实现，当前功能广泛，协议支持齐全的实现并不多。NGINX 官方目前实现了一个实验版本，但是该实现很多问题没解决，同时，其仅支持 IETF 最新的 DRAFT，甚至连一个完整的拥塞控制算法也没有实现。CLOUDFLARE 的 QUIC 基于 RUST 实现，性能从公开数据来看并不强。

其它的很多实现诸如 MSQUIC, NGHTTP3 等都只支持 IETF QUIC，并不支持 GQUIC。

GOOGLE 是 QUIC 协议的开创者，其基于 CHROME 的 QUIC 协议栈实现最早，功能最齐，实现上也最为标准。

不论是哪种 QUIC 协议栈，其接入都需要我们对 QUIC 的基本特性和概念有较深的理解。比如常见的连接，流，QUIC 连接 ID，QUIC 定时器，统一的调度器等等。这些概念与 QUIC 协议的内容息息相关。

下面以 CHROMIUM QUIC 为例的将 QUIC 协议栈与高性能转发框架 NGINX 与 LEGO 融合的架构图：

CHROMIUM QUIC接入高性能框架NGINX/LEGO

STGW 的工作

STGW 作为公司级的 7 层接入网关以及腾讯云 CLB(负载均衡器)的底层支撑框架，为公司内部业务和腾讯云外部客户提供数万亿次请求的服务，对请求处理的性能、传输效率、运营质量的高可靠性都有非常严苟的要求。

为此，我们对 QUIC 协议栈做了大量优化和深度定制，以满足大规模运营和业务需求。主要的工作有：

单机与传输性能优化

QUIC 协议单机性能/成本优化：QUIC 将协议栈搬到应用层来，从目前一些公开的实现看，性能比 TCP 差不少，优化 QUIC 协议的性能是大规模推广 QUIC 协议很重要的一环。

与高性能转发框架融合：当前开源的 QUIC 协议栈的实现仅仅提供单核支持，并仅提供简单的 demo。要想大规模应用，需要将 QUIC 协议栈接入到我们使用的高性能网络转发框架中来，如 NGINX,LEGO 等。

传输性能，拥塞控制定制化：可以允许不同业务根据业务特性选择不同的拥塞控制算法。

做到安全高比例的 0RTT，以降低业务的连接延迟。

功能特性的定制和增强

如何让 QUIC 连接迁移从理论走向应用：QUIC 的连接 ID 是 QUIC 协议的特性，但是实际应用中，要做到连接迁移并不容易，需要充分考虑 QUIC 包的各个路径。即使在同一台机器上，也需要正确转发到对应的核上去。

QUIC 私有协议的支持：QUIC 不仅仅用于 HTTP，作为通用的传输层协议，除了支持 GQUIC,IETF HTTP3 外，QUIC 的私有协议也需要我们提供给用户。

QUIC 定制化 SDK：除了高性能 QUIC 服务端外，要想使用 QUIC 需要客户端 SDK 的支持。对此我们也开发了 QUIC 的 SDK，并针对不同的场景做了定制化。

满足业务各种定制化需求：如有些业务需要 QUIC 明文传输，一些业务需要 QUIC 回源等。

高可用运营

日常变更与平滑升级：在配置频繁变更和模块升级时，我们需要做到对 QUIC 连接无损。

抓包分析工具：分析定位为更方便。

统计监控：QUIC 的关键统计指标，需做到可视化运营。

我们围绕着这些问题展开了 QUIC 的相关工作，力求将 QUIC 特性，QUIC 运营，QUIC 性能，QUIC 定制化需求等做到最好。

QUIC 处理性能优化

QUIC 协议基于 UDP 将 TCP 的特性从内核移到了应用层，从当前各种 QUIC 实现来看，性能相比 TCP 差不少。TCP 长期以来使用非常广泛，这也使得其从协议栈到网卡已经经过了非常多的优化，与之相比，UDP 的优化则少了很多。除了内核和硬件外，QUIC 协议的性能也与实现有关，不同的实现版本可能也会有很大的差别。

我们对 QUIC 的性能利用火焰图等各种工具进行了详细分析，找出了一些影响 QUIC 性能的关键点：

密码相关算法的开销：对于小包来说，RSA 的计算占比很高，对于大包来说，对称加解密也会占到 15%左右的比例。

UDP 收发包的开销：特别是对于大文件下载来说，sendmsg 占比很高，可以达到 35%-40%以上。

协议栈开销：主要受协议栈实现，如 ACK 的处理，MTU 探测和发包大小，内存管理和拷贝等。我们基于影响 QUIC 性能的关键点进行了优化。

QUIC 的 RSA 硬件 OFFLOAD

在小文件请求场景中，RSA 的计算在 QUIC 请求同 HTTPS 一样，仍然是最消耗 CPU 的开销。RSA 在 HTTPS 请求可以利用硬件 offload，在 QUIC 握手过程中，RSA 同样可以利用硬件进行 offload。

使用硬件做 RSA 卸载一个很重要原因是，CPU 计算 RSA 性能较差，而专门做加解密的加速卡性能则很强。一般来说，单块 RSA 加解密卡的成本差不多是一台服务器的 5%-7%，但是其对 RSA 签名的操作性能是服务器的 2-3 倍左右，一台机器插入 2 块卡就可以带来 5 倍的 RSA 性能提升。

将 QUIC 的 RSA 计算进行硬件卸载在不同的 QUIC 协议栈上方法并不相同，下面介绍一种 RSA HOOK + ASYNC JOB 通用的 RSA 卸载方案。其特点是代码侵入性小，不需要额外修改太多 quic 协议栈或者 openssl 的代码。

Openssl1.1.0 之后，开始支持 Async Job。Async job 机制利用类协程方式切换上下文方式实现异步任务，并且提供了一个通知机制通知异步任务的返回结果。

Async Job 里的 2 个重要函数是：

async_fibre_makecontext

async_fibre_swapcontext

它们利用 setjmp，longjmp，setcontext，makecontext 这些调用，保存和切换当前上下文，从而达到状态保留和代码跳转的能力。

使用 RSA callback 将握手过程中的 RSA 进行拦截，并在 RSA 的 HOOK 函数中本地或者远程向加速卡请求 RSA 操作。同时使用 Async job 方式将同步方式异步化，从而实现 RSA 操作的异步卸载。

在 QUIC TLS1.3 上 RSA HOOK + Async Job 进行 RSA offload。

QUIC 在进行了 RSA 的硬件 OFFLOAD 后，对于小包短连接，性能得到了很大的提升。

以 CHROMIUM QUIC 为例，在 1RTT 场景，QUIC 在使用了 RSA OFFLOAD 后，性能为原来的 256%;0RTT 场景，QUIC 在使用了 RSA OFFLOAD 后，性能为原来的 205%。在 QUIC 协议栈开销更小的实现上，这个性能提升会更加明显。

QUIC 发包的 GSO 优化

在大文件下载中，QUIC 发包的逻辑占比很大，通常在 35%-40%以上。因此优化发包逻辑可以提升大文件传输的性能。

QUIC大文件请求火焰图

GSO(Generic Segmentation Offload)在内核 4.8 之后开始支持 UDP，其原理是让数据跨过 IP 层，链路层，在数据离开协议栈，进入网卡驱动前进行分段，不论是 TCP 还是 UDP，都是分段(每个包都附加 TCP/UDP 头部)，这样，当一个段丢失，不需要发送整个 TCP/UDP 报文。同时，路径上的 CPU 消耗也会减少。

若网卡硬件本身支持 UDP 分段，则称为 GSO OFFLOAD，其将分段工作放在网卡硬件上做，可以进一步节省 CPU。

GSO原理示意图

QUIC 协议在实现上，一般为了不进行 MTU 分片，通常会在发包前就将发送数据进行分段，从而无需再进行 MTU 分片。对于大包来说，QUIC 会将每个包控制在 1400 字节左右，然后通过 sendmsg 发送出去。大文件发送场景，这种性能是很低的。如果在 sendmsg 时发送大包不做分段，然后利用内核 GSO 延迟分段，会减少路径的 CPU 消耗。

使用GSO发不同大小包时的吞吐

从表中可以看出，使用 GSO 连续 20 个包进行 sendmsg 发送，相比于 1400 个包单独发送，性能提升了 2-3 倍。

在实际 QUIC 场景中，发包并不是 QUIC 的全部逻辑。同时，并不是每次发包正好都可以凑齐 20 个连续包。我们对大文件下使用 GSO 进行 QUIC 压力测试，相同 CPU 使用情况下，吞吐提高了大约在 15%-20%。

QUIC 协议栈的优化

QUIC 协议栈的性能与 QUIC 协议栈实现有关。对于一些常见的协议栈实现，其优化空间主要有：

一些实现如 CHROMIUM 在 0RTT 和 1RTT 请求中分别多了一次 RSA 计算，这个多余的 RSA 计算是可以去掉的。优化后，0RTT 和 1RTT 的 RSA 计算分别为 0 次和 1 次。

大文件下载中服务端会收到并处理大量的 ACK。在 ACK 处理上，并不需要接收一个处理一个。可以将一轮中所有的 ACK 解析后再同时进行处理。

一次发包大小尽可能接近 MTU，QUIC 协议本身也提供了 MTU 探测的特性。

尽可能减少协议栈的内存拷贝。

4.4 QUIC 性能优化小结

目前，我们将 QUIC 协议栈无缝接入到了高性能转发模块 NGINX 与 LEGO。在小包请求上，QUIC 的性能开销基本可以达到 HTTPS 的 90%以上。如果 QUIC 使用加速卡做 RSA OFFLOAD，性能甚至比原生的 HTTPS 强。在大包请求上，优化过后的 QUIC CPU 性能可以达到 HTTPS 70%，但在大部分机型中，大文件请求通常都是网卡先到达瓶颈。总的来说，QUIC 目前的性能问题做大规模部署已经不在是大问题。当然，这里面仍然存在优化空间，我们也为此做继续的优化之中。

QUIC 的 0RTT 优化

下图展示了一个 HTTPS 请求与一个 QUIC 请求的对比。可以看出，一个完全握手的 HTTPS 请求，在 HTTP 请求正式发出时经历了 3 个 RTT。而 QUIC 请求可以做到发 HTTP 请求之前的 0RTT 消耗。

为什么 QUIC 可以做到 0RTT 呢？这里分为 QUIC 握手协议和 IETF QUIC 的 TLS1.3 协议。我们以 GQUIC 握手为例，如下图：

用户第一个 QUIC 包时发送一个没有带 server config 的 client hello，这个时候 server 回一个 REJ 的包，包含 server config 等信息。用户后续带上 server config 继续发 client hello，服务端会回 server hello。此时握手建立成功。

QUIC 加密握手基于 DH 的非对称秘钥交换算法进行秘钥交换，Server config 包含服务端的算法与公钥等信息，客户端利用服务端的公钥和自己的公私钥计算协商出连接的对称秘钥。

因此，第一次请求，客户端在没有保存服务端 server config 信息时，需要 1RTT 请求来完成第一次 QUIC 请求。而在后续请求中，客户端可以直接带上之前的 server config 来完成 0RTT 请求。

所以，这里的关键是：如何提升 0RTT 的比例。一种典型的场景就是，同一个用户在第一次 1RTT 请求获取到的 server config 信息，在后续多次请求中，不论路由到哪台 7 层 STGW 服务器，都能够尽可能的处理对应的 server config 信息。对此，我们尝试过很多方案，主要有：

1)4 层通过会话保持将同一个 IP 尽可能转发到同一个 7 层 STGW 服务器。这样的缺点是：1 用户的 ip 可能发生变化，2 四层基于 IP 的会话保持和基于连接 ID 的会话保持冲突，这可能导致 0RTT 提升的同时，连接迁移特性可能无法使用。

2)类似于 HTTPS 的分布式 session cache，同一个集群通过远端模块共享 server config 信息。这需要额外引进新的模块，并且会带来一定的延时。

3)类似于 session ticket，支持分布式无状态的 server config 生成。实际过程中可以根据日期和参数生成多组 SCFG，进一步提高可用性和安全性。

关于 0RTT 的优化目前我们做了不少工作，对于一些不敏感的数据传输，我们可以做到 100% 0RTT。

QUIC 连接迁移实现

QUIC 连接迁移是 QUIC 协议一个很重要的特点。QUIC 使用连接 ID 唯一区分连接，以应对用户的网络突然发生变化。一种典型的场景是 4G 与 wifi 之间的切换，之后用户的地址发生变化，原始的客户端 fd 已无法使用。这时只需要在客户端使用 QUIC SDK 重新创建新的 fd，并继续之前连接的发包，即可发出相同连接 ID 的包出去。

用户的 QUIC 包可能经过中间很多路径最后到达实际的业务服务器。我们以典型的腾讯业务走网关的场景分析：

一次 QUIC 请求经过外网后会先到四层 TGW 集群，然后转发给七层 STGW 集群的一台服务器。到达 STGW 服务器后，包会到达一个特定的 worker 进程处理。Worker 进行 QUIC 协议卸载后使用 TCP 或 UDP 转发给具体业务的一个 RS。如果用户的 QUIC 连接在处理过程中突然源地址发生了变化，我们如何继续正确的响应和维持这个 QUIC 连接？另一个场景是：用户的源地址没有发生变化，但是 7 层 STGW 服务器需要做配置变更和升级，这时 QUIC 连接是否可以维持？

四层基于 QUIC 连接 ID 的会话保持

当用户网络地址发生变化时，虽然源地址变化，但是 QUIC 连接 ID 仍可保持一致。包经过中间网络后首先会到 TGW 集群。为了保证用户的地址发生变化时，QUIC 连接得以维持，TGW 集群需要做正确的转发。

TGW 集群对 QUIC 的会话保持需要考虑 GQUIC 和 IETF QUIC 不同的情况。对于 GQUIC(Q043 以下)实现起来较为简单，因为 GQUIC 协议里的连接 ID 由客户产生，并在整个连接保持不变。对于 IETF QUIC，连接 ID 由客户端和服务端协商产生，需要考虑 long header 包和 short header 包等不同的场景。下图为 IETF 连接 ID 的协商过程以及 GQUIC 和 IETF QUIC 不同类型包的抓包分析。

IETF 下连接 ID 的协商过程

GQUIC包

IETF不同类型包

目前 TGW 集群已经支持 QUIC 的会话保持，基本原理是在同集群不同的 TGW 服务器之间同步 QUIC 连接信息，同时能够区分不同 QUIC 协议，将相同 QUIC 连接 ID 的包转发到相同的 7 层 STGW 服务器去。

七层单机多核的连接迁移

当包到达 STGW 服务器时，由于 STGW 服务器多核转发，此时还需要将 QUIC 包转发到同一个进程(或线程)去处理。当前，7 层网络框架一般使用多核+REUSEPORT 模型来提供高性能转发能力。对于 QUIC 服务，上层不同的进程在同一个 UDP 端口使用 REUSEPORT 监听。LINUX 内核默认基于 4 元组 hash，因此原生情况下，不同源地址的包是无法保证到达同一个进程的。

EBPF 在内核 4.19 引入 BPF_PROG_TYPE_SK_REUSEPORT 这个 HOOK，可以策略性的控制一个包到达后发往到哪一个 accept 队列。这使得使用 EBPF 可以实现因为用户源地址变化引起的 QUIC 连接迁移。具体方法是在 EBPF 的 REUSEPORT 钩子处，解析 QUIC 包以及连接 ID，根据 QUIC 连接 ID 将包转发到对应的 worker 去。

配置加载和热升级连接保持

QUIC 连接迁移还有一种典型的场景是配置加载和热升级：当 STGW 服务器进程配置变更或者进行模块升级时，原生 NGINX 对 TCP 是可以保持连接不中断的。但是对于基于 UDP 的 QUIC，在未经过优化的情况下，我们无法在配置变更和模块升级过程中保持包的正常转发。

以 NGINX 的配置和热升级变更为例，NGINX 在配置变更和热升级时，会产生新的一组 worker，同时老的 worker 进入 shutting down 状态，而老的连接状态都在老的 worker 中。此时新老 worker 共用一组 fd。若老的 worker 关闭 fd 监听，则对于老的请求的连接都会超时。若老的 worker 继续监听 fd，则存在新老 worker 惊群读同一个 fd 的问题，这使得任意新老连接的包可能会到任意一个 worker，对新老连接都存在影响。

STGW 作为一个平台，每天的配置变更需求非常多，某些集群甚至达到了几秒一次配置变更。虽然我们实现了动态配置加载可以做到绝大部分场景不需要 reload 程序，但是仍然有少部分程序要 reload。同时，热升级这种场景也是比较常见的。如果配置 reload 或者模块升级就导致存量 QUIC 连接超时或中断，必然会对业务产生很大影响。

NGINX配置变更和热升级时worker的收包

那么，如何解决这个问题呢？

基于内核的 EBPF 方案可以较好的处理 4G 与 WIFI 切换的场景，但是对于 STGW 服务器配置变更和模块升级的场景，却很难实现。

为此，STGW 使用了基于共享内存的 QUIC 连接迁移方案，使用共享内存管理不同进程的所有连接信息。同时为每个 worker 设定了一个 packet queue 用于接收来自别的进程连接迁移的包的转发。

可以说，目前 STGW 完全支持 4G 与 WIFI 互切的 QUIC 连接迁移场景。同时对于线上大规模运营来说，持续的配置变更和模块升级也不会影响 QUIC 连接的保持。

STGW基于共享内存的连接迁移和连接保持方案

连接迁移的应用场景

一切重连开销很大的场景可以说都是 QUIC 连接迁移的使用场景。

例如游戏，视频以及业务信道传输就是比较典型的场景。当用户在 WIFI 网络切换到 4G 时，使用原始的 TCP 方案，在网络切换后会有一个连接重建过程。一般重连后，业务会有一些初始化操作，这会消耗几个甚至十几个 RTT，现象就是应用的卡顿或者菊花旋转。在使用 QUIC 连接迁移功能后，可以保证在 WIFI 与 4G 网络切换过程中，连接的正确迁移和存活，无需建立新的连接，从而使得业务的流畅度在网络切换时会得到很大提升。。

灵活的拥塞算法与 TCP 重定义

TCP 拥塞控制算法的目的可以简单概括为：充分利用网络带宽、降低网络延时、优化用户体验。然而就目前而言要实现这些目标就难免有权衡和取舍。LINUX 的拥塞控制算法经过很多次迭代，主流都是使用的 CUBIC 算法。在 Linux4.19 内核后，拥塞控制算法从 CUBIC 改为了 BBR。

BBR 算法相比之前拥塞控制算法，进行了非常重大的改变。BBR 通过实时计算带宽和最小 RTT 来决定发送速率 pacing rate 和窗口大小 cwnd。BBR 主要致力于：

1)在有一定丢包率的网络链路上充分利用带宽。

2)降低网络链路上的 buffer 占用率，从而降低延迟。

BBR 完全摒弃丢包作为拥塞控制的直接反馈因素，这也导致其对丢包并不是非常敏感。通过测试我们得出，在模拟一定概率丢包的网络情况下，对 QUIC 大文件的请求，BBR 的下载性能会比 CUBIC 更好。

QUIC 将拥塞控制做在了应用层，这也使得我们能够灵活的选择不同的拥塞控制算法。目前我们在 QUIC 上支持常见的 CUBIC,BBR 等算法，并实现了业务的自主配置，根据不同业务，针对请求的不同 VIP 使用不同的拥塞控制算法。同时，我们也支持针对同一个业务不同的用户的 RTT 动态的选择拥塞控制算法。另外，我们也同 CDN 的拥塞控制算法团队密切合作，以优化拥塞控制算法在不同场景下的业务体验。

业务可配的拥塞控制算法

除了拥塞控制，基于 QUIC 也可以在传输层针对特定的应用场景去不同的定制化。QUIC 将 TCP 的特性带到了应用层，这也使得在传输层上，我们有更多的操作可能性。例如，参照音视频领域一些常见的用法，发送数据时发送冗余数据，在一定丢包情况下，QUIC 传输层可以自动恢复数据，而不需要等待数据包的重传，以降低音视频的卡顿率。这些基于 TCP 是很难做到的。业务如果需要重定义 TCP 的一些功能或特性，来提升业务体验，QUIC 将会有很大的发挥空间。

支持 QUIC 私有协议

STGW 作为 7 层网关，提供通用 WEB 协议卸载和转发。因此，支持 QUIC 的 WEB 协议如 GQUIC,HTTP/3 是我们的基本能力。

但是，如前面所说，QUIC 作为通用传输层协议，不仅仅应用于 WEB，任何私有协议都可以改造到 QUIC 下。使用 QUIC 握手协议之后，客户端就可以根据自己的业务需求，发送 GQUIC,HTTP/3 等 WEB 请求，或者可以发送任意自己的私有协议。

STGW 基于 NGINX 的 STREAM 模块，对其进行深度改造，使得任意私有协议都可以跑在 QUIC 协议之下。这也大大增加了 QUIC 的应用场景。

所以，不要觉得不是 HTTP 协议就用不了 QUIC。只要你理解了 QUIC 的特性，并且觉得 QUIC 的特性能够优化业务体验，那么，来试试 QUIC 吧。

QUIC 定制化 SDK

由于 QUIC 尚未标准化，当前使用 QUIC 相对来说门槛较高。

客户端方面，由于 Google 将其浏览器以 Chromium 项目开源出来，其网络协议栈 Cronet 成为业界 QUIC 客户端的主要参考对象。但 Cronet 因为 API 支持有限，代码复杂，难以满足个性化需求等，不适合直接用在我们的移动客户端上。同时，QUIC 作为一个还在高速发展的协议，服务端和客户端都在快速迭代，需要保持紧密的跟进。

基于上述痛点以及 QUIC 渐渐流行的趋势，我们提供比 Google QUIC 更定制化的 TQUIC SDK。TQUIC SDK 相比 Cronet，有体积更加轻量，简单易用，支持私有协议，连接迁移等诸多优点。目前，TQUIC SDK 已应用于公司内部多个业务之中。

总结

本文综合介绍了 STGW 在大规模应用 QUIC 协议过程中做的一些优化和成果。当前：

我们将 QUIC 协议栈与高性能网络框架做了深度融合，并支持 QUIC WEB 协议，QUIC 私有协议，带外拥塞控制配置等大部分 QUIC 功能和特性。满足 QUIC 大规模部署与运营。

我们对 QUIC 协议栈 0RTT，1RTT，小包，高带宽等多场景做了大量的性能优化，解决了 QUIC 严重消耗 CPU 资源的几个瓶颈。在小包请求上性能基本可以达到 HTTPS 的 90%。

针对 RTT 敏感的短连接业务，我们大大提升了 0RTT 的比例，某些场景可以做到 100% 0RTT。

更全面的连接迁移，解决了 4 层，7 层，多集群、多机器、多进程以及进程重启、重加载，模块升级等各种场景下的连接迁移问题。

我们提供了定制化的 QUIC SDK，以用于客户端满足定制化 QUIC 的各种特性。

QUIC 仍然有很多特性需要充分挖掘，如 QUIC 本身基于 UDP 没有队头阻塞特性以及 QPACK 编码在 HTTP/3 的 HTTP 头部上对队头阻塞的优化等。这些特性在弱网环境下对业务都会有较好的性能提升和卡顿率降低，特别是多路复用场景。目前我们也在结合业务积累更多的实际数据，并期望在这块能够有更多的优化。

QUIC 以及相关的 HTTP/3 等协议即将形成最终的标准，我们也在不断跟进 QUIC 协议的演进。

STGW 将持续为自研业务和腾讯云 CLB 客户提供 QUIC 的统一接入和优化，帮助业务更好的提升用户体验。