TCP/IP

 

 

 

Le protocole TCP/IP est sans doute le protocole le plus utilisé dans la communication réseau aujourd'hui. C'est pour cette raison qu'il est largement étudié ; il constitue par ailleurs un bon exemple de protocole réseau complet, et il est à ce titre représentatif.

 

 

Principes généraux

 

Il est composé de deux protocoles : TCP et IP.

 

TCP/IP repose en partie sur le modèle OSI. Certaines couches sont cependant agglomérées dans une fonction globale. Mais la logique qui préside au modèle OSI s'applique à TCP/IP, et on ne peut pas oublier le modèle OSI pour s'intéresser à TCP/IP qui serait conçu comme un autre modèle indépendant.

 

Pour comprendre les bases de TCP/IP, prenons l’exemple de deux ordinateurs, ceux de Paul et de Jessie. Paul utilise un programme qui envoie des messages sur l'écran de celui de Jessie toutes les dix secondes. Il utilise un autre programme qui permet de valider un transfert de fonds entre son ordinateur et celui de Jessie. Enfin, il consulte à l'aide d'un navigateur un serveur Web présent sur l'ordinateur de Jessie.

           

La première application ne demande pas d’accusé réception. En effet, quoi qu'il arrive, un message sera envoyé toutes les dix secondes. Si un message n'est pas reçu, on se contentera de celui d'après. Les concepteurs n'ont donc pas jugé utile de demander à accusé réception.

 

En revanche, l'opération de transferts de fonds demande un processus d'acquittement des données.

 

Le premier programme utilisera donc le protocole UDP, le second le protocole TCP.

 

Dans l'établissement de la communication entre l'ordinateur de Paul et celui de Jessie, qu'on utilise le protocole UDP ou le protocole TCP, certains processus sont communs.

 

En effet, Paul connaît son propre nom, son adresse IP et son adresse Mac, car ces éléments sont configurés au niveau de sa machine. Il connaît aussi le nom d'hôte de la machine de Jessie, mais ni son adresse IP ni son adresse Mac.

 

Pour trouver ces deux informations, Paul utilise le service DNS et le protocole ARP. L'adresse IP du serveur DNS et connu. Paul l'interroge donc, et le serveur donne comme adresse IP de Jessie le 10.1.1.2. Paul doit encore savoir quelle adresse Mac correspond cette adresse IP. Il émet donc une requête broadcast ARP contenant l’adresse IP de Jessie. Cette requête prend la forme d'une question du type « quelle adresse Mac a pour adresse IP 10.1. 1.2 ? » Seule la machine de Jessie répond, avec une trame du type « 10.1.1.2 correspond à l’adresse Mac 0200.2222.2222 ».

 

Avec cette information, Paul envoie une trame à destination de l'adresse Mac de Jessie qu'il connaît désormais, et qui contient les informations que Paul veut transmettre à Jessie.

 

Cependant, on a dit que Paul utilisait trois applications en liaison avec l'ordinateur de Jessie. Mais comment les machines peuvent-elles savoir quelle application est concernée par quelle trame ?

 

Les concepteurs de TCP et UDP ont prévu à cet usage d'ajouter dans l’en-tête un numéro de port. Ce numéro identifie quel est l'application concernée par les informations contenues dans la trame. Cette utilisation possible de plusieurs applications en même temps s'appellent le multiplexage.

 

 

 

Le protocole TCP :

 

 

Examinons à présent le protocole TCP un peu plus en détail.

 

Ce protocole (Transmission Control Protocol) fournit cinq fonctions principales qui font son succès :

·        le multiplexage ;

·        la correction d'erreurs ;

·        le contrôle de flux par fenêtrage ;

·        l'établissement et la libération d'une connexion ;

·        le transfert des données.

 

TCP s'appuie sur le protocole IP pour la livraison des données et le routage.

 

 

Multiplexage :

 

Comme on l'a vu plus haut, le multiplexage désigne le processus par lequel on ajoute à l'en-tête un numéro de port qui va déterminer quelle application sera concernée par les données.

 

Le multiplexage s'appuie sur le concept de socket. Un socket est composé de trois éléments : une adresse IP, un protocole, et un numéro de port. Dans notre cas, le socket de l'application Web serait : 10.1.1.2, TCP, port 80.

 

Les 1024 premiers numéros de port sont réservés pour des services connus, et sont donc en général utilisé sur des serveurs. Lors de l'établissement d'une connexion, une machine clientes ouvre un port choisi aléatoirement au-dessus de 1024, et appelle un port du serveur qui correspond au service qui est demandé.

 

Notez qu'une machine qui utilise un service précis emploie le même port en entrée et en sortie. Ainsi, si l'ordinateur de Paul ouvre son port 1030, il appellera le port 80 de Jessie pour le service Web, et l'ordinateur de Jessie répondra depuis son port 80 vers le port 1030 de Paul.

 

 

Correction d'erreurs :

 

Pour assurer la fiabilité de la connexion, TCP utilise la numérotation des octets de données. L'en-tête contient des champs de séquence et d'acquittement.

 

Par exemple, dans la lecture d'un serveur Web, avec des segments de 1000 octets chacun, le serveur enverrait un premier paquet avec un champ séquence à 1000, un deuxième paquet avec un champ séquence à 2000, un troisième paquet avec un champ séquence à 3000, et le client enverrait un paquet d'accusé réception avec un champ d'acquittement à 4000.

 

Notez que le champ d'acquittement correspond au paquet que la machine cliente s'attend à recevoir à l'envoi suivant. On appelle ce principe un acquittement avec anticipation.

 

Imaginons dans ce même exemple qu'un paquet soit perdu. Le serveur Web enverrait un premier paquet avec un champ séquence à 1000, qui serait bien reçu. Puis un second paquet avec un champ séquence à 2000, qui lui serait perdu. Puis un troisième paquet, avec un champ séquence à 3000, qui lui serait reçu. Le client enverrait un paquet avec un champ d'acquittement à 2000 (puisqu'après le premier paquet, il envoie l'acquittement correspondant au paquet qu'il s'attend à recevoir). Le serveur enverrait alors un paquet avec un champ d'acquittement à 2000, puis attendrait l'accusé de réception du client. Le client enverrait alors un paquet avec un champ d'acquittement à 4000, et la communication continuerait.

 

Lorsque des paquets sont reçus dans le désordre, TCP sait les réordonnancer en fonction de leur numéro de séquence.

 

 

Contrôle de flux par fenêtrage :

 

Comme vous l'avez compris à la lecture du paragraphe précédent, le client n’envoie pas un accusé réception après chaque paquet. C'est le principe du contrôle par fenêtrage.

 

Le serveur envoie plusieurs paquets, dont le nombre est défini, avant de recevoir un accusé réception. Le nombre de paquets que l'on peut envoyer avant de recevoir un accusé réception est appelée la fenêtre.

 

Dans le cas de TCP, la fenêtre est dite coulissante. En effet, une machine serveur envoie des paquets jusqu'à recevoir une erreur. Elle en déduit donc que la taille de la fenêtre idéale sera de « le nombre de paquets envoyés moins un ». En fonction de la qualité de la communication, la taille de fenêtre sera donc variable. Ce processus est adaptatif : Si en cours d'émission l'émetteur reçoit un acquittement, il utilise comme départ d'une nouvelle fenêtre. Lorsqu'il a envoyé le nombre de paquets correspondant à la fenêtre, il attend l'acquittement.

 

 

Établissement et libération des connexions :

 

L'établissement d'une connexion sous TCP se fait sous la forme d'une poignée de main en trois temps. Cette poignée de main utilise les drapeaux SYN et ACK.

 

Le client envoie un premier paquet avec un drapeau SYN, qui représente une demande de connexion (de synchronisation entre les machines). Le serveur renvoie un paquet avec un drapeau SYN et ACK, accusant réception de la demande de synchronisation (et donnant son aval à sa demande). Le client envoie enfin un paquet avec un drapeau ACK, accusant réception de l'accord du serveur. La communication est alors établie, et l’échange de données commence.

 

Il ne faut pas confondre les drapeaux SYN et ACK et le symbole d'acquittement. Par exemple, une communication pourrait s'établir la façon suivante :

Client vers serveur : SEQ = 200, SYN, DPORT=80, SPORT=1027 (demande de connexion).

Serveur au client : SEQ=1450, ACK=201, SYN, ACK, DPORT=1027, SPORT=80 (validation de la demande de connexion).

Client au serveur : SEQ=201,ACK=1451, ACK, DPORT=80, SPORT=1027.

 

Notez que le champ séquence du premier paquet n'a pas beaucoup de signification ici. Notez aussi que l'on considère dans cet exemple que les segments ont une taille d'un octet.

 

La terminaison d'une connexion procède du même principe. La différence vient de l'utilisation du drapeau FIN :

Client au serveur : ACK, FIN, SEQ=1000

Serveur au client : ACK, ACK=1001

Serveur au client : ACK, FIN ACK=1001, SEQ=1470

Client au serveur : ACK, ACK=1471. Fin de la communication.

 

 

Le protocole UDP

 

 

Contrairement à TCP, le protocole UDP (User Datagram Protocol) fonctionne en mode non connecté. Il n'assure donc pas de correction d'erreur, ce rôle est laissé à l'application (couche 7). Il n'assure pas non plus de fenêtrage, ni aucune fonction qui garantisse que les données arriveront à destination dans l'ordre dans lesquelles elles ont été émises.

 

Il assure cependant le multiplexage. Il utilise pour ce faire les numéros de port comme TCP. Le socket comprend alors l'adresse IP, UDP, le numéro de port. Une application pourrait utiliser un port défini, avec dans certains cas le protocole TCP et dans d'autres cas le protocole UDP. Ce n'est pas interdit, mais c'est rare.

 

Un exemple de requête qui utilise UDP est DNS. En effet, si le client n'obtient pas de réponse du serveur, il renouvelle sa demande. Un contrôle de flux ou un fenêtrage n'est donc pas nécessaire.

 

Le protocole UDP est donc moins fiable que TCP, mais il est plus rapide. Voici à titre de comparaison les en-têtes TCP et UDP, avec leur taille en octets :

 

TCP :

2

2

4

4

4 bits

6 bits

6 bits

2

2

2

3

1

Port source

Port destination

N° séquence

N° acquittement

Offset

Réservé

Indic.

Taille fenêtre

Somme contrôle

Urgent

Option

Remplissage

 

UPD

2

2

2

2

Port source

Port destination

Longueur

Somme de contrôle

 

 

 

 

Le protocole ARP

 

 

Ce protocole (Adress Resoluation Protocol) est utilisé sur un réseau LAN pour déterminer l'adresse Mac d'un équipement à partir de son adresse IP. On a vu plus haut les bases de fonctionnement de ce protocole.

 

Notez que seule la machine dont l'adresse IP correspond au Broadcast répond en mentionnant son adresse Mac.

 

Notez aussi que la machine qui utilise ce protocole constitue un cache qui contient une correspondance entre les adresses IP et l'adresse Mac du réseau qu'elle connaît. Lorsqu'une adresse n'est pas utilisée pendant un certain temps, elle est effacée du cache pour faire de la place. ARP est un protocole de couche 3, tandis que TCP et UDP sont des protocoles de couche 4.

 

Dans le modèle TCP/IP, au-dessus de la couche TCP et UDP se trouve la couche application, qui englobe les couches application, présentation et cessions du modèle OSI.

 

 

 

 

Le protocole ICMP

 

 

C'est un protocole essentiel qui est utilisé conjointement à TCP/IP. Le protocole ICMP (Internet Control Management Protocol) sert en fait à contrôler et à gérer le fonctionnement du protocole IP. Il faut donc le considérer comme faisant partie de TCP/IP. Il emploie des messages dont certains doivent être connus. Ils figurent dans le tableau ci-dessous :

 

Messages

Rôle

Destination unreachable

Destination inaccessible : signale à l'autre source un problème de livraison d'un paquet.

Time excedeed

Temps dépassé : le temps nécessaire à la livraison d'un paquet a été trop long. Le paquet est supprimé.

Source quench

Ralentissement de la source : l'émetteur envoie des messages plus vite que le destinataire ne peut les lire. Le destinataire demande un ralentissement de l'émission.

Redirect

Redirection : le routeur qui émet ce message connaît une route plus rapide que celle demandée par l'émetteur. Il signale à ce dernier la route plus rapide.

Echo

Réponse demandée : ce message est utilisé par la commande ping pour vérifier la connectivité.

 

 

ICMP comprend bien d'autres messages qui permettent de mesurer les temps d'aller-retour, de découvrir les adresses IP, de demander le masque de sous réseau, identifier des paramètres incorrects, etc. ce protocole est utilisé même sur les réseaux les plus petits.

 

Un paquet ICMP comporte l'adresse IP, le type de la trame, son code, une somme de contrôle, et des données dont la taille dépend du type et du code.

 

Quelques précisions sur les messages cités ci-dessus :

 

·        la requête et la demande d'écho ICMP permettent d'ajouter à la simple demande réponse des paramètres supplémentaires comme la taille maximale de la trame.

·        Le message ICMP de destination inaccessible comporte des codes qui permettent de préciser basiquement les raisons de cette inaccessibilité. Cela peut être réseau inaccessible (réponse du routeur), hôte inaccessible sur le réseau, fragmentation impossible (la fragmentation a été interdite mais est nécessaire), protocole inaccessible (le protocole demandé n'est pas disponible sur l’hôte de destination), ou port inaccessible (le paquet est arrivé à destination, mais le port demandé est fermé).

·        Le message ICMP de temps dépassé signale à l’hôte que le paquet qui a été envoyé a été supprimé, parce que sa durée de vie a été dépassée. C'est le fameux TTL qui figure dans l'en-tête  IP. Le T.T.L. est décrémenté de un à chaque passage d’un routeur. Quand il arrive à un, le routeur qui le reçoit l’efface et envoie un message ICMP de temps dépassé.

·        Le message ICMP de redirection est très important dans les réseaux routés. Par exemple, une machine utilise un routeur A comme passerelle par défaut. Elle envoie à ce routeur un paquet à destination d'un réseau 10.1.4.0. Ce réseau est relié à un routeur B, lui-même connecté sur le réseau de la machine. Le routeur A envoie le paquet au routeur B et un paquet ICMP de redirection à la machine pour qu’elle envoie ses paquets suivants au routeur B. la machine peut choisir d'ignorer ce paquet.

 

 

 

Adressage IP

 

 

Pour bien comprendre l'adressage IP, il faut comprendre que les adresses Mac qui figurent sur les cartes réseaux ne suffisent pas à constituer une base cohérente pour organiser les machines du réseau entre elles. En effet, on sait qu'une adresse Mac est unique. Elle est composée de deux parties, celle affectée au fabricant de la carte, et celle affectée par le fabricant à cette carte. Mais on ne pourrait pas organiser un réseau simplement en fonction des cartes réseaux et de leurs fabricants. On veut en général organiser un réseau en fonction d'autres critères.

 

Dans cet objectif, on se sépare de l'adressage de la couche 2, pour passer dans une couche 3 qui se désolidarise des cartes réseaux elle-même pour organiser un adressage basé sur la logique de l'administrateur.

 

Ainsi, on peut regrouper les machines dans des ensembles géographiques (toutes les machines d'un même immeuble sont regroupées) ou simplement logique (tous les ordinateurs d'un même service, organisé sur deux zones géographiques, sont dans le même ensemble).

 

Dans l'adressage IP, on a choisi de classer les réseaux en fonction de leur taille. Ainsi, on va définir une adresse réseau qui sera collective à l'ensemble, et une adresse hôte, qui dans le réseau sera unique.

 

Il existe quatre classes de réseau, défini en fonction de leur taille.

 

Un réseau de classe A pourra comporter un peu plus de 16 millions de machines. Un réseau de classes B pourra comprendre 65 000 machines environ, un réseau de classe C 255 machines (2.10.24, 2.10.16, 2.10.8 machines respectivement).

 

Pour comprendre l'adressage IP, il suffit de se souvenir que les adresses IP sont écrites en binaire.

 

À partir de ce principe, on définit un code qui permet de savoir si l'adresse considérée fait partie d'un réseau de classe A,B ou C. détenir cette information est essentiel pour adresser correctement le paquet, en passant par une table DNS d'une taille raisonnable.

 

Pour définir la classe, on s'intéressera au premier octet. Il est constitué d'une suite de huit 0 ou 1. Par convention, le premier bit sera à 0 pour une classe A, et à un pour toutes les autres. Le second bit sera à 0 pour une classe B, et à un pour les autres qui suivent. Le troisième bit sera à 0 pour une classe C, et à un pour celles qui suivent. Ainsi, la position des premiers 1 et des 0 donnera la classe :

·        0xxx : classe A (soit 1 à 126)

·        10xx : classe B (soit 129 à 191)

·        110x : classe C (soit 192 à 233)

 

Evidemment, on ne peut pas se contenter de cette logique pour adresser toutes les machines du monde. On distingue donc les machines qui sont reliées à l'Internet, et qui ont besoin d'une adresse enregistrée, et celles qui ne sont pas reliées à l'Internet, et qui peuvent s'organiser en sous réseau.

 

Ces sous réseaux comportent une partie qui est appelée identifiant du réseau, et qui est commune à toutes les machines du même groupe, et une autre qui est appelée identifiant d'hôte, unique à chaque machine au sein du groupe.

 

L'identifiant du réseau doit permettre d'identifier le sous réseau au sein du réseau, tout en laissant assez de place pour identifier chaque machine du sous réseau.

 

Ainsi, on bâtit un sous réseau en laissant une partie hôte assez longue pour identifier toutes les machines du sous réseau, mais pas plus.

 

Là encore, il faut raisonner en binaire. On commencera par établir le nombre d'adresses dont on a besoin, et la transcription en binaire de ce nombre donnera l'espace qu'il faut réserver à la partie hôte dans le sous réseau. Le reste de l'adresse sera celle du sous réseau lui-même.

 

Pour définir cette partie hôte par rapport à la partie réseau, on établira un masque qui mettra la partie réseau à la valeur la plus haute (tous les bits qui concernent la partie réseau seront à un, tous les bits qui concernent la partie hôte seront à 0 : cet ensemble constituera le masque).

 

Il faut se souvenir que l'adresse hôte la plus haute possible du sous réseau servira de Broadcast, et que la partie la plus basse possible définira l'adresse réseau. Ainsi, il y a toujours deux adresses interdites dans un sous réseau. Il convient d'en tenir compte pour établir la taille de la partie réseau et de la partie hôte.

 

 

 

 

 

L'adressage TCP/IP constitue un ensemble complexe qui obéit à bien d'autres règles. Par exemple, afin d'éviter la saturation du nombre d'adresses possibles, la convention CIDR permet de limiter la taille des tables DNS, en procédant par agrégation de routes. Cette partie sera vue plus en détail dans la section routage.