¿Beneficios de "No fragmentar" en paquetes TCP?

Uno de nuestros clientes tiene problemas para enviar datos de nuestra aplicación (en su PC) a un servidor (ubicación geográfica diferente). Cuando se envían paquetes de menos de 1100 bytes, todo funciona bien, pero sobre esto vemos que TCP retransmite el paquete cada pocos segundos y no recibe respuesta. Los paquetes que estamos usando para probar son aproximadamente 1400 bytes (pero menos de 1472). Puedo enviar un ping ICMP a www.google.com de 1472 bytes y obtener una respuesta (por lo que no es su enrutador / primeros saltos).

Descubrí que nuestra aplicación establece el indicador DF para estos paquetes, y creo que un enrutador en el camino hacia el servidor tiene una MTU menor que / igual a 1100 y descarta el paquete.

Esto afecta a 1 cliente en 5000, pero dado que las rutas de todos serán diferentes, esto se espera.

Los datos son un sobre SOAP y esperamos una respuesta SOAP. No puedo justificar POR QUÉ lo hacemos, el código para hacerlo fue escrito por un desarrollador anterior.

Entonces...¿Hay algún beneficio O justificación para configurar el indicador DF en los paquetes TCP para los datos de la aplicación?

Puedo pensar en las razones por las que es necesario para las aplicaciones de diagnóstico de red, pero no en nuestra situación (queremos que los datos lleguen al punto final, fragmentados o no). Uno de nuestros administradores de sistemas dijo que podría tener algo que ver con el uso de SSL, pero que yo sepa, SSL es como un flujo e independientemente de la fragmentación, siempre que el flujo se reconstruya al final, no hay problema.

Si no hay una buena justificación, cambiaré el comportamiento de nuestra aplicación.

Gracias por adelantado.

Respuestas a la pregunta(3)

Su respuesta a la pregunta