
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 A
de B
dados 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 A
e B
são completamente independentes, portanto, não quero que o servidor fique aguardando A
segmentos se todos B
os segmentos tiverem sido recebidos ou vice-versa. Na verdade, quero duas sessões TCP independentes para pedaços A
e 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.