VPN MTU를 작게 하면 더 빠른가? 실제 증거를 비교하세요
MTU를 낮추면 경로 한계를 피할 수 있지만 처리량을 치를 수 있습니다. 변경을 유지하기 전에 실제 제약, 헤더 오버헤드, 작업 부하를 비교하세요.
터널은 큰 전송을 떨어뜨리지만 핑은 통과시키므로 조언은 빨리 옵니다. MTU를 낮추라는 것입니다. 그 수정은 때때로 효과가 있고, 그러면 모든 네트워크의 모든 프로필에 적용됩니다. 바로 그 지점에서 표적 수리가 영구적인 성능 세금이 됩니다. 해야 할 비교는 경로의 실제 한계와 그 아래로 모든 패킷을 줄이는 비용 사이입니다.
MTU를 낮추면 실제로 무엇이 줄어드는가
모든 패킷은 데이터를 실어 나르기 전에 헤더를 실어 나릅니다. 1500바이트 이더넷 경로에서 IPv4와 TCP는 40바이트를 쓰고 1460을 페이로드로 남깁니다. 캡슐화는 그 위에 외부 IP, UDP, 터널 헤더를 더하므로 내부 페이로드 예산은 다시 줄어듭니다. 인터페이스 MTU를 낮추는 것은 그 예산을 의도적으로 줄이는 일입니다.
비용은 바이트 수가 아니라 패킷 수에 비례합니다. 같은 파일을 더 많은 패킷으로 나누면 경로상의 모든 장치에서 더 많은 인터럽트, 더 많은 라우팅 결정, 패킷당 더 많은 처리가 필요합니다. 이미 초당 패킷 한계에 가까운 라우터에서는 그것이 반올림 오차가 아니라 실제 느려짐입니다. 전송 자체가 성공해도 비용은 나타납니다.
그래서 작은 MTU는 제약을 우회하는 방법이지 일반적인 최적화가 아닙니다. 더 큰 프레임을 실을 수 없는 경로에 대해 신뢰성을 사고, 축소가 필요 없던 패킷에도 오버헤드를 부과합니다.
작은 MTU가 올바른 수정인 경우
전형적인 증상은 구체적입니다. TCP 핸드셰이크가 끝나고 작은 응답은 도착하는데 큰 다운로드가 멈추거나 재설정됩니다. 단편화 금지 비트를 붙인 1472바이트 핑은 실패하고 1400바이트 핑은 성공합니다. 이는 전체 크기 패킷을 실을 수 없고 송신자에게 줄이라고 알려 줄 ICMP 메시지를 전달하지 않는 경로를 가리킵니다.
경로 MTU 검색은 그 ICMP 단편화 필요 메시지에 의존합니다. 방화벽이 그것을 버리면 송신자는 큰 패킷을 계속 다시 시도하고 연결은 멈춘 것처럼 보입니다. 터널 쪽에서 MTU를 낮추면 재시도를 피할 수 있고, 그것은 그 네트워크에 정당한 수리입니다.
액세스 기술도 자체 한계를 둡니다. PPPoE는 보통 1492에서 끝나고, 일부 모바일 및 DSL 경로는 더 낮으며, 중첩 터널은 오버헤드를 두 번 뺍니다. 안내서의 숫자를 복사하지 말고 실제 경로를 측정하고, IPv6는 그를 실어 나르는 모든 링크에서 최소 1280바이트 MTU를 요구한다는 점을 기억하세요. RFC 8200이 규정한 대로입니다.
하나를 바꾸기 전에 세 가지 제어를 비교하세요
MTU, MSS, 단편화는 서로 다른 계층의 서로 다른 제어입니다. 잘못된 것을 바꾸면 증상은 그대로 남습니다.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS 제한은 흔히 가장 침습이 적은 수리입니다. TCP에만 영향을 주고 인터페이스를 다른 트래픽에 비워 두기 때문입니다. 인터페이스 MTU를 낮추는 방법은 범위가 넓고 따지기 쉬워 가정용 라우터에서 흔하지만, 한 프로토콜의 문제를 모든 프로토콜에 부과합니다.
단편화 금지 동작을 끄면 단편화를 허용해 증상을 숨깁니다. 또한 올바른 크기를 찾았을 피드백을 깨뜨리면서 지연을 악화시키는 경우가 많습니다. 영구적 수정으로는 피하세요.
숫자 하나가 아니라 절충을 측정하세요
단편화 금지 프로브로 경로 한계를 찾으세요. 높은 값에서 시작해 응답이 올 때까지 내려갑니다.
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10그다음 두 설정에서 실제 작업을 비교하세요. 같은 파일 전송, 같은 엔드포인트, 같은 네트워크입니다. 완료 시간과 재전송을 기록하고, 예를 들어 nstat -az TcpRetransSegs를 사용하며, 터널이 작은 라우터에서 끝난다면 장치 CPU도 보세요. 짧은 합성 처리량 시험은 몇 메가바이트 뒤에야 나타나는 멈춤을 놓칠 수 있습니다.
축소 후에는 패킷 카운터가 올라갑니다. 같은 전송이 이제 더 많은 패킷을 쓰기 때문입니다. 그것은 예상된 일이며 더 높은 처리량의 증거가 아닙니다. 완료된 애플리케이션 데이터, 재전송 횟수, 응답성을 비교하세요. 패킷 속도만 보지 마세요.
변경은 단계적으로 적용하고 범위를 좁게 유지하세요
원래 값을 기록하고, 제어 하나를 바꾸고, 영구화하기 전에 측정을 반복하세요. 증거가 이득을 보이지 않으면 설정할 때 쓴 것과 같은 인터페이스 명령으로 이전 값으로 되돌리세요.
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500결과를 그것이 필요했던 네트워크로 한정하세요. 호텔 Wi-Fi, 모바일 핫스폿, 사무실 LAN에서 동작해야 하는 프로필은 클라이언트가 경로를 감지할 수 없는 한 그중 하나가 요구하는 가장 낮은 값을 물려받아서는 안 됩니다.
올바른 값은 경로를 견디는 가장 큰 MTU이며, 증상을 사라지게 하는 가장 작은 값이 아닙니다. 경로, 프로브 결과, 되돌리기를 기록하고 액세스 네트워크가 바뀌면 설정을 다시 검토하세요.