Según tengo entendido, TCP toma una porción de datos y los corta ensegmentosque se transmiten a través de un TCPsesión.
Ahora supongamos que yo, como cliente, tengo dos fragmentos Ade Bdatos que quiero enviar a un servidor. Cada trozo se corta 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 que los recibirá el servidor. Afortunadamente, el servidor TCP reorganiza los segmentos desordenados por mí.
Sin embargo, para mi aplicación, los fragmentos Ay Bson completamente independientes, por lo que no quiero que el servidor esté esperando Asegmentos si se han recibido todos Blos segmentos, o viceversa. De hecho, quiero dos sesiones TCP independientes para fragmentos Ay B.
¿Es posible que un cliente y un servidor tengan sesiones TCP paralelas e independientes? Al observar las entradas del encabezado TCP, no veo ningún "número de sesión". ¿Me veo obligado a utilizar diferentes puertos de origen o de destino?
Respuesta1
Por supuesto, puede 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 de sesiones TCP no es un "número de sesión" sino la tupla(dirección local, puerto local, dirección remota, puerto remoto). Siempre que al menos uno de ellos sea diferente, es una sesión TCP diferente.
Entonces, en respuesta a su pregunta, sí, se ve obligado a utilizar un puerto de origen O de destino diferente. Su pila TCP se negará a realizar la conexión (dándole el error EADDRINUSE) si intenta utilizar el mismo puerto de origen Y de destino. Todo esto supone 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. Por lo general, los iniciadores TCP (clientes) no necesitan conectarse a un puerto en particular. Dejan que el kernel elija un puerto de origen automáticamente al no llamar bind()antes de llamar connect(). El kernel se asegurará de elegir un puerto de origen diferente para la segunda conexión.
Respuesta2
La respuesta aceptada es correcta y responde a la pregunta, pero la pregunta aborda un problema que tiene una respuesta diferente a la del uso de múltiples flujos TCP.
El problema del "bloqueo de cabecera de línea" que está describiendo es una de las motivaciones detrás del protocolo Quick UDP Internet Connections (QUIC). recomiendo mirareste webcastde Google sobre QUIC si está interesado en cómo esto resuelve ese y otros problemas.
Por supuesto, hayQUIC en Wikipediatambién.