Чи швидший VPN із меншим MTU? Порівняйте реальні докази
Менший MTU може обійти обмеження маршруту і все одно коштувати пропускної здатності. Порівняйте реальне обмеження, накладні витрати заголовків і навантаження, перш ніж залишати зміну.
Тунель відкидає великі передачі, але пропускає ping, тому порада приходить швидко: зменште MTU. Виправлення іноді працює, а потім застосовується до кожного профілю в кожній мережі. Саме тоді точкове виправлення перетворюється на постійний податок на продуктивність. Порівнювати треба реальну межу маршруту і ціну зменшення кожного пакета нижче неї.
Що насправді зменшується, коли ви знижуєте MTU
Кожен пакет несе заголовки перш ніж несе ваші дані. На маршруті Ethernet у 1500 байтів IPv4 і TCP займають 40 байтів і залишають 1460 для корисного навантаження; інкапсуляція додає зверху зовнішні заголовки IP, UDP і тунелю, тому внутрішній бюджет навантаження знову падає. Зниження MTU інтерфейсу навмисно зменшує цей бюджет.
Витрати пропорційні кількості пакетів, а не кількості байтів. Той самий файл, поділений на більше пакетів, потребує більше переривань, більше рішень маршрутизації і більше обробки на пакет на кожному пристрої вздовж маршруту. На маршрутизаторі, який уже близький до своєї межі пакетів за секунду, це реальне уповільнення, а не помилка округлення. Витрати видно навіть тоді, коли сама передача вдається.
Тому менший MTU — це обхід обмеження, а не загальна оптимізація. Він купує надійність проти маршруту, який не може нести більший кадр, і стягує накладні витрати за кожен пакет, якому зменшення не було потрібне.
Коли менший MTU — правильне виправлення
Класичний симптом конкретний: рукостискання TCP завершується, надходять малі відповіді, а велике завантаження зупиняється або скидається. Ping із бітом «не фрагментуй» на 1472 байтах не проходить, тоді як ping у 1400 байтів проходить, що вказує на маршрут, який не може нести пакет повного розміру і не доставляє ICMP-повідомлення, яке сказало б відправникові зменшити.
Виявлення MTU маршруту залежить від тих ICMP-повідомлень про необхідну фрагментацію. Коли міжмережевий екран їх відкидає, відправник продовжує повторювати великий пакет, і з'єднання виглядає завислим. Зниження MTU на боці тунелю уникає повтору, і це законне виправлення для такої мережі.
Технології доступу теж встановлюють свої межі: PPPoE зазвичай обмежується 1492, деякі мобільні та DSL-маршрути нижчі, а вкладені тунелі віднімають накладні витрати двічі. Вимірюйте реальний маршрут, а не копіюйте число з посібника, і пам'ятайте, що IPv6 вимагає щонайменше 1280 байтів MTU на будь-якому каналі, який його несе, як зазначає RFC 8200.
Порівняйте три регулятори, перш ніж змінювати один
MTU, MSS і фрагментація — це різні регулятори на різних рівнях, і зміна не того залишає симптом на місці.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
Обмеження MSS часто є найменш інвазивним виправленням, бо зачіпає лише TCP і залишає інтерфейс вільним для іншого трафіку. Нижчий MTU інтерфейсу ширший і простіший для осмислення, тому він поширений на побутових маршрутизаторах, але він стягує з кожного протоколу проблему одного протоколу.
Вимкнення поведінки «не фрагментуй» приховує симптом, дозволяючи фрагментацію, і зазвичай погіршує затримку, ламаючи зворотний зв'язок, який знайшов би правильний розмір. Уникайте цього як постійного виправлення.
Вимірюйте компроміс, а не одне число
Знайдіть межу маршруту зондом «не фрагментуй», почніть високо і спускайтеся, доки не прийде відповідь:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Потім порівняйте реальне завдання на обох налаштуваннях: та сама передача файлу, та сама кінцева точка і та сама мережа. Запишіть час завершення і повторні передачі, наприклад за допомогою nstat -az TcpRetransSegs, і стежте за процесором пристрою, якщо тунель закінчується на невеликому маршрутизаторі. Короткий синтетичний тест пропускної здатності може пропустити зупинку, яка з'являється лише після кількох мегабайтів.
Лічильники пакетів зростуть після зменшення, бо та сама передача тепер використовує більше пакетів. Це очікувано і не є доказом вищої пропускної здатності. Порівнюйте завершені дані застосунку, кількість повторних передач і чутливість, а не лише частоту пакетів.
Впроваджуйте зміну поетапно і тримайте її в межах
Запишіть початкове значення, змініть один регулятор і повторіть вимірювання, перш ніж робити його постійним. Якщо докази не показують користі, відновіть попереднє значення тією ж командою інтерфейсу, якою ви його задали:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Обмежте результат тією мережею, якій він був потрібен. Профіль, який має працювати в готельному Wi-Fi, на мобільній точці доступу і в офісній LAN, не повинен успадковувати найнижче значення, якого вимагає будь-яка з них, якщо тільки клієнт не може виявити маршрут.
Правильне значення — це найбільший MTU, який виживає на маршруті, а не найменший, який змушує симптом зникнути. Задокументуйте маршрут, результат зонда і відкат, і перегляньте налаштування, коли мережа доступу змінюється.