Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 999-archives:tcp-ip:010tcpip:030_les_sockets [le 30/05/2025 à 13:47] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 999-archives:tcp-ip:010tcpip:030_les_sockets [le 30/05/2025 à 13:47] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. prof
@@ Ligne 1: / Ligne 1: @@
+====== Les sockets ======
+===== Une oreille dans chaque port =====
+==== Adresse, port et socket ====
+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:
+  * un serveur web (HTTP);
+  * un serveur de fichiers (FTP);
+  * un serveur de messagerie (SMTP et IMAP);
+  * un serveur SSH pour l'administration à distance.
+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 IMAP 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.
+==== Le serveur et le client ====
+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).
+{{ :tcpip:sock1.gif |Client / serveur}}
+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.
+{{ :tcpip:sock2.gif |Port de réponse}}
+==== Un port d'écoute est une porte ouverte ====
+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.
+===== Quelques infos supplémentaires =====
+==== NAT, PAT et autres mascarades ====
+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.
+  * NAT (Network Address Translation) est une faculté dont dispose un routeur, de modifier les adresses IP des émetteurs lors du passage des datagrammes entre deux réseaux. Ca ne nous intéresse pas directement ici.
+  * PAT (Port Access Translation) est une fonction qui permet de changer au passage le numéro de port dans le datagramme. Ca peut paraître tordu, mais il existe une foule d'applications possibles pour cette propriété.
+  * MASQUERADE, qui est un mélange des deux (NAT, PAT) est une fonction très intéressante pour connecter tout un réseau local construit sur une classe IP privée à l'Internet. La passerelle utilisera son IP publique (côté Internet) pour faire du NAT sur les adresses privées du réseau local et fera également du PAT pour savoir à qui il faudra transmettre les réponses.
+    * Le principe de fonctionnement et la façon de construire une telle passerelle sont décrits dans la chapitre MASQUERADE, ailleurs sur ce site.
+==== La liste des ports réservés ====
+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 [[999-archives:tcp-ip:010tcpip:999_well_known_ports|ici]].\\