Преимущества "не Фрагментируйте" на TCP-пакетах?
У одного из наших клиентов возникли проблемы с отправкой данных из нашего приложения (на их ПК) на сервер (другое географическое расположение). При отправке пакетов до 1100 байт все работает нормально, но выше этого мы видим, что TCP ретранслирует пакет каждые несколько секунд и не получает ответа. Пакеты, которые мы используем для тестирования, составляют около 1400 байт (но меньше 1472). Я могу отправить ICMP ping на www.google.com то есть 1472 байта и получить ответ (так что это не их маршрутизатор/первые несколько скачки).
Я обнаружил, что наше приложение устанавливает флаг DF для этих пакетов, и я считаю, что маршрутизатор по пути к серверу имеет MTU меньше/равный 1100 и сбрасывает пакет.
Это влияет на 1 клиента из 5000,но так как все маршруты будут разными, это ожидается.
Данные представляют собой конверт SOAP, и мы ожидаем ответ SOAP. Я не могу объяснить, почему мы это делаем, код для этого был написан предыдущим разработчиком.
Итак... Есть ли такие преимущества или оправдание установки флага DF на TCP-пакетах для данных приложения?
Я могу придумать причины, по которым это необходимо для приложений диагностики сети, но не в нашей ситуации (мы хотим, чтобы данные попали в конечную точку, фрагментированные или нет). Один из наших системных администраторов сказал, что это может иметь какое-то отношение к использованию SSL, но насколько я знаю, SSL-это как поток, и независимо от фрагментации, пока поток перестраивается в конце, нет никаких проблем.
Если нет никаких веских оснований для того, чтобы я изменил поведение нашего приложения.
Заранее благодарю.
3 ответа:
Флаг DF обычно устанавливается на IP-пакетах, несущих сегменты TCP.
Это связано с тем, что TCP-соединение может динамически изменять размер своего сегмента в соответствии с MTU пути, и лучшая общая производительность достигается, когда сегменты TCP каждый переносится в одном IP-пакете.
Таким образом, TCP-пакеты имеют флаг DF, который должен вызывать возврат пакета, необходимого для фрагментации ICMP, если промежуточный маршрутизатор должен отбросить пакет, потому что он слишком большой. Отправляющий TCP затем уменьшит свою оценку пути соединения MTU (Maximum Transmission Unit) и повторно пошлет в меньших сегментах. Если DF не задан, отправляющий TCP никогда не узнает, что он отправляет слишком большие сегменты. Этот процесс называется PMTU-D ("путь MTU Discovery").Если необходимые пакеты фрагментации ICMP не проходят, то вы имеете дело со сломанной сетью. В идеале первым шагом было бы идентифицировать неправильно настроенное устройство и исправить его; однако, если это не сработает, то вы добавляете в приложение ручку настройки, которая говорит ему установить параметр сокета
TCP_MAXSEGс помощьюsetsockopt(). (Типичный пример неправильно настроенного устройства-маршрутизатор или брандмауэр, настроенный неопытным администратором сети для удаления всех ICMP, не понимая, что необходимые пакеты фрагментации требуются TCP PMTU-D).
Операция обнаружения Path-MTU описана в RFC 1191, https://tools.ietf.org/html/rfc1191 . Для TCP лучше обнаружить путь-MTU, чем иметь каждый пакет более определенного размера, фрагментированный на две части (обычно один большой и один маленький).
По-видимому, некоторые протоколы, такие как NFS, выигрывают от избежания фрагментации (Текст ссылки). Тем не менее, вы правы в том, что вы обычно не должны запрашивать DF, если вы действительно этого не требуете.