Чому завантаження через VPN обмежене віддачею сервера

Клієнт показує швидкий низхідний канал, сервер стоїть на оптичному з'єднанні, а передавання все одно повзе. Число, яке люди порівнюють, зазвичай надруковане в тарифі клієнта, тоді як пакет насправді спершу проходить вихідний канал доступу сервера. Цей канал і є бюджет, у який має вкластися передавання. На невеликому домашньому з'єднанні це найменше число на шляху.

Число, яке ви прочитали, було не в тому напрямку

Завантаження до віддаленого клієнта витрачає пропускну здатність на віддачу на серверному кінці тунелю. Заявлені швидкості завантаження сервера описують протилежний напрямок і нічого не кажуть про цей. Та сама асиметрія перевертається, коли клієнт віддає, тому один напрямок може здаватися нормальним, поки інший непридатний.

Накладні витрати інкапсуляції та будь-який конкурентний трафік витрачають частину того самого бюджету. Ні те, ні інше не видно в тесті швидкості, який вимірює лише клієнта.

Запишіть шлях як бюджет

Перелічіть усі межі, які пакет має перетнути, і кожній дайте число в одній і тій самій одиниці. Доставка від джерела, обробка на сервері, вихідний канал сервера, проміжний шлях, низхідний канал клієнта й обробка на клієнті — усе це застосовується. Корисна швидкість — найменша з них мінус накладні витрати, і жодне налаштування вище цієї стелі не змінює результат. Запишіть список до вимірювання, бо він каже, якому числу не вірити.

За вихідного каналу сервера 20 Mbit/s і низхідного каналу клієнта 100 Mbit/s сервер обмежує передавання задовго до того, як клієнт це помітить. Накладні витрати та будь-яке одночасне передавання забирають ще частину, а насичений вихідний канал також затримує підтвердження, що сповільнює передавання TCP нижче сирої стелі. Жоден із цих двох ефектів не проявляється в порівнянні тарифів.

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

Де плата справді коштує вам дорого

Щойно канал доступу стає достатньо великим, обладнання кінцевої точки стає помітним, і лише тоді процесор має значення. Визначте модель, розташування інтерфейсів і використовувану реалізацію. Спостереження про спільну шину ранньої плати не описує кожну наступну ревізію.

Порівнюйте окремі шляхи обробки, а не одне середнє за CPU. Помірне загальне навантаження може приховувати одне насичене ядро, яке виконує всю роботу на пакет, а тактова частота не переноситься між конструкціями процесорів як оцінка продуктивності. Швидкість пакетів важлива так само, як пропускна здатність, бо малі пакети коштують дорожче за байт, ніж великі. Вимірюйте тими розмірами пакетів, які ваше навантаження справді використовує.

Теплові та потужнісні межі теж визначають тривалу поведінку. Короткий сплеск може виглядати чудово, поки десятихвилинне передавання скидає частоти, і саме тому тест на кілька секунд — поганий орієнтир для нічного резервного копіювання.

Рекомендації виробника щодо продуктивності розділяють пропускну здатність доступу, CPU, обробку пакетів, транспорт і розмір пакета на окремі обмеження. Їх варто прочитати перед зміною шифру, бо зміна шифру рідко зсуває межу, яка ніколи не була обмеженням.

Виміряйте, перш ніж змінювати шифр

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

Зберігайте політику безпеки незмінною, поки порівнюєте. Старий результат, отриманий зі слабким шифром або розігнаною платою, не є планом для поточного розгортання.

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

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