Não, não há verdade na outra declaração. O que você provavelmente está confundindo com isso é o FTP ativo.
(Eu tenho uma pergunta sobre o handshake TCP e como os números de porta são atribuídos, se isso não pertencer aqui, me avise.)
Oi, estou estudando TCP / IP no livro "Internetworking with TCP / IP" de Douglas Comer. No capítulo TCP, ele menciona que o TCP define um "ponto final" como um par (endereço IP, número da porta) e uma conexão é definida por dois pontos finais.
Isso tem algumas implicações, como, por exemplo, uma porta TCP local pode estar em várias conexões ao mesmo tempo, desde que não haja duas do mesmo IP e da mesma porta remota . Isso também significa que a quantidade de conexões estabelecidas é quase ilimitada (2 ^ 16 para cada endereço IPv4. 2 ^ 48 no total).
Agora, na classe, me disseram que quando alguém se conecta a uma porta de escuta, ambos os lados concordam em usar uma porta diferente, então a comunicação pode acontecer e o soquete do ouvinte permanece livre. Essa também foi minha crença antes de ler o livro.
Agora eu sinto que devo obviamente confiar no livro (It's Comer!), mas existe alguma verdade na outra explicação?
Obrigado
Não, não há verdade na outra declaração. O que você provavelmente está confundindo com isso é o FTP ativo.
Primeiro, o básico - um socket é o 4-tuple de (srcip, srcport, dstip, dstport). Se algum desses valores for alterado, será um soquete diferente. Quando um determinado host abre um soquete TCP (ou UDP, para esse assunto) seu IP de origem já é conhecido, a porta de origem é selecionada aleatoriamente do intervalo efêmero (maior que 1023 ou 1024 - esqueça qual) e o IP e porta de destino são fornecidos para a pilha pelo processo de chamada.
No lado do servidor, uma conexão é configurada e vista vinda de srcip e srcport dada e ligada ao dstport e dstip. Esta entrada (novamente - alguma 4 tuplas) é mantida na tabela de conexão do host, a qual permitirá que pacotes de entrada sejam associados à conexão apropriada.
O handshaking TCP é o processo pelo qual as pilhas TCP nos respectivos lados negociam os parâmetros para números de seqüência, tamanhos de janela e outros. No momento em que isso ocorre, os números de porta já foram determinados.
Novamente - se qualquer dos valores dessas tuplas for alterado após a conexão inicial, por definição, os pacotes não serão mais associados ao soquete original.
Existem certas circunstâncias em que outros números de porta podem ser especificados pelo aplicativo em uso (isto é, FTP, RPC), mas em todos os casos isso exige o estabelecimento de um soquete separado , não a renumeração de um existente. No caso do FTP, isso corresponderia à conexão inicial na porta 21 (controle) do host - > servidor e, em seguida, a conexão subseqüente na porta 20 (dados) - que, dependendo do modo em uso, pode ser configurada em qualquer direção. Eu não posso enfatizar o suficiente, porém, que isso constitui dois soquetes separados. Referindo-se novamente à pilha OSI, isso seria muito mais um problema da camada 5.
a local TCP port could be in several connections at once
Sim - para que os clientes encontrem um serviço, ele sempre é executado em uma porta específica no servidor - 80 para HTTP, 25 para SMTP, 22 para ssh ... Um servidor da Web será tem muitos clientes conectados à porta 80.
Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use
Você ou seu professor não entendem o que está acontecendo. Existem alguns protocolos onde o cliente e o servidor irão negociar um soquete diferente - a conexão de dados FTP, algumas formas de rpc e (IIRC) as primeiras versões do sql * da Oracle funcionaram dessa maneira - mas é MUITO incomum.
Seu professor é aquele que está sendo pago para entender o problema e responder às suas perguntas - sugiro que volte para ele.
Isto é definitivamente fora do tópico para falha do servidor, mas você tem um mal entendido horrível que implora a correção: -)
Em primeiro lugar, você pode querer abandonar o livro de Comer e pegar uma cópia do TCP / IP Ilustrado (Stevens) - é em grande parte preferência pessoal, mas todos que eu conheço preferem o livro de Stevens.Agora, para a carne da sua pergunta:
TCP defines an "endpoint" as a pair (IP address, port number), and a connection is defined by two endpoints.
Isso é conceitualmente correto. O que realmente acontece na camada do protocolo é um pouco diferente, mas o conceito de uma conexão TCP é que um cliente (seu navegador da Web, por exemplo) abre um soquete local (10.0.0.1 porta 30000) e se conecta para um servidor (10.10.10.10 porta 80).
A conexão é o canal entre esses dois pontos finais.
Now, in class, I was told that when one connects to a listening port, both sides agree on a different port to use, so the communication can happen and the listener socket remains free.
Isso é semi-correto - parece que o que você está tentando descrever é uma versão confusa do comportamento da rendezvous socket de escuta no servidor.
Como você imaginou, se apenas tivermos nossa comunicação sobre o soquete rendezvous, somente uma máquina poderá se conectar a um listener de cada vez (o que é meio inútil), então o que realmente acontece é quando o servidor accept() s a conexão a pilha TCP no lado do servidor entrega um novo soquete conectado no qual a conversa real acontece.
Para todos os detalhes, veja o livro de Stevens, para uma breve descrição experimente esta questão do StackOverflow .
Se você quiser uma pequena lição de história, este vídeo provavelmente será interessante para você (o tempo marcado neste link é onde o TCP começa a ser discutido, mas o vídeo inteiro, ou a série de 3 partes, é algo que qualquer estudante sério de Ciência da Computação está aprendendo sobre design de SO e / ou rede deve assistir).
Tags networking tcp