Что именно является проблемой 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 были такие проблемы. А до этого у dial-up обычно возникали такие проблемы при использовании телефонных линий очень низкого качества и агрессивных кодировок.

Итак, почему это обычное дело: Ленивые техники / компании. Почти всегда «проще» затруднить соединение с крошечным MTU, чем решить одну из проблем, описанных выше. Как указывалось выше, в наши дни никто не должен связываться с MTU (единственное исключение, которое я могу себе представить, это включение Jumbo-фреймов, но на самом деле это не то, что мы обсуждаем здесь). В любом случае правильное лекарство - это выяснить основную проблему и исправить ее; Классический случай лечения болезни, а не симптом.

Как MTU влияет на соединение? Разделение данных на крошечные кусочки означает, что у каждого кусочка будет больше шансов добраться до места назначения, особенно по крайне ненадежным соединениям. Однако, будучи меньшими по размеру, на передаваемые данные накладывается больше затрат. Это означает, что эффективная скорость соединения уменьшается; существенно, если MTU действительно мало. Задержка может быть затронута, хотя я ожидаю, что она будет незначительной из-за дополнительной обработки и издержек процесса заголовка и фрагментации / повторной сборки.

Обновление: - Что касается --clamp-mss-to-pmtu
меня лично, я никогда не шутил с MTU; Я признаю, что я немного перфекционист, и когда мне дают такие уродливые хаки, я всегда нахожу корень проблемы и могу ее исправить. Для этого iptablesвариант --clamp-mss-to-pmtuмне незнаком. По-видимому, использование этого хака крайне распространено и, вероятно, в большинстве случаев совершенно неоправданно. Это все еще взломать, чтобы компенсировать одну из вышеуказанных проблем. Я цитирую на странице руководства Linux для iptables (8):

Эта цель используется для преодоления преступных провайдеров мозга или серверов, которые блокируют пакеты 'ICMP Fragmentation Needed' или '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.
   • Это должно быть успешным. Если это не удается, он должен вернуть «пакет должен быть фрагментирован». Если что-то из этого верно, остановитесь, ваше соединение работает нормально.
   • Если это ничего не возвращает или выдает сообщение «timeout», значит у вас проблема.
2. Только для разорванных соединений: запустить traceroute -F google.com 1472. Это скажет вам, какой хоп сломан. Примечание. Обычно CPE не отвечает на запросы traceroute, поэтому не пугайтесь, если первый прыжок не отвечает.
   • В зависимости от того, какой последний прыжок последует, последний работает правильно для вас.
   • Если никто из них не отвечает, это ваша линия CPE или DSL (выяснить, что может быть немного сложнее, но это почти никогда не CPE, если оно современно). Примечание. Если ваше соединение работает нормально, traceroute будет успешно завершено.

На заметку: какой провайдер использует PPTP в наши дни ?! Это взрыв из устаревшего и бесполезного прошлого. Они должны по крайней мере использовать PPPoE; но простая авторизация модема с помощью MAC и сегмента будет намного проще (проще как для интернет-провайдера, так и для клиента).