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

Question

Pelo que entendi, o TCP pega um pedaço de dados e os corta em segmentos que são transmitidos através de uma sessão TCP .

Agora, suponha que eu, como cliente, tenha dois fragmentos A , B de dados que eu quero enviar para um servidor. Cada pedaço é cortado em 3 segmentos, formando um total de 6 segmentos.

Eu enviarei esses 6 segmentos pela Internet, mas não posso garantir a ordem que o servidor irá recebê-los. Felizmente, o servidor TCP reorganiza os segmentos fora de ordem para mim.

No entanto, para meu aplicativo, os fragmentos A e B são completamente independentes, portanto, não quero que o servidor aguarde A segmentos se todos os segmentos B tiverem sido recebidos ou vice-versa . De fato, eu quero duas sessões TCP independentes para os fragmentos A e 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". Eu sou forçado a usar diferentes portas de origem ou destino?

    

Answer 1

Claro que você pode ter duas sessões TCP paralelas e independentes entre o mesmo cliente e servidor. Caso contrário, apenas por exemplo, os navegadores da Web não poderiam 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) . Desde 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 ou porta de destino diferente. Sua pilha TCP se recusará a fazer a conexão (dando erro EADDRINUSE) se você tentar usar a mesma origem e porta de destino. Isso tudo está assumindo que o endereço local e o endereço remoto são os mesmos.

Mas isso não é algo que você geralmente precisa se preocupar. Geralmente, os iniciadores TCP (clientes) não precisam se ligar a uma porta específica. Eles permitem que o kernel escolha uma porta de origem automaticamente, não chamando bind() antes de chamarem connect() . O kernel irá certificar-se de escolher uma porta de origem diferente para a segunda conexão.

    

Answer 2

A resposta aceita está correta e responde à pergunta, mas a questão resolve um problema que tem uma resposta diferente do que usar vários fluxos TCP.

O problema "head of line blocking" que você está descrevendo é uma motivação por trás do protocolo Quick UDP Internet Connections (QUIC). Recomendamos que você assista a este webcast do Google sobre o QUIC, caso esteja interessado em saber como isso resolve esses e outros problemas.

É claro que QUIC na Wikipédia também.