¿Beneficios de "No Fragmentar" en los paquetes TCP?

Question

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

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

Esto afecta a 1 cliente en 5000, pero como 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 hacer esto fue escrito por un desarrollador anterior.

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

No puedo pensar en razones por las que es necesario para 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 nosotros al usar SSL, pero hasta donde yo sé, SSL es como una secuencia e independientemente de la fragmentación, siempre que la secuencia se reconstruya al final, no hay problema.

Si no hay una buena justificación voy a cambiar el comportamiento de nuestra aplicación.

Gracias de antemano.

Answer 1

La bandera DF generalmente se establece en paquetes IP que transportan segmentos TCP.

Esto se debe a que una conexión TCP puede cambiar dinámicamente el tamaño de su segmento para que coincida con la MTU de ruta, y se logra un mejor rendimiento general cuando los segmentos TCP se transportan en un solo paquete IP.

Así que los paquetes TCP tienen el indicador DF configurado, que debe provocar que se devuelva un paquete de Fragmentación ICMP necesaria si un enrutador intermedio tiene que descartar un paquete porque es demasiado grande. El TCP emisor reducirá su estimación de la MTU de ruta de conexión (Unidad máxima de transmisión) y volverá a enviarse en segmentos más pequeños. Si no se configuró DF, el TCP emisor nunca sabría que estaba enviando segmentos que son demasiado grandes. Este proceso se llama PMTU-D ("Path MTU Discovery").

Si los paquetes de Fragmentación necesaria de ICMP no se están procesando, entonces se trata de una red interrumpida. Idealmente, el primer paso sería identificar el dispositivo mal configurado y corregirlo; sin embargo, si eso no funciona, agregue una perilla de configuración a su aplicación que le indique que configure la opción de socket TCP_MAXSEG con setsockopt(). (Un ejemplo típico de un dispositivo mal configurado es un enrutador o firewall que ha sido configurado por un administrador de red sin experiencia para eliminar todo ICMP, sin darse cuenta de que los paquetes requeridos por Fragmentación son requeridos por TCP PMTU-D).

Answer 2

Aparentemente, algunos protocolos como NFS se benefician al evitar la fragmentación (link text). Sin embargo, tiene razón en que normalmente no debería solicitar DF ​​a menos que realmente lo requiera.

Answer 3

El funcionamiento del descubrimiento Path-MTU se describe en RFC 1191, https://tools.ietf.org/html/rfc1191. Es mejor para TCP descubrir Path-MTU que tener cada paquete más de un cierto tamaño fragmentado en dos partes (generalmente una grande y una pequeña).