HTTP/2

読み：えいちてぃーてぃーぴーつー　／　英語表記：HTTP/2

• Web・メール・ファイル転送
• 通信の基礎

HTTPのバージョン2。1つのTCPコネクションの中に、ストリームという仮想的な通信の単位を複数作り、複数のリクエストとレスポンスを並列にやり取りできるようにした（多重化）。

イマシルちゃんの解説

Webページを開くときは、本文のほかにも画像やプログラムを取りに行くよ。
HTTP/1.1では要求を続けて送る方法もあるけれど、同じ接続では要求の順番に応答を返す必要があるんだ。
先の応答に時間がかかると、後のデータも待たされてしまうよ。

HTTP/2は、やり取りごとにストリームという単位を作り、番号を付けて区別するWeb通信のプロトコルだよ。
別のやり取りのデータを同じ接続へ交互に流せるから、複数の応答を並列に進められるんだ。
ただし、下位のTCPでデータが失われたときの再送待ちまではなくならないよ。

より深い解説

定義

HTTP/2は、RFC 9113（元はRFC 7540、2015年）で定められたHTTPのバージョンである。HTTP/1.1の意味（メソッド、ステータスコード、ヘッダーなど）はそのままに、通信の方式を大きく変えて、Webページの表示を高速化した。通常はTLSの上で使う。

主な特徴

要求先や処理結果を表すフィールド

HTTP/1.1はリクエスト行にメソッドや対象のパスを、ステータス行に応答コードを書く。HTTP/2では、これらをコロンで始まる疑似ヘッダーフィールドで表す。通常のヘッダーフィールドと合わせてHPACKで圧縮し、HEADERSフレームなどで送る。本文はDATAフレームで運ぶ。

最初の四つは要求側、最後の一つは応答側で使う。CONNECTには専用の規則があるため、すべてのメソッドが同じ組合せになるわけではない。

HTTP/1.1で要求先を示すHostヘッダーに対応する情報は、HTTP/2では:authorityで送る。リバースプロキシが複数のWebサイトを扱うときも、この要求先の情報が振り分けの手掛かりになる。フィールドを圧縮しても、その意味や要求先を区別する役割は変わらない。

HTTP/1.1との比較

HTTP/1.1のパイプライン処理では、先の応答を待たずに複数の要求を送れる。しかし同じ接続の応答順序は維持する必要があり、HTTP/2のストリーム多重化とは異なる。RFC 9112の9.3.2節にこの制約が示されている。

TCPのHoLブロッキングが残る理由

HTTP/2のストリームは、すべて1つのTCPコネクションの上を流れる。TCPは、パケットが1つ失われると、それより後ろのデータを、再送が届くまでアプリケーションに渡さない。そのため、あるストリームのパケットが失われると、関係のないほかのストリームまで止まってしまう。パケット損失の多い回線では、HTTP/1.1で複数のコネクションを使うより遅くなることもある。この問題を解決するため、HTTP/3では、TCPの代わりにUDPの上で動くQUICを使う。

NAPTへの影響

HTTP/1.1では、応答順序の制約を分散するために、1台のPCが同じサーバに複数のTCPコネクションを張る場合があり、NAPTの変換エントリーも使う。HTTP/2では同じ接続へ複数のやり取りをまとめられるため、接続数と変換エントリーの消費を減らせる場合がある。接続先の数や実装条件によって、全ての通信が常に一本になるとは限らない。

参考資料

• RFC 9113 §8.3：要求と応答のフィールド
• RFC 7541：ヘッダーの圧縮方式

実際の試験ではここに出る！全4問

ネットワークスペシャリスト

午後Ⅰ

• R7春 問2
• R5春 問1

午後Ⅱ

• R4春 問2

午前Ⅱ

• H30秋 問15

この用語が出てくる記事

• WebSocket
• HTTP
• HTTP/3
• HTTP/2導入とハイブリッドクラウドの設計
• HTTPリクエスト
• TLS
• フロー制御
• HoLブロッキング
• リバースプロキシ