Imaginons la situation suivante (fréquente sur des petits réseaux):
Un seul « serveur » (entendez par là une machine) héberge plusieurs services bien connus des internautes:
Tous ces services cohabitent donc sur un hôte disposant d'une seule adresse IP, disons 62.161.120.45 (pour fixer les idées) et fonctionnent sans problèmes. Vous êtes-vous posé la question de savoir par quel prodige tout ne se mélange pas? Comment se fait-il que le navigateur du client qui invoque l'URL http://62.161.120.45/default.html
voit bien arriver la page demandée, alors que le client qui se connecte sur le serveur POP 62.161.120.45 va pouvoir y récupérer son courrier?
Plus fort encore, pendant qu'un client consulte la page http://62.161.120.45/default.html
, un autre consulte http://62.161.120.45/sommaire.html
. Et chaque client reçoit bien la page qu'il demande…
Grâce aux ports! Les ports sont des numéros d'identification qui permettent de spécifier le service concerné. Ce numéro de port est écrit sur 2 octets, ce qui donne 65535 ports possibles (parce que le port 0 n'est, à ma connaissance, pas utilisé).
La combinaison « adresse IP:numéro de port » constitue ce que l'on appelle une « socket » (qui veut dire à peu près « connecteur » en anglais).
Une socket identifie pleinement le service qui est concerné sur une machine donnée.
Les serveurs ont une fonction particulière: Ils doivent envoyer des informations pertinentes aux clients qui en réclament. Comme un serveur ne convient pas d'un rendez-vous avec le client, il doit rester attentif en permanence pour ne pas risquer de rater une question. Pour ce faire, on y installe des « daemons“, petits programmes qui tournent en tâche de fond et qui écoutent continuellement sur un numéro de port donné. Il y a des conventions pour attribuer ces ports sur des services connus, par exemple le port 80 pour HTTP, le port 110 pour POP3, le port 21 pour FTP. Il faut qu'il y ait des conventions de ce genre pour que les clients puissent atteindre ces services.
Lorsque l'on écrit http://62.161.120.45
, on ne spécifie pas de port; sous-entendu, il s'agit du port 80 parce que l'on invoque un service HTTP. Il serait possible d'écrire: http://62.161.120.45:80
Ici, on spécifie le port. Certaines protections triviales consistent justement à forcer un service à ne pas employer le port standard. Un administrateur pourrait décider de mettre son serveur HTTP à l'écoute du port 88. Dans ce cas, si l'utilisateur n'est pas au courant de cette particularité, il ne pourra pas accéder à ce serveur (sauf s'il dispose d'un scanner de ports et qu'il découvre la supercherie).
En revanche, le client qui émet la requête ne dispose pas de port d'écoute attitré. Ce n'est pas un serveur, c'est un client; il n'a donc rien à écouter d'autre que les réponses à ses questions. Il faut donc, lorsqu'il envoie sa requête, qu'il spécifie sur quel port il va écouter la réponse, de manière à ce que le serveur puisse construire un socket efficace pour ladite réponse.
Vous êtes-vous demandé par quel miracle, si vous ouvrez deux fois votre navigateur pour afficher deux pages différentes sur le même serveur, les informations ne se mélangent pas?
C'est parce que les deux sessions du navigateur indiquent des ports de réponse différents! C'est le NOS du client qui choisit les ports de réponse en fonction de ceux qui sont disponibles sur la machine.
Lorsqu'un port est ouvert à l'écoute sur un service serveur, c'est une porte ouverte par laquelle un intrus peut entrer.
Ce détail nous mène directement aux problèmes de sécurité et d'intrusions. Mais ne mélangeons pas tout, cette affaire est traitée ailleurs sur ce site.
Nous y reviendrons plus loin dans le chapitre consacré au routage, mais tant qu'on est dans les ports, autant dire quelques mots de ces techniques.
Le mieux est de consulter la RFC 1700 qui définit les ports d'écoute standards:
(Pour mémoire, un site de référence pour ce genre d'informations: http://www.iana.org/ )
Ceux qui désirent consulter la liste exhaustive des « ports bien connus », peuvent le faire ici.