OSI 모델, 단순화

왜 "layer" 가 troubleshooting 을 가능하게 만드는가

전체 OSI 모델은 7 layer 인데, 실전 운영에선 4 개만 알면 돼. 그게 인터넷이 실제 쓰는 TCP/IP 모델에 깔끔하게 매핑돼. 문제가 어느 layer 에 사는지 알면 한 시간 추측이 5 분 fix 로 변해.

Layer	역할	프로토콜	어디 사는지
Application	앱이 진짜 원하는 것	HTTP, SSH, DNS, SMTP	네 소프트웨어
Transport	프로세스 간 신뢰 / 빠른 전달	TCP, UDP	OS 커널
Network	네트워크 간 패킷 라우팅	IP, ICMP	라우터, OS 커널
Physical/Link	선/공중파 위 비트	Ethernet, Wi-Fi, ARP	NIC, 스위치, 케이블

Encapsulation — 모든 패킷이 진짜로 뭔지

웹페이지 로드할 때 요청은 머신 떠나기 전 헤더로 layer 별로 감겨:

브라우저가 HTTP 요청 만듦: GET / HTTP/1.1\nHost: github.com — Application.
OS 가 TCP segment 로 감음, 출발/도착 포트 포함 — Transport.
OS 가 IP 패킷으로 감음, 출발/도착 IP 포함 — Network.
NIC 가 Ethernet frame 으로 감음, 출발/도착 MAC 포함, 선 위에 올림 — Link.

받는 쪽은 헤더를 역순으로 벗김 — de-encapsulation. 각 layer 는 자기 헤더만 신경 써.

Layered troubleshooting

Ping 안 돼? → Network layer (IP, routing, gateway).
Ping 되는데 포트 22 연결 안 돼? → Transport layer (방화벽 TCP 차단, 포트 닫힘).
연결되는데 앱이 에러? → Application layer (config, auth).
로컬 장치까지 안 돼? → Physical/Link (케이블 빠짐, Wi-Fi 다운).

Code

Layer 마다 점검·bash

# Physical/Link: is the interface even up?
ifconfig en0 | grep status

# Network: can we reach the gateway?
ping -c 3 $(route -n get default | awk '/gateway/ {print $2}')

# Network: can we reach the public internet?
ping -c 3 1.1.1.1

# Transport: is a specific port open?
nc -zv 192.168.1.100 22

# Application: does HTTP actually return something sane?
curl -I https://github.com

Exercise

네트워크에서 도달 못 하는 거 하나 골라 (말 안 듣는 프린터, 또는 일부러 가짜 IP 192.168.99.99 같은 거). Layer 따라 걸어 — ifconfig (link), ping gateway (network), ping target (network), nc -zv target port (transport), application 레벨 테스트 (application). 어느 layer 가 먼저 깨지는지 메모 — 그게 네 버그.