데이터가 화면에 도달하기까지의 여정: OSI, TCP/UDP, HTTP

개발#네트워크#http#인프라

원문을 번역하고 사내 발표용으로 정리한 글입니다. 예제 다이어그램과 실습 화면, 전체 설명은 원문에 있으니 함께 보시길 권합니다. 원문: How Data Travels the World to Reach Your Screen (deepintodev.com)

브라우저에 주소를 치고 엔터를 누르면 실제로 무슨 일이 일어나는지, 그 데이터가 어떻게 대양을 건너 내 노트북까지 오는지를 OSI 모델부터 HTTP/3까지 훑는 글입니다. 프론트엔드든 백엔드든 한 번은 정리해두면 좋은 내용이라 팀에 공유했습니다.

OSI 모델: 왜 계층이 필요한가

우리가 보내려는 건 결국 “원시 데이터”입니다. 이걸 네트워크로 보내려면 어디로 가야 하는지, 어떻게 가야 하는지를 담은 추가 정보(헤더와 트레일러)를 붙여야 합니다. OSI 모델의 각 계층이 하는 일이 대체로 이것입니다. 계층을 하나씩 내려가면서 데이터에 정보가 덧붙고, 이 단위를 PDU(Protocol Data Unit)라고 부릅니다.

브라우저에 10.0.0.3:80을 입력하면 브라우저가 그 문자열을 GET / HTTP/1.1 ...로 시작하는 요청 문자열로 바꾸고, 그 순간부터 OSI 모델이 동작하기 시작합니다.

요청이 내려가는 순서는 이렇습니다.

  • 7계층 응용 — HTTP 같은 프로토콜이 붙는 층. 사용자 데이터와 직접 만나는 유일한 계층이다. 이메일이면 SMTP처럼 목적에 따라 다른 프로토콜이 온다.
  • 6계층 표현 — 데이터 형식 변환, 압축, 암호화. HTTPS면 여기서 바이트 스트림을 암호화한다.
  • 5계층 세션 — 세션을 설정·유지·종료하고, 요청이 어느 세션에 속하는지 태그를 붙인다.
  • 4계층 전송 — 커진 바이트 스트림을 세그먼트로 쪼개고 포트 번호를 붙인다. 여기 프로토콜이 TCP와 UDP다.
  • 3계층 네트워크 — 세그먼트에 출발지·목적지 IP를 붙여 패킷으로 만들고, 최적 경로를 정한다(라우팅).
  • 2계층 데이터 링크 — 패킷을 프레임으로 쪼개고 목적지 MAC 주소를 붙인다. 같은 네트워크 안의 전달을 담당한다.
  • 1계층 물리 — 케이블과 스위치. 데이터가 비트 스트림이 되어 실제로 흐른다.

응답은 정확히 반대 방향으로 올라옵니다. 서버는 물리 계층에서 받아 응용 계층까지 올라오고, 거기서 우리가 보낸 요청을 원래 모습으로 되찾습니다.

text
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Connection: keep-alive
Cookie: session=abc123; user=jack

물리 계층에서 프레임은 같은 로컬 네트워크의 모든 장치로 뿌려지고, MAC 주소가 맞는 장치만 처리합니다. 뒤집어 말하면 공용 Wi-Fi에서는 같은 네트워크의 누구나 프레임을 들여다볼 수 있다는 뜻입니다. 암호화되지 않은 데이터가 위험한 이유가 여기 있습니다.

OSI와 TCP/IP는 어떻게 대응되나

OSI는 네트워크를 이해하기 위한 이론적 프레임워크이고, 실제 인터넷을 굴리는 건 4계층짜리 TCP/IP입니다. 대응은 이렇습니다.

  • 네트워크 인터페이스 ↔ 물리 + 데이터 링크
  • 인터넷 ↔ 네트워크
  • 전송 ↔ 전송
  • 응용 ↔ 세션 + 표현 + 응용

계층 수는 달라도 그 안에서 쓰이는 프로토콜은 동일합니다.

TCP와 UDP

가장 간단한 비유는 이렇습니다. TCP는 신중하게 쓴 편지입니다. 제대로 도착했는지 확인하고, 페이지가 빠지면 다시 보냅니다. UDP는 빠른 문자 메시지입니다. 분실 여부를 신경 쓰지 않고 그냥 보냅니다.

TCP는 신뢰성이 필요한 곳에 씁니다. 전달 보장, 순서 보장, 혼잡 제어가 들어 있고, 데이터를 보내기 전에 3-way 핸드셰이크로 연결을 맺습니다.

  1. SYN — 클라이언트가 연결을 요청한다
  2. SYN-ACK — 서버가 수락과 수신 확인을 함께 응답한다
  3. ACK — 클라이언트가 확인을 보내면 연결이 성립한다

대신 대가가 있습니다. 추가 검사 때문에 UDP보다 느리고, 패킷이 커지고, 서버가 연결 상태를 기억하므로 메모리를 씁니다(연결을 대량으로 열어 자원을 고갈시키는 것이 DDoS의 한 방식입니다).

UDP는 반대입니다. 연결 설정도 확인도 없어서 빠르고 가볍지만, 전달·순서·혼잡 제어가 전부 없습니다. FPS 게임이 대표적인 사용처입니다. 패킷 하나를 잃어도 곧 더 최신 상태가 도착하므로, 이미 낡은 스냅샷을 재전송하느라 시간을 쓰는 것보다 낫습니다.

정리하면, 신뢰성과 보안이 필요하면 TCP(웹, 이메일, 뱅킹), 속도와 낮은 지연이 필요하면 UDP(게임, 화상 통화, 라이브 스트리밍)입니다.

HTTP 요청과 응답의 구조

HTTP는 응용 계층 프로토콜이고, 인터넷의 거의 모든 동작은 요청-응답 주기를 따릅니다. 요청은 네 부분으로 이뤄집니다.

  1. 요청 라인 — 메서드(GET·POST·PUT·DELETE)와 URL 경로
  2. 헤더 — 콘텐츠 타입, 인증 토큰 같은 메타데이터. 로그인 상태를 서버에 알리는 것도 보통 여기다
  3. 본문 — 선택적. GET엔 보통 없고 POST·PUT에서 데이터를 실어 보낸다

응답도 상태 줄과 헤더, 본문으로 같은 구조입니다.

text
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 234
Connection: keep-alive
Cache-Control: max-age=3600

클라이언트는 브라우저만이 아닙니다. HTTP 요청을 보내는 JavaScript·Python 앱도 클라이언트입니다. 개발자도구 콘솔에서 fetch를 직접 날려보면 바로 확인됩니다.

브라우저에서 페이지 하나를 열면 요청이 하나만 나가지 않습니다. 먼저 HTML을 받고, 파싱하면서 CSS·JS·이미지·폰트 참조를 찾아 추가 요청을 자동으로 만듭니다.

HTTP는 TCP 위에서 어떻게 도나

HTTP 요청은 TCP 연결을 먼저 맺은 뒤 그 위로 흐릅니다. 연결 설정 → 요청 전송 → TCP가 세그먼트로 분할 → 신뢰성 있는 전달 → 서버에서 재조립 → 처리 → 응답 → 연결 유지 또는 종료의 순서입니다.

HTTPS면 여기에 한 단계가 더 붙습니다. TCP 연결이 맺어진 뒤 TLS 핸드셰이크로 암호화 채널을 만들고, 그 터널 안으로 HTTP가 흐릅니다. 핸드셰이크는 대략 이렇게 진행됩니다.

  1. Hello — 클라이언트가 지원 가능한 암호화 방식을 제시하고 서버가 하나를 고른다
  2. 인증서 교환 — 서버가 디지털 인증서를 보내고 클라이언트가 신뢰할 수 있는 기관이 발급했는지 확인한다
  3. 키 교환 — 비밀 키를 직접 주고받지 않고, 공개 키 암호를 써서 양쪽이 공유 비밀을 도출한다
  4. 세션 키 생성 — 양쪽이 각자 같은 세션 키를 만든다
  5. 완료 — 이후 모든 통신이 그 세션 키로 암호화된다

핵심은 실제 키가 네트워크를 건너지 않는다는 점입니다. 대화를 통째로 엿들어도 키를 알아낼 수 없습니다.

HTTP 버전은 왜 계속 바뀌었나

응답 첫 줄의 HTTP/1.1이 프로토콜 버전입니다. 개발자도구 네트워크 탭에서 열을 추가하면 요청마다 어떤 버전을 쓰는지 볼 수 있습니다(http/1.1, h2, h3).

  • HTTP/1.0 — 파일 하나를 받을 때마다 TCP 연결을 새로 맺고 닫았다. 서버 메모리를 아끼려던 선택이었지만, 웹이 이미지·비디오를 담기 시작하면서 TCP의 느린 시작 비용이 그대로 누적됐다.
  • HTTP/1.1 — Keep-Alive로 연결을 유지한다. 지금은 기본 동작이다. 연결은 서버 설정에 따라 타임아웃(Apache 5초, Nginx 75초 등)이나 최대 요청 수(보통 100개)로 닫힌다.
  • HTTP/2 — 멀티플렉싱. 하나의 TCP 연결로 여러 요청과 응답을 동시에 주고받는다. 1.1에서는 style.css가 느리면 뒤의 요청이 줄 서서 기다리지만, 2에서는 먼저 끝난 것부터 받는다. 여기에 HPACK 헤더 압축이 더해져, 반복되는 헤더를 매번 다시 보내는 대신 참조 번호로 대체하고 바뀐 것만 보낸다.
  • HTTP/3 — TCP를 버리고 UDP 기반의 QUIC을 쓴다. HTTP/2에서는 패킷 하나가 손실되면 나머지 통신이 함께 기다리지만, HTTP/3은 나머지가 계속 흐른다. 연결 설정도 한 번의 왕복으로 끝나고, 첫 바이트부터 암호화가 내장돼 있다.

정리

브라우저에 주소를 치는 것부터 화면에 픽셀이 찍히기까지, 데이터는 계층을 내려가며 옷을 껴입고 물리 매체를 건넌 뒤 반대편에서 하나씩 벗습니다. 그 과정에서 어떤 계층에 어떤 프로토콜이 붙는지, 그 프로토콜이 무엇을 보장하고 무엇을 포기하는지를 알면 성능 문제든 보안 문제든 어디를 봐야 할지가 훨씬 분명해집니다.

더 자세한 예제와 다이어그램, 실습 화면은 원문에 있으니 시간을 들여 한 번 읽어보시길 권합니다.