Sessões TCP paralelas para destino fixo e portas de origem

Sessões TCP paralelas para destino fixo e portas de origem

Pelo que entendi, o TCP pega um pedaço de dados e o divide emsegmentosque são transmitidos através de um TCPsessão.

Agora suponha que eu, como cliente, tenha dois pedaços Ade Bdados que desejo enviar para um servidor. Cada pedaço é cortado em 3 segmentos, formando um total de 6 segmentos.

Enviarei esses 6 segmentos pela Internet, mas não posso garantir a ordem em que o servidor os receberá. Felizmente, o servidor TCP reorganiza os segmentos fora de ordem para mim.

No entanto, para meu aplicativo, os pedaços Ae Bsão completamente independentes, portanto, não quero que o servidor fique aguardando Asegmentos se todos Bos segmentos tiverem sido recebidos ou vice-versa. Na verdade, quero duas sessões TCP independentes para pedaços Ae arquivos B.

É possível que um cliente e um servidor tenham sessões TCP paralelas e independentes? Olhando para as entradas do cabeçalho TCP, não vejo nenhum "número de sessão". Sou forçado a usar portas de origem ou destino diferentes?

Responder1

É claro que você pode ter duas sessões TCP paralelas e independentes entre o mesmo cliente e servidor. Caso contrário, apenas para dar um exemplo, os navegadores da web não seriam capazes de buscar uma página HTML e uma imagem, ou duas imagens de um servidor da web ao mesmo tempo.

O discriminador para sessões TCP não é um "número de sessão", mas a tupla(endereço local, porta local, endereço remoto, porta remota). Contanto que pelo menos um deles seja diferente, é uma sessão TCP diferente.

Então, em resposta à sua pergunta, sim, você é forçado a usar uma porta de origem OU de destino diferente. Sua pilha TCP se recusará a fazer a conexão (dando erro EADDRINUSE) se você tentar usar a mesma porta de origem e destino. Tudo isso assumindo que o endereço local e o endereço remoto são totalmente iguais.

Mas isso não é algo com que você normalmente precise se preocupar. Normalmente, os iniciadores TCP (clientes) não precisam se vincular a uma porta específica. Eles permitem que o kernel escolha uma porta de origem automaticamente, não chamando bind()antes de ligar connect(). O kernel escolherá uma porta de origem diferente para a segunda conexão.

Responder2

A resposta aceita está correta e responde à pergunta, mas a pergunta aborda um problema que tem uma resposta diferente do uso de vários fluxos TCP.

O problema de "bloqueio de linha" que você está descrevendo é uma motivação por trás do protocolo Quick UDP Internet Connections (QUIC). Eu recomendo assistireste webcastdo Google sobre QUIC se você estiver interessado em saber como isso resolve esse e outros problemas.

Claro, háQUIC na Wikipédiatambém.

informação relacionada