TCP/IP 4계층 모델

OSI 7계층 모델은 네트워크를 이해하기 위한 참조 모델이지만, 실제 인터넷은 이 모델을 그대로 따르지 않습니다.

현실에서 인터넷의 동작을 설명하는 데 사용되는 것은 TCP/IP 4계층 모델입니다.

그렇다면 왜 OSI를 먼저 배웠을까요?

OSI 모델이 각 계층의 역할을 더 세밀하게 나누어 놓았기 때문에, 네트워크의 동작 원리를 이해하는 데는 OSI가 더 좋은 학습 도구입니다.

하지만 실제 프로토콜 스택을 설명할 때는 TCP/IP 모델이 현실에 훨씬 가깝습니다.

IETF의 인터넷 호스트 요구사항 문서에서도 인터넷 프로토콜 묶음은 응용, 전송, 인터넷, 링크 계층으로 설명됩니다.

즉 TCP/IP 모델은 시험용 분류표라기보다, 오늘날 장비와 운영체제가 실제로 프로토콜을 나누어 구현하는 기준에 가깝습니다.

OSI와 TCP/IP의 대응 관계

OSI의 5~7계층은 TCP/IP에서 별도 계층으로 강하게 분리되지 않고 응용 계층 중심으로 다루어집니다.

세션 유지, 데이터 표현, 암호화 같은 기능은 응용 프로토콜, 라이브러리, 전송 위 보안 계층이 함께 맡는 경우가 많습니다.

OSI의 1~2계층이 TCP/IP의 네트워크 인터페이스 계층으로 합쳐집니다.

물리적 전송과 프레이밍을 함께 다룹니다.

각 계층 상세

응용 계층 (Application Layer)

사용자가 직접 상호작용하는 계층입니다.

HTTP, DNS, SMTP 등 모든 응용 프로토콜이 여기에 속합니다.

개발자가 가장 많이 다루는 계층입니다.

fetch(), axios, curl 등은 모두 이 계층에서 동작합니다.

전송 계층 (Transport Layer)

프로세스 간 데이터 전달을 담당합니다.

TCP와 UDP가 핵심입니다.

import socket

# TCP 소켓 (연결형, 신뢰성)
tcp_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# UDP 소켓 (비연결형, 빠름)
udp_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# 개발자는 소켓 API를 통해 전송 계층에 접근
# 소켓 = 응용 계층과 전송 계층 사이의 인터페이스

QUIC은 UDP 위에서 동작하는 전송 프로토콜로, HTTP/3의 기반입니다.

흐름 제어가 있는 스트림, 낮은 지연의 연결 설정, 연결 마이그레이션, TLS 기반 보안을 함께 제공합니다.

인터넷 계층 (Internet Layer)

IP 프로토콜이 핵심이며, 서로 다른 네트워크 간의 라우팅을 담당합니다.

ARP는 IP 주소를 MAC 주소로 연결하지만, 실제로는 같은 링크에서 프레임을 보낼 준비를 돕는 링크 계층 지원 프로토콜로 보는 편이 더 정확합니다.

# IP 주소 확인
ip addr show

# 라우팅 테이블 확인
ip route show

# ICMP로 연결 확인
ping -c 4 8.8.8.8

# 경로 추적
traceroute 8.8.8.8

# ARP 테이블 확인 (IP → MAC 매핑)
arp -n

네트워크 인터페이스 계층 (Network Interface Layer)

물리적 전송과 프레이밍을 담당합니다.

이더넷, Wi-Fi가 대표적입니다.

현실에서 TCP/IP를 더 많이 쓰는 이유

가장 근본적인 이유는 순서가 반대였기 때문입니다.

OSI 모델은 먼저 이론을 정립하고, 그에 맞는 프로토콜을 만들겠다는 하향식(Top-down) 접근이었습니다.

반면 TCP/IP는 먼저 인터넷에서 실제로 동작하는 프로토콜을 만들고, 나중에 그것을 모델로 정리했다는 상향식(Bottom-up) 접근이었습니다.

아래 그림은 OSI와 TCP/IP를 우열 비율로 비교하지 않고, 어떤 질문에 어떤 모델을 쓰는지로 나눕니다.

OSI는 장애 위치와 책임 경계를 말할 때 유용하고, TCP/IP는 실제 IP, 포트, 라우팅, 소켓 상태를 확인할 때 더 직접적입니다.

인터넷이 폭발적으로 성장하는 동안 TCP/IP 프로토콜들은 이미 전 세계에서 사용되고 있었습니다.

OSI 표준이 완성되었을 때는 이미 TCP/IP 기반의 인터넷이 사실상의 표준(de facto standard)이 된 뒤였습니다.

데이터 흐름 예시

웹 브라우저에서 https://example.com에 접속할 때 각 계층에서 어떤 일이 일어나는지 추적해 봅시다.

아래 흐름은 이해를 위해 HTTP over TCP/TLS 경로를 기준으로 단순화한 예시입니다.

HTTP/3에서는 QUIC이 UDP 위에서 TLS 보안과 전송 기능을 함께 제공합니다.

"""Ethernet + IPv4 + TCP 기본 헤더 크기를 계산하여
   전체 프레임에서 최대 TCP payload 비율을 확인

   실제 HTTPS에서는 TCP payload 안에 TLS record가 들어간다.
"""

headers = {
    "이더넷 헤더": 14,
    "IP 헤더": 20,
    "TCP 헤더": 20,
    "FCS (트레일러)": 4,
}

total_overhead = sum(headers.values())
mtu = 1500  # 이더넷 MTU
max_payload = mtu - 20 - 20  # IP + TCP 헤더 제외
frame_total = mtu + 14 + 4   # 이더넷 헤더 + FCS 포함

print("=== 헤더 크기 ===")
for name, size in headers.items():
    print(f"  {name}: {size} bytes")

print(f"\n전체 프레임: {frame_total} bytes")
print(f"프로토콜 오버헤드: {total_overhead} bytes")
print(f"최대 페이로드: {max_payload} bytes")
print(f"데이터 효율: {max_payload/frame_total*100:.1f}%")

실무에서의 계층 참조

실무에서는 OSI와 TCP/IP를 혼용합니다.

대화할 때는 OSI 번호를 쓰면서, 실제 프로토콜은 TCP/IP 기준입니다.

다음 절에서는 이 계층들 사이에서 데이터가 실제로 어떻게 포장되고 전달되는지, 캡슐화와 역캡슐화를 살펴보겠습니다.

송신 측에서는 데이터가 전송 세그먼트, IP 패킷 또는 데이터그램, 링크 프레임으로 감싸지고, 수신 측에서는 역순으로 헤더를 확인하며 원래 데이터에 접근합니다.

TCP/IP 4계층 모델에서는 계층 위치, 주소/식별자, 캡처에서 보이는 신호를 확인합니다.