Delivery Hero迁移HTTP/3,首页响应时间降17%

Delivery Hero迁移至HTTP/3,首页响应时间降17%。借助QUIC协议消除握手延迟,解决巴基斯坦等弱网地区瓶颈,为Uber收购后的多品牌运营优化网络性能。

Delivery Hero 借助 Cloudflare 迁移至 HTTP/3,应用首页响应时间降低 17%

在 P99 2026 虚拟会议上,德国全球外卖服务公司 Delivery Hero 的员工工程师 Elvis Chidera 披露了该公司的一项网络优化成果。通过将大部分用户群迁移至 HTTP/3 协议,Delivery Hero 成功将其应用程序首页屏幕的端到端总响应时间减少了 17%。

握手延迟减少51%

Chidera 指出,尽管 HTTP/3 相比 HTTP/2 提供了更快的网络性能,但在实际部署中仍存在一些需要调整的“慢点”才能发挥最佳效果。

收购背景与多品牌运营挑战

在美国市场,Uber Eats 和 DoorDash 占据主导地位,而总部位于德国的 Delivery Hero 则主要活跃于欧洲、拉丁美洲、非洲、中东和亚洲,拥有约 6000 万用户。目前,Uber 正以 148 亿美元收购 Delivery Hero,并计划将其与 Uber Eats 合并。此次收购旨在扩大 Uber 提供乘车和送货服务的市场覆盖范围。

Delivery Hero 采取集中管理策略,在不同地区运营多个独立开发或收购的应用程序:亚洲用户通过 Foodpanda 订餐,土耳其用户使用 Yemeksepeti,西班牙、意大利、波兰、罗马尼亚、乌克兰及非洲大部分地区使用本地化应用,而在拉丁美洲,用户则通过 PedidosYa 从附近的药店、餐馆和市场获取商品。

由于各地区网络连接状况差异巨大,最后一英里网络往往成为瓶颈。例如,巴基斯坦地区的 App 建立安全握手可能需要近一秒(P90)。工程团队将引入 HTTP/3 视为降低甚至消除这种延迟的关键手段。

HTTP/3 的技术优势:QUIC 与 0-RTT

互联网工程工作组(IETF)于 2022 年正式推出了 HTTP/3。作为连接浏览器与应用层服务器的协议,HTTP/3 摒弃了基于传输控制协议(TCP)的传统架构,转而采用 Google 开发的快速 UDP 互联网连接(QUIC)协议。

TCP 虽然保证了数据交付和流量控制,但其握手过程较为耗时。QUIC 运行在 UDP 之上,UDP 本身不保证数据包交付或流量控制,因此速度更快。QUIC 在 UDP 基础上添加了自身的流控机制,从而解决了可靠性问题。

基于 QUIC 的 HTTP/3 能够显著减少甚至消除建立安全连接所需的往返时间(RTT)。应用程序可以缓存会话票据,并利用 QUIC 的 0-RTT 功能,在握手尚未完成时即开始发送符合条件的应用数据。Chidera 解释称:“基本上,你可以消除困扰较慢网络的 1 秒延迟。如果你能更快地交换数据,就不必支付两次往返的成本。”

此外,不同于 HTTP/2 在数据包丢失或延迟时会出现队头阻塞(Head-of-Line Blocking),HTTP/3 将数据包发送到多个独立的流中,而非单个字符串,从而避免了因个别数据包问题导致整个连接挂起的情况。

实施细节:Android 端的 Cronet 初始化优化

Chidera 表示,设置 HTTP/3 的过程出乎意料地简单。由于 Delivery Hero 使用 Cloudflare 的内容分发网络(CDN)为全球用户提供服务,服务器端的迁移仅需简单的重新配置。客户端方面,自 iOS 15 以来 Apple 已原生支持 HTTP/3,主流浏览器也已普遍兼容。

然而,Android 系统的适配更为复杂。工程团队采用了 Google 的 Cronet 库来处理网络堆栈。为了最小化对现有代码的重写,他们最初通过 OkHttp 包装器将 Cronet Transport 集成到 Android 应用中。

虽然 Cronet 开箱即用支持 HTTP/3 并减少了网络级请求失败,但它存在一个显著缺点:引擎初始化需要大约 800 毫秒(P90),这抵消了 HTTP/3 带来的 0-RTT 速度优势。为此,团队分叉代码建立了名为 OKCronet 的内部库,并通过重叠 Cronet 初始化与其他后台任务来优化启动流程。

经过优化,整体 P95 延迟时间从 1.2 秒缩短至 120 毫秒,读取延迟提高了 10 倍。

拥塞控制算法的影响与后续合作

总体而言,工程团队已将 95% 的用户迁移至 HTTP/3。对于无法使用该协议的设备(主要是网络阻止 UDP 流量的情况),系统会自动回退至 HTTP/2。数据显示,应用与服务器之间的握手延迟减少了 51%,巴基斯坦地区的响应时间减半。

尽管如此,部分二级页面(非首页)在某些易发生数据包丢失的市场(如巴基斯坦)仍出现延迟问题。Delivery Hero 工程师将此归因于 Cloudflare 为 HTTP/3 选择的拥塞控制算法 CUBIC,该算法在处理数据包丢失时表现不佳。

作为对比测试,工程团队使用 Google 的 HTTP/3 感知服务器处理部分流量,这些服务器采用了另一种拥塞协议——带宽和回程传播时间(BBR),后者在处理数据包丢失时表现更稳健。

Chidera 透露,Delivery Hero 目前正在与 Cloudflare 合作,专门解决这一特定的拥塞算法问题。

评论 0

0/500

评论需审核后展示,请文明发言

💬
还没有评论,来说两句

相关阅读