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

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

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

현장에서 몇 년을 굴러다니다 보면 네트워크 문제의 절반은 눈에 보이지 않는 곳에서 온다는 걸 몸으로 배우게 된다. 케이블 뽑혔나, 스위치 꺼졌나 이런 건 초보 때 이야기고, 어느 정도 연차가 쌓이면 패킷이 어디서 어떻게 깨지는지를 손끝으로 느끼게 된다. MTU가 딱 그런 놈이다. 수치 하나, 숫자 하나인데 이걸 잘못 잡으면 현장이 조용히 망가진다. 속도도 애매하고, 끊기는 것도 아닌데 뭔가 이상한 그 느낌. 알고 보면 MTU였던 경우가 한두 번이 아니었다.

MTU가 뭔지 현장 언어로 풀어보면

MTU는 Maximum Transmission Unit, 한 번에 보낼 수 있는 패킷의 최대 크기다. 이걸 택배 박스에 비유하면 이렇다. 트럭 하나에 박스를 몇 개나 실을 수 있냐가 아니라, 박스 하나의 최대 크기가 얼마냐의 문제다. 박스가 너무 크면 문을 못 통과하고, 너무 작으면 왕복 횟수가 늘어나서 시간이 걸린다. 이더넷 기본 MTU는 1500바이트다. 근데 이게 항상 최선이냐 하면 그건 또 아니다.

현장에서 겪은 일인데, VPN 터널 위에서 데이터를 주고받는 환경이었다. 속도가 이상하게 느렸다. ping은 살아있고, 파일 전송만 하면 중간에 뚝뚝 끊기는 느낌. Wireshark 열어보니 패킷 단편화가 끊임없이 일어나고 있었다. VPN 헤더가 붙으면서 실질적인 payload 공간이 줄었는데, MTU는 그대로 1500으로 물려있었던 거다. 줄자로 재지 않고 그냥 밀어넣다가 박스가 찌그러지는 꼴이었다.

장점은 분명하다. 최적화된 MTU는 단편화를 줄이고, 헤더 오버헤드 비율을 낮추며, 실질 처리량을 끌어올린다. 단점도 있다. 환경마다 적정값이 달라서 일률적으로 적용하면 오히려 역효과가 난다. 특히 혼합 환경, 즉 이더넷과 PPPoE가 섞이거나 VPN이 겹치거나 하면 수치 하나 잘못 건드렸다가 통신이 아예 안 되는 경우도 봤다. 섣불리 건드리는 게 오히려 독이 되는 셈이다.

1단계 현재 MTU 확인하기

일단 지금 뭐로 설정되어 있는지 봐야 한다. 모르고 건드리는 건 지도 없이 산에 들어가는 것과 같다. 리눅스 서버에서는 ip 명령어 하나면 된다.

ip link show eth0

출력에 mtu 1500 이라고 나오면 현재 이더넷 기본값을 쓰고 있는 거다. Windows 환경이라면 다음처럼 확인한다.

netsh interface ipv4 show subinterfaces

이걸 처음 쳤을 때 1500 아닌 값이 나왔을 때의 그 당혹감이 아직도 기억난다. 누군가 예전에 바꿔놓고 인수인계를 안 한 거였다. 현장에서 제일 무서운 게 누군가 건드린 흔적이 남아있는데 이유를 모르는 상황이다. 그래서 항상 확인부터다.

2단계 Path MTU Discovery로 적정값 찾기

이 단계가 핵심이다. 내 쪽 MTU만 바꾼다고 되는 게 아니라, 경로 전체에서 병목이 되는 지점의 MTU를 맞춰야 한다. 이걸 Path MTU Discovery라고 하는데, 쉽게 말하면 목적지까지 가는 길에서 제일 좁은 문이 어디냐를 찾는 과정이다. 좁은 문 기준으로 박스 크기를 맞춰야 안 막힌다.

리눅스에서 ping으로 찾는 방법이다.

ping -c 4 -M do -s 1472 8.8.8.8

여기서 -M do는 단편화를 금지하는 옵션이고, -s 1472는 payload 크기다. 1472에 IP 헤더 20바이트, ICMP 헤더 8바이트를 더하면 딱 1500이다. 이 명령이 성공하면 1500이 통하는 거고, 실패하면 숫자를 줄여가면서 통하는 최대치를 찾으면 된다.

ping -c 4 -M do -s 1400 8.8.8.8
ping -c 4 -M do -s 1300 8.8.8.8

이진 탐색처럼 줄여가면서 딱 통하는 최대 payload 크기를 찾으면 된다. 그 값에 28을 더한 게 실제 MTU 값이다. 처음에 이 작업을 수동으로 했을 때 너무 번거로워서 스크립트로 만들어뒀다. 현장에서 반복 작업은 자동화가 답이다.

3단계 MTU 값 변경 적용하기

적정값을 찾았으면 이제 적용이다. 리눅스에서 즉시 적용은 이렇게 한다.

ip link set dev eth0 mtu 1400

근데 이건 재부팅하면 날아간다. 영구 적용은 배포판마다 다르다. Ubuntu/Debian 계열은 netplan 설정 파일에 넣는 게 깔끔하다.

network:
  ethernets:
    eth0:
      mtu: 1400
  version: 2

적용 후에는 반드시 다시 확인한다.

netplan apply
ip link show eth0

Windows Server 환경에서는 레지스트리를 건드리거나 netsh 명령을 쓴다.

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

현장에서 이 작업을 할 때 제일 긴장되는 순간이 apply 치고 엔터 누를 때다. 잘못되면 원격 접속이 끊기는 경우가 있어서, 항상 콘솔 접근이나 iDRAC 같은 백도어를 확보해두고 작업한다. 아찔했던 경험이 있기 때문에 이건 습관이 됐다.

4단계 적용 후 검증하고 모니터링하기

바꿨다고 끝이 아니다. 실제로 나아졌는지 확인해야 한다. 단편화가 줄었는지 Wireshark로 보고, 처리량이 개선됐는지 iperf로 측정한다.

iperf3 -s

iperf3 -c 서버IP -t 30

30초 동안 테스트를 돌려서 Bandwidth 수치가 이전보다 올라갔는지 본다. 단편화 관련해서는 Wireshark 필터로 이렇게 잡으면 된다.

ip.flags.mf == 1 || ip.frag_offset > 0

이 필터로 걸리는 패킷이 현저히 줄어들면 MTU 최적화가 제대로 먹힌 거다. 처음 이걸 해봤을 때 단편화 패킷이 눈에 띄게 줄어드는 걸 보면서 묘한 쾌감이 있었다. 숫자 하나 바꿨는데 그래프가 달라지는 그 느낌.

모니터링은 지속적으로 해야 한다. 네트워크 환경이 바뀌면 최적 MTU도 달라질 수 있다. 새로운 장비가 들어오거나, VPN 정책이 바뀌거나 하면 다시 2단계부터 점검하는 게 맞다. 한 번 세팅해놓고 영원히 잊어버리면 언젠가 원인 모를 성능 저하로 돌아온다. 그게 현장이다.

마무리 생각

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