Perché la penalità della VPN sembra peggiore sulla rete mobile che su Ethernet

Lo stesso portatile, lo stesso server e lo stesso tunnel possono perdere un quinto del loro throughput su Ethernet e tre quarti sulla rete mobile, e nessuno dei due numeri significa che la VPN sia guasta. Ogni rete di accesso fornisce un percorso diverso, e il tunnel ne aggiunge un secondo sopra. Confrontare un numero con tunnel con un numero senza tunnel non risponde a nulla, perché i due numeri descrivono denominatori diversi. Quattro celle e una frazione di ritenzione per riga vi diranno quale domanda porre dopo.

Quattro celle, non una sola penalità

Misurate la linea di base diretta e il risultato con tunnel su ciascuna rete di accesso, e teneteli come matrice invece che come unico verdetto. La base è lo stesso compito eseguito su quella rete senza il tunnel; il risultato con tunnel è lo stesso compito con esso.

Usate un carico di lavoro autorizzato per i test diretti e mantenete i controlli sulla privacy richiesti dall’ambiente. Un test che viola la politica produce un numero che non potete pubblicare e che non dovreste ripetere.

Tenete ferme le variabili

Tenete fissi dispositivo, applicazione, destinazione, direzione di trasferimento ed endpoint VPN su tutte e quattro le celle. Se un servizio cambia silenziosamente il proprio server di test tra un’esecuzione e l’altra, registrate il cambiamento e trattate la coppia come non controllata invece di diluire la differenza con una media.

Ripetete la matrice in entrambe le direzioni e in orari comparabili. Le condizioni di una radio mobile e il carico sulla sua cella cambiano in pochi minuti, quindi un’unica base eccezionalmente buona può esagerare la penalità apparente. Registrate la dispersione dei risultati accanto a un valore rappresentativo, e annotate se le esecuzioni con tunnel sono state alternate alle basi o eseguite in blocco.

L’alternanza conta più di quanto la maggior parte delle persone si aspetti. Una base misurata prima di pranzo e un’esecuzione con tunnel misurata dopo sono due reti diverse che portano lo stesso nome.

Tenete visibile il denominatore

Riportate la frazione di ritenzione oltre alla velocità assoluta: E1 diviso E0, e C1 diviso C0. Un collegamento veloce che conserva una piccola parte del proprio throughput e un collegamento lento che ne conserva la maggior parte sono riscontri diversi, e solo la frazione mostra la differenza.

Il throughput assoluto decide ancora che cosa può fare un utente. La frazione decide dove guardare. Quando Ethernet conserva la maggior parte della propria base e la rete mobile molto meno, la variabile interessante è sul percorso mobile e non dentro la cifratura.

Entrambi i numeri appartengono al rapporto, perché ciascuno da solo sostiene una conclusione che i dati non sostengono.

Leggete lo schema prima di cambiare qualsiasi cosa

Tetti con tunnel simili su entrambe le reti indicano qualcosa di condiviso: l’endpoint, la sua CPU, un limite di velocità o un singolo salto congestionato. Un calo che compare solo sulla rete mobile indica la rotta di quella rete, la perdita, la latenza e la dimensione effettiva del pacchetto.

Sono indizi, non diagnosi, e la differenza conta quando scrivete il ticket. Un tetto condiviso non migliorerà quando cambiate il modem mobile, e un calo solo mobile non migliorerà quando ridimensionate l’endpoint. Indicate quale dei due schemi avete visto prima di proporre un cambiamento. Così il cambiamento porta una previsione, e la misura successiva può confermarla o ucciderla.

Le linee guida sulle prestazioni di OpenVPN separano i vincoli di larghezza di banda, CPU, trasporto e dimensione dei pacchetti, il che è un utile promemoria del fatto che il tunnel raramente è una sola variabile.

Quando il sospetto è la dimensione dei pacchetti

L’incapsulamento consuma spazio del pacchetto, quindi la dimensione effettiva su un percorso mobile può essere inferiore a quella annunciata dall’interfaccia. Conservate le prove sulla dimensione dei pacchetti per il percorso che state confrontando invece di supporre un valore dal nome della tecnologia di accesso.

Datagram packetization-layer path MTU discovery descrive come scoprire la dimensione effettiva invece di codificarla. Usate le osservazioni supportate dall’implementazione, e non imponete un MTU basso arbitrario a ogni client per precauzione, perché così si scambia un problema con uno peggiore su percorsi che andavano bene.

Un’ipotesi sulla dimensione ha bisogno di prove proprie: lo stesso trasferimento a due dimensioni, con lo schema di perdita registrato.

Aggiungete una variabile alla volta

Confrontate un trasporto alternativo solo dopo che la matrice di base è stata salvata. Questo tiene in gioco una variabile deliberata e vi permette di attribuire il cambiamento invece di indovinarlo.

Tenete la dimensionazione del carico utile TCP separata dal comportamento dei datagrammi UDP, poiché i due reagiscono diversamente alla perdita e alla dimensione del percorso. Un miglioramento dovuto a un cambio di trasporto è una prova su quel trasporto, non la prova che la cifratura o la copertura fossero la causa originale.

Ordine del lavoro: riempite le quattro celle, calcolate entrambe le frazioni, alternate le esecuzioni, poi scegliete un’ipotesi e provatela con un solo cambiamento. Qualunque altra cosa è un confronto tra due incognite.