요약: "글씨는 보이는데 이미지만 깨져요!"와 같은 기묘한 네트워크 문제, 그 원인은 PMTUD 실패일 수 있습니다. IP 조각화의 위험성부터 PMTUD의 동작 원리, 그리고 방화벽 ICMP 차단 문제와 해결책(MSS Clamping)까지, 현업 멘토가 완벽하게 알려드립니다.
안녕하세요! 👋 네트워크와 보안의 세계에 첫발을 내딛는 학생, 신입 사원 여러분! 그리고 현업에서 끊임없이 성장하고자 하는 후배 엔지니어 여러분! IT 업계의 베테랑 멘토입니다. 😊 오늘은 네트워크 세상의 기본기를 다지고, 실무에서 마주칠 문제들을 한 단계 더 깊이 이해할 수 있도록 아주 중요한 개념, PMTUD (Path MTU Discovery)에 대해 이야기해 보려고 합니다. 이 글 하나로 PMTUD의 모든 것을 완벽하게 이해하게 될 거예요. 자, 그럼 시작해볼까요? 🧑🏫
[1장] 네트워크 통신의 첫 단추: 데이터 크기는 어떻게 결정될까?
우리가 친구에게 사진을 보내거나, 유튜브 영상을 볼 때 데이터는 '패킷(Packet)'이라는 작은 상자에 나눠 담아 보냅니다. 이때 '상자의 크기'를 결정하는 것이 네트워크 통신의 효율과 안정성에 아주 중요합니다.
MTU vs MSS, 더 이상 헷갈리지 말자!
📦 MTU (Maximum Transmission Unit): 네트워크 구간(L2)에서 한 번에 보낼 수 있는 데이터 상자(프레임)의 최대 크기입니다. 도로의 '차량 높이 제한' 표지판과 같으며, 보통 1500바이트입니다.
🎁 MSS (Maximum Segment Size): MTU라는 상자 안에, 헤더(송장 정보)를 제외하고 실제로 담을 수 있는 내용물(데이터)의 최대 크기입니다. TCP 통신에서는 보통 MTU(1500) - IP 헤더(20) - TCP 헤더(20) = 1460바이트가 MSS가 됩니다.
💡 실무 Tip: MTU와 MSS, 이것만은 기억하세요!
✅ MTU는 L2 데이터 링크 계층에서 정해지는 물리적인 한계 값입니다.
✅ MSS는 L4 전송 계층(TCP)에서 협상되는 논리적인 '순수 데이터'의 크기입니다.
✅ VPN 터널링, PPPoE 같은 특수 환경에서는 헤더가 추가되어 실제 가용 공간이 줄어든다는 점을 항상 기억해야 합니다.
[2장] 네트워크의 문제아: '조각화(Fragmentation)'를 피해야 하는 이유
만약 보내려는 패킷이 중간에 만난 라우터의 MTU보다 크면, 라우터는 이 큰 패킷을 여러 개의 작은 조각으로 쪼개서 보내주었습니다. 이것을 '조각화(Fragmentation)'라고 합니다. 하지만 이 '친절'은 오늘날 네트워크 환경에서는 심각한 문제를 일으키는 '오지랖'이 되었습니다.
조각화가 불러오는 3가지 재앙
🐢 성능 저하: 패킷을 쪼개고 재조합하는 과정은 CPU에 상당한 부담을 주어 네트워크 전체의 속도를 느리게 만듭니다.
💥 패킷 손실 위험 증가: 10개로 쪼갠 조각 중 단 하나라도 중간에 사라지면, 결국 원본 패킷 전체를 다시 요청해야 할 수 있어 심각한 비효율을 유발합니다.
🛡️ 보안 장비 무력화: 패킷이 조각나 있으면 방화벽이나 IDS 같은 보안 장비가 제대로 검사하지 못하는 상황이 발생할 수 있어, 해커들이 이를 악용해 보안 장비를 우회하는 공격을 시도하기도 합니다.
[3장] 우리의 영웅, PMTUD의 등장!
조각화라는 문제아를 해결하기 위해 등장한 영웅이 바로 PMTUD(Path MTU Discovery)입니다. 출발지에서 목적지까지 가는 '경로(Path)' 전체에서 '가장 작은 MTU'를 스스로 '발견(Discovery)'하는 똑똑한 기술이죠. PMTUD의 핵심은 IP 헤더에 있는 'DF(Don't Fragment) 비트'를 1로 설정하여 "절대 쪼개지 마세요!"라는 스티커를 붙이는 것입니다.
PMTUD 동작 원리 (초보자도 이해하는 단계별 설명)
🛫 (1단계) 일단 크게 보내보기: PC는 자신의 MTU(1500)에 맞춰 최대 크기 패킷에 "쪼개지 마!" (DF=1) 스티커를 붙여서 보냅니다.
🚧 (2단계) 중간에 장벽을 만나다: 패킷이 MTU가 1300으로 작은 구간(예: VPN 장비)을 만납니다.
🗣️ (3단계) "너무 커서 못 가!"라고 알려주기: "쪼개지 마!" 스티커 때문에 라우터는 패킷을 쪼개는 대신 버리고, 원래 패킷을 보냈던 PC에게 ICMP 메시지를 보냅니다. (메시지 내용: "네 패킷 너무 커서 못 보냈어. 여기 MTU는 1300이니까, 크기 줄여서 다시 보내!")
🔄 (4단계) 크기를 줄여 다시 보내기: ICMP 메시지를 받은 PC는 "아하! 저쪽 길은 좁구나!"라고 깨닫고, 패킷 크기를 1300에 맞춰 작게 만든 후 다시 보냅니다. 이제 패킷은 조각화 없이 무사히 목적지까지 도착합니다.
🚨 실무 사례: "글씨는 보이는데 이미지만 깨져요!"
고객사에서 VPN을 통해 웹 서버에 접속했는데, 텍스트는 잘 보이지만 이미지가 모두 '엑박'으로 뜨는 현상이 발생했습니다. 작은 텍스트 패킷은 문제가 없었지만, 용량이 큰 이미지 데이터는 큰 패킷으로 전송되다가 VPN 장비의 MTU 한계에 걸린 것입니다. PMTUD가 막혀있어 서버는 이 사실을 모르고 계속 큰 패킷을 보냈고, 결국 이미지가 깨져 보였던 것이죠. 이는 전형적인 PMTUD 실패 사례입니다.
[4장] 영웅의 시련: PMTUD는 왜 실패하고, 어떻게 해결할까?
가장 흔한 범인: ICMP 차단 (보안인가, 장애인가?)
PMTUD는 훌륭한 기술이지만, 안타깝게도 특정 상황에서는 제대로 동작하지 못합니다. PMTUD의 핵심은 라우터가 보내주는 ICMP 피드백 메시지인데, 많은 네트워크 관리자들이 보안을 이유로 방화벽에서 ICMP 프로토콜을 무조건 차단해버립니다.
문제: "너 패킷 너무 커!"라고 외치는 목소리(ICMP)를 막아버리니, 송신자는 왜 패킷이 사라지는지 영문도 모른 채 하염없이 재전송만 시도하다가 결국 통신을 포기하게 됩니다(Timeout). 이를 'PMTUD Blackhole' 이라고 부릅니다.
✅ 해결 방안: 방화벽에서 다른 ICMP는 차단하더라도, PMTUD에 필수적인 ICMP Type 3, Code 4 (Destination Unreachable, Fragmentation Needed) 메시지만큼은 꼭! 허용하도록 방화벽 정책을 수정하세요. 이것만으로도 수많은 네트워크 장애를 예방할 수 있습니다.
PMTUD 실패 시 대안 (플랜 B, 플랜 C)
ICMP를 허용할 수 없는 상황이라면, TCP MSS Clamping이 가장 현실적이고 권장되는 차선책입니다. 이 기능은 중간 장비(방화벽 등)가 TCP 연결 시 MSS 값을 강제로 특정 값(예: 1360) 이하로 낮춰버립니다. 이렇게 하면 애초에 클라이언트와 서버가 큰 패킷을 생성하지 않도록 원천 차단하여 PMTUD 실패 문제를 우회할 수 있습니다.
[5장] 직접 확인해보자! PMTUD 테스트 도구
우리 네트워크의 Path MTU는 얼마일까요? ping 명령어를 조금 특별하게 사용하면 직접 확인해볼 수 있습니다.
ping www.google.com -f -l 1472
# Linux / macOS:
ping www.google.com -D -s 1472
테스트 방법: 1472부터 시작해서 숫자를 10씩 줄여가며 명령을 실행해보세요. 에러 메시지가 나오지 않고 정상적으로 Ping이 가는 가장 큰 숫자가 바로 해당 경로의 (Path MTU - 28) 값입니다.
[마무리] PMTUD, 실무 엔지니어의 필수 소양
실무에서 "이상하게 이 서비스만 느려요", "큰 파일만 전송이 안 돼요" 같은 미스터리한 문제를 만났을 때, 오늘 배운 Path MTU를 의심하는 것은 문제 해결의 아주 중요한 첫걸음이 될 것입니다. 네트워크는 눈에 보이지 않지만, 이렇게 논리적인 원칙에 따라 움직입니다. 오늘 배운 지식이 여러분이 더 뛰어난 엔지니어링 역량을 갖추는 데 든든한 발판이 되기를 진심으로 바랍니다. 궁금한 점이 있다면 언제든 댓글로 질문해주세요! 😊
[부록]
간단 용어 정리
| 용어 | 설명 |
|---|---|
| MTU | 한 번에 전송 가능한 물리적 프레임의 최대 크기 (보통 1500바이트). |
| MSS | MTU에서 헤더를 제외한, 실제 데이터가 담기는 최대 크기. |
| PMTUD | 출발지에서 목적지까지 경로의 가장 작은 MTU를 찾는 기술. |
| Fragmentation | 큰 패킷을 작은 조각으로 나누는 것. 성능 및 보안 이슈를 유발함. |
| ICMP | 네트워크 상태 진단 및 오류 보고에 사용되는 프로토콜. PMTUD에 필수적. |
| TCP MSS Clamping | 중간 장비가 TCP MSS 값을 강제로 낮춰 MTU 문제를 예방하는 기술. |
자주 묻는 질문 (FAQ)
Q1: Ping은 잘 되는데 왜 웹사이트 이미지만 깨질까요?
A: 전형적인 PMTUD 실패 증상입니다. Ping 패킷은 작아서 MTU 제한에 걸리지 않지만, 이미지를 전송하는 TCP 패킷은 커서 중간 경로의 MTU 한계에 부딪히는 것입니다. 중간에서 ICMP가 차단되어 "패킷이 너무 크다"는 피드백을 받지 못해 발생하는 문제입니다.
Q2: UDP 통신에서도 PMTUD가 동작하나요?
A: 아니요, 기본적으로 PMTUD는 TCP 통신을 위한 메커니즘입니다. UDP 기반 애플리케이션은 PMTUD 문제에 더 취약할 수 있으며, 애플리케이션 레벨에서 자체적으로 패킷 크기를 조절하는 로직을 구현해야 합니다.
Q3: IPv6 환경에서는 PMTUD가 어떻게 다른가요?
A: 매우 중요한 포인트입니다. IPv6에서는 중간 라우터가 절대로 패킷을 조각화하지 않습니다. 패킷이 MTU보다 크면 무조건 버리고 ICMPv6 'Packet Too Big' 메시지를 보냅니다. 즉, IPv6는 PMTUD가 '선택'이 아닌 '필수'인 환경입니다.
더 상세한 내용은 Youtube채널(@NetworkingClass)을 참고해서 공부하실 수 있습니다.
아래 동영상을 참고하시면 내용을 이해하시는 데 더욱 도움이 될 것입니다.
댓글
댓글 쓰기