Pourquoi uniquement le port 80 pour les services Web?
54
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?
Vous avez tout à fait raison. J'ai changé le port par défaut de mon serveur Web de 80 à 90,91,92 & 93. La charge sur le serveur a considérablement diminué.
David Houde
17
... peut-être parce qu'aucun client ne peut plus trouver le serveur?
Marcos Gonzalez
5
80 est simplement le port utilisé pour http. Lorsque vous dites "quelque chose.com"; (ou même "quelque chose.com") le navigateur termine comme une demande à "quelque chose.com:80"; (sur le port 80, car c'est le port http bien connu par défaut). Idem pour https sur 443. Si vous décidez de le changer, vous devrez le dire dans l'URL: "myserver.com:1280"; sinon, le navigateur essaiera sur le port 80 et ne le trouvera pas. Une liste peut être vue sur wikipedia
Olivier Dulac Le
6
Désolé Marcos, c'était une mauvaise tentative d'humour. Je n'ai jamais été bon en la matière.
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.
C'est ça! Le port 80 n'est pas une ressource! C'est juste une partie d'un tuple! Merci de l'avoir dit si clairement.
Marcos Gonzalez
2
Cela vaut également la peine de noter que même pour différents services, la connexion HTTP réelle est généralement reçue sur le port 80 par un pilote système qui effectue une analyse initiale du protocole puis le transmet au bon service, permettant ainsi à des services totalement différents dans différents processus partager le même port.
Monstieur
1
Réponse utilisateur d'Useless
Deckard
26
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.
J'ajouterais à cette réponse que le port 80 n'est pas consommé par un utilisateur qui lui envoie sa demande. C'est pourquoi l'utilisation du port 80 (ou de tout port bien connu pour le protocole entrant que vous regardez) ne constitue pas un goulot d'étranglement pour l'évolutivité.
Craig Sirkin
1
C'est exactement ce que je n'ai pas bien compris. Même 100 000 utilisateurs se connectant simultanément à www.example.com:80 ne consomment pas le port 80. Merci pour cette clarification. Je trouve les informations @Useless ci-dessous également très éclairantes.
Marcos Gonzalez
Certains logiciels de serveurs Web ont des limites par instance et / ou processus. Parfois, il peut être judicieux d’exécuter plusieurs instances, mais cela nécessite un autre port d’écoute sur le même ordinateur, le premier (TCP80 / 443) étant le transfert des connexions vers la première instance.
Rémi Letourneau
22
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.
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
Merci de m'avoir présenté le concept d '"équilibrage de charge".
Marcos Gonzalez
1
Si vous souhaitez avoir un "pseudo" travail pratique et des idées sur certains concepts d'équilibrage de charge, F5 a quelques formations en ligne gratuites à university.f5.com L'inscription est gratuite et vous donne accès à LTM (Local Traffic Manager - leur équilibreur local ) formation, où vous pouvez voir à quoi ça ressemble et apprendre quelques concepts d’équilibrage de charge (ex: IP réel, IP virtuel, Pools, bilan de santé, etc.)
Remi Letourneau
Beau conseil!
Marcos Gonzalez
9
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.
s / label alors / label que / - je modifierais, mais il semble qu'un seul caractère ne soit pas acceptable.
Paul Gear
7
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.
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é.
Amen, les sites Web utilisant des ports non standard sont le fléau de l'existence de tout administrateur de sécurité. Un utilisateur de votre système doit utiliser un site Web avec un changement de port, un changement de proxy, un changement de
micrologiciel
0
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.
Réponses:
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 undst 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.
la source
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.
la source
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.
la source
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
la source
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.
la source
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
la source
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
la source
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.
la source
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é.
la source
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
la source