URLを打ってから表示されるまで

中級では「近くの控えから、なければ遠くへ」を見ました。上級では、その問い合わせの型とキャッシュ階層を精密にします。

• 再帰問い合わせと反復問い合わせ — あなた→フルサービスリゾルバへは「答えを持って帰って」という再帰。リゾルバ→ルート／TLD／権威サーバへは「知っている範囲を教えて、次はどこへ聞けばいい？」という反復。役割が違う
• 多段キャッシュ — 答えはブラウザ内・OS・リゾルバの各層に控えが残る。2回目が速いのはどこかで即答されるから
• ネガティブキャッシュ — 「存在しない（NXDOMAIN）」という答えも一定時間キャッシュされる。無い名前を何度も引かせないため
• 暗号化された名前解決（※1） — 通常のDNSは平文でUDPポート53を使い、経路上で覗ける。これを隠すのがDoH／DoT（HTTPS／TLSに載せる方式）

登場人物メモ：

• ※1 DoH／DoT — DNS over HTTPS／over TLS。名前解決の中身を暗号化して盗み見や改ざんを防ぐ

より詳しい階層と権威の仕組みは DNS を参照。

接続確立は往復（RTT）※1のコストそのものです。ここを削るのが高速化の主戦場になります。

TCPの3ウェイハンドシェイク — SYN → SYN-ACK → ACK。ここで1RTTを消費し、双方向到達とシーケンス番号の起点合わせを済ませます。

TLSハンドシェイク（HTTPSのみ）— 証明書の提示・検証と、鍵合意（現在は主にECDHE。盗聴前提でも2者だけの鍵を作る）を行います。

• TLS 1.3 — 手順を刈り込み、1RTTで鍵合意まで完了する
• 0-RTT再開（※2） — 一度つないだ相手には、次回待ち時間ゼロで最初のデータを乗せられる。ただし再送（リプレイ）耐性の弱さがあり、副作用のない要求に限る

つまりHTTPSの初回は、DNS＋TCP（1RTT）＋TLS（1RTT）という往復の積み重ねの上で、ようやく本題に入れます。この往復を1つでも減らす工夫が、次のHTTP進化の動機です。

登場人物メモ：

• ※1 RTT — Round Trip Time。相手まで往復する時間。距離が遠いほど1往復の重みが増す
• ※2 0-RTT — 再接続時、鍵合意の完了を待たずに最初のデータを送る高速化。副作用のある要求には使わない

TCP・TLSが通信のどの層に乗るのかは ネットワーク層 を参照。

同じ「注文と配達」でも、何本の会話を、どうさばくかが世代で変わってきました。

• HTTP/1.1 — 1接続で1つの往復を順番に処理。keep-aliveで接続は使い回せるが、前の応答が終わるまで次が待つアプリ層のHOLブロッキング（※1）が起きる。ブラウザは接続を複数本張って無理やり並列化していた
• HTTP/2 — 1本の接続の中をストリームに分けて多重化し、複数の要求／応答を同時に流す。ヘッダもHPACKで圧縮。ただし土台はTCPのままなので、パケット欠落時のTCPレベルのHOLブロッキングは残る
• HTTP/3 — 転送をTCPではなくQUIC（※2、UDPの上に構築）へ載せ替える。各ストリームを独立に扱うので、1つの欠落が他を止めない。TLSも一体化して接続確立が速く、回線が変わっても接続を保つコネクション移行もできる

登場人物メモ：

• ※1 HOLブロッキング — 先頭のつかえが後続全部を足止めする現象。どの層で起きるかで解決策が変わる
• ※2 QUIC — UDP上に再送・順序・暗号を自前で載せた新しい転送。HTTP/3の土台

確立した通信路の上で注文します。上級の主役は、そもそも往復を起こさない／軽く済ませるキャッシュ判定です。

1. ブラウザはHTTPリクエストを送る前に、手元のキャッシュが使えるかを確かめる
2. Cache-Control: max-age（※1）の期限内なら、通信せずにキャッシュを即使用する（最速）
3. 期限切れなら再検証（条件付きGET）へ。前回サーバがくれたETag（※2）をIf-None-Matchに、更新日時をIf-Modified-Sinceに載せて問い合わせる
4. 中身が同じなら 304 Not Modified（本体なし）、変わっていれば 200 ＋新しい本体が返る

このキャッシュ判定は二段構えです。手元のブラウザキャッシュ（そのユーザー専用＝private）と、経路上のCDNなど共有キャッシュ（public、みんなで再利用）。近い共有キャッシュから配れば、大元のサーバまで往復せずに済みます。

登場人物メモ：

• ※1 Cache-Control — 「何秒キャッシュしてよいか」「private／publicか」を指示する応答ヘッダ
• ※2 ETag — 中身の版を表す短い指紋。一致すれば「変わっていない」と判定できる

共有キャッシュの地理分散と配信の仕組みは CDN を参照。

材料が届いたら、ブラウザ内で DOM＋CSSOM→レンダーツリー→レイアウト→ペイント→合成 と進みます。ここで効くのが資源の優先度です。

• レンダーブロッキングCSS — CSSOMが揃うまで最初のペイントが止まる。だからCSSは小さく早く
• JSの割り込み — 同期<script>はHTMLパースを止める。defer／asyncや配置で緩和する
• 描画とJSは単一メインスレッドを奪い合う——この内部は ブラウザ 上級で深掘りする

• キャッシュが古すぎる／効かなすぎる — max-ageが長すぎると更新が届かず、無ければ毎回往復。ETagでの再検証と適切な期限で釣り合わせる
• HTTP/2にすればHOLは消える、という誤解 — 消えるのはアプリ層まで。TCPレベルのHOLはHTTP/3（QUIC）まで残る
• 証明書チェーンの不備 — 中間証明書の配布漏れで、一部の環境だけTLS検証に失敗する（自分の端末では気づきにくい）
• 0-RTTの誤用 — 待ち時間ゼロは魅力だが、再送されうるため副作用のある要求（注文確定など）に使うと二重実行の危険
• 往復の見落とし — 初回はDNS＋TCP＋TLSと往復が積み上がる。体感速度の主因は距離（RTT）であることが多く、CDNで距離を縮めるのが効く