hexダンプ形式のHTTPリクエスト

HTTPはテキストベースのプロトコルです。つまり、HTTPリクエストのすべてのコンポーネント — メソッド、URL、ヘッダー、テキストボディ — はASCII文字で構成されています。hexエディタやパケットキャプチャで表示すると、HTTPトラフィックはASCIIカラムで読み取れると同時に、バイトレベルで分析できます。

最小限のHTTP GETリクエストのhex表現:

47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A   GET / HTTP/1.1..
48 6F 73 74 3A 20 65 78 61 6D 70 6C 65 2E 63 6F   Host: example.co
6D 0D 0A 0D 0A                                     m....

リクエスト行のバイトごとの内訳:

Hex	ASCII	コンポーネント
47 45 54	GET	HTTPメソッド
20	（スペース）	セパレータ
2F	/	リクエストURI（ルートパス）
20	（スペース）	セパレータ
48 54 54 50 2F 31 2E 31	HTTP/1.1	プロトコルバージョン
0D 0A	\r\n	CRLF行ターミネータ

hexでのHTTPメソッドの識別:

各HTTPメソッドには特徴的なhexパターンがあります:

• 47 45 54 — GET
• 50 4F 53 54 — POST
• 50 55 54 — PUT
• 44 45 4C 45 54 45 — DELETE
• 48 45 41 44 — HEAD
• 4F 50 54 49 4F 4E 53 — OPTIONS
• 50 41 54 43 48 — PATCH

ヘッダー/ボディ境界:

HTTPのhexダンプで認識すべき最も重要なパターンは、ヘッダーとボディを区切るダブルCRLF: 0D 0A 0D 0A（4バイト）です。このシーケンスの前がすべてヘッダー、後がすべてメッセージボディです。長いパケットキャプチャでは、この4バイトパターンを検索するのがレスポンスコンテンツの開始位置を見つける最速の方法です。

Content-LengthとTransfer-Encoding:

ダブルCRLF境界の後、ボディの長さは以下のいずれかで決定されます:

• Content-Lengthヘッダー（正確なバイト数を指定）
• チャンクドトランスファーエンコーディング（各チャンクはASCIIでのhexサイズで始まり、CRLFが続く）

チャンクドエンコーディングでは、31 46 46 0D 0Aのようなパターンが見られます。これはASCIIの"1FF\r\n"で、次の511バイトがボディデータのチャンクであることを意味します。

HTTPSと暗号化トラフィック:

接続がTLS/HTTPSを使用している場合、hexダンプにはTLSハンドシェイク（TLS ClientHelloの16 03 01で始まる）が表示され、その後にランダムに見えるバイトの暗号化されたアプリケーションデータが続きます。実際のHTTPコンテンツを表示するには、復号のためのTLSセッションキーが必要か、すでに復号されたポイント（プロキシやローカルループバックなど）でトラフィックをキャプチャする必要があります。

hexでの一般的なヘッダーパターン:

• 43 6F 6E 74 65 6E 74 2D 54 79 70 65 — "Content-Type"
• 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 — "Content-Length"
• 41 75 74 68 6F 72 69 7A 61 74 69 6F 6E — "Authorization"

hexダンプでこれらのパターンを認識することで、完全なASCIIレンダリングなしにキーヘッダーを素早く識別できます。