MTU(Maximum Transmission Unit) 최적화 가이드 – 패킷 크기 하나 바꿔서 네트워크 성능 올리는 법 4단계

MTU(Maximum Transmission Unit) 최적화 가이드

MTU(Maximum Transmission Unit) 최적화 가이드, 패킷 크기 하나 바꿔서 네트워크 성능 올리는 법 4단계

"MTU"를 적절하게 설정하면 불필요한 패킷 단편화(Fragmentation)를 없애고 네트워크 전송 효율을 높여 실질적인 처리량(Throughput)을 개선할 수 있다.

MTU는 네트워크에서 한 번에 전송할 수 있는 데이터 단위의 최대 크기다. 별것 아닌 것 같지만, 이게 맞지 않으면 진짜 이상한 증상들이 나온다. 특정 웹사이트만 안 열린다거나, 파일 전송이 중간에 끊긴다거나, VPN 연결이 되는데 특정 패킷이 안 간다거나. 이런 문제의 상당수가 MTU 불일치 때문이다.

📌  목차

• MTU가 뭔지도 모르고 네트워크 최적화 한다고?
• MTU 1500의 기원 – 왜 하필 이 값인가
• MTU 불일치가 만들어내는 골치 아픈 증상들
• Path MTU Discovery – 최적 MTU를 자동으로 찾는 방법
• Jumbo Frame – MTU 9000의 세계
• MTU 확인 및 변경 방법 (리눅스/윈도우 실전 예시)
• 정리

---

 

📦 MTU가 뭔지도 모르고 네트워크 최적화 한다고?

"MTU(Maximum Transmission Unit)"는 네트워크 인터페이스에서 한 번에 전송할 수 있는 최대 프레임 크기(바이트)다. 이더넷 기본값은 1500바이트다.

택배 비유로 설명하면, 택배 박스 최대 크기가 MTU다. 보내야 할 짐이 그 크기를 넘으면 여러 박스로 나눠서(단편화) 보내야 한다. 목적지에서 다시 합쳐야(재조립) 한다. 이 과정이 CPU 자원을 소비하고 지연을 만든다.

MTU는 계층별로 의미가 다르다:

• 이더넷 MTU: 1500바이트 (페이로드 기준)
• IP MTU: 이더넷 MTU 기준으로 IP 헤더(20바이트)를 뺀 1480바이트가 실제 IP 페이로드 최대값
• TCP MSS(Maximum Segment Size): IP 헤더 + TCP 헤더를 뺀 값. 표준 환경에서 보통 1460바이트

이 숫자들이 경로 중간에 있는 장치들과 맞지 않으면 문제가 생긴다.

---

📅 MTU 1500의 기원 – 왜 하필 이 값인가

1500이라는 숫자가 갑자기 나온 게 아니다. 1980년대 이더넷 표준을 만들 때 당시 하드웨어 성능과 메모리 비용을 고려해서 결정된 값이다.

크면 좋은 거 아닌가? 맞다. 큰 패킷 하나로 많은 데이터를 보내면 헤더 오버헤드 비율이 줄어서 효율이 좋다. 근데 너무 크면 오류 발생 시 재전송해야 하는 데이터가 커지고, 버퍼 메모리도 많이 필요하다.

1500이라는 값은 당시 기술 수준에서 효율과 안정성을 균형 맞춘 결과물이다. 그리고 이게 표준이 되면서 지금까지 이어져 왔다.

현대에는 Jumbo Frame(MTU 9000)이 있는데, 이건 데이터센터 내부처럼 단거리 고속 네트워크에서 쓰는 거다. 인터넷 구간에서는 여전히 1500이 기준이다.

---

💥 MTU 불일치가 만들어내는 골치 아픈 증상들

"MTU" 문제는 진단이 어렵기로 유명하다. 증상이 애매하기 때문이다.

전형적인 증상들:

• ping은 되는데 특정 서비스가 안 된다
• 작은 파일 전송은 되는데 큰 파일이 중간에 끊긴다
• VPN 연결은 됐는데 특정 트래픽이 안 지나간다
• 웹사이트 접속 시 HTML은 뜨는데 CSS/JS가 안 로딩된다 (큰 파일)

왜 이런 현상이 생기나?

작은 패킷은 어느 MTU 환경에서도 문제없이 통과한다. 근데 큰 패킷은 중간 경로의 MTU보다 크면 단편화가 일어나야 하는데, ICMP "Fragmentation Needed" 메시지가 방화벽 등에서 차단되면 발신 쪽이 패킷 크기를 줄여야 한다는 걸 모른다. 그래서 패킷이 그냥 드롭된다. 이게 "PMTUD Blackhole" 문제다.

VPN 환경에서 특히 자주 발생한다. VPN 터널링 자체가 오버헤드를 추가하기 때문에 실제 페이로드 MTU가 줄어든다. 예를 들어 IPSec VPN은 오버헤드가 50~60바이트 정도 된다. 물리 MTU가 1500이면, VPN 내부 MTU는 1440~1450 정도로 낮춰야 한다.

---

🔍 Path MTU Discovery – 최적 MTU를 자동으로 찾는 방법

"MTU" 문제를 자동으로 해결하는 메커니즘이 PMTUD(Path MTU Discovery)다.

동작 방식:

1. 송신 측이 DF(Don't Fragment) 비트를 설정한 패킷을 보낸다
2. 경로 중간에 MTU가 작은 장치가 있으면 패킷을 드롭하고 ICMP Type 3 Code 4 (Fragmentation Needed) 메시지를 반송한다
3. 송신 측이 이 메시지를 받고 패킷 크기를 줄인다
4. 이 과정을 반복해서 경로의 최소 MTU(Path MTU)를 파악한다

문제는 ICMP 메시지를 방화벽이 차단하는 경우다. 보안 정책으로 ICMP를 전부 막는 경우가 있는데, 이러면 PMTUD가 동작을 못 한다.

TCP에서는 MSS Clamping으로 이 문제를 우회한다. 라우터나 방화벽이 TCP SYN 패킷의 MSS 값을 강제로 낮춰서 처음부터 큰 패킷을 안 보내게 한다. 리눅스에서는 iptables로 구현한다:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

---

🚀 Jumbo Frame – MTU 9000의 세계

데이터센터 내부 네트워크에서는 "MTU" 9000(Jumbo Frame)을 많이 쓴다. 이유가 있다.

스토리지 트래픽(NFS, iSCSI)이나 vMotion 같은 대용량 데이터 전송 시, MTU를 9000으로 키우면:

• 단편화 없이 큰 데이터를 한 번에 전송
• 헤더 오버헤드 비율 감소
• CPU 인터럽트 수 감소 (패킷 수가 줄어드니까)

실제로 Jumbo Frame 적용 후 NFS 성능이 20~30% 향상되는 사례가 있다.

주의사항이 있다. Jumbo Frame은 경로상 모든 장치가 지원해야 한다. 서버만 9000으로 올리고 스위치가 1500으로 설정돼 있으면 오히려 패킷 손실이 발생한다. 서버, NIC, 스위치, 스위치 간 업링크까지 전부 9000으로 맞춰야 한다.

인터넷 구간에서 Jumbo Frame은 쓸 수 없다. 인터넷 백본은 대부분 1500이 기준이고, 이보다 큰 패킷은 중간에 드롭된다.

---

🔧 MTU 확인 및 변경 방법 (리눅스/윈도우 실전 예시)

리눅스에서 MTU 확인:

ip link show
# 또는
ifconfig

출력에서 mtu 1500 이런 식으로 보인다.

리눅스에서 임시 변경:

ip link set ens3 mtu 9000

리눅스에서 영구 변경 (NetworkManager):

nmcli connection modify ens3 ethernet.mtu 9000
nmcli connection up ens3

윈도우에서 확인:

netsh interface ipv4 show interfaces

윈도우에서 변경:

netsh interface ipv4 set subinterface "이더넷" mtu=9000 store=persistent

MTU 문제 진단 – ping으로 테스트:

# DF 비트 설정하고 특정 크기로 ping
ping -M do -s 1472 192.168.1.1
# 1472 + 28(헤더) = 1500 바이트
# 이 사이즈가 통과되면 MTU 1500 구간은 정상

# 더 큰 사이즈로 테스트
ping -M do -s 8972 192.168.1.1
# 8972 + 28 = 9000 바이트
# Jumbo Frame 구간 테스트

패킷이 드롭되면 Message too long 또는 Frag needed 응답이 온다. 이걸로 실제 MTU가 얼마인지 추정할 수 있다.

---

"MTU"는 눈에 보이지 않지만 네트워크 성능과 안정성에 큰 영향을 미치는 설정이다. 기본값이 잘못된 경우는 별로 없지만, VPN이나 터널링, 데이터센터 환경에서는 반드시 확인하고 최적화해야 한다. 그리고 MTU 관련 문제가 의심될 때 진단하는 방법을 알아두면, 나중에 분명히 써먹을 날이 온다.

---

출처 및 참고

• RFC 791 - Internet Protocol (IP Fragmentation): https://www.rfc-editor.org/rfc/rfc791
• RFC 1191 - Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc1191
• Linux ip command man page: https://man7.org/linux/man-pages/man8/ip.8.html