MTU / MSS 계산기 — PPPoE·MAP-E·IPsec·WireGuard 오버헤드
PPPoE·MAP-E/DS-Lite·GRE·WireGuard·VXLAN·IPsec(ESP 패딩 계산 포함)를 쌓아 유효 MTU와 TCP MSS를 구하고, Cisco·YAMAHA RTX·Linux 설정 예시와 확인용 DF 핑을 출력합니다.
🔒 모두 브라우저 안에서 동작합니다. 입력과 출력은 서버로 전송되거나 저장되지 않아 안전합니다.
내역
설정 예시
DF 핑으로 확인
페이로드 = MTU − 28(IPv4 20 + ICMP 8). 이 값은 통과하고 +1은 실패하면 경로 MTU가 확정됩니다.
MSS는 IPv4에서 MTU − 40(IP 20 + TCP 20), IPv6에서 MTU − 60. MTU가 줄어드는 장비에서 MSS를 클램프하면 TCP가 단편화가 필요한 세그먼트를 보내지 않습니다.
이 도구 소개
이 MTU·MSS 계산기는 회선이 캡슐화되었을 때 실제로 통과할 수 있는 패킷 크기를 구합니다. 회선 MTU에서 시작해 트래픽이 실제로 거치는 계층(PPPoE, MAP-E·DS-Lite용 IPv4 over IPv6, GRE, WireGuard, VXLAN, NAT-T 포함 IPsec)을 고르면 유효 MTU, IPv4·IPv6 TCP MSS, 계층별 내역, Cisco IOS·YAMAHA RTX·Linux 설정 예시, 그리고 실제 회선에서 확인할 DF 비트 핑 명령을 보여 줍니다. IPsec은 어림값이 아니라 ESP 패딩을 실제로 계산합니다. 모든 처리는 브라우저 안에서 이루어집니다.
자주 묻는 질문
플레츠 PPPoE MTU는 왜 1492가 아니라 1454인가요?
PPPoE 자체 오버헤드는 8바이트라 이더넷에서 이론값은 1492입니다. 그래도 NTT 동·서는 플레츠 광의 권장값으로 1454를 공개하며, 그 차이는 접속망 내부의 추가 오버헤드에 대한 여유로 설명되는 것이 일반적입니다. 실무에서는 1454가 안전한 선택입니다. 몇 바이트의 효율을 내주고 어떤 경로에서도 단편화와 통신 정체를 피할 수 있습니다.
MSS 클램프란 무엇이고 왜 필요한가요?
TCP는 연결 시작 시 양 끝 각자의 인터페이스를 기준으로 최대 세그먼트 크기를 정하지만, 단말은 경로 너머의 터널을 알지 못합니다. 원래 경로 MTU 탐색이 ICMP '단편화 필요' 메시지로 보정하지만 ICMP를 막는 네트워크가 많아, 작은 페이지는 열리는데 큰 다운로드나 일부 HTTPS 사이트만 멈추는 전형적인 증상이 나타납니다. MSS 클램프는 MTU가 줄어드는 라우터에서 지나가는 SYN의 MSS를 고쳐 써서 너무 큰 세그먼트가 아예 전송되지 않게 합니다.
IPv6는 무엇이 다른가요?
세 가지가 다릅니다. 헤더가 20바이트 커서 MSS는 MTU − 40이 아니라 MTU − 60입니다. 라우터는 중간에서 IPv6를 단편화하지 않으므로 경로 MTU 탐색이 필수이며, ICMPv6 'Packet Too Big'을 막으면 통신이 확실히 깨집니다. 그리고 모든 IPv6 링크는 최소 1280바이트를 실어야 해서 Cisco 예시에서 IPv6 MTU를 그 아래로 두지 않습니다. 일본의 MAP-E와 DS-Lite는 IPv4를 IPv6 안에 넣어 나르는 방식으로, 익숙한 1460이 여기서 나옵니다.
IPsec 오버헤드는 왜 고정값이 아닌가요?
ESP는 페이로드와 2바이트 트레일러의 합이 암호 블록의 정수배가 되도록 패딩하기 때문입니다. AES-CBC는 블록이 16바이트라 패킷 크기에 따라 패딩이 0~15바이트로 달라지고, 여기에 16바이트 IV와 인증 태그가 더해집니다. AES-GCM은 4바이트 경계만 맞추고 IV도 8바이트라 낭비가 적습니다. 자료마다 수치가 다른 이유이며, 이 도구는 실제로 들어가는 가장 큰 내부 패킷을 계산합니다.
입력 내용이 서버로 전송되나요?
아니요. 계산과 설정 예시 생성은 모두 브라우저 안 JavaScript로 이루어지므로 네트워크 설계 정보가 기기 밖으로 나가지 않고, 페이지를 불러온 뒤에는 오프라인에서도 동작합니다. 핑 명령은 직접 실행하기 위한 것이며 이 페이지는 어떤 탐색 패킷도 보내지 않습니다.