HTTP/2のフレーミングとストリーム多重化

HTTP/2（RFC 9113）はHTTPの意味を保ったまま、メッセージをバイナリフレームとして送ります。フレームヘッダーには種類、長さ、フラグ、ストリーム識別子が含まれ、HEADERSやDATAなどを複数ストリーム間で交互に送れます。バイナリ化は通信上の表現を構造化するもので、HTTPの意味をなくしたり、入力検証を不要にしたり、脆弱性を自動で防いだりするものではありません。

複数ストリームの多重化はHTTP/1.1の応答順待ちを減らし、接続再利用を促します。ただし一般的なHTTP/2はTCP上で動くため、TCPの損失・再送待ちが同じ接続を共有する複数ストリームを遅らせる場合があります。HPACKはヘッダーフィールドを圧縮します。実際の性能はコンテンツ、実装、TLS、中継機器、回線条件で異なり、フレーミングだけでは一律の高速化を示せません。

専門家の視点：多重化の利点とTCPに残る制約

Cloudflareの技術記事でRyan Hodsonは、HTTP/2導入期のウェブ最適化として、複数ストリームを1本のTCP接続で並行処理し、反復するヘッダーを圧縮できる利点を説明しています。これは2015年の実務解説で、すべてのサイトの高速化を保証するものではありません。RFC 9113の多重化はHTTP/1.1パイプラインの応答順待ちを緩和しますが、HTTP/2 over TCPでは各ストリームが順序付きバイト列を共有します。パケット損失の再送待ちで同じ接続上の別ストリームも遅れる場合があります。

バイナリ形式だけで安全性や速度は決まらない

HTTP/2は9オクテットのフレームヘッダー、ストリーム識別子、HEADERSやDATAなどのフレームを定め、HPACKでヘッダーフィールドを圧縮します。境界が明示されても、インジェクションを自動的に防いだり、解析を必ず高速化したりするわけではありません。HTTPの意味、入力検証、中継時の変換は引き続き重要です。RFC 9218の優先度方式はurgencyやincrementalのヒントを交換する拡張仕様で、サーバーが必ず希望順に処理する保証ではありません。実装、コンテンツ、回線損失、中継機器を含めて計測しましょう。

参考資料および公式リンク