Waarom bestanden delen via VPN traag voelt: rondjes, geen Mbps

Een gedeelde map openen via de VPN en wachten tot de mapinhoud kruipt is een bekende ervaring, en de eerste neiging is de bandbreedte de schuld geven. Meestal is de verbinding vrijwel ongebruikt. Het protocol brengt zijn tijd door met wachten op antwoorden, en elke wachttijd kost een volledige heen-en-terugreis die het LAN nooit rekende. Repareer de vorm van het werk, en de deling wordt weer bruikbaar.

De werkkopie op afstand heeft de verkeerde vorm

SMB opent bestanden, leest metadata en bevestigt in veel kleine uitwisselingen. Een werkkopie van versiebeheer op een gekoppelde schijf gaat uit van lokale bestandssysteemlatentie en leest veel kleine bestanden. Een desktopdatabase trekt pagina's terwijl de gebruiker werkt. Elk daarvan maakt vertraging tot een vermenigvuldiger, omdat de kosten groeien met het aantal uitwisselingen dat de bewerking doet; een tunnel van 40 ms maakt daarom een paar honderd bewerkingen tot enkele seconden. De laadgrootte is in die rekensom bijna irrelevant.

De versleutelingskosten zijn een klein deel ervan; verlies is erger, want één hertransmissie plus een ingestort congestievenster kost veel meer dan de betrokken bytes.

Tel rondjes voordat je megabytes telt

Meet de vertraging voordat je capaciteit koopt. Eén ping vertelt wat elke uitwisseling betaalt.

ping -c 10 fileserver.example.net

Het overzicht geeft minimale, gemiddelde en maximale rondtetijden, en de spreiding is net zo belangrijk als het gemiddelde. Vermenigvuldig het gemiddelde met het aantal uitwisselingen dat een mapinhoud doet, en vergelijk dat met de tijd die je werkelijk ziet. Als één groot bestand snel gaat terwijl het bladeren traag is, zijn latentie en het aantal verzoeken de beperking. Tien keer zoveel capaciteit toevoegen aan een verbinding die nooit verzadigd raakt verandert helemaal niets.

Verplaats het werk, niet de bytes

Verander waar het werk gebeurt in plaats van te betalen voor een bredere pijp. Bedien de repository in plaats van hem te koppelen, en kopieer in bulk met een hulpmiddel dat alleen verschillen verstuurt.

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

Als de repository wordt bediend, zoals hgweb of een remote Git doet, kan de client op een lokale kloon werken zodat zijn bestandssysteemaanroepen nooit de tunnel oversteken. rsync loopt beide kanten door en stuurt gewijzigde blokken, waardoor de meeste uitwisselingen vervallen die een naïeve kopie betaalt. Een desktopdatabase hoort op een engine aan de serverkant, met de client teruggebracht tot een interface, of de hele client draait op een interne host. Elke optie verandert hoeveel latentie het protocol ondervindt, en dat is het punt.

Haperen bij dezelfde grootte is een MTU-symptoom

Grote overdrachten die na ongeveer dezelfde hoeveelheid data stokken, terwijl ping en kleine pagina's werken, wijzen op pakketgrootte en niet op bandbreedte.

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

Een geslaagde test betekent dat een IP-pakket van 1428 bytes het pad ongefragmenteerd passeert, omdat ICMP- en IP-headers 28 bytes toevoegen. Een fout met de do-not-fragment-vlag wijst erop dat de bruikbare MTU van de tunnel kleiner is dan de server aanneemt. Een server die buffers van 9000 bytes op een pad van 1500 bytes zet, dwingt fragmentatie of verlies af, en het ontdekken van de pad-MTU kan stil mislukken wanneer ICMP wordt gefilterd. Verlaag de MTU van de tunnel, schakel mssfix in op OpenVPN, of verklein de buffers van de server, en voer daarna dezelfde overdracht opnieuw uit om te bevestigen.

Meet de kloof die ertoe doet

Voer dezelfde bewerking op drie manieren uit waar het beleid dat toestaat: lokaal, over de tunnel en via een direct internetpad. Noteer voor elk de rondtetijd, de snelheid van één grote stroom en hoe lang een mapinhoud of het openen van een toepassing duurt. Het vergelijken van de lokale uitvoering met de tunneluitvoering laat zien welke kosten overheersen. Een kopie die langzaam eindigt wijst op een snelheids- of vertragingsprobleem, terwijl een kopie die op een vast punt sterft wijst op pakketgrootte of een stateful apparaat in het pad.

Als alleen de eerste megabytes slepen, kijk dan naar authenticatie en metadata; als alles kruipt, kijk dan naar capaciteit en verlies. Repareer de passende oorzaak, en stop met verwachten dat een WAN-verbinding zich gedraagt als een LAN-kabel.