soap - ¿Beneficios de "No Fragmentar" en los paquetes TCP?
ssl packet (3)
Aparentemente, algunos protocolos como NFS se benefician al evitar la fragmentación ( texto de enlace ). Sin embargo, tiene razón en que normalmente no debería solicitar DF a menos que realmente lo requiera.
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).
Descubrí 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 o igual a 1100 y descartando el paquete.
Esto afecta a 1 cliente en 5000, pero como las rutas de todos serán diferentes, se espera esto.
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?
Puedo pensar en razones por las cuales 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, cambiaré el comportamiento de nuestra aplicación.
Gracias por adelantado.
El indicador DF generalmente se establece en paquetes IP que llevan segmentos TCP.
Esto se debe a que una conexión TCP puede cambiar dinámicamente su tamaño de segmento para que coincida con la MTU de la ruta, y se logra un mejor rendimiento general cuando los segmentos TCP se transportan cada uno en un paquete IP.
Por lo tanto, los paquetes TCP tienen el indicador DF configurado, lo que debería provocar la devolución de un paquete ICMP Fragmentation Needed 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 un control de configuración a su aplicación que le indique que configure la opción de socket setsockopt() 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 descartar todo el ICMP, sin darse cuenta de que los paquetes de Fragmentation Needed son requeridos por TCP PMTU-D).
La operación del descubrimiento Path-MTU se describe en RFC 1191, https://tools.ietf.org/html/rfc1191 . Es mejor para TCP descubrir el Path-MTU que tener cada paquete sobre un cierto tamaño fragmentado en dos partes (generalmente una grande y una pequeña).