Zakaj je souporaba datotek prek VPN videti počasna: krogi, ne Mbps

Odpiranje skupne mape prek VPN in čakanje, da se seznam mape vleče, je znana izkušnja, prvi vzgib pa je kriviti pasovno širino. Običajno je povezava skoraj nedejavna. Protokol preživi čas z čakanjem na odgovore, vsako čakanje pa stane cel krog, ki ga lokalno omrežje nikoli ni zaračunalo. Popravite obliko dela in souporaba bo spet uporabna.

Oddaljena delovna kopija ima napačno obliko

SMB odpira datoteke, bere metapodatke in potrjuje v številnih majhnih izmenjavah. Delovna kopija sistema za nadzor različic na priklopljenem disku predpostavlja zakasnitev lokalnega datotečnega sistema in bere veliko majhnih datotek. Namizna zbirka podatkov vleče strani, medtem ko uporabnik dela. Vsaka od tega spremeni zakasnitev v množitelj, ker stroški rastejo s številom izmenjav, ki jih operacija opravi; zato tunel s 40 ms spremeni nekaj sto operacij v nekaj sekund. Velikost koristnega tovora je v tej aritmetiki skoraj nepomembna.

Stroški šifriranja so majhen del tega; izguba je slabša, ker eno ponovno pošiljanje in sesuto okno zastoja staneta veliko več kot prizadeti bajti.

Štejte kroge pred megabajti

Izmerite zakasnitev, preden kupite kapaciteto. En ping pove, kaj plača vsaka izmenjava.

ping -c 10 fileserver.example.net

Povzetek poda najkrajši, povprečni in najdaljši čas kroga, razpršenost pa je enako pomembna kot povprečje. Pomnožite povprečje s številom izmenjav, ki jih opravi seznam mape, in primerjajte s časom, ki ga resnično opazujete. Če se ena velika datoteka prenaša hitro, brskanje pa je počasno, so omejitev zakasnitev in število zahtev. Dodajanje desetkratne kapacitete povezavi, ki se nikoli ne zasiči, ne spremeni prav ničesar.

Premaknite delo, ne bajtov

Spremenite, kje se delo dogaja, namesto da plačujete za širšo cev. Repozitorij strežite, namesto da bi ga priklapljali, in kopirajte v velikem obsegu z orodjem, ki pošilja samo razlike.

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

Streženje repozitorija, kot to počne hgweb ali oddaljeni Git, omogoča odjemalcu delo na lokalnem klonu, zato njegovi klici datotečnega sistema nikoli ne prečkajo tunela. rsync prehodi obe strani in pošilja spremenjene bloke, s čimer odpravi večino izmenjav, ki jih plača naivna kopija. Namizna zbirka podatkov sodi na strežniški pogon, odjemalec pa se skrči na vmesnik, ali pa celoten odjemalec teče na notranjem gostitelju. Vsaka možnost spremeni, koliko zakasnitve je protokol izpostavljen, in to je poanta.

Zastoj pri enaki velikosti je simptom MTU

Veliki prenosi, ki se ustavijo po približno enaki količini podatkov, medtem ko ping in majhne strani delujejo, kažejo na velikost paketa, ne na pasovno širino.

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

Uspešen preizkus pomeni, da paket IP velikosti 1428 bajtov preide pot brez razdrobitev, ker glave ICMP in IP dodajo 28 bajtov. Neuspeh z zastavico prepovedi razdrobitve nakazuje, da je uporabna MTU tunela manjša, kot predpostavlja strežnik. Strežnik, ki pošilja medpomnilnike velikosti 9000 bajtov na pot velikosti 1500 bajtov, vsili razdrobitev ali zavrženje, odkrivanje MTU poti pa lahko tiho propade, ko je ICMP filtriran. Znižajte MTU tunela, omogočite mssfix v OpenVPN ali zmanjšajte medpomnilnike strežnika, nato znova zaženite isti prenos za potrditev.

Izmerite vrzel, ki šteje

Izvedite isto operacijo na tri načine, kjer politika to dovoljuje: lokalno, prek tunela in po neposredni internetni poti. Za vsako zabeležite čas kroga, hitrost enega velikega toka in koliko časa vzame seznam mape ali odprtje programa. Primerjava lokalnega izvajanja z izvajanjem prek tunela pokaže, kateri strošek prevladuje. Kopija, ki se konča počasi, nakazuje težavo s hitrostjo ali zakasnitvijo, kopija, ki umre na stalni točki, pa na velikost paketa ali napravo s stanjem na poti.

Ko se vlečejo le prvi megabajti, poglejte overjanje in metapodatke; ko se plazi vse, poglejte kapaciteto in izgube. Popravite ustrezni vzrok in nehajte pričakovati, da se bo povezava WAN obnašala kot kabel lokalnega omrežja.