TCP/IP 4계층과 패킷의 여행

네트워크의 기본 질문

브라우저에 https://example.com을 입력하면 어떤 일이 벌어질까요? 서버에서 HTML이 돌아오기까지 데이터는 여러 계층을 거칩니다. 이 과정을 이해하려면 TCP/IP 모델 을 알아야 합니다.

TCP/IP는 인터넷 통신의 표준 프로토콜 스택입니다. OSI 7계층 모델이 이론적 참조 모델이라면, TCP/IP 4계층은 실제 인터넷이 동작하는 방식을 반영합니다.

TCP/IP 4계층

TCP/IP 모델은 네 개의 계층으로 구성됩니다. 각 계층은 독립적인 역할을 맡고, 바로 아래/위 계층과만 소통합니다.

각 계층이 하는 일을 간단히 정리하면 다음과 같습니다.

Application 계층 은 사용자가 직접 다루는 프로토콜입니다. 웹 브라우저는 HTTP로 요청을 만들고, 도메인 이름은 DNS로 IP 주소로 변환합니다.

Transport 계층은 데이터가 목적지에 정확하게 도착하도록 보장합니다. TCP는 연결 수립 (3-way handshake), 순서 보장, 재전송을 처리합니다. UDP는 이런 보장 없이 빠른 전송에 집중합니다.

Internet 계층은 IP 주소를 기반으로 패킷의 경로를 결정합니다. 라우터는 이 계층에서 동작하며, 패킷을 다음 홉으로 전달합니다.

Network Access 계층 은 실제 물리적 매체 (케이블, 무선)를 통해 비트를 전송합니다. MAC 주소로 같은 네트워크 내 장치를 식별합니다.

캡슐화와 역캡슐화

데이터가 송신 측에서 각 계층을 내려갈 때, 해당 계층의 헤더가 데이터 앞에 추가됩니다. 이것을 캡슐화(Encapsulation)라고 합니다. 수신 측에서는 반대로 각 계층의 헤더를 제거하며 올라갑니다. 이것이 역캡슐화 (Decapsulation)입니다.

송신 측 (캡슐화)

Application:   [HTTP Header] [Data]
Transport:     [TCP Header] [HTTP Header] [Data]
Internet:      [IP Header] [TCP Header] [HTTP Header] [Data]
Network:       [Frame Header] [IP Header] [TCP Header] [HTTP Header] [Data] [FCS]

수신 측 (역캡슐화) -- 위 과정을 역순으로 진행

각 계층을 거칠 때마다 데이터 단위의 이름이 바뀝니다.

• Application: 메시지 (Message)
• Transport: 세그먼트 (Segment), TCP 기준
• Internet: 패킷 (Packet)
• Network Access: 프레임 (Frame)

아래 시각화에서 데이터가 각 계층을 거치며 헤더가 추가/제거되는 과정을 단계별로 확인하세요.

브라우저에서 서버까지 패킷의 경로

https://example.com에 접속할 때 실제로 일어나는 일을 순서대로 살펴봅니다.

1. 브라우저가 DNS에 example.com의 IP 주소를 질의
2. DNS 응답: 93.184.216.34
3. TCP 3-way handshake (SYN -> SYN-ACK -> ACK)
4. TLS handshake (HTTPS인 경우)
5. HTTP GET / 요청 전송 (캡슐화)
6. 라우터들이 IP 주소를 보고 패킷을 서버까지 전달
7. 서버가 패킷을 수신하고 역캡슐화
8. 서버가 HTTP 200 OK + HTML 응답 (다시 캡슐화)
9. 클라이언트가 응답을 수신하고 역캡슐화
10. 브라우저가 HTML을 렌더링

이 과정에서 각 라우터는 Internet 계층까지만 확인 합니다. 라우터는 TCP 헤더나 HTTP 내용을 볼 필요가 없습니다. IP 주소만 보고 다음 홉을 결정하면 됩니다. 이것이 계층화의 핵심 장점입니다.

코드로 보는 패킷 구조

JavaScript에서 TCP/IP 패킷의 구조를 개념적으로 표현하면 다음과 같습니다.

// 각 계층이 추가하는 헤더를 객체로 표현
const httpMessage = {
  method: "GET",
  path: "/",
  headers: { Host: "example.com" },
  body: "",
};

const tcpSegment = {
  srcPort: 52431,        // 클라이언트의 임시 포트
  destPort: 443,         // HTTPS 포트
  sequenceNum: 1,
  ackNum: 0,
  flags: { SYN: false, ACK: false, FIN: false },
  payload: httpMessage,  // 상위 계층 데이터가 payload가 됨
};

const ipPacket = {
  version: 4,
  srcIP: "192.168.1.10",
  destIP: "93.184.216.34",
  ttl: 64,               // 라우터를 거칠 때마다 1씩 감소
  protocol: "TCP",
  payload: tcpSegment,
};

const ethernetFrame = {
  srcMAC: "AA:BB:CC:DD:EE:01",
  destMAC: "AA:BB:CC:DD:EE:02",  // 게이트웨이 라우터의 MAC
  type: "IPv4",
  payload: ipPacket,
  fcs: "0xABCD1234",     // 프레임 체크 시퀀스
};

중요한 점은 각 계층은 자기 헤더만 읽고 나머지는 payload로 취급 한다는 것입니다. 라우터는 ipPacket의 destIP만 보고, 그 안의 TCP나 HTTP 내용은 신경 쓰지 않습니다.

OSI 7계층과의 비교

TCP/IP 4계층과 자주 비교되는 OSI 7계층 모델은 ISO가 정의한 이론적 참조 모델입니다.

OSI 모델의 Application, Presentation, Session 세 계층이 TCP/IP에서는 하나의 Application 계층으로 통합됩니다. 마찬가지로 Data Link와 Physical이 Network Access로 합쳐집니다. 실무에서는 TCP/IP 모델을 기준으로 이야기하는 경우가 대부분입니다.

실무에서의 연결

프론트엔드 개발자가 TCP/IP 계층을 이해해야 하는 이유:

• 성능 디버깅 : Chrome DevTools의 Network 탭에서 보이는 DNS Lookup, TCP Connection, TLS Handshake 시간은 각각 다른 계층의 동작 시간입니다. 어느 계층에서 병목이 생기는지 파악할 수 있습니다.
• HTTP/2, HTTP/3 이해 : HTTP/2는 Transport 계층의 TCP 위에서 멀티플렉싱을 구현했고, HTTP/3는 TCP 대신 UDP 기반의 QUIC를 사용합니다. 왜 이런 변화가 필요했는지는 계층 구조를 알아야 이해할 수 있습니다.
• CDN과 로드밸런서 : L4 로드밸런서는 Transport 계층 (포트 번호)에서, L7 로드밸런서는 Application 계층 (URL 경로)에서 트래픽을 분배합니다. "L4", "L7"이 바로 OSI 모델의 계층 번호입니다.

다음 단계

이 글에서는 데이터가 네트워크를 이동하는 기본 구조를 살펴봤습니다. 다음 글에서는 Transport 계층의 핵심인 TCP의 연결 수립과 해제 , 그리고 신뢰성 보장 메커니즘을 깊이 있게 다루겠습니다.