Un MTU VPN più piccolo è più veloce? Confrontate le prove reali
Un MTU più basso può aggirare un limite del percorso e costare comunque velocità. Confrontate il vincolo reale, il costo delle intestazioni e il carico prima di mantenere la modifica.
Un tunnel scarta i trasferimenti grandi ma lascia passare i ping, quindi il consiglio arriva presto: abbassate l’MTU. La correzione a volte funziona, e poi viene applicata a ogni profilo su ogni rete. È il punto in cui una riparazione mirata diventa una tassa permanente sulle prestazioni. Il confronto da fare è tra il limite reale del percorso e il costo di ridurre ogni pacchetto sotto di esso.
Che cosa si riduce davvero quando abbassate l’MTU
Ogni pacchetto porta intestazioni prima di portare i vostri dati. Su un percorso Ethernet da 1500 byte, IPv4 e TCP consumano 40 byte e lasciano 1460 per il carico utile; l’incapsulamento aggiunge sopra intestazioni esterne IP, UDP e tunnel, quindi il budget interno del carico scende di nuovo. Abbassare l’MTU dell’interfaccia riduce quel budget di proposito.
Il costo è proporzionale al numero di pacchetti, non al numero di byte. Lo stesso file diviso in più pacchetti richiede più interruzioni, più decisioni di instradamento e più elaborazione per pacchetto su ogni dispositivo lungo il percorso. Su un router già vicino al suo limite di pacchetti al secondo, è un rallentamento reale e non un errore di arrotondamento. Il costo si vede anche quando il trasferimento stesso riesce.
Per questo un MTU più piccolo è un aggiramento di un vincolo, non un’ottimizzazione generale. Compra affidabilità contro un percorso che non può portare la trama più grande e addebita un sovraccarico per ogni pacchetto che non aveva bisogno della riduzione.
Quando un MTU più piccolo è la correzione giusta
Il sintomo classico è preciso: la stretta di mano TCP si completa, arrivano risposte piccole e un download grande si blocca o si azzera. Un ping con il bit non-frammentare a 1472 byte fallisce mentre un ping da 1400 byte riesce, il che indica un percorso che non può portare un pacchetto di dimensioni piene e non consegna il messaggio ICMP che direbbe al mittente di ridurre.
Il rilevamento dell’MTU del percorso dipende da quei messaggi ICMP di frammentazione necessaria. Quando un firewall li scarta, il mittente continua a ripetere il pacchetto grande e la connessione sembra bloccarsi. Abbassare l’MTU lato tunnel evita la ripetizione, e questa è una riparazione legittima per quella rete.
Anche le tecnologie di accesso impongono i propri limiti: PPPoE di solito si ferma a 1492, alcuni percorsi mobili e DSL sono più bassi, e i tunnel annidati sottraggono il sovraccarico due volte. Misurate il percorso reale invece di copiare un numero da una guida, e ricordate che IPv6 richiede almeno 1280 byte di MTU su ogni collegamento che lo trasporta, come specifica RFC 8200.
Confrontate i tre controlli prima di cambiarne uno
MTU, MSS e frammentazione sono controlli diversi a livelli diversi, e cambiare quello sbagliato lascia il sintomo al suo posto.
| 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 |
Limitare l’MSS è spesso la riparazione meno invasiva perché colpisce solo TCP e lascia l’interfaccia libera per altro traffico. Un MTU di interfaccia più basso è più ampio e più semplice da ragionare, per questo è comune sui router domestici, ma addebita a ogni protocollo il problema di un solo protocollo.
Disattivare il comportamento non-frammentare nasconde il sintomo permettendo la frammentazione, e di solito peggiora la latenza mentre rompe il feedback che avrebbe trovato la dimensione corretta. Evitatelo come correzione permanente.
Misurate il compromesso invece di un solo numero
Trovate il limite del percorso con una sonda non-frammentare, partendo in alto e scendendo finché arriva la risposta:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Poi confrontate il compito reale su entrambe le impostazioni: lo stesso trasferimento di file, lo stesso endpoint e la stessa rete. Registrate il tempo di completamento e le ritrasmissioni, per esempio con nstat -az TcpRetransSegs, e osservate la CPU del dispositivo se il tunnel termina su un router piccolo. Un breve test sintetico di velocità può mancare il blocco che appare solo dopo diversi megabyte.
I contatori di pacchetti saliranno dopo una riduzione perché lo stesso trasferimento ora usa più pacchetti. È atteso e non è prova di velocità maggiore. Confrontate i dati applicativi completati, il numero di ritrasmissioni e la reattività, non solo la frequenza dei pacchetti.
Introducete la modifica per fasi e tenetela circoscritta
Annotate il valore originale, cambiate un controllo e ripetete la misura prima di renderla permanente. Se le prove non mostrano un beneficio, ripristinate il valore precedente con lo stesso comando di interfaccia che avete usato per impostarlo:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Limitate il risultato alla rete che ne aveva bisogno. Un profilo che deve funzionare su un Wi-Fi d’albergo, un hotspot mobile e una LAN d’ufficio non dovrebbe ereditare il valore più basso richiesto da uno di essi, a meno che il client non riesca a rilevare il percorso.
Il valore giusto è l’MTU più grande che sopravvive al percorso, non il più piccolo che fa sparire il sintomo. Documentate il percorso, il risultato della sonda e il ripristino, e rivedete l’impostazione quando la rete di accesso cambia.