← 研修トップ
HTTPとTLSの仕組み
GET の意味は HTTP/1.1 でも 2 でも 3 でも同じです。変わったのは運び方だけで、その運び方は、両端が何を共有しているかで決まっています。知らないステータスコードをどう読むか。リダイレクトでなぜ POST が GET に化けるのか。HTTP/2 はなぜ1本の接続で詰まり、HTTP/3 はなぜ UDP に移ったのか。TLS 1.3 はなぜ1往復で済むのか。署名しているのは証明書ではなく何なのか。RFC の逐語と手元の実演から積み上げます。
- 1約 9 分意味は1つ、運び方は版ごと — HTTP/2 の線上に GET の文字は無いGET の意味は HTTP/1.1 でも 2 でも 3 でも同じで、RFC 9110 がまとめて定義しています。版ごとに違うのは、その意味を線に載せる書き方です。
- 2約 9 分知らない値の扱いが先に決まっているから、拡張できる通信の仕組みは、両端が何を共有しているかで決まります。この回で両端が共有しているのは値の一覧ではなく、「知らない値が来たらどう扱うか」という規則です。
- 3約 8 分リダイレクトは、依頼をクライアントに作り直させるリダイレクトでサーバが返すのは、行き先とステータスコードだけです。2回目の依頼を組み立てて送るのはクライアントで、そのときメソッドを変えるかどうかの規則は、長いあいだ両端で共有されていませんでした。
- 4約 8 分条件付きリクエストは、比べる役をサーバに渡す通信の仕組みは、両端が何を共有しているかで決まります。ここで共有するのは、表現の版につけた札(ETag)です。同じ札を両端が持っていれば、本文の転送を省けます。
- 5約 9 分TLS 1.3 は、相手の答えを推測して1往復を削るTLS 1.3 の鍵交換は、両端が同じ群(方式)を使わないと成り立ちません。ところがクライアントは、サーバがどの群を選ぶかを知らないまま最初の ClientHello を送ります。
- 6約 9 分署名しているのは証明書ではなく、この会話TLS 1.3 のサーバは、証明書を送った直後に CertificateVerify を送ります。署名しているのは証明書ではなく、その接続でここまでに交わしたメッセージ全体のハッシュ(トランスクリプトハッシュ)です。
- 7約 8 分チェーンを組み立てるのは、受け取る側通信の仕組みは、両端が何を共有しているかで決まります。証明書の検証で両端が前もって共有しているのは起点(トラストアンカー)で、TLS はそれを送らずに済ませてよいと定めています。
- 8約 9 分HTTP/1.1 の応答には番号が無い — だから受け取った順に返すしかない通信の仕組みは、両端が何を共有しているかで決まります。HTTP/1.1 の要求と応答は、互いを結ぶ番号を共有していません。
- 9約 9 分HTTP/2 は番号で混ぜて返せるが、下の順序は1本のままHTTP/2 はフレームの先頭に「どの要求への応答か」を示すストリーム番号を書きます。両端がこの番号を共有しているので、応答を要求の順に並べる必要がなくなり、遅い応答の後ろで速い応答が待たなくて済みます。
- 10約 9 分HTTP/3 は、順序を守る単位をストリームに移したHTTP/2 は要求に番号を付けて1本の接続に混ぜましたが、並べ直しの順序は下の TCP 接続1本で両端が共有したままでした。1つのパケットが欠けると、関係の無い要求まで待たされます。
- 11約 9 分共有する表は、届く順序を要求するHTTP/2 のヘッダ圧縮 HPACK は、両端が同じ表を持っていることを前提に、2回目以降のヘッダを短い番号で送ります。共有しているから省略できる、というこのコースの芯そのものです。
- 12約 8 分どの版で話すかは、話し始める前に決まっているHTTPS で HTTP/2 と HTTP/1.1 のどちらを話すかは、TLS ハンドシェイクの中で ALPN という拡張が決めます。クライアントが候補を出し、サーバが1つ選んで返すだけで、ハンドシェイクで元々送るメッセージに載るので往復は増えません。