Proč se sdílení souborů přes VPN zdá pomalé: obrátky, ne Mbps

Otevřít sdílenou složku přes VPN a čekat, až se výpis adresáře plazí, je známý zážitek a první instinkt je vinit šířku pásma. Obvykle je spojení skoro nečinné. Protokol tráví čas čekáním na odpovědi a každé čekání stojí celou obrátku, kterou místní síť nikdy neúčtovala. Opravte tvar práce a sdílení bude zase použitelné.

Vzdálená pracovní kopie má špatný tvar

SMB otevírá soubory, čte metadata a potvrzuje v mnoha malých výměnách. Pracovní kopie systému správy verzí na připojeném disku počítá s latencí místního souborového systému a čte mnoho malých souborů. Stolní databáze tahá stránky, jak uživatel pracuje. Každé z toho mění zpoždění na násobitel, protože cena roste s počtem výměn, které operace provede; proto tunel s 40 ms mění několik stovek operací na několik sekund. Velikost užitečného zatížení je v té aritmetice téměř nepodstatná.

Režie šifrování je jen malá část; ztráta je horší, protože jedno opakované odeslání plus zhroucené okno zahlcení stojí mnohem víc než dotčené bajty.

Počítejte obrátky dřív než megabajty

Změřte zpoždění, než koupíte kapacitu. Jediný ping vám řekne, co každá výměna platí.

ping -c 10 fileserver.example.net

Souhrn dává minimální, průměrnou a maximální dobu obrátky a rozptyl je stejně důležitý jako průměr. Vynásobte průměr počtem výměn, které výpis adresáře provede, a porovnejte s časem, který skutečně pozorujete. Pokud se jeden velký soubor přenáší rychle, zatímco procházení je pomalé, limitují vás latence a počet požadavků. Přidat desetinásobek kapacity spojení, které se nikdy nevyčerpá, nezmění vůbec nic.

Přesuňte práci, ne bajty

Změňte, kde se práce odehrává, místo abyste platili širší trubku. Repozitář servírujte, místo abyste ho připojovali, a kopírujte hromadně nástrojem, který posílá jen rozdíly.

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

Servírování repozitáře, jak to dělá hgweb nebo vzdálený Git, nechává klienta pracovat na místním klonu, takže jeho volání souborového systému nikdy nepřekročí tunel. rsync projde obě strany a posílá změněné bloky, čímž odpadá většina výměn, které platí naivní kopie. Stolní databáze patří na serverový engine a klient se zúží na rozhraní, nebo celý klient běží na vnitřním hostiteli. Každá volba mění, jaké latenci je protokol vystaven, a o to jde.

Zaseknutí u stejné velikosti je příznak MTU

Velké přenosy, které se zastaví po zhruba stejném množství dat, zatímco ping a malé stránky fungují, ukazují na velikost paketu, ne na šířku pásma.

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

Úspěšná zkouška znamená, že IP paket o 1428 bajtech projde cestu bez fragmentace, protože hlavičky ICMP a IP přidávají 28 bajtů. Selhání s příznakem zákazu fragmentace naznačuje, že použitelná MTU tunelu je menší, než server předpokládá. Server, který posílá buffery o 9000 bajtech do cesty o 1500 bajtech, vynucuje fragmentaci nebo zahazování, a zjišťování MTU cesty může tiše selhat, když je ICMP filtrován. Snižte MTU tunelu, zapněte mssfix v OpenVPN, nebo zmenšete buffery serveru, a pak spusťte stejný přenos znovu pro potvrzení.

Změřte mezeru, na které záleží

Proveďte stejnou operaci třemi způsoby, kde to politika dovolí: místně, přes tunel a přes přímou internetovou cestu. U každého si poznamenejte dobu obrátky, rychlost jednoho velkého toku a jak dlouho trvá výpis adresáře nebo otevření aplikace. Srovnání místního běhu s během přes tunel ukáže, která cena převažuje. Kopie, která končí pomalu, naznačuje problém s rychlostí nebo zpožděním, zatímco kopie, která umírá v konzistentním bodě, naznačuje velikost paketu nebo stavové zařízení na cestě.

Když se vlečou jen první megabajty, dívejte se na autentizaci a metadata; když se plazí všechno, dívejte se na kapacitu a ztráty. Opravte odpovídající příčinu a přestaňte čekat, že se WAN spojení bude chovat jako kabel místní sítě.