Perché la condivisione di file in VPN sembra lenta: andate e ritorni, non Mbps

Aprire una cartella condivisa tramite la VPN e aspettare mentre l'elenco della directory si trascina è un'esperienza nota, e il primo istinto è dare la colpa alla banda. Di solito il collegamento è quasi inattivo. Il protocollo passa il tempo in attesa delle risposte, e ogni attesa costa un'andata e ritorno completa che la LAN non addebitava mai. Correggi la forma del lavoro e la condivisione torna utilizzabile.

La copia di lavoro remota ha la forma sbagliata

SMB apre i file, legge i metadati e conferma in molti scambi piccoli. Una copia di lavoro del controllo di versione su un'unità mappata dà per scontata la latenza del file system locale e legge molti file piccoli. Un database desktop estrae pagine mentre l'utente lavora. Ognuna di queste cose trasforma il ritardo in un moltiplicatore, perché il costo cresce con il numero di scambi che l'operazione esegue; un tunnel da 40 ms trasforma quindi qualche centinaio di operazioni in diversi secondi. La dimensione del carico utile è quasi irrilevante in quel calcolo.

Il costo della crittografia ne è una piccola parte; la perdita è peggiore, perché una ritrasmissione più una finestra di congestione collassata costano molto più dei byte coinvolti.

Conta le andate e ritorni prima dei megabyte

Misura il ritardo prima di comprare capacità. Un solo ping ti dice quanto paga ogni scambio.

ping -c 10 fileserver.example.net

Il riepilogo dà i tempi di andata e ritorno minimo, medio e massimo, e la dispersione conta quanto la media. Moltiplica la media per il numero di scambi che un elenco di directory esegue, poi confrontalo con il tempo che osservi davvero. Se un file grande si trasferisce velocemente mentre la navigazione è lenta, il vincolo è la latenza e il numero di richieste. Aggiungere dieci volte la capacità a un collegamento che non si satura mai non cambia assolutamente nulla.

Sposta il lavoro, non i byte

Cambia dove avviene il lavoro invece di pagare per un tubo più largo. Servi il repository invece di montarlo, e copia in blocco con uno strumento che invia solo le differenze.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Servire il repository, come fanno hgweb o un Git remoto, permette al client di lavorare su un clone locale, così le sue chiamate al file system non attraversano mai il tunnel. rsync percorre entrambi i lati e invia i blocchi modificati, eliminando la maggior parte degli scambi che una copia ingenua paga. Un database desktop appartiene a un motore lato server con il client ridotto a interfaccia, oppure l'intero client gira su un host interno. Ogni opzione cambia quanta latenza il protocollo deve sopportare, ed è questo il punto.

I blocchi alla stessa dimensione sono un sintomo di MTU

I trasferimenti grandi che si bloccano dopo più o meno la stessa quantità di dati, mentre ping e pagine piccole funzionano, indicano la dimensione del pacchetto e non la banda.

ping -M do -s 1400 -c 3 fileserver.example.net

Una prova riuscita significa che un pacchetto IP da 1428 byte attraversa il percorso senza frammentazione, dato che le intestazioni ICMP e IP aggiungono 28 byte. Un fallimento con il flag di non frammentare suggerisce che l'MTU utilizzabile del tunnel è più piccolo di quanto supponga il server. Un server che invia buffer da 9000 byte su un percorso da 1500 byte impone frammentazione o scarti, e la scoperta dell'MTU del percorso può fallire in silenzio quando ICMP viene filtrato. Abbassa l'MTU del tunnel, abilita mssfix su OpenVPN, oppure riduci i buffer del server, poi ripeti lo stesso trasferimento per confermare.

Misura il divario che conta

Esegui la stessa operazione in tre modi dove la policy lo consente: in locale, attraverso il tunnel e su un percorso internet diretto. Per ciascuno annota il tempo di andata e ritorno, la velocità di un flusso grande e quanto tempo impiega un elenco di directory o l'apertura di un'applicazione. Confrontare l'esecuzione locale con quella sul tunnel mostra quale costo domina. Una copia che finisce lentamente suggerisce un problema di velocità o di ritardo, mentre una copia che muore in un punto costante suggerisce la dimensione del pacchetto o un dispositivo con stato nel percorso.

Quando solo i primi megabyte si trascinano, guarda l'autenticazione e i metadati; quando tutto si trascina, guarda la capacità e le perdite. Correggi la causa corrispondente e smetti di aspettarti che un collegamento WAN si comporti come un cavo di LAN.