HTTP/3とQUICによあるネットワーキングの加速

HTTP/3とQUICによあるネットワーキングの加速

ウェブは絶えず変化しており、HTTPの次のメジャーバージョンが登場しています。HTTP/3がどのようにAppにおけるレイテンシを短縮し、信頼性を向上させるかについて確認し、その基盤となるトランスポート層のQUICが新しいトランスポート機能とマルチストリーミングコネクショングループを使用して、独自のカスタムプロトコルに新たなイノベーションをもたらすことを確認します。

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

Tech Talks
- ネットワーク環境の変化への対応
WWDC22
- ネットワーク遅延を減らしてAppの応答性を向上させる
- Background Assetsについて
WWDC21
ダウンロード

♪ (HTTP/3とQUICによるネットワーキングの加速) Rui Paulo: 皆さんこんにちは Ruiです今日は同僚のEricと一緒にどのような方法を使えばアプリケーションのネットワークを高速化できるか HTTP/3とQUICを使って説明します iOS 15とmacOS Monterey で使える2つの新しいプロトコルですまず HTTPの進化と HTTP/3がどのようにして性能を向上させるのかを見ますまた HTTP/3の背後にある新しいトランスポートプロトコルである QUICについても説明します次に URLSessionで HTTP/3を使用する方法と HTTP/3をサポートするように HTTPサーバを設定する方法について説明します最後にQUICを使用するための APIと QUIC上にカスタムネットワークプロトコルを実装する方法について詳しく説明します HTTPの進化について説明しますリソースを取得する必要があるとします接続を設定しリクエストを送信しサーバが処理するのを待ち応答を受信しますここで最初のリソースが終了する前に別のリソースをフェッチする場合は同じプロセスを再度実行します接続のセットアップリクエストの送信処理の待機および応答の受信この時間は濃い緑色で示されます 3番目のリソースの例をオレンジで示します図に示すように接続のセットアップには多くの時間がかかりますひとつのHTTP/1接続を再利用するとしたらどうでしょう? 接続のセットアップ時間を節約しましたがリクエストを送信できるのは前のレスポンスが終了した後だけですこれは head-of-line blockingと呼ばれますこれまでHTTP実装はこの問題を克服するために多くの並列接続を使用してきました並列HTTP接続の数は Appで設定することもできましたしかしこれはクライアントとサーバの両方に対して非効率的なネットワーク動作をもたらしてきました HTTP/2は単一の接続上で複数のストリームを多重化して Head-of-Line Blockingを解決しますリクエストはより早く送信され異なるストリームからのデータをインターリーブできますこれによりアイドル待機時間が大幅に削減されるため単一のTCP接続をより効率的に使用できます HTTP/3を使用すると接続のセットアップが遥かに高速になるためリクエストをより早く送信できますしかし HTTP/3の利点はそれだけではありません HTTP/3ストリームは独立しておりすべてのストリームが 1つのTCP接続を共有する HTTP/2とは異なりますほとんどのネットワークではパケットは失われますこれは無線ネットワーク上の通常のイベントでありネットワークの容量を検出する自然な部分です HTTP/2では全てのHTTP/2 ストリームが単一のTCP接続を共有するためパケット損失が多くのストリームに影響を与えかねません HTTP/3では対応するHTTPストリームのみが影響を受けます他のストリームに属するデータはより早く配信できます HTTP/3がより早く接続を確立する方法そしてパケット損失に上手く対処方法を示しましたこれらの改善は基礎となる転送プロトコルQUIC QUICはインターネット技術タスクフォースで標準化された信頼性の高い新しい通信プロトコルです TCPと同じ概念に基づいていますがエンドツーエンド暗号化多重化ストリームおよび認証を提供しています QUICの安全性は周知の TLS 1.3の上に構築され QUICの主な利点は性能の向上ですでは QUICがそれを実現する方法を見てみましょう QUICはTLS 1.3に依存して安全な通信を行い使い慣れた TCPスリーウェイ通信が不要でハンドシェイク時間が単一のラウンドトリップに短縮されます多重ストリームはQUICの重要な概念であるため head-of-line blockingの影響を受けません QUICエンドポイントは受信したパケットに関するより複雑な情報を他のエンドポイントに通信することができ TCPの制限によって妨げられることがないため QUIC接続の損失回復が向上しますまたこのプロトコルでは接続の移行もサポートされているためセルラーネットワークと Wi-Fi間などのセッションを再確立することなく異なるネットワークインターフェイス間で接続をシームレスに移動できますネットワーク遅延の詳細については "Appにおけるネットワーク遅延の低減" セッションをご覧ください AppでHTTP/3を使う方法について話しましょう URLSessionを使用している場合は iOS 15および macOS Monterey 以降のAppはHTTP/3が有効になった状態で出荷されていますサーバ上でHTTP/3を有効にしておけば問題ありません次のHTTP/3 RFC バージョンと以前のHTTP/3 Draft 29の両方がサポートされます HTTP/3を利用していることを確認する方法は？ツールを使って調べましょう Xcode 13ではHTTP トラフィックを検査するための新しいツールをネットワーキングプロファイリングテンプレートに導入しています URLSessionに直接接続するのでセットアップは必要ありませんツールを使ってAppが HTTP/3またはそれ以前の HTTPバージョンを使用しているかを調べることができます iOS Appを立ち上げて犬の写真セットを取得します次に HTTPヘッダを検査してサーバがHTTP/3に通知する方法を調べます次にネットワークプロファイルテンプレートを選択します
左上の記録をクリックしましょう HTTPトラフィックの記録によるプライバシーへの影響を示すプロンプトが表示されます同意した後ツールはHTTPトランザクションの記録を開始します
次にツールはApp毎およびドメイン毎の全HTTPトランザクションのプロットを表示しますこれで必要なデータをすべて収集できました左上にある一時停止ボタンをクリックします
使用するドメインを選択しますこれを行うにはオプションボタンを押しながら HTTPトランザクションをクリックしドメインを選択します
HTTPトランザクションの詳細を表示するようにツールを設定する必要がありますそのためには左側のメニューに HTTPトランザクションが表示されていることを確認します
最初のリクエストを選択します右にスクロールするとこのトランザクションが使用した HTTPのバージョンを示す HTTPバージョン列が表示されますまだHTTP/2を使っていますがなぜですか右側には応答ヘッダを含む拡張詳細ビューがありますこれが答えですサーバはHTTP代替サービスを使用して HTTP/3のサポートを通知しました
URLSessionは通知されないHTTP/3を使用しませんこの例ではHTTP/3は Alt-Svc HTTPヘッダを介して通知されています HTTPサーバがこのヘッダを使用してHTTP/3のサポートを通知するのは一般的ですこの情報は将来の接続のために記憶されこれを「サービスディスカバリ」と呼びますではもう一度Appを記録しましょう
いったんAppを再起動すると同じHTTPトランザクションのセットが発生しますここでもツールを一時停止できます
もう一度ズームインして最初のトランザクションをチェックしますサーバがHTTP/3をサポートしていたことを思い出したので現在はHTTP/3を使用しています HTTP/3サービス検出は Appに対して透過的です HTTP/3サーバサポートの検出は2つの方法で行われます推奨される方法は HTTPSリソースレコードを介してHTTP/3のサポートを通知するように DNSサーバを設定することです h3文字列を使用して HTTP/3を通知するようにアプリケーション層プロトコルを設定するだけですまたサーバを設定して代替サービスを使用して HTTP/3を通知する新しいヘッダを追加するようにサーバを設定する必要もありますサーバはHTTP/3を通知する Alt-Svcヘッダを送信する必要がありますこれにはポート番号とサービスの最大経過時間秒単位が含まれます DNSレコードの利点は情報がDNSにあるためアプリケーションがサーバに初めて接続しようとしたときに HTTP/3接続を確立できますサーバがHTTP/3をサポートしていることがわかっていて検出プロセスを高速化したい場合は assumesHTTP 3 Capableをプロパティを使用できますこれによりHTTPスタックは HTTP/3サーバですが HTTP/3が使用されることを保証しませんネットワークがまだHTTP/3をブロックしているかサーバが実際にHTTP/3をサポートしていない可能性がありますその場合はHTTP/2に戻ります HTTPを使用すると顧客は各リソースの優先順位を指定できるリソースは関連していることが多いため優先順位によってクライアントのニーズに基づいてサーバは一部のリソースを他のリソースよりも先に送信できますたとえば Webページのレンダリングに最も影響を与えるリソースに優先順位を付けることで Webブラウジングのユーザー体験を向上させることができます優先度スキームはHTTP/2で導入されましたがその複雑さのためにあまり評価されませんでしたそのため古いプライオリティモデルは HTTP/3から削除されました HTTP/3スタックでは HTTPヘッダに依存するより単純な新しいモデルが使用されますこのモデルでは優先順位が指定されています緊急度パラメータを 0から7に設定してオプションの増分配信パラメータがあります URLSessionを使用する場合優先順位をサポートする APIは同じままです優先度プロパティを使用して HTTP優先度を指定し緊急度を使用してサーバに通信しますインクリメンタル配信は prefersIncrementalDelivery プロパティを使用して有効にできデフォルトのプライオリティは3です URLSessionは便利なAPIであるかどうかに応じて差分配信を推測します async dataメソッドのように使用されますリソース全体をダウンロードするまで処理できないコンテンツを Appがダウンロードする場合はこのプロパティを falseに設定する必要がありますリクエストの送信後にリソースの優先順位を動的に変更することもサポートされています例えば低い優先度で写真をプリフェッチしユーザーがAppのそのセクションに移動したときにその優先度を上げることができます次に同僚のEricがカスタムのネットワークプロトコルを変更して QUICを採用する方法について説明しますありがとうございましたありがとう Rui 前述したようにHTTP/3は QUICの上に構築されており HTTP/2に見られるものと同様のストリームの多重化を提供しますが基礎となるトランスポートとして単一のTCP接続を共有することで生じる問題はありません QUICトランスポート接続またはQUICトンネル複数の単方向または双方向 QUICストリームのデータを多重化しますストリームはどちらのエンドポイントでも作成でき他のストリームと同時にインターリーブされたデータを送信できTCPによって提供される従来のストリームと同様の状態を持ちます何よりも優れているのは QUICにTLS 1.3 セキュリティが搭載しネットワーク状況の変化にも対応できる点ですこれらの機能は HTTP以外にも役立ちますアプリケーションがリクエストレスポンスに基づかないデータを交換している場合基礎となるトランスポートコンテキストを共有する多重ストリームを持つこと又はその他のカスタムプロトコルを実装していることからメリットが得られる可能性がありますピアツーピア通信やRPC呼び出しなど AppにQUICトランスポートを使用することを検討してください iOS 15と macOS Montereyで NWProtocolQUICは Network.frameworkで提供されるその他の組み込みプロトコルに加わります接続作成にQUICを使うことはよく知られていますエンドポイントと新しく使用可能になった QUICパラメータを指定するだけですこれらのパラメータはサーバとネゴシエートするアプリケーション層プロトコルであるALPN文字列を指定します通常と同じように状態更新ハンドラを設定します接続が進行し準備が整ったときに応答できるように最後に状態の更新やその他のコールバックに使用するディスパッチキューで接続を開始しますこれでQUICストリームが確立されたので他のNWConnectionと同じようにデータを送受信できます send関数を使用してリモートエンドポイントに送信するデータを指定し完了時に後続の送信をスケジュールします receiveを使用して着信データを処理しその後の受信が完了したときにスケジュールします Network.frameworkに昨年接続グループオブジェクトを導入し複数の接続が関連したりグループ化されている状況を扱いやすくしました基礎となるトランスポートコンテキストまたはトンネルで多重化されるQUICストリームはその関係に基づいて論理的にグループ化され新しいグループタイプ NWMultiplexGroupで使用できます接続グループは他の Network.framework オブジェクトと同様のライフサイクルに従いますこれによりQUICストリームによって共有される基盤となる QUICトンネルの状態を判断できますまた特定のQUICトンネルから新しい発信ストリームを作成したりリモートエンドポイントによって開始された新しい着信ストリームを受信したりできます多重プロトコルの接続グループを作成するには多重グループ記述子を使用しますこの例ではポート443で example.comに対するグループ記述子を作成します次に記述子とQUIC パラメータを使用して NWConnectionGroupを作成し ALPN文字列を指定します NWConnectionと同様に状態更新ハンドラを設定しますが今回は個々のストリームの状態ではなく基盤となるQUICトンネルの状態を追跡します最後にコールバックキューを提供する接続グループを開始します新しい発信ストリームを作成するにはグループから NWConnectionを初期化するかグループでextract 関数を呼び出しますリモートエンドポイントによって開始される着信ストリームはグループに新しい接続ハンドラを設定することによって処理できますこれらの接続は状態ハンドラを使用して通常どおり設定できます今度はストリームの状態を追跡しコールバックに使用するキューから始めます他のプロトコルと同様にパラメータのオブジェクトを作成するときに QUIC.Optionsを使用して設定できます QUICの場合 QUIC仕様にリストされているトランスポートパラメータを構成でき接続グループからストリームを作成するときに個々のストリームのプロパティをカスタマイズすることもできます例えば新しい単一方向ストリームを作成する場合などです NWListenerを使用して App内でサーバを実行中の場合はこの機能が拡張され新規の ConnectionGroupHandlerを介して新しい着信QUICトンネルを受信できるようになりましたサーバへの新しいQUIC トンネルが確立されるたびに新しい ConnectionGroupHandlerが呼び出されますそのハンドラ内で状態の更新を受信するようにグループを通常どおり設定できますこれは先ほど説明した新しい接続ハンドラを設定するのにも適した場所ですこのトンネルで開かれている後続のストリームを受信する場合はコールバックに使用するキューを使用してグループを開始するとすべての設定が完了します最後に NWProtocolMetadataを使用してストリームに関する情報にアクセスできます例えば新規作成のストリームのストリームIDを確認することができますまたストリームの処理が終了しカスタムプロトコルでアプリケーションエラーコードが定義されている場合はストリームをキャンセルする前にメタデータを使用してリモートエンドポイントにエラーを通知できますここまでは新しい NWMultiplexGroup タイプを使用して QUICトンネルを作成して管理する方法とそのグループから QUICストリームごとに個別の NWConnectionを作成する方法について説明しました NWListenerを使用して着信トンネルをリッスンし結果の接続グループを使用して新しい着信ストリームを受信できますこれらのストリームでは他の接続と同様にデータを送受信できますまた QUICプロトコルオプションを使用してトランスポートパラメータを指定しストリームを構成し QUICプロトコルメタデータを使用してストリームを検査し QUIC固有の情報をリモートエンドポイントに通信できます QUICを採用してAppのネットワーキングを改善しましたでは上手くいっているかどうかはどうすれば分りますか qlogファイルを出力する新しい環境変数を使用してデバッグ中にアプリケーションを起動できます qlogはIETFで提案された新規標準化されたロギング形式ですこれにより QUIC接続の動作に関する情報を従来のパケットキャプチャよりもさらに詳細にエクスポートできますテスト実行後 Xcodeのデバイスウィンドウを使用して分析用のqlogファイルを含むアプリケーションのコンテナをダウンロードできますまた QUIC接続の振る舞いをより簡単に内省できるようにするさまざまなオープンソースの視覚化があります今回は HTTP/3がHTTP トラフィックに提供する改善点を検証しました最新のネットワークAPIのユーザーには既にデフォルトで有効になっているのでサーバ上のHTTP/3でネットワークの状態の変化に対する向上した性能と回復力を利用することができます HTTP以外のカスタムネットワークプロトコルを使用している場合は Network.frameworkに組み込まれた新しい多重化プロトコルサポートを使用して NWConnectionGroupとの QUIC接続を作成しますどのプロトコルを使用している場合でも新しいデバッグツールを使用して次世代のネットワークプロトコルの優れた利点を視覚化できますご覧いただきありがとうございます ♪

// Create a connection using QUIC
let connection = NWConnection(host: "example.com", port: 443, using: .quic(alpn: ["myproto"]))

// Set the state update handler to be notified when the connection is ready
connection.stateUpdateHandler = { newState in
    switch newState {
    case .ready:
        print("Connected using QUIC!")
    default:
        break
    }
}

// Start the connection with callback queue
connection.start(queue: queue)

15:08 - Establish a tunnel with NWMultiplexGroup

// Establish a tunnel with NWMultiplexGroup

// Create a group
let descriptor = NWMultiplexGroup(to: .hostPort(host: "example.com", port: 443))
let group = NWConnectionGroup(with: descriptor, using: .quic(alpn: ["myproto"]))

// Set the state update handler to be notified when the group is ready
group.stateUpdateHandler = { newState in
    switch newState {
    case .ready:
        print("Connected using QUIC!")
    default:
        break
    }
}

// Start the group with callback queue
group.start(queue: queue)

15:45 - Manage streams with NWConnectionGroup

// Manage streams with NWConnectionGroup

// Create a new outgoing stream
let connection = NWConnection(from: group)

// Receive new incoming streams initiated by the remote endpoint
group.newConnectionHandler = { newConnection in

    // Set state update handler on incoming stream
    newConnection.stateUpdateHandler = { newState in
        // Handle stream states
    }

    // Start the incoming stream
    newConnection.start(queue: queue)

}

16:43 - Receive incoming QUIC tunnels from NWListener

// Receive incoming QUIC tunnels from NWListener

// Set the new connection group handler
listener.newConnectionGroupHandler = { group in

    group.stateUpdateHandler = { newState in
        // Handle tunnel states
    }

    group.newConnectionHandler = { stream in
        // Set up and start new incoming streams
    }

    group.start(queue: queue)

}

17:22 - Access QUIC metadata

// Access QUIC metadata to learn about and modify streams

// Find the stream ID of a particular QUIC stream
if let metadata = connection.metadata(definition: NWProtocolQUIC.definition)
                             as? NWProtocolQUIC.Metadata {
    print("QUIC Stream ID is \(metadata.streamIdentifier)")

    // Some time later...

    // Set the application error, if appropriate, before cancelling the stream
    metadata.applicationError = 0x100
    connection.cancel()

}

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

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

リソース

関連ビデオ

Tech Talks

WWDC22

WWDC21