5 - Protocole TCP
Nous avions vu que la couche APPLICATION se charge de mettre en forme les communications puis fait appel à la couche TRANSPORT pour la suite de la procédure : une couche - une tâche.
Vous allez en apprendre plus aujoud'hui sur cette nouvelle couche TRANSPORT.
Nous allons notamment voir que le protocole TCP de cette couche utilise des drapeaux pour communiquer. Le top de la technologie !
Evaluation ✎ : questions 01-02-03-04.
Documents de cours : open document ou pdf
1 - Couche TransPORT : notion de PORT
1 - TransPORT et PORT
Lorsqu'une application veut envoyer un message, elle transmet sa demande à la couche APPLICATION.
La couche APPLICATION est chargée de permettre une communication sans ambigüité entre deux programmes partageant un même protocole. Elle doit pouvoir :
- structurer correctement la communication qu'un programme veut envoyer ou recevoir : elle sait faire
- transmettre la communication à l'autre programme : elle ne sait pas faire cela...
Alors, comment fait-elle ?
La couche APPLICATION va faire appel à une amie qui pourra transférer la communication : une couche TRANSPORT.
Exemple :
FIREFOX veut transférer une demande, il active
la couche APPLICATION GAUCHE qui structure la demande puis active
la couche TRANSPORT GAUCHE qui gére l'envoi à
la couche TRANSPORT DROITE qui reçoit le message et le transfère à
la couche APPLICATION DROITE qui structure la demande puis la fournit
au programme-serveur HTTP
Par contre, ces couches TRANSPORT
- reçoivent des requêtes issues de beaucoup de programmes
- reçoivent des réponses de l'extérieur à destination de beaucoup de programmes...
Comment cette couche TRANSPORT sait-elle à quel programme transmettre une requête ou une réponse ?
Nous allons voir que la couche TRANSPORT attribue un identifiant à chaque programme voulant communiquer : un PORT.
Comment se fait-il que vous ne connaissiez sans doute pas cette notion de PORT ? Simple : on ne l'utilise jamais en tant qu'utilisateur ! Le navigateur gère tout comme un grand en les rajoutant.
2 - Le PORT dans l'URL ?
Rappel sur l'URL
Si vous êtes sur cette page, vous avez cette URL dans la barre de navigation :
https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
Nous avons donc :
- Le protocole https visible en début d'URL
- https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
- Le nom de domaine du serveur à joindre www.infoforall.fr précédé de ://
- https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
- L'adresse (absolue car commençant par un slash) de la ressource : /act/archi/communication-tcp-ip-couches/
- https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
Et c'est tout... Comment fait Firefox pour signaler qu'il veut discuter avec le programme-serveur HTTP ?
Et la réponse est :
Rajout automatique d'un PORT par défaut
La couche TRANSPORT attribue un identifiant nommé PORT à tous les programmes de l'ordinateur qui demandent à communiquer.
- Un serveur HTTP possède par défaut le PORT 80.
- Un serveur HTTPS possède par défaut le PORT 443.
On peut rajouter ce fameux PORT dans l'URL en le plaçant derrière le nom de domaine en utilisant un double point :.
Pour joindre le PORT 80 de l'ordinateur hébergeant un serveur en http, on peut taper ceci :
http://www.infoforall.fr:80/act/archi/communication-tcp-ip-couches/
Pour joindre le PORT 443 de l'ordinateur hébergeant un serveur en https, on peut taper ceci :
https://www.infoforall.fr:443/act/archi/communication-tcp-ip-couches/
Conclusion : pourquoi n'avez-vous jamais eu besoin de taper le 443 dans la barre d'adresses ? Simplement car le navigateur rajoute la valeur par défaut lors de l'envoi d'une requête HTTP lorsque la demande est en https.
✎ 01° QCM : Que va rajouter le navigateur si on tape ceci :
http://monsite.com
- http://monsite.com:8000
- http://monsite.com:80
- http://monsite.com:443
- http://monsite.com:PORT
3 - De quoi est composé le PORT ?
Le PORT est un entier naturel formant une adresse encodée sur 16 bits (2 octets).
Les programmes-serveurs courants bénéficient d'un PORT par défaut inférieur à 1024.
Les programmes-clients n'ont pas de valeur de PORT fixe : la couche TRANSPORT attribue un numéro aléatoire entre 49 152 et 65535, différent à chaque lancement.
✎ 02° QCM : Avec 16 bits, que vaut la valeur maximale des PORTS ?
- 216, soit 65536
- 216 - 1, soit 65535
- 162, soit 256
- 162 - 1, soit 255
Petit rappel sur la façon d'encoder un entier supérieur à 255 sur deux octets.
Rappel : encodage d'un grand entier naturel (en Big Endian)
Pour encoder un entier supérieur à 255, il faut au moins deux octets.
En Big Endian, on obtient d'abord l'octet de poids le plus fort, celui qu'on multiplie par 28 si on a deux octets ou par 216 si on a trois octets..
Exemple : l'entier naturel N encodé sur les deux octets 90 120 en Big Endian est donc
N = 90 * 28 + 120 * 1
N = 90 * 256 + 120 * 1
N = 23160
✎ 03° On veut transmettre un PORT 443. On utilise les octets suivants 001 187 . Vérifiez s'il s'agit bien du port 443. Justifiez votre résultat.
4 - Transport entre deux couches TRANSPORT
La couche TRANSPORT peut, en théorie, gérer le transport d'un message d'un programme A de PORT A et un programme B de PORT B..
Le TRANSPORT se fait en 3 temps (les 3 flèches)
- Le programme Firefox envoie sa demande à la couche TRANSPORT de son ordinateur
- La couche TRANSPORT communique le message pour le PORT 443 à l'autre couche TRANSPORT
- La couche TRANSPORT de droite transfère la communication au programme-serveur car le message est pour PORT 443.
Si vous désirez voir quels sont les numéros de PORT courants : article Wikipédia
2 - Couche Transport : la segmentation
Imaginons que vous soyez un train de regarder un film en ligne. Le film est long, le fichier vidéo est donc gros. Si on téléchargeait tout le fichier en une seule communication, cela voudrait dire qu'on ne pourrait rien faire passer d'autre sur la carte réseau en attendant :
- Voir les emails, non ? Non.
- Ouvrir une page Web ? Non.
Pour que la communication du programme B puisse se faire, il faudrait attendre que la communication du programme A soit finie...
Ce serait pénible.
5 - SEGMENTS de la couche TRANSPORT
La couche TRANSPORT est chargée de transporter les messages de tous les programmes en même temps.
La couche TRANSPORT d'un ordinateur 1 discute donc avec la couche TRANSPORT d'un ordinateur 2 si deux programmes ne sont pas sur la même machine.
Pour garantir que plusieurs programmes pourront communiquer "en même temps", on commence par décomposer leurs messages en plusieurs sous-messages :
Cela permet d'alterner entre les messages de plusieurs applications et leur permettre de communiquer en 'même temps'.
Si on ne fait que cela, on va avoir un problème : les étiquettes sont visibles à l'écran mais rien ne permet vraiment de distinguer les sous-messages entre eux.
A l'écran :
En réalité :
Pour identifier les sous-messages, nous allons faire comme pour un courrier :
- on prend le sous-message et une enveloppe
- nous allons glisser le sous-message dans une enveloppe
- nous fermons l'enveloppe et rajouter des informations sur l'avant de enveloppe : les informations d'en-tête.
Bien entendu, cela marche également avec une analogie sur le colis :
- on prend le sous-message et une boîte
- nous allons glisser le sous-message dans la boîte
- nous fermons la boîte et rajouter des informations sur le couvercle de la boîte : les informations d'en-tête.
L'ensemble d'un en-tête et d'un sous-message se nomme un SEGMENT.
On dit qu'on a encapsulé le sous-message dans le SEGMENT. L'en-tête peut être vu comme la capsule de la bouteille dans laquelle on a placé le sous-message.
Informatiquement, cela va simplement revenir à rajouter les octets de l'en-tête devant le sous-message.
6 - La création des segments TCP
Le contenu exact de l'en-tête dépend du protocole choisi pour la couche TRANSPORT. Nous allons travailler avec le protocole TCP qui est l'un des deux protocoles fondamentaux d'Internet.
Que rajouter au minimum dans l'en-tête TCP ?
- le PORT SRC pour SouRCe (2 octets) : celui du programme émetteur. Sans lui le programme-récepteur ne saurait pas à qui répondre.
- le PORT DST pour DeSTination (2 octets): celui du programme-récepteur qu'on veut joindre. Sans lui, la couche TRANSPORT de l'ordinateur récepteur ne saurait pas à quel programme transmettre le message.
- SEQ, un système de numérotation du segment par rapport aux autres (2 octets) pour signaler la place du segment dans l'ensemble. Remarque : dans le vrai TCP, ce n'est pas juste un numéro, mais un numéro d'octets. Ici on simplifie.
Remarque : vous pouvez zoomer en cliquant sur les segments, ou utiliser CRTL+ comme d'habitude.
Et voilà pour l'essentiel. Par la suite, nous représenterons l'en-tête TCP (TCP header en anglais) sous la forme d'un rectangle jaune noté TCP.
Un segment TCP est donc formé d'un en-tête TCP et d'un sous-message.
On dit que le segment TCP encapsule le sous-message.
Les SEGMENTS sont tous être transportés un par un d'une couche TRANSPORT à une autre couche TRANSPORT.
✎ 04° Il n'y a plus de couleur dans les segments affichés pour savoir s'ils proviennent des programmes A ou B. Dans le segment ci-dessous, où se trouve l'information permettant de retrouver le programme à l'origine du message ?
Question supplémentaire : quel est le numéro de ce segment ?
Pour info, les indications fournies dans le header TCP sur la représentation du segment sont :
- SRC 24945
- DST 443
- SEQ 4
7 - Transmission d'un flux via TCP
TCP permet donc de gérer les flux.
Le principe est simple côté récepteur :
- Si on reçoit un segment numéroté SEG 5 et qu'on a déjà reçu les segments 1-2-3-4, on renvoie un accusé de réception en notant ACK SUI 6 pour dire... qu'on veut bien le 6.
- Si on reçoit un segment numéroté SEG 5 sans avoir reçu tous les messages 1-2-3-4, on ne renvoie pas d'accusé de réception.
Le principe est simple également du côté émetteur :
- Lorsqu'on émet un segment, on attend un certain temps son accusé de réception. S'il n'arrive pas, on renvoie à nouveau le segment.
- Au bout d'un certain nombre de renvois, on arrête : la communication n'est juste plus possible visiblement.
05° On reprend la dernière configuration. Un nouveau segment arrive.
Voici le contenu de son en-tête :
- SRC 9860
- DST 443
- SEQ 3
Le segment 4 en mémoire va-il être transféré au programme 443 (attention aux valeurs des PORTS) ?
...CORRECTION...
Non car le nouveau segment est bien un segment identifié 3 mais il ne provient pas de la source 2050 mais d'une source 9860 : ce n'est donc pas le segment à placer devant l'autre !
06° Encore un nouveau segment.
- SRC 2050
- DST 443
- Seq 3
Le segment 4 en mémoire va-il finalement être transféré au programme 443 ?
...CORRECTION...
Oui, cette fois les segments 3 et 4 provenant du SRC 2050 sont transférés au programme DST 443.
D'abord le segment 3 qui vient d'arriver puis le segment 4 qui était en mémoire.
Si on veut visualiser la suite de la transmission, le programme serveur reçoit finalement toute la REQUETE HTTP :
Le serveur HTTP n'a plus qu'à créer sa REPONSE HTTP et ... ça repart dans l'autre sens en inversant simplement les valeurs de DST et SRC !
07° QCM : Firefox est identifié par le PORT 2050. Le programme-serveur est le PORT 443. On cherche à remplir l'en-tête des segments TCP de la réponse HTTP fournie par le serveur https. Que doit-on mettre comme information dans les PORTS :
- A : SRC 80 - DST 443
- B : SRC 443 - DST 80
- C : SRC 443 - DST 2050
- D : SRC 2050 - DST 443
...CORRECTION...
Réponse C : la source de la réponse HTTP est cette fois le serveur HTTPS et la destination est le PORT 2050 puisque c'est lui qui avait lancé initialement la requête.
2050 pour 443 lors de la requête.
443 pour 2050 lors de la réponse.
3 - Protocole TCP : Garantir le transport
TCP garantit la transmission
TCP veut dire Transmission Control Protocol.
Vous devez savoir que TCP permet de garantir la transmission correcte d'un message en contrant deux problèmes possibles :
- mauvaise transmission d'un segment TCP (quelques bits ont été modifiés)
- TCP gère avec une somme de contrôle
- disparition d'un segment TCP
- TCP gère avec les acquittements (ou accusés de réception)
Attention
Aucune connaissance des mécanismes exactes permettant de la somme de contrôle ou des accusés de réception ne sera demandée.
Vous devez juste savoir que c'est possible.
8 - La somme de contrôle dans l'en-tête TCP
Nous avons vu que l'en-tête TCP comporte déjà :
- le PORT SRC pour SouRCe (2 octets)
- le PORT DST pour DeSTination (2 octets)
- SEQ, un système de numérotation du segment (2 octets)
Nous allons maintenant rajouter une information pour détecter la modification de certains bits pendant la transmission :
- CS pour Check Sum ou Somme de Contrôle en Français (2 octets) : un nombre compris entre 0 et 65535 qu'on notera
XXXXXsur tous les exemples mais la valeur doit être calculer précisement pour chaque segment.
Le fonctionnement va nous permettre de refaire un peu de révision sur les additions binaires.
Rappel sur l'addition en base 2
- 0+0 = 0
- 0+1 = 1
- 1+1 = 10
- 1+1+1 = 11
- 1+1+1+1 = 100
Côté Emetteur : le calcul de la somme de contrôle CS.
- on réalise l'addition 16 bits de tous les bits du segment.
- on fait le complément à 1 sur la somme :
- 0 devient 1
- 1 devient 0
Ces opérations sont longues à faire par un humain mais rapides pour l'Unité Arithmétique et Logique.
08° Soit un segment imaginaire à émettre contenant uniquement ces octets :
- 2 octets de SRC : 0000 1000 0000 0010
- 2 octets de DST : 0000 0001 1011 1011
- 2 octets de SEQ : 0000 0000 0000 0100
- 0 octets de sous-message : c'est un message vide
1 - Réaliser l'addition sur 16 bits de SRC+DST+SEQ (vous pouvez le faire de tête et cliquer sur les ▫ pour changer l'affichage).
2 - Réaliser enfin le complément à 1 de la somme : c'est CS, la somme de contrôle.
| Retenue | ▫▫▫▫
▫▫▫▫
▫▫▫▫
▫▫▫ 2
|
| SRC 443 10 | 0000 0001 1011 1011 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| Somme | ▪▪▪▪
▪▪▪▪
▪▪▪▪
▪▪▪▪ 2
|
| CS | ▪▪▪▪
▪▪▪▪
▪▪▪▪
▪▪▪▪ 2
|
...CORRECTION...
| Retenue | ▫▫▫▫ ▫▫▫▫ ▫111 11▫ 2
|
| SRC 443 10 | 0000 0001 1011 1011 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| Somme | 0000 1001 1100 0001 2
|
| CS | 1111 0110 0011 1110 2
|
En inversant via le complément à 1, on obtient donc la somme de contrôle suivante :
CS = 1111 0110 0011 1110 2 = 63038 10
Pour obtenir rapidement la valeur en base 10, il suffit de taper ceci dans Python :
>>> 0b1111011000111110
63038
>>> int('1111011000111110', 2)
63038
On émet donc ce segment qui ne contient que les 8 octets de l'en-tête :
0000 0001 1011 1011
0000 1000 0000 0010
0000 0000 0000 0100
1111 0110 0011 1110
Cela donne donc :
SRC 443
DST 2050
SEQ 4
CS 63038
Côté Récepteur : le récepteur va recevoir le segment et faire à son tour un calcul utilisant le CS présent dans le segment :
09° Imaginons d'abord une situation sans erreur de transmisson : le récepteur a bien reçu le segment précédent.
0000 0001 1011 1011
0000 1000 0000 0010
0000 0000 0000 0100
1111 0110 0011 1110
Question : additionner sur 16 bits les bits du segment. Le SEGMENT est valide uniquement si la somme n'est composée que de 1. Le segment reçu est-il corrompu ?
| Retenue | ▫▫▫▫
▫▫▫▫
▫▫▫▫
▫▫▫ 2
|
| SRC 443 10 | 0000 0001 1011 1011 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| CS 63038 10 | 1111 0110 0011 1110 2 |
| Somme | ▪▪▪▪ ▪▪▪▪ ▪▪▪▪ ▪▪▪▪ 2
|
...CORRECTION...
| Retenue | ▫1▫▫ ▫▫▫▫ ▫111 11▫ 2
|
| SRC 443 10 | 0000 0001 1011 1011 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| CS 63038 10 | 1111 0110 0011 1110 2
|
| Somme | 1111 1111 1111 1111 2
|
On voit donc que la somme sur 16 bits des données doit donner la valeur maximale. Il n'y a que des bits à 1.
Avec l'évaluation pareusseuse, cela implique qu'on peut s'arrêter dès qu'un des bits de la somme ne donne pas 1.
10° Passons à un exemple avec un problème lors de la transmission : le dernier bit de SRC a été modifié (ici en surligné).
0000 0001 1011 1010
0000 1000 0000 0010
0000 0000 0000 0100
1111 0110 0011 1110
Question : additionner sur 16 bits les bits du segment. Le SEGMENT est valide uniquement si la somme n'est composée que de 1. Le segment reçu est-il corrompu ?
| Retenue | ▫▫▫▫
▫▫▫▫
▫▫▫▫
▫▫▫ 2
|
| SRC 443 10 | 0000 0001 1011 1010 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| CS 63038 10 | 1111 0110 0011 1110 2 |
| Somme | ▪▪▪▪ ▪▪▪▪ ▪▪▪▪ ▪▪▪▪ 2
|
...CORRECTION...
| Retenue | ▫1▫▫ ▫▫▫▫ ▫111 11▫ 2
|
| SRC 443 10 | 0000 0001 1011 1010 2 |
| DST 2050 10 | 0000 1000 0000 0010 2 |
| SEQ 4 10 | 0000 0000 0000 0100 2 |
| CS 63038 10 | 1111 0110 0011 1110 2
|
| Somme | ▪▪▪▪ ▪▪▪▪ ▪▪▪▪ ▪▪▪0 2
|
La somme posséde au moins un bit à zéro : inutile de continuer. Il y a eu un problème quelque part. Le segment n'est pas valide !
9 - Principe de la Somme de contrôle (Check Sum en anglais)
Une Somme de Contrôle est un moyen de détecter une altération du message entre émission et réception.
Ne retenez que le principe :
- L'émetteur effectue un calcul sur les données initiales.
- L'émetteur insère le résultat du calcul dans les données envoyées.
- Le récepteur effectue à son tour un calcul sur les données recues et vérifie si ces données ont pu être modifiées lors du transport.
Attention : on ne vous demande pas de retenir la méthode utilisée ici. Il s'agissait juste de réviser un peu les sommes binaires. Seul le principe général et l'intérêt de la Somme de Contrôle est à retenir.
Bon, on a presque fini :
- On sait que TCP segmente le message initial
- On sait localiser un programme avec son PORT
- On sait lire le numéro d'un segment avec SEQ
- On sait détecter qu'un segment reçu n'est pas valide avec CS, la Somme de Contrôle
Mais pour garantir la transmission, il reste à voir comment l'émetteur détecte qu'un segment n'a pas été reçu ou validé par le récepteur.
La fonction fondamentale de TCP est en effet de contrôler la transmission de données par un système d'accusé de réception. On parle également d'acquittement. En anglais, c'est acknowledgment.
Et ça fonctionne avec des drapeaux.
Si si.
Comme pour la somme de contrôle, il faut juste comprendre que c'est possible, et certainement pas de retenir les détails de l'acquittement suivant qui n'est de toutes manières qu'une version simplifiée et imaginaire du vrai acquittement TCP.
11° Jouer la transmission TCP dans la salle de cours en permettant à deux élèves de communiquer : personne n'a le droit de lancer le papier ou de bouger : on ne peut transmettre qu'à un voisin direct.
Protocole à suivre à la lettre. Aucune interprétation : vous jouez le rôle de la machine !
1er phase : conception du message
- Ecrire un message d'une ligne complète sur la feuille A4 couper en deux dans la longueur.
- Couper la feuille en 3 bouts de taille égale.
- Réaliser une copie de chaque sous-message.
- Encapsuler chaque sous-message par les "enveloppes TCP".
- Sur chaque enveloppe, notez l'en-tête TCP dans l'ordre suivant :
- SRC : votre prénom
- DST : le prénom de la personne à qui vous voulez envoyer le message
- SEG : le numéro du segment (1, 2 ou 3)
Vous obtenez donc 2 jeux de 3 sous-messages.
2e phase (version EMETTEUR): premier envoi
- Envoyer votre premier segment en le donnant à l'un de vos voisins qui devra faire la même chose de façon à faire parvenir le message SANS bouger de votre place.
- Si vous ne recevez pas d'accusé de réception pour ce message (ACK SUI 2) dans les 10 minutes, il faudra alors... renvoyer la copie du segment 1 (en espérant que celui-ci arrive).
- Si vous recevez l'accusé de réception, il faudra alors envoyer le SEGMENT n°2 puisqu'on vous le demande poliment avec ACK SUI 2.
- N'envoyez pas le troisième message tout de suite par contre.
2e phase (version RECEPTEUR)
- Lorsque vous recevez un SEGMENT qui vous est destiné, il faut normalement faire la Somme de Contrôle. On dira que c'est bon.
- Ecrire alors un SEGMENT VIDE (ne contenant pas du message) : vous utilisez juste une enveloppe TCP en notant sur l'EN-TETE TCP :
- SRC : votre prénom (la DST du SEGMENT reçu)
- DST : le prénom de la personne qui vous a écrit (la SRC du SEGMENT reçu)
- SEG : 0 (ou le numéro du dernier SEGMENT NON VIDE envoyé à cette personne)
- ACK (pour indiquer que vous signalez un accusé de réception)
- SUI 2 (pour indiquer que vous voulez bien la suite)
Lorsque vous allez recevoir le SEGMENT 2, pensez à noter ACK SUI 3.
Une fois que tout le monde aura bien reçu ses deux accusés de réception, nous passerons à la phase 3.
3e phase : disparition
Vous allez alors envoyer votre troisième segment MAIS il va y avoir une complication : vous aurez à faire disparaître au choix UN segment qui passe par vous. Un SEUL par personne. Soit à l'aller, soit un accusé de réception.
Maintenant que vous êtes persuadé que le système d'accusé de réception fonctionne, voyons comment faire cela avec des machines...
10 - En-tête TCP complet (ou presque...)
Nous avons vu que l'en-tête TCP qu'on place devant le sous-message comporte déjà :
- le PORT SRC pour SouRCe (2 octets)
- le PORT DST pour DeSTination (2 octets)
- SEQ, un système de numérotation du segment par rapport aux autres (2 octets)
- CS, un système de contrôle de bonne transmission : la somme de contrôle (2 octets)
Rajoutons un drapeau encodé via un seul BIT :
- Un bit ACK d'acquittement (1 bit) :
- Drapeau baissé : 0 veut dire que le segment ne contient pas d'accusé de réception.
- Drapeau levé : 1 veut dire que le segment contient un accusé de réception.
- on rajoute un système de numérotation des accusés de réception (SUI, sur 2 octets) pour signaler le segment qu'on accepte de recevoir ensuite. Dans le vrai système, on parle en octets. Ici, nous utiliserons directement les numéros de segments.
On peut donc accuser réception en plaçant le bit ACK à 1. Oui, mais on accuse réception de quoi exactement ? Il reste à insérer une dernière information.
Si on vient de recevoir le segment 5, on envoie un segment en activant le drapeau ACK et on place SUI 6 : "j'ai bien reçu le 5, tu peux envoyer le 6".
11 - Communication TCP, enfin !
Le protocole TCP tournant sur chaque machine va être à la fois émetteur et récepteur.
Algorithme d'émission
- TCP émet un segment et attend l'acquittement
- si TCP ne reçoit rien avant la durée limite, il émet à nouveau le segment (au bout d'un certain nombre d'échec, il arrête en réalité)
- si le segment est acquitté, TCP passe au segment suivant...
Algorithme de réception
- TCP reçoit un segment
- Il acquitte uniquement si
- le SEGMENT n'est pas corrompu
- les SEGMENTS précédents ont tous été reçus
Voyons l'exemple complet où Firefox établi une connexion avec le serveur.
- Le client envoie le segment 1 en précisant SEQ 1.
- Le côté-serveur répond ACK SUI 2 (pour acquitter et dire qu'il veut bien le segment 2)
- Le serveur envoie alors sa réponse à la couche TRANSPORT.
- La couche TRANSPORT segmente et devra envoyer deux SEGMENTS par exemple.
- Le TCP-serveur envoie le segment 1 : SEQ 1.
- Le TCP-client répond ACK SUI 2 pour dire qu'il veut bien du segment 2.
- Le TCP-serveur reçoit l'acquittement
- Il envoie le segment 2 : SEQ 2.
- Le TCP-client répond ACK SUI 3 pour dire qu'il veut bien du segment 3.
Comme vous le voyez, il s'en passe des choses simplement lorsque vous demandez à afficher une page Web. Et encore, n'oubliez pas qu'ici, vous n'avez reçu que le code HTML. Le navigateur doit maintenant faire des requêtes pour toutes les images nécessaires, les fichiers CSS, les fichiers JS...
Voyons comment TCP gère les erreurs à l'aide des accusés de réception ou acquittements.
1er situation : une erreur de transmission.
- Côté récepteur : on ne valide pas le SEGMENT puisqu'il est corrompu
- Côté émetteur : après un certain temps sans réponse du serveur, il va simplement renvoyer le segment. Et voilà.
2e situation : disparition d'un segment.
- Côté récepteur : on ne valide pas le SEGMENT puisqu'on ne l'a pas reçu !
- Côté émetteur : après un certain temps sans réponse du serveur, il va simplement renvoyer le segment. Et voilà.
12 - Fiabilité de transmission mais aucune garantie temporelle
Que devez-vous connaitre sur TCP au final ?
- Rôle de TCP : permettre et garantir la transmission des communication entre les programmes
- Adresse identifiant un programme : le PORT.
- Information transmise : un segment composé
- De quelques octets formant l'en-tête TCP
- D'un sous-message issu de la découpe du message de base
Cliquer sur le message Req pour visualiser le déroulement de la communication.
Atout de TCP : la fiabilité de la transmission
TCP permet de garantir la fiabilité de la transmission par le contrôle des paquets, la vérification de leur bonne réception et l'émission multiple s'il le faut. TCP gère ces deux problèmes :
- Segment corrompu (somme de contrôle + acquittement)
- Segment disparu (acquittement)
Défaut de TCP : aucune garantie temporelle
Pour garantir cette fiabilité, le protocole doit réguliérement émettre et réemettre des segments. Il n'y a donc aucune garantie temporelle avec ce protocole. La communication va aboutir mais on ne peut pas imposer de temps minimum de transmission.
On ne peut pas tout avoir non plus !
Protocole UDP
Le User Datagram Protocol est l'autre grand protocole de la couche transport.
A la différence de TCP, il ne vérifie et ne contrôle pas la bonne réception du flux de communication. Ici, pas d'acquittement et autres. On envoie vite et c'est tout (ou presque).
On l'utilise beaucoup lorsque la vitesse de transfert est plus importante que l'exactitude du signal.
Dans le vocal par exemple : il vaut mieux manquer un micro-bout de la communication que de créer un écart grandissement entre les paroles des deux personnes (ou plus) qui communiquent.
4 - Vue d'ensemble de la communication
Si on résume une communication Web (dans le sens de l'émission), nous allons retrouver le principe de "une fonction-une tâche" en version "une couche-une tâche" :
Un programme CLIENT veut envoyer une REQUETE.
Il ne sait pas faire cela seul :
- Il fait appel à la couche APPLICATION.
Couche APPLICATION
- Mission : permettre une communication sans ambigüité entre deux programmes partageant un même protocole.
Elle doit donc
- formuler la communication en respectant le protocole demandé : ok
- envoyer le message à l'autre programme : ne sait pas faire seule
- APPLICATION fait appel à TRANSPORT.
Couche TRANSPORT
- Mission : identifier les programmes et permettre le transport simultané de messages entre tous les programmes
Elle doit donc
- identifier les programmes : utilisation du PORT.
- segmenter le message : alternance en divisant le message en sous-messages.
- distinguer les communications : encapsulation dans un SEGMENT.
- si protocole TCP : garantir la bonne transmission en gérant
- un système d'accusés de réception : ok
- un système de somme de contrôle : ok
- émettre les SEGMENTS : ne sait pas faire seule
- TRANSPORT fait appel à la couche RESEAU également nommée INTERNET.
5 - FAQ
C'était quoi le Little Endian ?
Vous avez vu qu'on peut encoder un entier naturel supérieur à 255 en utilisant plusieurs octets.
Oui, mais quel est celui qu'on doit multiplié par 256 lorsqu'on en a deux.
Si on vous donne 90 120 , vous allez faire ceci si on ne vous donne pas d'information supplémentaire.
N = 90 * 256 + 120.
N = 23160
Cette façon de considérer que le premier octet est celui qu'on doit multiplié par le plus grand coefficent est nommée BIG ENDIAN.
En LITTLE ENDIAN, on obtient d'abord l'octet de poids faible..
Les mêmes octets reçus 90 120 en Little Endian, auraient alors été décodés de cette façon :
N = 90 * 1 + 120 * 256
N = 30810
On envoie toujours qu'un segment à la fois ?
TCP sait également gérer la vitesse de communication et peut permettre au serveur et au client de négocier l'envoi de plusieurs segments à la suite plutôt que par séquence envoi-acquittement-envoi-acquittement...
Regardons ce qui pourrait alors se passer : le serveur envoie les deux segments Rp1 et Rp2 de la réponse HTTP au client. Mais le segment Rp1 n'arrive pas.
Le TCP côté-client ne peut pas acquitter le segment 2 puisqu'il n'a pas reçu le segment 1. Que va-t-il se passer
La réponse est simple en réalité : le client ne va pas acquitté le segment 2 puisqu'il n'a pas reçu le segment 1. Du coup, au bout du temps d'attente maximum entre émission et réception de l'accusé de réception, le côté-serveur va renvoyer le segment 1.
Et si le segment 1 arrive plus tard que le 2 ?
Le premier segment n'est pas perdu. Il arrive juste en retard mais avant le délai d'attente maximum.
Que va-t-il pouvoir se passer au niveau des acquittements cette fois ? Le serveur va-t-il devoir renvoyer le segment 2 ?
Le client va simplement acquitter le segment 1 et 2 d'un coup en envoyant ACK SUI 3 pour dire : je veux bien le segment 3 s'il existe..
Du coup, l'acquittement des segments 1 et 2 arrive bien avant le délai d'attente maximum. Comme le client acquitte avec ACK 3, c'est bien qu'il a reçu les segments 1 ET 2.
J'en entendu parler d'une histoire de poignées de main, c'est quoi ?
Il s'agit du tout début de la connexion. Les deux ordinateurs doivent se mettre d'accord avant de parler. Ils doivent s'échanger des informations qui leur permettra de savoir où ils en sont. Dans notre version simplifiée, c'est un peu inutile mais voici le principe.
Nous avons d'abord besoin d'un nouveau drapeau :
- Un drapeau SYN pour synchronisation. Ce drapeau veut dire qu'on demande à l'interlocuteur s'il veut discuter. C'est l'équivalent de "On peut parler ?".
L'échange commence par l'établissement d'une connexion qui se fait en trois temps ou trois poignées de main :
- Le client envoie un segment contenant le drapeau nommé SYN levé pour demander l'ouverture de la communication
- Le serveur renvoie au client
- un drapeau SYN pour demander à son tour au client d'ouvrir la communication et
- un drapeau ACK associé à SUI 1 pour acquitter du segment initial et dire qu'il veut bien du premier segment de données.
- Le client renvoie alors un accusé de réception pour le segment initial envoyé par le serveur et dire qu'il veut bien la suite : ACK et SUI 1.
En gros, le client dit "Serveur, tu veux bien commencer à discuter (SYN) ?"
Pour la suite des explications, les segments ne contenant qu'un en-tête ne seront représentés que par la flèche.
Le serveur dit "J'ai bien reçu ton segment initial et je veux bien recevoir le premier segment maintenant (ACK 1). Est-ce toujours ok pour toi client (SYN) ?"
A partir de là, la connexion est établie : le client peut envoyer sa REQUETE (certainement dans un seul segment si elle ne contient pas grand chose).
6 - QCM
En cours de traitement.
Activité publiée le 19 03 2020
Dernière modification : 15 05 2021
Auteur : ows. h.