HTTP/1.1の亡霊とHTTP/2の現実：プロキシ境界におけるプロトコル変換の深層と闇
ネットワークエンジニアの夜を最も眠れなくさせるもののひとつが、プロトコル変換境界（Gateway / Reverse Proxy）の挙動だ。
現代のWebフロントエンドはHTTP/2、いやHTTP/3の波すら押し寄せている。しかし、レガシーなバックエンドアプリケーションやマイクロサービス群の足元を見れば、いまだにHTTP/1.1が息を潜めているケースは星の数ほどある。フロントの洗練されたマルチプレクシングの世界と、バックエンドの泥臭いTCPコネクションプールの世界。その狭間に立つのがリバースプロキシであり、Nginx、Envoy、あるいはAPI Gatewayといった「翻訳者たち」だ。
彼らは単にパケットを右から左へ流しているわけではない。HTTP/2のバイナリフレーミングとHPACKによる静的・動的テーブルの圧縮世界を解体し、あろうことかそれを改行コード（`\r\n`）で区切られたHTTP/1.1のテキスト世界へと再構築している。あるいはその逆だ。
今回は、このプロトコル変換の境界線上で何が起きているのか。パケットの挙動、TLSハンドシェイクの裏側、ヘッダーマッピングの罠、そして実務で踏み抜く地雷の回避策まで、ネットワークスタックの深部から徹底的に解剖しよう。
—
1. 境界におけるトランスポートとTLSの現実
HTTP/2を語るとき、私たちは真っ先に「1つのTCPコネクション上で複数のストリームを多重化（Multiplexing）する」という美しさを思い浮かべる。しかし、プロキシを介した瞬間に、この「単一コネクションの神話」は変容する。
クライアントとプロキシの間（クライアント-エッジ間）ではHTTP/2（通常はTLS 1.3が必須）が張られ、プロキシとバックエンドの間（エッジ-サーバー間）では、パフォーマンスやレガシーな制約からHTTP/1.1（場合によっては平文のTCP）が使われるという構成は、今やアーキテクチャの標準パターンだ。
ここで発生する最初の技術的課題が、「多重化の非対称性」である。
[Client] === (HTTP/2 / TLS 1.3 / 1つのTCP) ===> [Reverse Proxy] === (HTTP/1.1 / 複数のTCPコネクション) ===> [Backend App]
TCPバッファとウィンドウ制御のミスマッチ
HTTP/2側では、ひとつのTCPコネクション上で数百のストリームが流れる。これらはアプリケーション層（HTTP/2の流儀）でフロー制御（`WINDOW_UPDATE`フレーム）されるが、その下層にあるのはあくまで単一のTCP接続だ。
もしバックエンドへのHTTP/1.1コネクションがボトルネックになると何が起きるか。
プロキシは、クライアントからHTTP/2でパラレルに送られてくるリクエストを高速に受けるものの、バックエンドへ流すHTTP/1.1のコネクションプールが枯渇していれば、リクエストをプロキシ内のキューで待たざるを得ない。結果として、HTTP/2の単一TCPコネクション全体のTCPウィンドウサイズが圧迫され、「関係のない別のストリームのデータ転送までがブロックされる（Head-of-Line Blockingの亡霊の復活）」現象がエッジプロキシ内部で発生する。
これを防ぐためには、プロキシ側の接続プーリングとタイムアウト設計に極限のチューニングが求められる。例えば、Nginxであれば以下のようなディレクティブでバックエンドとのコネクション効率を最適化する。
upstream backend_cluster {
# バックエンドへのHTTP/1.1接続を維持し、コネクション確立のオーバーヘッド（TCP 3-way handshake + TLS）を排除
keepalive 32;
keepalive_requests 1000;
keepalive_timeout 60s;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
}
—
2. HPACKからテキスト形式へ：ヘッダーマッピングの迷宮
HTTP/2の最大のイノベーションのひとつが「HPACK」によるヘッダー圧縮だ。冗長なHTTPヘッダー（`User-Agent`や`Cookie`など）をインデックス化し、数バイトのバイナリ表現に縮小してネットワークを流れる。
しかし、この最適化されたバイナリがプロキシに到達した瞬間、プロキシはHPACKの「動的テーブル（Dynamic Table）」をデコードし、プレーンテキストのHTTP/1.1ヘッダーへと「翻訳」してバックエンドへ送り出す必要がある。
この変換プロセスには、セキュリティとパフォーマンスの観点からいくつかの厄介な仕様上のトラップが存在する。
偽の擬似ヘッダー（Pseudo-Header Fields）の脅威
HTTP/2には、`:method`、`:path`、`:authority`、`:scheme`といった「擬似ヘッダー」が存在する。これらはHTTP/1.1には存在しない概念だ。プロキシはこれらを以下のようにマッピングし直す。
- `:method: GET` + `:path: /index.html` $\rightarrow$ `GET /index.html HTTP/1.1`
- `:authority: example.com` $\rightarrow$ `Host: example.com`
ここで問題になるのが、悪意あるクライアントが不正な擬似ヘッダーや、HTTP/1.1の仕様では許されない制御文字を含むヘッダーをHTTP/2ストリームに混入させた場合だ。
HPACKのデコード段階で厳密なバリデーションを行わないプロキシを通過させると、バックエンドのHTTP/1.1サーバーに対してHTTP Request Smuggling（リクエストスマグリング）やヘッダーインジェクションの脆弱性を露出させることになる。
実際、過去に多くのリバースプロキシ実装において、HTTP/2の大文字混じりのヘッダー名や不正なコロン（`:`）始まりのカスタムヘッダーのハンドリング不備に起因する脆弱性が発見されてきた。プロキシ層は、単なるパケットの中継者ではなく、「プロトコル境界の厳格な検問所」でなければならない。
—
3. ストリーム管理の複雑性とライフサイクルの不一致
HTTP/1.1とHTTP/2の決定的な違いは、そのライフサイクル管理の思想にある。
- HTTP/1.1: リクエストとレスポンスは「シーケンシャル」かつ「コネクション占有」的。パイプライン化は事実上破綻しており、基本は1往復で1コネクション、あるいはKeep-Aliveによる順次処理。
- HTTP/2: 1つのコネクション上に、独立した番号を持つ「ストリーム」が無数に並行存在し、フレーム単位でインターリーブ（織り交ぜ）されて流れる。
この違いをプロキシが調停する際、次のような複雑なステートマシン管理が必要になる。
キャンセレーションの伝播問題
HTTP/2クライアントが、ブラウザのタブを閉じるなどして途中でリクエストをキャンセルした場合、クライアントはプロキシに向けて `RST_STREAM` フレームを送信する。
[Client] –(RST_STREAM)–> [Proxy] –(? Backend)–> [Backend App]
この時、プロキシはバックエンドに対して何をすべきか？
もしバックエンドとの間で既にHTTP/1.1の巨大なファイル転送や重いDBクエリが走っていた場合、プロキシがバックエンド側のTCPコネクションを即座に切断（あるいは `RST` 送信）しなければ、バックエンドは無駄なリソースを消費し続け、データベースやサーバーのCPUを焼き尽くすことになる（いわゆる「ゾンビリクエスト」問題）。
高性能なプロキシ（Envoyなど）では、HTTP/2の `RST_STREAM` や `CANCEL` を受け取った際、バックエンドへのHTTP/1.1リクエスト（もし可能であればコネクション自体の切断や、アボート処理）にどのように連動させるか、緻密なタイムアウトとキャンセルポリシーの設定が不可欠となる。
—
4. 実戦で効く！プロキシ・カーネルチューニングの極意
ここからは、実際にHTTP/2からHTTP/1.1への変換プロキシ（NginxやEnvoyを想定）を運用するインフラエンジニアに向けて、OSカーネル層からプロキシ設定に至るまでの具体的なチューニング指針をコードベースで提示しよう。
Linuxカーネルパラメータ（`/etc/sysctl.conf`）の最適化
マルチプレクシングされたHTTP/2トラフィックと、多数のHTTP/1.1バックエンド接続を同時にさばく場合、LinuxのソケットバッファとTCPの混雑制御アルゴリズムの選定がスループットを大きく左右する。
— TCPソケットバッファの動的チューニング —
メモリ消費を抑えつつ、高BDP（Bandwidth-Delay Product）環境でのスループットを最大化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
— TIME_WAITソケットの再利用と高速化 —
バックエンドとの間で短命なHTTP/1.1コネクションが頻発する場合のポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
— 輻輳制御アルゴリズムの変更 —
デ従来のCUBICから、パケットロスに強く低遅延なBBRへ移行（カーネル4.9以降）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
— 接続キューの拡張 —
突然のトラフィックバースト時にSYNパケットをドロップさせない
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
Envoy Proxy設定例：堅牢なHTTP/2-HTTP/1.1ブリッジング
現代のクラウドネイティブ環境でデファクトとなりつつあるEnvoyにおいて、プロトコル変換を行う際のガバナンスが効いた設定スニペットを示す。ヘッダーの検証やストリーム制限を明示的に行っている点に注目してほしい。
static_resources:
listeners:
- name: public_http2_listener
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
typed_config:
“@type”: type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
common_tls_context:
tls_certificates:
- certificate_chain: { filename: “/etc/ssl/certs/server.crt” }
private_key: { filename: “/etc/ssl/private/server.key” }
alpn_protocols: [ “h2”, “http/1.1” ]
filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
codec_type: AUTO # クライアント側のH2/H1を自動判定
route_config:
name: local_route
virtual_hosts:
- name: backend_service
domains: [“”]
routes:
- match: { prefix: “/” }
route:
cluster: internal_http1_backend
# バックエンドへのタイムアウト設定（ゾンビ化防止）
timeout: 30s
idle_timeout: 5s
http_filters:
- name: envoy.filters.http.router
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
# HTTP/2側の厳格なストリーム制限（リソース枯渇攻撃対策）
http2_protocol_options:
max_concurrent_streams: 100
initial_stream_window_size: 65536 # 64KB
initial_connection_window_size: 1048576 # 1MB
—
5. まとめ：プロトコル境界を制する者がインフラを制す
HTTP/2とHTTP/1.1のプロトコル変換は、単なる「新旧の互換性維持」というお茶濁しのタスクではない。そこには、バイナリとテキストの乖離、単一コネクションと複数コネクションの非対称性、そしてステートフルなストリームとステートレスに近いリクエストの調停という、ネットワークアーキテクチャの醍醐味と地雷が幾重にも埋め込まれている。
表面上の「動いた動いた」で満足するのではなく、パケットキャプチャを開き、HPACKがどのように展開され、バックエンドのTCPコネクションプールがどう呼吸しているのかを観測する。その深い洞察力こそが、障害に強く、極限まで最適化された次世代インフラを築き上げる唯一の武器となるのだ。
コメント