ネットワークの基礎 — IP・DNS・TCP/UDP・HTTP
Web開発をしていると、「なぜかサーバーに繋がらない」「DNSのキャッシュが残ってる」「TCPとHTTPって何が違うの？」 といった壁に必ず当たります。
この章では、ブラウザに https://example.com と入力してからページが表示されるまでに何が起きているのか、IP・DNS・TCP/UDP・HTTP の4つを軸に整理します。
ブラウザにURLを入れてから表示されるまでの全体像
まずは全体の流れです。細かい部分は後から掘り下げるので、ここでは「こんな順序で動いている」という地図を頭に入れます。
登場人物は「ブラウザ / DNSサーバー / Webサーバー」の3者。そして、DNSで名前解決 → TCPで接続 → HTTPでデータ取得 という3段階で進む、という構造をまず覚えます。
IPアドレスとMACアドレス
ネットワーク上で機器を識別するために、2種類のアドレスが使われます。
IPアドレス は、ネットワーク上の論理的な住所 です。引っ越せば変わる「住所」のようなもので、Wi-Fiを切り替えれば別の値になります。
IPv4: 192.168.1.100
IPv6: 2001:0db8:85a3::8a2e:0370:7334
MACアドレス は、ネットワーク機器のハードウェアに製造時に組み込まれた物理的な識別子 です。原則として変わりません。
MAC: 00:1A:2B:3C:4D:5E
| IPアドレス | MACアドレス | |
|---|---|---|
| 役割 | 論理アドレス | 物理アドレス |
| 変化 | 環境で変わる | 原則固定 |
| 範囲 | インターネット全体 | 同一ネットワーク内 |
| 使う場面 | 別ネットワークの相手を指す | LAN内で宛先を指す |
通信は、「遠くはIPで運び、ラスト1mをMACで届ける」 というイメージです。宅配便が住所で家まで運んで、最後は表札で個人を特定するのと似ています。
DNS — 名前をIPに変換する
人間が 93.184.216.34 のような数字を覚えるのは無理なので、example.com → 93.184.216.34 という名前解決の仕組みが用意されています。それが DNS (Domain Name System) です。
複数のDNSサーバーをバケツリレーして最終的な答えを返します。一度問い合わせた結果は キャッシュ に残るので、同じドメインに2回目以降アクセスする際は、ルートまで辿らずに済みます。
実務でよく関係するのはDNSのTTL（Time to Live） です。サーバーを引っ越してIPが変わったのに、ブラウザや中間キャッシュに古いIPが残っていて、一部のユーザーだけ古いサーバーに繋がる、という現象がよく起きます。TTLを事前に短くしておく、というのが引っ越し時のお作法です。
TCPとUDP — 信頼性 vs 速度
IPの上に乗せて「どう通信するか」を決めるのが トランスポート層のプロトコル で、代表が TCP と UDP です。
TCP — 信頼性重視
TCPは「確実に、正しい順序で届けること」を保証するプロトコルです。通信を始める前に、お互いの準備ができているかを確認する 3ウェイハンドシェイク を行います。
データを送るたびに到達確認（ACK） を返し、失われたら再送 します。順序が入れ替わっていれば並べ直してからアプリに渡します。確実だが、その分オーバーヘッドがある のが特徴です。
UDP — 速度重視
UDPはハンドシェイクなし、再送なし、順序保証なし。ただ投げるだけ のプロトコルです。
届かなかったら諦める、で許されるもの、あるいはアプリケーション側でリトライ制御を持っているもの に向きます。
使い分け
| TCP | UDP | |
|---|---|---|
| 信頼性 | 高い（再送・順序保証） | 低い |
| 速度 | 遅め | 速い |
| 典型例 | HTTP、メール、SSH、DB接続 | DNS、動画ストリーミング、オンラインゲーム、QUIC |
WebサイトはTCPが基本です。「データが欠けるとHTMLが壊れる」ため、信頼性の方が大事だからです。一方、HTTP/3 はUDPベースの QUIC 上で動きます。「UDPの上にHTTPが必要とする信頼性機能を自前で作った」という発想で、ハンドシェイク回数を減らして高速化しています。
HTTP — Webの共通言語
HTTP (HyperText Transfer Protocol) は、WebブラウザとWebサーバーの間でリクエストとレスポンスをやり取りする プロトコルです。TCPの上に乗って動きます。
HTTPの主要な構成要素は、メソッド（GET/POST/PUT/DELETE）、ステータスコード、ヘッダー、ボディ です。
HTTPステータスコード
レスポンスの先頭には3桁の ステータスコード が付き、結果の種類を示します。先頭の数字でカテゴリが決まる のを覚えれば、詳細は都度調べれば十分です。
| カテゴリ | 意味 | 代表例 |
|---|---|---|
| 2xx | 成功 | 200 OK / 201 Created / 204 No Content |
| 3xx | リダイレクト | 301 恒久移転 / 302 一時移転 / 304 未更新 |
| 4xx | クライアント側のエラー | 400 / 401 認証必要 / 403 権限なし / 404 存在しない / 429 送りすぎ |
| 5xx | サーバー側のエラー | 500 内部エラー / 502 ゲートウェイ不正 / 503 一時的に不可 |
実務で正しく使い分けたいのが4xxと5xx です。「バリデーションエラーを500で返す」「権限がないのに404を返す」といった誤用は、APIとしてデバッグしづらい形になります。クライアントの入力が悪いなら4xx、サーバーの都合で処理に失敗したなら5xx が原則です。
HTTPとHTTPSの違い
HTTPS は、HTTPを TLS で暗号化したものです。公開インターネットでHTTP（平文）を使うと、通信経路上でCookieやパスワードが盗聴・改ざんされるため、現代のWebではHTTPS必須 です。ブラウザもHTTPのサイトに警告を出します。
よくあるハマりどころ
1. DNSキャッシュが残って新しいIPに繋がらない
ブラウザ、OS、ルーター、ISP、それぞれにキャッシュが存在します。引っ越し後の切り替わりが遅いときは、まずはOSのDNSキャッシュをクリアするか、別のDNSサーバー（8.8.8.8 や 1.1.1.1 など）で確認します。
2. 「サーバーに繋がらない」ときの切り分け順
pingでIP層で届くかnslookup/digで名前解決できるかcurl -vでTCP/HTTPのどこまで進んでいるか- ファイアウォール / ポート番号 / SSL証明書の期限
「どの層でコケているか」を切り分けるのが最短ルートです。
3. ステータスコードの誤用
- バリデーションエラーで 500 を返してしまう → 本来は 400 Bad Request や 422 Unprocessable Entity
- 権限がないのに 404 を返す → 設計として「存在の有無を隠したい」なら意図的だが、そうでないなら 403 Forbidden
- リダイレクトに 302 を使い続ける → 恒久移転なら 301 を使う（SEO上も推奨）
ちゃんと使うためのポイント
- Web通信は DNS → TCP → HTTP の3段階。それぞれでトラブルが起きうる
- IPは論理アドレス、MACは物理アドレス。IPで経路、MACで届け先
- TCPは信頼性、UDPは速度。HTTP/1/2はTCP、HTTP/3はUDP(QUIC)上
- ステータスコードは先頭の数字でカテゴリ。4xx=クライアント、5xx=サーバーが大原則
- 本番サイトは HTTPS必須。平文HTTPは盗聴・改ざんの対象
次の章では、Web開発で遭遇する代表的なエラー と、その原因の読み解き方を整理します。これまでの章で学んだCPU・メモリ・スタック・ネットワークの知識が、エラーメッセージを読むときに直接役立ちます。