В случаях зависания, зависания, медленного, не отвечающего интернет-соединения причина обычно необоснованно определяется как «проблема MTU / MRU» с несколькими поспешно предложенными «волшебными лекарствами» (обычно недействительными или неприменимыми для данной ситуации), такими как команды, включающие iptables или ifconfig, и другие заклинания "закрепить MTU на TSS".
Я хочу знать, в чем именно заключается проблема MTU / MRU, почему она влияет на скорость и задержку соединения и как ее лечить (известные и современные методы), поскольку я хотел бы со знанием дела подойти к решению проблемы, не волшебным образом.
Это немного сложный вопрос, поэтому я начну с основ. Простите, если вы все это уже знаете.
MTU - это максимальная единица передачи, самый большой пакет данных, который отправляет компьютерный интерфейс. Для Ethernet значение по умолчанию - 1500 байт. Кадры Ethernet обычно могут иметь размер до 1522-1542 (зависит от того, что вы считаете), а дополнительное пространство «зарезервировано» для информации заголовка.
Различные соединения могут иметь разные возможности. Довольно часто встречается ссылка в Интернете, у которой MTU немного меньше 1500. Обычно это происходит из-за того, что ссылка использует дополнительную информацию заголовка или использует среду, отличную от «стандартного» Ethernet (большая часть Интернета фактически работает на Соединения ATM / SoNet). Обычно трафик, который встречает такую ссылку, просто разбивается на несколько частей и отправляется.
Поскольку это распространено и было во время изобретения IP, частью ответственности протокола ICMP было сообщение о любых проблемах с MTU. Если пакет по какой-либо причине не может быть нарушен и переадресован, используется ICMP, чтобы сообщить о проблеме компьютеру-отправителю. Отправляющий компьютер предпринимает соответствующие действия, разбивая информацию на более мелкие части, и все довольны. Весь этот процесс происходит за кулисами. В правильно функционирующая сеть никогда не надо гадить с настройками MTU.
Квалификатор в последнем предложении - кикер. Есть три распространенных причины, по которым автоматизированный процесс выходит из строя:
ping утилита).Итак, почему это распространено: ленивые техники / компании. Почти всегда «проще» помешать соединению с помощью крошечного 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, но могут быть адаптированы практически к любой ОС.
ping -c 2 -s 1472 -D google.com. traceroute -F google.com 1472. Это скажет вам, какой переход сломан. Примечание: CPE довольно часто не отвечает на запросы traceroute, поэтому не беспокойтесь, если первый переход не отвечает. На заметку: какой интернет-провайдер использует PPTP в наши дни ?! Это взрыв из устаревшего и бесполезного прошлого. По крайней мере, они должны использовать PPPoE; но простая авторизация модема по MAC и сегменту была бы намного проще (проще как для интернет-провайдера, так и для клиента).