Handshake TCP et numéros de port

Tout d'abord, les bases - une socket est le 4-tuple de (srcip, srcport, dstip, dstport). Si l'une de ces valeurs change, il s'agit d'un socket différent. Lorsqu'un hôte donné ouvre une socket TCP (ou UDP, d'ailleurs), son IP source est déjà connue, le port source est choisi de manière aléatoire dans la plage éphémère (supérieure à 1023 ou 1024 - j'ai oublié laquelle) et l'IP et le port de destination sont fournis à la pile par le processus appelant.

Du côté du serveur, une connexion est établie et vue en provenance des srcip et srcport donnés et liée aux dstport et dstip. Cette entrée (encore une fois, un couple de 4) est conservée dans la table de connexion de l'hôte, ce qui permet aux paquets entrants d'être associés à la connexion appropriée.

Le handshaking TCP est le processus par lequel les piles TCP des deux côtés négocient les paramètres des numéros de séquence, des tailles de fenêtre, etc. Au moment où cela se produit, les numéros de port ont déjà été déterminés.

Encore une fois - si cualquier des valeurs de ces tuples change après la connexion initiale, alors, par définition, les paquets ne sont plus associés à la socket d'origine.

Dans certaines circonstances, d'autres numéros de port peuvent être spécifiés par l'application utilisée (par exemple, FTP, RPC), mais dans tous les cas, il est nécessaire d'établir un protocole d'échange de données entre le serveur et le serveur. séparé et non la renumérotation d'une prise existante. Dans le cas de FTP, cela correspondrait à la connexion initiale sur le port 21 (contrôle) de l'hôte -> serveur, puis à la connexion ultérieure sur le port 20 (données) - qui, selon le mode utilisé, peut être établie dans les deux sens. Je ne saurais trop insister sur le fait qu'il s'agit de deux sockets distincts. Si l'on se réfère à la pile OSI, il s'agirait d'un problème de couche 5.

un port TCP local peut se trouver dans plusieurs connexions à la fois

Oui - pour que les clients trouver un service, il fonctionne toujours sur un port spécifique du serveur - 80 pour HTTP, 25 pour SMTP, 22 pour ssh... Un serveur web aura beaucoup de clients connectés à son port 80.

En classe, on m'a dit que lorsqu'on se connecte à un port d'écoute, les deux parties conviennent d'un port différent à utiliser.

Soit vous, soit votre professeur ne comprend pas ce qui se passe. Il existe certains protocoles pour lesquels le client et le serveur négocient un socket différent - la connexion de données FTP, certaines formes de rpc et (IIRC) les premières versions de sql*net d'Oracle fonctionnaient de cette façon - mais c'est TRES peu commune.

Votre professeur est celui qui est payé pour comprendre le problème et répondre à vos questions - je vous suggère de retourner le voir.

C'est définitivement hors sujet pour Server Fault, mais vous avez un horrible malentendu qui demande à être corrigé :-)

Tout d'abord, vous devriez laisser tomber le livre de Comer et prendre un exemplaire de TCP/IP illustré (Stevens) - c'est en grande partie une préférence personnelle, mais tous ceux que je connais préfèrent le livre de Stevens.

Venons-en maintenant à l'essentiel de votre question :

Le protocole TCP définit un "point d'extrémité" comme une paire (adresse IP, numéro de port). connexion est définie par deux points d'extrémité.

C'est conceptuellement correct. Ce que se produit réellement sur la couche de protocole est un peu différente, mais le concept d'une connexion TCP est qu'un client (votre navigateur web, par exemple) ouvre un socket local (10.0.0.1 port 30000) et se connecte à un serveur (10.10.10.10 port 80).
La connexion est le canal entre ces deux points d'extrémité.

En classe, on m'a dit que lorsqu'on se connecte à un port d'écoute, les deux parties se mettent d'accord sur un port différent à utiliser, donc la communication peut se faire et que le port d'écoute reste libre.

C'est semi-correct -- Il semble que ce que vous essayez de décrire est une version confuse du comportement de la fonction rendezvous socket à l'écoute du serveur.
Comme vous l'avez deviné, si la communication se faisait uniquement via le socket de rendez-vous, une seule machine pourrait se connecter à un listener donné à la fois (ce qui est plutôt inutile). accept() Lors de la connexion, la pile TCP du côté serveur transmet une nouvelle socket connectée sur laquelle la conversation réelle se déroule.
_{Pour tous les détails sanglants, voir le livre de Stevens, pour une description plus brève <a href="https://stackoverflow.com/questions/4734194/question-about-tcp-states-for-a-webserver-process-why-is-it-always-on-listenin">Essayez cette question StackOverflow </a>.}

Si vous voulez une petite leçon d'histoire, cette vidéo vous intéressera probablement (le moment marqué d'un signet dans ce lien correspond au moment où TCP commence à être abordé, mais l'ensemble de la vidéo, ou la série en trois parties, est quelque chose que tout étudiant sérieux en informatique qui se renseigne sur la conception des systèmes d'exploitation et/ou les réseaux devrait regarder).