네트워크 OSI 7계층 완벽 가이드

OSI 7계층 전체 구조

계층	이름	역할	대표 기술
7	Application (응용)	사용자와 직접 상호작용	HTTP, WebSocket, MQTT, Kafka
6	Presentation (표현)	인코딩, 암호화, 압축	TLS/SSL, JSON, XML, Base64
5	Session (세션)	연결 수립/유지/종료	WebRTC (signaling), SSH 세션
4	Transport (전송)	신뢰성 있는 데이터 전달, 포트	TCP, UDP
3	Network (네트워크)	IP 라우팅, 논리 주소	IP, ICMP, ARP
2	Data Link (데이터 링크)	MAC 주소, 프레임 전송	이더넷, 스위치, Wi-Fi (802.11)
1	Physical (물리)	전기/광 신호 전송	케이블, 허브, NIC

Layer 1 — 물리 계층

전기/광/무선 신호로 비트(0,1)를 전송
장비: 케이블, 광섬유, NIC, 허브
허브: 들어온 신호를 모든 포트에 브로드캐스트 → 충돌 도메인 공유 → 현재 거의 사용 안 함

Layer 2 — 데이터 링크 계층

이더넷 프레임 구조

[ Preamble | Dest MAC (6B) | Src MAC (6B) | EtherType (2B) | Payload | FCS ]

스위치 (Switch)

MAC 주소 테이블 학습 → 해당 포트로만 프레임 전달
포트별 독립 충돌 도메인 → 허브 대비 효율적
동작 과정:
1. 프레임 수신 → 출발지 MAC을 테이블에 기록
2. 목적지 MAC이 테이블에 있으면 해당 포트로만 전달 (Unicast)
3. 없으면 전체 포트로 Flooding
L3 스위치: IP 라우팅 기능 포함 (라우터 + 스위치)

Layer 3 — 네트워크 계층

IP vs ICMP vs ARP

셋 다 Layer 3 근처에서 동작하지만 역할이 완전히 다르다.

프로토콜	역할
IP	패킷을 목적지까지 전달
ICMP	전달 과정의 오류/상태 보고
ARP	IP 주소 → MAC 주소 변환

IP (Internet Protocol)

패킷을 출발지 → 목적지까지 라우팅
비연결성: 연결 수립 없이 그냥 보냄
비신뢰성: 손실, 중복, 순서 뒤바뀜 보장 안 함
TCP/UDP가 IP 위에서 신뢰성을 보완

IP 헤더:
[ Version | TTL | Protocol | Src IP | Dst IP | ... ]

Protocol 필드:
  6  = TCP
  17 = UDP
  1  = ICMP

ICMP (Internet Control Message Protocol)

IP 통신 중 발생한 오류나 상태를 알리는 메시지 프로토콜
데이터 전송 용도가 아님, 진단/제어 목적
IP 위에서 동작 (Protocol = 1)

대표 메시지 타입

Type 0  — Echo Reply              (ping 응답)
Type 3  — Destination Unreachable (목적지 도달 불가)
Type 8  — Echo Request            (ping 요청)
Type 11 — Time Exceeded           (TTL 만료 → traceroute 원리)

ping 동작

A ──ICMP Echo Request (Type 8)──> B
A <─ICMP Echo Reply   (Type 0)─── B
→ 왕복 시간(RTT)으로 연결 상태 확인

traceroute 동작

TTL=1 패킷 전송 → 첫 번째 라우터에서 TTL 만료 → ICMP Time Exceeded 반환 → 라우터 IP 획득
TTL=2 패킷 전송 → 두 번째 라우터에서 TTL 만료 → ICMP Time Exceeded 반환
... 반복 → 경로 전체 파악

ARP (Address Resolution Protocol)

같은 네트워크(LAN) 안에서 IP → MAC 주소 변환
실제 이더넷 프레임 전송에는 MAC 주소가 필요하기 때문
Layer 2와 3의 경계에서 동작

동작 과정

A가 192.168.0.5의 MAC을 모를 때:

1. A → 브로드캐스트 (FF:FF:FF:FF:FF:FF)
   "192.168.0.5 MAC 주소 가진 사람 응답해" (ARP Request)

2. B (192.168.0.5) → A에게 유니캐스트
   "나야, MAC은 AA:BB:CC:DD:EE:FF" (ARP Reply)

3. A는 ARP 캐시에 저장 → 다음엔 브로드캐스트 없이 바로 전송

arp -a  # 현재 ARP 테이블 조회

핵심 차이 정리

IP    → "패킷을 어디로 보낼까" (라우팅/전달)
ICMP  → "전달하다 문제 생겼어" (오류 보고/진단)
ARP   → "이 IP의 MAC이 뭐야?" (주소 변환)

ping이 안 되면 → ICMP 차단 or IP 경로 문제
같은 LAN인데 안 되면 → ARP 문제 의심
다른 네트워크로 못 나가면 → IP 라우팅/게이트웨이 문제

Layer 4 — 전송 계층

TCP (Transmission Control Protocol)

핵심 특성

연결 지향, 신뢰성 보장 (재전송, 순서 보장)
흐름 제어 (Sliding Window), 혼잡 제어 (Slow Start, AIMD)

3-Way Handshake (연결 수립)

Client          Server
  |--- SYN ------->|   (Seq=x)
  |<-- SYN-ACK ----|   (Seq=y, Ack=x+1)
  |--- ACK ------->|   (Ack=y+1)

4-Way Handshake (연결 종료)

Client          Server
  |--- FIN ------->|
  |<-- ACK --------|
  |<-- FIN --------|
  |--- ACK ------->|

TCP 헤더

[ Src Port | Dst Port | Seq Number | Ack Number | Flags | Window Size | Checksum ]

UDP (User Datagram Protocol)

핵심 특성

비연결성, 신뢰성 없음, 헤더 8바이트로 오버헤드 최소
손실 감수하고 속도 우선

UDP 헤더

[ Src Port (2B) | Dst Port (2B) | Length (2B) | Checksum (2B) ]

TCP vs UDP

항목	TCP	UDP
연결	O (3-way)	X
신뢰성	O	X
순서 보장	O	X
속도	느림	빠름
오버헤드	큼 (20B~)	작음 (8B)
사용처	파일전송, 웹, Kafka	스트리밍, 게임, WebRTC 미디어

Layer 5~7 — 세션 / 표현 / 응용 계층

HTTP (HyperText Transfer Protocol)

HTTP/1.1

TCP 기반 요청/응답 모델, Keep-Alive
Head-of-Line Blocking: 앞 요청 완료 전까지 다음 대기

HTTP/2

하나의 TCP로 여러 스트림 병렬 처리 (멀티플렉싱)
헤더 압축 (HPACK), 서버 푸시
TCP 기반 → TCP HOL Blocking은 여전히 존재

HTTP/3

QUIC (UDP 기반) 사용 → TCP HOL Blocking 완전 해결
연결 수립 시간 단축 (0-RTT), TLS 1.3 내장

HTTP 메서드

GET    — 조회 (멱등, 캐시 가능)
POST   — 생성
PUT    — 전체 교체 (멱등)
PATCH  — 부분 수정
DELETE — 삭제 (멱등)
OPTIONS— CORS preflight

HTTP 상태 코드

2xx — 성공     : 200 OK, 201 Created, 204 No Content
3xx — 리다이렉트: 301 Moved, 302 Found, 304 Not Modified
4xx — 클라이언트: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx — 서버 오류 : 500 Internal Error, 502 Bad Gateway, 503 Service Unavailable

WebSocket (WS)

특성

HTTP Upgrade로 시작 → 이후 양방향 전이중(Full-Duplex) 통신
지속 연결, HTTP 헤더 반복 없음 → 낮은 오버헤드

연결 과정

1. Client → HTTP Upgrade 요청
   GET /chat HTTP/1.1
   Upgrade: websocket
   Sec-WebSocket-Key: dGhlIHNhbXBsZQ==

2. Server → 101 Switching Protocols
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3. 이후 WebSocket 프레임으로 양방향 통신

HTTP vs WebSocket

항목	HTTP	WebSocket
방향	단방향 (요청→응답)	양방향
연결	요청마다 새로	지속 연결
오버헤드	헤더 매번 반복	최초 1회
사용처	REST API	채팅, 실시간 알림, 협업

WebRTC (Web Real-Time Communication)

개요

브라우저 간 P2P 직접 통신 (서버 중계 최소화)
UDP 기반 (실시간성 우선)
음성, 영상, 데이터 채널 지원

프로토콜 스택

미디어:     MediaStream → SRTP → DTLS → UDP/ICE
데이터:     DataChannel → SCTP → DTLS → UDP/ICE

연결 수립 과정

Peer A              Signal Server           Peer B
  |── Offer SDP ──────────>|                 |
  |                        |── Offer SDP ───>|
  |                        |<─ Answer SDP ───|
  |<─ Answer SDP ──────────|                 |
  |                                          |
  |◄──── ICE Candidate 교환 (STUN/TURN) ────►|
  |◄══════════ P2P 직접 연결 성립 ═══════════►|

핵심 개념

SDP: 미디어 포맷, 코덱, 해상도 협상
ICE: NAT/방화벽 통과를 위한 연결 후보 탐색
STUN: 자신의 공인 IP/Port 파악
TURN: P2P 불가 시 중계 서버

ICE 연결 순서

1. STUN 서버에 요청 → 공인 IP/Port 획득
2. ICE Candidate 교환 (local, srflx, relay)
3. Connectivity Check → 가능한 후보 선택
4. DTLS Handshake → 암호화 키 교환
5. SRTP/SCTP로 미디어/데이터 전송

MQTT (Message Queuing Telemetry Transport)

개요

경량 Pub/Sub 메시징 프로토콜, TCP 기반 (헤더 최소 2바이트)
IoT, 저전력 디바이스 설계

구조

Publisher ──PUBLISH──> Broker ──DELIVER──> Subscriber
                    (토픽 관리/라우팅)

예: 온도센서 ──> /home/temperature ──> 대시보드

QoS 레벨

레벨	이름	설명
0	At most once	최대 1회, 손실 가능
1	At least once	최소 1회, 중복 가능
2	Exactly once	정확히 1회 (4-way handshake)

토픽 와일드카드

home/livingroom/temperature  — 단일 토픽
home/+/temperature           — + : 한 레벨 와일드카드
home/#                       — # : 이하 모든 레벨

주요 패킷

CONNECT / CONNACK  — 연결 수립
PUBLISH            — 메시지 발행
SUBSCRIBE          — 토픽 구독
PINGREQ            — Keep-Alive
DISCONNECT         — 연결 종료

Kafka

개요

분산 이벤트 스트리밍 플랫폼, TCP 기반 자체 바이너리 프로토콜
대용량 처리, 고가용성, 메시지 영속 저장

구조

Producer ──> Topic [Partition 0, 1, 2, ...] ──> Consumer Group
                         │
                      Broker
                         │
                  KRaft (메타데이터)

파티션 & 오프셋

Topic: "orders"
  Partition 0: [msg0][msg1][msg2][msg3] ...
                offset: 0    1    2    3
  Partition 1: [msg0][msg1] ...

Consumer는 오프셋을 직접 관리 → 재처리 가능

Consumer Group

같은 그룹: 파티션을 나눠서 병렬 처리
다른 그룹: 동일 토픽을 독립적으로 소비 (브로드캐스트 효과)

MQTT vs Kafka

항목	MQTT	Kafka
대상	IoT 디바이스	백엔드 서비스 간
저장	없음 (기본)	영속 저장
처리량	낮음	초당 수백만
재처리	불가	오프셋으로 가능
복잡도	낮음	높음

전체 프로토콜 계층 정리

Layer 7  │ HTTP/1.1  HTTP/2  HTTP/3  WebSocket  MQTT  Kafka  WebRTC(SDP/ICE)
Layer 6  │ TLS/SSL  DTLS  JSON  Protobuf  HPACK
Layer 5  │ WebRTC(ICE 협상)  SSH 세션
Layer 4  │      TCP                        UDP
         │ HTTP, WS, MQTT, Kafka       WebRTC 미디어, DNS, QUIC(HTTP/3)
Layer 3  │              IP (IPv4 / IPv6)
Layer 2  │     이더넷 프레임, Wi-Fi, 스위치 (MAC 테이블)
Layer 1  │     케이블, 광섬유, 무선 신호, 허브

실무 선택 가이드

요구사항	추천 기술
REST API, 웹 페이지	HTTP/2 + HTTPS
실시간 채팅, 알림	WebSocket
브라우저 P2P 화상통화	WebRTC
IoT 센서 데이터 수집	MQTT (QoS 1~2)
MSA 서비스 간 이벤트	Kafka
DNS 조회, 게임	UDP
파일 전송, 결제	TCP
고성능 HTTP	HTTP/3 (QUIC)

자주 헷갈리는 포인트

Polling vs SSE vs WebSocket

Polling:   Client ──요청──> Server (매번 반복)         → 낭비 심함
Long Poll: Client ──요청──> Server (응답 대기 후 재요청) → 개선됐지만 비효율
SSE:       Client <──스트림── Server (서버→클라이언트 단방향)
WebSocket: Client <────────> Server (양방향 지속 연결)  → 가장 효율적

WebRTC가 UDP를 쓰는 이유

영상통화는 1프레임 손실 < 1초 지연 → 손실 감수
TCP 재전송 대기가 오히려 품질 저하
SRTP로 보안, RTCP로 품질 제어를 UDP 위에서 직접 구현

MQTT vs Kafka 선택 기준

디바이스 → 서버, 경량, IoT → MQTT
서버 → 서버, 대용량, 재처리 필요 → Kafka

TCP vs UDP 선택 기준

데이터 무결성 > 속도 → TCP
속도 > 완벽한 무결성 → UDP (애플리케이션 레벨에서 보완 가능)

네트워크 7계층 가이드(예시포함)