<p><!--META { "title": "HTTP/2 HPACK圧縮: RFC 7540とRFC 7541に基づく詳細解説", "primary_category": "ネットワーク>HTTP/2", "secondary_categories": ["プロトコル", "圧縮技術"], "tags": ["HTTP/2", "HPACK", "RFC 7540", "RFC 7541", "QPACK", "ヘッダ圧縮"], "summary": "HTTP/2で採用されているHPACKヘッダ圧縮技術について、RFC 7540およびRFC 7541に基づき、その仕組み、設計目標、セキュリティ、実装上の考慮点を解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"HTTP/2のパフォーマンスを支えるHPACKヘッダ圧縮技術について深掘り。RFC 7540とRFC 7541に基づき、その仕組み、設計目標、セキュリティ、そしてHTTP/3のQPACKとの比較を解説します。#HTTP2 #HPACK #ネットワーク","hashtags":["#HTTP2","#HPACK","#ネットワーク"]}, "link_hints": ["https://www.rfc-editor.org/rfc/rfc7540", "https://www.rfc-editor.org/rfc/rfc7541"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">HTTP/2 HPACK圧縮: RFC 7540とRFC 7541に基づく詳細解説</h1> <h2 class="wp-block-heading">背景</h2> <p>HTTP/1.1は、テキストベースのシンプルなプロトコルであり、拡張性に富んでいました。しかし、複数のリソースを同時に取得する際のレイテンシの増大や、ヘッダの冗長性によるオーバーヘッドといった課題を抱えていました。特に、Webページの複雑化とモバイルデバイスの普及に伴い、これらの課題は顕著になりました。</p> <p>HTTP/2は、これらの課題に対処するために設計され、2015年5月にRFC 7540として標準化されました。HTTP/2の主要な改善点の一つが、ヘッダ圧縮技術であるHPACKです。HPACKは、RFC 7541で詳細が定義されており、HTTP/1.1の課題であったヘッダの冗長性とオーバーヘッドを大幅に削減することを目指しました。</p> <h2 class="wp-block-heading">設計目標</h2> <p>HPACK（Header Compression for HTTP/2）の設計目標は以下の通りです[1][2]。</p> <ul class="wp-block-list"> <li><p><strong>ヘッダの効率的な圧縮</strong>: 複数のリクエストやレスポンス間で共通するヘッダフィールドを効率的に圧縮し、転送データ量を削減すること。特にCookieやUser-Agentなど、冗長になりがちなヘッダの最適化。</p></li> <li><p><strong>セキュリティの確保</strong>: CRIME/BREACH攻撃のような圧縮オラクル攻撃（Compression Oracle Attack）に対する耐性を持つこと。これは、圧縮によって秘密情報が推測されるリスクを回避することを意味します。</p></li> <li><p><strong>サーバとクライアント間の状態共有</strong>: ヘッダ圧縮の効率を高めるため、サーバとクライアント間でヘッダテーブルの状態を共有し、以前に送信されたヘッダフィールドを参照可能にすること。</p></li> <li><p><strong>簡潔なヘッダ表現</strong>: ヘッダをビットレベルで効率的に表現し、パースコストを低減すること。</p></li> </ul> <h2 class="wp-block-heading">詳細</h2> <p>HPACKは、主に以下の3つのメカニズムを組み合わせてヘッダを圧縮します。</p> <h3 class="wp-block-heading">1. 静的テーブル (Static Table)</h3> <p>HPACKは、HTTPで頻繁に使用されるヘッダフィールドや値をあらかじめ定義した「静的テーブル」を持ちます[2]。このテーブルはクライアントとサーバ間で共有されており、接続確立時に特別なネゴシエーションを必要としません。例えば、<code>:method: GET</code>や<code>:status: 200</code>といった項目が、それぞれ小さなインデックス番号で表現されます。これにより、これらのヘッダフィールドを毎回文字列として送信するのではなく、わずか数バイトのインデックスで参照できるようになります。</p> <h3 class="wp-block-heading">2. 動的テーブル (Dynamic Table)</h3> <p>静的テーブルに加え、HPACKは接続中に動的に更新される「動的テーブル」をクライアントとサーバで共有します[2]。これは、以前に送信されたヘッダフィールドや値の組み合わせを格納し、それらを新しいインデックスで参照できるようにするものです。新しいヘッダフィールドが送信されるたびに、それが動的テーブルに追加され、後続の通信でそのインデックスを利用して圧縮されます。動的テーブルの最大サイズは、HTTP/2のSETTINGSフレーム（<code>SETTINGS_HEADER_TABLE_SIZE</code>）を用いてネゴシエート可能です[1]。</p> <h3 class="wp-block-heading">3. ハフマン符号化 (Huffman Coding)</h3> <p>静的テーブルや動的テーブルに存在しないヘッダ名や値は、文字列リテラルとして送信されます。この文字列リテラルをさらに効率的に転送するため、HPACKはハフマン符号化を適用します[2]。HTTPヘッダフィールドで頻繁に出現する文字のシーケンス（例: “content-type”）には短いビット列が割り当てられ、出現頻度の低い文字には長いビット列が割り当てられることで、全体のデータ量を削減します。</p> <h3 class="wp-block-heading">HPACKエンコードのフロー</h3> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["ヘッダフィールドの入力"] --> B{"静的テーブルに存在するか？"}; B -- Yes --> C["静的テーブルのインデックスで参照"]; B -- No --> D{"動的テーブルに存在するか？"}; D -- Yes --> E["動的テーブルのインデックスで参照"]; D -- No --> F{"動的テーブルに追加するか？"}; F -- Yes --> G["動的テーブルに追加"]; G --> H{"文字列値はハフマン符号化が必要か？"}; F -- No --> H; H -- Yes --> I["ハフマン符号化された文字列リテラル"]; H -- No --> J["そのままの文字列リテラル"]; C --> K["エンコード済みヘッダブロックの出力"]; E --> K; I --> K; J --> K; </pre></div> <ul class="wp-block-list"> <li><p><strong>A[ヘッダフィールドの入力]</strong>: エンコード対象のHTTPヘッダフィールド（例: <code>content-type: application/json</code>）が入力されます。</p></li> <li><p><strong>B{静的テーブルに存在するか？}</strong>: まず、このヘッダフィールドがHPACKの静的テーブルに定義されているかを確認します。</p></li> <li><p><strong>C[静的テーブルのインデックスで参照]</strong>: 存在する場合、そのインデックス（例: <code>2</code>）を使ってヘッダフィールドを表します。</p></li> <li><p><strong>D{動的テーブルに存在するか？}</strong>: 静的テーブルに存在しない場合、動的テーブルに存在するかを確認します。</p></li> <li><p><strong>E[動的テーブルのインデックスで参照]</strong>: 存在する場合、そのインデックス（例: <code>61</code>）を使ってヘッダフィールドを表します。</p></li> <li><p><strong>F{動的テーブルに追加するか？}</strong>: どちらのテーブルにも存在しない場合、このヘッダフィールドを動的テーブルに追加するかを決定します。特定のコンテキスト（例: <code>Authorization</code>ヘッダなど）では、セキュリティ上の理由から追加しない選択も可能です（<code>Never-Indexed Literals</code>）。</p></li> <li><p><strong>G[動的テーブルに追加]</strong>: 追加する場合、新しいエントリとして動的テーブルに登録されます。</p></li> <li><p><strong>H{文字列値はハフマン符号化が必要か？}</strong>: ヘッダ名や値がテーブル参照ではない文字列リテラルとして送信される場合、その文字列をハフマン符号化するかを決定します。</p></li> <li><p><strong>I[ハフマン符号化された文字列リテラル]</strong>: ハフマン符号化が適用され、より短いビット列に変換されます。</p></li> <li><p><strong>J[そのままの文字列リテラル]</strong>: ハフマン符号化が適用されない場合、文字列はそのままの形で送信されます。</p></li> <li><p><strong>K[エンコード済みヘッダブロックの出力]</strong>: 最終的に、インデックス参照または符号化された文字列リテラルとしてヘッダブロックが出力されます。</p></li> </ul> <h3 class="wp-block-heading">HTTP/2フレーム構造とHPACK</h3> <p>HTTP/2では、すべての通信がフレームとして送受信されます[1]。ヘッダは<code>HEADERS</code>フレームまたは<code>PUSH_PROMISE</code>フレームの一部として、HPACKエンコードされた「ヘッダブロックフラグメント」として転送されます。</p> <div class="codehilite"> <pre data-enlighter-language="generic">HEADERS Frame Payload (excerpt): Pad Length:8 // Paddingのバイト数 (オプション) Header Block Fragment:variable // HPACKエンコードされたヘッダデータ Padding:variable // Paddingデータ (オプション) </pre> </div> <p>HPACKエンコードされたヘッダブロックフラグメントは、複数の<code>CONTINUATION</code>フレームに分割されて送信されることもあります。</p> <h3 class="wp-block-heading">HTTP/2接続確立シーケンスとHPACK</h3> <p>HTTP/2の接続確立時、クライアントとサーバは<code>SETTINGS</code>フレームを交換し、特に<code>SETTINGS_HEADER_TABLE_SIZE</code>パラメータを通じてHPACKの動的テーブルの最大サイズをネゴシエートします。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> sequenceDiagram participant C as Client participant S as Server C -> S: TCP SYN S -> C: TCP SYN-ACK C -> S: TCP ACK C -> S: TLS ClientHello S -> C: TLS ServerHello, Certificate, ServerKeyExchange, ServerHelloDone C -> S: TLS ClientKeyExchange, ChangeCipherSpec, Encrypted Handshake Message S -> C: TLS ChangeCipherSpec, Encrypted Handshake Message Note over C,S: TLSハンドシェイク完了 C -> S: PRIORITY Frame (Optional) C -> S: SETTINGS Frame (SETTINGS_HEADER_TABLE_SIZE=4096, etc.) S -> C: SETTINGS Frame (SETTINGS_HEADER_TABLE_SIZE=4096, etc.) S -> C: SETTINGS ACK Frame C -> S: SETTINGS ACK Frame Note over C,S: HTTP/2接続確立、HPACK動的テーブルサイズネゴシエート完了 C -> S: HEADERS Frame (HPACKエンコードされたリクエストヘッダ) S -> C: HEADERS Frame (HPACKエンコードされたレスポンスヘッダ) </pre></div> <ul class="wp-block-list"> <li><p><code>C->S: SETTINGS Frame</code>: クライアントは<code>SETTINGS_HEADER_TABLE_SIZE</code>を含む<code>SETTINGS</code>フレームを送信し、動的テーブルの初期最大サイズを提案します。デフォルトは4096バイトです。</p></li> <li><p><code>S->C: SETTINGS Frame</code>: サーバも同様に<code>SETTINGS</code>フレームを送信し、自身の動的テーブル設定を伝えます。</p></li> <li><p><code>S->C: SETTINGS ACK Frame</code>: サーバはクライアントの<code>SETTINGS</code>フレームを受信・処理したことを確認します。</p></li> <li><p><code>C->S: SETTINGS ACK Frame</code>: クライアントもサーバの<code>SETTINGS</code>フレームを受信・処理したことを確認します。 このネゴシエーションにより、両端でHPACKの動的テーブルサイズが同期され、ヘッダ圧縮が開始可能になります。</p></li> </ul> <h2 class="wp-block-heading">相互運用</h2> <h3 class="wp-block-heading">HTTP/2 vs HTTP/1.1</h3> <ul class="wp-block-list"> <li><p><strong>ヘッダ圧縮</strong>: HTTP/1.1はヘッダ圧縮メカニズムを持たず、全てのヘッダをプレーンテキストで送信します。HTTP/2はHPACKにより、静的/動的テーブルとハフマン符号化を用いてヘッダを効率的に圧縮します。これにより、HTTP/2は特に多数のリクエスト/レスポンスを伴うシナリオで、オーバーヘッドを大幅に削減します。</p></li> <li><p><strong>多重化</strong>: HTTP/1.1はパイプライン処理が可能ですが、依然としてHead-of-Line Blocking（HOL Blocking）が発生しやすいです。HTTP/2は単一のTCP接続上で複数のストリームを多重化し、HOL Blockingをトランスポート層で緩和します。</p></li> <li><p><strong>二進プロトコル</strong>: HTTP/1.1はテキストベースですが、HTTP/2はフレームベースの二進プロトコルです。これにより、パースが高速化され、エラー耐性も向上します。</p></li> </ul> <h3 class="wp-block-heading">HTTP/2 vs HTTP/3</h3> <ul class="wp-block-list"> <li><p><strong>トランスポート層</strong>: HTTP/2はTCP上で動作します。HTTP/3はQUIC（UDPベース）上で動作します。QUICはTCPのHOL Blocking問題を解決し、より高速な接続確立（0-RTT接続）、マルチパス接続、信頼性の高いUDPを実現します[3][4]。</p></li> <li><p><strong>ヘッダ圧縮</strong>: HTTP/2はHPACKを使用します。HTTP/3はHPACKから派生したQPACK（RFC 9204）を使用します[5]。HPACKはTCPのin-order保証に依存しているため、QUICのような多重化されたUDPストリームでは、一つのヘッダ圧縮ストリーム上の損失が他のストリームのヘッダデコードをブロックする可能性があります（Application-layer HOL Blocking）。QPACKはこの問題を解決するため、動的テーブルの更新を専用のストリームで行い、ヘッダブロックの参照を特定の動的テーブルバージョンに紐付けることで、他のストリームのデコードをブロックしないように設計されています。</p></li> <li><p><strong>0-RTT</strong>: HTTP/2は0-RTTを直接サポートしませんが、TLS 1.3の0-RTTモードを利用できます。HTTP/3はQUICのプロトコルレベルで0-RTT接続をサポートしており、ハンドシェイクを削減して高速な接続確立が可能です。</p></li> </ul> <h2 class="wp-block-heading">セキュリティ考慮</h2> <p>HPACKとHTTP/2の設計において、いくつかのセキュリティ考慮点がなされています[1][2]。</p> <ul class="wp-block-list"> <li><p><strong>圧縮オラクル攻撃 (CRIME/BREACH対策)</strong>: HTTP/1.1で問題となったCRIME/BREACH攻撃は、圧縮率の変化を観測することで秘密情報を推測するものです。HPACKは以下のメカニズムでこれに対処しています。</p> <ul> <li><p><strong>ハフマン符号化の静的辞書</strong>: ハフマン辞書は静的であり、攻撃者が動的に辞書を操作することはできません。</p></li> <li><p><strong>Never-Indexed Literals</strong>: <code>Authorization</code>ヘッダのような機密性の高い情報は、動的テーブルに追加されず、常にリテラルとして送信されるべきとRFC 7541で推奨されています。これにより、同じ値が繰り返し送信されても圧縮率が高まらないため、攻撃者が特定の値を推測する手掛かりを減らします。</p></li> <li><p><strong>テーブルサイズ制限</strong>: <code>SETTINGS_HEADER_TABLE_SIZE</code>により、動的テーブルの最大サイズを制限できます。これにより、テーブルへの過剰なエントリ追加によるメモリ枯渇攻撃を防ぎます。</p></li> </ul></li> <li><p><strong>リプレイ攻撃</strong>: HTTP/2はTLS上で動作することを前提としているため、TLSによってリプレイ攻撃は防止されます。HPACK自体にはリプレイ保護のメカニズムはありません。</p></li> <li><p><strong>ダウングレード攻撃</strong>: HTTP/2へのダウングレード攻撃は、接続開始時に<code>PRIOR_KNOWLEDGE</code>を使用しない限り、通常TLS ALPNネゴシエーション中に発生します。HTTP/2プロトコル自体がTLSを必須としているため、ダウングレードはHTTPSからHTTP/1.1へのダウングレードとして扱われ、TLSの保護下で行われます。</p></li> <li><p><strong>キー更新</strong>: TLSセッションのキー更新は、TLSプロトコル自身によって管理されます。HPACKのテーブル状態はTLSセッションとは独立して維持されますが、TLSセッションが終了すれば、そのHPACKテーブルも破棄されます。</p></li> <li><p><strong>0-RTTの再送リスク</strong>: HTTP/2はTLS 1.3の0-RTTを直接利用できますが、0-RTTデータはリプレイ攻撃のリスクを伴います。特にべき等ではないリクエスト（例: <code>POST</code>）を0-RTTで送信する場合、サーバはそれらを慎重に処理する必要があります。HTTP/2プロトコル自体は、0-RTTリクエストの処理に関して具体的なガイダンスを提供していませんが、TLS 1.3の勧告に従うべきです。</p></li> </ul> <h2 class="wp-block-heading">実装メモ</h2> <p>HPACKを実装する際の注意点およびHTTP/2の一般的な実装考慮事項です。</p> <ul class="wp-block-list"> <li><p><strong>MTU/Path MTU</strong>: HTTP/2フレームはTCPパケットにカプセル化されるため、下位層のMTU（Maximum Transmission Unit）やPath MTUを考慮する必要があります。特に大きな<code>HEADERS</code>フレームや<code>DATA</code>フレームを送信する際は、TCPセグメント化が適切に行われるように、フラグメント化を適切に管理する必要があります。</p></li> <li><p><strong>HOL blocking回避</strong>: HTTP/2はTCPレベルでのHOL blockingは緩和しますが、HPACKの動的テーブルの更新が順不同で届いた場合、アプリケーションレベルのHOL blockingが発生する可能性があります。例えば、参照先のテーブルエントリがまだ追加されていないヘッダブロックはデコードできません。このため、実装はテーブル更新を適切に順序付けて処理する必要があります。HTTP/3のQPACKはこの問題を解決しています。</p></li> <li><p><strong>キュー制御と優先度</strong>: HTTP/2はストリームごとに優先度を設定できます[1]。これにより、重要なリソース（HTML、CSSなど）のデータがより早く転送されるよう、送信キューを制御する必要があります。HPACKヘッダブロックの送信もこの優先度付けに従うべきです。</p></li> <li><p><strong>動的テーブル管理</strong>:</p> <ul> <li><p><strong>サイズ制限</strong>: <code>SETTINGS_HEADER_TABLE_SIZE</code>でネゴシエートされた最大サイズを厳守する必要があります。テーブルがサイズを超えた場合、古いエントリを削除して新しいエントリを追加するEvictionポリシーを実装します。</p></li> <li><p><strong>エントリの追加と参照</strong>: 新しいヘッダを送信する際、それが動的テーブルに追加されるべきかを適切に判断します。また、受信側はテーブルのインデックスを正しくデコードし、テーブルの状態を送信側と同期させる必要があります。</p></li> <li><p><strong>ハフマンデコーダ/エンコーダ</strong>: ハフマン符号化された文字列の効率的なエンコード/デコードロジックを実装する必要があります。</p></li> </ul></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>HTTP/2のHPACK圧縮は、HTTP/1.1の主要な課題の一つであったヘッダの冗長性を劇的に改善し、Webパフォーマンスの向上に大きく貢献しました。静的テーブル、動的テーブル、ハフマン符号化の組み合わせにより、データ転送量を削減し、CRIME/BREACH攻撃のようなセキュリティリスクにも対応しています。</p> <p>しかし、HPACKはTCPの特性に依存しているため、HTTP/3で採用されたQPACKでは、QUICのマルチプレックス環境下でのアプリケーションレベルHOL Blockingを回避する設計が導入されました。ネットワークプロトコルの進化は継続しており、HPACKはその重要な一里塚として、現代のWeb通信基盤を支える技術の一つであり続けています。RFC 7540とRFC 7541に記載された原則は、将来のプロトコル設計においても重要な指針となるでしょう。</p> <hr/> <h3 class="wp-block-heading">参考文献</h3> <p>[1] IETF. (2015, May). <em>RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)</em>. <a href="https://www.rfc-editor.org/rfc/rfc7540">https://www.rfc-editor.org/rfc/rfc7540</a> (閲覧日: 2024年7月30日) [2] IETF. (2015, May). <em>RFC 7541: HPACK – Header Compression for HTTP/2</em>. <a href="https://www.rfc-editor.org/rfc/rfc7541">https://www.rfc-editor.org/rfc/rfc7541</a> (閲覧日: 2024年7月30日) [3] IETF. (2021, May). <em>RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport</em>. <a href="https://www.rfc-editor.org/rfc/rfc9000">https://www.rfc-editor.org/rfc/rfc9000</a> (閲覧日: 2024年7月30日) [4] IETF. (2022, June). <em>RFC 9114: HTTP/3</em>. <a href="https://www.rfc-editor.org/rfc/rfc9114">https://www.rfc-editor.org/rfc/rfc9114</a> (閲覧日: 2024年7月30日) [5] IETF. (2022, June). <em>RFC 9204: QPACK – Header Compression for HTTP/3</em>. <a href="https://www.rfc-editor.org/rfc/rfc9204">https://www.rfc-editor.org/rfc/rfc9204</a> (閲覧日: 2024年7月30日)</p>

flowchart TD
    A["ヘッダフィールドの入力"] --> B{"静的テーブルに存在するか？"};
    B -- Yes --> C["静的テーブルのインデックスで参照"];
    B -- No --> D{"動的テーブルに存在するか？"};
    D -- Yes --> E["動的テーブルのインデックスで参照"];
    D -- No --> F{"動的テーブルに追加するか？"};
    F -- Yes --> G["動的テーブルに追加"];
    G --> H{"文字列値はハフマン符号化が必要か？"};
    F -- No --> H;
    H -- Yes --> I["ハフマン符号化された文字列リテラル"];
    H -- No --> J["そのままの文字列リテラル"];
    C --> K["エンコード済みヘッダブロックの出力"];
    E --> K;
    I --> K;
    J --> K;

HEADERS Frame Payload (excerpt):
  Pad Length:8           // Paddingのバイト数 (オプション)
  Header Block Fragment:variable // HPACKエンコードされたヘッダデータ
  Padding:variable       // Paddingデータ (オプション)

sequenceDiagram
    participant C as Client
    participant S as Server

    C -> S: TCP SYN
    S -> C: TCP SYN-ACK
    C -> S: TCP ACK

    C -> S: TLS ClientHello
    S -> C: TLS ServerHello, Certificate, ServerKeyExchange, ServerHelloDone
    C -> S: TLS ClientKeyExchange, ChangeCipherSpec, Encrypted Handshake Message
    S -> C: TLS ChangeCipherSpec, Encrypted Handshake Message
    Note over C,S: TLSハンドシェイク完了

    C -> S: PRIORITY Frame (Optional)
    C -> S: SETTINGS Frame (SETTINGS_HEADER_TABLE_SIZE=4096, etc.)
    S -> C: SETTINGS Frame (SETTINGS_HEADER_TABLE_SIZE=4096, etc.)
    S -> C: SETTINGS ACK Frame
    C -> S: SETTINGS ACK Frame
    Note over C,S: HTTP/2接続確立、HPACK動的テーブルサイズネゴシエート完了

    C -> S: HEADERS Frame (HPACKエンコードされたリクエストヘッダ)
    S -> C: HEADERS Frame (HPACKエンコードされたレスポンスヘッダ)