Comprendre les ports: comment plusieurs onglets de navigateur communiquent-ils en même temps? [fermé]

J'ai réalisé aujourd'hui que je ne comprends pas fondamentalement comment fonctionne la communication portuaire.

Si je lance une instance d'un serveur Web écoutant sur le port 80, il peut répondre à de nombreuses demandes provenant de nombreux onglets de navigateur différents, tous communiquant via le port 80.

Cependant, je ne peux pas démarrer deux instances du serveur, les deux écoutant sur le port 80, car cela entraîne un conflit de port.

J'ai toujours considéré cela comme une donnée, (un seul processus peut se lier à un port spécifique à un moment donné) sans jamais vraiment y réfléchir - n'y a-t-il pas plusieurs processus communiquant sur le port 80? (c'est-à-dire, chacun des onglets en cours d'exécution dans le navigateur?)

Fondamentalement, un seul processus peut ÉCOUTER sur un port à la fois (techniquement, un socket est dédié à l'écoute). Mais, un port peut gérer de nombreux sockets transférant des données, un socket est une combinaison d'IP / port local et d'adresse IP / port distant. De cette façon, une fois que le serveur accepte la connexion entrante pendant l'écoute, il ouvre un nouveau socket dédié à cette conversation et transfère le traitement à autre chose, puis revient à l'écoute.

Plus de détails ici .

Le navigateur se connecte depuis un port aléatoire élevé (c'est-à-dire> 1024) de votre ordinateur au port 80 d'un serveur distant. Il n'y a donc pas de conflit de port sur votre machine.

Si vous utilisez plusieurs onglets pour vous connecter au même serveur distant (ou si de nombreux utilisateurs se connectent au serveur), ils accèdent tous au même port et sont desservis par le même processus (c'est-à-dire le serveur Web du site).

Le serveur qui écoute sur le port 80 N'A PAS à gérer plusieurs processus. Les démons TCP simples des années plus âgées ne pouvaient gérer qu'une seule connexion à la fois. Vous pouvez émuler ce comportement en ayant un programme tel netcatqu'écouter sur un port spécifique et essayer d'y connecter deux machines. L'un entrera, l'autre rebondira sans connexion. Ces démons sont pour la plupart inutiles, vous ne les voyez donc plus.

Pour quelque chose comme un serveur Web, il écoute directement sur le port. La chose à garder à l'esprit est qu'elle se trouve au-dessus de la bibliothèque de sockets du système d'exploitation. Lorsqu'une nouvelle connexion est établie, la bibliothèque de sockets transmet le tout nouveau socket au logiciel du serveur Web. À ce stade, le logiciel du serveur Web a quelques options.

Une possibilité est qu'il passe l'objet socket à un nouveau thread dans le même processus. Chaque fois qu'une communication se produit sur ce socket, ce thread la gérera. Le processus parent assure la médiation des threads actifs à un moment donné, ce qui peut être beaucoup.

Une autre possibilité est qu'il entraîne un nouveau processus et passe l'objet socket au processus. Si je comprends bien, c'est maintenant au système de socket du système d'exploitation d'intervenir sur la communication entre ces processus enfants et leurs cibles. Le processus parent a toujours un certain contrôle sur les processus, tels que la suppression des processus bloqués et d'autres communications inter-processus.

Laquelle de ces approches est la plus efficace dépend du système d'exploitation. IIRC, Apache peut fonctionner dans les deux modes.

En substance, la bibliothèque de sockets fournit un niveau de traitement parallèle au serveur Web. Il peut gérer plusieurs connexions simultanées en transférant activement des données, tout en acceptant de nouvelles connexions.

Pour un navigateur qui peut lancer plusieurs tentatives de connexion à un serveur Web afin d'améliorer les temps de chargement, le parallélisme s'applique également du côté du navigateur, c'est une bonne et merveilleuse chose. Le navigateur garde une trace de l'état de la page pendant son chargement, et les multiples tentatives de connexion qu'il fait tourner font toutes partie du processus.

Il existe effectivement deux "types" de sockets de flux. L'un a une "autre extrémité" générique, l'autre a un hôte spécifique: un port pour l'autre extrémité.

Deux sockets ne peuvent (ou, plutôt, devraient jamais) avoir les mêmes identificateurs "this end" et "other end". Le socket "écouté" (acceptant les connexions entrantes) est celui qui a une "autre extrémité" générique, de sorte qu'une seule à la fois peut exister. À mesure que les connexions arrivent, une opération acceptest effectuée, renvoyant une socket avec un tuple host: port pour l'autre extrémité.

Votre question me rappelle moi-même il y a quelques années avant Cisco CCNA - avait les mêmes doutes :)

Tout d'abord, l'établissement de plusieurs connexions HTTP n'est pas nécessairement lié au nombre d'onglets ouverts dans votre navigateur. Lorsque vous visitez un site avec des annonces ou du code Google Analytics par exemple, vous vous connectez à plusieurs sites bien que vous ne soyez que dans un seul onglet.

Quoi qu'il en soit, lorsque votre navigateur communique avec le serveur Web, le port de destination du trafic envoyé au serveur Web est le port 80, tandis que le port source est un nombre aléatoire. Le port source est de faire savoir au serveur Web sur quel port il doit vous communiquer. Chaque connexion http établie aura son propre port ouvert sur votre ordinateur. Essayez d'exécuter netstat avec quelques sites Web ouverts et vous verrez immédiatement ce que je veux dire.

Vous pourriez rire, mais ce livre est un excellent moyen rapide de maîtriser les bases de TCP / IP. Cela m'a beaucoup aidé.