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

🎬 アニメーション『パケットの旅』の ②〜⑤ のところです！

名前解決は「近くの控えから確認し、なければ遠くへ聞きに行く」仕組みです。必ずこの順で進みます:

1. ブラウザは自分では調べず、OSのリゾルバ※1に「example.com のIPアドレスを教えて」と依頼する（アプリは直接ネットワークに触れず、必ずOSを通る）
2. OSはまずキャッシュ※2を確認する。答えの控えが残っていればここで即終了——そのまま②へ進む
3. 控えがなければ、設定されたフルサービスリゾルバ※3（通常は契約プロバイダかルーター）へ問い合わせる（主にUDPのポート53）
4. リゾルバも知らなければ、ルートサーバ → .com のTLDサーバ → example.com の権威サーバ※4と、住所帳の階層を上から順にたどる（これが再帰問い合わせ※5）
5. 得られた答え——Aレコード※6（= IPアドレス）——が、TTL※7の期間だけ各所に控えを残しながらブラウザまで戻ってくる

登場人物メモ（※の説明）:

• ※1 リゾルバ — OSに内蔵された名前解決の窓口。全アプリの「調べて」がここに集まる
• ※2 キャッシュ — 一度調べた答えの控え。2回目のアクセスが速い理由はほぼこれ
• ※3 フルサービスリゾルバ — あなたの代わりに世界中へ聞いて回るDNSサーバ。初級の「人脈最強の友達」の正体
• ※4 ルート／TLD／権威サーバ — 住所帳の階層。「世界の目次 → .com の目次 → example.com 本人」の順に詳しくなる
• ※5 再帰問い合わせ — 自分が知らなければ、他をたどってでも必ず答えを持ち帰る聞き方
• ※6 Aレコード — 「この名前のIPアドレスはこれ」という台帳の1行
• ※7 TTL — 控えの賞味期限。切れたら調べ直す

⚠️ イレギュラー（うまくいかないとき）:

• 名前が存在しない — 権威サーバが「そんな名前はない」と答える（NXDOMAIN）。ブラウザは「サーバが見つかりません」と表示。旅は①で終わり、②以降は始まらない
• リゾルバが応答しない — 一定時間待って（タイムアウト）、予備のDNSサーバへ聞き直す。全滅なら接続エラー
• 控えが古い — サーバが引っ越した直後は、TTLが切れるまで古い住所へ案内されることがある

🎬 アニメーション『パケットの旅』の ⑥〜⑧（緑の枠 = 3ウェイハンドシェイク）のところです！

IPアドレスがわかったら、そのIPのポート※1 443（HTTPSの場合）に向けて、2段階の準備をします。順序は必ず TCPが先、TLSが後です。

第1段階 — TCPの3ウェイハンドシェイク※2（初級の「3回の挨拶」の正式名）:

1. こちら → サーバ: SYN（シーケンス番号※3を添えて「話したい」）
2. サーバ → こちら: SYN-ACK（「受けた、こちらの番号はこれ」）
3. こちら → サーバ: ACK（「確認した、始めます」）

この3ステップ（メッセージ3本＝往復にして約1.5回）で「相手は実在し、双方向に届き、番号の起点を共有した」状態になり、欠落の検知・再送・順序の保証——つまり信頼できる通信が可能になります。

第2段階 — TLSハンドシェイク※4（HTTPSの場合のみ）:

1. サーバが証明書※5を提示し、ブラウザが「本物の example.com か」を検証する
2. 鍵合意※6（現在は主にECDHE）で、この通信専用の暗号鍵をその場で作る
3. 以降のやり取りは、すべてこの暗号化された道の上を流れる

登場人物メモ（※の説明）:

• ※1 ポート — 同じ機械の中の窓口番号。Webの窓口は443（HTTPS）と80（HTTP）
• ※2 3ウェイハンドシェイク — SYN → SYN-ACK → ACK の3ステップ（メッセージ3本＝約1.5往復）。TCPの接続開始の作法
• ※3 シーケンス番号 — データに振る通し番号。抜けや順番の乱れをこれで見つける
• ※4 TLS（ハンドシェイク） — 通信を暗号化する層。アドレスバーの鍵マークの正体
• ※5 証明書 — 「私は本物の example.com です」を第三者（認証局）が保証する身分証
• ※6 鍵合意 — 盗み聞きされている前提でも、2人だけの鍵を作れる数学的な手順

⚠️ イレギュラー（うまくいかないとき）:

• 途中でデータが消えた — ACKが返らないのでTCPが自動で再送する。人間は気づかない（少し遅く感じるだけ）
• 証明書がおかしい — 期限切れ・名義違いなどは、ブラウザが赤い警告画面で旅を中断する
• 窓口に誰もいない — 接続拒否（RST）が返り、「このサイトにアクセスできません」になる

🎬 アニメーション『パケットの旅』の ⑨〜⑪ のところです！

確立した通信路の上で、ようやく本題の注文です:

1. ブラウザがHTTPリクエスト※1を送る。実体はテキストの依頼書で、GET /index.html HTTP/1.1 という1行目に、Host や User-Agent などのヘッダ※2が続く
2. サーバはステータスコード※3 + ヘッダ + ボディ（HTML本体）を返す
3. ブラウザはHTMLを解析（パース）※4しながら、<link>（CSS）・<img>（画像）・<script>（JS）を見つけるたびに追加リクエストを発行する
4. この繰り返しで、1ページの表示に数十〜数百往復が発生する——だから控え（キャッシュ）とCDN※5が効く

登場人物メモ（※の説明）:

• ※1 HTTPリクエスト — 「何がほしいか」を書く定型の依頼書
• ※2 ヘッダ — 依頼書・返事の欄外メモ。差出人（ブラウザの種類）や希望（言語・圧縮方式）を書く

• ※3 ステータスコード — 返事の結果を表す3桁の数字。200=成功、404=品物がない、500=お店側の事故

• ※4 解析（パース） — 設計図を上から読み解いていく作業
• ※5 CDN — 世界中に置いたコピー配布拠点。近い拠点から配ることで速くする仕組み

⚠️ イレギュラー（うまくいかないとき）:

• 404 Not Found — 道はつながり注文も届いたのに、品物だけがない。①や②の失敗とは起きる場所が違うのがポイント
• 5xx — お店側の事故。あなたの操作は正しくても起きる
• リダイレクト（301/302） — 「引っ越しました、こちらへ」。ブラウザは新しい住所へ自動でもう一度注文し直す（Networkタブだと往復が1回増えて見える）

🎬 アニメーション『パケットの旅』の ⑫（最後のコマ）のところです！

材料が届いたら、ブラウザの中で組み立てが始まります。ここも流れ作業です:

1. HTMLを解析してDOMツリー※1を作る
2. CSSを解析してCSSOM※2を作る
3. 両者を合成して、実際に画面に出すものだけのレンダーツリー※3を作る
4. レイアウト — どこに・何を・どの大きさで置くかを計算する
5. ペイント — 計算どおりに描く。ここでようやくページが見える

登場人物メモ（※の説明）:

• ※1 DOMツリー — HTMLを、機械が扱える親子構造に変換したもの
• ※2 CSSOM — CSSを同じように構造化したもの
• ※3 レンダーツリー — 「実際に画面へ出るものだけ」を集めた最終形（非表示の要素は入らない）

⚠️ イレギュラー（割り込みと事故）:

• JavaScriptの割り込み — <script> は既定ではHTMLの解析を一時停止させる。JSが重いと白い画面が続くのはこのため。defer 属性や読み込み位置が表示速度に直結する
• CSSが遅れて届く — 一瞬だけ飾りのない「素のHTML」が見えることがある（FOUCと呼ばれる現象）

つまり「描画とJS実行は絡み合いながら進む」——ここを制御するのがフロントエンド性能改善の世界で、その入口がこのセクションです。開発者ツールのNetworkタブを開いてページを再読み込みすると、今日の旅の1往復1往復が、そのまま1行ずつ並んでいるのが見えます。