Uma MTU de VPN menor é mais rápida? Compare as evidências reais
Uma MTU mais baixa pode contornar um limite do caminho e ainda custar largura de banda. Compare a restrição real, o custo dos cabeçalhos e a carga antes de manter a mudança.
Um túnel descarta as transferências grandes mas deixa passar os ping, então o conselho chega rápido: baixe a MTU. A correção às vezes funciona, e depois é aplicada a cada perfil em cada rede. É aí que uma reparação direcionada se torna um imposto permanente sobre o desempenho. A comparação a fazer é entre o limite real do caminho e o custo de encolher cada pacote abaixo dele.
O que realmente encolhe quando baixa a MTU
Cada pacote carrega cabeçalhos antes de carregar os seus dados. Num caminho Ethernet de 1500 bytes, IPv4 e TCP consomem 40 bytes e deixam 1460 para a carga útil; o encapsulamento acrescenta por cima cabeçalhos externos de IP, UDP e túnel, pelo que o orçamento interno de carga volta a cair. Baixar a MTU da interface encolhe esse orçamento de propósito.
O custo é proporcional ao número de pacotes, não ao número de bytes. O mesmo ficheiro dividido em mais pacotes precisa de mais interrupções, mais decisões de encaminhamento e mais processamento por pacote em cada dispositivo do caminho. Num router que já está perto do seu limite de pacotes por segundo, isso é um abrandamento real e não um erro de arredondamento. O custo aparece mesmo quando a transferência tem sucesso.
Por isso uma MTU menor é um desvio para uma restrição, não uma otimização geral. Compra fiabilidade contra um caminho que não consegue transportar a trama maior e cobra sobrecarga por cada pacote que não precisava da redução.
Quando uma MTU menor é a correção certa
O sintoma clássico é concreto: o aperto de mão TCP conclui-se, chegam respostas pequenas e uma transferência grande encrava ou é reiniciada. Um ping com o bit de não fragmentar a 1472 bytes falha enquanto um ping de 1400 bytes tem sucesso, o que aponta para um caminho que não consegue transportar um pacote de tamanho completo e não entrega a mensagem ICMP que diria ao emissor para encolher.
A descoberta da MTU do caminho depende dessas mensagens ICMP de fragmentação necessária. Quando uma firewall as descarta, o emissor continua a repetir o pacote grande e a ligação parece bloquear. Baixar a MTU do lado do túnel evita a repetição, e isso é uma reparação legítima para essa rede.
As tecnologias de acesso também impõem os seus limites: PPPoE costuma limitar-se a 1492, alguns caminhos móveis e DSL são mais baixos, e os túneis encaixados retiram a sobrecarga duas vezes. Meça o caminho real em vez de copiar um número de um guia, e lembre-se de que IPv6 exige pelo menos 1280 bytes de MTU em qualquer ligação que o transporte, como especifica RFC 8200.
Compare os três controlos antes de mudar um
MTU, MSS e fragmentação são controlos diferentes em camadas diferentes, e mudar o errado deixa o sintoma no sítio.
| 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 é muitas vezes a reparação menos invasiva porque só afeta o TCP e deixa a interface livre para outro tráfego. Uma MTU de interface mais baixa é mais ampla e mais fácil de pensar, por isso é comum em routers domésticos, mas cobra a cada protocolo o problema de um só protocolo.
Desativar o comportamento de não fragmentar esconde o sintoma ao permitir a fragmentação, e normalmente piora a latência ao mesmo tempo que quebra o feedback que teria encontrado o tamanho certo. Evite-o como correção permanente.
Meça o compromisso em vez de um só número
Encontre o limite do caminho com uma sonda de não fragmentar, começando alto e descendo até chegar a resposta:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Depois compare a tarefa real nos dois ajustes: a mesma transferência de ficheiro, o mesmo endpoint e a mesma rede. Registre o tempo de conclusão e as retransmissões, por exemplo com nstat -az TcpRetransSegs, e observe a CPU do dispositivo se o túnel terminar num router pequeno. Um teste sintético curto de débito pode não ver o encrave que só aparece depois de vários megabytes.
Os contadores de pacotes vão subir após uma redução porque a mesma transferência usa agora mais pacotes. Isso é esperado e não é prova de maior débito. Compare os dados de aplicação concluídos, o número de retransmissões e a capacidade de resposta, não só a taxa de pacotes.
Introduza a mudança por etapas e mantenha-a limitada
Anote o valor original, mude um controlo e repita a medição antes de a tornar permanente. Se as evidências não mostrarem benefício, reponha o valor anterior com o mesmo comando de interface que usou para o definir:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Limite o resultado à rede que precisava dele. Um perfil que tem de funcionar num Wi-Fi de hotel, num hotspot móvel e numa LAN de escritório não deve herdar o valor mais baixo que qualquer um deles exige, a menos que o cliente não consiga detetar o caminho.
O valor certo é a maior MTU que sobrevive ao caminho, não a mais pequena que faz desaparecer o sintoma. Documente o caminho, o resultado da sonda e a reversão, e reveja o ajuste quando a rede de acesso mudar.