エンジニアのためのネットワーク基礎｜TCP/IP・DNS・HTTPを図解で理解

「ネットワークはインフラエンジニアの領域」と考えているWebエンジニアは少なくありません。しかし、APIの通信遅延やDNSの設定ミス、ファイアウォールの問題など、ネットワークの知識がなければ解決できないトラブルは日常的に発生します。

本記事では、Webエンジニアが最低限押さえておくべきネットワークの基礎知識を、TCP/IP、DNS、HTTPを中心に実践的に解説します。

TCP/IPモデルの全体像

インターネット上のすべての通信は、TCP/IPモデルと呼ばれるプロトコルの階層構造に基づいて行われます。このモデルを理解することが、ネットワークの仕組みを把握する第一歩です。

4つのレイヤーとその役割

TCP/IPモデルは4つのレイヤー（層）で構成されます。各レイヤーには明確な役割があり、上位レイヤーは下位レイヤーの機能を利用します。

アプリケーション層
ユーザーが直接触れるプロトコルの層です。HTTP、HTTPS、DNS、SMTP、FTP、SSHなどが含まれます。Webブラウザやメールクライアントが使うプロトコルはここに位置します。

トランスポート層
アプリケーション間の通信を制御する層です。TCPとUDPが代表的なプロトコルです。データの信頼性のある転送（TCP）や、高速だが信頼性を保証しない転送（UDP）を提供します。

インターネット層
ネットワーク間のルーティング（経路制御）を行う層です。IPプロトコルがデータをパケットに分割し、宛先まで届けます。

ネットワークインターフェース層
物理的なネットワーク接続を担う層です。イーサネット、Wi-Fiなど、実際にデータを電気信号や電波として送受信する技術が含まれます。

データの流れを追う

ブラウザでhttps://example.comにアクセスしたとき、データは以下のように処理されます。

【送信時：上から下へカプセル化】
アプリケーション層  : HTTPリクエスト（GET / HTTP/1.1）
    ↓
トランスポート層    : TCPセグメント（送信元ポート:49152 → 宛先ポート:443）
    ↓
インターネット層    : IPパケット（送信元IP:192.168.1.10 → 宛先IP:93.184.216.34）
    ↓
ネットワークIF層   : イーサネットフレーム（MACアドレス付き）

【受信時：下から上へデカプセル化（逆の順序）】

各レイヤーで独自のヘッダー情報が追加され（カプセル化）、受信側では逆にヘッダーを除去して（デカプセル化）元のデータを取り出します。

IPアドレスとポート番号

ネットワーク通信の宛先を特定するための2つの重要な概念が、IPアドレスとポート番号です。

IPv4とIPv6

IPv4アドレス
32ビットで表現される、最も広く使われているIPアドレス形式です。約43億個のアドレスが使用可能ですが、インターネットの普及により枯渇しています。

// IPv4アドレスの形式
192.168.1.10       // プライベートアドレス（LAN内部用）
203.0.113.50       // グローバルアドレス（インターネット上で一意）

// プライベートアドレスの範囲
10.0.0.0    ～ 10.255.255.255     (クラスA: 大規模ネットワーク)
172.16.0.0  ～ 172.31.255.255     (クラスB: 中規模ネットワーク)
192.168.0.0 ～ 192.168.255.255    (クラスC: 小規模ネットワーク)

IPv6アドレス
128ビットで表現される次世代のIPアドレス形式です。事実上無限に近い数のアドレスを提供します。

// IPv6アドレスの形式
2001:0db8:85a3:0000:0000:8a2e:0370:7334
// 省略形
2001:db8:85a3::8a2e:370:7334

ポート番号の役割

IPアドレスが「建物の住所」だとすると、ポート番号は「部屋番号」に相当します。一つのIPアドレスで複数のサービスを同時に提供するために使います。

// よく使われるポート番号
80    : HTTP（Webサーバー）
443   : HTTPS（SSL/TLS付きWebサーバー）
22    : SSH（リモートログイン）
25    : SMTP（メール送信）
53    : DNS（名前解決）
3306  : MySQL
5432  : PostgreSQL
6379  : Redis
3000  : 開発サーバー（Node.js等でよく使われる）
8080  : 代替HTTP（開発用によく使われる）

// ポート番号の範囲
0-1023     : ウェルノウンポート（特権ポート、管理者権限が必要）
1024-49151 : 登録済みポート（アプリケーション用）
49152-65535: 動的・プライベートポート（OS が自動割り当て）

# ポートの使用状況を確認するコマンド
# Linuxの場合
ss -tlnp               # TCPリスニングポートの一覧
netstat -tlnp           # 同様（古い方式）
lsof -i :3000           # 特定ポートを使用しているプロセス

# macOSの場合
lsof -nP -iTCP -sTCP:LISTEN

TCPとUDPの違いを理解する

トランスポート層で最も重要な2つのプロトコルが、TCPとUDPです。それぞれの特性を理解し、適切に使い分けましょう。

TCP（Transmission Control Protocol）

TCPは信頼性のある通信を提供するコネクション型プロトコルです。

3ウェイハンドシェイク
通信開始前に、送信者と受信者が接続を確立するプロセスです。

// 3ウェイハンドシェイクの流れ
クライアント → サーバー : SYN（接続要求）
クライアント ← サーバー : SYN+ACK（接続要求の確認応答）
クライアント → サーバー : ACK（確認応答の確認）
// これで接続が確立され、データ通信が開始される

TCPの特徴

・データの到着を保証（再送制御）
・データの順序を保証（順序制御）
・フロー制御・輻輳制御による通信の最適化
・コネクション確立のオーバーヘッドがある

用途：HTTP/HTTPS、メール（SMTP）、ファイル転送（FTP）、SSH、データベース接続など、データの正確性が求められる通信。

UDP（User Datagram Protocol）

UDPは高速だが信頼性を保証しないコネクションレス型プロトコルです。

UDPの特徴

・コネクション確立が不要（ハンドシェイクなし）
・データの到着や順序を保証しない
・オーバーヘッドが小さく高速
・リアルタイム性を重視するアプリケーションに最適

用途：DNS問い合わせ、動画・音声ストリーミング、オンラインゲーム、VoIPなど。

なお、HTTP/3ではQUICプロトコルがUDPの上に構築されています。TCPの信頼性をアプリケーション層で実現しつつ、UDPの高速性を活かした設計になっています。

DNSの仕組みを理解する

DNS（Domain Name System）は、人間が読めるドメイン名（example.com）を、コンピュータが理解できるIPアドレス（93.184.216.34）に変換する仕組みです。「インターネットの電話帳」とも呼ばれます。

DNS名前解決の流れ

ブラウザでwww.example.comにアクセスしたときのDNS問い合わせの流れを追ってみましょう。

// DNS問い合わせの流れ（再帰的クエリ）

1. ブラウザのDNSキャッシュを確認
   → キャッシュにあれば、そのIPアドレスを使用（終了）

2. OSのDNSキャッシュを確認
   → キャッシュにあれば、そのIPアドレスを使用（終了）

3. DNSリゾルバ（通常はISPまたは8.8.8.8など）に問い合わせ
   → リゾルバのキャッシュにあれば応答（終了）

4. リゾルバがルートDNSサーバーに問い合わせ
   → 「.com のネームサーバーは a.gtld-servers.net です」と応答

5. リゾルバが.comのTLDネームサーバーに問い合わせ
   → 「example.com のネームサーバーは ns1.example.com です」と応答

6. リゾルバがexample.comの権威DNSサーバーに問い合わせ
   → 「www.example.com のIPアドレスは 93.184.216.34 です」と応答

7. リゾルバが結果をキャッシュし、クライアントに応答

主要なDNSレコードタイプ

DNS設定で頻繁に使用するレコードタイプを理解しておきましょう。

// 代表的なDNSレコード
// Aレコード：ドメイン名をIPv4アドレスに紐づけ
example.com.    IN  A     93.184.216.34

// AAAAレコード：ドメイン名をIPv6アドレスに紐づけ
example.com.    IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

// CNAMEレコード：ドメイン名を別のドメイン名にエイリアス
www.example.com.  IN  CNAME  example.com.
blog.example.com. IN  CNAME  example.github.io.

// MXレコード：メールの送信先サーバーを指定
example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.  // 優先度が低いバックアップ

// TXTレコード：テキスト情報（SPF、DKIM、ドメイン所有確認など）
example.com.    IN  TXT   "v=spf1 include:_spf.google.com ~all"

// NSレコード：ゾーンの権威ネームサーバーを指定
example.com.    IN  NS    ns1.example.com.
example.com.    IN  NS    ns2.example.com.

DNSのトラブルシューティング

# DNSの問い合わせを確認するコマンド

# digコマンド（推奨）
dig example.com                # Aレコードの問い合わせ
dig example.com AAAA           # AAAAレコードの問い合わせ
dig example.com MX             # MXレコードの問い合わせ
dig +trace example.com         # 問い合わせ経路の追跡
dig @8.8.8.8 example.com       # 特定のDNSサーバーに問い合わせ

# nslookupコマンド
nslookup example.com
nslookup -type=MX example.com

# DNS伝播の確認（レコード変更後）
# TTL（Time To Live）が切れるまでキャッシュが残る
dig example.com +short         # 現在のIPを確認
dig example.com SOA            # SOAレコードでTTLを確認

HTTPプロトコルの基礎

HTTP（HyperText Transfer Protocol）は、Webの基盤となるアプリケーション層プロトコルです。クライアント（ブラウザ）とサーバーがリクエストとレスポンスを交換する形で通信します。

HTTPメソッド

HTTPメソッドは、リクエストの目的を示します。RESTful APIでは、各メソッドの意味を正しく使い分けることが重要です。

// 主要なHTTPメソッド
GET     : リソースの取得（副作用なし、べき等）
POST    : リソースの作成（副作用あり）
PUT     : リソースの全体更新（べき等）
PATCH   : リソースの部分更新
DELETE  : リソースの削除（べき等）
HEAD    : GETと同じだがボディを返さない（ヘッダーのみ）
OPTIONS : 利用可能なメソッドの確認（CORSプリフライト）

HTTPステータスコード

ステータスコードは3桁の数字で、リクエストの処理結果を示します。

// 2xx：成功
200 OK                    : リクエスト成功
201 Created               : リソースが作成された
204 No Content            : 成功したがレスポンスボディなし

// 3xx：リダイレクト
301 Moved Permanently     : 恒久的なリダイレクト
302 Found                 : 一時的なリダイレクト
304 Not Modified          : キャッシュを使用可能

// 4xx：クライアントエラー
400 Bad Request           : リクエストの形式が不正
401 Unauthorized          : 認証が必要
403 Forbidden             : アクセス権限がない
404 Not Found             : リソースが見つからない
405 Method Not Allowed    : メソッドが許可されていない
429 Too Many Requests     : レート制限超過

// 5xx：サーバーエラー
500 Internal Server Error : サーバー内部エラー
502 Bad Gateway           : ゲートウェイ/プロキシのエラー
503 Service Unavailable   : サービス利用不可（メンテナンス等）
504 Gateway Timeout       : ゲートウェイタイムアウト

重要なHTTPヘッダー

// リクエストヘッダー
Host: example.com                        // リクエスト先のホスト名
User-Agent: Mozilla/5.0 ...             // クライアント情報
Accept: application/json                 // 受け入れ可能なメディアタイプ
Authorization: Bearer eyJhbGciOi...      // 認証情報
Content-Type: application/json           // リクエストボディのメディアタイプ
Cookie: session_id=abc123                // Cookie

// レスポンスヘッダー
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=3600              // キャッシュ制御
Set-Cookie: session_id=abc123; HttpOnly; Secure
X-Request-Id: 550e8400-e29b...           // リクエスト追跡用ID

HTTP/2とHTTP/3の進化

HTTPプロトコルは進化を続けています。HTTP/2とHTTP/3がもたらす改善を理解しましょう。

HTTP/2の主な特徴

多重化（Multiplexing）
1つのTCP接続上で複数のリクエスト・レスポンスを並行して処理します。HTTP/1.1では1つのTCP接続で1つのリクエストしか処理できなかったため、大きなパフォーマンス改善になります。

ヘッダー圧縮（HPACK）
HTTPヘッダーを効率的に圧縮します。繰り返し送信されるヘッダー情報の冗長性を排除し、帯域幅を節約します。

サーバープッシュ
クライアントがリクエストする前に、サーバーが関連リソースを先行して送信できます。ただし、実際の運用では効果が限定的で、利用は減少傾向にあります。

HTTP/3の主な特徴

QUICプロトコル
TCPの代わりにUDPベースのQUICプロトコルを使用します。TCP特有のHead-of-Line Blocking（先頭パケットの遅延が後続に影響する問題）を解消します。

接続確立の高速化
TLSハンドシェイクが統合されており、最短0-RTT（ゼロラウンドトリップ）で接続を再開できます。モバイル環境でのパフォーマンスが特に向上します。

接続の移行
Wi-Fiからモバイルネットワークへの切り替え時でも、接続を維持できます。IPアドレスが変わっても通信が途切れません。

開発で役立つネットワークツール

ネットワークの問題を調査・デバッグするためのツールを紹介します。

curl：HTTPリクエストの送信

# 基本的なGETリクエスト
curl https://api.example.com/users

# レスポンスヘッダーも表示
curl -v https://api.example.com/users

# POSTリクエスト（JSON）
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "山田太郎", "email": "yamada@example.com"}'

# 認証付きリクエスト
curl -H "Authorization: Bearer eyJhbGciOi..." https://api.example.com/profile

# レスポンスタイムの計測
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" https://example.com

その他の有用なコマンド

# ping：疎通確認
ping example.com

# traceroute：経路確認
traceroute example.com
# macOS: traceroute example.com
# Windows: tracert example.com

# tcpdump：パケットキャプチャ
sudo tcpdump -i eth0 port 80 -A     # HTTPトラフィックをキャプチャ
sudo tcpdump -i eth0 host example.com # 特定ホストの通信をキャプチャ

# ss：ソケットの状態確認
ss -s            # ソケット統計サマリー
ss -tlnp         # リスニング中のTCPポート一覧