WWDC Quick Look 💓 By SwiftGGTeam
Reduce networking delays for a more responsive app

Reduce networking delays for a more responsive app

元の動画を見る

ハイライト

Apple はアプリの応答性をラウンドトリップ時間とラウンドトリップ数の 2 つの要素に分割し、HTTP/3、QUIC 移行、QUIC データグラム、サーバー バッファー チューニング、L4S 互換性テストなどの実装可能な遅延削減方法を提供しています。


主要内容

ネットワークの問題の多くは、帯域幅の不足のように見えます。ビデオ会議がフリーズしたり、画面共有が遅延したり、ビデオジャンプ後に長い再バッファリングが発生したりすると、ユーザーの最初の反応はブロードバンドをアップグレードすることになることがよくあります。セッションの開始時に反例が示されました。帯域幅が 1Mbps から 2Mbps に増加すると、ページの読み込み時間は 40% 近く短縮されました。 4Mbps を超えた後、帯域幅を増加し続けても、ページの読み込み時間はほとんど改善されなくなりました。逆に、ページの読み込み時間は、レイテンシが 20 ミリ秒低下するごとに直線的に改善されます (03:24)。

アプリの速度を実際に低下させる原因は、各ラウンド トリップの長さと、リクエストを完了するまでに必要なラウンド トリップの回数です。通常、キューはネットワーク内の最も遅いリンクにスタックされ、新しいパケットは古いパケットの後ろにキューに入れられる必要があります。TCP 上の TLS 1.2 では、最初の応答パケットを取得するために 4 往復が必要になる場合があります。各往復がキューによって増幅されると、最初のパケット時間が非常に長くなります (02:16)。

Apple が与えたルートは、アプリ側の往復数の削減、サーバー側の無意味なキューの削減、ネットワーク側の L4S のテストの 3 つの層に分かれています。使うだけのアプリURLSessionNetwork.framework は、サーバーの起動時に IPv6、TLS 1.3、および HTTP/3 を自動的に使用できます。 QUIC を使用している場合は、接続の移行とデータグラム フローを有効にすることもできます (04:45)。

サーバーによって遅延が発生することもあります。セッションでは、例として WWDC ビデオのランダム ジャンプを使用します。サーバーの TCP、TLS、HTTP バッファーはそれぞれ 4MB、256KB、4MB に構成されています。新しく生成されたデータ パケットは古いデータの後ろでキューに入れられるため、ビデオがジャンプした後に長い黒い画面が表示されます。HTTP、TLS、および TCP バッファーを 256KB、16KB、および 128KB に削減した後、再度ジャンプした後、すぐに再生を再開できます (09:36)。

詳細

HTTP/3 を採用し、接続の移行を可能にする

(06:03) モバイル デバイスは、Wi-Fi からセルラー ネットワークに切り替えることがよくあります。通常の接続を再確立する必要があり、アプリが一時停止します。HTTP/3 は QUIC に基づいており、接続の移行をサポートしています。のためにURLSession、Session によって与えられるオプトイン メソッドは非常に短いです。

let configuration = URLSessionConfiguration.default
configuration.multipathServiceType = .handover

キーポイント:

  • URLSessionConfiguration.defaultデフォルトのセッション構成を作成すると、後続のリクエストは引き続きシステム ネットワーク スタックを通過できます。
  • multipathServiceType = .handoverWi-Fi からセルラーに切り替えるときの停止を減らすことを目的として、ネットワークを切り替えるときに接続を移行できるようにします。
  • サーバーは HTTP/3 をサポートする必要があります。アプリ側で使用されるURLSessionその後、プロトコルの選択は、利用可能な場合にはシステムによって処理されます。

Network.framework を直接使用して QUIC 接続を作成する場合、同じ機能がNWParameters優れた:

let parameters = NWParameters.quic(alpn: ["myproto"])
parameters.multipathServiceType = .handover

キーポイント:

  • NWParameters.quic(alpn:)QUICパラメータを作成し、alpnアプリケーション層のプロトコル名を宣言するために使用されます。
  • multipathServiceType = .handoverハンドオーバー モードをオンにして、ネットワークが変化したときに接続を可能な限り継続的に維持します。
  • 接続の移行は実際のプロトコルとサーバーの展開とともにテストする必要があるため、セッションを有効にした後、独自のアプリで検証することをお勧めします。

UDP を直接使用する代わりに QUIC データグラムを使用する

(06:39) iOS 16 と macOS Ventura は、カスタム プロトコルが UDP を直接使用する場合、QUIC データグラムを提供します。データグラムの使用方法を維持しながらネットワークの輻輳に対応し、ラウンドトリップ時間を低く抑え、パケット損失を軽減します。

// Only one datagram flow can be created per connection
let options = NWProtocolQUIC.Options()
options.isDatagram = true
options.maxDatagramFrameSize = 65535

キーポイント:

  • 接続ごとに作成できるデータグラム フローは 1 つだけであるため、プロトコル設計に影響することに注意してください。
  • NWProtocolQUIC.Options()QUICプロトコルオプションを作成します。
  • options.isDatagram = trueこの QUIC フローがデータグラム モードを使用することを宣言します。
  • options.maxDatagramFrameSize = 65535許可される最大データグラム フレーム サイズを設定します。
  • データグラムフローを作成した後は、通常の QUIC ストリームと同様にデータを送受信できます。

networkQuality を使用してサーバー キューを確認する

(07:49) macOS Monterey によって導入されたネットワーク品質ツールは、サービス プロバイダーのネットワークまたは独自のサーバーをテストできます。方法としては、まずテスト先としてサーバーを設定し、次に Apple のデフォルトサーバーと独自サーバーをそれぞれテストします。デフォルトのサーバーのスコアが高く、自分のサーバーのスコアが低い場合、問題はサーバー側でキューに入れられている可能性があります。

networkQuality -s -C https://myserver.example.com/config

キーポイント:

  • networkQualitymacOS用のネットワーク品質テストツールです。
  • -sツールをサーバー テスト モードで実行します。
  • -C https://myserver.example.com/configテストサーバー構成をポイントします。
  • デフォルトのサーバーと独自のサーバーでセッションを 1 回ずつ実行して、応答性スコアを比較することをお勧めします。

Apple はまた、外部検証に利用できる 3 つのテスト ポータルもリストしています。

https://www.waveform.com/tools/bufferbloat
https://github.com/network-quality/goresponsiveness
https://www.speedtest.net/

キーポイント:

  • Waveform は、キューイングによって引き起こされる遅延を観察するための Bufferbloat テストを提供します。
  • goresponsiveness応答性テストの Go オープンソース実装です。
  • Ookla Speedtest アプリは応答性測定を追加し、往復時間を表示します。

サーバーのバッファー サイズを減らす

(09:36) セッションビデオジャンプの場合、サーバーバッファが大きすぎます。新しいデータは古いデータによってブロックされ、ユーザーには再バッファが表示されます。Apple は、Apache Traffic Server の TCP、TLS、HTTP/2 バッファリング動作を削減します。

% cat /opt/ats/etc/trafficserver/records.config

# Set not-sent low-water mark trigger threshold to 128 kilobytes
CONFIG proxy.config.net.sock_notsent_lowat INT 131072

# Set Socket Options flag to the sum of the options we want
# TCP_NODELAY(1) + TCP_FASTOPEN(8) + TCP_NOTSENT_LOWAT(64) = 73
CONFIG proxy.config.net.sock_option_flag_in INT 73

...

# Enable Dynamic TLS record sizes
CONFIG proxy.config.ssl.max_record_size INT -1

...

# Reduce low-water mark and buffer block size for HTTP/2
CONFIG proxy.config.http2.default_buffer_water_mark INT  32768
CONFIG proxy.config.http2.write_buffer_block_size   INT 262144

キーポイント:

  • proxy.config.net.sock_notsent_lowatTCP 未送信最低水準点を 128KB に設定します。
  • sock_option_flag_in組み合わせ可能TCP_NODELAYTCP_FASTOPENそしてTCP_NOTSENT_LOWAT
  • proxy.config.ssl.max_record_size INT -1動的 TLS レコード サイズを有効にします。
  • proxy.config.http2.default_buffer_water_markHTTP/2 の最低水準点を下げます。
  • proxy.config.http2.write_buffer_block_sizeHTTP/2書き込みバッファのブロックサイズを調整します。
  • 他の Web サーバーを使用する場合は、ATS 構成名をコピーするのではなく、同等の構成を検索する必要があります。

L4S 互換性をテストする

(14:50) L4S は、Apple がネットワーキング コミュニティと協力して開発した低遅延テクノロジであり、iOS 16 および macOS Ventura でベータ版として利用できます。これにより、送信側はキューを短く保ち、輻輳損失ゼロを達成することを目標に、明示的な輻輳信号を通じてレートを調整できます。

macOS Ventura では、Session によって指定されたdefaults コマンドを使用してテストを開始できます。

defaults write -g network_enable_l4s -bool true

キーポイント:

  • defaults write -gグローバル設定を書き込みます。
  • network_enable_l4smacOS Ventura で L4S ベータ テストを有効にするために使用されるスイッチです。
  • -bool trueこのスイッチをオンに設定します。
  • iOS 16 の対応する入り口は開発者設定にあります。
  • Linux サーバーを使用して QUIC をテストする場合、QUIC 実装は正確な ECN とスケーラブルな輻輳制御アルゴリズムをサポートする必要があります。

重要ポイント

  • ビデオまたはライブ ブロードキャスト サービスのサーバー応答性検査を追加:networkQuality -s -Cオンラインにする前に確認してください。最初に Apple のデフォルト サーバーをテストし、次に独自のサーバーをテストします。2 つの間のギャップが大きい場合は、TCP、TLS、および HTTP バッファーが最初にチェックされます。

  • リアルタイム コラボレーション アプリのネットワーク切り替えテスト ケースを追加: Wi-Fi とセルラーを切り替えて、進行中のリクエストや QUIC 接続が停止するかどうかを観察します。URLSessionConfiguration.multipathServiceType = .handover一番小さな入口です。

  • カスタム UDP プロトコルを QUIC データグラム実験ブランチに移行します: データグラム データ モデルを保持し、使用しますNWProtocolQUIC.Optionsデータグラム フローを有効にして、輻輳シナリオでの往復時間とパケット損失の変化を確認します。

  • 画面共有またはリモート コントロール アプリの L4S 互換性テストを確立: iOS 16 開発者設定または macOS Ventura のデフォルトで L4S を有効にし、実際のインタラクション プロセスを実行して、メニューの応答、カーソルの動き、画面の更新時間の差を記録します。

  • RPM をネットワーク エクスペリエンス インジケーターとして扱う: Ookla が往復時間を表示した後、次を使用できます。60000 / RTT(ms)1 分あたりの往復回数を取得します。この指標は、ダウンロード速度だけよりも、ビデオ会議、画面共有、検索候補のエクスペリエンスとより密接に一致しています。

関連セッション

コメント

GitHub Issues · utterances