Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

6장. 등기 택배와 전단지

“TCP, UDP, 포트, 방화벽”

이번 장에서 알게 될 것

  • 인터넷에서 데이터가 빠짐없이 도착하는 원리
  • 게임에서 “핑이 높다“는 것이 정확히 무슨 뜻인지
  • 하나의 서버에서 웹, 메일, 게임이 동시에 돌아가는 비밀
  • 카페 WiFi에서 남의 페이스북에 로그인할 수 있었던 시절

치킨 주문 여정: 데이터가 출발했다

DNS로 배달의민족 서버의 주소를 찾았습니다. 라우터들의 릴레이를 타고 데이터가 출발했습니다. 그런데 이 데이터가 정말로 도착할까요? 중간에 사라지면? 순서가 뒤바뀌면? 절반만 도착하면?

인터넷은 생각보다 불안정하다

5장에서 데이터가 라우터를 한 다리씩 거쳐 이동한다고 했습니다. 그 과정에서 데이터는 작은 조각으로 쪼개져서 보내집니다. 이 조각을 패킷(Packet) 이라고 합니다.

문제는 이 패킷이 언제나 안전하게 도착하는 것이 아니라는 점입니다. 네트워크가 혼잡하면 패킷이 버려질 수 있고, 다른 경로로 우회하면 순서가 뒤바뀔 수도 있습니다. 100개의 패킷을 보냈는데 98개만 도착하는 일은 흔합니다.

그래서 인터넷에는 두 가지 전송 방식이 있습니다. 하나는 느리더라도 확실하게 보내는 방식이고, 다른 하나는 빠르지만 보장은 없는 방식입니다.

택배로 비유하면 이렇습니다. 등기 택배와 전단지입니다.

TCP: 등기 택배

TCP(Transmission Control Protocol) 는 인터넷에서 가장 널리 쓰이는 전송 방식입니다.

등기 택배를 떠올려 보겠습니다. 등기 택배는 보내는 사람이 발송하고, 받는 사람이 수령 확인 서명을 합니다. 중간에 분실되면 재발송합니다. 느리지만 확실합니다.

TCP가 바로 이 방식입니다.

[그림 6-1] TCP의 특성

  TCP의 특성:
  ✅ 순서 보장     패킷이 순서대로 도착
  ✅ 재전송        유실되면 다시 보냄
  ✅ 흐름 제어     받는 쪽이 처리할 수 있는 속도로 보냄
  ✅ 혼잡 제어     네트워크가 막히면 속도를 줄임
  ❌ 상대적으로 느림  위 기능들의 대가

웹 브라우징, 이메일, 파일 다운로드 — “정확하게 도착해야 하는 것” 은 전부 TCP를 사용합니다. 여러분이 배달앱에서 치킨을 검색할 때, 그 검색 요청과 결과도 TCP로 전송됩니다. 메뉴 이름이 한 글자라도 빠지면 안 되니까요.

3-way Handshake: 통화 시작 전 “여보세요”

TCP 통신을 시작하기 전에는 반드시 연결 설정 과정을 거칩니다. 전화를 걸었을 때 “여보세요?“를 주고받는 것과 비슷합니다.

[그림 6-2] TCP 3-way Handshake

  클라이언트 (내 폰)                    서버 (배민 서버)
      │                                    │
      │── SYN ───────────────────────────→│  "여보세요? 통화 가능?"
      │                                    │
      │←── SYN-ACK ──────────────────────│  "네 여보세요! 들려요"
      │                                    │
      │── ACK ───────────────────────────→│  "네, 잘 들립니다!"
      │                                    │
      │     ← 연결 수립 완료 →               │
      │                                    │
      │── 데이터 전송 시작 ──────────────→│

세 번 왕복합니다. 그래서 3-way Handshake1라고 합니다.

왜 세 번이나 왕복할까요? 양쪽 모두 “보내기“와 “받기“가 가능한지 확인하기 위해서입니다. 첫 번째로 클라이언트가 보낼 수 있는지, 두 번째로 서버가 보내고 받을 수 있는지, 세 번째로 클라이언트가 받을 수 있는지. 이 과정이 끝나야 비로소 데이터 전송이 시작됩니다.

전화를 걸었는데 상대가 “여보세요?“라고 안 하면, 연결이 안 된 걸로 판단하는 것과 같습니다.

슬로우 스타트: 다운로드가 처음에 느린 이유

파일을 다운로드할 때 처음에 느리다가 점점 빨라지는 걸 느낀 적 있을 겁니다.

[그림 6-3] TCP 슬로우 스타트

  다운로드 속도
   ↑
   │                          ■■■■■■■■ (최대 속도)
   │                    ■■■■■
   │               ■■■■
   │          ■■■
   │      ■■
   │    ■
   │  ■
   │■
   └──────────────────────────→ 시간

이것이 TCP의 슬로우 스타트(Slow Start) 입니다. 처음에는 패킷 1개를 보냅니다. 잘 도착하면 2개, 또 잘 도착하면 4개, 8개… 지수적으로 늘려갑니다.

처음부터 최대 속도로 쏟아부으면 네트워크가 감당 못 할 수 있습니다. 그래서 천천히 시작해서 “이 네트워크가 얼마나 버틸 수 있는지” 탐색하는 겁니다. 중간에 패킷 유실이 감지되면 속도를 확 줄이고 다시 천천히 올립니다.

고속도로에 진입할 때 서행으로 시작해서 점점 가속하는 것과 비슷합니다. 갑자기 최고 속도로 끼어들면 사고가 나니까요.

UDP: 전단지

이번에는 전단지를 생각해 보겠습니다. 전단지는 사람들에게 뿌리기만 합니다. 누가 받았는지 확인하지 않고, 받지 못한 사람에게 다시 돌아가서 주지도 않습니다. 빠르고 가볍지만, 전부 도착한다는 보장은 없습니다.

UDP(User Datagram Protocol) 가 이 방식입니다.

[그림 6-4] UDP의 특성

  UDP의 특성:
  ✅ 빠름          연결 설정 없음, 확인 없음
  ✅ 실시간성       지연 최소
  ❌ 순서 보장 안 됨
  ❌ 유실되어도 재전송 안 함

UDP는 어디에 쓸까요? “1초 전 데이터보다 지금 데이터가 중요한 것” 에 씁니다. 온라인 게임, 영상 통화, 라이브 스트리밍이 대표적입니다.

왜 게임은 UDP를 쓸까?

롤이나 발로란트 같은 게임에서 “핑이 높다“는 말을 들어봤을 겁니다. 핑(ping)은 데이터가 서버에 갔다 돌아오는 시간입니다. 이 게임들이 UDP를 사용하는 이유를 보면 핑의 중요성이 이해됩니다.

TCP로 게임을 만든다고 가정해 보겠습니다.

  TCP로 게임을 만들면:

  서버: "적이 좌표 (10, 20)에 있어"
  패킷 유실!
  서버: "...응답이 없네, 재전송"  (50ms 대기)
  서버: "적이 (10, 20)에 있어"   (재전송)

  → 그사이 적은 이미 (50, 80)으로 이동
  → 50ms 전의 오래된 위치를 받음
  → 캐릭터가 순간이동하는 것처럼 보임

  UDP로 게임을 만들면:

  서버: "적이 (10, 20)에 있어"
  패킷 유실!
  서버: "적이 (30, 40)에 있어"   (다음 프레임, 새 데이터)
  서버: "적이 (50, 80)에 있어"   (또 다음 프레임)

  → 유실된 데이터는 무시하고 최신 데이터만 반영
  → 부드러운 이동

게임에서는 과거 데이터를 정확히 받는 것보다, 최신 데이터를 빨리 받는 것이 중요합니다. 0.05초 전 적의 위치를 정확히 알아봤자, 적은 이미 움직였으니까요.

영상 통화도 마찬가지입니다. 통화 중에 “여보…” “세…” 이렇게 끊기는 현상은 UDP 패킷이 유실된 것입니다. 유실된 음성을 재전송하면 더 지연되니까, 버리고 다음 음성을 재생합니다.

핑과 물리적 거리

게임에서의 핑은 곧 물리적 거리입니다. 빛의 속도에도 한계가 있기 때문입니다.

  서울 → 도쿄 서버:     약 30ms
  서울 → 미국 서부 서버:  약 130ms
  서울 → 유럽 서버:      약 250ms

  10~30ms:   매우 쾌적
  50~80ms:   보통
  100ms 이상: 렉이 느껴짐
  200ms 이상: 플레이 어려움

한국 서버에서 게임하면 핑이 낮고, 북미 서버에 접속하면 핑이 높은 이유입니다. 소프트웨어로 해결할 수 없는, 물리 법칙의 한계입니다. 4장에서 이야기한 해저케이블의 길이가 여기서도 영향을 줍니다.

TCP vs UDP: 한눈에 비교

[그림 6-5] TCP와 UDP의 비교

  ┌──────────────┬─────────────────┬─────────────────┐
  │              │ TCP (등기 택배)   │ UDP (전단지)      │
  ├──────────────┼─────────────────┼─────────────────┤
  │ 연결 설정     │ 필요 (3-way)     │ 불필요            │
  │ 순서 보장     │ O               │ X               │
  │ 재전송       │ O (유실 시)       │ X               │
  │ 속도         │ 상대적으로 느림   │ 빠름             │
  │ 대표 사용처   │ 웹, 이메일, 파일  │ 게임, 영상통화    │
  │ 비유         │ "확실하지만 느림" │ "빠르지만 대충"   │
  └──────────────┴─────────────────┴─────────────────┘

배달앱에서 치킨을 주문하는 과정은 TCP입니다. 주문 데이터가 한 글자라도 빠지면 안 되니까요. 하지만 배달원의 실시간 위치를 지도에 표시하는 것은 UDP에 가깝습니다. 0.5초 전 위치보다 지금 위치가 중요하니까요.

포트: 같은 건물, 다른 창구

5장에서 IP 주소를 “건물 주소“에 비유했습니다. 그런데 하나의 서버(건물)에서는 웹 서비스, 이메일, 파일 전송, 데이터베이스 등 여러 프로그램이 동시에 돌아갑니다.

시청 민원실을 떠올려 보겠습니다. 같은 건물이지만 1번 창구는 주민등록, 2번 창구는 세금, 3번 창구는 인감증명을 처리합니다. 서버도 마찬가지입니다. 같은 IP 주소에서 여러 서비스가 돌아가고, 이것을 구분하는 것이 포트(Port) 번호 — 창구 번호입니다.

[그림 6-6] 포트 번호의 구조

  IP 주소  = 건물 주소      203.0.113.50
  포트 번호 = 창구 번호       :443

  합치면: 203.0.113.50:443

  같은 건물(서버)의 서로 다른 창구(포트):
  ┌────────────────────────────────────┐
  │         서버 (203.0.113.50)         │
  │                                    │
  │   :80  → 웹 서비스 (HTTP)           │
  │   :443 → 웹 서비스 (HTTPS, 암호화)  │
  │   :22  → 원격 접속 (SSH)            │
  │   :25  → 이메일 전송 (SMTP)         │
  │   :3306 → 데이터베이스 (MySQL)       │
  └────────────────────────────────────┘

브라우저에서 웹사이트에 접속할 때, 주소창에는 baemin.com만 보이지만 실제로는 baemin.com:443으로 접속하고 있습니다. 브라우저가 HTTPS의 기본 포트인 443을 자동으로 붙여주는 겁니다.

왜 포트는 65535개까지인가?

TCP와 UDP 패킷의 헤더2에서 포트 번호는 16비트로 저장됩니다. 2^16 = 65,536. 0번은 예약이니 1번부터 65535번까지 사용 가능합니다.

  포트 범위:
  0 ~ 1023:       잘 알려진 포트 (Well-Known Ports)
                   HTTP(80), HTTPS(443), SSH(22) 등
                   시스템이 예약해 둔 번호

  1024 ~ 49151:    등록된 포트 (Registered Ports)
                   MySQL(3306), PostgreSQL(5432) 등

  49152 ~ 65535:   동적 포트 (Dynamic Ports)
                   운영체제가 임시로 할당하는 번호

방화벽: 건물 경비실

포트가 창구 번호라면, 방화벽(Firewall) 은 건물 입구의 경비실입니다.

[그림 6-7] 방화벽 규칙 구조

  ┌─────────────────────────────────────────┐
  │              방화벽 규칙                   │
  │                                         │
  │  ✅ 허용: 포트 80, 443 (웹)  ← "택배 OK" │
  │  ✅ 허용: 포트 22 (원격 접속, 특정 IP만)   │
  │  ❌ 차단: 포트 3306 (DB)  ← "외부 접근 금지"│
  │  ❌ 차단: 나머지 전부     ← "기본 거부"     │
  └─────────────────────────────────────────┘

경비실에서 택배(웹 요청)는 통과시키고, 등록된 방문자(허가된 IP)도 통과시키지만, 신원 불명(알 수 없는 포트로의 접근)은 차단합니다.

여기서 중요한 개념이 있습니다. 방화벽은 내가 먼저 요청한 것의 응답은 허용합니다. 내가 구글에 접속 요청을 보냈으면, 구글에서 오는 응답은 통과시킵니다. 하지만 외부에서 아무 요청 없이 먼저 들어오는 것은 차단합니다.

윈도우에서 “이 앱이 네트워크에 액세스하는 것을 허용하시겠습니까?” 팝업이 뜨는 것, 그것이 방화벽입니다.

VPN: 암호화된 전용 터널

카페 WiFi에서 인터넷을 하면, 같은 네트워크에 있는 사람이 데이터를 엿볼 수 있습니다. 공유기를 지나가는 모든 데이터가 같은 네트워크를 거치기 때문입니다.

이 문제를 해결하는 것이 VPN(Virtual Private Network) 입니다.

[그림 6-8] VPN 동작 원리

  VPN 없이:
  내 폰 → [데이터] → 카페 WiFi → ISP → 인터넷 → 서버
                      ↑
                    여기서 엿볼 수 있음

  VPN 사용:
  내 폰 → [암호화] → 카페 WiFi → ISP → [암호화 터널] → VPN 서버 → 인터넷 → 서버
                      ↑
                    암호화되어 있어서 내용을 볼 수 없음

VPN은 인터넷 위에 암호화된 전용 터널을 만드는 기술입니다. 터널 안의 데이터는 암호화되어 있어서 중간에서 엿봐도 내용을 알 수 없습니다. 또한 VPN 서버의 IP 주소로 접속하기 때문에, 내 실제 IP도 숨겨집니다.

회사에서 재택근무할 때 VPN을 켜라고 하는 이유가 이겁니다. 집에서 회사 내부 네트워크에 안전하게 접속하기 위한 것입니다.

한 가지 주의할 점이 있습니다. VPN을 쓰면 ISP 대신 VPN 업체가 데이터를 볼 수 있습니다. 신뢰할 수 있는 업체를 선택해야 합니다. 무료 VPN은 특히 조심해야 합니다 — 여러분의 데이터가 “상품“일 수 있습니다.

사건: Firesheep — 카페에서 남의 페이스북에 로그인하다

2010년, 보안 연구원 에릭 버틀러가 Firesheep이라는 프로그램을 공개합니다.

이 프로그램의 기능은 충격적이었습니다. 같은 WiFi 네트워크에 있는 사람들의 로그인 세션을 가로채는 것이었습니다.

[그림 6-9] Firesheep 세션 하이재킹 시나리오

  카페 WiFi에서:

  당신: HTTP로 페이스북 로그인
    → 로그인 정보(세션 토큰[^3])가 암호화되지 않은 채 전송

  옆자리 해커: Firesheep 실행 중
    → 같은 WiFi이므로 오가는 데이터가 보임
    → 당신의 세션 토큰을 가로챔
    → 해커의 브라우저에 당신으로 로그인됨
    → 비밀번호 없이 당신의 페이스북 접속

기술 지식이 없는 사람도 버튼 하나로 이 공격이 가능했습니다.

에릭 버틀러가 이 도구를 공개한 이유는 악용이 아니었습니다. 당시 페이스북, 트위터 같은 거대 서비스들이 여전히 HTTP(암호화 없음)를 사용하고 있다는 사실을 세상에 알리기 위해서였습니다.

효과는 강력했습니다. Firesheep 공개 이후 페이스북, 트위터 등 주요 서비스가 전면 HTTPS 도입을 서둘렀습니다.3 2015년에는 무료 HTTPS 인증서를 제공하는 Let’s Encrypt가 출범했고, 현재 웹 트래픽의 대부분이 HTTPS로 암호화되어 있습니다.

브라우저 주소창에 자물쇠 아이콘이 보이면, 그것이 HTTPS입니다. 카페 WiFi에서도 안전한 이유입니다. Firesheep이 세상을 바꾼 셈입니다.

알쓸신잡

  • ping의 어원은 잠수함 소나: 네트워크에서 ping 명령어를 사용하면 데이터가 목적지에 갔다 돌아오는 시간을 측정합니다. 이 이름은 잠수함의 소나(SONAR) 에서 왔습니다. 잠수함이 “핑!” 소리를 보내고 반사음이 돌아오는 시간으로 물체까지의 거리를 계산합니다. 네트워크 ping도 같은 원리입니다 — 패킷을 보내고 돌아오는 시간(RTT4)을 측정합니다.

  • “There’s no place like 127.0.0.1”: 127.0.0.1은 “나 자신“을 가리키는 특수한 IP 주소입니다. localhost라고도 합니다. 이 주소로 보낸 데이터는 네트워크 밖으로 나가지 않고 내 컴퓨터 안에서 돌아옵니다. 개발자들이 자기 컴퓨터에서 서버를 테스트할 때 localhost:3000 같은 주소를 쓰는 이유입니다. “There’s no place like 127.0.0.1“은 오즈의 마법사 명대사 “There’s no place like home(집만 한 곳은 없다)“에서 home을 127.0.0.1로 바꾼 개발자 유머입니다.

  • 500마일 이메일 전설: 실제로 일어난 일입니다. 어느 대학 시스템 관리자에게 교수가 “500마일(약 800km) 이상 떨어진 곳에 이메일을 보낼 수 없다“고 연락합니다. 말도 안 되는 소리라고 생각했지만, 테스트하니 진짜였습니다. 서버 업그레이드 중 이메일 서버의 타임아웃이 0ms로 초기화된 것이 원인이었습니다. 타임아웃 0ms는 “즉시 응답이 와야 한다“는 뜻인데, 광섬유에서 빛의 속도(약 200,000km/s)로 계산하면 왕복 0ms 이내인 거리가 약 500마일입니다. 그 이상은 빛이 왕복하는 데 1ms 이상 걸리므로 타임아웃 — 실패. 물리 법칙이 소프트웨어 버그가 된 순간입니다.

데이터가 TCP의 보호를 받으며 서버에 도착했습니다. 배달의민족 서버입니다. 우리가 “치킨“이라고 검색했으니, 서버는 수십만 개의 치킨집 중에서 우리에게 맞는 결과를 골라 보여줘야 합니다. 그런데 수십억 개의 데이터 중에서 원하는 것을 어떻게 0.3초 만에 찾아내는 걸까요?

  1. Handshake: 악수. 네트워크에서는 통신을 시작하기 전에 양쪽이 준비 상태를 확인하는 절차를 뜻한다. ↩

  2. 헤더(Header): 패킷의 맨 앞에 붙는 정보 영역. 발신지, 수신지, 포트 번호 등 전송에 필요한 정보가 들어 있다. 편지의 봉투에 해당. ↩

  3. 2010년 10월 Firesheep 공개. — Eric Butler ↩

  4. RTT(Round Trip Time): 데이터가 목적지에 갔다가 돌아오는 데 걸리는 왕복 시간. ↩