Delivery Heroは利用者の95％をHTTP/3へ移行し、ホーム画面の応答時間を17％短縮しました。 一方、一部市場では通信速度が落ちる問題も残り、同社はCloudflareと輻輳制御方式の改善に取り組んでいます。
HTTP/3移行で接続時の待ち時間を削減
Delivery HeroはFoodpandaやGlovoなど地域別の配達アプリを運営し、世界各地の異なる通信環境に対応しています。通信経路の最後の区間がボトルネックになることがあり、パキスタンではサーバーとの安全な接続を確立するまで、90パーセンタイルで約1秒かかる場合がありました。
HTTP/3は、HTTP通信にQUICという転送プロトコルを使います。QUICはUDP上で動作し、再接続時には保存したセッション情報を使って、接続の確立中に一部のアプリケーションデータを送る0-RTTに対応します。
Delivery HeroはCloudflareのコンテンツ配信ネットワークを利用していたため、サーバー側は設定変更でHTTP/3に対応できました。iOSでは標準的なブラウザーが対応済みで、AndroidではGoogleのCronetライブラリーを導入し、既存の通信処理との接続にOkHttp向けのラッパーを使いました。
Androidの初期化時間も並行処理で短縮
Cronetの導入後、ネットワーク層のリクエスト失敗は減少しましたが、Androidでは通信エンジンの初期化に90パーセンタイルで約800ミリ秒かかり、0-RTTによる短縮効果の一部を打ち消していました。
そこで開発チームは独自の接続ブリッジ「OKCronet」を作り、Cronetの初期化をほかのバックグラウンド処理と並行させました。その結果、読み込み時の95パーセンタイル遅延は1.2秒から120ミリ秒へ下がり、10分の1になりました。
P99 CONF 2026の講演概要では、18市場の本番環境でHTTP/2とHTTP/3を比較し、ネットワーク層の失敗が48％減った一方、複数市場でスループットが4％以上低下したとされています。 失敗の減少と通信量の低下が併存したため、移行後の結果は市場ごとの通信条件も分けて評価されました。
UDPを使えない環境にはHTTP/2で対応
HTTP/3はUDPを使うQUIC上で動作するため、UDP通信が遮断されたネットワークでは接続できないことがあります。Delivery HeroはHTTP/3を利用できない端末をHTTP/2へ自動的に切り替え、95％の利用者をHTTP/3へ移行しました。
QUICの適用に関するIETFのガイダンスでは、UDPを遮断するネットワークがあるため、HTTPではTLS over TCPへ切り替える設計が必要とされています。 ただし、切り替え後はQUICの多重ストリーム機能がそのまま使えず、接続方式によって性能が変わる可能性があります。
同ガイダンスは、0-RTTのデータが再送や悪意あるリプレイによってサーバーで複数回処理される危険も挙げています。 データ取得の開始や設定は安全な例として示される一方、実行が重複すると永続的な影響を及ぼす処理は送信に適さない場合があり、アプリケーションごとの選別が必要です。
パケット損失が多い市場では輻輳制御が課題
Delivery Heroの技術者は、ホーム画面以外の一部画面で起きた遅延について、パケット損失が多い市場でCloudflareがHTTP/3に採用するCUBICが影響したと説明しました。GoogleのHTTP/3対応サーバーでBBRを試したところ、同じようにパケット損失で停滞しなかったといいます。
CUBICはパケット損失を手掛かりに送信量を調整する方式で、BBRは観測したボトルネック帯域と最小往復時間からネットワークの状態を推定します。 ただし、これらの仕組みを説明する研究はTCPの輻輳制御を比較したもので、Delivery HeroのQUIC環境を直接測定した結果ではありません。
衛星回線で行われたTCPの測定では、CUBICとBBRの定常状態の中央値スループットは同程度でしたが、起動時にはBBRのスループットが高く、往復時間も両方式で同程度でした。 この測定では両方式ともボトルネックのキューを過負荷にして再送が増える期間があり、方式の違いだけで遅延や損失の問題が解消するわけではありません。
Delivery HeroはCloudflareと輻輳制御の問題解決に取り組んでいます。 HTTP/3への移行で接続確立や読み込みの時間が短くなった一方、パケット損失が多い市場では画面によって遅延が残り、方式の調整が続いています。
