Зашто дељење датотека преко VPN-а изгледа споро: кругови, а не Mbps

Отварање дељене фасцикле преко VPN-а и чекање док се списак директоријума вуче је познато искуство, а први инстинкт је кривити пропусност. Обично је веза готово неискоришћена. Протокол проводи време чекајући одговоре, а свако чекање кошта цео круг који локална мрежа никада није наплаћивала. Поправите облик посла и дељење поново постаје употребљиво.

Далека радна копија има погрешан облик

SMB отвара датотеке, чита метаподатке и потврђује у многим малим разменама. Радна копија контроле верзија на мапираном диску претпоставља латенцију локалног датотечног система и чита много малих датотека. Стона база података вуче странице док корисник ради. Свако од тога претвара кашњење у множилац, јер трошак расте са бројем размена које операција обави; зато тунел од 40 ms претвара неколико стотина операција у неколико секунди. Величина корисног терета је у тој аритметици готово неважна.

Трошак шифровања је мали део тога; губитак је гори, јер једно поновно слање плус срушен прозор загушења коштају много више од укључених бајтова.

Бројте кругове пре мегабајта

Измерите кашњење пре него што купите капацитет. Један ping каже шта свака размена плаћа.

ping -c 10 fileserver.example.net

Сажетак даје минимално, просечно и максимално време круга, а расипање је важно колико и просек. Помножите просек бројем размена које списак директоријума обави, па упоредите са временом које заиста примећујете. Ако се једна велика датотека преноси брзо док је прегледање споро, ограничење су латенција и број захтева. Додавање десет пута већег капацитета вези која се никада не засити не мења баш ништа.

Преместите посао, не бајтове

Промените где се посао обавља уместо да плаћате ширу цев. Служите репозиторијум уместо да га монтирате и копирајте у целини алатом који шаље само разлике.

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

Служење репозиторијума, као што чине hgweb или удаљени Git, пушта клијента да ради на локалном клону, па његови позиви датотечног система никада не прелазе тунел. rsync обилази обе стране и шаље измењене блокове, уклањајући већину размена које плаћа наивно копирање. Стона база података припада серверском мотору, а клијент се своди на интерфејс, или цео клијент ради на унутрашњем домаћину. Свака опција мења колико је латенције протокол изложен, и у томе је поента.

Застој на истој величини је симптом MTU-а

Велики преноси који се зауставе после приближно исте количине података, док ping и мале странице раде, указују на величину пакета, а не на пропусност.

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

Успешан тест значи да IP пакет од 1428 бајтова пролази пут без фрагментације, јер заглавља ICMP и IP додају 28 бајтова. Неуспех са заставицом забране фрагментације указује да је употребљиви MTU тунела мањи него што сервер претпоставља. Сервер који шаље бафере од 9000 бајтова на пут од 1500 бајтова присиљава фрагментацију или одбацивање, а откривање MTU-а пута може тихо да пропадне када се ICMP филтрира. Снизите MTU тунела, укључите mssfix у OpenVPN-у, или смањите бафере сервера, па поново покрените исти пренос ради потврде.

Измерите јаз који је важан

Изведите исту операцију на три начина где то политика дозвољава: локално, преко тунела и преко директне интернет руте. За сваки забележите време круга, брзину једног великог тока и колико траје списак директоријума или отварање апликације. Поређење локалног извршавања са извршавањем преко тунела показује који трошак преовлађује. Копија која се завршава споро указује на проблем брзине или кашњења, а копија која умире у сталној тачки на величину пакета или уређај који чува стање на путу.

Када се вуку само први мегабајти, гледајте аутентификацију и метаподатке; када све пуже, гледајте капацитет и губитак. Поправите одговарајући узрок и престаните да очекујете да се WAN веза понаша као кабл локалне мреже.