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

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 アドレス (例: 192.0.2.1) を取得します。この過程は通常、数十 ms から数百 ms 程度かかります。DNS の脆弱性を理解していれば、この段階のリスクも把握できます。

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

IP アドレスが判明したら、ブラウザはサーバーのポート 443 に TCP 接続を確立します。TCP の 3 ウェイハンドシェイク (3-way handshake) が行われます。参加するのはクライアントとサーバーの 2 者で、「3」は往復する回数ではなく、やり取りされるパケットの数を指します。

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 リクエストを送信します。

このリクエストには、ブラウザの種類、受け入れ可能なコンテンツ形式、言語設定、Cookie などの情報が含まれます。上の例は読みやすさのため HTTP/1.1 の書式で示していますが、HTTP/2 以降では同じ情報がバイナリのフレームとヘッダー圧縮で送られるため、回線を流れるバイト列はこの見た目とは異なります (ホスト名も Host ヘッダーではなく :authority という擬似ヘッダーで運ばれます)。

ステップ 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 リクエストの各段階にかかった時間が可視化されます。

よくある質問

URL を入力してからページが表示されるまでに何が起きていますか？

URL 解析 → DNS 解決 → TCP 接続 → TLS ハンドシェイク → HTTP リクエスト → サーバー処理 → HTML レンダリングの 7 ステップが実行されます。高速回線なら 1 秒未満で完了します。

ページ表示までの時間は、どのステップが支配的ですか？

何もキャッシュされていない初回アクセスでは、DNS 解決・TCP 接続・TLS ハンドシェイクの往復が積み上がる部分が支配的です。DNS がキャッシュ済みなら 1 ms 未満で終わり、残るのは物理距離に比例する RTT (東京〜ロサンゼルスで約 100 ms) になります。

TLS 1.3 は TLS 1.2 より速いのですか？

はい。TLS 1.3 ではハンドシェイクが 1 RTT で完了します (TLS 1.2 は 2 RTT)。以前接続したサーバーへの再接続では 0-RTT も可能です。