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

URL を叩いてから画面が出るまでには、DNS → TCP → TLS → HTTP → レンダリングが連続して走ります。この章では dig と curl -v、Chrome DevTools を使って、各ステップを自分のコマンドで観測していきます。

URL から画面までの流れ（概念）

ブラウザに https://example.com/users?tab=home#profile と入力して Enter を押すと、次の順で処理が進みます。

URL 自体は 5 要素に分解されます。

https://www.example.com:443/users?tab=home#profile
└─┬─┘   └─────┬──────┘ └┬┘ └──┬──┘ └──┬──┘ └──┬─┘
Scheme   Host            Port  Path    Query   Fragment

Fragment（# 以降）はサーバーに送られません。クライアント内部でのページ内移動や SPA のルーティングに使われます。これはサーバーログから Fragment が拾えない理由でもあります。

DNS はホスト名を IP に変換する階層的な仕組みです。

ブラウザ → OS リゾルバ → 再帰リゾルバ → ルート → TLD(.com) → 権威 DNS → IP

TCP は 3 回のやり取り（SYN → SYN/ACK → ACK）で双方向のトンネルを開通させます。HTTPS ではその上に TLS が乗り、証明書検証と鍵交換を 1 往復で行います。最後に HTTP メッセージが流れ、サーバーは HTML を返し、ブラウザが DOM/CSSOM を作ってレンダリングします。

作るもの

dig と curl -v を使って 1 本のリクエストの各層を可視化し、さらに Chrome DevTools で Timing の内訳を見ます。

[あなたの PC] ──dig──▶ [DNS サーバー]
             ──TCP/TLS/HTTP──▶ [example.com / localhost:8787]
[ブラウザ] ──Network タブ──▶ (DNS / Connect / SSL / Waiting / Download)

準備

2 つのプロファイルを立ち上げます。netshoot は dig や traceroute が入ったネットワーク調査用コンテナ、lab-api はローカル API です。

cd exercises
docker compose --profile netshoot up -d
docker compose --profile lab-api up -d --build
docker compose ps

lab-api と netshoot の両方が起動していれば準備完了です。

手順

1. DNS 解決を見る（dig）

ホスト名から IP アドレスへの変換は dig で観測できます。macOS / Linux ではそのまま、Windows の場合は netshoot コンテナ経由で実行します。

dig example.com

ANSWER SECTION に example.com. ... A 93.184.216.34（日によって変わります）のように IP が並びます。もし dig が無ければ、netshoot の中から実行してください。

docker compose exec netshoot dig example.com

ポイント: 同じコマンドを 2 回実行すると 2 回目は早く返ります。これは OS やリゾルバがキャッシュしているためです。

2. TCP + TLS + HTTP をまとめて見る（curl -v）

-v は verbose モード。接続確立からヘッダー送受信まで全部出ます。

curl -v https://example.com 2>&1 | head -30

読み解くポイントは 4 つです。

• * Connected to example.com (93.184.216.34) port 443 ← TCP 接続完了
• * TLSv1.3 (OUT), TLS handshake, Client hello 以降 ← TLS ハンドシェイク
• * Server certificate: に発行者・有効期限 ← 証明書検証
• > GET / HTTP/2 ← HTTP リクエスト送信
• < HTTP/2 200 ← サーバーからの応答ステータス

つまり 1 本の curl -v で DNS → TCP → TLS → HTTP がすべて順に走っていることが確認できます。

3. Chrome DevTools で Timing を見る

curl では見えにくい「どの段階で何ミリ秒かかったか」はブラウザの DevTools が最も分かりやすいです。

1. Chrome で http://localhost:8787/ok を開く
2. F12（macOS は Cmd+Option+I）で DevTools を開き Network タブへ
3. ページをリロード（Cmd+R / Ctrl+R）
4. ok 行をクリック → Timing タブを開く

次の内訳が見えるはずです。

http://localhost:8787/slow?ms=2000 を開き直すと Waiting (TTFB) に 2 秒 が乗るのを確認できます。サーバー処理が遅いのかネットワークが遅いのかを切り分ける基本スキルです。

4. ローカルと公開サイトでヘッダーを比べる

curl -I http://localhost:8787/ok
curl -I https://example.com

ローカル API は Content-Type: application/json、example.com は Content-Type: text/html; charset=UTF-8 を返します。同じ HTTP という仕組みで、ローカルの小さなサーバーも世界中からアクセスされる example.com も動いている ことが実感できます。

5. （オプション）経路を覗く（traceroute）

netshoot 内から traceroute を実行すると、自分の PC から example.com までのネットワーク経路が見えます。

docker compose exec netshoot traceroute example.com

途中のルーターがどこにあるか・どこで遅くなっているかの推測に使います。時間がかかる場合は Ctrl+C で止めて構いません。

手を動かす

やること

1. netshoot と lab-api を両方起動する
2. dig example.com で IP を確認し、同じコマンドを 2 回実行してキャッシュの効果を観察する
3. curl -v https://example.com 2>&1 | head -30 で DNS → TCP → TLS → HTTP の痕跡を読む
4. Chrome DevTools の Network タブで http://localhost:8787/ok と /slow?ms=2000 の Timing を比較する

成功条件

bash exercises/scripts/verify-b00-2.sh

• dig example.com が ANSWER SECTION に A レコードを返す（または netshoot 経由で返る）
• curl -s -o /dev/null -w '%{http_code}\n' https://example.com が 200 を返す
• curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8787/ok が 200 を返す
• verify-b00-2.sh が All b00-2 checks passed で終了する

片付け

docker compose down

確認クイズ

この章で手を動かすときの確認

この章は 導入編 の STEP 2にある 「手を動かす」 の章です。本文を読み終えたあと、次の観点だけ確認すると次へ進みやすくなります。

この章で確認すること:

• URL 入力から画面表示までの流れを追える
• DNS / TCP / TLS / HTTP / レンダリングの役割を説明できる
• dig と curl -v でネットワーク各層の様子を観測できる

次に活きる章:

• ネットワーク基礎（TCP/IP・DNS・HTTPS）
• Git基礎

補助参照:

• カリキュラム全体の完成条件（checklist.yml）
• 参照実装の README