Evolución y práctica de la tecnología Taobao HTTP3/QUIC

El artículo presenta el canal de cadena larga para actualizar la infraestructura HTTP3 / QUIC del enlace final de la nube. En la actualidad, la implementación del estándar QUIC de desarrollo propio de Taobao se ha aplicado a gran escala y continúa mejorando las capacidades de transmisión de la red del canal de cadena larga. , ayuda a múltiples servicios a mejorar la experiencia de la red y ha precipitado un conjunto completo de soluciones de implementación de protocolo estándar HTTP3/ QUI C que se pueden reutilizar horizontalmente .

introducción

La siguiente figura muestra los nodos clave en la evolución de los protocolos de red de Taobao En 2015, para optimizar el problema del protocolo de enlace lento del estándar TLS/1.2, desarrollamos y lanzamos SSL ligero, un protocolo de cifrado privado liviano para optimizar los problemas de protocolo de enlace y cifrado, lo que permite que la negociación de sesiones y el cifrado de datos se coloquen en un TCP cuando hay No hay riesgo de ataques de repetición. Para implementar 0-RTT en paquetes, actualmente HTTP2 + SlightSSL también es el principal operador de tráfico móvil en línea de Taobao. Al mismo tiempo, la solución de problemas / acceso comercial / demandas comerciales anteriores enfrentaron algunas dificultades o problemas que no pudieron satisfacer las demandas, como "la cadena larga bajo WI-FI no pudo degradar la cadena corta https con éxito y la cadena larga se cambió". a la red 4G para uso normal (SlightSSL privado El protocolo fue desconectado por el firewall wifi)", "¿Planea admitir TLS1.3?", "Nuestro servidor de acceso a nombres de dominio no admite la implementación de SlightSSL", etc. ; por otro lado, con el lanzamiento oficial de QUIC RFC9000 y HTTP3 RFC9114, Taobao Network La evolución del protocolo a HTTP3/QUIC no es solo para resolver los puntos débiles comerciales del protocolo privado Slight SSL, sino también para mejorar la transmisión de la red. rendimiento y experiencia de usuario.También es la tendencia general de la evolución actual de los protocolos de red. Si bien los protocolos privatizados aportan una experiencia de red eficiente, los problemas se pueden resumir centrándose en los siguientes tres puntos:

Los protocolos privados significan más personalización y requieren soporte de implementación de un extremo a otro (intrusivo)
No es compatible con TLS1.3
En ocasiones, los dispositivos intermedios de la red desconectan ambos extremos al mismo tiempo debido a protocolos privados.

Figura 1.1 Nodos clave en la evolución del protocolo de red Taobao

Evolución de la capacidad TNET

TNET, el nombre completo de TAOBAO NET, es un conjunto de bibliotecas de capacidades básicas de red subyacentes que se formaron gradualmente durante el desarrollo y evolución de la red inalámbrica de Taobao. Actualmente, transporta más del 90% del tráfico de datos HTTP comerciales de Taobao (una pequeña cantidad de nombres de dominio AMDC no está configurado con el protocolo de cadena larga). Como piedra angular de la implementación del servicio de red del grupo en el lado final, es el extremo- Entrada lateral del canal de Después de la evolución y mejora, actualmente proporciona una combinación de protocolos rica y combinable para la capa superior, implementa y resume la adaptación de diferentes protocolos internamente y proporciona una interfaz unificada en la interfaz externa. La capa externa solo necesita pasar diferentes tipos de protocolos combinados. a la hora de establecer una conexión, que sea realmente sencillo y fácil de utilizar. Actualmente existen dos funciones internas principales:

La capa superior se compone de SPDY/HTTP2/HTTP3/Custom/HTTP3/Tunnel para cumplir con las capacidades del canal de red de mensajes HTTP/carga de canal de protocolo privado/ACCS (el TLS estándar se utiliza principalmente en el extranjero y otras partes que no admiten SlightSSL servicios de implementación y actualmente se utiliza HTTP2 estándar El mantenimiento de la sucursal no se ha integrado en la red troncal de Taobao. La razón se basa principalmente en el tamaño del paquete integrado con Taobao. SlightSSL en Taobao cumple con los requisitos comerciales y tiene un mayor rendimiento)
La otra parte es proporcionar capacidades de resolución DNS/traceroute/detección de MTU/detección de PING ICMP/detección de pila de protocolos IPv4 e IPv6 autoimplementadas. Se centra principalmente en los atributos de las herramientas de red para cumplir con el soporte de la capa superior para las capacidades de diagnóstico/detección de red, y admite parcialmente el sistema cuando falla la interfaz DNS nativa Capacidades complementarias.

Figura 2.1 Arquitectura de capacidad TNET

Actualización del protocolo HTTP3/QUIC para mejorar el rendimiento

▐Plan de transformación de tecnología de actualización de terminales y nube

XQUIC, como biblioteca de protocolo estándar IETF QUIC de desarrollo propio de Taobao, tiene la ventaja de ser completamente independiente, controlable y de rápida evolución. Con respecto al diseño de la biblioteca de protocolos XQUIC, los colegas del equipo han publicado varios documentos para presentarlo en detalle. No lo repetiré. Si está interesado, puede leer este artículo. Consulte los enlaces de artículos relacionados al final. Volviendo a la biblioteca de red TNET al final, a través de la actualización integral de la biblioteca XQUIC adaptada, se agrega soporte para el protocolo HTTP3 de siete capas y el protocolo QUIC de cuatro capas. Al mismo tiempo, las diferencias en la implementación de Cada protocolo está blindado externamente. La capa superior solo necesita seleccionar diferentes protocolos al establecer una conexión. Simplemente use diferentes tipos para satisfacer diferentes demandas en diversos escenarios comerciales.

Figura 3.1 Plan de transformación integrado de XQUIC Taobao

Degradación del lado del dispositivo y recuperación rápida

Al final, primero extraerá un conjunto de políticas de amdc (amdc puede entenderse como un servicio extendido de resolución de nombres de dominio httpdns, que no solo devolverá la IP correspondiente al nombre de dominio, sino que también admitirá atributos extendidos como protocolos). Al mismo tiempo, AMDC emitirá los protocolos http3 y http2 al mismo tiempo (el final utiliza http3 primero y el protocolo http2 se emite al mismo tiempo para garantizar que exista un protocolo de cadena larga). Después de obtener el protocolo http3, se detecta la conectividad UDP. Se realizará primero para evitar el problema de limitación de UDP. Solo después de que pase la detección del entorno de red actual, se creará una nueva cadena larga HTTP3, que se presentará más adelante en el artículo sobre detección.

Figura 3.2 Estrategia de degradación del cliente

▐Efecto de actualización

Progreso y efectos de la actualización del mercado

El año pasado, completamos la cobertura de actualización HTTP3 de la parte del tráfico IPv4 en los enlaces clave de Taobao. El año pasado, con la finalización de la transformación del enlace QUIC IPv6 de la intranet del sitio principal de Aserver, trasladamos la guía de compras/transacción/video corto. /subir enlace al tráfico TCP + IPv6 original. Todo cambió a QUIC. Actualmente, se han completado todas las coberturas y actualizaciones de estos escenarios clave en Taobao. En efecto, los datos de AB de mercado/negocios muestran que HTTP3/QUIC ha logrado mejoras significativas en estos diferentes tipos de escenarios comerciales, ayudando a las empresas a lograr un mejor rendimiento de la red (velocidad de transmisión/consumo de tiempo promedio) y redes débiles (consumo de tiempo de cola prolongado y éxito). rate) ) es mejor y proporciona a los usuarios una experiencia de red más fluida. Además, otras aplicaciones dentro del Grupo Alibaba, como Cainiao, Shoumao, AliExpress, etc., también reutilizan nuestra solución para la cobertura de actualización HTTP3 para obtener datos de ingresos comerciales con una mejor experiencia de red. La siguiente es la mejora de los ingresos en Taobao:

Escenario de guía de compras: el consumo promedio total de tiempo de red/P99 se reduce en un 22%/33% y la tasa de finalización en un segundo aumenta en 1,2 puntos;
Escenario de transacción: el consumo promedio total de tiempo de la red/P99 se reduce en un 23%/32% y la tasa de finalización en un segundo aumenta en 0,55 puntos;
Escenario de carga: la tasa de carga de videos/imágenes aumentó en un 7,7%/21%, la tasa de éxito aumentó en 0,18 puntos;
Descarga de videos cortos: el consumo promedio total de tiempo de red/P99 se reduce en un 15%/16% y la velocidad de descarga aumenta en un 18%;

Figura 3.3 Datos comparativos de actualización del enlace principal de MTOP RPC

Figura 3.4 Comparación de la actualización del enlace de contenido de video corto y de carga

Efectos típicos del escenario empresarial de datos

Tasa de interrupción de escenas interactivas.

在互动业务下AB实验数据显示升级HTTP3实验桶可有效降低互动中断UV数/流失UV数。Android HTTP3 AB实验桶中断UV数/中断流失UV数分别降低 24.02%/22.89%，IOS端实验桶分别降低20.91%/18.57%。

图3.5 淘宝互动场景之一笆芭农场

购物车&详情

今年淘宝购物车改版后为用户下单带来了便捷，但同时也面临网络传输体验上耗时长的业务痛点问题，通过切换到HTTP3后从业务大盘耗时均值下降明显，给业务带来更多可能。如下图所示为HTTP3升级推量后接口大盘耗时变化趋势。其他详情/首页等接口也有类似表现，这正是由于升级后传输性能的提升所带来。

图3.6 业务接口耗时随着放量趋势

▐ 落地问题&优化

UDP穿透性问题

因部分运营商和网络中间设备可能存在将udp包丢弃的策略，这将拉低大盘建联成功率并导致降级率显著变高，往往需要等建联超时后才会降级重试成功，这显然会增加重试耗时导致不好用户体验。

对此我们设计了udp联通性探测，在启动阶段或者络环境发生切换时会触发异步探测，该探测结果会根据网络环境持久化到本地，在探测结果过期后会重新触发探测更新。这样确保了即使udp不通情况下，对上层业务体验也不会有劣化影响，而在探测通的环境下使用HTTP3/QUIC将为用户带来更优的用户体验，线上全国大盘的udp穿透性探测成功率数据平均值一开始在95%左右，经过对UDP质量差的VIP治理/下线历史不支持UDP端口特殊调度配置/运营商对某些UDP IP网段去黑名单处理，目前全国udp探测成功率均值提升到98%。

UDP端口NET-rebind问题

在TCP下五元组便唯一确定一条连接，过往我们SLB和CDN LVS的负载均衡分发基础算法都是基于5元组来实现，这在TCP下可以很好的满足要求。升级为QUIC协议后基于五元组转发对连接迁移（Connection Migration）和多路径（Multipath QUIC）的能力就无法支持，因为在这两类场景下5元组都会发生变化。比较理想的是基于CID进行一致性hash转发，这也是QUIC协议设计之初便与5元组解耦考虑，关于基于CID分发感兴趣的可以查看草案QUIC-LB。回到我们落地由于涉及到SLB/LVS基建改造周期较长，受此影响一开始在单路落地我们基于5元组转发（舍弃掉连接迁移能力）进行业务应用，这在大多数情况下已经满足要求但也面临一些问题。NAT 网关针对 UDP 的 Session 存活时间普遍较短，在移动端因为用户切后台空闲情况下容易发生UDP端口NET-rebind问题，这时通过5元组转发下将无法分发到目标服务器，便会出现因为找不到连接上下文而导致连接中断即使当前网络正常。

如下图所示，客户端QUIC连接Q首先从NET设备源出口端口1被SLB转发到Server A上，连接Q从客户端到Server A链路双向转发传输正常；某个时刻如果连接Q对应的UDP Session空闲（如用户切后台）超过NET设备保活时间，APP与出口端口1之间映射将失效；等用户回前台触发发包后，NET设备重新建立起APP到出口端口2的新映射，此时客户端上来的包将被SLB转发到另一台Server机器C上，而在C机器上是找不到QUIC连接Q对应的上下文，这时会回复RESET导致连接中断，从我们数据看华为机型比例高于其他厂商。问题已经清楚通过CID转发来确保端口NET-rebind前后路由的一致性，当Servre端检测到新的5元组后触发连接迁移便可得到解决。

图3.7、五元组转发面临问题

0RTT比例提升

在首次建连握手时，服务端会给客户端返回Session ticket和传输参数，客户端在Session ticket缓存有效期内，下一次握手即可在client-hello之后直接发送加密数据。同时Session ticket自动到期失效后可以退回1-RTT更新，在减少握手延迟的前提下，相较于公钥预置的方案更优，兼顾前向安全性。手淘上目前在完成首次1RTT建联后，我们会将Session ticket和传输参数存储在安全保镖中以确保缓存的安全性。在项目上线初期，提升效果并不那么理想，网络总耗时相较于H2提升约15%左右，分析数据在首包耗时方面与H2几乎保持持平这显然不符合预期，通过数据看0RTT连接比例一开始只有40%左右，经过优化缓存有效率后0RTT比例由40%提升到了65%（该比例还有进一步提升空间，短视频场景0RTT比例目前在80%+），网络总耗时相较H2的提升由15%提高到了20%左右。

业务非加密诉求

对于一些短视频业务，响应大小相比RPC场景更大，且基本都是明文传输对加密诉求弱，更关注视频拉流的速率。为此我们在XQUIC中实现了加密/明文协商能力，在握手完成后如果协商结果为明文传输，则后续包都不再进行加密，这可有效降低server端/客户端加解密的处理开销，进而提升性能。

XQUIC协议栈性能优化

除前面优化外我们还对协议栈进行深度优化，就XQUIC库本身协议处理性能提升85.93%，对比nginx-quic在处理性能上也有15.62%的提升。

图3.8 XQUIC库协议栈优化对比数据

XQUIC库处理模型

下图是XQUIC协议栈最简化模型：对于发送方而言，XQUIC会把一段有序字节流封装成QUIC报文发送出去，对于接收方来说，是把一个个无序的QUIC报文组装成一段有序的字节流。

图3.9 XQUIC库处理简化模型

整体性优化

我们思考下优化CPU开销的核心是什么？为了回答这个问题，我们先想想CPU上跑的是什么？没错，就是指令集。那么指令集是怎么来的呢？它是由汇编语言生成的。汇编语言是怎么来的呢？他是由高级编程语言生成的。因此，我们至少可以想到以下几方面可以优化：

编程语言：也就是你的代码，选择一个合适的编程语言，然后想办法写的性能高一点
编译：编译优化，可以开的编译优化选项都开起来；编译器，选择一个高性能的编译器
指令集：这个我们能做的比较少，服务端一般都是X86
组包优化：回到上面的问题，优化CPU开销的核心是什么？本质上就是减少完成一个功能所需的指令数。注意看XQUIC的简化模型，每收到一个QUIC报文，都需要一系列的函数操作，最终输出一段流。相反的，每发送一段流，都需要调用一系列函数，最终输出一个个QUIC报文。我们要完成的功能就是把一段流传输给对端，我们可以优化处理每个包的一系列函数的性能，但是减少函数调用次数是不是来的更高效。减少QUIC报文数能大幅提升性能，在协议允许的范围内尽量填满每一个报文。

图3.10 XQUIC最初组包情况

图3.11 装填组包优化

图3.12 去掉冗余帧优化

局部性优化

能不能不调

避免无效计算
避免重复计算：每次加解密包都创建加解密上下文，并且初始化密钥 -> 握手完成时或者密钥改变时创建加解密上下文，并且初始化密钥

能不能少调

减少内存拷贝：业务拷贝到H3层再拷贝到传输层 -> 业务拷贝到传输层
尽早退出循环：特别是遍历的列表很长时

优化函数性能

空间换时间：huffman解码表用4K数组存储，每次解码4bits -> 用64K数组存储，每次解码16bits
函数内联
分支预测：likely()/unlikely()

集团全链路压测协议升级

▐ 集团全链路压测升级HTTP3

在淘宝客户端导购&交易场景HTTP3大规模放量后，随之而来的大促全链路压测流量模型中协议占比也发生改变，全链路压测需同时支持HTTP2+HTTP3协议，对此我们对集团全链路压测引擎平台进行一次大的改造升级支持HTTP3协议压测。

不同于HTTP2基于TCP的已经过多年大促&压测多轮验证过的稳定链路，HTTP3基于UDP的全新链路在大促脉冲下的表现则显得缺少大促经验，确实通过压测前验证助力我们提前发现UDP新链路下一些问题，针对解决后最终确保双十一大促HTTP3平稳顺利。碰到的问题主要有：

1、udp_hash查找性能差问题：在quic连接数多的情况下，系统udp_hash查找的性能会急剧下降，易打满系统软中断而无法及时处理超时。内核对该问题进行过优化，4.19之前内核版本需要打patch，4.19及之后的版本已自带，该查找优化需通过设置socket option 来启用，为此我们升级内核版本到4.19。

setsockopt(s, SOL_UDP, 200, (const void *) &value, sizeof(int)

2、内核对udp丢包问题：升级4.19内核后在pps高的情况下又碰到udp丢包问题，原因在于4.19内核对udp内存存在限制。

具体原理：

对每个UDP session内核会把使用的内存计数，并累积到一定值（与rcvbuf正相关）才释放 2. 内核会记录所有UDP的的内存计数和，当这个计数和大于限制值（与umem正相关）时，将会丢弃所有的UDP报文。

不难看出该问题会导致我们单机长链数和应对突增流量的受限，为此我们两个优化参数调节方向：1、增加umem值；2、缩小recvbuf值。

正在进行

▐ HTTP3覆盖图片域名

当前我们完成导购、交易、短视频、上传链路的全量升级覆盖，图片域名的升级覆盖还在逐步灰度覆盖中。

▐ HTTP3 over MPQUIC规模化应用

MPQUIC改造涉及到客户端、SLB、Aserver等基建的升级，目前RPC链路端到端整条链路已经改造完成。淘宝Android已正式上线目前处在规模化放量阶段，能力上提供两种可选模式（长尾补偿模式和多路并行加速模式），从灰度数据看加速模式下MPQUIC相比单路QUIC还有8%进一步速率提升，目前XQUIC实现的MPQUIC已对外开源。CDN链路MPQUIC支持改造Server端和LVS正在进行中。

图5.1 WIFI+LTE双路聚合传输示意图

图5.2 淘宝通用设置网络加速用户开关

附录

QUIC-LB: https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-15
RFC 9000：https://quicwg.org/base-drafts/rfc9000.html
RFC 9114：https://quicwg.org/base-drafts/rfc9114.html
XQUIC: https://github.com/alibaba/xquic

团队介绍

我们是淘天集团终端平台网络技术团队，负责淘宝网络技术/高性能网关技术建设，包括但不限于Tengine-Ingress高性能网关/XQUIC标准化协议库/淘宝终端网络库，支撑亿万流量的移动网络接入和网关服务。团队持续迭代XQUIC/Tengine-Ingress等开源技术代表作，在SIGCOMM/NSDI等网络学术顶级会议发表过多篇论文，并于网络标准组织IETF推进MPQUIC RFC标准。
若你对我们的工作内容感兴趣，欢迎加入挑战，简历投递邮箱：[email protected]

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。