URLの入力からWebページ表示までの全体像

Webページを見る側のブラウザはクライアント、ページのデータを提供する側はサーバーです。この役割分担をクライアントサーバモデルといいます。ブラウザへURLを入力すると、最初にURLから通信方式を表す部分、接続先を表すドメイン名、サーバーへ要求するページの場所などが読み取られます。しかし、ブラウザはドメイン名だけを手掛かりにパケットを送るわけではありません。まずDNSで対応するIPアドレスを調べ、そのアドレスを宛先として通信を始めます。

続いて端末は、宛先が自分と同じネットワークにあるかを判断します。同じLAN内なら相手へ届くようにデータを送り、別のネットワークなら、外部への出口として設定されたデフォルトゲートウェイ、通常はルーターへ渡します。データはパケットという小さな単位に分けられ、途中のルーターが宛先IPアドレスと経路情報を見て次の転送先を選びます。目的のサーバーへ着いた後は、HTTPの要求に対する応答としてHTMLなどが返ります。ブラウザはHTMLを解析し、必要なスタイルシート、スクリプト、画像なども追加で要求して、最終的な画面を組み立てます。

この一連の処理には、役割の異なる複数のプロトコルが重なっています。IPはネットワークを越えて宛先へ運ぶための仕組み、TCPやUDPは端末上のどのアプリケーション同士でどのように届けるかを扱う仕組み、HTTPはWebで要求と応答を表現する仕組みです。HTTPSではさらにTLSによる暗号化などが加わります。「インターネットの規則が一つある」のではなく、各層の規則が自分の担当を受け持つと考えると整理できます。

DNSがドメイン名をIPアドレスへ変換する

ドメイン名とDNSの関係は、名前から通信先を調べる仕組みとして捉えます。人にとってドメイン名は覚えやすくても、IPでパケットを運ぶには対応するIPアドレスが必要です。端末やブラウザに以前の問い合わせ結果が残っていれば、そのキャッシュを利用できる場合があります。見つからなければ、端末に設定されたDNSリゾルバへ問い合わせます。リゾルバは自分のキャッシュを確認し、必要ならDNSの階層をたどって、そのドメイン名を管理する側から情報を得て端末へ返します。

DNSは巨大な一枚の名簿を一台のサーバーが持つ仕組みではありません。ドメイン名は右側から階層になっており、どのDNSサーバーが次の範囲を管理するかを委任して、分散して情報を管理します。また、一つのドメイン名が常に一つのIPアドレスだけを指すとは限りません。負荷の分散や利用場所に応じた配信のために複数の候補が返ることもあり、対応は時間とともに更新されることもあります。そのためキャッシュには、いつまで結果を利用できるかという有効期間があります。

ここでの誤解は、「DNSがWebページ本体を運ぶ」というものです。DNSが主に返すのは名前に対応するアドレスなどの情報であり、HTMLや画像はその後のWeb通信で取得します。ドメイン名が正しくIPアドレスへ変換できなければ、回線やWebサーバーが正常でも名前を使ったアクセスは先へ進みません。反対に、IPアドレスを指定した通信ができても、DNSが正常だとまでは判断できません。名前解決とページ取得を別々の段階として切り分けることが大切です。

パケットがLANからWANへルーティングされる

パケットには、運びたいデータの一部に加えて、送信元や宛先など配送に必要な制御情報が付けられます。大きなデータを小さく分けることで、一本の通信路を複数の通信が共有でき、途中の状況に応じて転送できます。パケット交換では、一つの通信が回線を最初から最後まで占有し続けるわけではありません。各パケットが同じ経路を通るとも限らず、受信側で元のデータとして扱うための役割をTCPなどが担います。

IPアドレスは、ネットワーク上の通信元と通信先を識別するために使われます。端末は自分のIPアドレスとネットワークの範囲を表す情報を基に、宛先が同じネットワークか外部かを判断します。外部ならパケットをデフォルトゲートウェイへ渡します。ルーターは宛先IPアドレスを見て経路表と照合し、次に渡す相手を決めます。この判断がルーティングです。ルーターは通常、目的地までの全経路を一度に指定するのではなく、次の一歩を選びます。その処理が途中のルーターで繰り返され、宛先側のネットワークへ近づきます。

LANとWANは、単純に有線と無線を分ける言葉ではありません。LANは家庭、施設、校内など比較的限られた範囲で管理されるネットワークで、無線LANもLANの一種です。WANは離れたLAN同士を結ぶ広域のネットワークです。端末から見ると、PCからスイッチや無線アクセスポイントを経てルーターまでが身近なLAN、その先で通信事業者などのネットワークを通り、接続先のLANへ至る部分がWAN側です。物理的には光回線や無線などが使われても、論理的な宛先を示すIPの働きとは分けて考えます。

TCPとUDPがデータの届け方を分担する

IPアドレスで端末まで届いても、その端末ではブラウザ、通話、名前解決など複数の通信が同時に動いています。TCPとUDPはポート番号を使い、どのアプリケーションの通信かを区別します。TCPは通信を始める前に相手と接続を確立し、データを順序どおりに扱い、届かなかった部分を再送するための仕組みを持ちます。Webページやファイルのように、欠けたり順序が入れ替わったりすると困るデータを確実に渡す場面で広く使われます。

UDPは、TCPのような接続確立、到着確認、順序制御を基本機能として持ちません。その分、短い要求を素早く送りたい名前解決や、多少の欠落より遅延を抑えたいリアルタイム通信などで利用されます。ただし「UDPなら必ず速い」「UDPならデータが失われる」と決めつけるのは正確ではありません。必要ならアプリケーション側の仕組みで再送や暗号化を加えられます。新しいWeb通信では、UDP上に信頼性や暗号化を組み込んだQUICを使う方式もあります。

TCPとUDPの違いは、安全か危険かではなく、どこまでを基本機能として受け持つかです。TCPにも通信内容を自動的に秘密にする機能があるわけではなく、暗号化にはTLSなどを組み合わせます。また、DNSは一般に短い問い合わせでUDPを使うことがありますが、応答の大きさや処理の都合によってTCPを使う場合もあります。「一つのサービスは必ず一つの方式」と丸暗記せず、用途と条件を確認します。

HTTPとHTTPSでWebの要求と応答を交わす

接続先との通信路が用意できると、ブラウザはHTTPの形式で要求を送ります。要求には、取得したいページの場所、操作の種類、ブラウザが扱える形式などの情報を含められます。サーバーは要求を処理し、結果を表す状態、データの種類、HTMLなどの本文を応答として返します。ブラウザは受け取ったHTMLを上から解析し、そこに別のファイルへの参照があれば追加の要求を送ります。一つのURLを開く操作でも、実際には複数回の要求と応答が発生します。

HTTPSは、HTTPをTLSで保護して送る仕組みです。通信開始時に接続先から示された証明書を検証し、これから使う暗号のための情報を安全に共有してから、HTTPの内容を暗号化してやり取りします。これにより通信経路の途中から内容を読み取られにくくし、途中で書き換えられていないかを確認し、接続しているドメイン名に対応する相手かを検証できます。パケットの宛先など配送に必要な情報がすべて見えなくなるわけではありません。

鍵の表示があればページの内容まで信頼できる、という理解には注意が必要です。HTTPSは通信経路を保護しますが、サイトに書かれた情報が正しいことや、運営者の目的が安全であることまでは保証しません。よく似た別のドメイン名で作られた偽サイトでも、その別名に対する証明書を取得してHTTPSを使えます。暗号化の有無と、URLのドメイン名が意図した相手かという確認は、別々に行います。

ネットワークレスキューで経路と設定を確かめる

ネットワークレスキューでは、PC、スイッチ、ルーター、サーバー、インターネットなどの機器を盤面へ配置し、機器を順に選んでケーブルを接続できます。機器の設定画面では名前、IPアドレス、ゲートウェイを入力できます。ステージでは、機器の接続、重複しないIPアドレス、デフォルトゲートウェイ、インターネットまでの経路といった条件を通信テストで確認します。ここでは自由接続モードを使い、条件を一つずつ変えて結果を比べます。

同じLAN内の通信を作る

  1. タイトル画面から「自由接続モードで遊ぶ」を選び、PCを二台、スイッチを一台配置します。
  2. 一台目のPCを選び、IPアドレスを192.168.1.10として保存します。二台目は192.168.1.11とします。
  3. 一台目のPC、スイッチの順に選んで接続し、二台目も同じようにスイッチへ接続します。
  4. 画面下部で送信元と宛先に二台のPCを選び、「Ping実行」を押します。次に二台目を192.168.1.10へ変えて、同じIPアドレスが重複した場合を比べます。

このツールのPing判定は、IPアドレスの形式、重複、先頭三つの数値が一致する同一ネットワーク、機器間の接続経路を確認する簡略化されたモデルです。実際のネットワークで使うサブネットマスクを自由に計算する機能ではないため、ここでは「同じLANの設定と物理的な経路が両方必要」という関係を確かめます。

ルーターを通って外へ出る

  1. 盤面をリセットし、PC、スイッチ、ルーター、インターネットを一台ずつ配置します。
  2. PCに192.168.1.10、ゲートウェイに192.168.1.1を設定し、ルーターのIPアドレスを192.168.1.1にします。
  3. PCからスイッチ、スイッチからルーター、ルーターからインターネットの順に接続します。送信元にPCを選び、「インターネット到達テスト」を実行します。
  4. PCのゲートウェイだけを192.168.1.2へ変えて再実行します。ケーブルがすべてつながっていても、指定したゲートウェイの機器が見つからなければ到達できないことを確認します。

到達テストは、PCのIPアドレスとゲートウェイ、IPアドレスの重複、ゲートウェイに一致するルーター、PCとルーターが同じネットワークにあること、PCからルーター、ルーターからインターネットまでの接続経路を順に判定します。DNS、TCP・UDP、TLS、HTTPの要求を再現する機能ではありません。したがって、この操作で確認できる範囲と、その後に必要な名前解決やWeb通信を分けて理解します。

通信失敗を近い場所から切り分ける

Webページが開かないとき、最初からDNS設定やサーバー障害だと決めつけると、単純なケーブル抜けや無線接続の問題を見落とします。反対に、無線の表示が出ているだけでインターネットまで正常とも判断できません。確認する範囲を端末から少しずつ外へ広げ、どこまで成功し、どこから失敗するかを記録します。設定を一度に複数変えると原因が分からなくなるため、一項目ずつ確認して元の状態も残します。

  1. 接続を確認する：有線なら端子やケーブル、無線なら意図したネットワークへ接続しているかを見ます。同じ端末の機内モードや通信機能の無効化も確認します。
  2. 端末の設定を確認する：IPアドレス、ネットワークの範囲、デフォルトゲートウェイ、DNSサーバーの情報が設定されているかを見ます。同じLAN内でIPアドレスが重複していないかも候補です。
  3. 同じLANを確認する：同じLAN内の別端末やルーターへ届くかを試します。ここで失敗するなら、スイッチや無線アクセスポイントまでの経路、IPアドレスの範囲、端末側の設定を疑います。
  4. ゲートウェイより先を確認する：ルーターまでは届くのに外部へ届かないなら、ルーターの外側の接続や経路に範囲を広げます。一台だけの問題か、同じLANの複数台で共通する問題かも有力な手掛かりです。
  5. DNSを分けて確認する：IPアドレスを宛先にした通信はできるのにドメイン名では失敗するなら、DNSの設定、応答、キャッシュを確認します。名前解決に成功したIPアドレスが意図したものかも見ます。
  6. Webの層を確認する：名前解決もIP通信もできるのにページだけ開かないなら、TCPやQUICの接続、TLS証明書の検証、HTTPの応答、ブラウザの表示処理へ進みます。別のWebサイトが開くかを比べると、特定サイト側か通信全体かを分けやすくなります。

Pingの失敗だけで「相手が停止している」と断定もできません。途中でPingに使う通信だけが制限されていても、Web通信は利用できる場合があります。同様にPingの成功は、相手までの一部のIP通信が往復した証拠にはなりますが、DNSやHTTPSまで成功した証拠ではありません。各テストが何を確かめ、何を確かめていないかを言葉にすると、原因候補を必要以上に広げずに済みます。

一つのWebページが表示されるまでを逆向きにたどれば、障害調査の地図になります。画面表示の前にはHTTP応答、その前には保護された通信路、その前にはTCPやQUIC、その下にはIPパケットの経路、さらに端末の近くにはLANの接続があり、通信開始前にはDNSの名前解決があります。正常時の順番を理解しておくことが、失敗した段階を見つける最も確実な手掛かりです。