HTTPリクエストの構造

リンクをクリックしたり、フォームを送信したり、APIからデータを取得したりするたびに、ブラウザはHTTPリクエストを構築してネットワーク経由で送信しています。しかし、そのリクエストは実際に何で構成されているのでしょうか?HTTPリクエストの構造を理解することで、ネットワークの問題をデバッグしたり、パフォーマンスを最適化したり、APIを構築したりする際に適用できるメンタルモデルが得られます。

この記事では、プロトコルバージョン全体にわたるHTTPリクエストの構造を分解し、フロントエンド開発者が知っておくべき最新のHTTPヘッダーとその実用的な影響について解説します。

HTTPリクエストの構造:コアコンポーネント

HTTPリクエストは3つの部分で構成されています:リクエストライン(またはその同等物)、ヘッダー、オプションのボディです。

HTTP/1.1では、リクエストは次のようになります:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 45

{"username": "dev", "email": "dev@example.com"}

リクエストラインには、メソッド(POST)、ターゲットパス(/api/users)、プロトコルバージョンが含まれます。ヘッダーはメタデータ(コンテンツタイプ、認証、キャッシュディレクティブ)を提供します。ボディは必要に応じてペイロードを運びます。

この構造は、HTTP/1.1、HTTP/2、HTTP/3全体でセマンティック的に同一のままです。変わるのは、これらのコンポーネントがどのように表現され、送信されるかです。

HTTP/1.1 vs HTTP/2 vs HTTP/3リクエスト

HTTP/1.1:テキストベースで順次処理

HTTP/1.1は、TCP上でリクエストをプレーンテキストとして送信します。リクエストは接続ごとに順次処理されます。HTTP/1.1は永続的接続(keep-alive)とパイプライン化をサポートしていますが、ヘッドオブラインブロッキングのため、ブラウザは一般的にパイプライン化を避けます。代わりに、ブラウザは複数の並列接続(通常はオリジンごとに6つ)を開くことで、単一リクエストの制限を回避します。

HTTP/1.1ではHostヘッダーが必須です。これは、どの仮想ホストがリクエストを処理すべきかをサーバーに伝えます。

HTTP/2:バイナリフレーミングと多重化

HTTP/2はメッセージをバイナリフレームでラップし、リクエストラインを置き換える疑似ヘッダーを導入します:

• :method — HTTPメソッド
• :path — パスとクエリ文字列
• :scheme — httpまたはhttps
• :authority — HostヘッダーのHTTP/2+相当で、ターゲット権限を識別するために使用

複数のリクエストは、多重化を通じて単一のTCP接続を共有します。ヘッダーはHPACKを介して圧縮され、リクエスト間で類似のヘッダーを繰り返す冗長性が排除されます。

HTTP/3:QUICと接続の回復力

HTTP/3は、TCPの代わりにUDP上でQUICを使用します。これにより、トランスポート層でのTCPのヘッドオブラインブロッキングが排除されます。1つのストリームが停止しても、他のストリームは影響を受けずに継続します。接続の移行により、リクエストはネットワークの変更に耐えられるため、Wi-Fiとセルラー間を切り替えるモバイルデバイスで特に有用です。

HTTP/3のヘッダー圧縮は、HPACKではなくQPACKを使用し、QUICの独立したストリームで正しく動作するように適応されています。

リクエストのセマンティクスは同じままです。コードは変更する必要がありません。変わるのはトランスポートです。

重要な最新HTTPヘッダー

Content-TypeやAuthorizationなどの基本的なヘッダーに加えて、いくつかの最新ヘッダーに注目する価値があります:

Fetch Metadataヘッダー(Sec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-Dest)により、サーバーはリクエストのコンテキスト(同一オリジン、クロスサイト、ナビゲーションによるトリガーかスクリプトによるトリガーか)を理解できます。

Client Hints(Sec-CH-UA、Sec-CH-UA-Platform、Sec-CH-UA-Mobile)は、構造化されたプライバシーを意識した方法でデバイスとブラウザ情報を提供し、多くのユースケースで従来のUser-Agent文字列への依存を減らします。

Priorityヘッダーは、リソースの重要度をサーバーに通知し、多重化接続で何を最初に送信するかを決定するのに役立ちますが、実際のサポートはサーバーやCDN間で異なります。

フロントエンド開発者への実用的な影響

パフォーマンスの優先順位付け

Priorityヘッダー(RFC 9218で定義)は、サーバーやCDNがレスポンスをどのように順序付けるかに影響を与えます。これは、HTTP/2時代のストリームウェイトと依存関係モデルを、urgencyとincrementalパラメータを使用したよりシンプルなスキームに置き換えます。フォントやファーストビュー画像などの重要なリソースを高優先度としてマークすることで、それらが最初に到着することを保証できます。

セキュリティの考慮事項

Content-LengthとTransfer-Encodingヘッダーの競合に注意してください。この不一致により、リクエストスマグリング攻撃が可能になります。サーバーは曖昧なリクエストを拒否すべきですが、予期しない動作をデバッグする際にリスクを理解することが役立ちます。

進化するCookieモデル

最新のブラウザでは、CookieはデフォルトでSameSite=Laxになり、明示的に設定しない限り、クロスサイトサブリクエストでCookieが送信されることが制限されます。パーティション化Cookie(CHIPS)は、トップレベルサイトごとにサードパーティCookieを分離し、埋め込みコンテンツが状態を管理する方法に影響を与えます。

まとめ

HTTPリクエストの構造(メソッド、ターゲット、ヘッダー、ボディ)は、プロトコルバージョン全体で一貫しています。変わるのはワイヤーフォーマットです:HTTP/1.1ではテキスト、HTTP/2ではバイナリフレーム、HTTP/3ではQUICストリームです。

フロントエンド作業では、HTTP/2+をデバッグする際に疑似ヘッダーを理解すること、Fetch MetadataやClient Hintsなどの最新ヘッダーを活用すること、リクエストの動作に影響を与えるセキュリティとCookieの変更を認識することに焦点を当ててください。プロトコルはトランスポートの複雑さを処理します。あなたの仕事は、実際に何を送信しているかを知ることです。

よくある質問

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.