技術書を読んでいると、疑問は点々と生まれる。それらを線でつなぎ、面として組み直してから、備忘録のログにして残す。思いのほか便利そうなので、試しに実行してみる。
ゴール
- L3/L4/L7が混ざらない
- ICMP/TCP/UDP/HTTPを「何を解くか」で説明できる
- “ハンドシェイク”がどこか迷わない
- Linuxで層ごとに検証できる（現場で使える）
0. 略語辞書
- IP: Internet Protocol
- ICMP: Internet Control Message Protocol
- TCP: Transmission Control Protocol
- UDP: User Datagram Protocol
- HTTP: Hypertext Transfer Protocol
- HTTPS: Hypertext Transfer Protocol Secure（HTTP + TLS）
- TLS: Transport Layer Security
- DNS: Domain Name System
- MTU: Maximum Transmission Unit
- TTL: Time To Live
- SNI: Server Name Indication（TLSでどのドメイン宛かを示す）
1. 最上位の全体像：通信は「配送」と「会話」に分かれる
ネットワークを理解するイメージ。
- 配送（Transport/Delivery）：どこへ・どう届けるか
- 会話（Conversation/Semantics）：届いた後に何を意味するか
OSI層は、ざっくり言うと
- L3/L4：配送を分解して扱う
-
L7：会話（意味）を扱う
という役割分担。
L7も通信。ただし“回線の話”ではなく 意味の通信。
注釈（混乱点）
Q.「アプリケーション層は通信じゃない気がする」
A. それは自然。L7になると「運ぶ」より「意味（API/操作/契約）」が主役になるから、脳内カテゴリが“通信”から外れやすい。
2. もう一段深い骨格：「点（ノード）」が層ごとに変わる
L3（IP）：点＝ホスト（機械）
- 宛先：
IPアドレス - 問い：「どの機械へ届ける？」
L4（TCP/UDP）：点＝プロセス（ポート）
- 宛先：
IP:Port - 問い：「その機械のどのアプリへ届ける？」
L7（HTTPなど）：点＝意味の宛先（資源/操作）
- 宛先：
URL/Host/Path/Methodなど - 問い：「そのアプリに何をしてほしい？」
「点」が 機械 → ポート → 意味 と変わる。
だからL7を同じ“通信”として感じにくい。
3. 4プロトコルを「存在理由」で理解する（暗記禁止ゾーン）
ここからは “機能の羅列”ではなく、何の問題を解くためにあるかで押さえる。
3.1 ICMP：配送（IP）の「状態通知・診断」をする
ICMP = Internet Control Message Protocol
IP配送は失敗することがある。そこで 失敗理由や状態を知らせるのがICMP。
- 到達できない（Destination Unreachable）
- 経路の途中でTTLが切れた（Time Exceeded → traceroute）
- MTUが大きすぎて通らない（Fragmentation Needed）
直感：ICMPは「配送の不在票・理由メモ」。
よくある誤解（厚み）
Q.「ICMPってデータ運ぶの？」
A. 運ばない。データ本体の通行を助ける“通知/診断”。
3.2 TCP：信頼できる“通信路”を作る
TCP = Transmission Control Protocol
IPの上で「ちゃんと届く」を作る。
- 再送
- 順序整列
- 重複排除
- フロー制御
- 輻輳制御
TCPハンドシェイクはどこ？
L4（TCP）。接続の前提（状態/番号）を合わせるために
SYN → SYN/ACK → ACK を行う。
直感：TCPは「受領印付きの宅配便」。握手は「契約開始」。
3.3 UDP：軽く・速く（低オーバーヘッド）を優先する
UDP = User Datagram Protocol
UDPは「やらない」ことで軽い。
- 接続確立なし（握手なし）
- 再送なし
- 順序保証なし
- 状態管理ほぼなし
- ヘッダが小さい（UDP 8B）
注釈（混乱点）
Q.「低オーバーヘッドって結局なに？」
A. 余計な制御（握手・ACK・再送・状態管理）が少ない＝軽い。
CPU/メモリ/遅延/制御パケットが減る、という意味。
注釈（あなたの混乱点）
Q.「アプリ側で好きな設計＝上で信頼性を実装って？」
A. UDPは素の配送なので、必要ならアプリが上に載せられる。
例：シーケンス番号、ACK、再送、重複排除、レート制御…
つまり「TCP相当を目的に合わせて“部分的に”自作できる」。
直感イメージ：UDPは「ハガキ」。必要なら上で“再配達ルール”を自作できる。
3.4 HTTP：意味の会話（注文票）を統一する
HTTP = Hypertext Transfer Protocol
名前はハイパーテキスト由来だが、本質は
アプリ同士が“何をしてほしいか”を統一フォーマットでやり取りする会話規約
- Method（GET/POST…）
- URI/Path（対象）
- Header（条件/メタ）
- Status（結果）
- Body（中身：HTML/JSON/画像…何でも）
注釈（混乱点）
Q.「HTTPってHTMLの転送の話？」
A. 起源はそう。でも今は “Web/APIの会話プロトコル”。HTML以外も運ぶ。
4. “ハンドシェイク”の全体像（層をまたぐ概念）
ハンドシェイクは層名ではなく、前提をすり合わせる手順の総称。
- TCPハンドシェイク：L4（接続開始）
- TLSハンドシェイク：実務上L5〜L6（暗号・証明書・鍵交換）
- （参考）QUIC/HTTP3：UDP上で接続＋TLSを内包
実務の見方：
TCPはOKでもTLSで落ちる、TLSはOKでもHTTPで403…みたいに分解できる。
5. Linuxで検証する：層ごとの最短セット
「エンジニアとして最低限」＋「現場で刺さる」だけ。
5.1 DNS（L7）
dig +short example.comdig example.com Adig @1.1.1.1 example.comdig +trace example.com
5.2 L3（疎通/経路/MTU）
ping -c 5 -n example.com-
traceroute -T -p 443 example.com（TCPで経路） -
tracepath example.com（MTUも見やすい）
5.3 L4（ポート）
nc -vz example.com 443-
ss -lntp（待受） -
ss -antp（状態）
5.4 TLS
openssl s_client -connect example.com:443 -servername example.com
5.5 HTTP/HTTPS（最重要）
curl -I https://example.comcurl -v https://example.comcurl -L https://example.com-
curl --resolve example.com:443:203.0.113.10 https://example.com（DNS無視でIP直叩き）
遅延分解：
curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://example.com
6. 最短Runbook：困ったらこの順で潰す
- DNS：
dig +short - 経路：
traceroute -T -p 443 - ポート：
nc -vz host 443 - TLS/HTTP：
curl -v - 証明書：
openssl s_client
7. 一発で思い出す短文（定着用）
- IP：ホストへ運ぶ
- ICMP：運べなかった理由を知らせる
- TCP：ちゃんと届く道を作る（握手で前提同期）
- UDP：軽い配送。必要なら上に機能を載せる
- HTTP：意味の会話（注文票）
- TLS：会話を安全にする（暗号・証明書の握手）