서울에서 뉴욕 서버로 메시지를 보내면 150밀리초 만에 도착합니다. 이 짧은 시간 동안 데이터는 수십 개의 라우터를 건너고, 바닷속 광케이블을 통과하며, 수백 번의 경로 판단을 거칩니다. 패킷이 인터넷에서 이동하는 방식은 단순히 “A에서 B로 전송된다”가 아닙니다. 데이터는 패킷이라는 작은 조각으로 분리되어 각자 최적의 경로를 찾아 독립적으로 이동하고, 목적지에서 다시 조립됩니다. 이 과정에 IP 라우팅, TTL, NAT, ARP, 캡슐화가 모두 관여합니다. 지금부터 패킷 하나가 태어나서 목적지에 도달하기까지의 전 여정을 낱낱이 파헤칩니다.
목차
- 패킷이란 무엇인가 — 데이터를 조각내는 이유
- 패킷의 여행 준비: 캡슐화와 OSI 계층
- IP 라우팅: 라우터가 다음 목적지를 결정하는 방법
- TTL·NAT·ARP: 패킷 여정의 숨은 조력자들
- 실전으로 보는 패킷 경로: traceroute 완전 해부
- 전문가 관점: BGP·CDN·패킷 최적화 트렌드
1. 패킷이란 무엇인가 — 데이터를 조각내는 이유 {#1}
패킷이 인터넷에서 이동하는 방식을 이해하려면 가장 먼저 “왜 데이터를 통째로 보내지 않고 조각으로 나누는가”라는 질문에 답해야 합니다.
패킷 교환 vs 회선 교환
초기 전화 네트워크는 회선 교환(Circuit Switching) 방식이었습니다. 통화를 시작하면 발신자와 수신자 사이에 물리적으로 독점적인 회선이 확보되고, 통화가 끝날 때까지 그 회선은 다른 사람이 쓸 수 없었습니다. 두 사람이 침묵하는 동안에도 회선은 점유된 채로 낭비됩니다.
인터넷은 완전히 다른 방식인 **패킷 교환(Packet Switching)**을 선택했습니다. 1960년대 폴 배런(Paul Baran)과 도널드 데이비스(Donald Davies)가 독립적으로 개발한 이 개념은 데이터를 작은 패킷으로 쪼개 각각 독립적으로 전송하는 방식입니다.
[회선 교환 vs 패킷 교환 비교]
회선 교환 (전통 전화망):
사용자 A ──────────── 전용 회선 ──────────── 사용자 B
(통화 중 100% 독점, 침묵해도 점유)
패킷 교환 (인터넷):
사용자 A ─[P1][P2][P3]──→ 공유 네트워크 ──→ 사용자 B
사용자 C ─[P4][P5]────→ (동일 링크 공유) ──→ 사용자 D
↑
빈 공간이 없음. 여러 사용자가 동시에 효율적으로 공유
왜 작은 조각으로 나누는가
하나의 큰 파일을 통째로 전송하지 않고 작은 패킷으로 나누는 데는 네 가지 핵심 이유가 있습니다.
① 공평한 대역폭 공유: 100MB 파일을 통째로 보내는 동안 다른 사용자는 기다려야 합니다. 패킷으로 쪼개면 여러 사람의 데이터가 번갈아가며 전송됩니다.
② 오류 복구 효율: 1GB 파일을 통째로 보내다가 오류가 나면 처음부터 다시 보내야 합니다. 패킷 단위로 나누면 오류가 난 패킷만 재전송합니다.
③ 다중 경로 활용: 같은 목적지로 가는 패킷들이 서로 다른 경로를 통해 동시에 이동할 수 있어 전체 처리량이 증가합니다.
④ 네트워크 장애 우회: 일부 경로가 끊겨도 라우터가 다른 경로를 즉시 선택합니다. 원래 인터넷은 핵 공격에도 살아남는 네트워크를 목표로 설계되었습니다.
패킷의 구조
[하나의 패킷 내부 구조]
┌─────────────────────────────────────────────────────┐
│ 패킷 │
│ ┌──────────────┬──────────────┬────────────────────┐ │
│ │ 헤더 │ 페이로드 │ 트레일러(선택적) │ │
│ │ (Header) │ (Payload) │ (Trailer) │ │
│ │ │ │ │ │
│ │ 출발지 IP │ 실제 데이터 │ 오류 검출 코드 │ │
│ │ 목적지 IP │ (최대 │ (CRC 등) │ │
│ │ 시퀀스 번호 │ 1460 byte) │ │ │
│ │ TTL, 프로토콜│ │ │ │
│ │ 체크섬 등 │ │ │ │
│ └──────────────┴──────────────┴────────────────────┘ │
└─────────────────────────────────────────────────────┘
IP 헤더: 20~60 byte
TCP 헤더: 20~60 byte
실제 데이터(페이로드): 최대 1460 byte (이더넷 기준)
전체 최대 크기(MTU): 1500 byte
**MTU(Maximum Transmission Unit)**는 하나의 패킷이 가질 수 있는 최대 크기입니다. 이더넷 기준 1500바이트입니다. 데이터가 이보다 크면 여러 패킷으로 **단편화(Fragmentation)**되어 전송되고, 목적지에서 다시 조립됩니다.
2. 패킷의 여행 준비: 캡슐화와 OSI 계층 {#2}
패킷이 네트워크에 뛰어들기 전, 출발지 컴퓨터에서는 데이터를 여러 겹의 봉투에 포장하는 캡슐화(Encapsulation) 과정이 이루어집니다.
OSI 7계층과 패킷 캡슐화
[OSI 7계층에서 데이터가 캡슐화되는 과정]
계층 7: 응용 계층 (Application)
데이터: "GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n"
PDU 이름: 메시지(Message)
계층 6: 표현 계층 (Presentation)
인코딩·암호화 (TLS 적용 시)
PDU 이름: 메시지(Message)
계층 5: 세션 계층 (Session)
세션 관리
PDU 이름: 메시지(Message)
계층 4: 전송 계층 (Transport) ← TCP/UDP 헤더 추가
┌─────────────┬─────────────────────────────────┐
│ TCP 헤더 │ HTTP 메시지 │
│ (Sport,Dport│ │
│ Seq, ACK..)│ │
└─────────────┴─────────────────────────────────┘
PDU 이름: 세그먼트(Segment)
계층 3: 네트워크 계층 (Network) ← IP 헤더 추가
┌──────────┬─────────────┬─────────────────────┐
│ IP 헤더 │ TCP 헤더 │ HTTP 메시지 │
│(Src/Dst IP│ │ │
│ TTL, 프토)│ │ │
└──────────┴─────────────┴─────────────────────┘
PDU 이름: 패킷(Packet)
계층 2: 데이터링크 계층 (Data Link) ← MAC 헤더+트레일러 추가
┌──────────┬──────────┬─────────────┬──────────────┬────────┐
│이더넷 헤더│ IP 헤더 │ TCP 헤더 │ HTTP 메시지 │ FCS │
│(Src/Dst │ │ │ │(오류 │
│ MAC 주소)│ │ │ │ 검출) │
└──────────┴──────────┴─────────────┴──────────────┴────────┘
PDU 이름: 프레임(Frame)
계층 1: 물리 계층 (Physical)
0과 1의 전기 신호 / 빛 신호 / 전파로 변환되어 전송
PDU 이름: 비트(Bit)
이 캡슐화 과정을 편지 봉투에 비유할 수 있습니다. 편지 내용(HTTP 데이터)을 작은 봉투(TCP)에 넣고, 그 봉투를 큰 봉투(IP)에 넣고, 최종적으로 배달용 포장지(이더넷 프레임)로 감쌉니다. 각 봉투에는 해당 계층에서 필요한 주소와 정보가 적혀 있습니다.
두 종류의 주소: IP 주소와 MAC 주소
패킷이 이동할 때 두 가지 주소 체계가 함께 사용됩니다.
[IP 주소 vs MAC 주소 역할 비교]
IP 주소 (논리적 주소) MAC 주소 (물리적 주소)
────────────────────────────────────────────────────────
예: 192.168.1.100 예: AA:BB:CC:DD:EE:FF
소프트웨어적으로 할당 하드웨어에 고정 (NIC에 내장)
전체 여정의 출발지·목적지 바로 다음 홉까지만 사용
라우터를 건너도 유지 라우터를 건너면 변경
전 세계 고유 식별 로컬 네트워크 내 식별
비유:
IP 주소 = 편지의 최종 목적지 주소 (서울시 강남구 테헤란로 100)
MAC 주소 = 지금 이 순간 배달부 이름 (다음 우체국까지 담당 배달부)
라우터를 하나 건널 때마다 이더넷 프레임의 MAC 주소는 바뀌지만, IP 패킷의 IP 주소는 최종 목적지까지 유지됩니다. 이 차이가 네트워크 계층과 데이터링크 계층의 역할 분담의 핵심입니다.
역캡슐화: 목적지에서의 포장 해제
목적지에 도달하면 반대 순서로 각 계층이 자신의 헤더를 제거하면서 원본 데이터를 추출합니다.
[수신 측의 역캡슐화 과정]
물리 계층: 전기 신호 → 비트열로 변환
↓
데이터링크 계층: 이더넷 헤더·FCS 제거, MAC 주소 확인
↓
네트워크 계층: IP 헤더 제거, 목적지 IP 확인
↓
전송 계층: TCP 헤더 제거, 포트 번호로 애플리케이션 식별
↓
응용 계층: "GET /index.html HTTP/1.1..." 수신 완료
3. IP 라우팅: 라우터가 다음 목적지를 결정하는 방법 {#3}
캡슐화가 완료된 패킷은 이제 실제 여행을 시작합니다. 패킷이 인터넷에서 이동하는 방식의 핵심 엔진은 바로 IP 라우팅입니다.
라우터의 역할: 교차로의 교통경찰
라우터(Router)는 패킷을 받아 목적지 IP 주소를 보고 다음에 어느 방향으로 보낼지 결정하는 장비입니다. 고속도로 인터체인지의 안내판과 같습니다. “서울 방향은 이쪽, 부산 방향은 저쪽”을 결정하되, 최종 목적지까지 전체 경로를 미리 알지 못해도 됩니다. 다음 홉(hop)만 결정하면 됩니다.
[패킷의 홉-바이-홉(Hop-by-Hop) 이동]
내 PC 라우터1 라우터2 라우터3 서버
(192.168.1.100) (ISP) (해저 케이블) (목적지 ISP) (93.184.216.34)
│ │ │ │ │
│ 패킷 전송 │ │ │ │
│───────────────►│ │ │ │
│ │ 다음 홉 결정 │ │ │
│ │───────────────►│ │ │
│ │ │ 다음 홉 결정 │ │
│ │ │───────────────►│ │
│ │ │ │ 최종 전달 │
│ │ │ │──────────────►│
각 라우터는 "전체 경로"가 아닌 "다음 홉"만 결정
→ 분산 처리로 인터넷 전체 확장성 달성
라우팅 테이블: 라우터의 지도
라우터는 **라우팅 테이블(Routing Table)**이라는 지도를 갖고 있습니다. 목적지 IP와 서브넷 마스크를 기준으로 패킷을 어느 인터페이스로 내보낼지 결정합니다.
[실제 라우팅 테이블 예시]
$ ip route show (Linux 명령어)
또는
$ route print (Windows 명령어)
Destination Gateway Genmask Interface
─────────────────────────────────────────────────────────
0.0.0.0 192.168.1.1 0.0.0.0 eth0 ← 기본 게이트웨이
10.0.0.0 10.0.0.1 255.0.0.0 eth1 ← 내부 네트워크
172.16.0.0 172.16.0.1 255.240.0.0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 eth0 ← 직접 연결된 네트워크
127.0.0.0 0.0.0.0 255.0.0.0 lo ← 루프백
라우팅 결정 알고리즘 (Longest Prefix Match):
목적지 IP: 192.168.1.55
→ 0.0.0.0/0 매칭: 0비트 (기본 게이트웨이)
→ 192.168.1.0/24 매칭: 24비트 ← 가장 길게 일치 → 이 경로 선택!
목적지 IP: 8.8.8.8 (Google DNS)
→ 0.0.0.0/0 매칭: 0비트 ← 유일 매칭 → 기본 게이트웨이로 전송
**LPM(Longest Prefix Match)**은 라우팅 테이블에서 목적지 IP와 가장 길게(구체적으로) 일치하는 항목을 선택하는 규칙입니다. /24 경로와 /16 경로가 둘 다 매칭되면 더 구체적인 /24를 선택합니다.
정적 라우팅 vs 동적 라우팅
[라우팅 프로토콜 종류]
정적 라우팅 (Static Routing):
관리자가 직접 라우팅 테이블 수동 입력
장점: 예측 가능, 보안성, 오버헤드 없음
단점: 경로 변경 시 수동 업데이트 필요
용도: 소규모 네트워크, 특정 고정 경로
동적 라우팅 (Dynamic Routing):
라우터끼리 자동으로 경로 정보 교환 및 최적 경로 계산
내부 라우팅 프로토콜 (AS 내부):
├── OSPF (Open Shortest Path First)
│ → 링크 상태 알고리즘, 다익스트라(Dijkstra) 기반
│ → 전체 토폴로지 지도를 갖고 최단 경로 계산
│ → 대기업 내부 네트워크에서 주로 사용
│
└── RIP (Routing Information Protocol)
→ 거리 벡터 알고리즘, 홉 수 기반
→ 최대 15홉 제한 (소규모 네트워크용)
외부 라우팅 프로토콜 (AS 간):
└── BGP (Border Gateway Protocol)
→ 인터넷 백본의 핵심
→ AS(자율 시스템) 간 경로 교환
→ 아래 섹션에서 자세히 다룸
패킷 단편화: MTU를 초과하면 어떻게 되는가
[IP 단편화 과정]
원본 데이터: 4000 byte
이더넷 MTU: 1500 byte
IP 헤더: 20 byte → 페이로드 최대 1480 byte
단편화:
┌──────────────────────────────────────┐
│ 원본 IP 패킷 (4000 byte) │
└──────────────────────────────────────┘
↓ 단편화
┌───────────────────┐ ┌────────────────┐ ┌────────────┐
│ 조각 1: 1480 byte │ │ 조각 2: 1480B │ │ 조각 3: │
│ MF=1, Offset=0 │ │ MF=1, Offset= │ │ MF=0(마지막│
│ (More Frag있음) │ │ 185 (1480/8) │ │ Offset=370 │
└───────────────────┘ └────────────────┘ └────────────┘
IP 헤더의 단편화 필드:
- Identification: 같은 원본 패킷의 조각들을 식별 (동일 값)
- MF (More Fragments): 뒤에 조각이 더 있으면 1
- Fragment Offset: 원본에서의 위치 (8 byte 단위)
현대적 해결책: Path MTU Discovery (PMTUD)
→ 처음부터 경로 상 최소 MTU를 파악해 단편화 방지
→ IPv6에서는 라우터 단편화 금지, 출발지만 단편화 가능
4. TTL·NAT·ARP: 패킷 여정의 숨은 조력자들 {#4}
라우팅 외에도 패킷이 정상적으로 이동하기 위해 함께 동작하는 세 가지 핵심 메커니즘이 있습니다.
TTL(Time To Live): 패킷의 수명
TTL은 IP 헤더에 있는 1바이트 숫자 필드입니다. 패킷이 라우터를 하나 통과할 때마다 1씩 감소하고, 0이 되면 라우터가 패킷을 폐기하고 출발지에 ICMP Time Exceeded 메시지를 보냅니다.
[TTL 동작 과정]
출발지 PC 목적지
TTL=64 ──[라우터1: TTL→63]──[라우터2: TTL→62]──... ──► 도착
↓TTL=0이 되면
라우터가 패킷 폐기
+ ICMP "Time Exceeded" 메시지 출발지로 전송
TTL의 역할:
① 라우팅 루프 방지
A→B→C→A→B→C... 무한 순환 패킷이 네트워크를 마비시키는 것을 방지
② traceroute의 핵심 원리
TTL=1로 전송 → 1번째 라우터에서 폐기 → 해당 라우터 IP 확인
TTL=2로 전송 → 2번째 라우터에서 폐기 → 해당 라우터 IP 확인
(자세한 내용은 섹션 5에서)
운영체제별 기본 TTL 값:
Linux/Mac : 64
Windows : 128
Cisco IOS : 255
→ ping 응답의 TTL 값으로 상대방 OS를 추측할 수 있음
NAT(Network Address Translation): 하나의 공인 IP로 여러 기기를
가정에서 스마트폰, PC, TV, 태블릿이 모두 인터넷에 연결됩니다. 그런데 ISP(인터넷 서비스 제공자)로부터 받는 공인 IP는 보통 하나뿐입니다. 이 문제를 해결하는 것이 **NAT(Network Address Translation)**입니다.
[NAT 동작 원리: 집에서 외부 서버에 접속하는 경우]
가정 네트워크 (사설 IP) 공유기/NAT 장치 인터넷 (공인 IP)
(공인 IP: 1.2.3.4)
PC: 192.168.1.10 ──►
스마트폰: 192.168.1.20 ──► NAT 테이블 관리 ──► 93.184.216.34
TV: 192.168.1.30 ──► (example.com)
[NAT 변환 테이블 예시]
┌────────────────────┬───────────────┬────────────────────┐
│ 내부 주소:포트 │ 공인 IP:포트 │ 외부 주소:포트 │
├────────────────────┼───────────────┼────────────────────┤
│ 192.168.1.10:52345 │ 1.2.3.4:10001 │ 93.184.216.34:80 │
│ 192.168.1.20:48123 │ 1.2.3.4:10002 │ 93.184.216.34:443 │
│ 192.168.1.30:55678 │ 1.2.3.4:10003 │ 8.8.8.8:53 │
└────────────────────┴───────────────┴────────────────────┘
출발 시: 사설 IP:포트 → 공인 IP:새 포트 (SNAT, 소스 NAT)
귀환 시: 공인 IP:새 포트 → 사설 IP:포트 (역변환)
→ 외부 서버 입장에서는 모두 1.2.3.4에서 온 것으로 보임
→ 포트 번호로 어느 내부 기기의 요청인지 구분
NAT의 부작용: 외부에서 내부 기기로 먼저 연결을 시도하면 NAT 테이블에 항목이 없어 연결이 불가능합니다. 이것이 가정용 공유기 뒤의 기기가 서버로 동작하기 어려운 이유이며, 포트 포워딩이나 UPnP로 해결합니다.
ARP(Address Resolution Protocol): IP 주소에서 MAC 주소 찾기
같은 네트워크 내에서 패킷을 전달하려면 목적지의 MAC 주소가 필요합니다. IP 주소는 알지만 MAC 주소를 모를 때 사용하는 프로토콜이 ARP입니다.
[ARP 동작 과정]
시나리오: PC(192.168.1.10)가 라우터(192.168.1.1)에 패킷을 보내려 함
1. ARP 캐시 확인
$ arp -n (현재 ARP 테이블 출력)
→ 192.168.1.1의 MAC 주소가 없음
2. ARP 요청 (브로드캐스트)
PC가 네트워크 전체에 방송:
"192.168.1.1을 사용하는 분, MAC 주소가 뭔가요?"
(이더넷 목적지: FF:FF:FF:FF:FF:FF — 브로드캐스트)
3. ARP 응답 (유니캐스트)
라우터가 PC에게 직접 응답:
"저는 192.168.1.1이고 MAC 주소는 AA:BB:CC:DD:EE:FF입니다"
4. ARP 캐시 저장
PC가 192.168.1.1 → AA:BB:CC:DD:EE:FF 매핑을 캐시에 저장
(보통 수 분~수십 분 유효)
5. 이더넷 프레임 완성
목적지 MAC: AA:BB:CC:DD:EE:FF로 프레임 생성 후 전송
[ARP 스푸핑 공격]
악성 노드가 "192.168.1.1의 MAC은 제 것(ZZ:ZZ...)입니다" 위조 응답
→ 트래픽이 공격자에게 흘러들어감 (중간자 공격, MITM)
→ 방어: Dynamic ARP Inspection (DAI), 정적 ARP 설정
ICMP: 네트워크의 피드백 시스템
**ICMP(Internet Control Message Protocol)**는 네트워크 장치들이 오류 및 상태 정보를 주고받는 프로토콜입니다. 데이터를 전송하는 프로토콜이 아니라 네트워크 상태를 진단하는 제어 메시지를 주고받습니다.
[주요 ICMP 메시지 유형]
유형 설명 발생 상황
────────────────────────────────────────────────────────────
0 Echo Reply ping 응답
3 Destination Unreachable 목적지 도달 불가
코드 0: 네트워크 도달 불가
코드 1: 호스트 도달 불가
코드 3: 포트 도달 불가 (UDP 없는 포트)
코드 4: 단편화 필요하나 DF 비트 설정
8 Echo Request ping 요청
11 Time Exceeded TTL = 0 (traceroute 핵심)
12 Parameter Problem 헤더 오류
# ping: ICMP Echo Request/Reply 사용
ping -c 4 google.com
# ICMP를 이용한 경로 탐색
traceroute google.com (Linux/Mac)
tracert google.com (Windows)
5. 실전으로 보는 패킷 경로: traceroute 완전 해부 {#5}
지금까지 배운 모든 개념이 실제로 어떻게 동작하는지 traceroute 명령어 하나로 직접 확인할 수 있습니다. 패킷이 인터넷에서 이동하는 방식을 눈으로 볼 수 있는 가장 강력한 도구입니다.
traceroute의 동작 원리
[traceroute 핵심 원리: TTL을 1씩 증가시키며 각 홉 식별]
traceroute google.com 실행 시:
1단계: TTL=1 패킷 전송
→ 첫 번째 라우터에서 TTL 0 → 패킷 폐기
→ 라우터가 "Time Exceeded" ICMP 응답 전송
→ 응답 시간 측정 + 라우터 IP 기록
2단계: TTL=2 패킷 전송
→ 두 번째 라우터에서 TTL 0 → 패킷 폐기
→ 두 번째 라우터 IP 기록
3단계: TTL=3 패킷 전송
...반복...
N단계: 목적지 도달
→ 목적지 서버가 ICMP Echo Reply 전송
→ 전체 경로 완성
traceroute 실제 출력 해석
bash
# Linux/Mac
$ traceroute -n google.com
# Windows
$ tracert google.com
[실제 출력 예시 (서울 → Google 서버)]
traceroute to google.com (142.250.196.110), 30 hops max
홉# RTT1 RTT2 RTT3 IP 주소 (역방향 DNS)
──────────────────────────────────────────────────────────
1 1.2ms 1.1ms 1.2ms 192.168.1.1 (공유기/게이트웨이)
2 5.4ms 5.2ms 5.3ms 10.10.1.1 (ISP 내부)
3 7.8ms 7.9ms 7.7ms 112.174.x.x (KT/SKT 백본)
4 12.3ms 12.1ms 12.4ms 112.174.x.x (국내 ISP 코어)
5 35.2ms 35.4ms 35.1ms 72.14.x.x (Google 인터넷 교환점)
6 38.1ms 37.9ms 38.0ms 108.170.x.x (Google 내부 네트워크)
7 37.8ms 37.7ms 37.9ms 142.250.196.110 (목적지 도달)
[출력 해석]
RTT 세 번 측정: 각 홉으로 3개의 프로브 패킷을 보내 신뢰도 확인
* 표시: 해당 라우터가 ICMP 응답을 차단 (방화벽)
RTT 급증 구간: 홉 4→5에서 약 23ms 증가 → 해저 케이블 또는 대양 횡단 지점
패킷 캡처: Wireshark로 패킷 직접 관찰
[Wireshark 필터로 패킷 분석]
# 특정 IP의 패킷만 보기
ip.addr == 142.250.196.110
# TCP 3-Way Handshake만 보기
tcp.flags.syn == 1 or tcp.flags.ack == 1
# HTTP 요청만 보기
http.request.method == "GET"
# DNS 쿼리 보기
dns
# ICMP(ping/traceroute) 보기
icmp
[Wireshark 패킷 상세 보기 예시]
Frame 1: 74 bytes on wire
Ethernet II
Destination: aa:bb:cc:dd:ee:ff ← 다음 홉 MAC (공유기)
Source: 11:22:33:44:55:66 ← 내 NIC MAC
Internet Protocol Version 4
Source: 192.168.1.100 ← 내 사설 IP
Destination: 142.250.196.110 ← Google 공인 IP
TTL: 64
Protocol: TCP (6)
Transmission Control Protocol
Source Port: 54321
Destination Port: 443
Flags: SYN ← 3-Way Handshake 시작
네트워크 진단 명령어 모음
bash
# 기본 연결 확인
ping google.com # ICMP Echo로 연결 확인
ping -c 4 -i 0.2 google.com # 4회, 0.2초 간격
# 경로 추적
traceroute google.com # Linux/Mac (UDP 기본)
traceroute -I google.com # ICMP 사용
tracert google.com # Windows
# DNS 조회
nslookup google.com # 기본 DNS 조회
dig google.com A # A 레코드 조회
dig +trace google.com # DNS 계층 전체 추적
# 소켓 연결 상태
ss -tn # TCP 연결 상태 (Linux)
netstat -an # 전체 소켓 상태
# 라우팅 테이블
ip route show # Linux 라우팅 테이블
route print # Windows 라우팅 테이블
netstat -rn # Mac/Linux 라우팅 테이블
# ARP 캐시
arp -n # ARP 테이블 확인
ip neigh show # Linux ARP 테이블 (더 자세함)
# MTU 확인 및 Path MTU Discovery
ip link show eth0 | grep mtu # 인터페이스 MTU 확인
ping -M do -s 1472 google.com # DF 비트 설정, MTU 테스트
6. 전문가 관점: BGP·CDN·패킷 최적화 트렌드 {#6}
패킷이 인터넷에서 이동하는 방식을 진정으로 이해하려면 인터넷 전체를 연결하는 거시적 인프라도 알아야 합니다.
BGP: 인터넷의 우편번호 체계
인터넷은 수만 개의 **AS(Autonomous System, 자율 시스템)**로 이루어져 있습니다. AS는 KT, SK브로드밴드, Google, AWS 등 독립적으로 운영되는 네트워크 단위입니다. 각 AS는 고유한 **ASN(AS Number)**을 갖습니다.
[인터넷의 AS 구조]
AS 9318 (SKB) AS 4766 (KT) AS 15169 (Google)
┌──────────┐ ┌──────────┐ ┌──────────────────┐
│ 내부 라우터│ │ 내부 라우터│ │ Google 데이터 │
│ OSPF로 │ │ OSPF로 │ │ 센터 전 세계 │
│ 내부 경로 │ │ 내부 경로 │ │ │
│ 관리 │ │ 관리 │ │ │
└────┬─────┘ └─────┬────┘ └────────┬─────────┘
│ BGP 피어링 │ BGP 피어링 │
└────────────────┼────────────────────┘
│
[인터넷 교환 포인트 IXP]
KINX (한국), JPIX (일본)
DE-CIX (독일), LINX (영국)
BGP가 하는 일:
→ AS 간 도달 가능한 IP 주소 블록(프리픽스) 광고
→ 정치적·비즈니스적 결정이 경로 선택에 영향
→ BGP 오설정 = 인터넷 대규모 장애 원인 1위
[유명한 BGP 사고 사례]
2010년 차이나 텔레콤 BGP 하이재킹:
중국 ISP가 실수로 전 세계 수만 개 IP 프리픽스를 자신의 것으로 광고
→ 약 15분간 대규모 트래픽이 중국을 경유
→ 미국 정부 기관, 군 사이트 트래픽 포함
2021년 Facebook 대규모 장애:
내부 BGP 설정 오류로 Facebook의 모든 IP 프리픽스 철회
→ 전 세계에서 Facebook, Instagram, WhatsApp 약 6시간 다운
→ DNS 서버도 같은 네트워크에 있어 복구도 지연
CDN: 패킷 이동 거리를 줄이는 방법
**CDN(Content Delivery Network)**은 전 세계 주요 도시에 **엣지 서버(Edge Server)**를 배치해 사용자와 가장 가까운 서버에서 콘텐츠를 제공합니다. 패킷이 이동하는 물리적 거리를 줄여 레이턴시를 최소화합니다.
[CDN 없을 때 vs 있을 때 패킷 경로]
CDN 없음:
서울 사용자 ──────────────────────────────► 미국 오리진 서버
(RTT: ~150ms, 패킷이 태평양을 횡단)
CDN 있음 (Cloudflare, AWS CloudFront, Akamai):
서울 사용자 ──────► 서울/도쿄 CDN 엣지 서버
(RTT: ~5~20ms, 패킷이 국내/근처 이동)
↑
콘텐츠가 미리 캐싱되어 있음
CDN의 추가 이점:
→ DDoS 방어 (대규모 트래픽을 여러 엣지로 분산)
→ BGP Anycast: 같은 IP를 전 세계 여러 서버가 공유
→ 사용자는 자동으로 가장 가까운 서버로 연결
→ 오리진 서버 트래픽 부하 감소
소프트웨어 정의 네트워킹(SDN)과 패킷의 미래
[전통적 네트워킹 vs SDN]
전통 네트워킹:
각 라우터가 제어 평면(Control Plane)과
데이터 평면(Data Plane)을 모두 내장
→ 분산된 결정, 변경 어려움
SDN (Software Defined Networking):
제어 평면을 중앙 컨트롤러로 분리
┌─────────────────────────────────┐
│ SDN 컨트롤러 │ ← 전체 네트워크 가시성
│ (오픈플로우 프로토콜로 제어) │ 중앙 집중 정책 관리
└──────────┬──────────────────────┘
│ 플로우 테이블 배포
┌──────┼──────┐
▼ ▼ ▼
스위치 스위치 스위치 ← 단순 데이터 전달만 담당
활용: 구글 B4(사내 WAN), AWS VPC, 클라우드 네트워크 전반
개발자가 패킷 경로를 알아야 하는 실무 이유
python
# 실무 사례 1: Connection Timeout 설정 시 RTT 고려
import requests
# ❌ 글로벌 서비스에서 너무 짧은 타임아웃
response = requests.get("https://api.us-east.example.com",
timeout=0.1) # 100ms
# 서울→미국 RTT ≈ 150ms → 항상 타임아웃!
# ✅ RTT를 고려한 적절한 타임아웃
response = requests.get("https://api.us-east.example.com",
timeout=(3.0, 30.0))
# (connect_timeout=3초, read_timeout=30초)
# connect_timeout은 3-Way Handshake + TLS Handshake 포함
# 실무 사례 2: 리전 선택으로 레이턴시 최적화
# 한국 사용자 대상 서비스: ap-northeast-2 (서울 리전) 선택
# → 서울 사용자 RTT: ~5ms (같은 도시)
# → us-east-1 사용: RTT ~150ms (30배 차이)
# 실무 사례 3: DNS TTL 설정으로 장애 복구 시간 조정
# DNS TTL이 86400(1일)이면 장애 시 복구에 최대 1일 소요
# 중요 서비스: TTL=300(5분)으로 낮춰 빠른 페일오버 가능
# 트레이드오프: TTL 낮을수록 DNS 쿼리 증가 → CDN 히트율 감소
결론
패킷이 인터넷에서 이동하는 방식은 세 가지 핵심으로 요약됩니다. 첫째, 데이터는 MTU 크기의 패킷으로 분리되어 캡슐화된 후 홉-바이-홉으로 각 라우터가 라우팅 테이블의 LPM 규칙에 따라 다음 경로를 독립적으로 결정합니다. 둘째, TTL이 라우팅 루프를 막고, NAT이 부족한 공인 IP 문제를 해결하며, ARP가 IP 주소와 MAC 주소를 연결해 패킷이 목적지에 정확히 도달하도록 협력합니다. 셋째, BGP가 수만 개의 AS를 연결해 인터넷 전체의 경로를 동적으로 관리합니다. 오늘 배운 내용을 바탕으로 traceroute google.com을 직접 실행하고, 각 홉의 IP와 RTT가 무엇을 의미하는지 해석하는 것부터 시작해보세요.
답글 남기기