URL を入力してからページが表示されるまでの全過程

ブラウザのアドレスバーに URL を入力して Enter を押す。ページが表示されるまでの時間は、高速な回線なら 1 秒未満。しかし、この 1 秒未満の間に、あなたのブラウザは驚くほど多くの処理を実行しています。

この記事では、https://example.com と入力してからページが表示されるまでの全過程を、ネットワークの各レイヤーを横断しながら解説します。IP 確認さんにアクセスするときも、まったく同じプロセスが裏側で動いています。

ステップ 1: URL の解析

ブラウザはまず、入力された文字列を解析します。

  • プロトコル: https:// → HTTPS (ポート 443) を使用
  • ドメイン名: example.com → DNS で IP アドレスに変換が必要
  • パス: / (省略時はルート) → サーバーに要求するリソース

入力が URL ではなく検索クエリだと判断された場合は、デフォルトの検索エンジンにリダイレクトされます。

ステップ 2: DNS 解決 - ドメイン名を IP アドレスに変換

ブラウザは example.com の IP アドレスを知る必要があります。DNS 解決は以下の順序で試みられます。

  1. ブラウザキャッシュ: 最近アクセスしたドメインの IP アドレスをブラウザが記憶している
  2. OS キャッシュ: ブラウザにない場合、OS の DNS キャッシュを確認
  3. hosts ファイル: /etc/hosts (Unix) や C:\Windows\System32\drivers\etc\hosts (Windows) を確認
  4. DNS リゾルバ: 上記すべてにない場合、設定された DNS サーバー (ISP のデフォルト、または Cloudflare 1.1.1.1 など) に問い合わせる

DNS リゾルバは、ルートサーバー → .com の TLD サーバー → example.com の権威サーバーと、階層的に問い合わせを行い、最終的に IP アドレス (例: 93.184.216.34) を取得します。この過程は通常 10〜100 ms 程度です。DNS の脆弱性を理解していれば、この段階のリスクも把握できます。

ステップ 3: TCP 接続の確立 - 三者間ハンドシェイク

IP アドレスが判明したら、ブラウザはサーバーのポート 443 に TCP 接続を確立します。TCP の三者間ハンドシェイク (3-way handshake) が行われます。

  1. SYN: クライアント → サーバー「接続したい」
  2. SYN-ACK: サーバー → クライアント「了解、こちらも準備 OK」
  3. ACK: クライアント → サーバー「確認した、通信開始」

この 3 往復で 1 RTT (Round Trip Time) を消費します。東京からロサンゼルスのサーバーなら約 100 ms。traceroute で確認できる遅延が、ここで直接影響します。

ステップ 4: TLS ハンドシェイク - 暗号化通信の確立

HTTPS の場合、TCP 接続の上に TLS の暗号化レイヤーを構築します。TLS 1.3 では以下の処理が行われます。

  1. ClientHello: クライアントがサポートする暗号スイート、TLS バージョン、ランダム値を送信
  2. ServerHello: サーバーが暗号スイートを選択し、TLS 証明書を送信
  3. 証明書の検証: ブラウザが証明書の有効性 (発行元 CA の信頼性、有効期限、ドメイン名の一致) を検証
  4. 鍵交換: Diffie-Hellman 鍵交換で共通の暗号鍵を生成

TLS 1.3 では、ハンドシェイクが 1 RTT で完了するよう最適化されています (TLS 1.2 では 2 RTT 必要だった)。さらに、以前接続したサーバーへの再接続では 0-RTT (ゼロラウンドトリップ) が可能です。

ステップ 5: HTTP リクエストの送信

暗号化された接続が確立されたら、ブラウザは HTTP リクエストを送信します。

GET / HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Language: ja,en
Accept-Encoding: gzip, br

このリクエストには、ブラウザの種類、受け入れ可能なコンテンツ形式、言語設定、Cookie などの情報が含まれます。サーバー側ではこれらの情報をもとにユーザーを識別しますが、近年はディープフェイク検出技術のように、デジタルコンテンツの真正性を検証する仕組みも重要性を増しています。

ステップ 6: サーバーの処理とレスポンス

サーバーはリクエストを受け取り、HTML を生成して返します。静的サイトならファイルをそのまま返し、動的サイトならアプリケーションサーバーがデータベースに問い合わせて HTML を生成します。

レスポンスにはHTTP ステータスコード (200 OK、301 リダイレクト、404 Not Found など) と、セキュリティヘッダーが含まれます。

ステップ 7: レンダリング - HTML からピクセルへ

ブラウザが HTML を受け取ってからページが表示されるまでにも、複数の処理が行われます。

  1. HTML パース: HTML を DOM (Document Object Model) ツリーに変換
  2. CSS パース: CSS を CSSOM (CSS Object Model) に変換
  3. レンダーツリー構築: DOM と CSSOM を組み合わせて、画面に表示する要素のツリーを構築
  4. レイアウト: 各要素の位置とサイズを計算
  5. ペイント: 各要素をピクセルに変換して画面に描画

この過程で、追加のリソース (CSS、JavaScript、画像、フォント) が必要になれば、それぞれに対して DNS 解決 → TCP 接続 → TLS ハンドシェイク → HTTP リクエストのサイクルが繰り返されます (HTTP/2 では同一ドメインへの接続を多重化できるため、効率化されています)。

まとめ - 1 秒未満に詰まった技術の集大成

URL を入力してからページが表示されるまでの過程は、DNS、TCP、TLS、HTTP、HTML/CSS のレンダリングという、インターネットの主要技術のほぼすべてを横断します。この記事で紹介した各ステップは、それぞれが独立した技術領域であり、それぞれに深い歴史と設計思想があります。

IP 確認さんにアクセスするとき、ブラウザの開発者ツール (F12) の「ネットワーク」タブを開いてみてください。DNS 解決、TCP 接続、TLS ハンドシェイク、HTTP リクエストの各段階にかかった時間が可視化されます。

Web の仕組みを体系的に学びたい方には、Web 技術の入門書が参考になります。

この記事の関連用語

DNS ステップ 2 でドメイン名を IP アドレスに変換するシステム。 HTTPS ステップ 4 の TLS ハンドシェイクで確立される暗号化通信。 IP アドレス DNS 解決の結果として得られる、サーバーの数値アドレス。 TLS ステップ 4 で暗号化通信を確立するプロトコル。TLS 1.3 では 1 RTT で完了。 HTTP ステップ 5 でブラウザがサーバーにリソースを要求するプロトコル。