作者：孔令涛

自 2015 年以来，QUIC 协定开始在 IETF 进行标准化并被国内外各大厂商相继落地。鉴于 QUIC 具备“0RTT 建联”、“反对连贯迁徙”等诸多劣势，并将成为下一代互联网协议：HTTP3.0 的底层传输协定，蚂蚁团体支付宝客户端团队与接入网关团队于 2018 年下半年开始在挪动领取、海内减速等场景落地 QUIC。

本文是综述篇，介绍 QUIC 在蚂蚁的整体落地状况。之所以是综述，是因为 QUIC 协定过于简单，如果对标已有的协定，QUIC 近似等于 HTTP + TLS +TCP，无奈具体的毕其功于一役，因而咱们通过综述的形式将落地的重点出现给读者，次要介绍如下几个局部：

• QUIC 背景：简略全面的介绍下 QUIC 相干的背景常识；
• 计划选型设计：具体介绍蚂蚁的落地计划如何另辟蹊径、优雅的撑持 QUIC 的诸多个性，包含连贯迁徙等；
• 落地场景：介绍 QUIC 在蚂蚁的两个落地场景，包含：支付宝客户端链路以及海内减速链路；
• 几项关键技术：介绍落地 QUIC 过程中外围须要解决的问题，以及咱们应用的计划，包含：“反对连贯迁徙”、“晋升 0RTT 比例 ”，“ 反对 UDP 无损降级”以及“客户端智能选路”等；
• 几项要害的技术专利。

QUIC 背景介绍

鉴于读者的背景可能不同，在开始本文之前，咱们先简略介绍下 QUIC 相干的背景常识，如果您对这个协定的更多设计细节感兴趣，能够参见相干 Draft：https://datatracker.ietf.org/…

一、QUIC 是什么？

简略来说，QUIC (Quick UDP Internet Connections) 是一种基于 UDP 封装的平安 牢靠传输协定，他的指标是取代 TCP 并自蕴含 TLS 成为规范的平安传输协定。下图是 QUIC 在协定栈中的地位，基于 QUIC 承载的 HTTP 协定进一步被标准化为 HTTP3.0。

二、为什么是 QUIC？

在 QUIC 呈现之前，TCP 承载了 90% 多的互联网流量，仿佛也没什么问题，那又为何会呈现革命者 QUIC 呢？这次要是因为倒退了几十年的 TCP 面临“协定僵化问题”，体现在几方面：

1. 网络设备反对 TCP 时的僵化，体现在：对于一些防火墙或者 NAT 等设施，如果 TCP 引入了新的个性，比方减少了某些 TCP OPTION 等，可能会被认为是攻打而丢包，导致新个性在老的网络设备上无奈工作。
2. 网络操作系统降级艰难导致的 TCP 僵化，一些 TCP 的个性无奈疾速的被演进
3. 除此之外，当应用层协定优化到 TLS1.3、HTTP2.0 后，传输层的优化也提上了议程，QUIC 在 TCP 根底上，取其精华去其糟粕具备如下的硬核优势：

三、QUIC 生态圈倒退简史

下图是 QUIC 从创立到当初为止的一些比拟重要的工夫节点，2021 年，QUIC V1 成为 RFC，完结百花齐放的态势。

介绍完 QUIC 相干背景，之后咱们来介绍蚂蚁的整个落地的内容，这里为了便于论述，咱们用蚂蚁 QUIC 的 一、二、三、四 来进行概括总结，即“一套落地框架”、“两个落地场景”、“三篇翻新专利爱护”、“四项关键技术”。

一套落地框架

蚂蚁的接入网关是基于多过程的 NGINX 开发的 (外部称为 Spanner，协定卸载的扳手)，而 UDP 在多过程编程模型上存在诸多挑战，典型的像无损降级等。为了设计一套齐备的框架，咱们在落地前充分考虑了服务端在云上部署上的方便性、扩展性、以及性能问题，设计了如下的落地框架以撑持不同的落地场景：

在这套框架中，包含如下两个组件：

1. QUIC LB 组件：基于 NGINX 4 层 UDP Stream 模块开发，用来基于 QUIC DCID 中携带的服务端信息进行路由，以反对连贯迁徙；
2. NGINX QUIC 服务器：开发了 NGINX_QUIC_MODULE，每个 Worker 监听两种类型的端口：
3. BASE PORT，每个 Worker 应用的雷同的端口号，以 Reuseport 的模式监听，并裸露给 QUIC LB，用以接管客户端过去的第一个 RTT 中的数据包，这类包的特点是 DCID 由客户端生成，没有路由信息；
4. Working PORT，每个 Worker 应用的不同的端口号，是真正的工作端口，用以接管第一个 RTT 之后的 QUIC 包，这类包的特定是 DCID 由服务端的过程生成携带有服务端的信息。

以后框架反对的能力包含如下：

1. 在不必批改内核的状况下，齐全在用户态反对 QUIC 的连贯迁徙，以及连贯迁徙时 CID 的 Update；
2. 在不必批改内核的状况下，齐全在用户态反对 QUIC 的无损降级以及其余运维问题；
3. 反对真正意义上的 0RTT，并可晋升 0RTT 的比例。

为何能反对上述能力，咱们前面会开展叙述。

两个落地场景

咱们由近及远的两个落地场景如下：

场景一、支付宝挪动端落地

如下为咱们落地架构的示意图，支付宝手机客户端通过 QUIC 携带 HTTP 申请，通过 QUIC LB 等四层网关将申请转发到 Spanner（蚂蚁外部基于 NGINX 开发的 7 层网关），在 Spanner 上咱们将 QUIC 申请 Proxy 成 TCP 申请，发送给业务网关（RS）。

具体的计划选型如下：

• 反对的 QUIC 版本是 gQUIC Q46；
• NGINX QUIC MODULE 反对 QUIC 的接入和 PROXY 成 TCP 的能力；
• 反对包含挪动领取、基金、蚂蚁森林在内的所有的 RPC 申请；

• 以后抉择 QUIC 链路的形式有两种：

  • Backup 模式，即在 TCP 链路无奈应用的状况下，降级到 QUIC 链路；
  • Smart 模式，即 TCP 和 QUIC 竞速，在 TCP 表现力弱于 QUIC 的状况下，下次申请被动应用 QUIC 链路。

在此场景下，通过应用 QUIC 能够取得的红利包含：

1. 在客户端连贯产生迁徙的时候，能够一直链持续服务；
2. 客户端在首次发动连贯时，能够节俭 TCP 三次握手的工夫；
3. 对于弱网状况，QUIC 的传输管制能够带来传输性能晋升。

场景二、海内减速落地

蚂蚁团体从 2018 年开始自研了海内的动静减速平台 AGNA（Ant Global Network Accelerator）以替换第三方厂商的减速服务。AGNA 通过在海内部署接入点：Local Proxy(LP) 以及在国内部署接出点：Remote Proxy（RP）的形式，将用户的海内申请通过 LP 和 RP 的减速链路回源国内。如下图所示，咱们将 QUIC 部署在 LP 和 RP 之间的链路。

在海内接入点上(LP)，每一个 TCP 连贯都被 Proxy 成 QUIC 上的一个 Stream 进行承载，在国内接出点上(RP), 每一个 QUIC Stream 又被 Proxy 成一个 TCP 连贯，LP 和 RP 之间应用 QUIC 长连贯。

在此场景下，通过应用 QUIC 能够取得的红利包含：

1. 通过 QUIC 长连贯的上的 Stream 承载 TCP 申请，防止每次的跨海建联；
2. 对于跨海的网络，QUIC 的传输管制能够带来传输性能晋升。

三篇要害专利

到目前为止，咱们把落地过程中一些翻新的技术点通过申请专利进行了爱护，并踊跃在 IETF 进行标准化分享咱们的研究成果，包含：

专利一

咱们将落地场景 2 中，通过 QUIC Stream 进行四层代理的伎俩来进行海内回源的减速办法进行专利爱护，提出：“一种基于 QUIC 协定代理的的链路减速办法”，目前此专利曾经取得美国专利受权，专利号：CN110213241A。

专利二

将咱们落地框架中的 QUIC LB 组件作为专利进行爱护，提出：“一种无状态、一致性、分布式的 QUIC 负载平衡设施”，目前此专利还在受理中。因为通过 QUIC LB 能够很好的反对 QUIC 协定的连贯迁徙问题，所以目前 IETF QUIC WG 上有对于 QUIC LB 相干的草案，咱们目前曾经参加到 Draft 的探讨和制订中，后序相干的计划也会持续推广到云上产品。

专利三

将咱们解决的 UDP 的无损降级办法进行专利爱护，提出“一种 QUIC 服务器无损降级计划”，目前此专利还在受理中。因为 UDP 无损降级问题是一个业界难题，以后有些伎俩须要在用户态进行跳转，性能损失较大，咱们的计划能够在咱们的落地框架中解决以后问题，对于这个计划的细节咱们再前面的关键技术中进行介绍。

四项关键技术

在整个的落地中，咱们设计的计划围绕解决几个外围问题开展，造成了四项关键技术，别离如下：

技术点 1：优雅的反对连贯迁徙能力

先说 连贯迁徙面临的问题，上文有提到，QUIC 有一项比拟重要的性能是反对连贯迁徙。这里的连贯迁徙是指：如果客户端在长连贯放弃的状况下切换网络，比方从 4G 切换到 Wifi , 或者因为 NAT Rebinding 导致五元组发生变化，QUIC 仍然能够在新的五元组上持续进行连贯状态。QUIC 之所以能反对连贯迁徙，一个起因是 QUIC 底层是基于无连贯的 UDP，另一个重要起因是因为 QUIC 应用惟一的 CID 来标识一个连贯，而不是五元组。

如下图所示，是 QUIC 反对连贯的一个示意图，当客户端进口地址从 A 切换成 B 的时候，因为 CID 放弃不变，所以在 QUIC 服务器上，仍然能够查问到对应的 Session 状态。

然而，实践很饱满，落地却很艰巨，在端到端的落地过程中，因为引入了负载平衡设施，会导致在连贯迁徙时，所有依赖五元组 Hash 做转发或者关联 Session 的机制生效。以 LVS 为例，连贯迁徙后，LVS 依附五元组寻址会导致寻址的服务器存在不统一。即使 LVS 寻址正确，当报文达到服务器时，内核依据五元组关联过程，仍然会寻址出错。同时，IETF Draft 要求，连贯迁徙时 CID 须要更新掉，这就为仅依附 CID 来转发的打算同样变的不可行。

再说 咱们的解决办法，为了解决此问题，咱们设计了开篇介绍的落地框架，这里咱们将计划做一些简化和形象，整体思路如下图所示：

1、在四层负载平衡上，咱们设计了 QUIC LoadBalancer 的机制：

• 咱们在 QUIC 的 CID 中扩大了一些字段（ServerInfo）用来关联 QUIC Server 的 IP 和 Working Port 信息；
• 在产生连贯迁徙的时候，QUIC LoadBalancer 能够依赖 CID 中的 ServerInfo 进行路由，防止依赖五元组关联 Session 导致的问题；
• 在 CID 须要 Update 的时候，NewCID 中的 ServerInfo 保留不变，这样就防止在 CID 产生 Update 时，仅依赖 CID Hash 筛选后端导致的寻址不统一问题；

2、在 QUIC 服务器多过程工作模式上，咱们冲破了 NGINX 固有的多 Worker 监听在雷同端口上的枷锁，设计了多端口监听的机制，每个 Worker 在工作端口上进行隔离，并将端口的信息携带在对 First Initial Packet 的回包的 CID 中，这样代理的益处是：

• 无论是否连贯迁徙，QUIC LB 都能够依据 ServerInfo，将报文转发到正确的过程；
• 而业界广泛的计划是批改内核，将 Reuse port 机制改为 Reuse CID 机制，即内核依据 CID 筛选过程。即使前面能够通过 ebpf 等伎俩反对，但咱们认为这种批改内核的机制对底层过于依赖，不利于计划的大规模部署和运维，尤其在私有云上；
• 应用独立端口，也有利于多过程模式下，UDP 无损降级问题的解决，这个咱们在技术点 3 中介绍。

技术点 2：晋升 0RTT 握手比例

这里先 介绍 QUIC 0RTT 原理。前文咱们介绍过，QUIC 反对传输层握手和平安加密层握手都在一个 0RTT 内实现。TLS1.3 自身就反对加密层握手的 0RTT，所以难能可贵。而 QUIC 如何实现传输层握手反对 0RTT 呢？咱们先看下传输层握手的目标，即：服务端校验客户端是真正想握手的客户端，地址不存在坑骗，从而防止伪造源地址攻打。在 TCP 中，服务端依赖三次握手的最初一个 ACK 来校验客户端是真正的客户端，即只有真正的客户端才会收到 Sever 的 syn_ack 并回复。

QUIC 同样须要对握手的源地址做校验，否则便会存在 UDP 自身的 DDOS 问题，那 QUIC 是如何实现的？依赖 STK(Source Address Token) 机制。这里咱们先申明下，跟 TLS 相似，QUIC 的 0RTT 握手，是建设在曾经同一个服务器建设过连贯的根底上，所以如果是纯的第一次连贯，依然须要一个 RTT 来获取这个 STK。如下图所示，咱们介绍下这个原理：

1. 相似于 Session Ticket 原理，Server 会将客户端的地址和以后的 Timestamp 通过本人的 KEY 加密生成 STK。
2. Client 下次握手的时候，将 STK 携带过去，因为 STK 无奈篡改，所以 Server 通过本人的 KEY 解密，如果解进去的地址和客户端此次握手的地址统一，且工夫在有效期内，则示意客户端可信，便能够建设连贯。
3. 因为客户端第一次握手的时候，没有这个 STK，所以服务度会回复 REJ 这次握手的信息，并携带 STK。

实践上说，只有客户端缓存了这个 STK，下次握手的时候带过去，服务端便能够间接校验通过，即实现传输层的 0RTT。然而实在的场景却存在 如下两个问题：

1. 因为 STK 是服务端加密的，所以如果下次这个客户端路由到别的服务器上了，则这个服务器也须要能够辨认进去；
2. STK 中 encode 的是上一次客户端的地址，如果下一次客户端携带的地址产生了变动，则同样会导致校验失败。此景象在挪动端产生的概率十分大，尤其是 IPV6 场景下，客户端的进口地址会常常发生变化。

再介绍下咱们的解决办法。第一个问题比拟好解，咱们只有保障集群内的机器生成 STK 的秘钥统一即可。第二个问题，咱们的解题思路是：

1. 咱们在 STK 中扩大了一个 Client ID, 这个 Clinet ID 是客户端通过无线保镖黑盒生成并全局惟一不变的，相似于一个设施的 SIMID，客户端通过加密的 Trasnport Parameter 传递给服务端，服务端在 STK 中蕴含这个 ID；
2. 如果因为 Client IP 发生变化导致校验 STK 校验失败，便会去校验 Client ID，因为 ID 对于一个 Client 是永远不变的，所以能够校验胜利，当然前提是，这个客户端是实在的。为了避免 Client ID 的泄露等，咱们会选择性对 Client ID 校验能力做限流爱护。

技术点 3：反对 QUIC 无损降级

咱们晓得 UDP 无损降级是业界难题。无损降级是指在 reload 或者更新二进制时，老的过程能够解决完存量连贯上的数据后优雅退出。以 NGINX 为例，这里先介绍下 TCP 是如何解决无损降级的，次要是如下的两个步骤：

1. 老过程先敞开 listening socket，待存量连贯申请都完结后，再敞开连贯套接字；
2. 新过程从老过程继承 listening socket , 开始 accept 新的申请。

而 UDP 无奈做到无损降级是因为 UDP 只有一个 listening socket 没有相似 TCP 的连贯套接字，所有的收发数据包都在这个 socket 上，导致上面的热降级步骤会存在问题：

1. 在热降级的时候，old process fork 出 new process 后，new process 会继承 listening socket 并开始 recv msg；
2. 而 old process 此时如果敞开 listenging socket，则在途的数据包便无奈接管，达不到优雅退出的目标；
3. 而如果持续监听，则新老过程都会同时收取新连贯上的报文，导致老过程无奈退出。

这里介绍下相干的解决办法。针对此问题，业界有一些办法，比方：在数据包中携带过程号，当数据包收发错乱后，在新老过程之间做一次转发。思考到接入层上的性能等起因，咱们不心愿数据再做一次跳转。联合咱们的落地架构，咱们设计了如下的 基于多端口轮转的无损降级计划，简略来说，咱们让新老过程监听在不同的端口组并携带在 CID 中，这样 QUIC LB 就能够依据端口转发到新老过程。为了便于运维，咱们采纳端口轮转的形式，新老过程会在 reload N 次之后，从新开始之前选中的端口。如下图所示：

1. 无损降级期间，老过程的 Baseport 端口敞开，这样不会再承受 first intial packet, 相似于敞开了 tcp 的 listening socket；
2. 老过程的工作端口，持续工作，用来接管以后过程上残余的流量；
3. 新过程的 Baseport 开始工作，用来接管 first initial packet, 开启新的连贯，相似于开启了 tcp 的 listening socket；
4. 新过程的 working port = (I + 1) mod N, N 是指同时反对新老过程的状态的次数，例如 N = 4，示意能够同时 reload 四次，四种 Old, New1, New2, New3 四种状态同时并存，I 是上一个过程工作的端口号，这里 + 1 是因为只有一个 worker, 如果 worker 数有 M 个，则加 M；
5. 建好的连贯便被 Load Balancer 转移到新过程的监听端口的 Working Port 上。

技术点 4：客户端智能选路

只管落地 QUIC 的欲望是好的，然而新事物的倒退并不是一帆风顺的。因为 QUIC 是基于 UDP 的，而 UDP 相比于 TCP 在运营商的反对上并非敌对，体现在：

1. 在带宽缓和的时候，UDP 会常常被限流；
2. 一些防火墙对于 UDP 包会间接 Drop；
3. NAT 网关针对 UDP 的 Session 存活工夫也较短。

同时，依据察看发现，不同的手机厂商对于 UDP 的反对能力也不同，所以在落地过程中，如果自觉的将所有流量齐全切为 QUIC 可能会导致一些难以预料的后果。为此，咱们在客户端上，设计了开篇介绍的 TCP 和 QUIC 互相 Backup 的链路，如下图所示，咱们实时探测 TCP 链路和 QUIC 链路的 RTT、丢包率、申请实现工夫、错误率等指标状况，并依据肯定的量化办法对两种链路进行打分，依据评分高下，决定抉择走哪种链路，从而防止寻址只走一条链路导致的问题。

做个总结

本文次要综述性的介绍了 QUIC 在蚂蚁的落地计划、场景以及一些关键技术。关键技术上 ，次要介绍了咱们如何通过创造性的提出 QUIC LB 组件、以及多端口监听的机制来优雅的反对 QUIC 的连贯迁徙机制、QUIC 服务端的无损降级等，依赖这套计划咱们的接入网关不须要像业界一样依赖底层内核的改变，这极大的不便了咱们计划的部署，尤其在私有云场景下。除了连贯迁徙以外，咱们还提出了 0RTT 建联晋升计划、客户端智能选路计划，以最大化 QUIC 在挪动端上的收益。截止以后，QUIC 曾经在支付宝挪动端以及寰球减速链路 两个场景 上安稳运行，并带来了较好的业务收益。

将来布局

两年来，咱们次要以社区的 gQuic 为根底，充分发挥 QUIC 的协定劣势，并联合蚂蚁的业务特色以最大化挪动端收益为指标，创造性的提出了一些解决方案，并踊跃向社区和 IETF 进行推广。在将来，随着蚂蚁在更多业务上的发展和摸索以及 HTTP3.0/QUIC 行将成为规范，咱们会次要围绕以下几个方向持续深挖 QUIC 的价值：

1. 咱们将利用 QUIC 在应用层实现的劣势，设计一套对立的具备自适应业务类型和网络类型的 QUIC 传输管制框架，对不同类型的业务和网络类型，做传输上的调优，以优化业务的网络传输体验；
2. 将 gQUIC 切换成 IETF QUIC，推动规范的 HTTP3.0 在蚂蚁的进一步落地；
3. 将蚂蚁的 QUIC LB 技术点向 IETF QUIC LB 进行推动，并最终演变为规范的 QUIC LB；
4. 摸索并落地 MPQUIC（多路径 QUIC）技术，最大化在挪动端的收益；
5. 持续 QUIC 的性能优化工作，应用 UDP GSO，eBPF，io_uring 等内核技术；
6. 摸索 QUIC 在内网承载东西向流量的机会。

关注咱们，每周 3 篇挪动技术实际 & 干货给你思考！