У одного из наших клиентов возникли проблемы с отправкой данных из нашего приложения (на их ПК) на сервер (в другом географическом местоположении). При отправке пакетов в 1100 байт все работает нормально, но выше этого мы видим, что TCP ретранслирует пакет каждые несколько секунд и не получает ответа. Пакеты, которые мы используем для тестирования, составляют около 1400 байт (но меньше 1472). Я могу отправить запрос ICMP на www.google.com, который составляет 1472 байта, и получить ответ (так что это не их маршрутизатор/первые несколько переходов).Преимущества "Do not Fragment" на TCP-пакетах?
Я обнаружил, что наше приложение устанавливает флаг DF для этих пакетов, и я считаю, что маршрутизатор по пути к серверу имеет MTU меньше/равно 1100 и отбрасывает пакет.
Это влияет на 1 клиента в 5000, но поскольку все маршруты будут разными, это ожидается.
Данные представляют собой SOAP-конверт, и мы ожидаем ответа SOAP. Я не могу оправдать ПОЧЕМУ мы это делаем, код для этого был написан предыдущим разработчиком.
So ... Есть ли какие-либо преимущества или обоснование для установки флага DF на пакеты TCP для данных приложения?
Я могу придумать причины, которые необходимы для сетевых диагностических приложений, но не в нашей ситуации (мы хотим, чтобы данные доходили до конечной точки, фрагментировались или нет). Один из наших системных администраторов сказал, что это может иметь отношение к нам с использованием SSL, но насколько я знаю, SSL подобен потоку и независимо от фрагментации, пока поток будет восстановлен в конце, нет проблем.
Если нет хорошего оправдания, я буду изменять поведение нашего приложения.
Заранее спасибо.
Каков фактический вызов API сокета, который вы делаете, что приводит к установке бит DF? –
Есть несколько хороших дискуссий о том, где DF может быть полезен здесь: http://stackoverflow.com/questions/351806/where-is-the-dont-fragment-bit-of-the-ip-flags-used - in Короче говоря, это похоже на ситуацию, когда, если вы не знаете, что вам это нужно, тогда вы этого не сделаете. –