こんにちは！日々のインフラ運用やWeb開発、本当にお疲れ様です。技術メディア主筆の私です。
突然ですが、みなさんは普段何気なく見ているWebサイトの裏側で、どんな「交通整理」が行われているか気になったことはありませんか？ 私たちがブラウザでURLを叩いた瞬間、世界中のネットワークを駆け巡るデータたちは、まるで緻密にスケジュールされた郵便配達のように目的地へ向かっています。
今日は、その中でも少し通なテーマである「HTTP/2とHTTP/1.1のプロトコル変換」について、現場の泥臭いリアルな挙動を交えながら、一緒に紐解いていきたいと思います。
「HTTP/2って何だか難しそう……」「ストリームとかHPACKとか、カタカナの用語でお腹いっぱいだよ！」というインフラ初学者の方もいらっしゃるかもしれませんが、安心してください。一歩ずつ、身近な例えから優しく解説していきますね！
—
そもそも、なぜHTTP/2とHTTP/1.1の「通訳」が必要なの？
現代のWebは、高速化のために新しい通信規格である「HTTP/2」が当たり前のように使われています。HTTP/2の最大の魅力は、何といっても「マルチプレクシング（多重化）」という技術です。
HTTP/1.1の時代は、1つの通信路（道路）につき1つのファイルしか運べませんでした。だから、画像やスタイルシート（CSS）がたくさんあるWebサイトを見るときは、道路がすぐに大渋滞を起こしてしまっていたんです。
イメージとしては、「1通の手紙を送るために、わざわざ1台の軽トラックを走らせていた状態」ですね。非効率ですよね。
これがHTTP/2になると、1本の太い高速道路（TCPコネクション）の中で、いくつものレーンを同時に作って、たくさんの荷物を一気にビュンビュン運べるようになります。
でも、世の中すべてがHTTP/2に置き換わったわけではない
ここでインフラエンジニアの頭を悩ませる問題が発生します。
「うちの会社の新しいWebサーバーは超高速なHTTP/2対応だけど、クライアント（ユーザーの古いスマホアプリや社内システム）がまだHTTP/1.1しか話せない……！」なんて状況は、実務の現場ではよくあることです。
そんなとき、クライアントとサーバーの間に立つのが「リバースプロキシ（NginxやEnvoyなど）」という名の通訳さんです。
プロキシさんは、こんな大変な作業を裏で一手に引き受けています。
1. HTTP/1.1しか話せないクライアントからの手紙を受け取る。
2. 「おっ、向こうのサーバーはHTTP/2が大好きだな」と理解し、HTTP/2の言葉に翻訳してサーバーへ届ける。
3. サーバーからの返事を受け取り、再びHTTP/1.1の言葉に翻訳してクライアントへ返す。
この「翻訳」のプロセス、実は想像以上に複雑で、ネットワークの深い知識が必要とされるドラマが隠されているんです。
—
翻訳の壁①：「手紙の書き方（ヘッダー）」の根本的な違い
まず、HTTP/1.1とHTTP/2では、私たちが普段意識しない「手紙の宛名や条件（ヘッダー）」の書き方が全く異なります。
- HTTP/1.1の世界：
人間がパッと読んでわかるテキスト形式です。「Host: example.com」「User-Agent: Mozilla/…」のように、1行ずつ人間が読める文字で書かれています。
- HTTP/2の世界：
通信を極限まで速くするため、ヘッダーをすべて「バイナリ（0と1のデジタルデータ）」に変換し、さらにHPACK（エイチパック）という圧縮技術を使って、過去に送った共通の単語を省略して送ります。
プロキシでのヘッダーマッピングの苦悩
ここでプロキシの頭が痛くなるポイントがあります。例えば、HTTP/2には存在しない（あるいは禁止されている）ヘッダーがHTTP/1.1から送られてきたり、その逆が起きたりするのです。
代表的なのが `Connection` ヘッダー や `Keep-Alive` ヘッダー です。
HTTP/1.1では「この通信を切らないで維持してね」という指示をこれらで管理していましたが、HTTP/2ではコネクションの管理そのものが全く違う仕組み（ストリームという概念）で行われるため、HTTP/2の世界にそのまま持ち込むとエラー（プロトコル違反）になってしまいます。
そのため、優秀なプロキシ（例えばNginxなど）は、裏で次のような「辞書引きと検閲」を行っています。
Nginxをリバースプロキシとして使う際の設定イメージ
server {
listen 80;
server_name example.com;
location / {
# クライアントとはHTTP/1.1で話すけれど、
# バックエンドのサーバーとはHTTP/2（またはgRPCなど）で通信する設定
proxy_pass https://backend_server;
proxy_http_version 1.1;
# 【重要】HTTP/1.1特有の不要なコネクション制御ヘッダーを削除・変換する
proxy_set_header Connection “”;
proxy_set_header Host $host;
# 実際の現場では、プロキシが自動的にHTTP/2用のバイナリ形式へと
# ヘッダーを圧縮・変換してバックエンドへ流し込んでくれます。
}
}
(※上記コードは、プロキシがクライアントとサーバーの間に入り、異なるプロトコル間でのメッセージの整合性を保つための代表的な設定アプローチを分かりやすく示したものです。)
プロキシは、クライアントから届いたテキスト形式のヘッダーを一度すべてバラバラにして、HTTP/2用の「圧縮辞書（HPACK）」を使ってコンパクトに縮め、宛先を書き換えてからサーバーへパスしているのです。すごい苦労ですよね。
—
翻訳の壁②：「レーンの管理（ストリームの対応付け）」
もう一つの大きな頭痛の種が、「ストリームの多重化と逐次処理のギャップ」です。
先ほど、HTTP/2は1本の道路で同時にたくさんの荷物を運べる（マルチプレクシング）と言いました。この個々の荷物の通り道のことを「ストリーム」と呼びます。それぞれのストリームには「ストリームID（1, 3, 5…と奇数で振られる整理券番号）」が割り振られます。
ここで問題発生です。
HTTP/1.1のクライアントから、画像を読み込むためのリクエストが「バラバラのタイミングで複数」送られてきたとしましょう。
プロキシはこれを一旦すべて受け止め、HTTP/2のサーバーへ向けて「ストリームID: 1」「ストリームID: 3」という整理券を同時に発行して流し込みます。
しかし、もしバックエンドのサーバーから返事が返ってくる順番が前後したり、途中でパケットロスが起きて渋滞したりするとどうなるでしょうか？
- クライアント側（HTTP/1.1）は、基本的に古い順・来た順にしかデータを処理できません。
- プロキシ側は、HTTP/2の世界でパラレル（並行）に届いたデータを、一度キレイに交通整理し直して、HTTP/1.1のクライアントへ順序よく返してあげる必要があります。
この「並行世界（HTTP/2）」と「一本道の世界（HTTP/1.1）」の橋渡しこそが、プロキシサーバーのCPUやメモリを最も消費する、エンジニア泣かせの処理なのです。
—
トラブルシューティングの現場から：プロトコル変換の落とし穴
実際の開発現場や障害対応で、このプロトコル変換に起因するトラブルに遭遇することがあります。
例えば、「ある特定の古めのAPIクライアントからリクエストを送ると、なぜかバックエンドのHTTP/2サーバーで `STREAM_CLOSED` や `PROTOCOL_ERROR` という謎のエラーが出て接続が切断される」というケース。
だいたいの原因は、プロキシが解釈しきれなかった特殊なカスタムヘッダーの持ち込みや、Content-Length（データのサイズ）の不整合、あるいはタイムアウトの設計ミスです。
そんなときのデバッグの鉄則はこれです。
1. クライアント ⇔ プロキシ間の通信をブラウザの検証ツール（Developer Tools）や `tcpdump` でキャプチャし、HTTP/1.1として正しくリクエストが飛んでいるか確認する。
2. プロキシ ⇔ サーバー間のログ（Nginxなら `$server_protocol` や `$http2` 変数などを使った詳細ログ）を出力し、HTTP/2として正しく変換されているか追跡する。
プロトコル変換のレイヤーが入ることで、「どこで言葉のニュアンスが変わってしまったのか」を見極める力が、インフラエンジニアの腕の見せどころになります。
—
まとめ：見えない通訳たちの努力に思いを馳せて私たちができること
今回は、HTTP/2とHTTP/1.1のプロトコル変換という、一歩踏込んだ技術テーマについてお話ししました。
- クライアントとサーバーの「言語の違い」を、リバースプロキシという通訳が必死に翻訳していること。
- テキストとバイナリ（HPACK）というヘッダーの仕組みの違いを、裏で上手くマッピングしていること。
- 複数レーン（HTTP/2）と一本道（HTTP/1.1）の交通整理に、プロキシが日夜奮闘していること。
普段何気なく開いているWebページですが、その裏側ではこうしたネットワークの職人技とも言えるプロトコル変換が、コンマ数秒の間に何千回も行われています。
「なんだかネットワークの裏側って、人間社会のコミュニケーションみたいで面白いな」と思っていただけたら、インフラエンジニアとして最高に嬉しいです！
それでは、また次回の技術解説でお会いしましょう。あなたのネットワークライフが、いつもスムーズで快適なものでありますように！
コメント