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

Тры рэчы, якія тунель можа змяніць

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

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

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

Чаго ён змяніць не можа

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

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

Параўноўвайце шляхі правільна

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

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

Калі розніцу варта захаваць

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

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

Падобныя артыкулы