TCP / UDP y Ethernet MTU La fragmentación

Question

He leído varios sitios y tutoriales en línea, pero todavía estoy confundido. Si el mensaje es más grande que la MTU de IP, entonces send() devuelve el byte enviado. ¿Qué ocurre con el resto del mensaje? ¿Debo llamar de nuevo y send() intento de enviar resto del mensaje? ¿O es que algo capa IP debe hacerse cargo de forma automática?

Answer 1

Si está utilizando TCP entonces la interfaz presentada a usted es el de un flujo de bytes. Usted no tiene que preocuparse acerca de cómo el flujo de bytes que lleva de un extremo de la conexión con el otro. Puede pasar por alto la MTU de la capa IP. De hecho se puede ignorar por completo la capa IP.

Cuando se llama a send() la pila TCP en su máquina se ocupará de todos los detalles necesarios para el flujo de bytes que está empujando en su envío de llamadas a aparecer a partir recv() llama en el otro extremo de la conexión.

La única cosa a recordar es que con TCP se trata de una corriente y eso significa que uno send() puede resultar en datos que llegan en múltiples llamadas recv() y múltiples llamadas send() puede resultar en datos que llegan en una sola llamada recv(). Usted no tiene ningún control sobre esto. Que se trata de un flujo de bytes y cada llamada a recv() puede devolver cualquier número de bytes desde 1 hasta el número actualmente en circulación (teniendo en cuenta los tampones adecuados pasa a la llamada recv()).

Dado que los comentaristas lo pidieron;)

En la mayoría pilas TCP send() es más probable que falle para enviar todo porque los tampones de la pila TCP están llenos y (probablemente) la ventana TCP también es completa y el flujo de control se encuentra en funcionamiento lo que significa que la pila no puede enviar más datos hasta que el extremo remoto ACK algunos datos y no está preparado para amortiguar más en su nombre. No he encontrado una pila TCP que se negará a un send() debido a consideraciones de MTU por sí solos, pero supongo que algunos sistemas embebidos, aligerado podrían comportarse de esa manera ...

De todos modos, si send() vuelve menor que el número de bytes que proporcionó entonces usted debe volver a enviar los datos restantes en algún momento. A menudo send() bloqueará y esperar hasta que pueda enviar todos los datos, y si ha establecido la toma en modo de no bloqueo a continuación, es probable que no desea volver a intentar el envío si no envía todo lo que es probable que termina en un bucle estrecho ...

Probablemente sería útil para usted ser más específico sobre el sistema operativo que está utilizando.

Answer 2

Si el paquete es demasiado grande para el transporte de la red una sugerencia de fragmentación ICMP se envía señalización del remitente para reducir el tamaño del paquete y vuelve a intentarlo.

Si utiliza TCP estos son todos los detalles que usted debe esperar que la capa de red para tomar el cuidado de usted. Lo moderna pilas IP realmente hacen detrás de las escenas de averiguar la MTU más bajo a lo largo del camino parece haberse convertido en algo de un arte negro.

WRT UDP todavía se puede esperar que la pila de fragmentar para usted pero en la práctica dado el caso de uso para su UDP no es ideal .. dependiendo de su aplicación, es probable que vea un mejor rendimiento mediante la comprensión explícitamente la ruta MTU.

... en la cuestión send () algunas pilas comportan de manera diferente, pero el tratamiento WRT El código debería ser el mismo. Digamos que tiene 100 bytes a enviar ... send () devuelve 10 bytes enviados. Es necesario seguir llamando a enviar con los 90 bytes restantes hasta que todo es empujado hacia fuera el cable para enviar el mensaje completo.

Usando el bloqueo de tomas de corriente en el envío de la plataforma de Windows () se ususally regresar después de todo lo que se envía .. .. En otras plataformas Linux y otros tendrá que seguir enviando más a menudo para empujar los datos.