Качването през 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 за път, който засича. Пазете всяка промяна обратима и ограничена до една работа. Оставете на мира нещата, които измерването казва, че са наред, включително скорост на сваляне, която вече отговаря на линията.

Запишете числата преди и след заедно с профила, крайната точка и часа от деня, защото проблем с качването, който се мести с крайната точка, е въпрос на маршрутизация, а такъв, който се мести с устройството, е местен. Именно този запис превръща смътна жалба в решение и струва два пуска на същата команда.