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.
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.
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.
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.
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.
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.
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.
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 |
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.
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.
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.