¿Cuándo se fragmentará un paquete de red TCP en la capa de aplicación?

Question

¿Cuándo se fragmentará un paquete TCP en la capa de aplicación? Cuando se envía un paquete TCP desde una aplicación, ¿recibirá el destinatario en la capa de la aplicación el paquete en dos o más paquetes? Si es así, qué condiciones causan que el paquete se divida. Parece que un paquete no se fragmentará hasta que alcance el límite de Ethernet (en la capa de red) de 1500 bytes. Pero esa fragmentación será transparente para el destinatario en la capa de aplicación, ya que la capa de red volverá a ensamblar los fragmentos antes de enviar el paquete a la siguiente capa, ¿verdad?

Answer 1

Se dividirá cuando llegue a un dispositivo de red con una MTU más baja que el tamaño de los paquetes. La mayoría de los dispositivos ethernet son 1500, pero a menudo pueden ser más pequeños, 1492 si ese ethernet pasa por encima de PPPoE (DSL) debido a la información de enrutamiento adicional, incluso menor si se agrega una segunda capa como el uso compartido de conexión a Internet de Windows. ¡Y el acceso telefónico es normalmente 576!

En general, debe recordar que TCP no es un protocolo de paquete.Utiliza los paquetes en el nivel más bajo de transmitir a través de IP, pero en lo que se refiere a la interfaz para cualquier pila TCP, que es un protocolo de secuencia y no tiene ningún requisito para ofrecerle una relación 1: 1 a los paquetes físicos enviado o recibido (por ejemplo, la mayoría de las pilas contendrán mensajes hasta que haya expirado un cierto período de tiempo, o haya suficientes mensajes para maximizar el tamaño del paquete IP para la MTU dada)

Como ejemplo, si envió dos "paquetes" (llame a su función de envío dos veces), el programa receptor podría recibir solo 1 "paquete" (la pila TCP receptora podría combinarlos juntos). Si está implimenting un protocolo de tipo de mensaje a través de TCP, se debe incluir una cabecera al comienzo de cada mensaje (o algún otro encabezado/mechansim pie de página) para que el lado de recepción puede dividir el flujo TCP de nuevo en mensajes individuales, o bien cuando un mensaje se recibe en dos partes, o cuando se reciben varios mensajes como un fragmento.

Answer 2

Si un paquete de 3000 bytes entra en una red Ethernet con un tamaño de MTU predeterminado de 1500 (para ethernet), se fragmentará en dos paquetes de cada 1500 bytes de longitud. Esa es la única vez que se me ocurre.

Wireshark es su mejor opción para comprobar esto. Lo he estado usando por un tiempo y estoy totalmente impresionado

Answer 3

Si un paquete excede el máximo MTU de un dispositivo de red, se dividirá en varios paquetes. (Tenga en cuenta que la mayoría de los equipos están configurados en 1500 bytes, pero esto no es necesario).

La reconstrucción del paquete debe ser completamente transparente para las aplicaciones.

Answer 4

Correcto: la forma más informativa de ver esto es usando Wireshark, una herramienta invaluable. Tómese el tiempo para resolverlo, me ha salvado varias veces y ofrece una buena verificación de la realidad

Answer 5

Los diferentes segmentos de red pueden tener diferentes valores de MTU. En ese caso, la fragmentación puede ocurrir. Para obtener más información, vea TCP Maximum segment size

Esta (de) fragmentación ocurre en la capa TCP. En la capa de aplicación, no hay más paquetes. TCP presenta una secuencia de datos contigua a la aplicación.

Answer 6

En la capa de aplicación hay varios motivos por los cuales los 1500 bytes enteros pueden no mostrarse en una lectura. Diversos factores en el sistema operativo interno y la pila TCP pueden hacer que la aplicación obtenga algunos bytes en una llamada de lectura, y algunos en la siguiente. Sí, la pila TCP tiene que volver a ensamblar el paquete antes de enviarlo, pero eso no significa que tu aplicación lo obtendrá todo de una vez (es probable que lo obtenga en una sola lectura, pero no está GARANTIZADO obtenerlo en una lectura).

TCP intenta garantizar la entrega ordenada de bytes, con la comprobación de errores, reenvíos automáticos, etc. sucediendo a sus espaldas. Piense en ello como una tubería en la capa de aplicaciones y no se quede demasiado empantanado en cómo la pila realmente la envía a través de la red.

Answer 7

fragmentación debe ser transparente para una aplicación TCP. Tenga en cuenta que TCP es un protocolo de transmisión: ¡obtiene un flujo de datos, no paquetes! Si está creando su aplicación basándose en la idea de paquetes completos de datos, entonces tendrá problemas a menos que agregue una capa de abstracción para ensamblar paquetes completos de la transmisión y luego pasar los paquetes a la aplicación.

Answer 8

A la "capa de aplicación" un paquete TCP (bueno, segmento realmente; TCP en su propia capa no sabe a partir de paquetes) no está fragmentado, ya que no existe. La capa de aplicación es donde ve los datos como una secuencia de bytes, entregados de manera confiable y en orden.

Si está pensando en ello de otro modo, es probable que se aproxima algo en el camino equivocado. Sin embargo, esto no quiere decir que no exista una capa superior a esta, por ejemplo, una secuencia de mensajes entregados a través de este confiable y ordenado bytest.

Answer 9

La pregunta hace una suposición que no es cierto - TCP no entrega los paquetes a sus puntos finales, sino que envía un flujo de bytes (octetos). Si una aplicación escribe dos cadenas en TCP, puede entregarse como una cadena en el otro extremo; asimismo, una cadena se puede entregar como dos (o más) cadenas en el otro extremo.

RFC 793, Sección 1.5:

"El TCP es capaz de transferir una corriente continua de octetos en cada dirección entre sus usuarios por envasado de algún número de octetos en segmentos para la transmisión a través de la sistema de internet ".

Las palabras clave son corriente continua de octetos (bytes).

RFC 793, Sección 2.8:

"No hay relación necesaria entre las funciones de empuje y segmento límites Los datos en cualquier segmento particular pueden ser el resultado de una sola llamada SEND , en su totalidad. o parte, o de llamadas SEND múltiples ".

La totalidad de la sección 2.8 es relevante.

Answer 10

This página es una buena fuente de información sobre algunos de los problemas que otros han planteado, es decir, la necesidad de encapsular datos en un protocolo de aplicación por protocolo de aplicación No es autoritativo en el sentido que describe pero tiene ejemplos y tiene su origen en algunos nombres bastante importantes en la programación de redes.