Notion de port et de socket dans une connexion de transport

1 L’origine des sockets

La version BSD 4.1c d’Unix pour VAX, en 1982, a été la première à inclure TCP/IP dans le noyau du système d’exploitation et à proposer une interface de programmation de ces protocoles : les sockets.
Les sockets sont ce que l’on appelle une API (Application Program Interface'') c'est à dire une interface entre les programmes d'applications et la couche transport, par exemple TCP ou UDP. Néanmoins les sockets ne sont pas liées à TCP/IP et peuvent utiliser d'autres protocoles. _ Les sockets apparaissent entre la couche transport et la couche application du modèle OSI. Il faut noter que les constructeurs de stations de travail comme HP, SUN, IBM, SGI, ont adopté ces sockets, ainsi sont-elles devenues un standard de fait et une justification de leur étude. _ Pour conforter ce point de vue, il n'est pas sans intérêt d'ajouter que toutes les applications  majeures (named, dhcpd, sendmail, ftpd, serveurs httpd,...) de l'Internet, et dont l'utilisateur peut lire le code source, sont programmées avec de telles sockets. _ Les sockets Windows (Winsock) sont apparus plus tard en 1993. La première version des socket windows, la winsowk 1.1 autorisait  l'utilisation d'un seul protocole TCP/IP, contrairement à la version 2.0 qui propose en plus, la suite des protocoles ATM, IPX/SPX, DECnet et le sans fil. Le passage à Winsock 2.0 s'est fait en gardant 100% de compatibilité permettant aux applications déjà développées de continuer à fonctionner. _ {{{ 2 Présentation des sockets}}} Les créateurs des sockets ont essayé au maximum de conserver la sémantique des primitives systèmes d'entrées/sorties sur fichiers comme open, read, write, et close. Cependant, les mécanismes propres aux opérations sur les réseaux les ont conduits à développer des primitives complémentaires. _ Pour créer une socket, une application utilisera la primitive socket et non open, pour les raisons que nous allons examiner. En effet, il serait très agréable si cette interface avec le réseau conservait la sémantique des primitives de gestion du système de fichiers, malheureusement les entrées/sorties sur réseau mettent en jeux plus de mécanismes que les entrées/sorties sur un système de fichiers. _ Par exemple, il faut considérer les points suivants : Dans une relation du type client-serveur les relations ne sont pas symétriques. Démarrer une telle relation suppose que le programme sait quel rôle il doit jouer. _ Une connexion réseau peut être du type connecté ou non. Dans le premier cas, une fois la connexion établie le processus émetteur discute uniquement avec le processus destinataire. Dans le cas d'un mode non connecté, un même processus peut envoyer plusieurs data-grammes à plusieurs autres processus sur des machines différentes. _ Une connexion est définie par un quintuplet défini par le protocole, l'IP Local, le Port local, l'IP distante et Port distant qui est beaucoup plus compliqué qu'un simple nom de fichier. _ Le terme socket désigne, d'une part un ensemble de primitives, on parle des sockets de Berkeley, et d'autre part l'extrémité d'un canal de communication (point de communication) par lequel un processus peut émettre ou recevoir des données. Ce point de communication est représenté par une variable entière, similaire à un descripteur de fichier. {{{ 3 La vie d'une socket:}}} _ {{ 3.1 Création d'une socket}} _ Pour créer une socket, il est nécessaire de spécifier la famille de protocole, ipv4, ipv6,X25,... Le type de communication principalement mode connecté et mode non connecté. Le protocole TCP, UDP,... La création d'une socket permet de connaître le `descripteur de la socket`. Cela nous donne le premier élément du quintuplet: Le protocole. {{ 3.2 Spécification d'une adresse}} _ Il faut remarquer qu'une socket est créée sans adresse de l'émetteur ni celle du destinataire. _ Pour les protocoles de l'Internet cela signifie que la création d'une socket est indépendante d'un numéro de port. _ Dans beaucoup d'applications, surtout des clients, on a pas besoin de s'inquiéter du numéro de port, le protocole sous-jacent s'occupe de choisir un numéro de port pour l'application. _ Cependant un serveur qui fonctionne suivant un numéro de portbien connu’’ doit être capable de spécifier un numéro de port bien précis.
Une fois que la socket est créée, la primitive bind permet d’effectuer ce travail, c’est à dire d’associer une adresse IP et un numéro de port à une socket
La primitive bind ne permet pas toutes les associations de numéros de port, par exemple si un numéro de port est déjà utilisé par un autre processus, ou si l’adresse Internet est invalide.
Cet appel système complète l’adresse locale et le numéro de port du quintuplet qui qualifie une connexion.on a la moitié d’une connexion, à savoir un protocole, un numéro de port et une adresse IP.

3.3 Connexion à une adresse distante
L’initiative de la demande de connexion est typiquement la préoccupation d’un processus client.
Quand une socket est créée, elle n’est pas associée avec une quelconque destination. C’est la primitive connect qui permet d’établir la connexion, si on choisit un mode de fonctionnement connecté, sinon elle n’est pas très utile.
Pour les protocoles orientés connexion, cet appel système rend la main au code utilisateur une fois que la liaison entre les deux systèmes est établie. Durant cette phase des messages sont échangés ; les deux systèmes échangent des informations sur les caractéristiques de la liaison future.
Dans le cas d’un client en mode non connecté un appel à connect n’est pas faux mais il ne sert à rien et redonne aussitôt la main au code utilisateur. Le seul intérêt que l’on peut voir est que l’adresse du destinataire est fixée et que l’on peut alors utiliser les primitives read, write, recv et send, traditionnellement réservées au mode connecté.
Le quintuplet est maintenant complet : protocole, port local, adresse locale, port éloigné, adresse éloignée. A partir de ce moment on peut utiliser la socket pour envoyer et recevoir des données.

3.4 Terminer une connexion
On ferme la Connexion uniquement en mode connecté. Avant de fermer la Connexion , le système s’assure que tous les octets en attente de transmission sont bien transmis dans de bonnes conditions. Lors d’un arrêt ’brutal’ de la Connexion , un reset est envoyer à l’hôte distant, ce qui provoque un arrêt brutale de la Connexion . Les octets éventuellement en attente sont perdus.

4 Le multiplexage dans une connexion de transport.

Lors d’une communication en réseau, les différents processus s’échangent des informations qui sont généralement destinées à plusieurs applications. Seulement ces informations transitent par la même passerelle. Il faut donc savoir pour quelle application telle information est destinée. On attribue donc des ports pour chaque application.
Un port est comme une porte en schématisant. Les informations sont multiplexées et passent par la passerelle. A leur arrivée ou à leur réception elles sont démultiplexées et chaque information distincte passe par le port qui lui est associé. Les informations sont ensuite traitées par l’application correspondante.
Un port est codé sur 16 bits, il y a donc 65536 ports.
Les 1024 premiers ports sont des ports bien connus (Well known ports), ces ports sont liés à des applications spécifiques.

Les ports référencés permettent ainsi à une application dite cliente, d’identifier une application sur le système distant. L’extrémité de la connexion cliente est identifié par un numéro de port attribué dynamiquement (>1024) par le processus appelant. Ce numéro de port est dit port dynamique ou éphémère.

5 Schéma d’une connexion