¿Los sockets TCP ponen en cola múltiples mensajes en un búfer para leerlos uno a la vez? ¿O el búfer solo almacena el mensaje recibido más recientemente?

Respuesta corta: pone en cola múltiples mensajes en una cola que la aplicación lee en secuencia, uno a la vez.

TCP establece una conexión confiable entre los dos pares TCP. Después de que se entrega un mensaje al par TCP receptor, el remitente recibe un acuse de recibo que libera el búfer que contiene la copia del mensaje del remitente. En el nivel TCP (capa de transporte), los datos ahora son responsabilidad de la entidad TCP receptora. Debe mantener estos datos en sus buffers hasta que la aplicación los haya leído a través de su socket abierto.

Dependiendo del tamaño de la ventana dinámica actualmente activa entre el remitente TCP y el TCP receptor, podría haber varios segmentos de datos transferidos con éxito del remitente al receptor que se ubicarán en los buffers TCP del receptor para que la aplicación los lea.

Tenga en cuenta que, a nivel de aplicación, la aplicación de envío y recepción que acuerda si los datos enviados han sido recibidos y leídos (y procesados) con éxito por la aplicación receptora no es responsabilidad de TCP. Si la aplicación lee datos del socket TCP y los almacena en sus propias colas, pero no puede procesarlos, no es culpa de TCP. TCP liberará las memorias intermedias para los mensajes tan pronto como la aplicación los lea.

Cuando el TCP receptor no puede asignar más memorias intermedias (ya sea debido a la escasez de recursos o al cruzar el límite de la memoria intermedia configurada) dejará de enviar acuses de recibo al remitente, evitando así que el remitente envíe más mensajes. Los mensajes no enviados permanecen en los buffers del TCP de envío, y cuando se llenan, el socket TCP de envío deja de aceptar nuevos mensajes de su aplicación de envío, asegurando así el control de flujo de extremo a extremo.

Sí. TCP admite una llamada de concepto ventanas deslizantes. Esta facilidad permite la transmisión confiable de datos usando dicho protocolo. El lado del búfer depende del protocolo y del lado de la ventana deslizante.

http://en.m.wikipedia.org/wiki/S …

Además, las bibliotecas de red también proporcionan capacidades de E / S de red almacenadas en memoria intermedia que almacenan una cantidad adicional de paquetes recibidos.

TCP no tiene concepto de mensajes, es todo un flujo continuo. No importa si un remitente envía varios fragmentos por separado porque el receptor no obtendrá ningún límite de mensaje de TCP. Por ejemplo, enviar “hola” y luego “mundo” podría recibirse como:

• “Hola Mundo”
• “Hola Mundo”
• “Hola Mundo”
• “Hola Mundo”
• cualquier otra cosa como esa

Por lo tanto, el protocolo utilizado en la parte superior de TCP debe implementar límites de mensaje en sí mismo si son necesarios.

En cuanto al almacenamiento en búfer, TCP garantiza la entrega de mensajes hasta la aplicación. Si el receptor es lento, los datos no se perderán.

El punto de almacenamiento en búfer es la eficiencia de transferencia de datos para múltiples segmentos. Eso es bueno para los protocolos de transferencia de archivos como FTP, pero malo para los interactivos como SSH. Para estos, desea que el remitente establezca el indicador PSH (Push) en el encabezado TCP (hecho a nivel del núcleo). El socket receptor ve el indicador PSH y lo envía a la API de inmediato, sin esperar en el búfer.

Hay otra bandera relacionada que hace casi lo mismo, el puntero URG (Urgente). Cuando el puntero URG está activado, el receptor lee un campo de 2 bytes que describe la ubicación selectiva de los datos de prioridad dentro de la carga útil de un segmento.

La mayoría de los sistemas modernos tienen amortiguadores significativos ya que el almacenamiento rápido ha bajado de precio. Además, cada conmutador y enrutador a lo largo de la tubería también tiene buffers.

Entonces, la respuesta a su pregunta es sí, pero tenga en cuenta que cualquier paquete (que llame mensajes) puede contener de 0 a 1500 caracteres (bytes) o más de datos.

El núcleo de TCP son los paquetes ACK (reconocimiento) que el destinatario envía cuando recibe un bloque de paquetes contiguos (tamaño de ventana deslizante negociado al inicio del socket) que coincide con una suma de verificación. Esto le indica al remitente que envíe más datos o retransmita los mismos datos nuevamente hasta que se reciba el paquete ACK correspondiente.

Esto hace que TCP sea un sistema de entrega de datos confiable, en oposición al protocolo UDP más rápido pero menos confiable.