こんにちは、皆さん。日々のインフラ運用やAPI設計、お疲れ様です。
私たちは普段、ブラウザの向こう側やモバイルアプリから飛んでくるリクエストを当たり前のようにさばいています。「HTTP/2になってマルチプレクシングのおかげで速くなったよね」なんて語られることは多いですが、皆さんはその下層、すなわちTCPセグメントの上に構築されたストリームの中で、パケットがどのような「武装」をしているか意識したことがあるでしょうか？
今回は、HTTP/2の知られざる（しかしセキュリティの文脈では極めて重要な）機能、「データフレーム（DATA）のパディング（Padding）」について、現場のシニアエンジニアの視点から徹底的に掘り下げていきたいと思います。
教科書通りの仕様の丸暗記ではなく、「なぜそれが必要なのか」「実務でどう影響するのか」「どうやってデバッグするのか」を一緒に見ていきましょう。
—
1. なぜHTTP/2にパディングが必要なのか？（サイドチャネル攻撃の脅威）
HTTP/1.1の時代から、Webの通信はTLS（HTTPS）によって暗号化されています。「暗号化されているんだから、盗聴されても中身は見えない安全な通信だ」――そう信じられていた時期が私たちにもありました。
しかし、セキュリティの世界は日進月歩です。暗号化されたデータそのものは読めなくても、「そのデータが何バイトのサイズ（長さ）を持っているか」というメタデータから、通信の機微を推測するという巧妙な攻撃手法が存在します。これがサイドチャネル攻撃（代表例として BREACH や CRIME、あるいはHTTPSトラフィック解析による機密情報の特定など）です。
例えば、あるユーザーが特定のAPIエンドポイントにアクセスした際、返ってくるレスポンスのバイト数が「ユーザーの権限（管理者か一般か）」や「入力された検索クエリの特定のパターン」によって微かに変わるとしたらどうでしょう？ 攻撃者は、暗号化されたパケットの長さを観測し続けることで、暗号を解読することなく、ユーザーの機密情報を暴き出すことができてしまうのです。
この脆弱性に正面から対抗するため、HTTP/2（RFC 7540）では、フレームのペイロードサイズを意図的にカモフラージュする「パディング機能」が標準で組み込まれました。
—
2. 仕様の深掘り：DATAフレームとパディングの構造
HTTP/2の基本単位は「フレーム」です。すべてのフレームは9バイトの共通ヘッダーを持ち、その後にペイロードが続きます。
DATAフレーム（Type = `0x0`）において、パディングがどのように組み込まれているか、そのバイナリ構造を見てみましょう。
データの配置とフラグ
DATAフレームの先頭には、フラグ（Flags）を格納する1バイトがあります。ここでパディングを有効にするために使用されるのが `PADDED` フラグ（`0x8`） です。
`PADDED` フラグが有効（立っている）場合、ペイロードの先頭1バイトに「Pad Length（パディングの長さ）」を表すフィールドが出現し、その直後に実際のデータ（Data）、そして最後にパディング領域（Padding）が配置されます。
+———————————————–+
| Length (24) |
+—————+—————+—————+
| Type (8) | Flags (8) |
+-+————-+—————+——————————-+
|R| Stream Identifier (31) |
+-+—————————————————————+
| [Pad Length?] | Data Payload… |
+—————————————————————+
| [Padding…] |
+—————+
- Pad Length (1バイト): 直後のパディング領域が何バイトあるかを示します（0〜255バイト）。この値自体もパディングの長さに含まれます。
- Padding (可変長): 実際の長さを隠蔽するためのダミーデータです。仕様上、パディングの中身はすべて `0x00`（ヌルバイト）で埋められることが推奨されます。
この仕組みにより、サーバー側（またはクライアント側）は、実際のデータサイズに任意の「ゲタ（ノイズ）」を履かせて送信できるようになりました。攻撃者は正確なコンテンツの長さを特定できなくなり、サイドチャネル攻撃の精度が大幅に減衰するというわけです。
—
3. パフォーマンスへのトレードオフ（現場のジレンマ）
「セキュリティが上がるなら、常に大きめのパディングを盛っておけばいいじゃないか」と思われるかもしれません。しかし、ネットワークエンジニアの常として、「セキュリティの強化には、必ずパフォーマンス上のコスト（代償）が伴う」という鉄則があります。
パディングの運用において、現場のエンジニアが直面するトレードオフは主に以下の2点です。
1. 帯域幅の無駄遣い（Goodputの低下）:
数バイトの小さなAPIレスポンス（例えば `{“status”:”ok”}` など）に対して、数十〜数百バイトのパディングを付与した場合、実効スループット（Goodput）が著しく低下します。モバイル回線やIoTデバイスなど、帯域が限られた環境では致命的なオーバーヘッドになり得ます。
2. CPU・メモリ負荷:
パディングを生成・付与するエンコード処理、および受信側でパディングをパースして切り捨てるデコード処理は、わずかではありますがCPUサイクルを消費します。超高スループットを要求されるAPIゲートウェイ等では、この積み重ねが無視できないボトルネックになることがあります。
したがって、実務では「すべてのフレームに一律でパディングを入れる」のではなく、「セッションの秘匿性が特に高いエンドポイントや、タイミング攻撃のリスクがある認証系トラフィックに絞って適切に制御する」といったチューニングのセンスが問われます。
—
4. 実践：パディングを観測・制御するコードと設定例
「理屈は分かったけれど、実際にどう扱えばいいのか？」
ここからは、開発やデバッグの現場ですぐに使える具体的なアプローチを見ていきましょう。
① Python (h2ライブラリ) を使ったパディング付きDATAフレームの送信
HTTP/2の低レイヤーをハンドリングするPythonの `h2` ライブラリを使用すると、パディング長を明示的に指定したデータ送信が可能です。
import h2.connection
import h2.config
HTTP/2クライアント設定の初期化
config = h2.config.H2Configuration(client_side=True)
conn = h2.connection.H2Connection(config=config)
conn.initiate_connection()
stream_id = 1
ヘッダーの送信（省略）
送信したい実際のペイロード
real_data = b'{“user_id”: 12345, “role”: “admin”}’
サイドチャネル攻撃対策として、あえてパディングを50バイト付与する
padding_len には 0 から 255 までの整数を指定可能
padding_length = 50
padded_payload = real_data + b’\x00′ padding_length
DATAフレームの送信（PADDEDフラグが自動的に考慮される、またはライブラリの仕様に依存）
※実際のフレーム送信バッファを取得するコード例
conn.send_data(
stream_id=stream_id,
data=real_data,
pad_length=padding_length, # ネットワーク層でパディングを付与して送信
end_stream=True
)
生成されたバイナリデータをソケットへ流し込む
out_data = conn.data_to_send()
socket.sendall(out_data)
② Go言語 (net/http) での挙動と注意点
Go言語の標準ライブラリ（`net/http`）は非常に優秀ですが、HTTP/2のパディング制御に関しては、基本的にはGoのHTTP/2内部実装（`golang.org/x/net/http2`）が自動的に最適化して処理します。
一般的なWebアプリケーション開発者が、アプリケーションコードから直接「このレスポンスに〇バイトのパディングを乗せろ」と細かく指示するためのパブリックAPIは、通常提供されていません。これは、誤ったパディング実装による脆弱性やプロトコル違反を防ぐための設計上の配慮でもあります。
もしリバースプロキシ（EnvoyやNginxなど）のレイヤーでパディングの挙動をコントロールしたい場合は、それぞれのプロキシのHTTP/2モジュール設定（例: Envoyの `http2_protocol_options` など）を確認する必要があります。
—
5. デバッグとトラブルシューティングの現場Tips
「APIレスポンスのサイズがおかしい」「プロキシのログとクライアントの受検データが一致しない」といったHTTP/2特有のトラブルに直面したとき、パディングの存在を知っていると原因究明のスピードが劇的に変わります。
トラブルシューティング手順
1. Wiresharkやnghttp2でのパケットキャプチャ:
TLSが絡むため、ブラウザやクライアントのSSLKEYLOGFILEを出力させ、Wiresharkに読み込ませてHTTP/2の復号化を行います。
2. フレームの確認:
パケットの詳細ツリーで `HTTP/2` -> `Data Frame` を展開します。
- `Flags: 0x08 (PADDED)` が立っているか？
- `Pad Length` に予期せぬ大きな値が入っていないか？を確認します。
3. 「フレーム長」と「データ長」の不一致に惑わされない:
HTTP/2のフレームヘッダーにある `Length`（24ビット）は、パディングの長さ（Pad Lengthの1バイト分）とパディング自体のバイト数を含んだ合計の長さを表しています。
- デバッグ時に「ペイロードが短いのにフレームサイズやけにデカいぞ？」と思ったときは、大抵このパディングが原因です。仕様の読み違えに注意してください。
—
まとめ
HTTP/2のパディング機能は、日々の高速化の裏側で、私たちのプライバシーとセキュリティを静かに守るための「いぶし銀」な技術です。
普段、アプリケーション層のコードを書いているだけでは意識する機会は少ないかもしれませんが、インフラの深部、あるいは高度なセキュリティ要件を持つAPIを設計・運用するシニアエンジニアにとっては、必須の教養であり武器となります。
パケットの1バイト1バイトに込められた設計者の意図を想像できるようになると、ネットワークのトラブルシューティングはぐっと面白くなります。ぜひ、次回のパケット解析の際には、DATAフレームの端っこに隠されたパディングにも目を向けてみてください。
それでは、また次回のテクニカルコラムでお会いしましょう！
コメント