Les navigateurs Web utilisent-ils différents ports sortants pour différents onglets?

Dans un navigateur Web prenant en charge plusieurs onglets, tels que Firefox, différents onglets destinés à des domaines de site Web différents utilisent-ils un port dédié à chaque domaine?.

Ou le navigateur utilise-t-il un seul port pour gérer tous les onglets et donc tous les domaines?.

Les navigateurs utilisent-ils différents ports pour se connecter à différents sites Web?

Oui, ils le font.

Voici un exemple montrant mes connexions Firefox actuelles (j'ai 9 onglets ouverts) sur Windows 7:

Remarques:

• Vous pouvez voir que les ports locaux sont tous différents.

• Les ports distants sont généralement 80 (HTTP), 443 (HTTPS) ou 8080 (HTTP alternatif).

  • De nombreux autres ports sont utilisés pour héberger des serveurs Web. Recherchez HTTPsur Liste des numéros de ports TCP et UDP pour certains d’entre eux.

• Le processus complet de rendu d'une page Web est décrit ci-dessous. Voir en particulier les étapes 5, 6, 13 et 15 (en gras):

  • En règle générale, le rendu d'une seule page Web utilise plusieurs connexions, qui ne seront pas toutes à la même adresse distante.

  • En effet, les pages Web incluent souvent des ressources hébergées ailleurs (fichiers javascript, etc.).

• Plusieurs connexions au même site Web (par exemple, stackoverflow.com) ont également des ports locaux différents (parce que ce sont des connexions distinctes dans différents onglets rendant différentes pages).

Rendu d'une page Web - étape par étape

Remarque:

• Les étapes 5, 6, 13 et 15 (en gras) sont directement pertinentes pour la question.

Avez-vous déjà pensé à ce qui se passe lorsque vous surfez sur le Web? Ce n'est pas aussi simple qu'il y paraît:

1. Vous tapez une URL dans la barre d'adresse de votre navigateur préféré.
2. Le navigateur analyse l'URL pour trouver le protocole, l'hôte, le port et le chemin.
3. Il forme une requête HTTP (qui était probablement le protocole)
4. Pour atteindre l'hôte, il doit d'abord traduire l'hôte lisible en un numéro IP. Pour ce faire, il effectue une recherche DNS sur l'hôte.
5. Ensuite, un socket doit être ouvert depuis l'ordinateur de l'utilisateur vers ce numéro IP, sur le port spécifié (le plus souvent, le port 80).
6. Lorsqu'une connexion est ouverte, la requête HTTP est envoyée à l'hôte.
7. L'hôte transmet la demande au logiciel serveur (le plus souvent Apache) configuré pour écouter sur le port spécifié.
8. Le serveur inspecte la requête (le plus souvent, seul le chemin) et lance le plug-in du serveur requis pour gérer la requête (correspondant au langage serveur utilisé, PHP, Java, .NET, Python?)
9. Le plugin a accès à la requête complète et commence à préparer une réponse HTTP.
10. Pour construire la réponse, une base de données est (probablement) consultée. Une recherche dans la base de données est effectuée en fonction de paramètres dans le chemin (ou les données) de la demande.
11. Les données de la base de données, ainsi que d'autres informations que le plug-in décide d'ajouter, sont combinées dans une longue chaîne de texte (probablement HTML).
12. Le plugin combine ces données avec des métadonnées (sous la forme d'en-têtes HTTP) et renvoie la réponse HTTP au navigateur.
13. Le navigateur reçoit la réponse et analyse le code HTML (qui, avec une probabilité de 95%, est cassé) dans la réponse
14. Un arbre DOM est construit à partir du HTML cassé
15. De nouvelles demandes sont adressées au serveur pour chaque nouvelle ressource trouvée dans la source HTML (généralement des images, des feuilles de style et des fichiers JavaScript). Retournez à l'étape 3 et répétez l'opération pour chaque ressource.
16. Les feuilles de style sont analysées et les informations de rendu de chacune d'elles sont attachées au noeud correspondant dans l'arborescence DOM.
17. Javascript est analysé et exécuté, les nœuds DOM sont déplacés et les informations de style sont mises à jour en conséquence
18. Le navigateur affiche la page à l'écran en fonction de l'arborescence DOM et des informations de style pour chaque nœud.
19. Vous voyez la page à l'écran
20. Vous êtes énervé, tout le processus était trop lent.

Source de rendu d' une page Web - étape par étape

Chaque connexion à un site Web utilise un socket différent avec le port TCP de destination par défaut 80 pour HTTP simple et 443 pour HTTPS. Pour que le socket soit unique, la combinaison de l'adresse IP source, du port TCP source, de l'adresse IP de destination et du port TCP de destination doit être différente.

Si vous avez plusieurs connexions au même site Web (en supposant que celui-ci utilise une seule adresse IP) à partir du même ordinateur, vous devez utiliser un port TCP source différent. De cette façon, chaque connexion est unique.

Toutefois, il convient de noter que depuis HTTP 1.1, toutes les connexions sont persistantes pendant une période donnée (sauf indication contraire). Cela signifie que la même connexion peut être réutilisée par votre navigateur si plusieurs ressources du même site Web sont demandées (par exemple, fichiers css / js). Cela s'applique également si vous avez plusieurs instances du même site Web dans votre navigateur.

Si vous êtes sous Windows, la netstat -no -p TCPcommande vous montrera tous les sockets TCP actifs et leurs ID de processus correspondants, y compris ceux de votre navigateur:

Si vous êtes sous Unix / Linux (Debian dans ce cas), vous pouvez utiliser la commande netstat -ntpou ss -t:

En ce qui concerne les onglets vers différents sites Web, rien dans TCP ne requiert que le port local soit différent, tant que le tuple {IP local, port local, IP cible, port cible} est unique. Pour les onglets du même site Web, la situation est beaucoup plus complexe.

Le navigateur, comme tout autre logiciel client, utilise un port local différent pour chaque connexion sortante vers la même cible. En général, il formera plusieurs connexions à un site Web donné, pour récupérer des ressources incorporées telles que des images, CSS, JavaScript, etc. Il regroupera également ces connexions en vue d'une éventuelle réutilisation.

Il n'est pas possible d'indiquer si différents onglets d'un même site Web utiliseront des connexions distinctes , car (a) il n'y a généralement pas de connexion unique par onglet, et (b) en fonction du moment et de l'authentification, les connexions peuvent être réutilisé entre les onglets; et comme il n'est pas possible d'identifier les connexions, il n'est donc pas possible d'identifier les ports locaux non plus.

Oui. Non peut-être. Ça dépend.

Tout d'abord, un navigateur peut utiliser l'une des stratégies suivantes pour les connexions:

1. Connexion unique (peu probable pour un navigateur plus récent que 1995)
2. Une connexion par onglet (essentiellement identique au n ° 1, mais très légèrement meilleur)
3. Une connexion par ressource (naïf, mais ne fonctionne pas si mal)
4. Pool de connexions avec connexions persistantes, réutilisant des connexions
5. Quelque chose de différent (lu comme: des trucs bizarres)

Vous n'avez pas le moyen de savoir quelle stratégie un navigateur utilisera, bien que l'utilisation d'un pool de connexions (et la réutilisation de connexions) constitue une hypothèse raisonnable.

Deuxièmement, TCP fonctionne avec un port source et un port de destination pour chaque connexion. La paire adresse / port source et destination définit la connexion.
Vous utilisez toujours ^[1] un port connu (tel que 80 ou 443) pour vous connecter au serveur (auquel il écoute sur son adresse publiée), mais l’autre port est choisi au hasard. Ainsi, en fonction de quel côté vous regardez une connexion, celle-ci a un ou plusieurs ports possibles.

Ainsi, un même onglet peut (et utilisera généralement) plusieurs ports différents à sa fin, mais en principe, différents onglets peuvent (si les connexions sont regroupées et que des ressources différentes dans différents onglets sont chargées à partir du même serveur) utiliser le même port.

Étant donné que la question mentionne explicitement sortant , dans le cas "normal", les numéros de port seraient les mêmes, quel que soit l'onglet dans lequel ils se trouvent, ou l'un des deux ports possibles (80 et 443). Bien sûr, il est possible de demander explicitement un autre port (comme 8080) dans une URL. C'est un peu rare, cependant.