Pourquoi uniquement le port 80 pour les services Web?

Pourquoi n'est-il pas judicieux de dédier plus d'un port TCP / IP à http? Bien que certes naïf, n’est-il pas intuitif de penser que les performances du serveur pourraient être augmentées?

Le port 80 est un port bien connu , ce qui signifie qu'il est connu comme étant l'emplacement où vous trouverez normalement les serveurs HTTP. Vous pouvez le trouver dans la RFC HTTP / 1.1 .

Avoir une valeur par défaut est utile précisément parce que vous n'avez pas besoin de la saisir dans votre navigateur Web avec l'URI. Si vous exécutez un serveur HTTP (ou tout service) sur un port non standard, vous forcez le client à se souvenir du nombre arbitraire de 16 bits que vous avez choisi et à le saisir.

Outre ces inconvénients, il n’ya aucun avantage en termes de performances: un port n’est qu’une partie du (dst ip:port, src ip:port)tuple à quatre qui identifie de manière unique une connexion TCP. Si deux connexions partagent un dst ip:port, cela ne signifie pas qu'elles partagent une ressource système, elles peuvent résider dans différents threads ou processus.

Maintenant, si vous avez des services logiquement différents qui sont tous deux Happen utiliser HTTP, il n'y a pas problème avec eux en cours d' exécution sur des ports différents. Cela rend l'URI un peu plus laid.

Le serveur ne gaspille pas de ressources en gérant les connexions dans un ou plusieurs ports. Les ressources du serveur sont allouées pour gérer les connexions et le numéro de port est simplement un moyen de connecter un programme spécifique à une connexion spécifique.

Par exemple: le serveur HTTP sait qu'il écoutera les connexions entrant dans le port 80. Et le serveur sait que, chaque fois qu'il reçoit une requête sur le port 80, il le traite sur le serveur http. Après cela, le serveur http gérera la communication, puis consommera des ressources.

Vous semblez penser aux ports comme à quelque chose de réel; c'est juste un nombre non signé de 16 bits (0-65535) qui est une étiquette dans l'en-tête d'un paquet IP. Cela facilite le multiplexage au niveau de l'application. Lorsqu'un paquet entrant arrive sur une carte réseau, le système d'exploitation reçoit une notification. Il vérifie le port vers lequel le paquet entrant a été dirigé, puis le transmet uniquement à la bonne application. Si vous exécutez votre serveur Web (nginx) pour écouter sur le port 80, seul nginx reçoit les paquets envoyés au port 80.

Lorsqu'un client (IP: 100.200.100.200) adresse une requête HTTP au serveur (55.55.55.55), il adresse cette demande au port de destination 80 du serveur (55.55.55.55:80), mais le port source est choisi de manière aléatoire par le serveur de destination. Système d'exploitation pour le navigateur Web (quelque chose comme 45490). La réponse HTTP du serveur Web provient alors de (55.55.55.55:80), mais envoyée à la destination (votre IP) (100.200.100.200:45490). Le système d'exploitation de votre ordinateur sait que les paquets entrants sur le port 45490 (à partir de 55.55.55.55:80) doivent être transmis au navigateur Web qui a effectué la demande. Comme chaque connexion unique à un site Web du client obtient un port aléatoire unique, plusieurs navigateurs Web peuvent ainsi se connecter au même site Web. Lorsqu'une page est rechargée dans un navigateur, les autres fenêtres ne sont pas affectées.

Chaque paquet IP a à la fois les adresses IP source et de destination et le port disponible dans l'en-tête. Le système d'exploitation et l'application (navigateur Web ou serveur Web) peuvent utiliser les deux pour déterminer l'action appropriée sur la manière de traiter le paquet.

Les ports 80 et 443 sont les ports "par défaut" pour HTTP / HTTPS

Cela signifie que vous ne devez pas spécifier le port ( http://www.example.com:80 , https://www.example.com:443 ) lorsque vous utilisez un navigateur Web.

Si vous souhaitez qu'un serveur Web écoute sur d'autres ports, les utilisateurs doivent ajouter manuellement le port à l'URL, ou il doit être codé dans un lien vers ce port particulier.

De plus, la plupart des proxies et des pare-feu ne permettent pas les connexions à ces ports à moins d'être spécifiquement configurés à cet effet (sans configuration, les proxys sortants n'écoutent pas les ports autres que ceux par défaut et ne transmettent donc pas la requête aux serveurs Web, tandis que les pare-feu bloquer les tentatives de connexion non-TCP80 / 443)

Tout cela limite ce qui peut être fait au niveau TCP / IP

Un moyen d'améliorer les performances consiste à disposer d'un périphérique / service d'équilibrage de charge écoutant TCP80 / 443, qui redirige ensuite la demande vers des serveurs situés sur différents ports et / ou ip (équilibrage local) ou même sur différents sites distants (équilibrage global). Mais ceci est tout à fait un autre sujet

Ajouter des ports supplémentaires n’ajoute pas de bande passante supplémentaire, un port est plus une étiquette qu’un tuyau , il peut "grossir" aussi largement que vous le souhaitez sans ralentir car le tuyau est plein.

Si un serveur reçoit trop de demandes, il ralentira bien sûr. Cependant, ce type de problème ne peut pas être résolu en ajoutant un autre numéro de port.

Si vous utilisez des ports aléatoires, l'utilisateur devra ajouter les numéros de port corrects chaque fois qu'il se rend sur votre site. c'est-à-dire www.example.com:80; www.example.com:81; www.example.com:82 etc

Utiliser plus de ports n'augmenterait pas les performances. Les ports source pour chaque connexion sont des ports éphémères et si différents de toute façon

Chaque connexion TCP / IP a un sourceIP: sourcePort et un destinationIP: destinationPort.

Lorsque vous établissez une connexion, vous utiliserez toujours 80 comme port de destination (ce qui est logique, car le serveur doit uniquement écouter le port 80 sur HTTP et non plusieurs ports). L'astuce est que sourcePort est dynamique pour chaque connexion.

Exemple:

utilisateur1: 1.1.1.1:29999 à 2.2.2.2:80

utilisateur2: 1.1.1.2:45333 à 2.2.2.2:80

Ne confondez pas un port différent avec une autre connexion physique ou avec une bande passante réseau supérieure ou des performances de traitement du serveur supérieures. Ce que le serveur obtient sont des paquets TCP ou UDP, qui ont un numéro de port dans l’adresse. Ils utilisent toujours les mêmes câbles, utilisent le même matériel et le même pilote d’interface réseau, etc.

Si vous deviez envoyer deux paquets à un serveur, en termes de ressources, le serveur dépense pour traiter ces deux paquets, peu importe si l'un des deux a des numéros de port différents ou les mêmes numéros de port qui leur sont associés, la gestion interne être proche de l'identique.

Par conséquent, ce n'est pas une méthode pour augmenter les performances de quelque manière que ce soit.

La seule exception à cette règle est si vous associez deux démons différents (ou deux copies identiques) exécutés en même temps sur les deux numéros de port différents et si chacun de ces démons augmentait extrêmement mal avec load. Ce qui n'est généralement pas le cas.

Comme Remi l'a mentionné, les ports 80 et 443 sont les ports "par défaut" pour HTTP / HTTPS.

La plupart des réseaux et des pare-feu ne bloquent pas le trafic passant par ces ports. Il est donc plus facile d’utiliser ces ports car la plupart du temps, vous n’aurez peut-être pas à vous soucier du blocage de votre service par les pare-feu, sinon vous devrez peut-être reconfigurer les règles du pare-feu et obtenir les approbations de conformité / sécurité.

Comme tout le monde l'a dit, il est en principe inutile d'héberger un serveur Web sur un port autre que le port 80 ... sauf si vous l'hébergez chez vous. De nombreux fournisseurs d'accès Internet étranglent les ports TCP / UDP sortants 80 et 443 ( IANA étant définis comme HTTP et HTTPS , respectivement). Dans ce cas, l'utilisation de ces ports réduira la vitesse de chargement du site, etc. Cependant, l' IANA a affecté 3 ports HTTP-ALT à à la fois TCP et UDP. Ce sont les suivants: 591, 8008 et 8080. L’utilisation de ces ports est également acceptable, mais vous allez rendre la vie des administrateurs de serveur infernale.

Source des numéros de port: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml