É máis rápida unha MTU de VPN máis pequena? Compare as probas reais
Unha MTU máis baixa pode esquivar un límite da ruta e aínda así custar rendemento. Compare a restrición real, o custo das cabeceiras e a carga antes de manter o cambio.
Un túnel descarta as transferencias grandes pero deixa pasar os ping, así que o consello chega rápido: baixe a MTU. A solución ás veces funciona, e despois aplícase a cada perfil en cada rede. Ese é o punto no que unha reparación dirixida se converte nun imposto permanente sobre o rendemento. A comparación que hai que facer é entre o límite real da ruta e o custo de encoller cada paquete por debaixo del.
Que encolle realmente cando baixa a MTU
Cada paquete leva cabeceiras antes de levar os seus datos. Nunha ruta Ethernet de 1500 bytes, IPv4 e TCP consomen 40 bytes e deixan 1460 para a carga útil; a encapsulación engade enriba cabeceiras externas de IP, UDP e túnel, así que o orzamento interior de carga volve baixar. Baixar a MTU da interface encolle ese orzamento a propósito.
O custo é proporcional ao número de paquetes, non ao número de bytes. O mesmo ficheiro dividido en máis paquetes necesita máis interrupcións, máis decisións de encamiñamento e máis procesamento por paquete en cada dispositivo da ruta. Nun router que xa está preto do seu límite de paquetes por segundo, iso é unha ralentización real e non un erro de redondeo. O custo aparece mesmo cando a transferencia ten éxito.
Por iso unha MTU máis pequena é un rodeo para unha restrición, non unha optimización xeral. Compra fiabilidade fronte a unha ruta que non pode levar a trama maior e cobra sobrecusto por cada paquete que non necesitaba a redución.
Cando unha MTU máis pequena é a solución correcta
O síntoma clásico é concreto: o aperto de mans TCP complétase, chegan respostas pequenas e unha descarga grande atasca ou reiníciase. Un ping co bit de non fragmentar a 1472 bytes falla mentres que un ping de 1400 bytes ten éxito, o que apunta a unha ruta que non pode levar un paquete de tamaño completo e non entrega a mensaxe ICMP que diría ao emisor que encolla.
O descubrimento da MTU da ruta depende desas mensaxes ICMP de fragmentación necesaria. Cando un cortalumes as descarta, o emisor segue reintentando o paquete grande e a conexión parece colgarse. Baixar a MTU do lado do túnel evita o reintento, e iso é unha reparación lexítima para esa rede.
As tecnoloxías de acceso tamén impoñen os seus propios límites: PPPoE adoita limitarse a 1492, algunhas rutas móbiles e DSL son máis baixas, e os túneles aniñados restan sobrecusto dúas veces. Mida a ruta real en lugar de copiar un número dunha guía, e lembre que IPv6 esixe polo menos 1280 bytes de MTU en calquera enlace que o transporte, como especifica RFC 8200.
Compare os tres controis antes de cambiar un
MTU, MSS e fragmentación son controis distintos en capas distintas, e cambiar o equivocado deixa o síntoma no seu sitio.
| 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 |
Limitar a MSS adoita ser a reparación menos invasiva porque só afecta a TCP e deixa a interface libre para outro tráfico. Unha MTU de interface máis baixa é máis ampla e máis fácil de razoar, por iso é habitual en routers de consumo, pero cobra a cada protocolo o problema dun só protocolo.
Desactivar o comportamento de non fragmentar oculta o síntoma ao permitir a fragmentación, e normalmente empeora a latencia á vez que rompe a retroalimentación que tería atopado o tamaño correcto. Evíteo como solución permanente.
Mida o compromiso en lugar dun só número
Atope o límite da ruta cunha sonda de non fragmentar, comezando alto e baixando ata que chegue a resposta:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Despois compare a tarefa real con ambos os axustes: a mesma transferencia de ficheiro, o mesmo extremo e a mesma rede. Rexistre o tempo de finalización e as retransmisións, por exemplo con nstat -az TcpRetransSegs, e vixíe a CPU do dispositivo se o túnel remata nun router pequeno. Unha proba sintética curta de rendemento pode non ver o atasco que só aparece tras varios megabytes.
Os contadores de paquetes subirán tras unha redución porque a mesma transferencia agora usa máis paquetes. Iso é esperable e non é proba de maior rendemento. Compare os datos de aplicación completados, o número de retransmisións e a capacidade de resposta, non só a taxa de paquetes.
Introduza o cambio por etapas e mantéñao acoutado
Anote o valor orixinal, cambie un control e repita a medición antes de facelo permanente. Se as probas non mostran un beneficio, restaure o valor anterior co mesmo comando de interface que usou para fixalo:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Acoite o resultado á rede que o necesitaba. Un perfil que debe funcionar nun Wi-Fi de hotel, un punto de acceso móbil e unha LAN de oficina non debería herdar o valor máis baixo que exixa calquera deles, salvo que o cliente non poida detectar a ruta.
O valor correcto é a MTU máis grande que sobrevive á ruta, non a máis pequena que fai desaparecer o síntoma. Documente a ruta, o resultado da sonda e a reversión, e revise o axuste cando cambie a rede de acceso.