- MTU와 MSS의 차이, 각종 헤더 오버헤드 계산법, Ping으로 MTU 문제를 직접 진단하는 방법
- 적용 환경: Windows / Linux (Ubuntu)
- GitHub 저장소: https://github.com/20eung/mtu-mss
1. MTU와 MSS의 차이는?
25년 넘게 네트워크를 다루면서 신입 엔지니어들이 가장 많이 헷갈려하는 개념 중 하나가 MTU와 MSS입니다. 두 개념의 차이를 모르면 VPN 터널에서 패킷이 잘리거나, 특정 사이트만 느려지는 증상의 원인을 찾지 못합니다. 이 글에서는 MTU와 MSS의 차이, 각종 헤더 오버헤드 계산법, Ping으로 MTU 문제를 직접 진단하는 방법 3가지를 다룹니다.
1.1 MTU (Maximum Transmission Unit) — MTU와 MSS 핵심 정의
MTU는 네트워크에서 한 번에 전송할 수 있는 최대 데이터 크기(헤더 포함)입니다.
- 동작 계층: 2계층 (데이터링크 계층)
- 단위: 바이트(Byte) = 옥텟(Octet)
- 일반 이더넷 기본값: 1,500 바이트
MTU를 초과하는 패킷은 두 가지 처리 중 하나를 겪습니다.
– 분할(Fragmentation): 패킷을 MTU 크기에 맞게 쪼개어 전송
– 폐기(Drop): DF(Don’t Fragment) 비트가 설정된 경우 패킷을 버리고 ICMP 오류 반환
1.2 MSS (Maximum Segment Size) — MTU와 MSS 핵심 정의
MSS는 4계층(TCP)에서 순수하게 전달할 수 있는 데이터의 최대 크기입니다. 헤더를 제외한 순수 페이로드 크기입니다.
MSS = MTU - IP 헤더(20) - TCP 헤더(20)
= 1500 - 20 - 20
= 1,460 바이트
| 항목 | 계층 | 기본값 | 헤더 포함 여부 |
|---|---|---|---|
| MTU | 2계층 | 1,500 바이트 | 포함 |
| MSS | 4계층 | 1,460 바이트 | 미포함 (순수 데이터만) |
2. 헤더 크기 총정리
네트워크 터널링 기술을 쓸수록 헤더 오버헤드가 쌓입니다. 실무에서 자주 쓰는 헤더 크기를 정리했습니다.
| 프로토콜 | 헤더 크기 | 비고 |
|---|---|---|
| TCP | 20 Bytes | 옵션 헤더 제외 |
| UDP | 8 Bytes | |
| IPv4 | 20 Bytes | |
| ICMP | 8 Bytes | |
| GRE | 24 Bytes | IP Protocol 47, RFC 2784 |
| 6in4 | 20 Bytes | IP Protocol 41, RFC 4213 |
| MPLS | 4 Bytes | 레이블 1개 기준 |
| IEEE 802.1Q | 4 Bytes | VLAN 태그 |
| Q-in-Q | 8 Bytes | 802.1ad |
| VxLAN | 50 Bytes | UDP 8 + VxLAN 8 + Eth 14 + IP 20 |
| IPSec (ESP/AES) | 50~93 Bytes | 알고리즘·모드에 따라 가변 |
💼 팁: VxLAN 오버레이 환경에서는 물리 MTU를 1,550 이상(보통 1,600 또는 9,000 Jumbo Frame)으로 설정해야 내부 패킷이 잘리지 않습니다.
3. IPSec VPN을 쓰면 왜 패킷이 잘릴까?
IPSec VPN 터널에서 특정 애플리케이션만 느리거나 안 되는 증상의 대부분은 MTU 문제입니다.
3.1 ESP(Encapsulating Security Payload) 오버헤드 계산
ESP 터널 모드(AES 암호화)를 기준으로 한 오버헤드:
Outer IP Header: 20 Bytes
Sequence Number: 4 Bytes
SPI: 4 Bytes
Initialization Vector: 16 Bytes ← AES 사용 시
ESP Padding: 0~15 Bytes ← 가변
Padding Length: 1 Bytes
Next Header: 1 Bytes
Authentication Data: 12~32 Bytes ← 인증 알고리즘에 따라
─────────────
Total: 58~93 Bytes
AES + SHA-256 조합 기준 일반적인 오버헤드: 약 73~88 바이트
3.2 IPSec 터널에서의 유효 MSS 계산
표준 이더넷 MTU: 1,500 Bytes
- IP 헤더: - 20 Bytes
- TCP 헤더: - 20 Bytes
- IPSec ESP 오버헤드: - 73~88 Bytes
────────────
유효 MSS: 1,372~1,387 Bytes
AES ESP 사용 시 이상적인 MSS 값은 1,328 바이트로 알려져 있습니다.
(참고: IPSec Bandwidth Overhead Using AES — PacketPushers)
💼 팁: 터널 모드는 원본 IP 패킷 전체를 새 IP 패킷으로 감싸므로 IP 헤더가 하나 더 추가됩니다(+20 Bytes).
4. Ping으로 MTU와 MSS 문제 직접 진단하기
MTU 문제를 확인하는 가장 빠른 방법은 DF 비트를 설정한 Ping입니다. 패킷이 특정 크기에서 막히면 MTU 문제임을 즉시 확인할 수 있습니다.
4.1 Windows에서 MTU와 MSS Ping 진단
-f 옵션은 DF(Don’t Fragment) 비트 설정, -l 옵션은 송신 데이터 크기입니다.
REM 1472 바이트 (ICMP 기준 이더넷 최대값) — 성공해야 정상 C:\> ping 172.16.32.1 -f -l 1472 Pinging 172.16.32.1 with 1472 bytes of data: Reply from 172.16.32.1: bytes=1472 time=3ms TTL=251 Reply from 172.16.32.1: bytes=1472 time=4ms TTL=251
REM 1473 바이트 — MTU 초과, 폐기됨 C:\> ping 172.16.32.1 -f -l 1473 Pinging 172.16.32.1 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set.
ICMP 기준 최대 송신 크기 계산:
MTU 1500 - ICMP 헤더 8 - IP 헤더 20 = 1,472 바이트
4.2 Linux(Ubuntu)에서 MTU와 MSS Ping 진단
-s 옵션은 데이터 크기, -M do는 DF 비트 설정입니다.
# 1472 바이트 — 성공해야 정상 $ ping -s 1472 -M do 192.168.25.25 PING 192.168.25.25 (192.168.25.25) 1472(1500) bytes of data. 1480 bytes from 192.168.25.25: icmp_seq=1 ttl=62 time=3.77 ms 1480 bytes from 192.168.25.25: icmp_seq=2 ttl=62 time=3.25 ms
# 1473 바이트 — MTU 초과 $ ping -s 1473 -M do 192.168.25.25 PING 192.168.25.25 (192.168.25.25) 1473(1501) bytes of data. From 192.168.25.26 icmp_seq=1 Frag needed and DF set (mtu = 1500) ping: local error: message too long, mtu=1500
4.3 IPSec 터널 구간 MTU 찾기
IPSec 터널을 통과하는 경우 이진 탐색으로 실제 허용 크기를 찾습니다.
REM 1472 → 실패, 1384 → 성공이면 터널 MTU ≈ 1384+28 = 1412 근처 C:\> ping 172.16.68.1 -f -l 1384 Reply from 172.16.68.1: bytes=1384 time=8ms TTL=251
💡 팁: 1472 실패 → 1200 시도 → 성공이면 1200~1472 사이 탐색 → 1336 → … 이렇게 범위를 좁혀나갑니다.
5. 자주 발생하는 오류와 해결법
| 증상 | 원인 | 해결 방법 |
|---|---|---|
Packet needs to be fragmented but DF set |
패킷 크기가 경로 MTU 초과 | 라우터/방화벽에서 ip tcp adjust-mss 설정 또는 MTU 축소 |
Frag needed and DF set (mtu = 1500) |
Linux에서 동일 증상 | 인터페이스 MTU 조정: ip link set eth0 mtu 1400 |
| VPN 연결 후 특정 사이트만 느림 | IPSec 오버헤드로 인한 실질 MTU 감소 | TCP MSS Clamping 설정 (FortiGate: set tcp-mss-sender, set tcp-mss-receiver) |
| 대용량 파일 전송 실패, 소용량은 정상 | MTU 경계값 근처 패킷 폐기 | PMTUD(Path MTU Discovery) 동작 확인, ICMP Type 3 Code 4 차단 여부 점검 |
6. 헤더 구조 한눈에 보기
실제 패킷 캡쳐에서 본 각 헤더의 구조입니다. 위에서 다룬 오버헤드 계산이 어떤 필드에 해당하는지 그림으로 확인하세요.
6.1 TCP Header (20 Bytes) — MTU와 MSS 계산 근거
6.2 IP Header (20 Bytes) — MTU와 MSS 계산 근거
6.3 UDP Header (8 Bytes) — MTU와 MSS 계산
6.4 ICMP Header (8 Bytes) — MTU와 MSS Ping 진단
6.5 ARP Header 구조
7. Jumbo Frame 실전 가이드
표준 이더넷 MTU가 1,500 바이트인 이유는 전기·광 신호 감지 오류율과 충돌 감지 효율을 양립시키기 위한 역사적 결정입니다. 하지만 데이터센터 내부처럼 단일 운영 주체가 모든 장비를 통제할 수 있는 환경에서는 Jumbo Frame(일반적으로 9,000 바이트)을 켜서 같은 대역폭에서 더 많은 페이로드를 실어 나를 수 있습니다.
7.1 Jumbo Frame이 효과적인 경우
- 스토리지 트래픽: iSCSI, NFSv4, SMB 다중 채널처럼 큰 블록 단위 전송
- 동일 VLAN 대용량 백업: rsync, robocopy, Bacula 같은 도구의 시퀀스 처리
- 가상화 호스트 간 vMotion: 메모리 상태 덤프가 한 번에 전송됨
반대로 라우터를 가로지르는 WAN 트래픽, 클라우드 VPN 터널, 인터넷 일반 트래픽에서는 Jumbo Frame이 거의 도움이 되지 않습니다. 경로상 한 hop이라도 MTU 1,500만 지원하면 패킷이 분할되거나 폐기됩니다.
7.2 Jumbo Frame 설정 시 체크리스트
Jumbo Frame은 경로상의 모든 장치가 동일한 MTU를 지원해야만 효과가 있습니다. 한 군데라도 어긋나면 PMTUD가 정상 동작하지 않거나, ICMP가 막혀 있으면 침묵의 성능 저하가 생깁니다.
- 서버 NIC MTU:
ip link set eth0 mtu 9000 - 스위치 포트 MTU: 대부분 vendor 마다 별도 명령 (Cisco:
system mtu jumbo 9000등) - 운영 체제 확인: Linux는 인터페이스와 라우트 양쪽, Windows는 NIC 어댑터 설정 + 레지스트리
- 양 끝단 ping 테스트:
ping -s 8972 -M do <상대>로 9,000 바이트 통화 확인
💡 팁: Jumbo Frame 적용 후 회귀 테스트로 8,972 (9000 - 28) 바이트 ping을 던져 보세요. 작은 ping (1,472 바이트)은 Jumbo와 표준 MTU 양쪽 모두에서 성공하므로 Jumbo 전용 회귀 테스트로는 부적합합니다.
8. PMTUD(Path MTU Discovery) 동작 원리 상세
PMTUD는 RFC 1191에서 표준화된 메커니즘으로, 송신자가 DF(Don’t Fragment) 비트가 설정된 패킷을 보내고 라우터가 “이보다 큰 패킷은 못 보냄”을 알려주면 그 크기로 MSS를 자동 축소합니다.
8.1 PMTUD 정상 동작 흐름
1. 송신자가 MSS=1460 으로 TCP 연결 시작 (SYN 패킷)
2. SYN+DATA 도달 → 중간 라우터에서 MTU=1400 발견
3. 라우터가 ICMP Type 3 Code 4 ("Fragmentation Needed and DF set") 송신자에게 응답
4. 송신자가 MSS=1360 (1400 - 40) 로 재시도
5. 이후 모든 패킷을 1360 이하로 전송
8.2 PMTUD가 깨지는 흔한 원인
| 원인 | 증상 | 해결 |
|---|---|---|
| 방화벽이 ICMP Type 3 차단 | 패킷 소멸, 연결은 성립되지만 대용량 전송만 실패 | ICMP Type 3 Code 4 허용 정책 추가 |
| VPN 터널 캡슐화로 인한 추가 오버헤드 | 터널 통과 트래픽만 부분 실패 | TCP MSS Clamping (서버/방화벽에서 MSS 자동 축소) |
| IPv4/IPv6 듀얼스택 환경에서 한 쪽만 차단 | IPv6 연결만 느림 | 양쪽 패밀리 정책 일관성 유지 |
| 비공개 peering 시 ICMP 정책 부재 | 클라우드 간 직접 연결만 실패 | CSP 별 권고 설정 확인 (Azure, AWS 등) |
💡 팁: PMTUD는 한 방향의 경로에만 동작합니다. 양방향 MTU가 다를 수 있으므로 양쪽 ping 테스트를 모두 수행해야 정확한 진단이 가능합니다.
9. 디바이스별 TCP MSS Clamping 설정 예시
MTU 진단 후 근본적으로 해결할 수 없는 환경(예: ICMP 차단 정책상 PMTUD가 무력화된 WAN)에서는 MSS Clamping으로 강제 축소하는 것이 표준 해법입니다. 주요 디바이스별 설정 예시입니다.
9.1 FortiGate (방화벽 정책 단계)
config firewall policy
edit 0
set name "vpn-out-mss-clamp"
set srcintf "port1"
set dstintf "port2"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set tcp-mss-sender 1360
set tcp-mss-receiver 1360
next
end
9.2 Linux iptables
# MSS=1360 으로 SYN 패킷 강제 변경 (경로 MTU=1400 가정)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1360
9.3 Cisco IOS (라우터 인터페이스 단계)
interface GigabitEthernet0/0 ip tcp adjust-mss 1360
9.4 Windows (PowerShell)
Windows는 OS 단계 MSS 옵션이 제한적이므로 NIC 어댑터의 Jumbo Packet / MTU 값 또는 레지스트리 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery 로 제어합니다.
💡 팁: 양 방향 모두에 적용해야 합니다. 송신측만 조정하면 응답 패킷의 MSS가 그대로 1,460 이어서 일부 환경에서는 회귀가 발생합니다.
10. 자주 묻는 질문 (FAQ)
10.1 MSS와 MTU 중 어느 것을 우선 조정해야 하나요?
대부분의 환경에서는 MTU를 그대로 두고 MSS만 조정하는 것이 안전합니다. MTU 변경은 NIC, 스위치, NIC 드라이버, 운영체제 라우팅 테이블 등 광범위한 영향을 주기 때문입니다. MSS Clamping은 SYN 패킷만 rewrite 하므로 영향 범위가 좁고 롤백도 쉽습니다.
10.2 클라우드 환경에서 권장 MSS 값은?
| 환경 | 권장 MSS |
|---|---|
| 일반 인터넷 (VPN 없음) | 1,460 (기본) |
| AWS Site-to-Site VPN | 1,387 (Tunnel 1 MTU=1,391 기준) |
| Azure VPN Gateway | 1,350 (보수적 권고) |
| GCP Cloud VPN | 1,380 |
| WireGuard 터널 | 1,380 |
| IPSec/AES ESP | 1,328 |
CSP 별 권고값은 정기적으로 갱신되므로, 적용 전 해당 CSP 공식 문서를 한 번 더 확인하세요.
10.3 traceroute 결과만으로 MTU 문제를 진단할 수 있나요?
traceroute는 도달 가능성과 경로를 보여주지만 최대 MTU는 알려주지 않습니다. MTU 진단은 반드시 DF 비트가 설정된 ping(ping -f -l 또는 ping -M do)으로만 가능합니다. traceroute 의 작은 TTL 만료 패킷은 일반 MTU 1,500 안에 들어가므로 MTU 문제 자체를 가려버립니다.
11. 마치며
이 글에서는 MTU와 MSS의 정의부터 헤더 크기, IPSec VPN 환경의 패킷 잘림 원인, Ping 기반 진단법, 자주 발생하는 오류, 그리고 데이터센터 환경의 Jumbo Frame, WAN의 PMTUD 동작 원리, MSS Clamping 디바이스별 설정, FAQ까지 정리했습니다. 가장 중요한 한 가지를 꼽자면:
🎯 핵심 요약
- MTU = 2계층 최대 전송 단위, 일반 이더넷 기본값 1,500 바이트
- MSS = 4계층 TCP 순수 페이로드 최대값, 기본 1,460 바이트
- IPSec 터널 = 오버헤드(58~93 Bytes)만큼 유효 MSS 감소 → 1,300대 설정 권장
- Ping -f = MTU 문제 현장 진단의 가장 빠른 방법
- PMTUD = ICMP Type 3 Code 4 가 살아 있어야만 동작
- MSS Clamping = PMTUD가 무력화된 WAN 에서의 마지막 안전망
네트워크 트러블슈팅은 “한 가지 가설에 매몰되지 않는 것”이 핵심입니다. DNS 문제로 보이는 증상이 사실은 MTU 문제였던 경우를 여러 번 겪었습니다. 위 진단 절차를 순서대로 적용하면 거의 모든 MTU/MSS 관련 이슈는 30분 안에 원인을 좁힐 수 있습니다.
추가로 다루었으면 하는 시나리오(예: 클라우드 Load Balancer + MSS, 컨테이너 네트워크 MTU, Kubernetes CNI MTU)가 있다면 댓글로 알려주세요.
