ネットワーク遅延を減らしてAppの応答性を向上させる

最新のネットワークスループットレートを最大限に活用することで、ネットワークレイテンシがご利用のAppにどう影響するのかご覧ください。応答性を向上させるためにAppやサーバで行う変更について解説します。インターネットの改善が行われたときにご利用のAppが対応できるようにしておくことで、エンドツーエンドの遅延を低減させることができるようになります。

リソース

関連ビデオ

WWDC23

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

WWDC22

Push to Talkで音声通信を強化する

WWDC21

ダウンロード

♪メロウなインストゥルメンタルヒップホップ音楽♪ ♪ Vidhi Goelですこのビデオでは Appのネットワークのディレイを短縮し反応を良くする方法を説明しますまずAppの反応になぜレイテンシーの縮小が重要か次にAppでできるリストまたサーバ上で不必要なディレイをなくす方法を説明します最後にネットワーク自体でディレイ縮小でできることを説明しますネットワークレイテンシーはデータ移動にかかる時間です Appにコンテンツをどれだけ速く配信できるかを左右しますネットワーク処理遅延はネットワークを使用するすべてのAppに影響します App体験を損ないます例えばビデオ通話が時々フリーズしたり遅れが発生し会議を妨げてしまいます多くの場合サービス・プロバイダで帯域幅をアップグレードしますが問題はまだ解決できませんこの問題の根本的原因を理解するには Appパケットがどのようにネットワークを移動するか知る必要があります App フレームワークがサーバーデータを要求しパケットがネットワークのスタックから送信されます多くの場合パケットは直接ディレイなくネットワークでサーバーに送信されると思われますしかし実際には最も遅いリンクに通常パケット処理の大きなキューがあります Appからのパケットはこの大きなキューの処理が終わるまで処理できません最も遅いリンクのキューで Appとサーバー各往復に時間がかかりますこの問題は多数の往復で悪化し Appリクエストに最初のレスポンスを得るまで長くかかります例えばTCP TLS 1.2を使用し最初のレスポンスパケットまでの時間は 4つのトリップを掛けた各往復の時間ですネットワークキューによって毎往復の時間が既に膨張しているため結果として総使用時間は長すぎるのです Appの反応には 2つの相補要因があります各往復の期間また往復の数ですこれらを縮小すればレイテンシーが下がり App反応が改善されます帯域幅増加とレイテンシー減少とページ・ロード時間のインパクト研究があります最初のテストでレイテンシーは固定で帯域幅は1から10Mb/sまで漸増的に増加します初めは帯域幅は1から2Mb/sまで増加しページ・ロードはおよそ 40パーセント短縮されますすばらしいですねしかし4Mb/sの後ページ・ロードはほとんど改善がありませんでしたこのためAppはギガビットにアップグレードしても遅いのです他方レイテンシー・テストでレイテンシーが 20ミリセカンド減少するごとにページ・ロードは線形の改善があります結果はAppのすべてのネットワーク活動に適用されます App反応完全とレイテンシー短縮の簡単な方法はIPv6 TLS 1.3また HTTP/3など最新のプロトコルの採用ですAppで URLSessionと Network. framework API を使用するとプロトコルはサーバ上で有効化すると自動的に使用されます公開以来1年以内にHTTP/3使用は一貫して増加しましたウェブの20パーセントが既にHTTP/3で成長し続けていますサファリの異なるHTTPバージョン比較で HTTP/3は最も高速でした HTTP/3リクエストはHTTP/1と比較し時間が半分ですラウンド・トリップ時間の倍数としてリクエスト完了時間のメジアンを見た場合です Appのリクエストがはるかに速くなりますデバイスがWiFiからセルに移動する場合新しい接続には時間がかかり Appが失速します接続退避の使用で失速を除去できます URLSessionあるいはNWParametersで multipathServiceTypeプロパティを .handoverに設定します Appでこのオプションの作動を確かめます UDPを直接使用するプロトコル設計で iOS 16 macOS Venturaはデータグラムの送信でよりよい方法を導入しました QUICデータグラムは平易なUDPの多く利点を提供し最も重要なのはQUICデータグラムがネットワーク中で混雑に反応し往復の時間を維持するかパケット・ロスを縮小しますクライアント選択で isDatagramをQUICオプション上で Trueに設定し最大のデータグラムフレーム・サイズを設定しますデータグラム・フローを作成した後 QUICストリームと同じく送受信ができます Appレイテンシーの縮小がわかりました次にサーバはAppの反応にどのように影響があるか説明します多くの場合ハードウェアはよいにもかかわらずサーバがAppを遅くしています macOSモンテレーはネットワーク品質ツールが導入されましたサービス・プロバイダーネットワークとサーバのバッファを測定しますネットワーク品質ツールの目的地としてサーバを構成します networkQualityツールを実行しますまずアップルの既定のサーバにその後構成サーバです既定のサーバのツールスコアが良く自分のサーバーで悪い場合サーバ反応を改善する余地があるかもしれませんこのテクニックを使用した改善例ですそれはストリームビデオです

ビデオをスキップしても遅延のバッファで結局遅かった経験があるでしょうランダム・アクセスでこの緩慢の理由を調査しましたネットワーク品質ツールでストリーミングサーバの挙動のテストで反応スコアはよくありませんでした右はWWDCビデオを流しビデオをスキップしてもスクリーンはビデオのデバッファ中に何も表示しませんでした数秒後にビデオが表示されました macOSの上でネットワーク品質ツールから詳細な出力でサーバのキューが大きいことが原因とわかりサーバ設定をチェックしました特にTCP TLS またHTTPバッファサイズです 4MB 256K 4MBまでの構成で RAMが大きくバッファは巨大でしたバッファがよくてもバッファを増やすことがよりよいとは限りません反応測定はこの問題を強調します新しく生成したパケットはこれらの大きなバッファで古いデータ後にキューされ最新パケットでディレイが増えてしまいました HTTPのバッファサイズを256Kに TLSは16K TCPは128Kに縮小しました

Apache Traffic Serverコンフィグ・ファイルのオプションを示します TCP未送信マークは128Kにセットされオプションで低バッファを有効化しました TLSで動的なレコード・サイズを有効化しまたHTTP/2のマークおよびバッファブロック・サイズを縮小しましたこれらの設定をApache Traffic Serverに推奨します異なるウェブサーバを使用している場合同等のオプションを推奨します変更後再びネットワーク品質ツールを実行し今回は高いRPMスコアが得られました右側で同じビデオを流しますスキップするとビデオは即座に再開されますサーバで不必要キューが除去されることによりランダム・アクセス反応が改善されました App ネットワーキングをどのように使用するかにかかわらずサーバ上の変更でApp反応が良くなりよりよいユーザー体験が提供できます Appを改善しサーバを更新する方法です反応に非常に影響する3番めの要因はネットワーク自体ですアップルはmacOSモンテレーで iOS 15 ネットワーク品質ツールを導入しました以来ネットワーク検査で他社も同じ方法を使用しました WaveformはBufferbloatテストを始め反応テストのオープン・ソース実装で Goで書かれました Ooklaの速度試験Appに反応測定が加わりました OoklaのAppはミリセカンドで往復時間を表示また60,000で割る場合毎分往復あるいはRPM数を得られますこれらのツールを自分のネットワーク測定で使用できますネットワークのディレイを理解する最良の方法はディレイに反応するAppですリモート・マシンスクリーン共有体験をおみせしますアクセス・ネットワークを模倣したネットワーク条件セットアップでその他ネットワークの共有デバイスと通信します遠隔ログオンしスクリーン共有します

別のFinderrメニューをクリックし各メニューのディスプレイは非常に遅く相互ディレイをチェックするためローカルのマシン上の時間を表示するAppを立ち上げ同じAppをリモートマシン上で立ちあげましたコンピューター時間は同期されても遠隔のスクリーンは定期的に更新されず数秒ディレイがありこの理由はネットワークの最も遅いリンクで大きなキューが存在することでこの大きなキューにスクリーン共有App パケットデータがありました

このキュー問題の解決でアップルはネットワークのコミュニティと L4Sと呼ばれる新技術を開発しています iOS 16および macOSヴェントゥーラでベータとして利用可能です L4Sはキューディレイを著しく縮小し 0の混雑ロスを達成します一貫して短いキューを続けるためにネットワークはパケットを落とす代わり明示的に混雑信号を示しますまた送信元はネットワークから混雑フィードバックに基づき送信割合を調節しますパケット・ロスなしでネットワーク中のキューを非常に低く抑えます App反応を改善できますさてL4S でスクリーン共有改善を見てみましょう同じマシンまた同じネットワークを使用します今回はL4Sを有効化します別のFinderrメニューをクリックすると直ちに開きました両方のマシン上でタイム・Appを起動し両方の遠隔スクリーン時間を計るとローカルのマシンはほとんど完全に同期されましたこのテクノロジーはスクリーン共有だけでなく L4Sは今日のAppのすべてを改善し将来のAppで現在にはないドアを開きますこのチャートはスクリーン共有Appパケットから観察された平均ラウンド・トリップ時間です同じネットワーク共有その他デバイスから通信もありますクラシックキューとL4Sで L4Sでのラウンドトリップ時間はかなり縮小されましたこれはスクリーン共有体験劇的な改善の主要な理由です HTTP/3あるいはQUICを使用するAppを L4Sでテストします開発者設定の内部であるいはmacOS ヴェントゥーラでデフォルト書き込みによって iOS 16のL4Sを有効化できますリナックス・サーバーを使用してテストするにはQUIC実装で正確なECNを支援し拡張可能な混雑制御アルゴリズムを使用する必要があります To ensure that you are ready ネットワーキング展開準備ができていることを保証するため Appで L4Sとの互換ををテストしまた遭遇する問題のフィードバックを供給します Appの反応改善のためレイテンシーの縮小は必要なことがわかりましたしたがってHTTP/3およびQUICで往復の数を減らし Appにコンテンツをより高速で配信します反応速度を挙げるためサーバで不必要なキューを除去します L4S開発者設定でAppの互換をテストしフィードバックします最後にサーバープロバイダにL4S対応を問い合わせますありがとうございました ♪

6:21 - Enable connection migration on URLSessionConfiguration for HTTP/3

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

6:29 - Enable connection migration on NWParameters for QUIC

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

7:08 - Opt-in to QUIC datagrams

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

8:12 - Network quality tool in MacOS

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

% 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

12:52 - Responsiveness tests

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

17:12 - Enable L4S for QUIC on Mac
```
defaults write -g network_enable_l4s -bool true
```

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。