L4Sによるネットワーク遅延の削減

♪ ♪

こんにちは Shawnです Internet Technologiesチーム のエンジニアです L4Sを使用して アプリのネットワーク遅延を 軽減する方法についてお話しします L4Sは低遅延で低損失 かつ スケーラブルなスループット を意味します ネットワーク遅延が ユーザーエクスペリエンスに 影響を与える場合に アプリのパフォーマンスを 劇的に向上させる素晴らしい技術です コンテンツ読み込み時間の短縮 ビデオ品質の向上 ユーザー間のより応答性の高い コラボレーションを実現します

今日はまずL4Sがどう機能し ネットワーク遅延を どう軽減するか見ていきます 次に アプリをL4S用に準備する方法と サーバー上でL4Sを 有効にする方法を説明します 最後にL4Sネットワークを構成し アプリをテストするための 手順を説明します まずL4Sの利点と その仕組みを見てみましょう

混雑したネットワークは特に リアルタイムオーディオや ビデオなどを扱う アプリにとっては課題です ネットワークが同時に 多数のデバイスに使用されると この種のアプリでは 多くの場合 長い遅延や パケット損失が 発生する可能性があります 例えばビデオ通話中に 同じネットワークを使用して 他の人が映画を見たり ゲームをダウンロードすると ビデオが遅延したり 停止したりします このような状況でL4Sが どう役立つかお伝えします 2つのデバイス間で ビデオ通話を行う サンプルアプリを作成しました サンプルアプリでは 異なる時間に行われた 2つのビデオ通話を紹介します 片方はL4Sなし もう一方はL4Sありです これら両方の通話では 同じように制約された 帯域幅が狭い ネットワークを使用しています さらに同じネットワークを 同時に使用している 他の複数のデバイスもあります 実際に見てみましょう 2つの通話のビデオ品質に 顕著な違いがあることがわかります 従来のバージョンでは 特に動作中に ビデオの停止や遅延が 発生することがあります L4Sを使用すると ビデオはスムーズで応答性が高く 大幅な遅延はありません 何が起きていたのかを理解するために 今 目撃したビデオ通話を 分析してみましょう L4Sによってアプリは すべての主要な ネットワークメトリクスにおいて 大幅な改善を達成しました まずはこれらの ビデオ通話中のパケットの 往復時間の 分布を見てみましょう 往復時間が短いほど ネットワーク上の遅延が低く 良好であることを示します このような対話型アプリの場合 テールレイテンシは ユーザーが経験する 最悪のケースを示すのに非常に重要です テストネットワークの 最小往復時間は 20ミリ秒です L4Sを使用しない場合 パケットの往復時間は 最大45ミリ秒かかりました L4Sがオンの場合 最悪の場合の遅延は 50%カットされました 25ミリ秒未満に短縮されます

次にパケットロスについて 見てみましょう パケットロスが少ないほど デバイス間の接続の 信頼性が高くなります 従来のものでは パケットロス率40%以上でした L4Sを使用するとビデオ通話での パケットロスはほぼなくなりました データ損失によるフレームの ドロップや停止が大幅に減少します 遅延とパケット損失率の改善は ビデオ通話の レンダリング指標の向上 に直接つながりました ビデオストールの割合を見てみましょう ストール率が低いほど ビデオ通話中のフリーズが少なくなります L4Sを使用しないと アプリでビデオが 時々停止することがありました しかしL4Sを使用すると ビデオの停止がほぼ排除されました

次に受信ビデオの フレームレートを見てみましょう 受信ビデオフレームレートが より高くより安定しているのは より豊かでスムーズな ビデオコールを意味します L4Sでは ほとんどの場合 受信ビデオフレームレートが 25フレーム/秒を超えていました ただし従来のバージョンでは 1秒あたりのフレーム数が 0フレームにまで低下することがあり ビデオが完全に停止することを意味します これらの改善により 制約のあるネットワークでも ユーザーエクスペリエンス が大幅に向上しました L4Sを採用することで これと同じ改善を アプリにもたらすことができます それではL4Sが どのように機能するかを見てみましょう

L4Sによってキューイングと パケット損失が軽減されるため このような顕著な改善が見られます まずネットワーク内でキューが どのように構築されるかを見てみましょう パケットがアプリから送信されると 異なるネットワークホップ を経由してルーティングされます サーバーに到達する前に パケットが通過するこの一連のホップは ネットワークパスと呼ばれます

ネットワークを介したパスでは ボトルネックと呼ばれる 最も遅いホップで サポートされるレートによって エンドツーエンドでのみ データを配信できます 多くの人にとって これはインターネットサービス プロバイダ接続であり パケットを処理できる最高速度が パスでサポートされる 最大スループットを決定します 送信者が最大スループットを超えると ボトルネックでキューが形成され 後続のパケットに遅延が発生します L4Sがないと キューがこれ以上 パケットを収容できなくなるまで キューは増大し続けます これが発生すると パケットがドロップされ 遅延とスループットの 両方に悪影響を及ぼします L4Sはクライアントやサーバー そしてボトルネック間の 連携を通じて この問題を解決します L4Sではパケットを送信する クライアントまたはサーバーは ネットワークの輻輳の管理に協力することを シグナルする必要があります

これを行うために L4S対応の送信者は 明示的輻輳通知(ECN) と呼ばれるテクノロジーを使用します パケットを送信するとき 送信者はパケットの IPヘッダーのECNビットを使用して L4Sのサポートを示します L4Sホップが これらのパケットを受信すると L4Sキュー管理が適用されます

キューがボトルネックに集まり始めると L4Sキュー管理はパケットに 異なるECNラベルを設定し 輻輳が発生していることを示します このラベルは 次のホップに転送する前に ネットワークで輻輳が 発生したことを示します 受信者はこれらのパケットを受信すると 輻輳ラベルが付けられた パケットの数をカウントし 送信者にその数を報告します 送信者はこの番号を受信すると このフィードバックを使用して ネットワーク上の輻輳を理解します 次に送信側は ボトルネックの輻輳レベルに応じて 送信レートを調整し 最大スループットを 超えないようにします 送信レートを調整することで 送信者はボトルネックで 大量のパケットのキューを 構築することを回避できます これにより L4S のスループットを最大化し 同時にエンドツーエンド の低遅延を実現します ここで このコラボレーションを 可能にしてこれらの利点を ユーザーに提供するために 何をするべきか見てみましょう まず アプリをL4S用に 準備する方法について説明します URLSessionや Networkフレームワークで ネットワークAPIを使用することは アプリにL4Sを導入する最良の方法です アプリがフレームワーク内で HTTP/3またはQUICを 使用する場合 L4Sサポートは 自動的に組み込まれます アプリのコードを 変更する必要はありません アプリがHTTP/2 またはTCPを使用する場合 iOS 17とmacOS Sonomaに これらのプロトコルの ダウンロード用の L4Sサポートが組み込まれます コードを変更する必要がないため アプリにL4Sサポートを 追加する最良の方法です ただしアプリがカスタムプロトコルを 使用している場合は アプリでL4Sをサポートするために 実装するものがいくつかあります RFC 9330は L4S要件について 学ぶための良い出発点です いくつかの新しい動作を 実装する必要があります プロトコルは L4S輻輳フィードバックを ネットワークから取得し それに応じて 送信レートを調整しています これを行うにはスケーラブルな 輻輳制御アルゴリズムの実装が必要です 次に ネットワークがECNビットの 通過を許可する場合のみ アプリがL4Sトラフィックを 送信するようにします これを行うにはECNブリーチングなど ECNに干渉する可能性のある ネットワークの問題をチェックする ECN検証メカニズムを実装します 受信者として機能する場合 プロトコルにはネットワークの ECNフィードバックを 送信者にエコーバックする 中継メカニズムも必要です 実装がネットワークフレームワーク に基づいている場合は パケットのメタデータで ECNプロパティを使用して カスタムプロトコルの ECNフラグを送受信できます ソケットを使用している場合は ソケットの設定オプションを使用するか メッセージシステムコールを送受信して ECNフラグを送受信できます

アプリをL4S用に 準備する方法を説明しました 次にサーバーをセットアップ する方法を見てみましょう アプリがQUICを使用する場合 サーバーのQUIC実装もL4Sと ECNマーキングを サポートする必要があります サーバー側で使用できる QUIC実装は多数あります ECNとL4Sを有効にする方法については サーバープロバイダに問い合わせて下さい L4Sトラフィックの送信を まだサポートしていない場合でも ECNがサーバー上でL4Sトラフィックを 受信できるようにすることができます 今こそL4Sをサポートするよう 奨励する絶好の機会です

アプリがTCPを使用している場合は サーバーのTCP実装に L4Sサポートを追加する 必要があります Linuxベースのサーバーの場合 GitHubページの指示に従い サーバーにサポートを加えます この動画の 関連項目の記事でも 詳細をご覧いただけます 他のすべてのサーバー プラットフォームについては サーバープロバイダに問い合わせて L4Sのサポートに 追加の設定や変更をしてください アプリとサーバーをL4S用に 設定する方法を解説しました アプリをテストするために L4Sネットワークを設定しましょう ネットワークがL4S対応 になる理由を確認します ネットワークはECN マーキングをブロックしません ECNマーキングは送信者- ボトルネック-受信者の間で ネットワークに関する情報を 通信するため使用されます ネットワークがECNマーキングと 干渉する際にL4Sは機能しません ドキュメントには 実行できる手順と ネットワークがECNと 互換性があるかどうか検証する 追加のツールが記載されています ネットワークのボトルネックはL4S キュー管理をサポートする必要があります これはL4Sの利点を 理解するために不可欠です ネットワークがECNと 互換性があることを確認したら ボトルネックにL4Sキュー 管理を追加するだけです キュー管理をサポートする テストネットワークを設定するには インターネット共有を 使用するのが最善の方法です

macOS Sonomaではネット共有は L4Sキュー管理をサポートします インターネット共有を使用して Macによって作成されたネットワークに デバイスが参加すると Mac自体が デバイスとサーバー間の 追加のネットワークホップになります Macがネットワーク上の ボトルネックになるように設定すると 通過するトラフィックに L4Sキュー管理が適用され 完全なL4Sネットワーク を構築できます macOSでインターネット共有 を有効にするには システム設定の インターネット共有ペインに移動します 開示ボタンをクリックして テストデバイスが接続する インターフェイスを選択します

Macがネットワーク上で ボトルネックとして機能するには その帯域幅を 調整する必要があります 共有するインターフェイスと デバイスが接続するインターフェイスで ターミナルでこの ifconfigコマンドを使用します このコマンドのインターフェイス名を 使用するインターフェイス の名前に置き換えます たとえばen1です 次にテストデバイスで ネットワークに参加し アプリをテストして L4Sの利点を確認します Macでの帯域幅 スロットリングを元に戻すには 再起動するか同じifconfig コマンドを実行します ただし帯域幅を10メガビット/秒 ではなく0に変更します

iOS 17および macOS Sonomaでは L4Sはランダムなユーザー セットに段階的に展開されます テストデバイスでL4S をオンにするよう確認するために に移動して L4Sをオンにしてください macOSではテスト前に デフォルトの書き込みコマンドを 実行してL4Sを有効にします ネットワークまたはサーバーが L4S をサポートしていない場合は TCPとQUICは引き続き レガシーモードで動作します ただしL4Sをオンにして アプリケーションをテストし 問題を特定する必要があります 問題が発生した場合は フィードバックアシスタントを使用し フィードバックを提供します このドキュメントにはアプリでの L4Sのデバッグと テストに関する役立つ 情報も記載されています L4Sで アプリとネットワークを サポートし遅延と パケット損失を削減できることを とても嬉しく思います

L4Sをサポートする ネットワーク上のiOS 17や macOS Sonomaで アプリを今すぐテストしてください それ以外のネットワークでも同様です サーバーやCDNプロバイダ と共にアプリのサーバーで L4Sのサポートをまだ有効にしていない 場合は 有効にしてください アプリでL4Sが有効な際に 発生した問題があれば フィードバックアシスタントで ご報告ください ご視聴ありがとうございました L4Sを使用して 皆さんと優れた アプリを構築することを楽しみにしています ♪ ♪