パケットの鼓動を聞け：HTTPリクエストラインという「通信のパスポート」を解剖する
ネットワークエンジニアとして現場に立ち続けていると、若手から「Web APIがうまく叩けないんです」と相談を受けることがよくある。ログを見てみると、往々にして原因はパケットの「顔」であるHTTPリクエストラインの不備にある。
ブラウザの裏側で、あるいはアプリケーションの深淵で、何が行われているのか。今日はHTTP/0.9から続く、Web通信の根幹「リクエストライン」の構造と、現場で生き残るためのデバッグ視点を語ろう。
—
1. リクエストラインとは何か？――通信の「挨拶」と「意志」
HTTPリクエストラインは、TCPコネクションが確立された直後、クライアントがサーバーに対して最初に叩きつける文字列だ。RFC 7230（および最新のRFC 9112）によれば、この一行には通信のすべてが集約されている。
METHOD SP REQUEST-URI SP HTTP-VERSION CRLF
この3つの要素が欠けることはない。順を追って紐解こう。
メソッド（METHOD）
「何をしてほしいのか」という意志だ。`GET`（取得）、`POST`（作成・送信）、`PUT`（更新）、`DELETE`（削除）が代表格だが、現場で最も見るべきは冪等性（Idempotency）の遵守だ。`GET`でサーバーの状態を変えてしまうような設計は、キャッシュやリトライ処理で必ずエンジニアの首を絞めることになる。
リクエストURI（REQUEST-URI）
「どこにアクセスするのか」を示すパスだ。ここで重要なのは、URIの長さ制限（RFCで明確な制限はないが、Webサーバーやプロキシ側で8KB制限などを設けている場合が多い）と、エンコーディングの罠だ。特殊文字や日本語をURLエンコードせず投げれば、当然のように400 Bad Requestが返ってくる。
HTTPバージョン（HTTP-VERSION）
「どのルールで会話するのか」の宣言だ。`HTTP/1.1`を明示することで、コネクションの持続（Keep-Alive）やチャンク転送といった現代的なネットワーク効率化の恩恵に預かれる。
—
2. 現場のツールで「生のパケット」を観察する
教科書を読んでいるだけでは、パケットの鼓動は聞こえない。実際に手を動かして、サーバーがどうリクエストラインを受け取っているかを確認しよう。
curlで「生の会話」を覗く
デバッグの基本中の基本だ。`-v`（verbose）オプションを使えば、隠れたヘッダーやリクエストラインの全貌が可視化される。
-vオプションで通信過程をすべて表示
-o /dev/nullでレスポンスボディを捨てる（ヘッダー確認に集中）
curl -v -X POST “https://api.example.com/v1/users” \
-H “Content-Type: application/json” \
-d ‘{“name”: “engineer”}’ \
-o /dev/null
出力結果の先頭を見てほしい。
`> POST /v1/users HTTP/1.1`
これこそがリクエストラインだ。この一行がズレているだけで、ロードバランサーは行き先を失い、WAFは不審な通信として遮断する。
Fetch APIでリクエストを生成する
フロントエンドからの通信も、本質は同じだ。
// ブラウザコンソール等で実行可能なFetchの例
fetch(‘https://api.example.com/v1/users’, {
method: ‘POST’, // ここがリクエストラインのMETHODに入る
headers: {
‘Content-Type’: ‘application/json’
},
body: JSON.stringify({ name: ‘engineer’ })
})
.then(response => console.log(‘ステータス:’, response.status));
—
3. 実務で遭遇する「リクエストライン」の落とし穴
長年インフラを見ていると、リクエストラインにまつわる「鉄板のトラブル」がいくつかある。これらは覚えておいて損はない。
- HTTP/1.0 と Keep-Alive の不一致:
古いレガシーシステムを叩く際、サーバーがHTTP/1.0しか解釈できず、`Connection: keep-alive`を送ってもコネクションが即座に切断されることがある。リクエストラインでバージョンをどう指定するかは、実は性能に直結する。
- プロキシサーバーによる書き換え:
途中に挟まるリバースプロキシ（NginxやHAProxy）が、内部転送時にリクエストラインを微妙に改変することがある。特にURIの正規化（`/./`や`/../`の処理）は、セキュリティ診断で突かれるポイントだ。
- 改行コード（CRLF）の欠落:
手製のソケット通信プログラムを書く際、最後に`\r\n`を忘れてサーバーからタイムアウトを食らうケース。HTTPプロトコルは、この「改行」がなければリクエストが完結したと判断できない。
—
最後に：ネットワークを「見る」ということ
リクエストラインは、プロトコル解析における「起点」だ。ここを読み解く力があれば、Wiresharkのパケットキャプチャ画面がただの乱数に見えることはなくなる。
「なぜ400が返るのか？」「なぜプロキシで502になるのか？」――そう悩んだときは、まず通信の先頭行、つまりこのリクエストラインに戻ってきてほしい。そこにすべての答えが記されているはずだ。
次は、このリクエストに続く「HTTPヘッダー」の深淵について話そうか。プロトコルの解像度を上げれば、インフラはもっと面白くなる。
コメント