最初に結論：Web表示までの全体像

一般的なHTTPSのWebサイトへ初めてアクセスするとき、通信は大まかに次の4段階で進みます。

今回の通信条件

実際のWebアクセスは、利用する回線、OS、ブラウザ、キャッシュ、Webサーバーの構成によって変わります。 この記事では流れを理解しやすくするため、次の条件を想定します。

Webサイトが表示されるまでの11ステップ

1. ブラウザへURLを入力する 利用者がブラウザへhttps://www.example.com/と入力します。 ブラウザはURLから、通信方式、接続先の名前、要求する場所を読み取ります。
   URLから分かる主な情報
   https：HTTPSを利用する
   www.example.com：接続先のドメイン名
   /：サーバーへ要求するパス
2. ブラウザやOSがキャッシュを確認する ブラウザやOSは、以前に調べたIPアドレスや取得済みのWebデータが残っていないか確認します。 有効なキャッシュがあれば、DNS問い合わせや一部のデータ取得を省略できることがあります。
   キャッシュは通信量と待ち時間を減らしますが、この記事では全体の仕組みを理解するため、 必要な情報が残っていない状態として次へ進みます。
3. DNSでドメイン名をIPアドレスへ変換する コンピューターはwww.example.comという名前だけでは、IPパケットの宛先を決められません。 そこでDNSサーバーへ問い合わせ、Webサーバーへ到達するためのIPアドレスを取得します。
   例：www.example.com → 203.0.113.50
   DNSは、人が扱いやすい名前と、通信で使うIPアドレスを対応付ける仕組みです。
4. 宛先が同じネットワークか判定する パソコンは、自分のIPアドレスとサブネットマスクを使い、WebサーバーのIPアドレスが同じネットワークにあるか確認します。 今回のWebサーバーはインターネット上にあるため、別のネットワークだと判定されます。
   別ネットワーク宛ての通信は、Webサーバーへ直接送るのではなく、 まずデフォルトゲートウェイであるルーターへ渡します。
5. ARPでデフォルトゲートウェイのMACアドレスを調べる Ethernetでフレームを送るには、同じLAN内で次に渡す相手のMACアドレスが必要です。 ARPテーブルに情報がなければ、パソコンはARP Requestをブロードキャストし、ルーターのMACアドレスを確認します。
   ここで調べるのはWebサーバーのMACアドレスではありません。
   Webサーバーは別ネットワークにいるため、パソコンが必要とするのは 「最初の中継先」であるデフォルトゲートウェイのMACアドレスです。
6. Ethernetフレームを作り、ルーターへ送る パソコンは、Webサーバー宛てのIPパケットをEthernetフレームに入れて送信します。 このときIPアドレスは最終的な通信相手を示し、MACアドレスは同じLAN内で次に渡す相手を示します。
   送信元IP：パソコンのIPアドレス
   宛先IP：WebサーバーのIPアドレス
   送信元MAC：パソコンのMACアドレス
   宛先MAC：デフォルトゲートウェイのMACアドレス
7. ルーターが経路を選び、インターネットへ中継する ルーターは受け取ったフレームからIPパケットを取り出し、宛先IPアドレスとルーティングテーブルを確認します。 その後、次の回線で使う新しいフレームへ入れ直し、次のルーターへ転送します。
   家庭用ルーターでは、プライベートIPアドレスをインターネット側で使うグローバルIPアドレスへ変換する NAT・NAPTも行われるのが一般的です。
8. TCPの3ウェイハンドシェイクで接続を確立する WebサーバーへIPパケットを届けられる状態になったら、HTTPS通信に使用するTCP接続を準備します。 クライアントとサーバーはSYN、SYN/ACK、ACKを交換し、双方向に通信できることを確認します。
   HTTPSでは通常、Webサーバー側の宛先ポート番号として443を使用します。 クライアント側は通信ごとに選ばれる一時的なポート番号を使用します。
9. TLSでサーバーを確認し、暗号化を準備する TCP接続が確立したあと、HTTPSではTLSハンドシェイクを行います。 ブラウザはサーバー証明書などを確認し、通信を暗号化するための情報を合意します。
   TLSの主な目的は、通信内容の暗号化、通信相手の確認、データ改ざんの検知です。 URLがhttp://であれば、通常はこのTLS処理を行いません。
10. HTTPリクエストを送信し、サーバーが応答する 安全な通信路が準備できると、ブラウザはWebサーバーへHTTPリクエストを送ります。 サーバーは要求内容を処理し、ステータスコード、ヘッダー、HTMLなどをHTTPレスポンスとして返します。
    要求の例：GET / HTTP/1.1
    応答の例：200 OKとHTMLデータ
    実際にはHTTP/2など別の形式が使われる場合もありますが、役割は同じです。
11. ブラウザがHTMLを解析し、画面を描画する ブラウザは受け取ったHTMLを読み取り、画面の構造を作ります。 HTMLからCSS、JavaScript、画像、フォントなどの追加ファイルが指定されていれば、それらも取得します。 必要なデータを組み合わせ、文字、画像、ボタン、レイアウトとして画面へ表示します。
    つまり、最初のHTMLを受け取った時点で通信が完全に終わるとは限りません。 1ページを表示するために、多数の追加通信が発生することがあります。

データは各階層で包まれて送られる

ブラウザが作ったHTTPデータは、そのままLANケーブルやWi-Fiへ流れるわけではありません。 TCP/IPモデルの各層が、通信に必要な情報を付け加えます。この処理をカプセル化と呼びます。

受信側では逆の処理を行います。Webサーバーのネットワークインターフェース層から順番に情報を外し、 最終的にWebサーバーのアプリケーションへHTTPリクエストを渡します。この処理を非カプセル化と呼びます。

通信中に変わる情報・変わりにくい情報

Webサーバーまで複数のルーターを通るとき、すべての情報が最初から最後まで同じではありません。 特にMACアドレスとIPアドレスの違いを理解することが重要です。

HTML受信後も通信は続く

WebサーバーからHTMLを1つ受け取っただけでは、ページの表示に必要なすべてのデータがそろわないことがあります。 HTMLには、別のファイルを読み込む指示が含まれているからです。

ブラウザは受け取ったHTMLから画面構造を作り、CSSから見た目を決め、JavaScriptを実行し、画像などを配置します。 この一連の処理を経て、利用者が見られるWebページになります。

HTTP/3ではTCPを使わない場合がある

ここまで、HTTPS通信を「TCP接続 → TLS → HTTP」の順で説明しました。 これはHTTP/1.1やHTTP/2で一般的な考え方です。

一方、WebサイトとブラウザがHTTP/3へ対応している場合、TCPではなく UDP上で動作するQUICという仕組みが使われます。 QUICは、接続管理、信頼性、暗号化などをまとめて実現します。

Webサイトが表示されないときは、どこで止まっているか

Webアクセスの流れが分かると、「Webサイトが表示されない」という現象を段階ごとに分解できます。 原因を最初から1つに決めつけず、どの処理まで成功しているかを確認することが重要です。

現場では流れを逆向きに確認することもある

障害調査では、利用者の症状から確認範囲を絞ります。 たとえば「IPアドレスを直接入力すると開けるが、ドメイン名では開けない」なら、DNSを優先して確認できます。

• 他のWebサイトは開けるか
• ドメイン名をIPアドレスへ変換できるか
• デフォルトゲートウェイまで通信できるか
• 接続先まで経路があるか
• TCPやTLSの接続が成立するか
• WebサーバーからどのHTTPステータスが返るか

具体的なコマンドを使った確認方法は、第5章の「Windowsで確認するネットワークコマンド」や 「インターネットにつながらないときの基本切り分け」で詳しく扱います。

Webアクセスに関するよくある勘違い

自分の言葉で説明する課題

ITを学び始めた人から、「URLを入力すると、なぜWebサイトが表示されるのですか」と聞かれました。 DNS、ARP、TCPまたはQUIC、HTTPという言葉を使い、1分程度で説明してください。