Miks VPN-i kaudu failijagamine tundub aeglane: edasi-tagasi käigud, mitte Mbps

Jagatud kausta avamine VPN-i kaudu ja ootamine, kuni kataloogi loend roomab, on tuttav kogemus, ja esimene instinkt on süüdistada ribalaiust. Tavaliselt on ühendus peaaegu jõude. Protokoll veedab aega vastuseid oodates ja iga ootus maksab täisringi, mida lähivõrk kunagi ei küsinud. Parandage töö kuju ja jagamine muutub taas kasutatavaks.

Kaugtöökopeerimine on vale kujuga

SMB avab faile, loeb metaandmeid ja kinnitab paljudes väikestes vahetustes. Versioonihalduse töökopeerimine kaardistatud kettal eeldab kohaliku failisüsteemi latentsust ja loeb palju väikeseid faile. Töölaua andmebaas tõmbab lehti, kui kasutaja töötab. Igaüks neist muudab viivituse kordajaks, sest kulu kasvab sellega, kui palju vahetusi toiming teeb; seetõttu muudab 40 ms tunnel paarsada toimingut mitmeks sekundiks. Kasuliku koorma suurus on selles aritmeetikas peaaegu tähtsusetu.

Krüpteerimise üldkulu on sellest väike osa; kadu on hullem, sest üks kordussaatmine pluss kokkuvarisenud ummikuaken maksab palju rohkem kui asjasse puutuvad baidid.

Loendage ringe enne megabaite

Mõõtke viivitust enne, kui ostate mahtu. Üks ping ütleb, mida iga vahetus maksab.

ping -c 10 fileserver.example.net

Kokkuvõte annab minimaalse, keskmise ja maksimaalse ringiaja ning hajuvus loeb sama palju kui keskmine. Korrutage keskmine kataloogiloendi vahetuste arvuga ja võrrelge seda ajaga, mida tegelikult näete. Kui üks suur fail liigub kiiresti, samal ajal kui sirvimine on aeglane, piiravad latentsus ja päringute arv. Kui lisada kümme korda mahtu ühendusele, mis ei küllastu kunagi, ei muutu üldse midagi.

Liigutage tööd, mitte baite

Muutke, kus töö toimub, selle asemel et maksta laiema toru eest. Teenindage hoidlat selle kinnitamise asemel ja kopeerige hulgi tööriistaga, mis saadab ainult erinevused.

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

Kui hoidlat teenindatakse, nagu teeb hgweb või kaug-Git, saab klient töötada kohalikul kloonil, nii et tema failisüsteemi kutsed ei ületa kunagi tunnelit. rsync käib läbi mõlemad pooled ja saadab muudetud plokid, kõrvaldades enamiku vahetustest, mille naiivne kopeerimine maksab. Töölaua andmebaas kuulub serveripoolsele mootorile, kus klient on taandatud liideseks, või töötab kogu klient sisemisel hostil. Iga valik muudab, kui palju latentsusele protokoll avatud on, ja see ongi mõte.

Sama suuruse juures tõrkumine on MTU sümptom

Suured ülekanded, mis jäävad seisma umbes sama andmemahu järel, samal ajal kui ping ja väikesed lehed töötavad, viitavad paketi suurusele, mitte ribalaiusele.

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

Edukas katse tähendab, et 1428-baidine IP-pakett läbib tee killustamata, sest ICMP ja IP päised lisavad 28 baiti. Ebaõnnestumine mittetükeldamise lipuga viitab, et tunnelil kasutatav MTU on väiksem, kui server eeldab. Server, mis saadab 9000-baidiseid puhvreid 1500-baidisele teele, sunnib peale tükeldamise või kaod, ja tee MTU avastamine võib vaikselt nurjuda, kui ICMP on filtreeritud. Vähendage tunneli MTU-d, lubage mssfix OpenVPN-is või vähendage serveri puhvreid, seejärel käivitage sama ülekanne uuesti kinnitamiseks.

Mõõtke lünka, mis loeb

Tehke sama toimingut kolmel viisil, kus poliitika lubab: kohapeal, läbi tunneli ja otse internetiteel. Igaühe jaoks märkige ringiaeg, ühe suure voo kiirus ja see, kui kaua võtab kataloogiloend või rakenduse avamine. Kohaliku käivituse võrdlemine tunneliläbisega näitab, milline kulu domineerib. Aeglaselt lõppev koopia viitab kiiruse või viivituse probleemile, samas kui kindlas kohas surev koopia viitab paketi suurusele või olekut hoidvale seadmele teel.

Kui roomavad ainult esimesed megabaidid, vaadake autentimist ja metaandmeid; kui kõik roomab, vaadake mahtu ja kadu. Parandage vastav põhjus ja lõpetage ootamine, et WAN-ühendus käituks nagu lähivõrgu kaabel.