SNT Internet

Identification

Infoforall

2 - Protocole TCP


Nous allons aujourd'hui voir un peu plus dans le détail le principe de l'un des protocoles d'Internet : le protocole TCP.

Evaluation ✎ : questions 01-02-03-04-07-08-09-14

Documents de cours :

Attention, cette activité remplace une activité debranchée nommée "le routage élastique". Difficile de faire du débranché en ce moment...

1 - Couche Application

Commençons par une opération basique à priori : la communication entre deux programmes : la connexion de votre navigateur sur un site Web.

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Le navigateur lance une requête http (un texte écrit de façon très précise) et le navigateur lui répond avec une réponse http (un texte écrit de façon très précise également, notamment le corps du message qui est tout simplement le code html de la page).

A titre d'exemple, voici la réquête HTTP que mon serveur a reçu lorsque vous avez demandé à afficher cette page :

Texte de la requête reçue :

GET /act/snt/le-protocole-tcp/ HTTP/1.1
Host: www.infoforall.fr

User-Agent: CCBot/2.0 (https://commoncrawl.org/faq/)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: br,gzip
Connection: Keep-Alive
X-Real-Ip: 18.207.98.97
Via: 1.1 alproxy
X-Forwarded-Proto: https


BODY VIDE !
FIN DE LA REQUETE

Regardons surtout les deux premières lignes

GET /act/snt/le-protocole-tcp/ HTTP/1.1
Host: www.infoforall.fr

Méthodes GET et POST

Pour transmettre des informations à un serveur HTTP, nous avons vu qu'il existe deux méthodes possibles :

  • La méthode GET :
    • on transmet toutes les informations directement dans l'URL
    • on utilise donc cette méthode uniquement pour transmettre un nombre limité de données
    • on ne l'utilise jamais pour transmettre un mot de passe, même si le protocole est HTTPS ! La communication est cryptée mais le mot de passe va néanmoins apparaître dans la barre du navigateur : en regardant l'écran de quelqu'un on peut alors facilement dérober le mot de passe !
  • la méthode POST :
    • on transmet la majorité des données dans le corps du message : c'est que vous faites lorsque vous envoyez une commande sur un site de vente en ligne.

✎ 01 QCM : La requête que vous avez effectué pour visualiser cette page est-elle une requête 

  • A : GET
  • B : POST
  • C : HEAD
  • D : PUT

✎ 02 QCM : Sur la fin de la première ligne de la requête se trouve la version du protocole HTTP utilisé pour formaliser la requête. Quelle version HTTP le serveur distant devra-t-il utiliser pour décoder correctement votre requête 

  • A : 0.9
  • B : 1.0
  • C : 1.1
  • D : 2.0

✎ 03 Quel est le nom du serveur distant (Host) qu'on tente de joindre ?

✎ 04 En regardant les lignes sous la ligne du GET, on trouve l'ensemble des en-têtes que votre navigateur a envoyé au serveur ou que le serveur a récupéré d'une manière ou d'une autre. Est-ce une communication utilisant http ou https ? Trouvez la ligne comportant une indication sur la nature http ou https dans la demande. Fournir la ligne et le protocole utilisé.

On notera que le serveur récupère également des informations qui seront rajoutées ensuite. Notamment votre adresse IP : ce que j'affiche sur cette page est une partie de l'en-tête reçu par le serveur. On y trouve surtout X-Real-Ip qui contient l'IP ayant à priori fait la requête HTTP initiale.

Et que vous a répondu le serveur ?

Nous avons vu dans la partie Web qu'on peut observer les réponses en utilisant les outils de développement des navigateurs Web.

Vous pouvez le faire avec le votre si vous vous souvenez comment atteindre l'observateur des communications réseaux de votre navigateur. Attention, il faudra relancer la page.

05° Dans Firefox, activer le menu, choisir Développement Web puis réseau :

Accès à l'outil Réseau

Relancer alors votre page.

Un exemple de réponse http possible :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 36435
Vary: Cookie
Via: 1.1 alproxy
Date: Thu, 19 Mar 2020 12:54:47 GMT

<!DOCTYPE html... : la suite, c'est le fichier html !

✎ 06° On voit que le serveur répond avec un code 200. C'est pour dire que la requête s'est bien passé ou qu'il y a eu un problème ?

Couche TRANSPORT Protocole : TCP (et +) Adresse : PORT Message : SEGMENT DATA d'un programme SEGMENT TCP Port SRC 443 Port DST 2050 Seq 4 Suiv 2 Flags : ACK CS : 15241 PAQUET IP IP DST 25.25.25.5 IP SRC 45.45.45.2 TRAME (Ethernet ou Wifi) SEQUENCE INTIALE MAC DST MAC SRC CheckSum selon le type de trame Couche RESEAU Protocole : IP (et +) Adresse : IP Message : PAQUET Couche LIAISON Protocole : WLAN ... Adresse : MAC Message : TRAME Couche Application Firefox Couche Application Serveur HTTP Communication prog A Comm. prog B A B Rq TCP Rp1 TCP Rp2 TCP vide TCP Ack4 TCP ? A TCP IP Trame B TCP IP Trame data SRC 2050 DST 443 Seq data SRC 24945 DST 443 Seq data SRC DST CS data Seq Suiv F vide Seq Suiv F SRC 2050 DST 443 F ACK Suiv 2 Seq 1 CS XXXXX

Nous avons donc vu comment deux programmes parviennent à communiquer, ici est se transférant un simple texte.

Tout est simple et limpide mais ... les deux programmes ne tournent pas du tout sur le même ordinateur.

Comment font-ils pour parvenir à communiquer du coup ?

La réponse dans les parties suivantes.

2 - Couche Transport

Si vous êtes sur cette page, vous avez certainement ceci dans la barre de navigation :

https://www.infoforall.fr/act/snt/les-protocoles-tcp-et-ip/

Nous avons donc :

  • Le protocole : https
    • https://www.infoforall.fr/act/snt/les-protocoles-tcp-et-ip/
  • Le nom du serveur à joindre www.infoforall.fr
    • https://www.infoforall.fr/act/snt/les-protocoles-tcp-et-ip/
  • L'adresse absolue de la ressource : /act/snt/les-protocoles-tcp-et-ip/
    • https://www.infoforall.fr/act/snt/les-protocoles-tcp-et-ip/

Et c'est tout ? Comment fait Firefox pour signaler qu'il veut discuter avec le programme-serveur HTTP ? Ca encore, on peut se douter qu'avec le nom du protocole dans l'URL, on peut se débrouiller. Mais surtout, comment fait le serveur HTTP pour savoir à quel programme répondre sur votre ordinateur. Ils sont nombreux à tourner en même temps.

Et la réponse est : en attribuant à tous les programmes voulant communiquer une adresse portant le nom de PORT.

Et la couche se chargeant de gérer les communications de l'extérieur vers les programmes se nomme la couche TRANSPORT dans la mesure où elle transporte les communications d'un programme à un autre.

Si vous vous souvenez un peu de votre cours Web, vous avez peut-être le souvenir qu'on peut rajouter ce fameux port derrière le nom du serveur en utilisant un double point :.

Pour joindre le PORT 80 (l'adresse qu'on choisit habituellement pour un programme-serveur HTTP) d'un ordinateur, il faut taper ceci :

https://www.infoforall.fr:80/act/snt/les-protocoles-tcp-et-ip/

Pour joindre le PORT 443 (l'adresse qu'on choisit habituellement pour un programme-serveur HTTPS) d'un ordinateur, il faut taper ceci :

https://www.infoforall.fr:443/act/snt/les-protocoles-tcp-et-ip/

Pourquoi ne pas avoir eu besoin de taper le 443 dans la barre d'adresse ? Simplement car le navigateur va rajouter la valeur par défaut lors de l'envoi de la requête si on ne lui précise rien.

✎ 07° QCM : Que va rajouter le navigateur si on tape ceci :

http://monsite.com

  • A : http://monsite.com:8000
  • B : http://monsite.com:80
  • C : http://monsite.com:443
  • D : http://monsite.com:PORT

Le PORT est donc une adresse identifiant un programme sur un ordinateur identifié lui par son adresse IP. Le PORT est un simple nombre entier allant de 0 à 65535.

Les programmes-serveurs courants bénéficient d'un PORT inférieur à 1024.

Et que vaut le PORT qui identifie votre navigateur lorsque vous lancer une requête ? L'ordinateur lui attribue un numéro aléatoire (non attribué à ce moment sur cet ordinateur) entre 1024 et la valeur maximale.

✎ 08° Ouvrir un onglet vers une page permettant de faire une recherche d'IP. Par exemple http://www.mon-ip.com/. Ecrire votre adresse IP publique et le port sous lequel le site identifie votre instance de navigateur. Attention, votre adresse IP peut être une adresse IPv4 (de type 80.80.80.80)ou IPv6 (de type 8F:8F:8F:8F:8F:8F:8F:8F)

En réalité, lorsqu'un programme veut communiquer avec un programme extérieur, il utilise un autre programme dont la mission est de réaliser cette communication. Ce programme de communication fait partie de ce qu'on nomme la couche TRANSPORT.

.
Couche TRANSPORT

Lorsqu'un programme veut communiquer, il envoie donc à la couche TRANSPORT son message et le PORT du programme qu'il veut joindre. Soit 80 pour un serveur en protocole HTTP et 443 pour un serveur en protocole HTTPS.

La couche TRANSPORT se charge donc de transporter les messages d'un programme d'un ordinateur vers un programme d'un autre ordinateur.

Pour cela, il existe plusieurs protocoles de communication.

Les deux plus connus sont

  • UDP : User Datagram Protocol. C'est un protocole de communication rapide car sans vérification de réception des messages. Pratique pour les applications de type temps réel, comme la visioconférence.
  • TCP : Transmission Control Protocol. Comme son nom l'indique, celui-ci intégre une composante de contrôle et vérification des communications. Plus lent qu'UDP mais fiable.

Dans les deux cas, l'adresse utilisée par les protocoles pour identifier et localiser le bon programme à l'intérieur de l'ordinateur est le PORT.

L'intérêt de cette couche est donc que tous les programmes l'utilisent lorsqu'ils veulent communiquer.

Regardons comment fonctionne TCP plus en détails. Il s'agit d'un des deux grands protocoles d'Internet. Le deuxième étant IP. Voilà pourquoi on parle souvent de TCP/IP au sujet d'Internet.

Protocole TCP - la segmentation

Le premier grand intérêt de TCP est qu'il peut segmenter un gros message initial en plusieurs sous-messages si nécessaire.

Pourquoi ?

Imaginons que vous soyez un train de regarder un film en passant par un service en ligne (soit dit en passant, ce n'est pas écologique si vous compter regarder ce film plusieurs fois, autant le regarder sur support fixe). Le film est long, le fichier vidéo est donc long également. Si on téléchargeait tout le fichier en une seule communication, cela voudrait dire qu'on ne pourrait plus rien faire d'autres sur cette ligne en attendant... Voir les emails, non ? Non. Ouvrir une page Web ? Non. Pour que la communication du programme B puisse se faire, il faut attendre que la communication du programme A soit finie...

La solution ? Décomposer la communication en petits messages et envoyer les messages et gérer l'alternance lorsque plusieurs programmes veulent communiquer sur le même créneau.

7 6 5 4 3 2 1 4 3 2 1

Cela permet d'alterner entre les messages de plusieurs applications et ainsi de permettre à plusieurs applications de communiquer en 'même temps'.

1 2 3 4 5 6 7 1 2 3 4

Ensuite, on les envoie en fonction des besoins. Initialement, le programme A est seul à vouloir communiquer : on envoie ses messages à la suite. Vient ensuite une comunication de B : on a alors une alternance (par exemple) entre les deux.

A l'émission, TCP et la couche TRANSPORT se chargent donc de décomposer les communications des applications pour en faire des messages numérotés. Ensuite, des algortihmes tournent pour donner la priorité à tel ou tel message.

Par contre, si on ne fait que cela, on va avoir un problème : les étiquettes sont visibles à l'écran mais il n'y a aucune information réeelle de numérotation (1,2,3..) ou d'identité de l'émetteur (A ou B) sur les messages.

A l'écran :

1 2 3 4 5 6 7 1 2 3 4

En réalité :

Donc pas moyen de savoir qui envoie quoi et dans quel ordre on doit les placer à la réception.

Pour garantir la transmission et la possibilité de leur remettre dans le bon sens, nous allons rajouter des informations autour du message. Et ce nouveau message, plus complet, sera nommé un segment TCP.

Il ne s'agit pas ici d'examiner en détails les vrais segments TCP. Un segment réel possède un peu plus d'informations que celles présentées ici.

Protocole TCP - création des segments

Que doit-on rajouter au minimum à chaque message ?

Nous allons rajouter un en-tête TCP que nous allons placer devant le sous-message que nous voulons transmettre :

  • le PORT SRC source : celui du programme émetteur, sans lui l'ordinateur-récepteur ne saura pas à quel programme répondre ! Prenons ici l'exemple d'un programme-émetteur dont le PORT SRC serait 2050.
  • Remarque : vous pouvez zoomer en cliquant sur les segments, ou utiliser CRTL + comme d'habitude.

    1
  • le PORT DST destination : celui du programme-récepteur qu'on veut joindre. Sans lui, l'ordinateur-récepteur ne sera pas auquel de ses programmes le message est destiné. Ici, on veut se connecter à un serveur en https : 443. Sinon, c'est 80 pour du http classique.
  • 1
  • Un système de numérotation de séquences (Seq) pour signaler au destinataire la place du segment dans l'ensemble.
  • 1
  • Un système d'accusés de réception (Suiv) pour signaler quel paquet suivant on veut bien recevoir. Exemple : si ACK vaut 3, cela veut dire qu'on a déjà reçu les segments 1 et 2 et qu'on veut bien le 3.
  • 1

Le segment précédent veut donc dire que le programme de PORT 2050 à un segment numéroté 1 pour le programme de PORT 443 et que 2050 est prêt à recevoir le segment numéro 2 de 443 s'il en a un.

Et voilà pour l'essentiel. Nous allons rajouter d'autres informations dans ce header (en-tête) dans les questions suivantes. Par la suite, nous représenterons parfois uniquement le header TCP sous la forme d'un petit rectangle jaune-orangé noté TCP.

Voici donc le résultat des transformations des communications envoyées par les applications à la couche TRANSPORT : on crée une multitude de petits segments TCP incorporant les ports SRC et DST. Maintenant, on peut connaitre la destination et l'origine de chaque segment :

Sur les segments ci-dessus, je n'ai pas placé d'accusés de réception mais ils existent. Au pire sur une valeur de 1 pour dire qu'on est prêt à recevoir le premier segment.

Si vous voulez augmenter la taille affichée des segments pour voir le contenu de l'en-tête, cliquez dessus.

1 2 3 4 5 6 7 1 2 3 4

✎ 09° 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 ?

4

Question supplémentaire : quel est le numéro de ce segment ?

Pour information, les indications fournies dans le header TCP sur la représentation du segment sont :

  • SRC 24945
  • DST 443
  • Seq 4
Transmission d'un flux via TCP

TCP permet donc de gérer les flux.

Le principe est simple :

  • Si on reçoit un segment, et on lit le numéro du segment. Si on a bien reçu tous les segments précédents, on envoie le message à la couche APPLICATION et on renvoie un segment-accusé de réception avec une valeur juste supérieure : on renvoie 3 pour indiquer qu'on a bien reçu les segments 1-2 et qu'on veut bien le 3e maintenant.
    • Exemple : Le côte de droite a déjà recu les segments 1-2. Cela veut dire également qu'il a renvoyé un accusé de réception 3 au côté gauche. Le côté gauche envoit alors le segment 3. Le côté droit reçoit et renvoie un segment accusé de réception portant le numéro 4 (pour dire qu'il a bien reçu 1-2-3).
    • 3 3 3 3 4 4 1 2 3
  • Si on reçoit un segment sans avoir encore reçu l'un des segments antérieurs, on stocke et on attend le segment qui manque avant d'envoyer celui qu'on vient de recevoir.
    • Exemple : on a déjà reçu les segments 1-2. Cela veut dire également qu'on a renvoyé un accusé de réception 3 au côté gauche. On reçoit le segment 4. Action : on ne transmet pas au programme et on envoie pas d'accusé de réception. On attend juste le 3.
    • 4 4 4 4 3 4 4 3 1 2
  • Dans ce cas, la couche TRANSPORT de gauche va attendre l'accusé de réception pendant un certain temps. Une fois le temps d'attente dépassé, on va renvoyer le segment 3 et le segment 4 puisque le dernier acquittement qu'on a eu en provenance était un ACK 3.

10° On reprend la dernière configuration : Le PORT 443 a reçu des segments 1 et 2 du PORT 2050 et le segment 4 est en mémoire, en attente de transfert. 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 ?

...CORRECTION...

Non car le nouveau segment est bien un segment identifié 3 mais il ne provient pas de la source 2050 : ce n'est donc pas le segment à placer devant l'autre !

11° Encore un nouveau segment qui arrive au serveur.

  • 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 DST 2050 sont transférés au programme-serveur 443.

D'abord le segment 3 qui vient d'arriver puis le segment 4 qui été en mémoire.

Si on veut visualiser la suite de la transmission, le programme serveur reçoit finalement toute la REQUETE :

1 2 3 4

Le serveur HTTP n'a plus qu'à créer la REPONSE et ... ça repart dans l'autre sens !

  • Envoi de la réponse par le programme-serveur à sa couche TRANSPORT.
  • Segmentation de cette réponse (il y a donc inversion des valeurs des PORTS SRC et DST)
  • Réception des segments par la couche TRANSPORT de gauche
  • Désencapsulation des sous-messages et transmisson des messages à l'instance de Firefox (qu'on retrouve cette fois à l'aide de la valeur PORT DST du coup).

12° QCM : L'instance de Firefox est 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.

Une communication entre votre navigateur et un serveur HTTP est donc un va-et-vient de ce type entre les deux programmes :

  • l'un des programmes envoie par sa couche TRANSPORT un segment contenant le PORT source (SRC), le PORT destination (DST), la place du segment dans l'ensemble (Seq) et un numéro d'acquittement pour signaler quel segment il est prêt à recevoir.
  • L'autre couche TRANSPORT reçoit les segments et fournit à chaque fois un segmen t-accusé de réception portant le numéro du segment suivant qu'il est prêt à recevoir.

Imaginons le déroulement d'une communication lorsque vous demandez une page.

La requête http tient sur 1 segment.

La réponse http tient sur 3 segments.

Voici déjà une image avec simplement deux segments en retour :

13° Cliquer sur la requête Req en bleue de façon à lancer l'animation et voir le transfert des segments de données et d'accusés de réception (attention, je n'ai mis que deux segments-réponses dans cette animation).

Rep http Rep TCP Req TCP ACK TCP

Déroulement

  1. Le navigateur envoie sa requête vers sa couche TRANSPORT.
  2. TCP-client crée un segment 1.
  3. TCP-client envoie le segment 1.
  4. TCP-serveur reçoit le segment 1.
  5. TCP-serveur acquitte ce segment avec un accusé de réception à 2
  6. TCP-client reçoit l'accusé de réception : il supprime le segment 1 de sa mémoire
  7. TCP-serveur envoie le segment vers le programme-serveur
  8. Le programme-serveur reçoit la requête.
  9. Le programme-serveur envoie sa réponse http à sa couche TRANSPORT.
  10. TCP découpe la réponse en créant 3 segments
  11. TCP-serveur envoie le segment 1
  12. TCP-client reçoit le segment 1.
  13. TCP-client acquitte ce segment avec un accusé de réception à 2
  14. TCP-serveur reçoit l'accusé de réception : il supprime le segment 1 de sa mémoire et envoie le segment 2.

Même explications mais en image :

SEQ 1 + ack 1 Data 1 (la requête http) ACK 2 + Data vide SEQ 1 + ack 2 Data 1 (la réponse http) ACK 2

14° Que va faire la couche TRANSPORT du côté serveur maintenant qu'elle a reçu un accusé de réception à 2 ?

...CORRECTION...

La couche TRANSPORT du serveur va envoyer le segment 2 puisqu'il vient de recevoir un accusé de réception à 2 : cela veut dire que le client a bien reçu le premier segment et qu'il veut le deuxième.

✎ 15° Compléter la séquence de communication jusqu'à ce que le côté-client ai bien envoyé un accusé de réception à 4 pour indiquer qu'il avait bien reçu les segments 1-2-3.

Comme vous l'avez compris, si un segment est perdu et que l'autre côté ne le reçoit jamais, il va se passer une chose simple :

  • Le récepteur ne va pas envoyer d'accusés de réception (normal, il n'a rien reçu)
  • L'émetteur va attendre puis décider de renvoyer le segment !

Et voilà comment les communications peuvent être rendues fiables. Par contre, on ne peut pas garantir que les segments arrivent en temps et en heure. Les applications de type vocale ou visuelle en temps réelle travaillent donc avoir d'autres protocoles, moins fiables mais plus rapides.

3 - FAQ

Pas de question pour le moment

La prochaine activité traitera donc du transfert des paquets IP de routeurs en routeurs.

En effet, si on doit résumer Internet en deux mots, on dirait TCP / IP.

TCP rend la communication fiable.

IP rend la communication possible si elle l'est !

Activité publiée le 30 03 2020
Dernière modification : 06 04 2020
Auteur : ows. h.