Hvorfor fildeling over VPN føles tregt: rundturer, ikke Mbps

Å åpne en delt mappe over VPN og vente mens mappelisten krabber av gårde er en kjent opplevelse, og den første innskytelsen er å gi båndbredden skylden. Som regel er forbindelsen nesten ledig. Protokollen bruker tiden på å vente på svar, og hver venting koster en full rundtur som LAN-et aldri tok betalt for. Rett opp formen på arbeidet, og delingen blir brukbar igjen.

Den eksterne arbeidskopien har feil form

SMB åpner filer, leser metadata og kvitterer i mange små utvekslinger. En arbeidskopi for versjonskontroll på en tilkoblet stasjon forutsetter lokal filsystemforsinkelse og leser mange små filer. En skrivebordsdatabase henter sider mens brukeren jobber. Hver av disse gjør forsinkelse til en multiplikator, fordi kostnaden vokser med hvor mange utvekslinger operasjonen gjør; en tunnel på 40 ms gjør derfor et par hundre operasjoner til flere sekunder. Nyttelastens størrelse er nesten irrelevant i den regnestykket.

Krypteringskostnaden er en liten del av det; tap er verre, fordi én retransmisjon pluss et kollapset overbelastningsvindu koster langt mer enn bytene som er involvert.

Tell rundturer før megabytes

Mål forsinkelsen før du kjøper kapasitet. Én ping forteller hva hver utveksling betaler.

ping -c 10 fileserver.example.net

Sammendraget gir minste, gjennomsnittlige og største rundturstid, og spredningen betyr like mye som gjennomsnittet. Gang gjennomsnittet med antall utvekslinger en mappeliste gjør, og sammenlign med tiden du faktisk ser. Hvis én stor fil overføres raskt mens blaing er treg, er forsinkelse og antall forespørsler begrensningen. Å legge til ti ganger kapasiteten på en forbindelse som aldri mettes endrer absolutt ingenting.

Flytt arbeidet, ikke bytene

Endre hvor arbeidet skjer i stedet for å betale for et bredere rør. Betjen repositoriet i stedet for å montere det, og kopier i bulk med et verktøy som bare sender forskjeller.

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

Når repositoriet betjenes, slik hgweb eller en ekstern Git gjør, kan klienten jobbe på en lokal klone, så filsystemkallene aldri krysser tunnelen. rsync går gjennom begge sider og sender endrede blokker, og fjerner de fleste utvekslingene en naiv kopi betaler for. En skrivebordsdatabase hører hjemme på en servermotor med klienten redusert til et grensesnitt, eller hele klienten kjører på en intern vert. Hvert alternativ endrer hvor mye forsinkelse protokollen utsettes for, og det er poenget.

Stopp ved samme størrelse er et MTU-symptom

Store overføringer som stopper etter omtrent samme datamengde, mens ping og små sider fungerer, peker på pakkestørrelse fremfor båndbredde.

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

En vellykket test betyr at en IP-pakke på 1428 byte passerer veien uten fragmentering, siden ICMP- og IP-hoder legger til 28 byte. En feil med do-not-fragment-flagget tyder på at tunnelens brukbare MTU er mindre enn serveren antar. En server som sender buffere på 9000 byte ut på en vei på 1500 byte fremtvinger fragmentering eller tap, og oppdagelse av veiens MTU kan feile stille når ICMP filtreres. Senk tunnelens MTU, aktiver mssfix på OpenVPN, eller krymp bufferne på serveren, og kjør deretter den samme overføringen på nytt for å bekrefte.

Mål gapet som betyr noe

Kjør den samme operasjonen på tre måter der policyen tillater det: lokalt, over tunnelen og via en direkte internettvei. Noter for hver rundturstiden, hastigheten på én stor strøm, og hvor lang tid en mappeliste eller åpning av et program tar. Å sammenligne den lokale kjøringen med tunnelkjøringen viser hvilken kostnad som dominerer. En kopi som blir ferdig sakte tyder på et hastighets- eller forsinkelsesproblem, mens en kopi som dør på et fast punkt tyder på pakkestørrelse eller en stateful enhet i veien.

Når bare de første megabytene sleper, se på autentisering og metadata; når alt krabber, se på kapasitet og tap. Rett opp den matchende årsaken, og slutt å forvente at en WAN-forbindelse oppfører seg som en LAN-kabel.