Эволюция и практика технологии Taobao HTTP3/QUIC

В статье представлен канал с длинной цепочкой для обновления инфраструктуры HTTP3/QUIC конечного облачного канала.В настоящее время Taobao самостоятельно разработала стандартную реализацию QUIC.Он применяется в больших масштабах и продолжает улучшать возможности передачи сети по каналу с длинной цепочкой. , помогает множеству сервисов улучшить работу сети и предлагает полный набор решений по реализации стандартного протокола HTTP3/ QUI C, которые можно повторно использовать горизонтально .

введение

На рисунке ниже показаны ключевые узлы эволюции сетевых протоколов Taobao В 2015 году, чтобы оптимизировать проблему медленного установления связи стандарта TLS/1.2, мы разработали и запустили Slight SSL, легкий частный протокол шифрования для оптимизации проблем установления связи и шифрования, позволяющий переносить согласование сеанса и шифрование данных на один TCP, когда отсутствует риск повторных атак.Для реализации 0-RTT в пакетах в настоящее время HTTP2+SlightSSL также является основным носителем мобильного онлайн-трафика Taobao. В то же время в прошлом устранение неполадок/доступ к бизнесу/бизнес-требования сталкивались с некоторыми трудностями или проблемами, которые не могли удовлетворить требования, например, «длинная цепочка под WI-FI не смогла успешно понизить короткую цепочку https, и длинная цепочка была переключена». к сети 4G для обычного использования (частный протокол SlightSSL. Протокол был отключен брандмауэром Wi-Fi)», «Планируете ли вы поддерживать TLS1.3?», «Наш сервер доступа к доменным именам не поддерживает развертывание SlightSSL» и т. д. ; с другой стороны, с официальным выпуском QUIC RFC9000 и HTTP3 RFC9114, сеть Taobao Развитие протокола до HTTP3/QUIC направлено не только на решение бизнес-проблем частного протокола Slight SSL, но и на улучшение сетевой передачи. производительность и удобство использования, а также общая тенденция современной эволюции сетевых протоколов. Хотя приватизированные протоколы обеспечивают эффективную работу сети, проблемы можно резюмировать следующим образом:

Частные протоколы означают больше возможностей настройки и требуют сквозной поддержки развертывания (навязчивой).
Не поддерживает TLS1.3
Иногда сетевые промежуточные устройства отключают оба конца одновременно из-за частных протоколов.

Рисунок 1.1 Ключевые узлы в эволюции сетевого протокола Taobao

Эволюция возможностей TNET

TNET, полное название TAOBAO NET, представляет собой набор базовых сетевых библиотек, постепенно формируемых в ходе развития и развития беспроводной сети Taobao. В настоящее время через него проходит более 90 % бизнес-трафика данных HTTPs компании Taobao (небольшое количество доменных имен AMDC не настроено на протокол длинной цепочки). боковой вход длинного канала цепочки от конца к серверу, а также вход на конечную сторону.Основная После развития и усовершенствований в настоящее время он обеспечивает богатую и комбинируемую комбинацию протоколов для верхнего уровня, реализует и абстрагирует адаптацию различных протоколов внутри страны и обеспечивает унифицированный интерфейс на внешнем интерфейсе.Внешнему уровню необходимо только передавать различные комбинированные типы протоколов. при установке соединения быть по-настоящему простым и легким в использовании. В настоящее время существуют две основные внутренние функции:

Верхний уровень состоит из SPDY/HTTP2/HTTP3/Custom/HTTP3/Tunnel для удовлетворения запросов сети HTTP/загрузки канала частного протокола/возможностей канала сети сообщений ACCS (стандартный TLS в основном используется за рубежом и в других частях, которые не поддерживают SlightSSL). услуги развертывания, и в настоящее время используется стандарт HTTP2. Обслуживание филиала не интегрировано в магистраль Taobao. Причина в основном связана с размером пакета, интегрированного с Taobao. SlightSSL под Taobao соответствует бизнес-требованиям и имеет более высокую производительность)
Другая часть заключается в обеспечении самореализуемого разрешения DNS/traceroute/обнаружения MTU/обнаружения ICMP PING/обнаружения стека протоколов IPv4 и IPv6. В основном он фокусируется на атрибутах сетевых инструментов, чтобы обеспечить поддержку верхнего уровня для возможностей диагностики/обнаружения сети и частично поддерживает систему при сбое собственного интерфейса DNS.Дополнительные возможности.

Рисунок 2.1 Архитектура возможностей TNET

Обновление протокола HTTP3/QUIC для повышения производительности

▐План трансформации технологий модернизации терминалов и облака

XQUIC, как стандартная библиотека протоколов IETF QUIC, разработанная Taobao, имеет то преимущество, что она полностью независима, управляема и быстро развивается. Что касается дизайна библиотеки протоколов XQUIC, коллеги из команды опубликовали множество документов, чтобы подробно представить ее. не буду повторять.Если вам интересно, вы можете прочитать эту статью.Ссылки на соответствующие статьи смотрите в конце. Возвращаясь к сетевой библиотеке TNET в конце, за счет комплексного обновления адаптационной библиотеки XQUIC добавляется поддержка семиуровневого протокола HTTP3 и четырехуровневого протокола QUIC.В то же время различия в реализации каждый протокол внешне экранирован.Верхнему уровню необходимо только выбирать разные протоколы при установлении соединения.Просто используйте разные типы для удовлетворения различных требований в различных бизнес-сценариях.

Рисунок 3.1 План комплексной трансформации XQUIC Taobao

Понижение версии на стороне устройства и быстрое восстановление

В конце сначала будет получен набор политик из amdc (amdc можно понимать как расширенную службу разрешения доменных имен httpdns, которая не только возвращает IP-адрес, соответствующий имени домена, но также поддерживает расширенные атрибуты, такие как протоколы). время amdc будет одновременно выдавать протоколы http3 и http2 (конец сначала использует http3, и одновременно выдается протокол http2, чтобы гарантировать наличие протокола с длинной цепочкой). будет выполнен в первую очередь, чтобы избежать проблемы ограничения UDP.Только после того, как текущее обнаружение сетевой среды пройдет, создайте новую длинную цепочку HTTP3, которая будет представлена позже в статье об обнаружении.

Рисунок 3.2 Стратегия перехода на более раннюю версию клиента

▐Эффект обновления

Прогресс и эффекты обновления рынка

В позапрошлом году мы завершили обновление HTTP3 части трафика IPv4 на ключевых ссылках Taobao. В прошлом году, после завершения преобразования ссылок QUIC IPv6 интрасети основного сайта Aserver, мы переместили руководство по покупкам/транзакции/короткое видео /upload ссылка на исходный трафик TCP+IPv6. Все переключено на QUIC. В настоящее время все покрытие и обновления этих ключевых сцен в Taobao завершены. Фактически, рыночные/бизнес-данные AB показывают, что HTTP3/QUIC добился значительных улучшений в этих различных типах бизнес-сценариев, помогая предприятиям добиться более высокой производительности сети (скорость передачи/среднее потребление времени) и слабых сетей (долгое потребление времени и успех). скорость) ) лучше и обеспечивает пользователям более плавную работу в сети. Кроме того, другие приложения внутри Alibaba Group, такие как Cainiao, Shoumao, AliExpress и т. д., также повторно используют наше решение для обновления HTTP3, чтобы получать данные о доходах бизнеса и улучшать работу сети. Ниже приводится улучшение доходов на Taobao:

Сценарий руководства по покупкам: среднее общее потребление времени в сети/P99 снижается на 22%/33%, а скорость завершения за одну секунду увеличивается на 1,2pt;
Сценарий транзакции: среднее общее потребление сетевого времени/P99 снижается на 23%/32%, а скорость выполнения за одну секунду увеличивается на 0,55pt;
Сценарий загрузки: скорость загрузки видео/изображений увеличилась на 7,7 %/21 %, процент успешных попыток увеличился на 0,18 пт;
Загрузка короткого видео: среднее общее потребление сетевого времени/P99 снижается на 15 %/16 %, а скорость загрузки увеличивается на 18 %;

Рисунок 3.3 Сравнительные данные обновления основного канала MTOP RPC

Рисунок 3.4. Сравнение загрузки и обновления ссылки на короткий видеоконтент

Эффекты типичного бизнес-сценария данных

Частота прерываний интерактивных сцен

在互动业务下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源创计划”，欢迎正在阅读的你也加入，一起分享。