Important:

je suis désolé de dire que la réponse de" Borealid " est imprécise et quelque peu incorrecte - tout d'abord, il n'y a pas de rapport à l'état d'esprit ou à l'apatridie pour répondre à cette question, et surtout la définition du tuple pour une socket est incorrecte.

rappelez-vous d'abord ci-dessous deux règles:

1. clé primaire d'une socket: A la socket est identifiée par {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL} et non par {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT} - le Protocole est un élément important de la définition d'une socket.

2. OS Process & Socket mapping: un processus peut être associé à (peut ouvrir/peut écouter) plusieurs sockets qui peuvent être évidents pour de nombreux lecteurs.

exemple 1: deux clients se connectant au même port de serveur signifie: socket1 {SRC-A, 100, DEST-X,80, TCP} et socket2{SRC-B, 100, DEST-X,80, TCP} . Ce signifie que l'hôte a se connecte au port 80 du serveur X et qu'un autre hôte B se connecte également au même serveur X sur le même port 80. Maintenant, la façon dont le serveur gère ces deux sockets dépend de si le serveur est mono-threadé ou multi-threadé (Je l'expliquerai plus tard). Ce qui est important, c'est qu'un serveur peut écouter à prises multiples simultanément.

pour répondre À la question initiale du post:

sans distinction de nationalité ou protocoles apatrides, deux clients peuvent se connecter au même port de serveur parce que pour chaque client nous pouvons assigner une socket différente (comme L'IP du client sera certainement différent). Un même client peut aussi avoir deux sockets se connectant au même port de serveur - puisque ces sockets diffèrent par SRC-PORT . En toute justice, "Borealid" a essentiellement mentionné la même réponse correcte, mais la référence à "Sans état/complet" était en quelque sorte inutile/déroutante.

pour répondre À la deuxième partie de la question sur comment un serveur connaît la prise de réponse. Tout d'abord, comprenez que pour un processus serveur unique qui écoute le même port, il peut y avoir plus d'une socket (peut provenir d'un même client ou de clients différents). Maintenant, tant qu'un serveur sait quelle requête est associée à quelle socket, il peut toujours répondre au client approprié en utilisant la même socket. Ainsi, un serveur n'a jamais besoin d'ouvrir un autre port dans son propre noeud que celui d'origine sur lequel le client a d'abord essayé de bind connecter. Si un serveur affecte des ports de serveur différents après qu'une socket est liée, alors à mon avis le serveur gaspille sa ressource et il doit avoir besoin du client à bind se connecter à nouveau au nouveau port assigné.

un peu plus complet:

exemple 2: c'est une question très intéressante que les deux processus différents d'un serveur peuvent écouter la même port. Si vous ne considérez pas le protocole comme l'un des paramètre définissant socket alors la réponse est non. Initiatively c'est donc parce que nous pouvons dire que dans ce cas, pour un seul client tente de se connecter à un serveur-port n'aura pas de mécanisme de mentionner lequel des deux processus d'écoute le client a l'intention de. C'est le même thème affirmé par la règle (2). Cependant, c'est une mauvaise réponse car 'protocol' fait aussi partie de la définition de la socket. Ainsi deux processus dans un même noeud peuvent écouter la même port seulement s'ils utilisent un protocole différent. Par exemple, deux clients indépendants (l'un utilise TCP et l'autre UDP) peuvent bind se connecter et communiquer au même noeud serveur et au même port, mais ils doivent être servis par deux serveurs-processus différents.

types de serveurs-simple et multiple:

quand un serveur traite l'écoute d'un port qui signifie que plusieurs sockets peuvent se connecter et communiquer simultanément avec le même processus serveur. Si un serveur n'utilise qu'un seul processus enfant pour servir toutes les sockets, alors le serveur s'appelle un processus unique/threaded et si le serveur utilise de nombreux sous-processus pour servir chaque socket par un sous-processus, alors le serveur s'appelle multi-processus/threaded server. Notez que quel que soit le type du serveur, un serveur peut/doit toujours utiliser la même socket initiale pour répondre (pas besoin d'allouer un autre port-serveur).

suggérée livres et le reste des deux volumes si vous le pouvez.

Note sur l'Enfant et le Parent (en réponse à requête/commentaire de "Alexandru Ioan Cucu')

chaque fois que j'ai mentionné un concept en relation avec deux processus disent A et B, considérez qu'ils ne sont pas liés par la relation parent-enfant. Les OS (particulièrement UNIX) permettent à un processus enfant d'hériter de tous les descripteurs de fichiers (FD) des parents. Ainsi, toutes les sockets (sous UNIX comme OS font aussi partie de FD) qu'un processus à l'écoute, peut être écouté par beaucoup plus de processus A1, A2, .. aussi longtemps qu'ils sont liés par la relation parent-enfant à A. Mais un processus indépendant B (c.-à-d. n'ayant pas de relation parent-enfant à A) ne peut pas écouter la même prise. En outre, notez également que cette règle de rejet de deux processus indépendants pour écouter la même socket se trouve sur un OS (ou ses bibliothèques réseau) et de loin elle est obéie par la plupart des OS. Cependant, on peut créer son propre OS qui peut très bien violer ces restrictions.

TCP / HTTP Écoute Sur les Ports: Comment de Nombreux Utilisateurs Partagent le Même Port

alors, que se passe-t-il lorsqu'un serveur écoute les connexions entrantes sur un port TCP? Par exemple, disons que vous avez un serveur web sur le port 80. Supposons que votre ordinateur ait l'adresse IP publique de 24.14.181.229 et que la personne qui essaie de se connecter à vous ait l'adresse IP 10.1.2.3. Cette personne peut se connecter à vous en ouvrant une socket TCP à 24.14.181.229:80. Assez Simple.

intuitivement (et à tort), la plupart des gens pensent qu'il ressemble à quelque chose comme ceci:

    Local Computer    | Remote Computer
    --------------------------------
    <local_ip>:80     | <foreign_ip>:80

    ^^ not actually what happens, but this is the conceptual model a lot of people have in mind.

c'est intuitif, car du point de vue du client, il a une adresse IP, et se connecte à un serveur à IP:PORT. Puisque le client se connecte au port 80, alors son port doit être 80 aussi? C'est une chose sensée à penser, mais en fait pas ce qui se passe. Si cela devait être exact, nous ne pourrions servir qu'un utilisateur par adresse IP étrangère. Une fois un ordinateur distant connecte, puis il monopolise le port 80 à la connexion du port 80, et personne d'autre ne peut se connecter.

trois choses doivent être comprises:

1.) Sur un serveur, un processus est listening sur un port. Une fois qu'il a une connexion, il le remet à un autre fil. La communication n'est jamais le port d'écoute.

2.) Les connexions sont identifiées de manière unique par le système D'exploitation au moyen du 5-tuple suivant: (local-IP, local-port, remote-IP, distance du port, protocole). Si l'un des éléments du tuple est différent, il s'agit alors d'une connexion complètement indépendante.

3. Lorsqu'un client se connecte à un serveur, il sélectionne un port source aléatoire et non utilisé . De cette façon, un seul client peut avoir jusqu'à ~64k connexions au serveur pour le même port de destination.

donc, c'est vraiment ce qui se crée quand un client se connecte à un serveur:

    Local Computer   | Remote Computer           | Role
    -----------------------------------------------------------
    0.0.0.0:80       | <none>                    | LISTENING
    127.0.0.1:80     | 10.1.2.3:<random_port>    | ESTABLISHED

en Regardant Ce qui se Passe Réellement

tout d'abord, utilisons netstat pour voir ce qui se passe sur cet ordinateur. Nous utiliserons le port 500 au lieu de 80 (parce qu'un tas de choses se passe sur le port 80 car c'est un port commun, mais fonctionnellement cela ne fait pas de différence).

    netstat -atnp | grep -i ":500 "

Comme prévu, la sortie est vide. Maintenant, démarrons un serveur web:

    sudo python3 -m http.server 500

maintenant, voici la sortie de lancer netstat à nouveau:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      - 

donc maintenant il y a un processus qui écoute activement (État: LISTEN) sur le port 500. L'adresse locale est 0.0.0.0, qui est le code pour "écoute pour tous". Une erreur facile à faire est d'écouter à l'adresse 127.0.0.1, qui n'accepte que les connexions de l'ordinateur courant. Ce n'est donc pas une connexion, cela signifie simplement qu'un processus demandé à bind() de porter IP, et que ce processus est responsable de gérer toutes les connexions à ce port. Ceci indique la limitation qu'il ne peut y avoir qu'un seul processus par écoute informatique sur un port (il y a des moyens de contourner cela en utilisant le multiplexage, mais c'est un sujet beaucoup plus compliqué). Si un serveur web écoute sur le port 80, il ne peut pas partager ce port avec d'autres serveurs web.

alors maintenant, connectons un utilisateur à notre machine:

    quicknet -m tcp -t localhost:500 -p Test payload.

c'est un script simple ( https://github.com/grokit/dcore/tree/master/apps/quicknet ) qui ouvre une socket TCP, envoie la charge utile ("Test payload."dans ce cas), attend quelques secondes et se déconnecte. Faire netstat à nouveau pendant que cela se produit affiche ce qui suit:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      -
    tcp        0      0 192.168.1.10:500        192.168.1.13:54240      ESTABLISHED -

si vous vous connectez avec un autre client et que vous refaites netstat, vous verrez ce qui suit:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      -
    tcp        0      0 192.168.1.10:500        192.168.1.13:26813      ESTABLISHED -

... qui est, le client a utilisé un autre port aléatoire pour la connexion. Si il n'y a jamais de confusion entre les adresses IP.

Normalement, pour chaque client de connexion le serveur bifurque un processus enfant qui communique avec le client (TCP). Le serveur parent confie à l'enfant le traitement d'une socket établie qui communique de nouveau avec le client.

lorsque vous envoyez les données à une socket à partir de votre serveur enfant, la pile TCP dans L'OS crée un paquet qui retourne au client et définit le "du port" à 80.

plusieurs clients peuvent se connecter au même port (disons 80) sur le serveur parce que du côté du serveur, après avoir créé une socket et binding (paramètre IP locale et port) listen est appelé sur la socket qui dit à L'OS d'accepter les connexions entrantes.

Lorsqu'un client essaie de se connecter au serveur sur le port 80, l'appel accepte est invoqué sur la socket du serveur. Ce crée une nouvelle socket pour le client qui essaie de se connecter et de la même manière de nouvelles sockets seront créés pour les clients suivants utilisant le même port 80.

les mots en italique sont des appels de système.

Ref

http://www.scs.stanford.edu/07wi-cs244b/refs/net2.pdf