実践LESSON 03
この教材で学ぶこと TCP/IPの動作を、通信障害の切り分けまでつなげて理解します。TCP/IP 詳解 — 応用情報・実務レベル
前提知識: OSI参照モデルの概要。本教材ではプロトコルの詳細とトラブルシューティングを扱います。
1. TCP の状態遷移（応用情報頻出）
クライアント サーバー
| |
|──── SYN ─────────────────> | LISTEN
| | SYN_RCVD
| <──── SYN+ACK ────────── |
| ESTABLISHED |
|──── ACK ─────────────────> | ESTABLISHED
| |
| ← データ転送 → |
| |
|──── FIN ─────────────────> | CLOSE_WAIT
| FIN_WAIT_1 |
| <──── ACK ────────────── |
| FIN_WAIT_2 |
| <──── FIN ────────────── | LAST_ACK
| TIME_WAIT |
|──── ACK ─────────────────> | CLOSED
| (2MSL待機後CLOSED) |TIME_WAIT が重要な理由
- 最後の ACK がロストした場合にサーバーが FIN を再送できるようにする
- ネットワーク上に残った古いパケットが新しい接続に混入しないようにする
- 実務での問題: 短命な接続を大量に張ると TIME_WAIT が枯渇 →
net.ipv4.tcp_tw_reuse=1で対処
2. TCP ヘッダーの重要フィールド（応用情報で問われる）
| フィールド | ビット数 | 内容 |
|---|---|---|
| 送信元ポート | 16 | |
| 宛先ポート | 16 | |
| シーケンス番号 | 32 | 送信バイトの先頭番号 |
| 確認応答番号 | 32 | 次に期待する受信バイト番号 |
| データオフセット | 4 | ヘッダー長（32bit単位） |
| フラグ | 6 | URG/ACK/PSH/RST/SYN/FIN |
| ウィンドウサイズ | 16 | 受信バッファの残量（フロー制御） |
| チェックサム | 16 | 誤り検出 |
| 緊急ポインタ | 16 | URGフラグ時のみ有効 |
ウィンドウサイズとスループット
スループット上限 = ウィンドウサイズ / RTT
例: ウィンドウサイズ 64KB、RTT 100ms
= 65536 bytes / 0.1s = 655,360 bytes/s ≒ 5.2 Mbps
→ 回線が1Gbpsでも、RTTが大きければウィンドウサイズがボトルネックになる
→ TCP Window Scaling（RFC 7323）で最大1GB まで拡張可能3. HTTP/1.1 vs HTTP/2 vs HTTP/3
| 機能 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 多重化 | ❌（1接続1リクエスト） | ✅（ストリーム） | ✅ |
| ヘッダー圧縮 | ❌ | ✅（HPACK） | ✅（QPACK） |
| サーバープッシュ | ❌ | ✅ | ✅ |
| トランスポート | TCP | TCP | QUIC（UDP） |
| HoL ブロッキング | あり | TCP層ではあり | なし |
HTTP/2 のストリームとフレーム
1本のTCP接続
Stream 1 ──[HEADERS][DATA][DATA]──────────────>
Stream 3 ───────[HEADERS][DATA]────────────>
Stream 5 ────────────[HEADERS][DATA][DATA]─>
↑ 多重化：複数リクエストを並列で処理4. TLS 1.3 ハンドシェイク（応用情報・セキュリティで頻出）
クライアント サーバー
| |
|── ClientHello ─────────────> | （サポートするCipher Suite、乱数）
| <── ServerHello ───────── | （選択したCipher Suite、証明書、公開鍵）
| |
| 証明書検証（CAの公開鍵で署名確認）
| |
|── Finished ────────────────> | （共有鍵で暗号化）
| <── Finished ──────────── |
| |
| ← 暗号化通信開始 → |TLS 1.3 の改善点（vs TLS 1.2）:
- ハンドシェイクが 1-RTT（1.2は2-RTT）
- 脆弱な暗号スイート（RSA鍵交換等）を廃止
- 前方秘匿性（PFS）を必須化 — 秘密鍵が漏洩しても過去の通信は守られる
5. DNS の仕組み（応用情報必須）
名前解決の流れ
ブラウザ → OSキャッシュ → スタブリゾルバ（/etc/resolv.conf）
→ フルサービスリゾルバ（例: 8.8.8.8）
→ ルートDNSサーバー（.）
→ TLDサーバー（.jp, .com）
→ 権威DNSサーバー（example.com）
→ 回答をキャッシュ（TTL秒間）重要なレコードタイプ
| レコード | 意味 | 例 |
|---|---|---|
| A | IPv4アドレス | example.com → 1.2.3.4 |
| AAAA | IPv6アドレス | |
| CNAME | 別名 | www → example.com |
| MX | メールサーバー | 優先度付き |
| TXT | テキスト | SPF・DKIMなど |
| NS | ネームサーバー | |
| SOA | ゾーン情報 | TTL・管理者等 |
| PTR | 逆引き | 1.2.3.4 → example.com |
DNS トラブルシューティング
# 権威DNSに直接問い合わせ（キャッシュを経由しない）
dig +trace example.com
# TTL確認
dig example.com | grep -A1 "ANSWER SECTION"
# 逆引き
dig -x 8.8.8.8
# DNSサーバーの指定
dig @1.1.1.1 example.com
# 特定レコードタイプ
dig example.com MX
dig example.com TXT | grep spf6. NAT・IPマスカレード
[Private: 192.168.1.10:50000] → [NAT変換] → [Public: 203.0.113.1:60001]
↓
[Internet Server: 8.8.8.8:80]
NATテーブル:
192.168.1.10:50000 ↔ 203.0.113.1:60001
192.168.1.11:50001 ↔ 203.0.113.1:60002NAPT（IPマスカレード）: 複数のプライベートIPを1つのグローバルIPに変換
AWS の場合: NATゲートウェイがこの役割 → プライベートサブネットからのアウトバウンドを可能にする
7. 応用情報 午後問題 — ネットワーク頻出パターン
サブネット計算（確実に解けるようにする）
問題: 172.16.0.0/20 のネットワーク
→ サブネットマスク: 255.255.240.0
→ ホストアドレス数: 2^12 - 2 = 4094台
→ ネットワークアドレス: 172.16.0.0
→ ブロードキャスト: 172.16.15.255
→ 使用可能範囲: 172.16.0.1 ～ 172.16.15.254VLAN と トランク
アクセスポート: 1つのVLANのみ（エンドデバイス接続）
トランクポート: 複数VLANを束ねる（スイッチ間・スイッチ-ルーター間）
タグなしVLAN（ネイティブVLAN）: タグなしフレームが属するVLANスパニングツリー（STP）
- ループ防止プロトコル（L2ネットワークでのブロードキャストストームを防ぐ）
- ルートブリッジ選出 → 最小コストのパスを有効化 → 冗長パスをブロック
- RSTP（Rapid STP）: STPの高速版（収束時間を数秒に短縮）
🔗 次のステップ
- DNS・TLS・HTTP詳解 — アプリ層プロトコル深掘り（今後追加予定）
- ネットワークセキュリティ — TLSとセキュリティ（今後追加予定）
- AWSネットワーク設計 — AWSでのネットワーク応用（今後追加予定）