¿Pueden los paquetes TCP llegar al receptor por piezas?
Por ejemplo, si envío 20 bytes usando el protocolo TCP, ¿puedo estar 100% seguro de que recibiré exactamente 20 bytes a la vez, no 10 bytes y luego otros 10 bytes?
Y la misma pregunta para el protocolo UDP.
Sé que UDP no es confiable y que los paquetes no pueden llegar o llegar en un orden diferente, pero ¿qué pasa con un solo paquete? Si llega, ¿puedo estar seguro de que es un paquete completo, no una pieza?
networking
tcp
udp
iamnp
fuente
fuente
Respuestas:
Sí. IP admite la fragmentación, aunque TCP generalmente intenta determinar la ruta MTU y mantener sus paquetes más pequeños que eso por razones de rendimiento. La fragmentación aumenta la tasa de pérdida de datagramas catastróficamente. Si una ruta tiene una tasa de pérdida de paquetes del 10%, fragmentar un datagrama en dos paquetes hace que la tasa de pérdida de datagramas sea casi del 20%. (Si se pierde cualquiera de los paquetes, se pierde el datagrama).
Sin embargo, no tiene que preocuparse por esto, y tampoco la capa TCP. La capa IP vuelve a ensamblar los paquetes en datagramas completos.
No, pero eso no tiene nada que ver con los paquetes. TCP es, fundamentalmente, un protocolo de flujo de bytes que no conserva los límites de los mensajes de la aplicación.
Lo mismo es cierto para TCP. Los paquetes son paquetes. La diferencia es que TCP tiene reintentos y reordenamientos integrados en el protocolo, mientras que UDP no.
No, pero ese no es tu problema. El protocolo UDP maneja el reensamblaje de datagramas. Eso es parte de su trabajo. (En realidad, el protocolo IP hace esto para el protocolo UDP, por lo que UDP lo hace simplemente por capas sobre IP). Si un datagrama se divide en dos paquetes, el protocolo IP lo volverá a ensamblar para el protocolo UDP, por lo que verá los datos completos.
fuente
No puedes estar seguro de que realmente lleguen físicamente de una vez. Las capas de enlace de datos debajo de TCP / UDP pueden dividir su paquete si así lo desean. Especialmente si envía datos a través de Internet o cualquier red fuera de su control, es difícil predecirlo.
Pero no importa si los datos llegan en un paquete o en varios paquetes al receptor. El sistema operativo debe abstraer la concatenación de estos paquetes, por lo que para su aplicación todavía parece que todo llegó de una vez. Por lo tanto, a menos que sea un pirata informático del núcleo, en la mayoría de los casos no debe preocuparse si estos datos se transfieren en uno o varios paquetes.
Para UDP, el sistema operativo también hará algo de abstracción, por lo que la aplicación que recibe los datos no tiene que saber en cuántos paquetes se han transmitido los datos. Pero la diferencia con TCP es que no hay garantía de que los datos lleguen realmente. También es posible que los datos se dividan en múltiples paquetes, y algunos lleguen y otros no. Para la aplicación receptora, de todos modos, parece una secuencia de datos, sin importar si está completa o no.
fuente
Ejemplos. Los bloques de caracteres contiguos corresponden a las llamadas send ():
TCP:
Todos los datos enviados se reciben en orden, pero no necesariamente en los mismos fragmentos.
UDP:
Los datos no están necesariamente en el mismo orden y no se reciben necesariamente, pero los mensajes se conservan en su totalidad.
fuente
No, TCP es un protocolo de flujo, mantiene los datos en orden pero no los agrupa por mensaje. Por otro lado, UDP está orientado a mensajes, pero no es confiable. SCTP tiene lo mejor de ambos mundos, pero no se puede usar de forma nativa porque los NAT rompen Internet.
fuente
Hay cierta seguridad de que si envía 20 bytes al comienzo de una secuencia TCP, no llegará como dos piezas de 10 bytes. Esto se debe a que la pila TCP no enviará segmentos tan pequeños: hay un tamaño mínimo de MTU. Sin embargo, si el envío está en algún lugar en medio de una transmisión, todas las apuestas están desactivadas. Podría ser que su pila de protocolos tome 10 bytes de los datos para llenar un segmento y enviarlo, y luego los siguientes diez bytes van a otro segmento.
Su pila de protocolos divide los datos en fragmentos y los coloca en una cola. Los tamaños de los fragmentos se basan en la ruta MTU. Si realiza una operación de envío, y todavía hay datos en cola pendientes, la pila de protocolos normalmente mirará el segmento que está en la cola de la cola y verá si hay espacio en ese segmento para agregar más datos. La habitación puede ser tan pequeña como un byte, por lo que incluso un envío de dos bytes se puede dividir en dos.
Por otro lado, la segmentación de datos significa que puede haber lecturas parciales. Una operación de recepción puede potencialmente despertarse y obtener datos cuando llega tan solo un segmento. En la API de sockets ampliamente implementada, una llamada de recepción puede solicitar 20 bytes, pero podría regresar con 10. Por supuesto, se puede construir una capa de almacenamiento en búfer que se bloqueará hasta que se reciban 20 bytes o se rompa la conexión. En el mundo POSIX, esa API puede ser la secuencia de E / S estándar: puede usar
fdopenun descriptor de socket para obtener unaFILE *secuencia, y puede usarlafreadpara llenar un búfer de modo que la solicitud completa se satisfaga con tantasreadllamadas como sea necesario .Los datagramas UDP enmarcan los datos. Cada llamada de envío genera un datagrama (pero vea más abajo sobre el descorche). El otro lado recibe un datagrama completo (y, en la API del socket, debe especificar un búfer lo suficientemente grande como para contenerlo, de lo contrario, el datagrama se truncará). Los grandes datagramas se fragmentan por fragmentación de IP y se vuelven a ensamblar de forma transparente para las aplicaciones. Si falta algún fragmento, se pierde todo el datagrama; no hay forma de leer datos parciales en esa situación.
Existen extensiones a la interfaz que permiten múltiples operaciones para especificar un solo datagrama. En Linux, se puede "tapar" un socket (evitar que se envíe). Mientras se tapa, los datos escritos se ensamblan en una sola unidad. Luego, cuando el zócalo está "descorchado", se puede enviar un solo datagrama.
fuente