1 votos

Sesiones TCP paralelas para puertos de destino y fuente fijos

Según entiendo, TCP toma un trozo de datos y lo divide en segmentos que se transmiten a través de una sesión TCP.

Ahora supongamos que yo, como cliente, tengo dos trozos A, B de datos que quiero enviar a un servidor. Cada trozo se divide en 3 segmentos, formando un total de 6 segmentos.

Enviaré esos 6 segmentos a través de Internet, pero no puedo garantizar el orden en el que el servidor los recibirá. Afortunadamente, el servidor TCP reorganiza los segmentos fuera de orden por mí.

Sin embargo, para mi aplicación, los trozos A y B son completamente independientes, por lo que no quiero que el servidor esté esperando los segmentos de A si todos los segmentos de B han sido recibidos, o viceversa. En efecto, quiero dos sesiones TCP independientes para los trozos A y B.

¿Es posible que un cliente y un servidor tengan sesiones TCP paralelas e independientes? Al observar las entradas del encabezado TCP, no veo un "número de sesión". ¿Estoy obligado a usar puertos de origen o destino diferentes?

5voto

Celada Puntos 3781

Puedes tener dos sesiones TCP paralelas e independientes entre el mismo cliente y servidor. De lo contrario, por ejemplo, los navegadores web no podrían recuperar una página HTML y una imagen, o dos imágenes de un servidor web al mismo tiempo.

El discriminador para las sesiones TCP no es un "número de sesión" sino la tupla (dirección-local, puerto-local, dirección-remota, puerto-remoto). Mientras al menos uno de esos sea diferente, es una sesión TCP diferente.

Entonces, en respuesta a tu pregunta, sí, estás obligado a usar un puerto de origen O destino diferente. Tu pila TCP se negará a establecer la conexión (dándote el error EADDRINUSE) si intentas usar el mismo puerto de origen Y destino. Esto asumiendo que la dirección local y la dirección remota son las mismas en todo momento.

Pero esto no es algo de lo que normalmente tengas que preocuparte. Normalmente, los iniciadores TCP (clientes) no necesitan enlazarse a un puerto en particular. Permiten que el kernel elija automáticamente un puerto de origen al no llamar a bind() antes de llamar a connect(). El kernel se asegurará de elegir un puerto de origen diferente para la segunda conexión.

0voto

bytesinflight Puntos 71

La respuesta aceptada es correcta y responde a la pregunta, pero la pregunta aborda un problema que tiene una respuesta diferente al uso de múltiples flujos TCP.

El problema de "bloqueo en la cabeza de línea" que estás describiendo es una de las motivaciones detrás del protocolo Quick UDP Internet Connections (QUIC). Te recomiendo que veas este seminario web de Google sobre QUIC si estás interesado en cómo esto resuelve ese y otros problemas.

Por supuesto, también está QUIC en Wikipedia.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X