📄
概念 📚 beginner-stepup

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

ブラウザに URL を入力してから画面にページが描画されるまでの全段階（URL 解析・DNS・TCP・TLS・HTTP・レンダリング）を順を追って理解する

  • この章で学ぶこと：ブラウザに https://example.com と入力して Enter を押してから画面に内容が出るまでに、何が・どの順で・どこで起きているかを説明できる状態になる。
  • なぜ学ぶのか：この 1 本の流れが分かれば、ネットワーク・フロントエンド・バックエンド・インフラのどこに問題があるかを切り分けられる。実務での障害対応・パフォーマンス改善の土台となる。
  • Web 開発のどの領域か：横断的な基礎知識。フロント・バック・インフラすべてに関わる。

前提: b00-1-what-is-web を読んで「Web とは何か」の全体像を把握していること。

所要時間: 45 分（読解 30 分＋確認クイズ 15 分）

到達目標: 「なぜ Chrome DevTools の Network タブにはこれが映るのか」を自分の言葉で説明でき、段階ごとのボトルネックを見分けられる状態。

全体像：10 段階の旅

URL を入力してから画面に内容が表示されるまでには、大きく次の 10 段階がある。

URL 入力から画面表示までの 10 段階

この章では 1〜10 を順に追いかける。各段階でどんなエラーが出るかも併記するので、Chrome DevTools を開きながら読むと理解が深まる。

1. URL の入力と解析

ブラウザはアドレスバーに入力された文字列を以下の 5 要素に分解する。

https://www.example.com:443/users?tab=home#profile
└─┬─┘   └─────┬──────┘ └┬┘ └──┬──┘ └──┬──┘ └──┬─┘
Scheme   Host            Port  Path    Query   Fragment
  • Scheme: 通信方式（https または http）。https は TLS で暗号化される。
  • Host: サーバーの名前。www.example.com のようなホスト名か、192.0.2.1 のような IP アドレス。
  • Port: 接続先の論理的な窓口番号。HTTPS は省略時 443、HTTP は 80。
  • Path: サーバー内のリソース位置。
  • Query: ?key=value&... 形式の追加パラメーター。
  • Fragment: # 以降。サーバーには送られず、ブラウザ内でページ内移動やクライアントサイドルーティングに使われる。

入力文字列が URL として妥当かどうか、ブラウザはこの段階で判定する（スキーム省略時は検索エンジンに回すなどの処理もここ）。

2. HSTS とブラウザキャッシュの確認

ネットワークに出る前に、ブラウザは内部の辞書を引く。

  • HSTS（HTTP Strict Transport Security）: 過去に Strict-Transport-Security ヘッダーを受け取ったサイトは、HTTP で書いても自動で HTTPS に昇格する。ここで書き換えが起きる。
  • Service Worker / キャッシュ: オフラインで動くよう登録された Service Worker がある場合、そこで応答を返してネットワークに出ないこともある。通常のキャッシュ（Disk Cache / Memory Cache）も有効期限内ならそのまま使われる。

DevTools の Network タブで (disk cache) (memory cache) (ServiceWorker) と表示されるのはこの段階の結果。

3. DNS：名前から IP への変換

ホスト名（www.example.com）のままではネットワークに出られない。IP アドレス（93.184.216.34 や 2606:2800:220:1::...）に変換する必要がある。この名前解決を担うのが DNS（Domain Name System）。

解決は階層的に進む（キャッシュがなければの話）。

ブラウザ → OS リゾルバ → ISP の DNS サーバー（再帰リゾルバ）
                         → ルートサーバー         （「.com を聞け」）
                         → .com TLD サーバー      （「example.com を聞け」）
                         → example.com の権威サーバー（最終的な IP を返す）

実際はキャッシュが各段階に効いており、多くの場合 1〜2 ホップで終わる。

起こりうるエラー: DNS_PROBE_FINISHED_NXDOMAIN（ホスト名が存在しない）、DNS_PROBE_FINISHED_NO_INTERNET（DNS サーバーに到達できない）。

4. TCP 3-way ハンドシェイク

IP アドレスとポートが分かったら、TCP（Transmission Control Protocol） で信頼性のある接続を確立する。3 回のやり取りで「お互い通信できる」ことを確認する。

クライアント ─── SYN ──────▶ サーバー   （「つなぎたい」）
クライアント ◀── SYN/ACK ──── サーバー   （「了解、こっちもつなぎたい」）
クライアント ─── ACK ──────▶ サーバー   （「じゃあ始めよう」）

この時点で双方向のトンネルが開通する。HTTP/3（QUIC）の場合は TCP を使わず UDP 上に独自のハンドシェイクを行うが、「信頼性ある接続を確立する」という役割は同じ。

5. TLS ハンドシェイク（HTTPS の場合）

HTTPS では TCP 接続の上に TLS（Transport Layer Security） の暗号層を張る。現行主流は TLS 1.3 で、1 往復（1-RTT）で次のことを一気に決める。

  • 使う暗号スイート（例：TLS_AES_128_GCM_SHA256）
  • サーバー証明書の検証（認証局の署名チェーン・有効期限・ドメイン一致）
  • セッション鍵の共有（楕円曲線 Diffie-Hellman などで）

証明書が期限切れや不一致だと NET::ERR_CERT_DATE_INVALID や NET::ERR_CERT_COMMON_NAME_INVALID が出る。開発中に自己署名証明書を使うと警告が出るのはこのチェックが働いているため。

6. HTTP リクエスト送信

ここで初めて HTTP のメッセージが流れる。内容は b06-http-rest で詳しく扱うが、骨格はこうなる。

GET /users?tab=home HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,...
Cookie: session=abc123

HTTP/2・HTTP/3 ではテキストではなくバイナリフレームに変わるが、「メソッド・パス・ヘッダー・ボディ」の構造は変わらない。

7. サーバーが処理してレスポンス生成

リクエストを受けたサーバーでは、概ね次の流れで応答が組み立てられる。

  1. リバースプロキシ（Nginx・CloudFront・ALB）が受信
  2. アプリケーションサーバー（Hono・Rails・Django 等）が起動中のコードで処理
  3. 認証・入力バリデーション・ビジネスロジック
  4. データベースへの SQL クエリ
  5. テンプレート描画 or JSON シリアライズ
  6. HTTP レスポンスとして返送

本カリキュラムの構成では、2 が Hono（Node.js）、4 が PostgreSQL、1 が AWS ALB + CloudFront になる（b17-hosting で詳解）。

8. HTTP レスポンス受信

サーバーから返るメッセージの骨格は以下。

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 3421
Cache-Control: max-age=300
Set-Cookie: session=xyz; HttpOnly; Secure

<!DOCTYPE html>
<html>...</html>

ステータスコードとヘッダーはブラウザの次の振る舞い（キャッシュ・Cookie 保存・リダイレクト追従）を決める重要な指示書となる。

9. HTML パースとサブリソース取得

ブラウザは受け取った HTML を先頭から順に解析し、DOM ツリーを構築する。途中で <link> <script> <img> などが現れると、追加のリクエストを並行で送る。

  • <link rel="stylesheet"> → CSS を取得（レンダリングブロック：取得完了まで描画されない）
  • <script> → JavaScript を取得・実行（デフォルトではこれもブロック。defer・async 属性で制御可能）
  • <img>・<video> → 非同期に取得（画面の描画をブロックしない）

CSS から CSSOM（CSS Object Model） が作られ、DOM と組み合わせてレンダーツリーが生成される。

10. レンダリング：Layout → Paint → Composite

レンダーツリーができたら、画面に絵を出す工程に入る。

  1. Layout（Reflow）: 各要素の大きさと位置を計算する。幅・高さ・マージンなどがこの段階で決まる。
  2. Paint: 文字・色・影・画像を個別のレイヤーに塗る。
  3. Composite: レイヤーを重ね合わせ、GPU に送って最終的なピクセルを画面へ出す。

この 3 段階はどれか 1 つが遅いだけで体感速度が下がるため、パフォーマンスチューニングではどの段階にボトルネックがあるかを見極めることが重要。Chrome DevTools の Performance タブで各段階の時間を可視化できる。

First Contentful Paint と Time to Interactive

ユーザー体験の指標として次の 2 つがよく使われる。

指標意味影響する段階
FCP（First Contentful Paint）最初の文字／画像が画面に出た瞬間1〜10 全体、特に 3・4・9
TTI（Time to Interactive）ユーザー操作に反応できる状態になった瞬間JavaScript の実行完了（9・10）

Google の Core Web Vitals（LCP・INP・CLS）もこの 10 段階のどこに対応するかを押さえると、改善ポイントを特定しやすくなる。

【セキュリティ】コラム：各段階で狙われる攻撃

10 段階のそれぞれに脅威と防御がある。すべてを覚える必要はないが、「どこに穴が開きうるか」をざっと持っておくと設計時に抜けが減る。

段階脅威防御策
3. DNSDNS スプーフィング（偽の IP を返す）DNSSEC・DoH／DoT の採用
4. TCPパケット盗聴・SYN フラッドTLS 化で盗聴を無効化、クラウドの DDoS 対策
5. TLS中間者攻撃・証明書なりすましHSTS を有効化し、HTTP での接続を禁止する
6. HTTPCookie 盗聴・CSRFSecure HttpOnly SameSite 属性の徹底
9. HTMLXSS（悪意スクリプトの注入）入力サニタイズ、Content-Security-Policy ヘッダー
10. RenderクリックジャッキングX-Frame-Options / frame-ancestors CSP

個別の対策は b07（認証）、b08（HTML/CSS）、b13（API）、b18（環境変数）で順に扱う。

【アーキテクチャ】コラム：CDN とエッジキャッシュが挟まると何が変わるか

上記の 10 段階は「クライアントが直接オリジンサーバーに届く」前提で書いたが、実務では間に CDN（Content Delivery Network） が挟まる。本カリキュラムの構成では CloudFront が該当する。

  • DNS（段階 3） の応答は、ユーザーに地理的に近いエッジサーバーの IP になる。
  • TCP・TLS（段階 4・5） はエッジとの間で完結するため、往復時間が短くて済む。
  • HTTP（段階 6〜8） はエッジにキャッシュがあれば即応答、なければオリジンへ転送する。

結果として FCP と LCP が大幅に短縮 され、オリジンサーバーの負荷も下がる。この仕組みは b17-hosting で具体的な設定まで扱う。

よくある詰まりポイント

  • DevTools の Network タブで「TTFB（Time to First Byte）が遅い」と見えても、どの段階が遅いのかまでは 1 行では判別できない。Timing タブを開いて DNS・Connect・SSL・Waiting の内訳を見る。
  • Fragment（# 以降）はサーバーに送られないため、サーバー側のログに出ない。クライアントルーティングでページ遷移がログに残らないのはこのため。
  • 「GET なのに副作用がある API」を作ってしまうと、ブラウザや CDN が勝手に再送・キャッシュして予期しない動作を招く。CRUD の意味とメソッドの対応は b06 で厳格に扱う。
  • HTTPS 開発時に自己署名証明書を使うと段階 5 で警告が出る。開発では mkcert などでローカル CA を信頼させると解消できる。

参考リソース

確認クイズ

Q1. URL のうち、ブラウザ内だけで処理されサーバーには送られない部分はどれか。　A. Query　B. Path　C. Fragment　D. Port

正解: C. Fragment

解説: # 以降の Fragment はブラウザ内でページ内移動やクライアントサイドルーティングに使われる。HTTP リクエストのパスとしては送信されないため、サーバーログにも残らない。

Q2. HSTS の役割を説明せよ。

正解: 過去に HTTPS でアクセスしたドメインを記録し、HTTP での接続要求を自動で HTTPS に昇格させる仕組み。

解説: HSTS は中間者攻撃（最初の HTTP 接続を乗っ取って偽サイトに誘導する）を防ぐためにある。サーバーが Strict-Transport-Security ヘッダーを返すと、ブラウザは指定期間このドメインに対して HTTP を使わなくなる。

Q3. DNS 解決の階層で、最初に IP アドレスを返す権威サーバーは誰か。　A. ルートサーバー　B. TLD サーバー（.com など）　C. ドメインの権威 DNS サーバー　D. ISP の再帰リゾルバ

正解: C. ドメインの権威 DNS サーバー

解説: ルートサーバーは「.com を聞け」と指示し、TLD サーバーは「example.com を聞け」と指示する。実際の IP アドレスを持つのは example.com の権威 DNS サーバー。多くの場合はキャッシュで途中省略される。

Q4. TCP 3-way ハンドシェイクの 3 つのメッセージを順に答えよ。

正解: SYN → SYN/ACK → ACK

解説: クライアントが SYN を送り、サーバーが SYN/ACK で応え、クライアントが ACK を返す 3 回のやり取りで双方向の通信路が確立される。HTTP/3（QUIC）は TCP を使わずに同等の確立を行う。

Q5. TLS ハンドシェイクで検証されるものはどれか。　A. ユーザーのパスワード　B. サーバー証明書（認証局の署名・有効期限・ドメイン一致）　C. クライアントの IP アドレス　D. Cookie の内容

正解: B. サーバー証明書

解説: TLS ハンドシェイクではサーバーの身元確認と暗号鍵の共有が行われる。証明書の有効期限切れやドメイン不一致があるとブラウザは警告を出して通信を拒否する。クライアント認証は別途 mTLS として実装できる。

Q6. HTML パース中に が見つかったとき、ブラウザの挙動として正しいものはどれか。

正解: CSS を取得するまでレンダリングをブロックする（レンダリングブロッキングリソース）。

解説: CSS がない状態で描画するとスタイル崩れが一瞬見える（FOUC）ため、ブラウザは CSS を待ってから描画する。これが重い CSS ファイルが FCP を遅くする理由。media 属性やクリティカル CSS インライン化で軽減できる。

Q7. レンダリングの 3 段階「Layout → Paint → Composite」のそれぞれで何が行われるか。

正解: Layout で各要素の大きさと位置を計算し、Paint で色・文字・影を個別レイヤーに塗り、Composite でレイヤーを重ねて GPU で画面に出す。

解説: CSS の transform や opacity は Composite だけで完結するためパフォーマンスが良く、width や top の変更は Layout からやり直しになるため重い。この違いがアニメーション実装で問題になる。

Q8. CDN（例：CloudFront）が挟まることでユーザー体験が向上する主な理由を説明せよ。

正解: ユーザーに地理的に近いエッジサーバーと TCP・TLS 接続できるため往復時間が短くなり、静的リソースがエッジキャッシュにあればオリジンへの往復が不要になるため。

解説: FCP と LCP が短縮される最大の理由がこれ。ネットワークの物理距離は光速で決まるため縮められないが、距離そのものを短くすることで回避できる。本カリキュラムでは b17 で CloudFront の具体的な設定を扱う。

Q9. DevTools の Network タブで「TTFB が遅い」と表示されている場合、考えられる原因はどれか。　A. HTML が大きい　B. サーバー側処理 or DNS/TCP/TLS のいずれかが遅い　C. CSS のレンダリングが遅い　D. JavaScript の実行が遅い

正解: B. サーバー側処理 or DNS/TCP/TLS のいずれかが遅い

解説: TTFB（Time to First Byte）は「リクエストを送ってから最初の 1 バイトが返るまで」の時間。HTML のサイズや CSS・JS の重さは TTFB には影響せず、後段で効いてくる。Timing タブで内訳を見ることで原因を特定できる。

Q10. 「GET リクエストで副作用のある処理（DB 書き込みなど）を実装してはいけない」と言われる技術的な理由を説明せよ。

正解: ブラウザや CDN は GET を冪等と見なしてプリフェッチ・リトライ・キャッシュを自動的に行うため、意図せず複数回実行されて副作用が重複発生する恐れがあるため。

解説: HTTP の仕様上、GET は安全（副作用なし）かつ冪等（同じ結果）であることを前提に各種の最適化が働く。更新系の操作は POST／PATCH／PUT／DELETE を使う。この対応は b06（HTTP）で厳格に扱う。

生きているコード

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

  • 対応 Week: W2
  • 参照ブランチ:
  • W2: reference/week-2
  • 対応 checklist 項目: （直接対応なし）

ブランチの作り方・見方は b00-curriculum-map を参照してください。

📚 beginner-stepup 全 53 章
導入編 13 章 ● この編を閲覧中
  1. 1. 📄Web とは何か
  2. 2. 📄URL を打ってから画面が表示されるまで
  3. 3. 📄ネットワーク基礎（TCP/IP・DNS・HTTPS）
  4. 4. 📄【発展】物理層から通信が成立するまで（電力・Ethernet・Wi-Fi・Bluetooth）
  5. 5. 📄WSL2・Docker セットアップ詳細（Windows 向け）
  6. 6. 📄環境構築の段階的導入（macOS / Windows）
  7. 7. 📄カリキュラム全体マップ（Week × 教材 × 参照ブランチ × 要求チェックリスト）
  8. 8. 📄このカリキュラムの使い方（SQL・Python・Dify経験者向け）
  9. 9. 📄シェル・ターミナル基礎
  10. 10. 📄Windows で完全にゼロから始める開発環境構築（Week 1）
  11. 11. 📄Git基礎
  12. 12. 📄GitHubワークフロー
  13. 13. 📄パッケージ管理（pnpm workspace）
応用編 16 章
  1. 1. 📄AWSインフラ基礎
  2. 2. 📄AWS Budget Alert の設定（Month 5 Week 17）
  3. 3. 📄環境変数管理
  4. 4. 📄Bastion EC2 と SSH ProxyJump（Month 5 Week 18）
  5. 5. 📄CI/CD基礎
  6. 6. 📄ECR への Docker イメージ push と App EC2 デプロイ（Month 5 Week 19）
  7. 7. 📄テスト設計の基本
  8. 8. 📄CloudFront + S3 + ALB で公開する（Month 5 Week 20）
  9. 9. 📄CLAUDE.md・プロジェクト設定
  10. 10. 📄PR レビュー 5 観点ルーブリック（全 Week 共通）
  11. 11. 📄タスク分解・仕様の書き方
  12. 12. 📄Playwright で E2E テスト（Month 6 Week 22）
  13. 13. 📄生成コードのレビュー・デバッグの勘所
  14. 14. 📄Trivy で脆弱性スキャン（Month 6 Week 23）
  15. 15. 📄CloudWatch Logs の読み方と運用（Month 6 Week 23）
  16. 16. 📄PDF ポートフォリオの自動生成（Month 6 Week 24）