HTTP/1.1 — Web Protocol Lab

#このページで確認できること

HTTP/1.1 の開始行とヘッダーフィールドがテキスト形式であることを curl -v と nc で確認する
Keep-Alive によるコネクション再利用を curl の出力で確認する
Head-of-line blocking がどこで発生するかをシーケンスで確認する
試すURL: https://web-protocol-lab.com/status/200

公開範囲: このページのcurl例は公開URLで実行できます。HTTPSのパケットキャプチャからHTTPメッセージを読むには、ブラウザのキーログなど復号に必要な情報を別途用意します。

#特徴

テキスト形式の開始行とヘッダー: リクエストライン・ステータスライン・ヘッダーフィールドはテキストとして読めるため、telnet や nc で手打ちできる。ボディは画像を含む任意のオクテット列であり、テキストとは限らない。
持続的接続 (Keep-Alive): HTTP/1.1の基本仕様では、明示的に閉じない限りコネクションを再利用できます。Connection: close は、応答後に接続を閉じることを相手へ伝えます。
パイプライン化は主要ブラウザでは通常使われない: 仕様上は複数リクエストを応答待ちせずに送れるが、サーバーは応答をリクエスト順に返す必要がある。応答順序の制約や中間装置との互換性から、主要ブラウザ実装では一般に利用されていない。
Head-of-line blocking: パイプライン化した場合でも、先行レスポンスが完了するまで後続レスポンスを返せない。ブラウザは複数コネクションで緩和することがあるが、本数は実装や環境に依存する。
メッセージボディの長さ: Content-Length や Transfer-Encoding: chunked のほか、メソッド・ステータスによるボディなしの規則や、接続クローズによって決まる場合がある。

#通信シーケンス

HTTP/1.1 over TLS — 基本シーケンス

participants: Client, Server
Client -> Server: TCP SYN
Server --> Client: SYN/ACK
Client -> Server: ACK
note: TCP 3-way handshake 完了
Client <-> Server: TLS handshake (ClientHello / ServerHello ...)
Client -> Server: GET /index.html HTTP/1.1
Server --> Client: HTTP/1.1 200 OK + headers
Server --> Client: Response body
note: Keep-Alive により同一コネクションで次のリクエストを送れる
Client -> Server: GET /style.css HTTP/1.1

パイプライン時の Head-of-line blocking — 応答順序は入れ替えられない

participants: Client, Server
Client -> Server: GET /slow (処理に時間がかかる)
Client -> Server: GET /fast (応答を待たずに送信)
note: /fast の処理が先に終わっても、応答はリクエスト順に返す
Server --> Client: 200 OK (/slow, ようやく完了)
Server --> Client: 200 OK (/fast)

#検証コマンド

curl — HTTP/1.1 を明示して観測

$ curl -v --http1.1 https://web-protocol-lab.com/status/200
# -v で「> GET /status/200 HTTP/1.1」「< HTTP/1.1 200 OK」を確認

$ curl -v --http1.1 -H 'Connection: close' https://web-protocol-lab.com/status/200
# レスポンス後にコネクションが閉じられることを確認

openssl — TLS接続へHTTP/1.1を手動送信

$ printf 'GET /status/200 HTTP/1.1\r\nHost: web-protocol-lab.com\r\nConnection: close\r\n\r\n' \
    | openssl s_client -quiet -connect web-protocol-lab.com:443 \
        -servername web-protocol-lab.com -alpn http/1.1
# TLSの内側へ、開始行とヘッダーフィールドをテキストで送る

応答例 (主要ヘッダーの抜粋)

HTTP/1.1 200 OK Server: nginx Content-Type: text/plain Connection: close X-Demo: status-200 200 OK

#観測ポイント

curl	`-v` でリクエスト/レスポンスの生テキスト。`--http1.1` で強制。2回連続リクエストで `* Re-using existing connection` が出れば Keep-Alive が効いている。
DevTools	Network → 対象リクエスト → Headers で `Protocol` 列 (http/1.1)。Timing タブで Stalled(コネクション待ち)を観測。
Proxy	HTTP/1.1を終端するプロキシは、メッセージを解析して転送する。`Via: 1.1 proxy-name` の付与、Hop-by-hop ヘッダー(`Connection`, `Keep-Alive`)が次のホップへそのまま転送されないことを確認。
tcpdump / Wireshark	公開URLはHTTPSです。通常のキャプチャではTCPとTLSの流れを確認でき、HTTPメッセージを読むには復号設定が必要です。
TLS inspection	装置がTLSを終端し、クライアント側でHTTP/1.1を選択した場合は、復号後のメッセージを解析します。ヘッダーの追加や正規化を直接接続と比較します。

tcpdump

$ sudo tcpdump -i <interface> -w http11.pcap 'tcp port 443'
# 公開URLとのTLS通信を保存し、必要に応じてWiresharkで復号する

#HTTP/2 へ続く課題

HTTP/1.1 の限界がそのまま HTTP/2 の設計動機になっています。

応答順序の制約と、非パイプライン時の直列処理 → HTTP/2 の多重化(ストリーム)
毎回同じヘッダーをテキストで送る冗長性 → HPACK ヘッダー圧縮
テキスト解析のコストと曖昧さ → バイナリフレーミング

続き: HTTP/2 →