Що саме є проблемою MTU / MRU, чим вона викликана та як її виправити?

У випадках зависання, замерзання, повільних і безвідповідальних підключень до Інтернету причина зазвичай необґрунтовано ідентифікується як "проблема MTU / MRU" з декількома поспішно запропонованими "магічними засобами" (як правило, недійсними або неприйнятними для ситуації), такими як команди, що включають iptablesабо ifconfigта інше " затискання MTU до TSS "заклинання.

Мені хочеться знати, що саме полягає в проблемі MTU / MRU, чому це впливає на швидкість та затримку з'єднання та як воно виліковується (відомими та сучасними методами), оскільки я б хотів грамотно підійти до вирішення цього питання, не магічно.

Це трохи складне запитання, тож я розпочну з основ. Пробачте, якщо ви вже все це знаєте.

MTU - це блок максимальної передачі, найбільший пакет даних, який надсилатиме комп'ютерний інтерфейс. Для Ethernet типово 1500 байт. Кадрів Ethernet зазвичай може бути до 1522-1542 (залежить від того, що ви рахуєте), а додатковий простір "зарезервовано" для інформації заголовка.

Різні з'єднання можуть мати різні можливості. Досить звичайно переходити посилання в Інтернеті з MTU, який трохи менше 1500. Це зазвичай пов'язано з посиланням, що використовує додаткову інформацію заголовка або використовує носій, відмінний від "стандартного" Ethernet (більшість Інтернету насправді працює на Підключення ATM / SoNet). Зазвичай трафік, що стикається з таким посиланням, просто розбивається на кілька частин і надсилається разом.

Оскільки це є загальним явищем і було в той час, коли був винайдений IP, частина відповідальності протоколу ICMP полягала в повідомленні будь-яких проблем з MTU. Якщо пакет з будь-якої причини не вдалося зламати та переслати, ICMP використовується для передачі проблеми назад на комп'ютер, що відправляє. Комп'ютер, що надсилає, вживає відповідних дій, розбиваючи інформацію на менші шматки, і всі радіють. Весь цей процес ведеться за лаштунками. У належно функціонуючій мережі ніколи не потрібно спілкуватися з налаштуваннями MTU .

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

1. Зламана реалізація - Програмне забезпечення в певний момент просто не працює як слід. Не існує законів, в яких говориться, що люди повинні дотримуватися відповідних стандартів Інтернету, і є компанії, які порушують стандарти, як правило, дешево.
2. Реалізація з обмеженою адміністративністю - трапляється, що люди з добрими намірами ламають програмне забезпечення, оскільки вони насправді не знають, що роблять. Я особисто бачив, як люди блокують ICMP, тому що вони думають, що він використовується лише для пакетів ICMP.0.0 (відлуння, більшість людей знають це за допомогою pingутиліти).
3. Інші причини, що знаходяться повністю поза цим «нормальним» процесом. Найчастіше це означає, що з'єднання настільки втрачає, що лише більш короткі пакети роблять це з'єднання надійно (або без масивної кількості повторень). У деяких ранніх DSL та CableModems виникли такі проблеми. А до цього у комутованого зв’язку зазвичай виникали подібні проблеми при використанні дуже низької якості телефонних ліній та агресивного кодування ліній.

Отже, чому загальне: ледачі техніки / компанії. Майже універсально «легше» перешкодити з'єднанню з крихітним MTU, ніж виправити одну з проблем, описаних вище. Як було сказано вище, сьогодні ніхто не повинен возитися з MTU (єдиний виняток, про який я можу подумати, що дозволяє включити рамки Jumbo, але це дійсно не те, що ми тут обговорюємо). Правильне лікування в будь-якому випадку - з’ясувати основну проблему та виправити це; класичний випадок лікування хвороби не симптомом.

Як MTU впливає на з'єднання? Розбиваючи дані на невеликі шматочки, це означає, що кожна деталь матиме більше шансів дістатися до місця призначення, особливо через дуже ненадійні з'єднання. Однак, будучи меншими шматочками, є більше витрат на дані, що передаються. Це означає, що ефективна швидкість з'єднання знижується; істотно, якщо MTU дійсно невеликий. Затримка може вплинути, хоча я б очікував, що вона буде незначною через додаткову обробку та накладні витрати заголовка та процес фрагментації / повторної збірки.

Оновлення: - Що стосується --clamp-mss-to-pmtu
особисто, я ніколи не спілкувався з MTU; Я визнаю, що я трохи перфекціоніст, і коли мені подають подібні некрасиві хаки, я завжди знаходжу корінь проблеми і змогла її виправити. З цією метою iptablesваріант --clamp-mss-to-pmtuмені незнайомий. Мабуть, вкрай часто, і, швидше за все, невиправдано в більшості ситуацій, використовувати цей хак. Це все-таки хак компенсувати одну з перерахованих вище проблем. Я наводжу з маніпуляції Linux для iptables (8):

Ця мета застосовується для подолання кримінально просунутих провайдерів або серверів, які блокують необхідні фрагменти ICMP або ICMPv6 Packet Too Big.

Відносно жорстка мова сторінки вказування повинна бути вказівкою на те, скільки зневаги отримують Інтернет-провайдери та мережі, які не слідують за RFC (і не намагаються компенсувати).

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

Багато сучасних протоколів тунелювання VPN побудовані або на нижчих рівнях (з ще меншими накладними витратами), таких як GRE та L2TP; або тунельовано на більш високих рівнях (як правило, для сумісності з обмежуючими брандмауерами або іншими причинами), наприклад, SSTP або SSH. Вони поступово замінять UDP як транспортний механізм.

Оновлення 2: - Діагностування проблем MTU / ICMP
Отже, ви вважаєте, що у вас проблема з MTU / ICMP і хочете бути впевненими. Є два основні етапи цього процесу. Вказівки призначені для вікна Linux або BSD, але їх можна адаптувати під будь-яку ОС.

1. Виберіть ціль ICMP Ping (наприклад, Google.com, Yahoo.com, Facebook.com тощо). Спробуйте перевірити їх за допомогою наступної команди: ping -c 2 -s 1472 -D google.com.
   • Це має досягти успіху. Якщо це не вдається, він повинен повернути "пакет потрібно фрагментарно". Якщо будь-яке з них відповідає дійсності, припиніть, ваше з'єднання працює чудово.
   • Якщо це нічого не повертає або дає повідомлення про "тайм-аут", тоді у вас є проблема.
2. Тільки для розірваних з'єднань: запустіть traceroute -F google.com 1472. Це підкаже, який хміль зламаний. Примітка: CPE досить часто не відповідає на запити відслідковування, тому не турбуйтеся, якщо перший скачок не відгукнеться.
   • Незалежно від того, чи є останній скачок на відповідь, той останній, який працює правильно для вас.
   • Якщо жоден з них не відповідає, це ваша лінія CPE або DSL (з'ясовуючи, що може бути трохи хитро, але це майже ніколи не CPE, якщо це сучасно). Примітка: Якщо ваше з'єднання працює нормально, трасування буде успішно виконано.

Зі сторони: Який провайдер сьогодні використовує PPTP ?! Це вибух із давнього і марного минулого. Вони повинні принаймні використовувати PPPoE; але просто авторизувати модем MAC та Segment було б набагато простіше (простіше і провайдеру, і клієнту).