Преимущества "Не фрагментировать" на TCP-пакетах?

У одного из наших клиентов возникли проблемы с отправкой данных из нашего приложения (на их ПК) на сервер (другое географическое местоположение). При отправке пакетов в 1100 байт все работает нормально, но выше этого мы видим, что TCP ретранслирует пакет каждые несколько секунд и не получает ответа. Пакеты, которые мы используем для тестирования, составляют около 1400 байт (но меньше 1472). Я могу отправить запрос ICMP на www.google.com, который составляет 1472 байта, и получить ответ (так что это не их маршрутизатор/первые несколько переходов).

Я обнаружил, что наше приложение устанавливает флаг DF для этих пакетов, и я считаю, что маршрутизатор по пути к серверу имеет MTU меньше/равно 1100 и отбрасывает пакет.

Это влияет на 1 клиент в 5000, но поскольку все маршруты будут разными, это ожидается.

Данные - это SOAP-конверт, и мы ожидаем ответа SOAP. Я не могу оправдать ПОЧЕМУ мы это делаем, код для этого был написан предыдущим разработчиком.

Итак... Есть ли какие-либо преимущества или обоснование для установки флага DF для пакетов TCP для данных приложения?

Я могу думать о причинах, которые необходимы для сетевых диагностических приложений, но не в нашей ситуации (мы хотим, чтобы данные доходили до конечной точки, фрагментировались или нет). Одна из наших системных администраторов сказала, что это может иметь отношение к нам с использованием SSL, но насколько я знаю, SSL подобен потоку и независимо от фрагментации, пока поток не будет восстановлен в конце, нет проблем.

Если нет хорошего оправдания, я буду изменять поведение нашего приложения.

Спасибо заранее.

Ответ 1

Флаг DF обычно устанавливается на IP-пакеты, несущие сегменты TCP.

Это связано с тем, что TCP-соединение может динамически изменять размер сегмента для соответствия MTU пути, а лучшая общая производительность достигается, когда каждый из сегментов TCP переносится в одном IP-пакете.

Таким образом, у TCP-пакетов установлен флаг DF, что должно привести к возврату пакета фрагментации ICMP, если промежуточный маршрутизатор должен отказаться от пакета, потому что он слишком велик. Затем отправляющий TCP уменьшит свою оценку MTU пути соединения (Maximum Transmission Unit) и повторно отправит в меньшие сегменты. Если DF не был установлен, отправляющий TCP никогда не узнает, что он посылает слишком большие сегменты. Этот процесс называется PMTU-D ( "Path MTU Discovery" ).

Если пакеты ICMP Fragmentation Needed не пройдут, тогда вы имеете дело с разбитой сетью. В идеале первым шагом было бы определить неправильно сконфигурированное устройство и исправить его; однако, если это не сработает, вы добавите в приложение ручку конфигурации, которая сообщает ей, чтобы установить опцию TCP_MAXSEG сокета с помощью setsockopt(). (Типичным примером неправильно сконфигурированного устройства является маршрутизатор или брандмауэр, который был сконфигурирован неопытным администратором сети, чтобы удалить все ICMP, не понимая, что требуемые пакеты для фрагментации требуются TCP PMTU-D).

Ответ 2

Операция обнаружения Path-MTU описана в RFC 1191, https://tools.ietf.org/html/rfc1191. Лучше TCP обнаруживать Path-MTU, чем иметь каждый пакет с определенным размером, фрагментированным на две части (обычно один большой и один маленький).

Ответ 3

По-видимому, некоторые протоколы, такие как NFS, могут избежать фрагментации (текст ссылки). Тем не менее, вы правы в том, что обычно вам не следует запрашивать DF, если вы действительно этого не требуете.