Чаму спампоўка праз VPN абмежаваная хуткасцю аддачы сервера

Кліент паказвае хуткую лінію спампоўкі, сервер стаіць на аптычным злучэнні, а перадача ўсё роўна ледзь цягнецца. Лік, які звычайна параўноўваюць, — той, што надрукаваны ў тарыфе кліента, хаця пакет насамрэч спачатку перасякае зыходную лінію доступу сервера. Гэтая лінія і ёсць бюджэт, у які перадача павінна ўпісацца. На невялікім хатнім злучэнні гэта найменшы лік на шляху.

Лік, які вы чыталі, быў не ў тым кірунку

Спампоўка да аддаленага кліента расходуе прапускную здольнасць на аддачу на серверным канцы тунеля. Заяўленыя хуткасці спампоўкі сервера апісваюць процілеглы кірунак і нічога не кажуць пра гэты. Тая ж асіметрыя пераварочваецца, калі кліент аддае, і менавіта таму адзін кірунак можа здавацца добрым, пакуль другі непрыдатны.

Накладныя выдаткі інкапсуляцыі і любы канкурэнтны трафік расходуюць частку таго ж бюджэту. Ні тое, ні другое не відаць у тэсце хуткасці, які вымярае толькі кліента.

Запішыце шлях як бюджэт

Пералічыце ўсе межы, якія пакет павінен перасекчы, і дайце кожнай лік у адной і той жа адзінцы. Дастаўка з крыніцы, апрацоўка на серверы, лінія аддачы сервера, прамежкавы шлях, лінія спампоўкі кліента і апрацоўка на кліенце — усё гэта дзейнічае. Прыдатная хуткасць — найменшая з іх мінус накладныя выдаткі, і ніякая наладка вышэй за гэтую столь не змяняе выніку. Запішыце спіс да вымярэння, бо ён паказвае, якому ліку не верыць.

Пры лініі аддачы сервера 20 Mbit/s і лініі спампоўкі кліента 100 Mbit/s сервер абмяжоўвае перадачу задоўга да таго, як кліент гэта заўважыць. Накладныя выдаткі і любая адначасовая перадача забіраюць яшчэ частку, а насычаная лінія аддачы таксама затрымлівае пацверджанні, што запавольвае TCP-перадачу ніжэй за сырую столь. Ні адзін з двух эфектаў не бачны ў параўнанні тарыфаў.

Трымайце мегабіты і мегабайты асобна і ўказвайце, ці кожная лічба вымярае трафік зашыфраванай лініі, ці карысную нагрузку праграмы. Змешванне гэтых двух — самая частая прычына таго, што бюджэт нібыта не сыходзіцца. Пазначайце кожную лічбу яе адзінкай і кропкай вымярэння.

Дзе плата сапраўды каштуе вам

Калі лінія доступу дастаткова вялікая, абсталяванне канчатковага пункта становіцца бачным, і толькі тады мае значэнне працэсар. Вызначце мадэль, кампаноўку інтэрфейсаў і ўжытую рэалізацыю. Назіранне пра агульную шыну ранняй платы не апісвае кожную наступную рэвізію.

Параўноўвайце асобныя шляхі апрацоўкі, а не адзінае сярэдняе працэсара. Умераны агульны нагрузак можа хаваць адно насычанае ядро, якое робіць усю працу на пакет, а тактавая частата не пераносіцца паміж канструкцыямі працэсараў як паказчык прадукцыйнасці. Хуткасць пакетаў важная гэтак жа, як прапускная здольнасць, бо малыя пакеты каштуюць больш на байт, чым вялікія. Вымярайце з тымі памерамі пакетаў, якія ваша нагрузка фактычна выкарыстоўвае.

Цеплавыя і энергетычныя межы таксама вызначаюць устойлівыя паводзіны. Кароткі выбліск можа выглядаць выдатна, пакуль дзесяціхвілінная перадача трапляе пад тратлінг, і менавіта таму бенчмарк на некалькі секунд — дрэнны дараднік для начной рэзервовай копіі.

Рэкамендацыі вытворцы па прадукцыйнасці раздзяляюць прапускную здольнасць доступу, працэсар, апрацоўку пакетаў, транспарт і памер пакета на асобныя абмежаванні. Іх варта прачытаць перад зменай шыфра, бо змена шыфра рэдка зрушвае мяжу, якая ніколі не была абмежаваннем.

Вымярайце перад зменай шыфра

Правядзіце кірункавы тэст, які паказвае хуткасць, фактычна дасягнутую праз тунель, затым правядзіце той жа тэст на сырым інтэрфейсе для параўнання. Розніца паміж гэтымі двума лікамі — цана тунеля, і меншая з дзвюх столяў паказвае, на якую мяжу нападаць.

Захоўвайце палітыку бяспекі нязменнай падчас параўнання. Стары вынік, атрыманы са слабым шыфрам або разгоненай платай, не з'яўляецца планам для бягучага разгортвання.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Захоўвайце кірункавыя вынікі побач з назіраннямі канчатковага пункта з таго ж запуску. Наступная змена павінна нацэльвацца на вымераную столь, а не на кампанент, які выглядае найменшым у спецыфікацыі.