Varför fildelning över VPN känns långsam: rundturer, inte Mbps

Att öppna en delad mapp över VPN och vänta medan mapplistan kryper fram är en välbekant upplevelse, och den första impulsen är att skylla på bandbredden. Oftast är förbindelsen nästan oanvänd. Protokollet tillbringar tiden med att vänta på svar, och varje väntan kostar en full rundtur som LAN:et aldrig tog betalt för. Rätta till arbetets form, och delningen blir användbar igen.

Den fjärrstyrda arbetskopian har fel form

SMB öppnar filer, läser metadata och kvitterar i många små utbyten. En arbetskopia för versionshantering på en monterad enhet förutsätter lokal filsystemsfördröjning och läser många små filer. En skrivbordsdatabas hämtar sidor medan användaren arbetar. Var och en av dessa gör fördröjning till en multiplikator, eftersom kostnaden växer med hur många utbyten operationen gör; en tunnel på 40 ms gör därför ett par hundra operationer till flera sekunder. Nyttolastens storlek är nästan irrelevant i den matematiken.

Krypteringskostnaden är en liten del av det; förlust är värre, eftersom en omsändning plus ett kollapsat överbelastningsfönster kostar långt mer än byten som berörs.

Räkna rundturer före megabyte

Mät fördröjningen innan du köper kapacitet. En enda ping berättar vad varje utbyte betalar.

ping -c 10 fileserver.example.net

Sammanfattningen ger minsta, genomsnittliga och största rundturstid, och spridningen betyder lika mycket som genomsnittet. Multiplicera genomsnittet med antalet utbyten som en mapplista gör, och jämför med tiden du faktiskt ser. Om en stor fil överförs snabbt medan bläddringen är långsam är fördröjningen och antalet förfrågningar begränsningen. Att lägga till tio gånger kapaciteten på en förbindelse som aldrig mättas ändrar absolut ingenting.

Flytta arbetet, inte byten

Ändra var arbetet sker i stället för att betala för ett bredare rör. Betjäna förrådet i stället för att montera det, och kopiera i bulk med ett verktyg som bara skickar skillnader.

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

När förrådet betjänas, som hgweb eller en fjärr-Git gör, kan klienten arbeta på en lokal klon så att dess filsystemsanrop aldrig korsar tunneln. rsync går igenom båda sidor och skickar ändrade block, vilket tar bort de flesta utbyten som en naiv kopia betalar för. En skrivbordsdatabas hör hemma på en servermotor med klienten reducerad till ett gränssnitt, eller så kör hela klienten på en intern värd. Varje alternativ ändrar hur mycket fördröjning protokollet utsätts för, och det är poängen.

Stopp vid samma storlek är ett MTU-symtom

Stora överföringar som stannar efter ungefär samma datamängd, medan ping och små sidor fungerar, pekar på paketstorlek och inte bandbredd.

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

Ett lyckat test betyder att ett IP-paket på 1428 byte passerar vägen utan fragmentering, eftersom ICMP- och IP-huvuden lägger till 28 byte. Ett misslyckande med do-not-fragment-flaggan tyder på att tunnelns användbara MTU är mindre än servern antar. En server som skickar buffertar på 9000 byte på en väg på 1500 byte tvingar fram fragmentering eller bortfall, och upptäckt av vägens MTU kan misslyckas tyst när ICMP filtreras. Sänk tunnelns MTU, aktivera mssfix på OpenVPN, eller krymp serverns buffertar, och kör sedan samma överföring igen för att bekräfta.

Mät gapet som betyder något

Kör samma operation på tre sätt där policyn tillåter: lokalt, över tunneln och via en direkt internetväg. Anteckna för varje rundturstiden, hastigheten på en stor ström och hur lång tid en mapplista eller öppning av ett program tar. Att jämföra den lokala körningen med tunnelkörningen visar vilken kostnad som dominerar. En kopia som blir klar långsamt tyder på ett hastighets- eller fördröjningsproblem, medan en kopia som dör vid en fast punkt tyder på paketstorlek eller en tillståndshållande enhet i vägen.

När bara de första megabyten släpar, titta på autentisering och metadata; när allt kryper, titta på kapacitet och förlust. Rätta till den matchande orsaken och sluta förvänta dig att en WAN-förbindelse beter sig som en LAN-kabel.