Hvorfor fildeling over VPN føles langsom: rundture, ikke Mbps

At åbne en delt mappe over VPN og vente, mens mappelisten kravler afsted, er en velkendt oplevelse, og den første indskydelse er at give båndbredden skylden. Som regel er forbindelsen næsten ledig. Protokollen bruger tiden på at vente på svar, og hver ventetid koster en fuld rundtur, som LAN'et aldrig opkrævede. Ret arbejdets form, og delingen bliver brugbar igen.

Den fjernarbejdende kopi har den forkerte form

SMB åbner filer, læser metadata og kvitterer i mange små udvekslinger. En arbejdskopi til versionskontrol på et tilknyttet drev forventer lokal filsystemlatens og læser mange små filer. En skrivebordsdatabase trækker sider, mens brugeren arbejder. Hver af dem gør forsinkelse til en multiplikator, fordi prisen vokser med antallet af udvekslinger, som operationen udfører; en tunnel på 40 ms gør derfor et par hundrede operationer til flere sekunder. Nytten af datamængden er næsten irrelevant i det regnestykke.

Krypteringsomkostningerne er en lille del af det; tab er værre, fordi én gensendelse plus et kollapset overbelastningsvindue koster langt mere end de involverede bytes.

Tæl rundture før megabytes

Mål forsinkelsen, før du køber kapacitet. Et enkelt ping fortæller, hvad hver udveksling betaler.

ping -c 10 fileserver.example.net

Oversigten giver mindste, gennemsnitlige og største rundturstider, og spredningen betyder lige så meget som gennemsnittet. Gang gennemsnittet med det antal udvekslinger, en mappeliste udfører, og sammenlign det med den tid, du faktisk observerer. Hvis én stor fil overføres hurtigt, mens gennemsyn er langsomt, er latens og antal anmodninger begrænsningen. At tilføje ti gange kapaciteten til en forbindelse, der aldrig mættes, ændrer slet intet.

Flyt arbejdet, ikke bytesene

Ændr hvor arbejdet sker i stedet for at betale for mere rør. Servér repositoriet i stedet for at montere det, og kopiér i bulk med et værktøj, der kun sender forskelle.

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

Når repositoriet servers, som hgweb eller en fjern Git gør, kan klienten arbejde på et lokalt klon, så dets filsystemkald aldrig krydser tunnelen. rsync går begge sider igennem og sender ændrede blokke, hvilket fjerner de fleste udvekslinger, som en naiv kopi betaler. En skrivebordsdatabase hører til på en servermotor med klienten reduceret til en frontend, eller hele klienten kører på en intern vært. Hver mulighed ændrer, hvor meget latens protokollen udsættes for, og det er pointen.

Stop ved samme størrelse er et MTU-symptom

Store overførsler, der går i stå efter nogenlunde samme datamængde, mens ping og små sider virker, peger på pakkestørrelse frem for båndbredde.

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

En vellykket test betyder, at en IP-pakke på 1428 bytes passerer vejen uden fragmentering, da ICMP- og IP-headere tilføjer 28 bytes. En fejl med do-not-fragment-flaget tyder på, at tunnelens brugbare MTU er mindre, end serveren antager. En server, der sender buffere på 9000 bytes ud på en vej på 1500 bytes, fremtvinger fragmentering eller tab, og opdagelse af vejens MTU kan fejle lydløst, når ICMP filtreres. Sænk tunnelens MTU, aktivér mssfix på OpenVPN, eller skrum buffere på serveren, og kør derefter den samme overførsel igen for at bekræfte.

Mål det hul, der betyder noget

Kør den samme operation på tre måder, hvor politikken tillader det: lokalt, over tunnelen og ad en direkte internetvej. Notér for hver rundturstiden, hastigheden på én stor strøm, og hvor lang tid en mappeliste eller åbning af et program tager. At sammenligne det lokale kør med tunnelkøret viser, hvilken pris der dominerer. En kopi, der slutter langsomt, tyder på et hastigheds- eller forsinkelsesproblem, mens en kopi, der dør på et fast punkt, tyder på pakkestørrelse eller en stateful enhed på vejen.

Når kun de første megabytes slæber, se på godkendelse og metadata; når alt kravler, se på kapacitet og tab. Ret den matchende årsag, og hold op med at forvente, at en WAN-forbindelse opfører sig som et LAN-kabel.