# Réseaux TCP/IP/La pile TCP/IP
## La pile TCP/IP
### Le datagramme IP (version 4)

Lorsque deux machines communiquent en utilisant le protocole IP, elles s'échangent des datagrammes IP qui ont le format ci-dessous :
32 bits (= 4 octets) :
| Numéro de version | Longueur en-tête | Type de service | Longueur totale du datagramme | Longueur totale du datagramme |
| Identificateur (recopié dans chaque segment) | Identificateur (recopié dans chaque segment) | Identificateur (recopié dans chaque segment) | Drapeaux + position du segment |
| Durée de vie | Durée de vie | Protocole couche 4 | Somme de contrôle de l'en-tête | Somme de contrôle de l'en-tête |
| Adresse IP source ||||||
| Adresse IP destination ||||||
| Options ||||||
| Données ||||||
* Version (4 bits) :
    le champ version indique la version utilisée du protocole IP. Début 2006, la version de IP la plus fréquemment utilisée est la version 4. La version 6 commence à apparaitre : il n'y aura pas de version 5. Les 4 bits de ce champ sont donc 0100 (codage en binaire de la valeur décimale 4).
* IHL = IP Header Length - longueur de l'en-tête IP (4 bits) :
    ce champ indique la longueur de l'entête IP. L'unité est le nombre de mots de 32 bits. Pour la version 4 la longueur de cette entête est de 20 octets soit 5 fois 32 bits : ce champ vaut donc 0101.
* Type of service (8 bits) :
    ce champ permet d'indiquer que certains datagrammes IP ont une priorité supérieure à d'autres. Il est peu utilisé sauf par quelques routeurs spécialisés dans la transmission de voix sur IP.
* Total length (16 bits) :
    ce champ indique le nombre d'octets du datagramme, en-tête IP comprise. La longueur maximale du datagramme en octets est 2$^{16}$-1 = 65 535 octets = 64 ko -1 octet
* ID (16 bits) :
    ce champ est un identifiant du datagramme IP (le numéro du datagramme).
* F = Flags - les drapeaux (3 bits) :
** le premier bit est inutilisé
** le deuxième bit DF (don't fragment) permet d'interdire ou d'autoriser la fragmentation. positionné à 1, il est interdit de fragmenter ce datagramme IP.
** le troisième bit MF (more fragment) est utilisé lors de la fragmentation : il indique si le fragment est le dernier fragment du datagramme (MF=0) ou non (MF=1).
* TTL = Time to live - temps restant à vivre (8 bits) :
    il s'agit d'une valeur initialisée par l'émetteur et qui est décrémentée de 1 à chaque fois que le datagramme traverse un routeur. Si le TTL arrive à la valeur 0, le datagramme est détruit : ce mécanisme assure la destruction des datagrammes qui se perdent sur le réseau. Ainsi ces datagrammes perdus n'encombrent pas indéfiniment le réseau.
* Protocole (8 bits) :
    ce champ indique la nature des données transportées par ce datagramme IP. 3 protocoles sont principalement utilisés au dessus de IP : ICMP (code 1), TCP (code 6) et UDP (code 17).
* Header Checksum - somme de contrôle de l'en-tête (16 bits) :
    il s'agit d'un code détecteur d'erreurs qui ne porte que sur l'entête : la somme des octets de l'entête regroupé par paquets de 16 bits (header checksum compris) doit valoir 2$^{16}$-1 modulo 2$^{16}$. En cas d'erreur sur l'entête le datagramme est détruit. IP n'est pas un protocole fiable puisqu'on ne garantit pas que les données arrivent, ni de leur fiabilité.
* IP source (32 bits) :
    adresse IP de l'expéditeur.
* IP destination (32 bits) :
    adresse IP du destinataire.

## La fragmentation IP
### Notion de MTU

La plupart des réseaux imposent une limite physique à la taille des données qu'ils peuvent transporter. Un datagramme IP peut avoir une taille maximale de 65535 octets, ce qui est trop grand pour la plupart des réseaux. Le MTU (Maximum Transfert Unit) correspond à la taille maximale des données transportables par le réseau. Le datagramme IP (entête comprise) aura comme taille maximale le MTU du réseau.

### Quelques valeurs du MTU

Ethernet : MTU = 1500 octets (fixé à 1492 pour optimiser sa connexion). FDDI : 4470 octets.

### Découpage par le routeur

Si un routeur route des données d'un réseau A vers un réseau B et si les 2 réseaux ont des valeurs différentes de MTU (par exemple le réseau A est un réseau FDDI de MTU 4470 et le réseau B est un réseau Ethernet de MTU 1500 octets), alors il peut être amené à découper un datagramme IP en plusieurs datagrammes plus petits.

### Le rôle des flags et du champ FO

Si un datagramme a été découpé, il faut être capable de réunir les différents morceaux dans le bon ordre à l'arrivée : les flags (3 bits) et le champ FO (Fragment Offset sur 13 bits) vont contenir les informations nécessaires à cette reconstruction.

### Les flags

* premier bit : inutilisé. La valeur est toujours à 0.
* deuxième bit : DF (Don't fragment) permet d'autoriser ou d'interdire la fragmentation du datagramme. Si le bit DF est à 0, la fragmentation est autorisée et s'il vaut 1, elle est interdite. Si le routeur doit découper un datagramme et que le bit DF est à 1, alors le datagramme IP sera détruit.
* troisième bit : MF (More Fragment) permet d'indiquer si le datagramme est le dernier ou non. Si MF est à 0, alors le fragment est le dernier, s'il vaut 1, alors il n'est pas le dernier.

### Le champ FO

Le nombre d'octets de données de chaque fragment, sauf le dernier, doit être un multiple de 8. Ainsi la position du premier octet de chaque fragment dans le datagramme d'origine sera un multiple de 8. La valeur du champ FO de chaque fragment sera le quotient de cette position par 8, codé en binaire sur 13 bits.

### Exemple

* Données de départ :
** Un routeur doit router un datagramme IP dont la taille totale fait 4470 octets sur un réseau Ethernet.
** Le datagramme initial comprend 20 octets d'entête et 4450 octets de données. Numérotons de 0 à 4449 ces octets.
** Chaque fragment aura une taille maximale de 1500 octets, soit 20 octets d'entête et 1480 octets de données.
* Répartition des données dans les fragments :
** On mettra dans le premier fragment les octets de 0 à 1479 du datagramme initial.
** On mettra dans le deuxième fragment les octets de 1480 à 2959 du datagramme initial.
** On mettra dans le troisième fragment les octets de 2960 à 4439 du datagramme initial.
** On mettra dans le quatrième fragment les octets de 4440 à 4449 du datagramme initial.
* La position du premier octet du fragment dans le datagramme initial sera donc :
** premier fragment : 0
** deuxième fragment : 1480
** troisième fragment : 2960
** quatrième fragment : 4440
* On s'aperçoit que la condition Chaque fragment sauf le dernier contient un nombre d'octets multiple de 8 a pour conséquence que dans tous les fragments y compris le dernier la position du premier octet du fragment dans le datagramme initial est un multiple de 8.
* Description des fragments :
** premier fragment : FO=0/8=0 et MF=1
** deuxième fragment : FO=1480/8=185 et MF=1
** troisième fragment : FO=2960/8=370 et MF=1
** quatrième fragment : FO=4440/8=555 et MF=0

## Le protocole ARP
### Encapsulation des protocoles

* Lorsqu'un datagramme IP est envoyé sur un réseau Ethernet alors sur le réseau il ne va circuler que des trames Ethernet. Ces trames Ethernet contiendront dans leur champ de données un datagramme IP. On dit que le protocole IP est encapsulé dans Ethernet.
* L'encapsulation peut être plus complexe. Lorsque une machine envoie un datagramme ICMP, celui-ci sera encapsulé dans un datagramme IP qui sera encapsulé dans une trame Ethernet.

### Format de la trame Ethernet

Une trame Ethernet contient les champs suivants :
* un préambule sur 64 bits : 31 fois 01 suivi de 11. Le préambule sert à la synchronisation ;
* l'adresse MAC du destinataire ;
* l'adresse MAC de l'expéditeur ;
* un code sur 16 bits indiquant le protocole utilisé au dessus d'Ethernet. IP aura comme code 0800 (en hexadécimal) et ARP aura comme code 0806 ;
* les données ;
* un code détecteur d'erreur de type CRC permettant de savoir si la trame a été altérée ou non.

### Le problème

Imaginons qu'une machine A veuille envoyer un datagramme IP à une machine B via un réseau Ethernet. Le datagramme IP sera encapsulé dans une trame Ethernet. A va avoir besoin des informations suivantes :
* sa propre adresse IP. A connait son adresse IP car l'administrateur l'a configurée ;
* l'adresse IP de B. A la connait : un serveur DNS lui a fourni l'adresse IP de B ;
* sa propre adresse MAC : A la connait car elle est écrite sur sa carte Ethernet ;
* l'adresse MAC de B. A ne possède pas cette information ! A est incapable d'envoyer une trame Ethernet à B sans cette information. Le protocole ARP va permettre à A de récupérer cette information.

### Rôle du protocole ARP

Le protocole ARP, pour Address Resolution Protocol, permet d'obtenir l'adresse MAC d'une machine à partir de son adresse IP.

### Le format de la trame ARP

32 bits (= 4 octets) :
| champ 1 | champ 1 | champ 2 | champ 2 |
| champ 3 | champ 4 | champ 5 | champ 5 |
| champ 6 ||||
| champ 6 (suite) | champ 6 (suite) | champ 7 | champ 7 |
| champ 7 (suite) | champ 7 (suite) | champ 8 | champ 8 |
| champ 8 (suite) ||||
| champ 9 ||||
* champ 1 (2 octets) : type de réseau physique. Il s'agit d'un code indiquant la nature du réseau physique. Pour Ethernet le code sera 01 (en hexadécimal)
* champ 2 (2 octets) : il s'agit du code du protocole réseau utilisé. IP aura comme code 0800 (en hexadécimal).
* champ 3 (1 octet) : longueur de l'adresse physique. Le protocole Ethernet utilise des adresses de 48 bits soit 6 octets. Ce champ vaudra donc 6 pour un réseau Ethernet.
* champ 4 (1 octet) : longueur de l'adresse protocole. Le protocole IP utilise des adresse de 32 bits soit 4 octets. Ce champ vaudra donc 4 pour un réseau IP.
* champ 5 (2 octets) : opération indique la nature de l'opération demandée. Une demande ARP aura comme code 01 et une réponse ARP le code 02.
* champ 6 (6 octets) : adresse physique de l'expéditeur.
* champ 7 (4 octets) : adresse protocole de l'expéditeur.
* champ 8 (6 octets) : adresse physique du destinataire. Pour les demandes ce champ a la valeur hexadécimale FF:FF:FF:FF:FF:FF.
* champ 9 (4 octets) : adresse protocole du destinataire.

### La table ARP

Les réponses des différentes demandes ARP sont mémorisées dans une table ARP qui contient les correspondances entre les adresses MAC et IP de différentes machines.

### Un exemple d'échange de trames ARP

On considère 2 machines A et B sur un même réseau. A souhaite connaître l'adresse MAC de B dont il connait l'adresse IP.
* A envoie en broadcast une demande ARP.
* B notifie dans sa table ARP la correspondance entre les adresses IP et MAC de A.
* B répond à A en lui transmettant son adresse MAC.
* A mémorise les correspondances entre les adresses MAC et IP de B dans sa table ARP.
Les données contenues dans la table ARP ont une validité de 20 minutes. Une fois ce delai dépassé, il faut refaire une demande ARP.

## Le protocole ICMP

ICMP, pour Internet Control Message Protocol, est un protocole de contrôle au niveau de la couche 3 du modèle OSI. À l'instar du protocole IP, il se décline actuellement en versions 4 et 6.

### Le rôle de protocole ICMP

Ce protocole assure les rôles suivants :
* éprouver la connectivité réseau. Par exemple, dans sa version 4, le datagramme ICMP de type 8 (demande d'écho) invite le destinataire à une réponse par un datagramme ICMP de type 0 (réponse à une demande d'écho) ;
* optimiser le réseau, à une certaine échelle ;
* gérer les messages d'erreurs de réseau.
Il n'assure pas d'échange de données proprement dit.

### Le format du paquet ICMP

Les données du protocole ICMP sont encapsulées dans un paquet IP. Dans ce sens, un paquet ICMP désigne un paquet IP dont la charge utile correspond aux données ICMP.
Les champs spécifiques à ICMP sont les suivants :
* Type : sur 8 bits. Ce champ détermine la nature (ou le type ou la catégorie) du datagramme ICMP.
* Code : sur 8 bits. Il indique un sous-type du datagramme ICMP.
* Checksum - somme de contrôle : sur 16 bits. Il correspond à un code détecteur d'erreurs pour les données ICMP.
* Données : sur 32 bits ou plus. Elles figurent des informations, optionnelles, liées aux type et sous-type de paquet ICMP.

### Types de datagramme ICMP

Les RFC de référence, 792 pour la version 4, 4443 et 4884 pour la version 6, spécifient plusieurs types de paquet ICMP.
Les paquets ICMP les plus couramment rencontrés et utilisés sont les suivants :
* demande d'écho : Type 8 en version 4, Type 128 en version 6 ;
* réponse à une demande d'écho : Type 0 en version 4, Type 129 en version 6.

## Le protocole UDP

Le protocole UDP (User Datagram Protocol) utilise le protocole IP (adresses source et destinataire) pour l'envoi et la réception de trames de données (Datagram).
Ce protocole n'est pas "fiable" pour différentes raisons :
* Les paquets peuvent être reçus dans un ordre différent de celui utilisé lors de leur envoi. Ceci s'explique par le fait qu'ils peuvent suivre des routes différentes, subir des traitements différents, ...
* Il n'y a pas d'acquittement ou de retransmission des paquets de données.
* La connexion n'est pas maintenue entre le serveur (émetteur) et le client (récepteur), la transmission des paquets est ponctuelle.
Ce manque de "fiabilité" doit donc être compensé au niveau supérieur (application) en résolvant les points précédents de la manière suivante (par exemple) :
* Afin de reconstituer les données sources, inclure un numéro de paquet pour reconstituer les données dans l'ordre, ou ajouter une adresse dans le flux de donnée global,
* Afin de vérifier la bonne transmission de chaque paquet, ajouter une somme de vérification (CRC, code de hashage),
* Afin de vérifier la bonne transmission de tous les paquets, le client envoi un paquet d'acquittement pour chaque paquet reçu correctement, l'émetteur qui n'obtient pas cet acquittement dans un temps raisonnable retransmet à nouveau le paquet correspondant.

## Le protocole TCP

Le protocole TCP (Tranmission Control Protocol) résout les problèmes de "fiabilité" du protocole UDP, et permet la transmission de données sous la forme d'un flux d'octets plutôt que sous la forme de paquets.

## Voir aussi ...

* IP version 4 : présentation du datagramme IP.
* Ethernet : présentation de la trame Ethernet.
* ARP : présentation de ARP.
* ICMP : présentation du protocole ICMP.