Prečo sa zdieľanie súborov cez VPN zdá pomalé: obrátky, nie Mbps

Otvoriť zdieľaný priečinok cez VPN a čakať, kým sa výpis adresára plazí, je známy zážitok a prvý inštinkt je obviňovať šírku pásma. Zvyčajne je spojenie takmer nečinné. Protokol trávi čas čakaním na odpovede a každé čakanie stojí celú obrátku, ktorú miestna sieť nikdy neúčtovala. Opravte tvar práce a zdieľanie bude zase použiteľné.

Vzdialená pracovná kópia má nesprávny tvar

SMB otvára súbory, číta metadáta a potvrdzuje v mnohých malých výmenách. Pracovná kópia systému správy verzií na pripojenom disku počíta s latenciou miestneho súborového systému a číta veľa malých súborov. Stolová databáza ťahá stránky, kým používateľ pracuje. Každé z toho mení oneskorenie na násobiteľ, pretože cena rastie s počtom výmen, ktoré operácia vykoná; preto tunel s 40 ms mení niekoľko stoviek operácií na niekoľko sekúnd. Veľkosť užitočného zaťaženia je v tej aritmetike takmer nepodstatná.

Režia šifrovania je len malá časť; strata je horšia, pretože jedno opakované odoslanie plus zrútené okno zahltenia stoja oveľa viac než dotknuté bajty.

Počítajte obrátky skôr než megabajty

Zmerajte oneskorenie, kým kúpite kapacitu. Jediný ping vám povie, čo každá výmena platí.

ping -c 10 fileserver.example.net

Súhrn dáva minimálnu, priemernú a maximálnu dobu obrátky a rozptyl je rovnako dôležitý ako priemer. Vynásobte priemer počtom výmen, ktoré výpis adresára vykoná, a porovnajte s časom, ktorý skutočne pozorujete. Ak sa jeden veľký súbor prenáša rýchlo, kým prehliadanie je pomalé, limitujú vás latencia a počet požiadaviek. Pridať desaťnásobok kapacity spojeniu, ktoré sa nikdy nevyčerpá, nezmení vôbec nič.

Presuňte prácu, nie bajty

Zmeňte, kde sa práca odohráva, namiesto platenia za širšiu rúru. Repozitár servírujte, namiesto toho, aby ste ho pripájali, a kopírujte hromadne nástrojom, ktorý posiela len rozdiely.

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

Servírovanie repozitára, ako to robí hgweb alebo vzdialený Git, necháva klienta pracovať na miestnom klone, takže jeho volania súborového systému nikdy neprekročia tunel. rsync prejde obe strany a posiela zmenené bloky, čím odpadá väčšina výmen, ktoré platí naivná kópia. Stolová databáza patrí na serverový engine a klient sa zúži na rozhranie, alebo celý klient beží na vnútornom hostiteľovi. Každá voľba mení, akej latencii je protokol vystavený, a o to ide.

Zaseknutie pri rovnakej veľkosti je príznak MTU

Veľké prenosy, ktoré sa zastavia po približne rovnakom množstve dát, kým ping a malé stránky fungujú, ukazujú na veľkosť paketu a nie na šírku pásma.

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

Úspešná skúška znamená, že IP paket s veľkosťou 1428 bajtov prejde cestu bez fragmentácie, pretože hlavičky ICMP a IP pridávajú 28 bajtov. Zlyhanie s príznakom zákazu fragmentácie naznačuje, že použiteľná MTU tunela je menšia, než server predpokladá. Server, ktorý posiela buffery s veľkosťou 9000 bajtov na cestu s 1500 bajtmi, vynucuje fragmentáciu alebo zahadzovanie, a zisťovanie MTU cesty môže ticho zlyhať, keď je ICMP filtrovaný. Znížte MTU tunela, zapnite mssfix v OpenVPN, alebo zmenšite buffery servera, a potom spustite ten istý prenos znova na potvrdenie.

Zmerajte medzeru, na ktorej záleží

Vykonajte tú istú operáciu tromi spôsobmi tam, kde to politika dovoľuje: lokálne, cez tunel a cez priamu internetovú cestu. Pri každej si poznamenajte dobu obrátky, rýchlosť jedného veľkého toku a ako dlho trvá výpis adresára alebo otvorenie aplikácie. Porovnanie lokálneho behu s behom cez tunel ukáže, ktorá cena prevláda. Kópia, ktorá končí pomaly, naznačuje problém s rýchlosťou alebo oneskorením, zatiaľ čo kópia, ktorá umiera v konzistentnom bode, naznačuje veľkosť paketu alebo stavové zariadenie na ceste.

Keď sa vlečú len prvé megabajty, pozerajte sa na autentifikáciu a metadáta; keď sa plazí všetko, pozerajte sa na kapacitu a straty. Opravte zodpovedajúcu príčinu a prestaňte čakať, že sa WAN spojenie bude správať ako kábel miestnej siete.