QUIC プロトコルの動作: Uber がパフォーマンスを最適化するために QUIC プロトコルをどのように実装したか

QUIC プロトコルは見るのが非常に興味深いので、私たちはそれについて書くのが大好きです。 しかし、QUIC に関するこれまでの出版物が歴史 (お好みであれば、地域の歴史) の性質とハードウェアに関するものであったとしたら、今日は喜んで別の種類の翻訳を出版します。2019 年のプロトコルの実際の応用についてお話します。 さらに、私たちはいわゆるガレージを拠点とする小規模なインフラストラクチャーについて話しているのではなく、ほぼ世界中で事業を展開している Uber について話しています。 同社のエンジニアがどのようにして QUIC を本番環境で使用する決定に至ったのか、テストをどのように実行したのか、そして本番環境で QUIC を展開した後に見たものを以下に示します。

写真はクリック可能です。 読書を楽しむ！

Uber は世界的な規模、つまり 600 都市で展開しており、各都市でアプリケーションは 4500 以上の携帯電話会社の無線インターネットに完全に依存しています。 ユーザーは、アプリが速いだけでなくリアルタイムであることを期待しています。これを実現するには、Uber アプリには低遅延と非常に信頼性の高い接続が必要です。 ああ、でもスタックは HTTP / 2 動的で損失が発生しやすいワイヤレス ネットワークではうまく機能しません。 この場合、パフォーマンスの低下はオペレーティング システム カーネルの TCP 実装に直接関係していることがわかりました。

この問題を解決するために、私たちは申請しました QUIC、トランスポート プロトコルのパフォーマンスをより詳細に制御できる最新のチャネル多重化プロトコル。 現在、ワーキンググループは、 IETF QUICを次のように標準化します HTTP / 3.

広範なテストの結果、アプリケーションに QUIC を実装すると、TCP と比較してテール レイテンシが低下するという結論に達しました。 運転手および助手席アプリケーションの HTTPS トラフィックが 10 ～ 30% の範囲で減少することが観察されました。 QUIC により、ユーザー パッケージをエンドツーエンドで制御できるようになりました。

この記事では、QUIC をサポートするスタックを使用して Uber アプリケーションの TCP を最適化した経験を共有します。

最新テクノロジー：TCP

現在、TCP は、インターネット上で HTTPS トラフィックを配信するために最もよく使用されているトランスポート プロトコルです。 TCP は信頼性の高いバイト ストリームを提供するため、ネットワークの輻輳やリンク層の損失に対処できます。 HTTPS トラフィックに TCP が広く使用されているのは、前者の遍在性 (ほぼすべての OS に TCP が含まれている)、ほとんどのインフラストラクチャ (ロード バランサー、HTTPS プロキシ、CDN など) での可用性、およびすぐに使用できる機能によるものです。ほぼほとんどのプラットフォームとネットワーク上で動作します。

ほとんどのユーザーは外出先で当社のアプリを使用しており、TCP テールの遅延はリアルタイムの HTTPS トラフィックの要求には遠く及ばませんでした。 簡単に言うと、世界中のユーザーがこれを経験しています。図 1 は主要都市での遅延を示しています。

図 1: テール レイテンシは、Uber の主要都市によって異なります。

インドとブラジルのネットワークの遅延は米国や英国よりも高かったものの、テール遅延は平均遅延よりも大幅に高かった。 そしてこれは米国や英国にも当てはまります。

TCP over the air パフォーマンス

TCP は次のために作成されました。 有線 つまり、予測可能性の高いリンクに重点を置いたネットワークです。 しかし、 無線 ネットワークにはそれぞれ独自の特徴と困難があります。 まず、ワイヤレス ネットワークは干渉や信号の減衰による損失を受けやすくなります。 たとえば、Wi-Fi ネットワークはマイクロ波、Bluetooth、その他の電波の影響を受けやすくなっています。 携帯電話ネットワークでは信号損失が発生します (失われた道) 物体や建物、また他の場所からの信号の反射/吸収が原因です。 干渉 隣から 携帯電話の塔。 これにより、より重要 (4 ～ 10 倍) でより多様な情報が得られます。 往復時間 (RTT) 有線接続と比較してパケットロスが少なくなります。

帯域幅の変動や損失に対処するために、セルラー ネットワークは通常、トラフィック バースト用に大きなバッファを使用します。 これにより過剰なキューが発生し、遅延が長くなる可能性があります。 非常に多くの場合、TCP はタイムアウトの延長によりこのキューを無駄なものとして扱うため、TCP は中継を行ってバッファを埋める傾向があります。 この問題は次のように知られています バッファブロート (過剰なネットワーク バッファリング、バッファの肥大化）、これは非常に 深刻な問題 現代のインターネット。

最後に、携帯電話ネットワークのパフォーマンスは通信事業者、地域、時間によって異なります。 図 2 では、2 キロメートルの範囲内のセルにわたる HTTPS トラフィックの遅延の中央値を収集しました。 インドのデリーにある 3 つの大手携帯電話事業者から収集されたデータ。 ご覧のとおり、パフォーマンスはセルごとに異なります。 また、あるオペレーターの生産性は、もう XNUMX 人のオペレーターの生産性とは異なります。 これは、時間と場所、ユーザーのモビリティを考慮したネットワーク エントリ パターン、タワーの密度やネットワーク タイプ (LTE、XNUMXG など) の比率を考慮したネットワーク インフラストラクチャなどの要因によって影響されます。

図 2. 例として半径 2 km を使用した遅延。 デリー、インド。

また、携帯電話ネットワークのパフォーマンスは時間の経過とともに変化します。 図 3 は、曜日ごとの待ち時間の中央値を示しています。 また、XNUMX 日および XNUMX 時間以内の、より小規模な違いも観察しました。

図 3. テール遅延は、同じオペレーターでも日によって大きく異なる場合があります。

上記のすべてにより、ワイヤレス ネットワークでの TCP パフォーマンスが低下します。 ただし、TCP の代替手段を探す前に、次の点について正確に理解する必要がありました。

• アプリケーションのテール レイテンシーの主な原因は TCP ですか?
• 最新のネットワークには、大幅かつ多様なラウンドトリップ遅延 (RTT) がありますか?
• RTT と損失が TCP パフォーマンスに与える影響は何ですか?

TCP パフォーマンス分析

TCP パフォーマンスをどのように分析したかを理解するために、TCP が送信者から受信者にデータをどのように転送するかを簡単に見てみましょう。 まず、送信者は TCP 接続を確立し、XNUMX 方向の通信を実行します。 ハンドシェーク: 送信側は SYN パケットを送信し、受信側からの SYN-ACK パケットを待ってから、ACK パケットを送信します。 TCP 接続の確立には、追加の XNUMX 番目と XNUMX 番目のパスが費やされます。 受信者は各パケットの受信確認 (ACK) を行い、信頼性の高い配信を保証します。

パケットまたは ACK が失われた場合、送信者はタイムアウト (RTO、 再送信タイムアウト）。 RTO は、送信者と受信者の間で予想される RTT 遅延など、さまざまな要因に基づいて動的に計算されます。

図 4. TCP/TLS を介したパケット交換には再送信メカニズムが含まれています。

アプリケーションで TCP がどのように実行されたかを判断するために、次を使用して TCP パケットを監視しました。 tcpdump インドのエッジサーバーからの戦闘トラフィックについてXNUMX週間。 次に、次を使用して TCP 接続を分析しました。 tcptrace。 さらに、実際のトラフィックを可能な限り模倣して、エミュレートされたトラフィックをテスト サーバーに送信する Android アプリケーションを作成しました。 このアプリケーションをインストールしたスマートフォンが数人の従業員に配布され、数日間にわたってログが収集されました。

両方の実験の結果は互いに一致していました。 RTT レイテンシが高かったことがわかりました。 テール値は中央値のほぼ 6 倍でした。 遅延の算術平均は 1 秒を超えます。 多くの接続に損失が発生し、TCP が全パケットの 3,5% を再送信しました。 空港や駅などの混雑したエリアでは、7% の損失が発生しました。 これらの結果は、携帯電話ネットワークで使用されているという従来の通念に疑問を投げかけます。 高度な再送信回路 輸送レベルでの損失を大幅に削減します。 以下は、「シミュレーター」アプリケーションからのテスト結果です。

ネットワークメトリクス
値

RTT、ミリ秒 [50%、75%、95%、99%]
[350、425、725、2300]

RTT 発散、秒
平均約 1,2 秒

不安定な接続でのパケット損失
平均 ~3.5% (過負荷領域では 7%)

これらの接続のほぼ半数で少なくとも 1 つのパケット損失があり、そのほとんどが SYN および SYN-ACK パケットでした。 ほとんどの TCP 実装では、SYN パケットに対して XNUMX 秒の RTO 値が使用されますが、これは後続の損失に対して指数関数的に増加します。 TCP では接続の確立に時間がかかるため、アプリケーションの読み込み時間が長くなる可能性があります。

データ パケットの場合、RTO 値が高いと、ワイヤレス ネットワークに一時的な損失が存在する場合、ネットワークの有効利用が大幅に減少します。 平均再送信時間は約 1 秒で、テール遅延はほぼ 30 秒であることがわかりました。 TCP レベルでのこのような長い遅延により、HTTPS タイムアウトと再要求が発生し、ネットワークの遅延と非効率がさらに増加し​​ました。

測定された RTT の 75 パーセンタイルは約 425 ミリ秒でしたが、TCP の 75 パーセンタイルはほぼ 3 秒でした。 これは、損失により、TCP がデータを正常に送信するために 7 ～ 10 回のパスが必要になったことを示唆しています。 これは、非効率的な RTO 計算、TCP が損失に迅速に対応できないことの結果である可能性があります。 最新のパッケージ 無線損失とネットワーク輻輳による損失を区別しない輻輳制御アルゴリズムの非効率性。 以下は TCP 損失テストの結果です。

TCP パケット損失統計
値

少なくとも 1 つのパケット損失が発生した接続の割合
視聴者の３８%が

接続セットアップ中に損失が発生した接続の割合
視聴者の３８%が

データ交換中に損失が発生した接続の割合
視聴者の３８%が

再送信遅延の分布、秒 [50%、75%、95%、99%] [1、2.8、15、28]

XNUMXパケットまたはTCPセグメントの再送回数の分布
【1,3,6,7]

QUICの応用

もともと Google によって開発された QUIC は、UDP 上で実行されるマルチスレッドの最新のトランスポート プロトコルです。 現在QUICは 標準化プロセス (QUIC にはいわば XNUMX つのバージョンがあるとすでに書きましたが、興味深いのは リンクをたどることができます – 約翻訳者）。 図 5 に示すように、QUIC は HTTP/3 の下に置かれます (実際、QUIC の上にある HTTP/2 は HTTP/3 であり、現在集中的に標準化が進められています)。 UDP を使用してパケットを形成することで、HTTPS 層と TCP 層を部分的に置き換えます。 TLS は QUIC に完全に組み込まれているため、QUIC は安全なデータ転送のみをサポートします。

図 5: QUIC は、以前 HTTP/3 で実行されていた TLS に代わって、HTTP/2 で実行されます。

TCP 増幅に QUIC を使用することを確信した理由は次のとおりです。

• 0-RTT 接続の確立。 QUIC を使用すると、以前の接続からの承認を再利用できるため、セキュリティ ハンドシェイクの数が削減されます。 将来は TLS1.3 は 0-RTT をサポートしますが、引き続き XNUMX ウェイ TCP ハンドシェイクが必要です。
• HoL ブロッキングを克服します。 HTTP/2 はパフォーマンスを向上させるためにクライアントごとに XNUMX つの TCP 接続を使用しますが、これにより HoL (ヘッドオブライン) ブロッキングが発生する可能性があります。 QUIC は多重化を簡素化し、リクエストをアプリケーションに独立して配信します。
• 輻輳制御。 QUIC はアプリケーション層に存在し、ネットワーク パラメータ (損失数または RTT) に基づいて送信を制御するメインのトランスポート アルゴリズムを簡単に更新できます。 ほとんどの TCP 実装では、次のアルゴリズムが使用されます。 キュービックこれは、遅延の影響を受けやすいトラフィックには最適ではありません。 最近開発された次のようなアルゴリズム BBR、ネットワークをより正確にモデル化し、遅延を最適化します。 QUIC を使用すると、BBR を使用し、使用に応じてこのアルゴリズムを更新できます。 改善.
• 損失の補充。 QUIC は XNUMX つの TLP を呼び出します (テールロスプローブ) RTO がトリガーされる前 - 損失が非常に顕著な場合でも。 これは TCP 実装とは異なります。 TLP は主に最後のパケット (または、存在する場合は新しいパケット) を再送信して、高速補充をトリガーします。 テール遅延の処理は、Uber のネットワーク運用方法、つまり、短時間、散発的、遅延の影響を受けやすいデータ転送の場合に特に役立ちます。
• 最適化されたACK。 各パケットには固有のシーケンス番号があるので問題ありません 区別 パケットが再送信されるとき。 ACK パケットには、パケットを処理してクライアント側で ACK を生成する時間も含まれています。 これらの機能により、QUIC は RTT をより正確に計算できます。 QUIC の ACK は最大 256 バンドをサポートします ナックこれにより、送信側のパケット シャッフルに対する耐性が向上し、プロセスで使用するバイト数が減ります。 選択的ACK (袋TCP の ) では、すべての場合にこの問題が解決されるわけではありません。
• 接続の移行。 QUIC 接続は 64 ビット ID によって識別されるため、クライアントが IP アドレスを変更した場合でも、古い接続 ID は中断することなく新しい IP アドレスで引き続き使用できます。 これは、ユーザーが Wi-Fi 接続とセルラー接続を切り替えるモバイル アプリケーションでは非常に一般的な方法です。

QUICの代替手段

QUIC を選択する前に、問題を解決するための代替アプローチを検討しました。

私たちが最初に試みたのは、TPC PoP (Points of Presence) を展開して、ユーザーの近くで TCP 接続を終了することでした。 基本的に、PoP はセルラー ネットワークに近いモバイル デバイスとの TCP 接続を終了し、トラフィックをプロキシして元のインフラストラクチャに戻します。 TCP をより近くで終了することで、RTT を削減できる可能性があり、動的なワイヤレス環境に対する TCP の応答性が向上します。 ただし、私たちの実験では、RTT と損失のほとんどはセルラー ネットワークから発生しており、PoP の使用では大幅なパフォーマンスの向上が得られないことがわかりました。

TCP パラメータの調整についても検討しました。 TCP は OS バージョンごとに実装が異なるため、異種エッジ サーバーに TCP スタックをセットアップするのは困難でした。 これを実装してさまざまなネットワーク構成をテストするのは困難でした。 権限がないため、モバイル デバイスで TCP を直接構成できませんでした。 さらに重要なのは、0-RTT 接続や改善された RTT 予測などの機能はプロトコルのアーキテクチャにとって重要であるため、TCP だけを調整するだけでは大きな利点を達成することは不可能です。

最後に、ビデオ ストリーミングのトラブルシューティングを行ういくつかの UDP ベースのプロトコルを評価しました。これらのプロトコルが今回のケースで役立つかどうかを確認したかったのです。 残念ながら、多くのセキュリティ設定が大幅に欠如しており、メタデータと制御情報のために追加の TCP 接続も必要でした。

私たちの調査によると、セキュリティとパフォーマンスの両方を考慮しながら、インターネット トラフィックの問題を解決できる唯一のプロトコルは QUIC である可能性があります。

QUICのプラットフォームへの統合

QUIC をうまく埋め込み、接続状態が悪い環境でアプリケーションのパフォーマンスを向上させるために、古いスタック (TLS/TCP 上の HTTP/2) を QUIC プロトコルに置き換えました。 ネットワークライブラリを利用しました クロネット の クロムプロジェクト、これには、元の Google バージョンのプロトコル - gQUIC が含まれています。 この実装も、最新の IETF 仕様に準拠するために継続的に改善されています。

まず、QUIC のサポートを追加するために Cronet を Android アプリに統合しました。 統合は、移行コストを可能な限り削減する方法で実行されました。 ライブラリを使用していた古いネットワーク スタックを完全に置き換えるのではなく、 OKHTTP、OkHttp API フレームワークの下に Cronet を統合しました。 この方法で統合を行うことで、ネットワーク呼び出し ( 組み込む) API レベルで。

Android デバイスのアプローチと同様に、iOS 上の Uber アプリに Cronet を実装し、ネットワークからの HTTP トラフィックを傍受しました。 API使い方 NSURLプロトコル。 iOS Foundation によって提供されるこの抽象化は、プロトコル固有の URL データを処理し、多額の移行コストをかけずに Cronet を iOS アプリケーションに統合できるようにします。

Google Cloud Balancer で QUIC を完了する

バックエンド側では、QUIC 完了は Google Cloud 負荷分散インフラストラクチャによって提供されます。 alt-svc QUIC をサポートするための応答内のヘッダー。 一般に、バランサーは各 HTTP リクエストに alt-svc ヘッダーを追加します。これにより、ドメインの QUIC サポートがすでに検証されます。 Cronet クライアントは、このヘッダーを持つ HTTP 応答を受信すると、そのドメインへの後続の HTTP 要求に QUIC を使用します。 バランサーが QUIC を完了すると、インフラストラクチャはこのアクションを HTTP2/TCP 経由でデータ センターに明示的に送信します。

パフォーマンス: 結果

より良いプロトコルを探す主な理由は、出力パフォーマンスです。 まずはスタンドを作りました ネットワークエミュレーションさまざまなネットワーク プロファイルの下で QUIC がどのように動作するかを調べます。 実際のネットワーク上で QUIC のパフォーマンスをテストするために、乗客用アプリの HTTP 呼び出しによく似たエミュレートされたネットワーク トラフィックを使用して、ニューデリーを運転しながら実験を実行しました。

実験1

実験用の設備：

• OkHttp スタックと Cronet スタックを使用して Android デバイスをテストし、それぞれ TCP および QUIC 経由の HTTPS トラフィックが許可されていることを確認します。
• Java ベースのエミュレーション サーバーは、応答で同じタイプの HTTPS ヘッダーを送信し、クライアント デバイスをロードしてクライアントからのリクエストを受信します。
• TCP および QUIC 接続を終了するためにインドの近くに物理的に配置されたクラウド プロキシ。 TCP 終端にはリバース プロキシを使用しましたが、 nginxの、QUIC 用のオープンソース リバース プロキシを見つけるのは困難でした。 私たちは、Chromium の基本的な QUIC スタックを使用して、QUIC 用のリバース プロキシを自分たちで構築しました。 公開 それをオープンソースとして Chrome に組み込みます。

図 6. TCP と QUIC のロード テスト スイートは、OkHttp と Cronet を備えた Android デバイス、接続を終了するクラウド プロキシ、およびエミュレーション サーバーで構成されていました。

実験2

Google が QUIC を利用できるようにしたとき Googleクラウド負荷分散同じインベントリを使用しましたが、変更が XNUMX つありました。NGINX の代わりに Google ロード バランサを使用して、デバイスからの TCP および QUIC 接続を終了し、HTTPS トラフィックをエミュレーション サーバーにルーティングしました。 バランサーは世界中に分散されていますが、(位置情報のおかげで) デバイスに最も近い PoP サーバーを使用します。

図 7. XNUMX 番目の実験では、Google Cloud を使用した場合とクラウド プロキシを使用した場合で、TCP と QUIC の完了レイテンシを比較したいと考えました。

その結果、いくつかの事実が私たちを待っていました。

• PoP 経由の終端により、TCP パフォーマンスが向上しました。 バランサーはユーザーの近くで TCP 接続を終了し、高度に最適化されているため、RTT が低下し、TCP パフォーマンスが向上します。 また、QUIC はそれほど影響を受けませんでしたが、テール レイテンシーの短縮 (10 ～ 30%) という点では TCP よりも優れたパフォーマンスを示しました。
• 尾が影響を受ける ネットワークホップ. 当社の QUIC プロキシは、Google のロード バランサよりもデバイスから離れていましたが (レイテンシが約 50 ミリ秒高かった)、同様のパフォーマンスを実現しました。15 パーセンタイルでの TCP の 20% 削減に対して、TCP では 99% のレイテンシ削減でした。 これは、ラスト マイルの移行がネットワークのボトルネックであることを示唆しています。

図 8: XNUMX つの実験の結果は、QUIC が TCP よりも大幅に優れていることを示しています。

戦闘交通

実験からインスピレーションを得て、Android および iOS アプリケーションに QUIC サポートを実装しました。 Uber が事業を展開している都市で QUIC の影響を判断するために A/B テストを実施しました。 一般に、両方の地域、通信事業者、ネットワークの種類にわたってテール遅延が大幅に減少していることがわかりました。

以下のグラフは、マクロ領域およびさまざまなネットワーク タイプ (LTE、95G、99G) ごとのテール (3 および 2 パーセンタイル) の改善率を示しています。

図 9. 実戦テストでは、QUIC は遅延の点で TCP を上回りました。

転送のみ

おそらくこれはほんの始まりにすぎません。QUIC の運用環境へのリリースにより、安定したネットワークと不安定なネットワークの両方でアプリケーションのパフォーマンスを向上させる素晴らしい機会が提供されました。

適用範囲の拡大

実際のトラフィックでのプロトコルのパフォーマンスを分析したところ、セッションの約 80% が QUIC の使用に成功していることがわかりました。 すべて 一方、セッションの 15% は QUIC と TCP の組み合わせを使用していました。 この組み合わせは、Cronet ライブラリが実際の UDP 障害と劣悪なネットワーク状態を区別できないため、TCP にタイムアウトすることが原因であると考えられます。 現在、今後の QUIC の実装に向けて、この問題の解決策を検討中です。

QUICの最適化

モバイル アプリからのトラフィックは遅延の影響を受けますが、帯域幅の影響は受けません。 また、当社のアプリケーションは主に携帯電話ネットワークで使用されます。 実験によると、プロキシを使用してユーザーの近くで TCP と QUIC を終了しても、テール レイテンシーは依然として高いことがわかります。 私たちは、輻輳管理を改善し、QUIC 損失回復アルゴリズムの効率を向上させる方法を積極的に模索しています。

これらおよびその他のいくつかの改善により、ネットワークや地域に関係なくユーザー エクスペリエンスを向上させ、世界中で便利でシームレスなパケット転送をよりアクセスしやすくする予定です。

出所： habr.com