TCP/IP（インターネットの基礎）

なぜ「層」で分けるのか

通信には「ケーブルに電気を流す」から「Webページを表示する」まで膨大な仕事があります。これを1つの巨大な仕組みで作ると、Wi-Fiが光ファイバに変わるたびにブラウザまで作り直す羽目になります。

そこで TCP/IP は仕事を層に分け、層と層の間だけを決まった形でつなぎます。すると、

下の層を差し替えても上は無関係（有線→Wi-Fi に変わっても HTTP は変えなくていい）
各層は隣の層だけ気にすればよい（自分の担当に集中できる）
問題の切り分けが楽（「IPは届くが TCP が張れない」のように層で考えられる）

TCP/IP の4層モデル

TCP/IP は下から リンク層 → インターネット層 → トランスポート層 → アプリケーション層 の4層で考えます。下の層ほど物理に近く、上の層ほど人間のアプリに近づきます。

層	役割（何をする係か）	代表例	宛先の単位
アプリケーション層	アプリ同士の会話のルール	HTTP / DNS / TLS / SMTP	—
トランスポート層	中身を“どう届けるか”（確実 or 高速）	TCP / UDP	ポート番号
インターネット層	“どこへ・どの道で”届けるか	IP / ICMP	IPアドレス
リンク層	隣の機器まで実際に電気/電波で運ぶ	Ethernet / Wi-Fi	MACアドレス

OSI参照モデルとの対応

教科書でおなじみの OSI 7層 は、TCP/IP の4層を細かく分けた“地図”です。実際の通信は TCP/IP 4層で動き、OSI は議論や切り分けの共通言語として使います。詳しくは /network/osi/ を参照。

各層は何をしているか

リンク層：同じネットワーク内で、隣の機器（ルータやスイッチ）まで フレーム を運ぶ。宛先は MACアドレス。届く範囲はそのLANの中だけ。
インターネット層：IPアドレス を使って、LANを越えて世界中の相手まで パケット を届ける。途中の経路選び（ルーティング）もここ。
トランスポート層：相手機器の中の どのアプリ宛てか を ポート番号 で区別し、確実に届ける（TCP） か 速さ優先（UDP） かを選ぶ。
アプリケーション層：HTTP や DNS など、アプリ同士の会話の文法 を決める。私たちが普段「通信」と呼ぶものの大半はここ。

IP とルーティング（住所と道順）

インターネット層の主役が IP（Internet Protocol） です。すべての機器に IPアドレス という住所を割り当て、データを パケット に分けて送ります。

ポイントは、IP は ベストエフォート（届くよう最善は尽くすが保証はしない）であること。届かない・順序が入れ替わる・重複することもあり得ます。その穴を埋めるのが上のトランスポート層（TCP）です。

宛先が別のネットワークにいる場合、パケットは ルータ から ルータ へとバケツリレーされます。各ルータは ルーティングテーブル（経路表）を見て「次にどのルータへ渡すか（next hop）」を決めます。これを ルーティング と呼びます。

IPアドレスは“機器”ではなく“接続点”につく

IPアドレスはネットワーク上の 位置（接続点） を表すため、機器が別のネットワークへ移ると変わります。一方 MACアドレスは機器(NIC)に固定。「IPは住所、MACは機器の名札」と覚えると、NAT や DHCP の話が一気に腑に落ちます。アドレスの読み方は /network/ip-subnet/ へ。

カプセル化（データを“包んで”運ぶ）

TCP/IP の肝が カプセル化（encapsulation） です。送信時、データは上の層から下の層へ渡されるたびに、その層の ヘッダ で包まれていきます。

アプリが送りたい データ（例: HTTPリクエスト）
トランスポート層が TCPヘッダ を付ける（→ セグメント）。ここに送信元/宛先 ポート が入る
インターネット層が IPヘッダ を付ける（→ パケット）。ここに送信元/宛先 IP が入る
リンク層が イーサネットヘッダ を付ける（→ フレーム）。ここに MAC が入る

受信側はこれを 逆順に剥がす（デカプセル化）だけ。封筒を二重三重にして送り、相手が外側から開けていくイメージです。各層は 自分のヘッダだけ を読み、中身（上位層のデータ）には踏み込みません。

“どの単位”で呼ぶかは層で変わる

同じデータでも、層によって呼び名が変わります：アプリ層の メッセージ → トランスポート層の セグメント（TCP）/ データグラム（UDP） → インターネット層の パケット → リンク層の フレーム。面接やトラブル時に層を取り違えると話が噛み合わなくなる定番のひっかけです。

TCP と UDP（確実 vs 高速）

トランスポート層には性格の違う2つがあり、用途で選びます。

観点	TCP	UDP
接続	事前に確立（3ウェイハンドシェイク）	なし（いきなり送る）
信頼性	再送・順序保証・重複排除あり	保証なし（落ちたら落ちたまま）
速さ/オーバーヘッド	確実だが重い	軽くて速い・低遅延
向く用途	Web・メール・ファイル転送	DNS・動画/音声・ゲーム

TCP は通信開始時に 3ウェイハンドシェイク（SYN → SYN/ACK → ACK） で握手してから、欠けたデータを再送し順序を整えて届けます。UDP は握手も再送もせず投げっぱなしで、その分 軽くて速い。詳しい比較は /network/tcp-udp/ を参照。

DNS・HTTP との関係（全部つながっている）

普段使う DNS / HTTP / TLS は、すべて アプリケーション層 に乗り、下を TCP/IP が支えています。https://example.com を開くときの流れで一気通貫させると：

DNS で example.com を IPアドレスに変換（多くは UDP）→ /network/dns/
その IP 宛てに TCP で接続を確立（3ウェイハンドシェイク）
その上で TLS ハンドシェイク（暗号化の準備）→ /network/tls/
ようやく HTTP リクエストを送ってページを取得 → /network/http/

つまり HTTP は「IP が住所で運び、TCP が確実に届け、DNS が住所を教えてくれる」土台の上で初めて成立します。

つまずきポイント

「IPだけで通信が成り立つ」は誤解：IP は届くだけで信頼性は無い。確実さは TCP、宛先アプリの区別は ポート が担う
TCP/IP と OSI を混同しがち：実装は TCP/IP の4層、OSI は説明用の7層モデル。同じものを別の粒度で見ているだけ
localhost(127.0.0.1) は自分自身：外に出ずループバックで返るため、疎通確認の最初の一歩に使える
切り分けは下の層から：「LAN内は届く？(ping)」→「外のIPは届く？」→「ポートは開いてる？」→「アプリは応答する？」の順が定石

ハンズオン

# 相手まで IP パケットが届くか（インターネット層の疎通確認）
ping example.com

# どのルータを経由しているか経路を辿る（ルーティングの可視化）
traceroute example.com      # Windows は tracert example.com

# TCP の接続状態とポートを一覧（LISTEN/ESTABLISHED を確認）
netstat -ano                # Linux なら ss -tan

# 指定ポートへ TCP 接続できるか（443=HTTPS が開いているか）
curl -v https://example.com