📄
概念 📚 beginner-stepup

ネットワーク基礎（TCP/IP・DNS・HTTPS）

Web の下を流れているネットワーク層の仕組み（TCP/IP・ポート・DNS・HTTPS/TLS・NAT）を、アプリ開発者が実務で困らない粒度でまとめる

  • この章で学ぶこと：IP アドレス・ポート・DNS・TCP／UDP・HTTPS／TLS の役割を説明でき、ping や nslookup などの基本ツールで疎通を切り分けられる状態になる。
  • なぜ学ぶのか：障害対応では「ブラウザが悪いのか、サーバーが悪いのか、ネットワークが悪いのか」の切り分けが必須。ネットワーク層の共通言語を持つと、インフラチームとの会話が通じるようになる。
  • Web 開発のどの領域か：インフラ・運用寄りの横断知識。フロント／バック開発でも障害解析時に必ず使う。

前提: b00-2-url-to-screen を読んで 10 段階の旅を一通り把握していること。

所要時間: 45 分（読解 30 分＋確認クイズ 15 分）

到達目標: 社内の別サーバーにアクセスできないとき、「DNS が引けないのか、TCP 接続が通らないのか、TLS で失敗しているのか」を 3 コマンドで切り分けられる状態。

TCP/IP 4 層モデル

インターネット上の通信は 層（レイヤー） を重ねて実現される。教科書的には OSI 7 層モデルが有名だが、実務では TCP/IP 4 層モデル の方が直感的である。

TCP/IP 4 層モデルの図

役割分担：HTTP は「人間が書くメッセージ」、TCP は「配達証明付き郵便」、IP は「住所と配送ルート」、Ethernet/Wi-Fi は「トラック・電波」に例えられる。

IP アドレス

IP アドレスはネットワーク上のホストを一意に識別する番号である。

  • IPv4: 192.0.2.1 のような 32 ビット（4 オクテット）。世界で約 43 億個しかなく、枯渇済み。
  • IPv6: 2001:db8::1 のような 128 ビット。事実上無限。普及が進行中。

プライベート IP とパブリック IP

  • プライベート IP: 家庭内・会社内でのみ有効な IP。10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 が予約されている。
  • パブリック IP: インターネット全体で一意の IP。ISP から割り当てられる。

家庭内の PC はプライベート IP を持っており、ルーターが NAT（Network Address Translation） でパブリック IP に書き換えて外に出す。

ループバック

127.0.0.1（IPv4）と ::1（IPv6）は自分自身を指す特別な IP。localhost はこれらを指すホスト名で、開発サーバー（http://localhost:4321）の接続先になる。

ポート番号

1 台のサーバーは 65,535 個のポート を持つ。ポートは「どのアプリに届ける荷物か」を示すサーバー内の窓口番号。

ポート用途
22SSH
53DNS
80HTTP
443HTTPS
3000〜5432開発用（React dev server 3000、PostgreSQL 5432 など）
4321Astro dev server（本サイトのローカル）

0〜1023 はウェルノウンポートで、root 権限が必要（macOS/Linux）。アプリ開発では 1024 以上を使う。

TCP と UDP

トランスポート層の代表的な 2 つのプロトコル。

TCPUDP
信頼性配達保証・順序保証・再送あり配達保証なし・順序保証なし
接続性3-way ハンドシェイクで接続確立コネクションレス
速度遅め高速・軽量
用途HTTP／HTTPS／SSH／メールDNS・動画／音声ストリーミング・オンラインゲーム

Web は長らく TCP 一択だったが、HTTP/3 は UDP 上に QUIC という独自プロトコルを乗せることで TCP の欠点（ハンドシェイクの往復数、TCP Head-of-Line Blocking）を改善している。

DNS：名前解決の仕組み

DNS はホスト名を IP アドレスに変換する分散データベース。主要なレコードタイプは次のとおり。

レコード意味
Aホスト名 → IPv4 アドレス
AAAAホスト名 → IPv6 アドレス
CNAMEホスト名 → 別のホスト名（別名）
MXメール配送先サーバー
TXT任意のテキスト（SPF・DKIM・ドメイン所有確認などで使用）
NSそのドメインを管理する権威 DNS サーバー

名前解決の流れ

アプリ（ブラウザ） → OS のリゾルバ（stub resolver）
                   → 設定済み DNS サーバー（/etc/resolv.conf や ISP の DNS）
                   → （キャッシュになければ）ルート → TLD → 権威サーバーの順で再帰問い合わせ

DNS の結果は TTL（Time To Live） の秒数だけキャッシュされる。短い TTL（60 秒）にしておくと切り替えが早く反映されるが、DNS サーバーへの問い合わせが増える。

HTTPS と TLS

HTTPS は HTTP over TLS の略。TLS が提供するのは次の 3 点。

  1. 機密性：対称鍵暗号でパケットを暗号化し、盗聴を防ぐ。
  2. 完全性：MAC（Message Authentication Code）で改ざんを検出する。
  3. 真正性：サーバー証明書で接続先が本物かを確認する。

証明書と認証局

サーバー証明書は 認証局（CA：Certificate Authority） が発行・署名する。ブラウザと OS にはあらかじめ信頼できる CA のルート証明書が組み込まれており、その連鎖で検証する。

  • 無料の CA: Let’s Encrypt が事実上の標準。AWS Certificate Manager も AWS 内で無料。
  • 有効期限: Let’s Encrypt は 90 日。自動更新の仕組み（certbot など）を必ず組む。
  • ワイルドカード証明書: *.example.com のようにサブドメイン全体に 1 枚で対応可能。

NAT とファイアウォール

  • NAT: プライベート IP とパブリック IP を相互変換する。家庭用ルーターが典型例。1 つのパブリック IP の裏に複数のクライアントが隠れる。
  • ファイアウォール: ポートやプロトコル単位で通信を許可／拒否する。AWS の Security Group、Linux の iptables／nftables が代表例。
  • リバースプロキシ: サーバー側でクライアントに近い位置に立ち、SSL 終端・ロードバランシング・キャッシュを担う。Nginx・CloudFront・ALB など。

本カリキュラムの AWS 構成（b00-target-infrastructure 参照）では、CloudFront → ALB → EC2 の経路でこれらが組み合わさって動く。

【Windows / macOS 差分】ネットワーク調査コマンド

障害時の基本は「上の層から順に切り分ける」こと。以下の 4 コマンドがその入口となる。

macOS（zsh / Terminal）:

ping example.com                    # IP 層の疎通（応答があるか）
nslookup example.com                # DNS 解決（IP が引けるか）
traceroute example.com              # 経路（どこで止まるか）
curl -vI https://example.com        # TLS・HTTP まで含めた疎通

Windows（PowerShell）:

Test-Connection example.com             # ping の PowerShell 版
Resolve-DnsName example.com             # nslookup の PowerShell 版
Test-NetConnection example.com -Port 443 # 特定ポートへの TCP 到達確認
Invoke-WebRequest -Uri https://example.com -Method Head -Verbose

補足: Windows でも Git Bash／WSL2 を使えば macOS と同じコマンドが使える。本カリキュラムは WSL2 を推奨しており、b00-env-setup で導入手順を案内している。

【セキュリティ】コラム：中間者攻撃（MITM）と HTTPS

脅威: 公衆 Wi-Fi やルーターの乗っ取りによって、クライアントとサーバーの間に攻撃者が割り込むと、HTTP の通信はすべて読み取り・改ざんされてしまう。

具体例: 空港の無料 Wi-Fi に接続中、HTTP のログインページにパスワードを入力すると、同じ Wi-Fi にいる攻撃者が tcpdump で平文のまま読み取れる。

防御:

  1. HTTPS を強制する：すべての本番サーバーで HTTPS 化し、HSTS ヘッダーで HTTP アクセスを禁止する。
  2. 証明書エラーを無視しない：ブラウザの警告は中間者攻撃の可能性がある。自己署名証明書を安易に信頼する習慣をつけない。
  3. Public Wi-Fi では VPN：信頼できない Wi-Fi では VPN か 4G/5G 回線を使う。

本カリキュラムでは b17-hosting で ACM（AWS Certificate Manager）による HTTPS 化、b18-env-vars で Cookie の Secure 属性の設定を扱う。

【他言語対応】表：HTTP クライアントの書き方

言語コード例
TypeScript（ブラウザ・Node.js）const res = await fetch('https://api.example.com/users');
Pythonimport requests; res = requests.get('https://api.example.com/users')
Rubyrequire 'net/http'; Net::HTTP.get(URI('https://api.example.com/users'))
Goresp, err := http.Get("https://api.example.com/users")
シェル（curl）curl https://api.example.com/users

どの言語でも「URL を指定してレスポンスを受け取る」という本質は変わらない。違いは非同期制御・エラーハンドリング・型定義の仕組みにある。

よくある詰まりポイント

  • ping が通らないからといって「サーバーが落ちている」とは限らない。ICMP をファイアウォールで落としている本番環境は多く、Test-NetConnection で TCP ポートが開いているかを見る必要がある。
  • localhost と 127.0.0.1 と 0.0.0.0 を混同しがち。0.0.0.0 は「すべてのインターフェイスで待ち受ける」という意味で、クライアントが接続する IP ではない。
  • DNS の設定変更が即時反映されないのは TTL のキャッシュが原因。dig +trace example.com や nslookup -type=NS example.com で権威サーバーに直接問い合わせると最新値を確認できる。
  • 自己署名証明書は TLS の真正性検証を通さないため、学習以外で使うと中間者攻撃と区別がつかない状態になる。本番は必ず CA 署名の証明書を使う。

参考リソース

確認クイズ

Q1. TCP/IP 4 層モデルの層として正しい組み合わせはどれか。　A. 物理・データリンク・ネットワーク・トランスポート　B. アプリケーション・トランスポート・インターネット・ネットワーク　C. プレゼンテーション・セッション・アプリケーション・トランスポート　D. HTTP・TCP・IP・HTTPS

正解: B. アプリケーション・トランスポート・インターネット・ネットワーク

解説: TCP/IP 4 層モデルは上から順にアプリケーション層（HTTP・SSH）、トランスポート層（TCP・UDP）、インターネット層（IP）、ネットワーク層（Ethernet・Wi-Fi）。OSI 7 層モデルとは違う実用的な区切り。

Q2. プライベート IP として予約されているアドレス範囲はどれか。　A. 127.0.0.0/8　B. 8.8.8.0/24　C. 192.168.0.0/16　D. 169.254.0.0/16

正解: C. 192.168.0.0/16

解説: RFC 1918 で予約されているプライベート IP は 10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 の 3 つ。家庭用ルーターは通常 192.168.1.0/24 などを使う。127.0.0.0/8 はループバック、169.254.0.0/16 はリンクローカル用の別の区分。

Q3. localhost・127.0.0.1・0.0.0.0 の違いを説明せよ。

正解: localhost と 127.0.0.1 はどちらも自分自身（ループバック）を指すが、0.0.0.0 は「すべてのネットワークインターフェイスで待ち受ける」という意味でサーバー起動時の bind に使うアドレスである。クライアントが接続する IP として使うものではない。

解説: Hono や Express を 0.0.0.0:3000 で起動すると、localhost:3000 だけでなく LAN 内の他のマシンからも接続できるようになる。127.0.0.1:3000 で起動すると自分自身からしか接続できない。

Q4. TCP と UDP の違いとして正しいものはどれか。

正解: TCP は配達保証・順序保証・再送があり、UDP はそれらを持たない代わりに軽量で高速である。

解説: TCP は信頼性が必要な HTTP・SSH・メールで使われ、UDP はリアルタイム性が重要な DNS・動画／音声ストリーミング・オンラインゲームで使われる。HTTP/3 は UDP 上の QUIC で信頼性を独自に実装している。

Q5. DNS の A レコードと CNAME レコードの違いを説明せよ。

正解: A レコードはホスト名を IPv4 アドレスに対応付け、CNAME レコードはホスト名を別のホスト名に対応付ける（別名にする）レコードである。

解説: www.example.com → 192.0.2.1 が A レコード、www.example.com → example.com が CNAME レコード。CNAME は IP が変わっても末端側の設定を変更不要にできる利点があるが、ルートドメイン（example.com 自身）には使えないという制約がある。

Q6. TLS が提供する 3 つの性質を答えよ。

正解: 機密性（暗号化）・完全性（改ざん検出）・真正性（証明書による身元確認）。

解説: この 3 つが揃うことで、クライアントは「盗聴されない」「改ざんされていない」「相手は本物のサーバーである」ことを保証できる。3 点のうちどれか 1 つが欠けても安全な通信とは呼べない。

Q7. NAT の役割を説明せよ。

正解: プライベート IP とパブリック IP を相互変換する仕組みで、1 つのパブリック IP の裏に複数のデバイスを収容できるようにする。

解説: IPv4 の枯渇を緩和するための工夫でもある。NAT の裏側にあるデバイスに外から直接アクセスするには、ポートフォワーディング・トンネリング・リバースプロキシのいずれかが必要。

Q8. 社内のサーバー api.internal.example.com に接続できないときの切り分け順序として合理的なものはどれか。　A. curl → nslookup → ping　B. nslookup → ping / Test-NetConnection → curl　C. ping → curl → nslookup　D. traceroute → curl → nslookup

正解: B. nslookup → ping / Test-NetConnection → curl

解説: 下の層から順に切り分ける。まず DNS で名前解決できるか（nslookup）、次に IP 層で疎通があるか（ping）、次に TCP ポートが開いているか（Test-NetConnection または telnet）、最後に TLS・HTTP まで含めた確認（curl -vI）の順がセオリー。

Q9. Let's Encrypt の証明書の有効期限は何日か。また、それが短く設定されている理由は何か。

正解: 90 日。短く設定されている理由は、漏洩した秘密鍵による被害期間を限定するためと、自動更新の仕組みを必ず組ませるため。

解説: 有効期限を短くすることで、万が一秘密鍵が漏洩しても悪用期間が最大 90 日に制限される。また、短い期限は certbot などの自動更新ツールの使用を促し、運用の属人化を防ぐ効果もある。

Q10. HSTS ヘッダーを有効化することの効果を説明せよ。

正解: ブラウザが当該ドメインへの HTTP 接続を自動的に HTTPS に置き換え、最初のリクエストから中間者攻撃の機会を奪う。

解説: HTTP でリダイレクトする方式では、最初の HTTP リクエストが中間者に盗聴・改ざんされるリスクが残る。HSTS はブラウザ側で HTTP を出さないようにするため、このリスクを完全になくせる。有効期限（max-age）は 1 年以上が推奨される。

生きているコード

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

  • 対応 Week: W2
  • 参照ブランチ:
  • W2: reference/week-2
  • 対応 checklist 項目: （直接対応なし）

ブランチの作り方・見方は b00-curriculum-map を参照してください。

📚 beginner-stepup 全 53 章
導入編 13 章 ● この編を閲覧中
  1. 1. 📄Web とは何か
  2. 2. 📄URL を打ってから画面が表示されるまで
  3. 3. 📄ネットワーク基礎（TCP/IP・DNS・HTTPS）
  4. 4. 📄【発展】物理層から通信が成立するまで（電力・Ethernet・Wi-Fi・Bluetooth）
  5. 5. 📄WSL2・Docker セットアップ詳細（Windows 向け）
  6. 6. 📄環境構築の段階的導入（macOS / Windows）
  7. 7. 📄カリキュラム全体マップ（Week × 教材 × 参照ブランチ × 要求チェックリスト）
  8. 8. 📄このカリキュラムの使い方（SQL・Python・Dify経験者向け）
  9. 9. 📄シェル・ターミナル基礎
  10. 10. 📄Windows で完全にゼロから始める開発環境構築（Week 1）
  11. 11. 📄Git基礎
  12. 12. 📄GitHubワークフロー
  13. 13. 📄パッケージ管理（pnpm workspace）
応用編 16 章
  1. 1. 📄AWSインフラ基礎
  2. 2. 📄AWS Budget Alert の設定（Month 5 Week 17）
  3. 3. 📄環境変数管理
  4. 4. 📄Bastion EC2 と SSH ProxyJump（Month 5 Week 18）
  5. 5. 📄CI/CD基礎
  6. 6. 📄ECR への Docker イメージ push と App EC2 デプロイ（Month 5 Week 19）
  7. 7. 📄テスト設計の基本
  8. 8. 📄CloudFront + S3 + ALB で公開する（Month 5 Week 20）
  9. 9. 📄CLAUDE.md・プロジェクト設定
  10. 10. 📄PR レビュー 5 観点ルーブリック（全 Week 共通）
  11. 11. 📄タスク分解・仕様の書き方
  12. 12. 📄Playwright で E2E テスト（Month 6 Week 22）
  13. 13. 📄生成コードのレビュー・デバッグの勘所
  14. 14. 📄Trivy で脆弱性スキャン（Month 6 Week 23）
  15. 15. 📄CloudWatch Logs の読み方と運用（Month 6 Week 23）
  16. 16. 📄PDF ポートフォリオの自動生成（Month 6 Week 24）