Загрузка праз VPN павольнейшая за спампоўку? Вызначце, аб якую мяжу вы ўпіраецеся

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

Тры межы, якія з панэлі прагрэсу выглядаюць аднолькава

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

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

Меркаваць адзін кірунак за раз

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

iperf3 па змаўчанні адпраўляе ад кліента, таму звычайны запуск мерае ваш шлях загрузкі; -R перавяртае кірунак і мерае спампоўку. Запусціце іх з хвілінным інтэрвалам і запішыце абодва лікі замест усярэднення:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

Вырашайце па тым, дзе змяняецца загрузка

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

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

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

Калі затынанне перамагае павольнасць

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

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

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

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

Што змяніць, а што пакінуць

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

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