Appにおけるネットワーク遅延の低減

Appにおけるネットワーク遅延の低減

CPUのパフォーマンスとネットワークの伝送速度は向上し続けていますが、光の速度はこれ以上上がらない限界の一つです。ネットワークのラウンドトリップ時間を短くし、ネットワーク操作時のラウンドトリップ回数を最小限にすることで、Appの応答性と効率性を最大限に高めるAPIとベストプラクティス紹介します。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC22
- ネットワーク遅延を減らしてAppの応答性を向上させる
WWDC21
- HTTP/3とQUICによあるネットワーキングの加速
- InstrumentsでのHTTPトラフィックの解析
WWDC19
- ネットワーキングの最新情報（パート2）
WWDC18
- Introducing Network.framework: A modern alternative to Sockets
WWDC15
- Your App and Next Generation Networks
ダウンロード

♪ （Appにおけるネットワーク遅延の低減） "Appのにおけるネットワーク遅延の低減" へようこそ Stuart CheshireですネットワークAppの動作が遅くなる要因についてお話しします次に同僚のVidhi Goelに移りネットワークAppの応答性を高めるために使えるテクニックとAPIについて説明しますまずiOSのWWDCベータ版ですでに見たであろうことについて説明しましょう設定を見るとセクションに "応答性"という新しい項目がありますアップロードのスループットやダウンロードのスループットおよびアイドル時のping時間はすべて興味深いものですがネットワークAppの応答性に影響する主な要因はアイドル状態ではなく稼働状態でのネットワークの応答性です一般的なインターネット速度試験のアイドルping時間の測定値はインターネット接続を使っていないときの動作を示します重要なのはインターネット接続使用時のインターネット接続状態ですをタップしますネットワークトラフィックが生成され数秒間のネットワーク測定後ネットワークの動作が正常かどうかが通知されますこのツールはミリ秒単位ではなく1分あたりのラウンドトリップ数（RPM）でネットワークの応答性を報告しますこの新しいRPM測定基準は多くの人にとってミリ秒が抽象的すぎるために作成されました値が高ければより優れている指標についても皆が理解しています RPM測定基準は数百RPMから数千RPMまでの範囲の数値を生成しますこれは車のエンジンの RPMのようなものです macOSには"NetworkQuality"と呼ばれるコマンドラインバージョンもあります自宅や職場のネットワークでは pingの時間が長いと考えられますがそれはアイドル状態ですこのネットワーク品質テストは iPhoneまたはMac上であなたが実行しますまたネットワーク使用中に応答性が大幅に低下することがありますさらに悪いことにネットワークには20ミリ秒のアイドルラウンドトリップ時間があるかもしれませんかなり素晴らしく聞こえるでしょうしかし作業条件下ではラウンドトリップ時間が最大600ミリ秒以上になることがありますそれは30倍悪いです作業環境におけるネットワークの応答性は Appのユーザー体験にとって重要ですこの問題は常に発生していますビデオ会議中に音声やビデオがフリーズしたりドロップアウトしたりする場合は特にそうですネットワーク遅延が大きければ全Appに悪影響を及ぼしますが私たちは慣れてきたためビデオ会議に影響する場合の多さに注目していますビデオ会議で問題が発生した場合はインターネット接続をアップグレードして解決すると思います数メガビット/秒からギガビット以上になってもまだ問題は起こりますビデオ会議では数メガビット/秒が十分である必要がありますがこれらの問題が解決しないのはなぜでしょうかネットワーク内のバッファが過度に大きい場合バッファがいっぱいになるとスループットは向上せず遅延が発生します通常インターネットはこのように動作しておりパケットはネットワークを介して高速で流れると考えていますしかしクラウド内を見ると実際にはこのように機能することがわかりますネットワークから出てくるパケットは入ってきたパケットとは異なりますパケットはネットワーク内の過度に大きいバッファに長時間置かれますこのようにバッファが大きすぎる現象は "バッファブロート"と呼ばれネットワークの日常的な利用に影響を与えているにもかかわらずこれまで大々的に測定されることはありませんでした良いニュースは制御された遅延キューイングアルゴリズムである Codelなどバッファブロートを排除する最新のキュー管理アルゴリズムがあることですネットワークがキューを短くし続けるとパケットがネットワークで待機する時間が大幅に短縮されます高いスループットと低い遅延を同時に実現できます二者択一やゼロサムではありません私たちは業界と協力してよりスマートなキュー管理アルゴリズムを導入し稼働状況下でのネットワークの応答性を向上させていますしかし今のところ優れたユーザー体験を提供したい場合は現在のようにAppをインターネットに対応させたいと考えるでしょうバッファブロートはAppで発生するネットワーク遅延の大きな要素ですが遅延の原因はそれだけではありませんソフトウェアとハードウェアの処理時間があります CPUの処理速度が向上するとこの処理時間は短縮され続けます実際のデータ転送時間がありますデータレートがキロビットからメガビットギガビット/秒に増えると伝送時間は短縮され続けますネットワークでのバッファリングによる遅延が発生します前述のように私たちは業界と協力してこれらの遅延の短縮に取り組んでいますしかし信号の伝播遅延は常にあります 1990年代には米国を横断すスタンフォード大学から MITへのping時間往復つまり海岸から海岸への往復はすでに100ミリ秒未満でしたこれはすでに光速の限界に近いためそれほど向上することはありません私たちは他3つの遅延短縮に取り組んでいますが光の遅延がなくなることはありませんそのためネットワークの往復時間を考慮した App設計が重要なのですネットワークの往復時間を考慮に入れるとどのような種類の Appが話題になりますかネットワーク遅延が高ければビデオ会議に深刻な影響が出ることは誰もが知っています高いネットワーク遅延でオンラインゲームに深刻な影響が出ると誰もが知っていますただしこれはネットワークを使うすべてのAppに影響します天気予報や株価情報それから道案内などを入手することについてお話していますこれはウェブ閲覧に影響しますこれはストリーミングビデオ視聴中の早送りに影響します Appのネットワーク待機中にアニメーション化されたスピン遅延インジケータが何個のAppに入っているか考えてみてくださいあなたのAppに入っているでしょう Appがハングしたとユーザーが思わないように "お待ちください"の表示が出ます低速ネットワーク待機中にユーザに見せるものに多大な努力を払うのは素晴らしいことですが待ち時間を短くするためにも同様の努力を払う必要がありますネットワークからのデータ待機中に遅延インジケータを表示する Appがある場合はこれらの待機時間の短縮に使えるテクニックがあります Appがネットワークデータを待機する時間は 1回のネットワーク往復にかかる時間と Appが必要とするネットワーク往復数の計算式です App開発者は基礎となるネットワークの往復時間を改善するために多くのことを行うことはできませんが Appに必要な往復回数を制御できます私の同僚であるVidhi Goelがその方法を説明しますありがとう Stuart Vidhiです今日はAppのネットワーク遅延短縮のために開発者としてできることについてお話したいと思います Appの応答性はネットワーク往復数に反比例します最新のネットワークプロトコルを採用することでネットワークの往復数を削減し Appを非常に軽くする方法をご紹介します Appを高速化するには HTTP/3やQUIC TCP Fast Open TLS1.3やMultipath CPなどの最新ネットワークプロトコルを採用しますこのような手法により Appはユーザーへのデータ配信の際に複数回の往復を削減できる可能性がありますこれらの最新のプロトコルすべてにサーバ側のサポートが必要なためプロバイダの準備状況をご確認くださいこれらのテクノロジーはすべてiOSとmacOSで利用できますではこれらのテクノロジーについて見ていきましょうまずiOS 15と macOS MontereyではデフォルトでHTTP/3とQUICが有効になっています QUICはTCPやTLSよりもはるかに高速な接続を設定できるトランスポートプロトコルですヘッドオブラインブロッキングを削減することで QUICはユーザーへのデータ配信遅延を大幅に削減できます最高なのはここです URLSessionをすでに使用している場合はすべて設定済ですネットワークフレームワークAPIを使って独自のAppレイヤを提供して QUICを活用したい場合は QUICパラメーターで NWConnectionを作成し TLS Application-Layerプロトコルまたは ALPNを設定します Appでのこれらのテクノロジーの使用方法は "HTTP/3とQUICによるネットワーキングの加速" セッションをご覧ください QUICは多くのシナリオで役立ちますただし一部のAppでは TCPが適切な選択肢である場合があります TCPを使用する場合TCPハンドシェイクとともにAppデータを送信することでラウンドトリップ全体を排除できます TCP Fast Openはネットワークフレームワークおよびソケットでサポートされています NWConnectionsで使うには 2つの選択肢があります 1つ目のオプションは接続で Fast Openを許可することですこの場合Appはハンドシェイクで送信される初期データを提供しますこれを有効にするには allowFastOpenパラメータを trueに設定し接続を作成します次にstartを呼び出す前に sendを初期データで呼び出します TCP Fast Openを使う場合はハンドシェイクを使って冪等な要求のみを送信するよう注意する必要があります冪等とは基本的にデータをネットワーク経由で安全にリプレイできることを意味します TCP Fast Openを使うもう1つの方法がありますが Appが独自の初期データを送信する必要はありません AppがTCPを介した TLSを使っている場合は初期データとして TLSハンドシェイクメッセージの送信を選択できますこれを有効にするには TCP固有のオプションに移動し enableFastOpenを trueに設定します TCPFastOpen を使用するには Networkフレームワーク APIの使用をおすすめしますが Appがソケット上に構築されている場合はそれぞれのフラグを指定して connectx APIを呼び出してハンドシェイクで冪等なデータを送信するように指定します私は何度か冪等について述べましたその意味するところやハンドシェイクを使って冪等な要求のみを送信することが重要な理由について説明します一度以上実行した場合冪等とリプレイセーフな操作は追加の影響を与えない操作ですたとえばユーザが developer.apple.comのウェブページにアクセスするとこのウェブページの HTTP GETリクエストが TCPハンドシェイクで送信されますこの要求の確認応答が遅延したかネットワーク内でドロップされた場合デバイスはHTTP GET リクエストを再送信しますこれは別のサーバにルーティングされる可能性があります今回は HTTP応答とともに確認が到着します HTTP GET要求はネットワークを介して再送信された場合には追加の影響を与えないため冪等リクエストと見なされますさてユーザーが新しいiPhone 12を購入しようとしているとしますこの操作のために送信されたHTTPリクエストは冪等なリクエストではありませんデータがネットワーク経由でリプレイされるたびにリクエストが異なるサーバに送られると複数のトランザクションが発生する可能性がありますこれを念頭に置いて TLS1.3について説明します TLS1.3ではTLS1.2と比較するとハンドシェイクからラウンドトリップ全体が削除されますまたセキュリティが強化されます URLSessionとNWConnectionの iOS13.4ではデフォルトで有効になっています TLS1.3プロトコルは早期データサポートを定義していますこれは冪等なリクエストと TLSハンドシェイクメッセージを送信することでさらに別のラウンドトリップを節約できますではギアを切り替えてネットワーク遅延短縮において少し異なる動作をする Multipath TCPを見てみましょう Multipath TCPによりシングルTCP接続がデバイス切り替えとして継続できるようになります Multipath TCPの低遅延機能を取得するにはインタラクティブモード APIを使います新しい接続の確立に必要なすべてのラウンドトリップが節約されデータパケットの高速ネットワークパスが自動で選択されますクライアントからオプトインするには URLSession構成または NWParametersで multipathServiceType プロパティを interactiveに設定しますこれらの最新テクノロジーで節約できるラウンドトリップ数を把握するには基準点から始めましょう Appが現在TCP上でTLS1.2を実行しているとしますこの場合ユーザーに最初のバイトを取得するには4回のラウンドトリップが必要ですサーバーがTLS1.2から TLS1.3に切り替わると接続がラウンドトリップ全体を削除します接続でTCP Fast Openを有効にするとさらに別のラウンドトリップが節約されます iOS 15ではQUICを介した HTTP/3によりラウンドトリップが 2回に削減されます QUICプロトコルは早期データサポートも定義しているため 1回のラウンドトリップをさらに削減できます Appleでの測定結果に基づきユーザーは600ミリ秒に達することもあるようなラウンドトリップ回数をよく見ます Appにとっての意味を見てみましょう 600ミリ秒で4回のラウンドトリップを行うとユーザーはデータ到着まで約2秒半待機していますこれはネットワークのスピナーを待機して見るための膨大な時間です最新のネットワークプロトコルを採用することで最初のバイトまでの時間を 2.4秒から約0.5秒に短縮できますユーザーはデータが 1秒半前に到着するとその違いがはっきりとわかります高いネットワークパフォーマンスを求めているすべての開発者はラウンドトリップの回数に注意する必要がありますこれが大きな勝利ですここまでお話したすべてのテクノロジーは実際のネットワーク環境での Appのネットワーク遅延の短縮に役立ちます 5G LTEまたは高速Wi-Fi ネットワークでAppを試験すると Appの応答性が問題なく感じられることがありますしかしユーザーが最適なネットワーク環境で Appを使っているとは限りません実際のネットワークをシミュレートするため iOS用の Network Link Conditionerツールがデベロッパ設定メニューから利用できます macOSの場合は Apple Developer Webサイトからダウンロードできますこのツールはユーザーが日常的に経験する可能性のあるさまざまなネットワーク条件での Appのテストに信頼性が高く繰り返し利用できます先程 Stuartがネットワークのラウンドトリップ時間の短縮はできないと言っていたと思いますそれは違います Appのトラフィックをシステムに正しく通知することでネットワークの往復時間を短縮する方法を説明しますほとんどのAppでは送受信するトラフィックが混在しています多数のAppを実行するときにユーザーのデバイスからやり取りされるデータが大量にあります自宅やオフィスWi-Fiなど実際のネットワークでは多数のデバイスが同一のネットワークを共有していますこれらのデバイスは一連のAppを使いながら大量のデータを同時に送受信しますこの共有ネットワークで長いキューを作成しないようにするにはネットワーク遅延を低く抑えるためシステムがトラフィックを効率的に管理できるよう Appデータの適切な分類が重要ですまたシステムがネットワーク遅延を低く抑えられるようにすると Appのフォアグラウンドトラフィックが高速になりユーザーにとって最も重要なデータが迅速に送られます例を挙げて説明しましょう多くのAppはグラフィクスやオーディオファイルなどのコンテンツをプリフェッチして後で使用できるようにします Appが大量のデータをプリフェッチしている場合ネットワークはこのように表示されるでしょうボトルネックキューがいっぱいになる可能性がありますこの時点でユーザがネットワークアクティビティ（プロファイルページの表示など）を開始した場合このリクエストに対する応答はネットワークキューの最後に入れられプロファイル表示までに数秒かかることがありますこれは優れたユーザー体験ではありませんではこれらのユーザー以外が開始したプリフェッチタスクをバックグラウンドとしてマークするとネットワークにどのような影響があるか見てみましょうこれらの非ユーザーが開始する転送をバックグラウンドとしてマークするとネットワークキューのサイズが大幅に削減され他のフォアグラウンドデータで使えるようになりますつまり緑のパケットであるフォアグラウンドデータはすぐに送られ迅速で快適な体験が得られます iOS 15および macOS Montereyではバックグラウンドサービスタイプが大幅に改善されましたバックグラウンドのアップロードとダウンロード用に新しい輻輳制御アルゴリズムが追加されましたこれらの新しいアルゴリズムはネットワーク遅延を大幅に削減しユーザー体験を向上させるだけでなくバックグラウンド転送が他のトラフィックとほぼ同じ時間で終了するようにしますではバックグラウンドサービスタイプを活用するために採用できるネットワーキングAPIについて見ていきましょう Appがフォアグラウンドにあり非ユーザーが開始した転送実行中はデフォルトの URLSessionを使い URLリクエストでネットワークサービスタイプをバックグラウンドに設定しますこの場合もシステムはネットワーク遅延を低く抑えられますまたNWConnectionの場合はNWParametersでサービスクラスをバックグラウンドに設定しますユーザーが開始したかどうかにかかわらず長時間実行される転送を Appが開始した場合はバックグラウンドの URLSessionを作成すると Appが一時停止している場合でも実行を継続します時間をかけないタスクの場合は isDiscretionaryプロパティを trueに設定できますこれによりシステムは最適な状態で転送実行まで待機できますネットワークキューを短くするためにAppがどのように役立つかについて説明しました送信側デバイス自体には別の遅延源が存在する場合があります従来ネットワーキングスタックが使用する送信バッファは非常に大きなものでしたこれによりパケットがネットワークに入る前に多くの不要な遅延（秒単位の場合も）がときどき入りますこれは2015年にURLSessionと NWConnectionで修正されましたしかしインターネット上のほとんどのサーバは Linux上で動作し BSDソケットを使用していますサーバーオペレータに問い合わせて TCP NotSent Low Watermark ソケットオプションでソースでの遅延の短縮を確認してください次のステップでは最新のネットワークプロトコルを導入して複数のラウンドトリップを排除しますバックグラウンドモードはアセットのプリフェッチ一括転送および緊急でないタスクにお使いください様々なネットワーク条件でApp パフォーマンスをテストしますネットワークリンクコンディショナはそれを行うための秀でたツールですネットワーク遅延を低く抑えると Appの応答性が向上し全体的なユーザー体験が向上しますご覧いただきありがとうございます WWDCをお楽しみください ♪

/* Allow fast open on the connection parameters */
parameters.allowFastOpen = true

let connection = NWConnection(to: endpoint, using: parameters)

/* Call send with idempotent initial data before starting the connection */
connection.send(content: initialData, completion: .idempotent)
connection.start(queue: myQueue)

11:01 - Sockets with fast open

connectx(fd, ..., CONNECT_DATA_IDEMPOTENT | CONNECT_RESUME_ON_READ_WRITE, ...); // delay SYN
write(fd, ...); // SYN goes out with first data segment

13:35 - Save round-trips when switching networks with Multipath TCP

// Multipath TCP
// Save multiple round-trips when switching networks

// On URLSessionConfiguration
let configuration = URLSessionConfiguration.default
configuration.multipathServiceType = .interactive

// On NWParameters
let parameters = NWParameters.tcp
parameters.multipathServiceType = .interactive

20:09 - Background service type, App in foreground

//Use default  URLSession, set background on URLRequest
var request = URLRequest(url: myurl)
request.networkServiceType = .background

//Set service class on parameters to apply to the  NWConnection
let parameters = NWParameters.tls
parameters.serviceClass = .background

20:10 - Time insensitive tasks running in background

//Configure background URL Session

lazy var urlSession: URLSession = {
    let configuration = URLSessionConfiguration.background(withIdentifier: "MySession")
    configuration.isDiscretionary = true
    return URLSession(configuration: configuration, delegate: self, delegateQueue: nil)
}()

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

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC21

WWDC19

WWDC18

WWDC15