핵심 인사이트 (3줄 요약)

  1. 본질: PMTU (Path MTU Discovery)는 목적지까지 수많은 라우터를 거쳐 가는 인터넷의 험난한 여정에서, "가장 좁은 병목 도로(최소 MTU)의 폭이 얼마인지"를 통신 시작 전에 미리 탐색해 내는 영리한 알고리즘이다.
  2. 작동 원리 (DF 비트와 ICMP의 핑퐁): 송신자가 무작정 1500바이트 패킷에 "절대 찢지 마!(DF=1)" 딱지를 붙여 쏘고, 좁은 라우터가 이를 튕겨내며 "우리 길 1400밖에 안 돼!(ICMP 에러)"라고 응답하면, 송신자가 패킷 크기를 1400으로 줄여서 다시 쏘는 과정을 반복하며 최적의 크기를 찾아낸다.
  3. 목적: 네트워크 통신의 암 덩어리인 '단편화(Fragmentation)'가 중간 라우터에서 아예 발생하지 않도록, 송신자 PC가 처음부터 좁은 문을 무사통과할 수 있는 크기로 패킷을 미리 작게 썰어서 보내기 위함이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: 출발지 호스트와 목적지 호스트 사이의 전체 라우팅 경로 중, 가장 작은 MTU 값을 알아내는 프로토콜 및 매커니즘 (RFC 1191).

  • 필요성: 내 PC와 공유기는 MTU가 1500이다. 미국 구글 서버도 1500이다. 그런데 태평양 해저를 건너는 중간 라우터 하나가 구형이라 MTU가 1400이라고 치자. 내가 1500으로 던지면 중간 라우터가 땀을 뻘뻘 흘리며 패킷을 1400과 100으로 찢는다. 전 세계 수천만 명이 패킷을 던지는데 라우터가 일일이 찢고 있으면 CPU가 터져 인터넷이 마비된다. "라우터 고생시키지 말고, 내 PC에서 보낼 때 아예 1400으로 미리 맞춰서 보내면 어떨까?"라는 착한 배려심에서 출발했다.

  • 💡 비유: 서울에서 부산까지 화물차를 몰고 가는데, 중간에 **"높이 제한 3m"**짜리 오래된 굴다리가 있습니다. 4m짜리 화물을 싣고 출발했다가 굴다리 앞에서 짐을 끄집어내려 쪼개고 있으면(단편화) 뒤차들이 다 밀립니다. PMTU는 출발 전 굴다리 높이를 미리 알아보고, 처음부터 서울에서 짐을 3m 규격으로 맞춰서 화물차 2대에 나눠 싣고 출발하는 똑똑한 운송 전술입니다.

📢 섹션 요약 비유: PMTU Discovery는 동굴 탐험대가 사람이 통과할 수 있는 가장 좁은 구멍의 크기를 미리 레이저(DF 패킷)로 쏴서 측정한 뒤, 가방 크기를 그 구멍에 딱 맞게 줄여 매고 들어가는 치밀한 사전 탐사 작업입니다.

Ⅱ. PMTU 탐색 과정과 블랙홀 문제 (Deep Dive)

1. 탐색 프로세스 (Trial and Error)

현재 거의 모든 OS(윈도우, 리눅스)는 기본적으로 PMTU 알고리즘을 켜놓고 통신을 시작한다.

  1. 송신 (DF=1): PC가 1500바이트 패킷 헤더에 DF(Don't Fragment) = 1을 세팅해서 쏜다.
  2. 병목 조우: 가다가 MTU가 1400인 라우터 R2를 만난다. 라우터는 찢어야 하는데 DF 딱지를 보고 "찢지 말라네? 그럼 버린다!"라며 패킷을 쓰레기통에 폐기(Drop)한다.
  3. 에러 반송 (ICMP): R2는 PC에게 ICMP 메시지(Type 3, Code 4: Fragmentation Needed but DF set)를 반송하며, 친절하게 "Next-Hop MTU is 1400"이라고 좁은 문의 크기를 알려준다.
  4. 크기 조절: PC는 ICMP를 받고 "아! 1400이 한계구나" 깨닫고, 패킷을 1400바이트로 줄여서 DF=1을 붙여 다시 쏜다. 목적지까지 거절당하지 않고 도달하면, 1400을 Path MTU로 확정 짓고 계속 그 크기로 통신한다.
 ┌─────────────────────────────────────────────────────────────┐
 │                PMTU Discovery 메커니즘 (ICMP 핑퐁)             │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 내 PC ] ── 1500B (DF=1) ──▶ [ R1 (1500) ] ──▶ [ R2 (1400) ] │
 │                                                          │  │
 │   "에잇 1500으로 줄여!" ◀──── ICMP Error (MTU 1400) ───────┘  │
 │   (PC가 패킷 크기 조절)                                          │
 │                                                             │
 │   [ 내 PC ] ── 1400B (DF=1) ──▶ [ R1 (1500) ] ──▶ [ R2 (1400) ] │
 │                                                       통과! │
 │                                                          ▼  │
 │                                                 [ 구글 서버 ] │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘

2. 치명적 오류: PMTU 블랙홀 (Black Hole) 현상

PMTU는 중간 라우터가 돌려보내 주는 ICMP 에러 메시지에 100% 의존한다. 그런데 회사의 보안 방화벽 장비들이 "ICMP는 해커들이 핑(Ping) 때릴 때 쓰는 위험한 프로토콜이다!"라며 무조건 차단(Drop)해 버리는 경우가 많다.

  • 라우터 R2는 1500바이트 패킷을 버리고 ICMP를 쏘았는데, 방화벽이 이걸 막아버렸다.
  • 내 PC는 ICMP 에러를 못 받았으니 "왜 대답이 없지?"라며 1500바이트 패킷을 영원히 계속 쏜다.
  • 영원히 버려진다. 접속이 안 되고 뱅글뱅글 무한 로딩만 돈다. 이 끔찍한 단절 현상을 PMTU 블랙홀이라고 부른다.
  • 해결책: 방화벽에서 ICMP Type 3 Code 4 메시지만큼은 예외로 허용(Allow)해 주거나, 중간 라우터에서 아예 TCP 헤더의 MSS 값을 강제로 변조해 버리는 꼼수(MSS Clamping)를 쓴다.

📢 섹션 요약 비유: PMTU는 앞차(ICMP)가 좁은 길을 만나면 클락션을 울려 뒤차에게 알려주는 훌륭한 시스템이지만, 방음벽(방화벽) 때문에 클락션 소리가 막혀버리면 뒤차들이 좁은 길에 계속 들이박고 터져 죽는(블랙홀) 치명적 맹점을 가지고 있습니다.