QUICに向けて：HTTP / 3を支えるもの

インターネットの歴史における新しいマイルストーンは、まさに目の前から始まります。HTTP/ 3がすでに発表されていると想定できます。 10月末に、IETFのマークノッティンガムは、2015年以降IETFが構築してきた新しいプロトコルの名前を既に決定することを提案しました 。 そのため、QUICのような名前の代わりに、騒々しいHTTP / 3が登場しました。 欧米の出版物はすでにこのことについて 何度も 書いています。 QUICの歴史は2012年にGood Corporationの腸で始まりました。それ以来、GoogleのサーバーのみがHTTP-over-QUIC接続をサポートしていましたが、時間が経ち、Facebookはすでにこのテクノロジーの実装を開始しました（11月7日、 FacebookとLiteSpeedはHTTP / 3 ）; 現在、QUICをサポートしているサイトの割合は1.2％です。 最後に、WebRTCワーキンググループもQUIC （およびQUIC APIを参照）に目を向けているため、近い将来、リアルタイムのビデオ/オーディオはRTP / RTCPではなくQUICを経由するようになります。 したがって、IETF QUICの詳細を明らかにすることは素晴らしいことであると判断しました。特にHabrについては、ロングドッティングiの翻訳を準備しました。 お楽しみください！







QUIC（Quick UDP Internet Connections）は、暗号化された新しいデフォルトのトランスポートレイヤープロトコルであり、多くのHTTP拡張機能を備えています。トラフィックを高速化し、セキュリティを強化します。 QUICには長期的な目標もあります。最終的にはTCPとTLSを置き換えることです。 この記事では、主要なQUICチップと、Webがそれらの恩恵を受ける理由の両方と、この完全に新しいプロトコルをサポートする問題について説明します。



実際、同じ名前の2つのプロトコルがあります。GoogleQUIC（gQUIC）は、数年前にGoogleのエンジニアが開発したオリジナルのプロトコルで、一連の実験の後、標準化のためにInternet Engineering Task Force（IETF）によって採用されました。



IETF QUIC（以降、単にQUIC）は、gQUICとの間に非常に大きな違いがあるため、別個のプロトコルと見なすことができます。 パッケージ形式からハンドシェイクおよびHTTPマッピングに至るまで、QUICは、インターネットの高速化と安全性の向上という共通の目標を持つ多くの組織や開発者と協力して、元のgQUICアーキテクチャを改善しました。



それでは、QUICはどのような改善を提供しますか？

統合セキュリティ（およびパフォーマンス）

QUICと由緒あるTCPの最も注目に値する違いの1つはデフォルトで安全である輸送プロトコルであるという最初に述べられた目標です 。 QUICは、認証と暗号化を使用してこれを行います。これは通常、トランスポートプロトコル自体ではなく、より高いレベル（TLSなど）で行われます。



元のQUICハンドシェイクは、TCPを介した通常の3者間通信とTLS 1.3ハンドシェイクを組み合わせ、参加者の認証と暗号化パラメーターの調整を提供します。 TLSに精通している場合：QUICはTLS記録レベルを独自のフレーム形式に置き換えますが、同時にTLSハンドシェイクを使用します。



これにより、接続が常に暗号化および認証されるだけでなく、初期接続をより高速に行うことができます。通常のQUICハンドシェイクは、1回のパスでクライアントとサーバー間の交換を行い、TCP + TLS 1.3は2回のパスを行います。













ただし、QUICはさらに進んで、サードパーティによって簡単に侵害される可能性がある接続メタデータも暗号化します。 たとえば、攻撃者はパケット番号を使用して、接続移行が使用されているときに複数のネットワークパスにユーザーを誘導できます（以下を参照）。 QUICはパケット番号を暗号化するため、接続の実際の参加者以外は修正できません。



暗号化は、「停滞」に対しても効果的です。これは、実装の誤った仮定のためにプロトコルの柔軟性を実際に使用できない現象です（骨化-TLS 1.3が長い間レイアウトされた理由です。新しいTLSリビジョンの不要なブロックを防ぎます）。

キューの先頭をブロックする（行頭ブロッキング）

HTTP / 2によってもたらされた主な改善点の1つは、1つのTCP接続で異なるHTTP要求を結合できることです。 これにより、HTTP / 2アプリケーションはリクエストを並行して処理し、ネットワークチャネルをより有効に活用できます。



もちろん、これは大きな前進でした。 以前のアプリケーションは、複数のHTTP要求を同時に処理する場合（たとえば、ブラウザーがページをレンダリングするためにCSSとJavaScriptの両方を受信する必要がある場合）、多くのTCP + TLS接続を開始する必要があったためです。 新しい接続を作成するには、オーバーロードウィンドウを初期化するだけでなく、複数のハンドシェイクが必要です。つまり、ページのレンダリングが遅くなります。 組み合わせたHTTPリクエストはこれを回避します。











ただし、欠点があります。複数の要求/応答が同じTCP接続を介して送信されるため、失われたデータが1つの要求のみに関係する場合でも、それらはすべてパケット損失に等しく依存します。 これは「キューの先頭をブロックする」と呼ばれます。



QUICはさらに深くなり、要求を結合するためのファーストクラスのサポートを提供します。たとえば、異なるHTTP要求は異なるトランスポートQUIC要求と見なすことができますが、同時に同じQUIC接続を使用します-つまり、追加のハンドシェイクは不要です。輻輳ステータス、QUIC要求は独立して配信されます。その結果、ほとんどの場合、パケット損失は1つの要求のみに影響します。



したがって、たとえば、パケット損失が大きい過負荷のネットワークの場合は特に、Webページ（CSS、JavaScript、画像、およびその他のリソース）の完全なレンダリングの時間を大幅に短縮できます。

とても簡単ですね

その約束を果たすために、QUICプロトコルは、多くのネットワークアプリケーションが当たり前と考えていたいくつかの前提を克服する必要があります。 これにより、QUICの実装と実装が複雑になる場合があります。



QUICは、開発を促進し、不明なプロトコルのパケットをドロップするネットワークデバイスの問題を回避するために、UDPデータグラムを介して配信されるように設計されています（ほとんどのデバイスがUDPをサポートしているため）。 また、QUICをユーザー空間に配置できるため、たとえば、ブラウザーはOSの更新を待たずに、新しいプロトコル機能を実装してエンドユーザーに伝えることができます。



ただし、ネットワークの問題を減らすという目標は、パケットを保護して適切にルーティングすることをより困難にします。

1つのNATですべてを集めて、1つの黒い意志で団結します

通常、NATルーターは、4つの値のタプル（送信元IPとポートに加えてIPと宛先ポート）を使用するTCP接続と、ネットワークを介して送信されるTCP SYN、ACK、およびFINパケットを監視します。 ルーターは、新しい接続がいつ確立され、いつ終了したかを判断できます。 したがって、NATバインディング（内部および外部IPとポート間の接続）の正確な管理が可能です。



QUICの場合、これはまだ不可能です。 現代のNATルーターはQUICをまだ認識していないため、通常はデフォルトのダウングレードで精度の低いUDP処理にダウングレードします。これは、長期間の接続に影響する可能性がある任意の（場合によっては短い）期間のタイムアウトを意味します



再バインドが発生すると（タイムアウトなど）、NAT境界の外側のデバイスは別のソースからパケットの受信を開始し、4つの値のタプルのみを使用して接続を維持できなくなります。









そして、それは単なるNATではありません！ QUIC機能の1つは接続移行と呼ばれ、デバイスが自由に接続を他のIPアドレス/パスに転送できるようにします。 たとえば、モバイルクライアントは、QUIC接続をモバイルネットワークから既知のWiFiネットワークに転送できます（ユーザーはお気に入りのコーヒーショップなどにアクセスしました）。



QUICは、接続IDの概念を使用してこの問題を解決しようとします。接続IDは、QUICパケットで送信され、接続を識別できる任意の長さの情報です。 エンドポイントデバイスはこのIDを使用して、タプルと調整せずに接続を追跡できます。 実際には、たとえば、接続の移行時に異なるパスが接続されるのを避けるために、同じ接続を指す多くのIDが必要です。これは、プロセス全体がミドルボックスではなくエンドデバイスによってのみ制御されるためです。



ただし、1つのIPで数百または数千のサーバーを識別できる可能性がある、エニーキャストとECMPルーティングを使用する通信事業者には問題がある可能性があります。 これらのネットワークの境界ルーターはまだQUICトラフィックの処理方法を知らないため、同じQUIC接続からのUDPパケットが異なるタプルで異なるサーバーに送信されることがあります。これは切断を意味します。











これを回避するために、オペレーターはよりスマートなレベルバランサーを実装する必要があります。 これは、境界ルーター自体に影響を与えることなく、プログラムで実現できます（たとえば、FacebookのKatranプロジェクトを参照）。

Qpack

HTTP / 2のもう1つの便利な機能は、 ヘッダー圧縮（HPACK）でした 。これにより、エンドポイントデバイスは、不要な要求と応答を破棄することにより、送信されるデータのサイズを削減できます。



特に、他の手法の中でも特に、HPACKは、以前のHTTP要求/応答から既に送受信されたヘッダーを持つ動的テーブルを使用します。これにより、デバイスは、新しい要求/応答で以前に遭遇したヘッダーを参照することができます（それらを再度送信するのではなく） 。



HPACKテーブルは、エンコーダー（要求/応答を送信する側）とデコーダー（受信側）の間で同期する必要があります。そうしないと、デコーダーは受信したものを単にデコードできません。



TCP上のHTTP / 2の場合、トランスポート層（TCP）は送信されたのと同じ順序で要求/応答を配信するため、この同期は透過的です。 つまり、単純な要求/応答でテーブルを更新するためのデコーダー命令を送信できます。 しかし、QUICを使用すると、事態ははるかに複雑になります。



QUICは複数のHTTPリクエスト/レスポンスを異なる方向に同時に配信できます。つまり、QUICは1方向の配信順序を保証しますが、複数の方向の場合はそのような保証はありません。



たとえば、クライアントがQUICストリームAでHTTPリクエストAを送信し、ストリームBでリクエストBを送信した場合、パケットの並べ替えまたはネットワーク損失のため、サーバーはリクエストAの前にリクエストBを受信します。リクエストAのヘッダーに示されていた場合、サーバーはリクエストBをまだデコードできないため、リクエストAをまだ見ていません。



gQUICプロトコルは、単一のgQUICストリーム内でHTTPリクエスト/レスポンスのすべてのヘッダー（ボディではなく）を連続させることでこの問題を解決しました。 これにより、何が起こっても、すべてのヘッダーが正しい順序で並べられます。 これは非常に単純なスキームであり、既存のソリューションを使用すると、HTTP / 2のコードを引き続き使用できます。 一方、これにより、キューの先頭がブロックされる可能性が高くなります。QUICはこれを削減するように設計されています。 そのため、IETF QUICワーキンググループは、HTTPとQUICの間の新しいマッピング（HTTP / QUIC）と、新しいヘッダー圧縮原理であるQPACKを開発しました。



HTTP / QUICおよびQPACK仕様の最終ドラフトでは、各HTTP要求/応答交換は独自の双方向QUICフローを使用するため、キューの開始のブロックは発生しません。 また、QPACKをサポートするために、各参加者は2つの追加の単方向QUICストリームを作成します。1つはテーブルの更新を送信し、もう1つは受信を確認します。 したがって、QPACKエンコーダーは、デコーダーが受信を確認した後にのみ動的テーブルへのリンクを使用できます。

屈折反射

UDPベースのプロトコルの一般的な問題は、攻撃者がサーバーに大量のデータを被害者に送信するように強制する場合の、リフレクション攻撃に対する脆弱性です。 攻撃者は自分のIPを偽装して、サーバーがデータ要求が被害者のアドレスから来たと判断するようにします。









この種の攻撃は、サーバーの応答が要求よりもかなり大きい場合に非常に効果的です。 この場合、彼らは「利得」について話します。



TCPは通常、このような攻撃には使用されません。元のハンドシェイク（SYN、SYN + ACKなど）のパケットは同じ長さであるため、「増幅」の可能性がないためです。



一方、QUICハンドシェイクは非常に非対称です：TLSの場合、最初にQUICサーバーは証明書チェーンを送信しますが、クライアントは数バイトのみを送信する必要があるにもかかわらず、ClientHello TLSクライアントからのメッセージはQUICパッケージに組み込まれます） このため、パッケージの内容がはるかに小さい場合でも、元のQUICパッケージを特定の最小長に増やす必要があります。 通常、サーバーの応答には複数のパケットが含まれているため、この方法はあまり効果的ではありません。したがって、クライアントパッケージの増加以上の可能性があります。



QUICプロトコルは、明示的なソース検証メカニズムも定義します。サーバーは、大きな応答を提供する代わりに、一意のトークンを持つ再試行パケットのみを送信し、クライアントはそれを新しいパケットでサーバーに送信します。 したがって、サーバーには、クライアントに代替IPアドレスがないという自信があり、ハンドシェイクを終了できます。 決定のマイナス-ハンドシェイクの時間が増加します。1パスではなく、2パスが既に必要です。



別の解決策は、サーバーの応答を、リフレクション攻撃の効果が低下するサイズに減らすことです。たとえば、 ECDSA証明書を使用します （通常はRSAよりもはるかに小さい）。 また、zlibやbrotliなどの既製の圧縮アルゴリズムを使用したTLS証明書圧縮メカニズムを試しました。 これはgQUICで最初に登場した機能ですが、現在TLSではサポートされていません。

UDPパフォーマンス

QUICの不変の問題の1つは、QUICで動作できない既存のハードウェアとソフトウェアです。 QUICがルーターのようなネットワークミドルボックスをどのように扱うかを既に検討しましたが、別の潜在的に問題のある領域は、UDPを介したQUICデバイス間でのデータの送受信のパフォーマンスです。 長年にわたり、ソフトウェア（オペレーティングシステムなど）およびハードウェア（ネットワークインターフェイス）に組み込まれたオフロード機能など、TCP実装を可能な限り最適化する努力がなされてきましたが、これはUDPに関係しません。



ただし、QUIC実装がこれらの改善と利点を上回るのは時間の問題です。 LinuxでUDPオフロードを実装する最近の取り組みを見てください。これにより、アプリケーションは、ユーザー空間とカーネル空間のネットワークスタック間で複数のUDPセグメントを約1セグメントのコストで結合および送信できます。 もう1つの例は、Linux上のソケットのゼロコピーサポートです。これにより、アプリケーションは、ユーザースペースメモリをカーネルスペースにコピーするコストを回避できます。

おわりに

HTTP / 2やTLS 1.3と同様に、QUICプロトコルには、Webサイトとインターネットインフラストラクチャの他の参加者の両方のパフォーマンスとセキュリティを向上させる多数の新機能が必要です。 IETFワーキンググループは、今年の終わりまでにQUIC仕様の最初のバージョンを展開する予定です。そのため、QUICの利点を最大限に活用する方法について考えます。