És més ràpid un MTU de VPN més petit? Compareu les proves reals
Un MTU més baix pot esquivar un límit del camí i, tot i així, costar amplada de banda. Compareu la restricció real, el cost de les capçaleres i la càrrega abans de mantenir el canvi.
El túnel descarta transferències grans però deixa passar els ping, així que el consell arriba de seguida: baixa l’MTU. La solució de vegades funciona i després s’aplica a cada perfil de cada xarxa. És aquí on una reparació específica es converteix en un impost permanent sobre el rendiment. La comparació que cal fer és entre el límit real del camí i el cost d’encongir cada paquet per sota seu.
Què s’encongeix realment quan baixes l’MTU
Cada paquet porta capçaleres abans de portar les teves dades. En un camí Ethernet de 1500 bytes, IPv4 i TCP consumeixen 40 bytes i en deixen 1460 per a la càrrega útil; l’encapsulació hi afegeix a sobre capçaleres externes d’IP, UDP i túnel, així que el pressupost interior de càrrega torna a baixar. Baixar l’MTU de la interfície encongeix aquest pressupost deliberadament.
El cost és proporcional al nombre de paquets, no al nombre de bytes. El mateix fitxer dividit en més paquets necessita més interrupcions, més decisions d’encaminament i més processament per paquet a cada dispositiu del camí. En un encaminador que ja és a prop del seu límit de paquets per segon, això és una alentiment real i no un error d’arrodoniment. El cost apareix fins i tot quan la transferència té èxit.
Per això un MTU més petit és una solució alternativa a una restricció, no una optimització general. Compra fiabilitat davant d’un camí que no pot portar la trama més gran i cobra sobrecost per cada paquet que no necessitava la reducció.
Quan un MTU més petit és la solució correcta
El símptoma clàssic és específic: l’apretada de mans TCP es completa, arriben respostes petites i una descàrrega gran s’atura o es reinicia. Un ping amb el bit de no fragmentar a 1472 bytes falla mentre un ping de 1400 bytes té èxit, cosa que apunta a un camí que no pot portar un paquet de mida completa i no lliura el missatge ICMP que diria a l’emissor que s’encongeixi.
El descobriment de l’MTU del camí depèn d’aquests missatges ICMP de fragmentació necessària. Quan un tallafoc els descarta, l’emissor continua reintentant el paquet gran i la connexió sembla penjada. Baixar l’MTU al costat del túnel evita el reintent, cosa que és una reparació legítima per a aquesta xarxa.
Les tecnologies d’accés també imposen els seus límits: PPPoE normalment es limita a 1492, alguns camins mòbils i DSL són més baixos, i els túnels imbricats resten sobrecost dues vegades. Mesura el camí real en lloc de copiar un número d’una guia, i recorda que IPv6 requereix com a mínim 1280 bytes d’MTU a qualsevol enllaç que el porti, tal com especifica RFC 8200.
Compareu els tres controls abans de canviar-ne un
MTU, MSS i fragmentació són controls diferents a capes diferents, i canviar el control equivocat deixa el símptoma al seu lloc.
| 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 l’MSS sol ser la reparació menys invasiva perquè només afecta TCP i deixa la interfície lliure per a altre trànsit. Un MTU d’interfície més baix és més ampli i més fàcil de raonar, per això és habitual en encaminadors de consum, però cobra a cada protocol el problema d’un sol protocol.
Desactivar el comportament de no fragmentar amaga el símptoma permetent la fragmentació, i normalment empitjora la latència alhora que trenca la retroalimentació que hauria trobat la mida correcta. Eviteu-ho com a solució permanent.
Mesureu el compromís en lloc d’un sol número
Trobeu el límit del camí amb una sonda de no fragmentar, començant alt i baixant fins que arribi la resposta:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Després compareu la tasca real amb tots dos ajustos: la mateixa transferència de fitxer, el mateix punt final i la mateixa xarxa. Registreu el temps de finalització i les retransmissions, per exemple amb nstat -az TcpRetransSegs, i vigileu la CPU del dispositiu si el túnel acaba en un encaminador petit. Una prova sintètica curta de rendiment pot no veure l’aturada que només apareix després de diversos megabytes.
Els comptadors de paquets pujaran després d’una reducció perquè la mateixa transferència ara fa servir més paquets. Això és esperable i no és prova de més rendiment. Compareu les dades d’aplicació completades, el nombre de retransmissions i la capacitat de resposta, no només la taxa de paquets.
Feu el canvi per etapes i manteniu-lo acotat
Registreu el valor original, canvieu un control i repetiu la mesura abans de fer-lo permanent. Si les proves no mostren cap benefici, restabliu el valor anterior amb la mateixa ordre d’interfície que vau fer servir per fixar-lo:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Acoteu el resultat a la xarxa que el necessitava. Un perfil que ha de funcionar en un Wi-Fi d’hotel, un punt d’accés mòbil i una LAN d’oficina no hauria d’heretar el valor més baix que requereixi qualsevol d’ells, tret que el client no pugui detectar el camí.
El valor correcte és l’MTU més gran que sobreviu al camí, no el més petit que fa desaparèixer el símptoma. Documenteu el camí, el resultat de la sonda i la reversió, i reviseu l’ajust quan canviï la xarxa d’accés.