Webの仕組み — ブラウザからサーバーまで何が起きているか
この章の目次開く
ブラウザのアドレスバーにURLを入力してEnterを押すと、一瞬でページが表示されます。しかしその裏側では、複数のサーバーとの通信が何段階にもわたって行われています。
この章では、Webの通信がどんな手順で進むのかを「全体の地図」として整理します。個々の技術は後の章で掘り下げるので、ここではまず流れの全体像を掴みます。
DNS、IPアドレス、TCP/UDP、ポート、TLSをネットワーク基礎として体系的に確認したい場合は、ネットワークの全体像 から読むと、HTTPがどの層の上で動いているかを整理できます。
学習者URLを入れてEnterを押すだけでページが出るけど…裏で何が起きてるのか、実はまったく分かってない。
ブラウザからページが表示されるまでの流れ
大きく分けると 3つのフェーズ で進みます。
- 名前解決（DNS） — ドメイン名をIPアドレスに変換する
- 接続確立（TCP） — サーバーとの通信路を確保する
- データのやりとり（HTTP） — リクエストを送り、レスポンスを受け取る
この「DNS → TCP → HTTP」の順番は、Web開発のトラブルシューティングでも切り分けの基本になります。
フェーズ1: 名前解決 — DNSの役割
ブラウザは example.com という文字列のままでは通信できません。実際に通信するには、サーバーの IPアドレス（例: 93.184.216.34）が必要です。
この「ドメイン名 → IPアドレス」の変換を行うのが DNS（Domain Name System） です。電話帳で名前から電話番号を調べるようなものです。
example.com → DNSに問い合わせ → 93.184.216.34
DNSの結果は一定時間 キャッシュ されます。ブラウザ、OS、ルーターなど複数のレイヤーにキャッシュが存在し、毎回DNSサーバーまで問い合わせるわけではありません。
フェーズ2: 接続確立 — TCPの役割
IPアドレスがわかったら、次はサーバーとの 通信路 を確保します。Web通信では TCP（Transmission Control Protocol） が使われます。
TCPは通信を始める前に「3ウェイハンドシェイク」と呼ばれる手順でお互いの準備を確認します。
このハンドシェイクによって、データが確実に、正しい順序で届く ことが保証されます。Webページは1バイトでも欠けるとHTMLやCSSが壊れるため、この信頼性が重要です。
フェーズ3: データのやりとり — HTTPの役割
TCP接続が確立したら、いよいよ HTTP（HyperText Transfer Protocol） でデータをやりとりします。
HTTPは「リクエスト → レスポンス」の1往復が基本です。
ブラウザ → サーバー: GET /index.html HTTP/1.1
サーバー → ブラウザ: HTTP/1.1 200 OK + HTMLの中身
HTMLを受け取ったブラウザは、その中に書かれたCSS・JavaScript・画像の参照を見つけて、それぞれ追加のHTTPリクエストを送ります。1つのページを表示するために、数十回のHTTPリクエストが飛ぶのは普通です。
URLの構造を分解する
HTTPリクエストの宛先となるURLは、いくつかのパーツで構成されています。
https://api.example.com:443/users/1?fields=name,email#profile
| パーツ | 値 | 意味 |
|---|---|---|
| スキーム | https | 通信プロトコル |
| ホスト | api.example.com | サーバーのドメイン名 |
| ポート | 443 | 接続先のポート番号（HTTPS既定は443） |
| パス | /users/1 | サーバー上のリソースの位置 |
| クエリ | ?fields=name,email | 追加のパラメータ |
| フラグメント | #profile | ページ内の位置（サーバーには送られない） |
Web APIの設計ではこの中の パス と クエリ を特によく使います。「リソースの特定はパスで、フィルタや並び順はクエリで」というのがREST APIの基本的な考え方です。
HTTPSとセキュリティ
現代のWebでは、HTTPではなく HTTPS が標準です。HTTPSは、HTTPの通信を TLS（Transport Layer Security） で暗号化したものです。
| HTTP | HTTPS | |
|---|---|---|
| 通信 | 平文（暗号化なし） | TLSで暗号化 |
| ポート | 80 | 443 |
| ブラウザ表示 | 「保護されていない通信」と警告 | 鍵マーク表示 |
HTTPSがないと、通信経路上の第三者がリクエストの中身（パスワード、Cookie、APIレスポンスなど）を盗聴・改ざんできてしまいます。開発環境でもHTTPS化が推奨されるのはそのためです。
DevToolsで実際に確認する
ここまでの内容は、ブラウザの 開発者ツール（DevTools） で実際に確認できます。Chrome DevToolsを開いて（F12 または Cmd + Option + I）、Networkタブを見ながら任意のページにアクセスしてみます。
DNS・TCP・HTTPの所要時間を見る
Networkタブでリクエストを選択し、Timing タブを見ると、各フェーズにかかった時間がわかります。
| 項目 | 対応するフェーズ |
|---|---|
| DNS Lookup | ドメイン名 → IPアドレスの変換 |
| Initial Connection | TCPハンドシェイク |
| SSL | TLS暗号化のネゴシエーション |
| Waiting (TTFB) | サーバーが処理してレスポンスを返すまで |
| Content Download | レスポンスボディのダウンロード |
1ページで何回リクエストが飛ぶか
NetworkタブのStatusバーに表示される「XX requests」の数字を見ると、1ページの表示に何回のHTTPリクエストが必要かがわかります。一般的なWebサイトでは 30〜100回以上 のリクエストが飛びます。HTML、CSS、JavaScript、画像、フォント、API呼び出し — それぞれが独立したHTTPリクエストです。
よくあるトラブルと切り分け方
Web開発で「繋がらない」「表示されない」というとき、DNS・TCP・HTTPのどこでコケているかを切り分けるのが最短ルートです。
# 1. 名前解決できるか確認
nslookup example.com
# 2. IPに到達できるか確認
ping example.com
# 3. ポートに接続できるか確認
curl -v https://example.com 2>&1 | head -20curl -v の出力を見れば、DNS解決、TCP接続、TLSハンドシェイク、HTTPレスポンスのどこまで進んだかがわかります。
まとめ
Webの通信は DNS → TCP → HTTP の3段階で進みます。
- DNS でドメイン名をIPアドレスに変換する
- TCP で信頼性のある通信路を確立する
- HTTP でリクエストとレスポンスをやりとりする
- HTTPS はHTTPをTLSで暗号化したもので、現代のWebでは必須
- SSH はHTTPとは別の安全な通信プロトコルで、GitHubのSSH cloneなどで使われる
この全体像を押さえておくと、「サーバーに繋がらない」「レスポンスがおかしい」といったトラブルのとき、どの層で問題が起きているかを切り分けられるようになります。
次の章では、HTTPの中核である HTTPメソッド（GET・POST・PUT・DELETE）の使い分けを詳しく見ていきます。