HTTP3の解析

はじめに

そう、あなたは橋の上で景色を眺めていて、橋の隣の家の誰かがあなたを見ているのです。

時代に取り残されないように、今日はHTTP3の新機能を解説します。

HTTPの成長の紹介

HTTPは、正式名称をHypertext Transfer Protocolといい、WWWのベースとなっているアプリケーション層トランスポートプロトコルである。1980年代後半にHTTP 0.9が誕生し、1996年に1.0にバージョンアップされたのが原型。

しかし、HTTP 1.0では、増大する物質的・文化的ニーズとより良い世界への願望を満たすことができなかった。そこで1997年にHTTP 1.1が登場し、その後2014年まで更新され続けています。

そして2015年、送信速度の速いWebアプリケーションやモダンブラウザのニーズに対応するため、GoogleのSPDYプロジェクトをベースにした新しいプロトコル「HTTP2」が開発されました。

さらに4年後の2019年、GoogleはHTTP3の基盤となる新しいプロトコル規格「QUICプロトコル」を開発し、WebサイトやAPIとユーザーのやりとりのスピードと安全性を向上させることを目的とした。

HTTPプロトコルの違いによって解決される問題

HTTPプロトコルの違いによって、解決できる問題は異なります。HTTP 1.1の問題点は何でしょうか？

1. HTTP 1.1では1つのコネクションでデータを順次送信するため、大きなパケットが先行すると後続のパケットがブロックされる Head-of-line Blockingの問題があります。

2. HTTP 1.1 はリクエストヘッダとクッキーを圧縮できないため、転送効率が悪くなることがあります。

3. 3. バッファがオーバーフローしないように、HTTP 1.1 には TCP スロースタート機能があり、輻輳制御策として、プロトコルがネットワークを繰り返し調査して利用可能な容量を計算するようになっていますが、この結果、複数のデータ転送が発生し、メッセージ遅延につながる可能性があります。

HTTP2では、メッセージングにバイナリを使用し、メッセージを複数のフレームを含むストリームに分割することで、同じ接続を使用してリソースを多重接続で送信でき、ヘッドオブラインブロッキングの問題を解決し、パケットの優先順位付けとサーバプッシュもサポートしています。

しかし、HTTP2のサーバープッシュはアプリケーションを複雑にし、パケットが失われ正しい順序で再送信しなければならない場合、TCPレベルのヘッダーブロッキングが依然として発生する可能性があります。

HTTP/2は、HTTP/1.1の拡張であり、その置き換えではないことに注意してください。アプリケーションのセマンティクスは同じで、同じ HTTP メソッド、ステータスコード、URI、ヘッダーフィールドが使用されたままです。そのため、HTTP/1.1が使われているところならどこでも、HTTP/2を使うことができます。

HTTP/2は、クライアントとサーバーの間で単一のTCP接続を使用し、対話の間、その接続は開いたままとなります。

HTTP/2は並行処理をサポートしていますが、並行処理が多すぎると、HTTP/2サーバーが大量のリクエストを受信し、リクエストがタイムアウトする可能性があります。

HTTP3とQUIC

HTTP/3の目標は、HTTP/2のトランスポート関連の問題を解決することで、あらゆる形態のデバイスで高速かつ信頼性が高く、安全なWeb接続を提供することです。これを実現するために、もともとGoogleが開発したQUICと呼ばれる別のトランスポート層ネットワークプロトコルを使用します。

<ブロッククオート

最近、中国でも応用が進んでいますが、このような基礎となるプロトコルを見て、まだ外国人が研究していることに少し寂しさを感じています。

HTTP/2とHTTP/3の根本的な違いは、HTTP/2はTCPプロトコルを底辺に使っているのに対し、HTTP/3はUDPプロトコルを底辺に使ったQUICを使っていることです。

HTTP/2とHTTP/3のプロトコルスタック比較を見てみましょう。

TCPプロトコルは主にサービスの信頼性と秩序ある配信を保証しますが、TCPは接続を確立するためにハンドシェイクを必要とし、これはクライアントとサーバーの両方が存在し、データを交換する意思と能力があることを確認するために行われます。しかし、その接続上で他の操作を行う前に、ネットワークの完全なラウンドトリップを完了させることも必要です。クライアントとサーバーが離れている場合は、接続に時間がかかります。

UDPはコネクションレス型なので、TCPよりずっとシンプルなことが分かっています。TCPのように複数のコネクションを確立するステップを必要とせず、パケットを送信するだけでいいのです。

ですから、QUICを使うメリットは、システムの遅延が少なく、オンラインゲームや広告入札、オンラインビデオ、ライブストリーミングなど、多少のパケットロスが許容される場面に適していることです。

また、UDPはブロードキャストをサポートしているため、HTTP3は正確な時間プロトコルやルーティング情報プロトコルなどのブロードキャストアプリケーションでの使用にも適しています。

また、IoTやビッグデータ、VRなどでもHTTP3は利用できます。

HTTP3はQUICプロトコルを採用しているとのことですが、QUICとは具体的にどのようなものなのでしょうか？

一般的にQUICは、TCPに非常によく似た汎用トランスポートプロトコルです。なぜ新しいプロトコルのセットを構築するのか？それは、既存のTCPプロトコルは、すでに様々なバージョンのTCPプロトコルを使用している機器が多すぎるため、拡張が非常に難しく、また、既存のTCPプロトコル上に直接拡張することは、非常に多くの機器をアップグレードすることになり、ほぼ不可能な作業となるからです。

そこでQUICは、UDPプロトコルの上に構築することを選択したのです。QUICがUDPを使ったのは、主に、インターネット上のすべてのデバイスがすでに知っていて実装しているため、HTTP/3をより簡単に展開できるようにしたかったからです。

QUICは、実際にはUDPの上にTCPを書き換えたものですが、TCPの中核機能を実装する上でTCPよりもスマートで効率的です。

次に、QUICには具体的にどのような機能があるのかを見ていきましょう。

TLS1.3

TLSは、データ転送時にクライアントとサーバー間のデータを保護するために使用され、平文データを暗号化して転送することができます。TLS1.3はTLSプロトコルの最新バージョンです。TLS1.2などの古いバージョンでは、クライアントとサーバーのハンドシェイクは少なくとも2往復必要でしたが、TLS1.3ではこれがわずか1往復に減少しています。

HTTP/2では暗号化なしのトランスポートモードがサポートされていますが、デフォルトではすべてのモダンブラウザがサポートしていないため、HTTP/2はHTTPSで使用する必要があります。長い目で見ればHTTPSは間違いなく未来なので、QUICではTLS 1.3プロトコルが直接使われ、QUIC自体がTLS 1.3をカプセル化する。

QUICは平文を実行する手段がないので、より安全性が高いというメリットがあります。また、QUICは暗号化プロトコルを内蔵しており、トランスポートと暗号化のハンドシェイクを一つにまとめ、ラウンドトリップを節約することができます。

QUICは全体が暗号化されているため、ネットワークデータの解析やカウントができなくなるISPや中間ネットワークによっては、制限がかかる場合があります。また、QUICはパケットを個別に暗号化するため、同時接続性が高い場合、性能上の問題が発生する可能性があります。

HoLブロッキングの解消

従来のHTTP1.1やHTTP2の基礎となるプロトコルはTCPですが、HTTP2はアプリケーション層で異なるファイルのデータを個々のストリームに分割し、同じ接続で転送することができます。しかしTCP自身は、これらのストリームが異なるファイルに属していることを知らないので、同じファイルとして扱われることになります。そのため、パケットロスが発生した場合、TCPはすべてのファイルパケットを再送することになります。これが、HOLブロッキングの問題につながります。

一方、QUICはもう少し細かく、パケットロスの検出と回復のロジックをストリーム単位で実行します。そのため、ファイル全体ではなく、失敗したストリームのみが再送されます。

コネクションの移行

TCPでは、クライアントとサーバーの接続を確立する場合、クライアントのIPアドレス＋クライアントポート＋サーバーのIPアドレス＋サーバーポートの4つの要素を知る必要があるんだ。

この4つの要素のうち1つでも変更を送ると、TCP接続を再確立する必要があります。そして、アプリケーションレベルのプロトコルに従って、インプロセス操作を再開する必要があります。

例えば、大きなファイルをダウンロードしているときに、ネットワークアドレスが突然変更された場合、ファイルを再要求する必要があります。

この問題を解決するために、QUICは接続識別子（CID）と呼ばれる概念を導入しています。各接続には、上記の4つの要素のうち追加の番号が割り当てられ、クライアント側とサーバー側の間のユニークな接続をマークするために使用されます。

このCIDはQUICで定義されているため、ネットワークの移行が変わっても変わることはありません。したがって、新たなハンドシェイクは必要なく、このような状況はコネクションマイグレーションと呼ばれています。

概要

さて、今日のHTTP/3とQUICはこれでおしまいです。基礎となるレイヤーの詳細には触れませんでしたが、皆さんはそれらを聞いた上で、QUICは実はUDPプロトコルの上に、より高度で効果的なTCPプロトコルを再現するラインであるとまとめるべきと思います。

HTTP3に関する今回の記事はここまでです。HTTP3の詳細については、スクリプトハウスの過去記事を検索するか、以下の記事を引き続き閲覧してください。