Archi TCP/IP Couches

Identification

Infoforall

4 - Communication TCP


Nous allons aujourd'hui voir un peu plus dans le détail le principe d'une communication Web et son passage sur le réseau Internet.

Cette activité spécifique se concentre sur la communication entre votre navigateur (attention au choix, ce n'est pas innocent) et un serveur Web distant.

Cette activité intégre pas mal de choses à lire et à comprendre. Bon nombres de ces choses sont des rappels ou des prolongements du cours de SNT sur le Web. Bien entendu, tout est noté en détails néanmoins pour ceux qui auraient raté des bouts.

Evaluation ✎ : questions 01-02-03-04-13-14-15-19-23-24.

Documents de cours :

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

Quel est le type de données envoyées par votre navigateur ? Du texte.

Ou plutôt une suite d'octets encodant une chaîne de caractères en ASCII. Pour A, l'octet vaut 6510 ou 4116, pour B c'est 6610 ou 4216...

...ASCII...

Table ASCII en version hexadécimale
_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
0_ NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI _0
1_ DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 1_
2_ !"#$%&'()*+,-./ 2_
3_ 0123456789:;<=>? 3_
4_ @ABCDEFGHIJKLMNO 4_
5_ PQRSTUVWXYZ[\]^_ 5_
6_ `abcdefghijklmno 6_
7_ pqrstuvwxyz{|}~DEL 7_
_0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F

Lorsque vous avez lancé cette page, votre navigateur a fait la demande suivante dans votre barre de navigation :

https://www.infoforall.fr/act/archi/communication-tcp-ip/

Vous allez voir ci-dessous le texte que le site a reçu lorsque vous avez lancé votre requête le sam 15 Aoû 2020 à 14:36 pour afficher cette page. On remarquera d'ailleurs qu'on doit surveiller les heures : à cause des heures d'été, des fuseaux horaires peut-être différents, de leurs gestions ou pas, de l'utilisation du temps universel sur les serveur,... il peut y avoir un décalage entre l'heure réelle affichée chez le client et l'heure de réception affichée.

J'ai rajouté les passages à la ligne (représentés ici par , code ASCII 1010 ou 0A16) qui sont les caractères séparateurs entre les informations transmises.

Texte de la requête reçue :

GET /act/archi/communication-tcp-ip-couches/ 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.108.191
Via: 1.1 alproxy
X-Forwarded-Proto: https


BODY VIDE !
FIN DE LA REQUETE

Regardons surtout les deux premières lignes

GET /act/archi/communication-tcp-ip-couches/ HTTP/1.1
Host: www.infoforall.fr

Méthodes GET et POST

Pour transmettre des informations à un serveur HTTP, 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, souvent liées à un affichage configurable : uniquement les chaussures de telle marque, uniquement la page 12...
    • 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 vos copies numériques : vous avez dû vous rendre compte que vos réponses n'apparaissent pas dans l'URL.

Pour informations, sachez qu'il existe aussi des requêtes :

  • HEAD : permet de ne recevoir que l'en-tête d'une page, pas le corps du message en lui-même : ça permet de savoir si une page existe, a été mise à jour ...
  • DELETE : permet de supprimer une ressource sur le serveur
  • PUT : permet de placer une ressource sur le serveur

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

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

Accès à l'outil Réseau

06° Relancer la page https://www.infoforall.fr/act/archi/communication-tcp-ip/ sur laquelle vous êtes actuellement.

Remonter en haut des fichiers que vous venez de télécharger : vous devriez tomber sur un fichier HTML.

Quel est le code obtenu sur la plupart des fichiers ?

  • 200 pour dire que la réponse s'est bien passée
  • 304 pour signaler que le fichier demandé n'a pas été modifié depuis la dernière demande
  • 404 pour signaler que la requête n'a pas pu aboutir
  • 500 pour signaler que le serveur rencontre un problème

Parvenez-vous à reconnaitre d'autres types de fichiers parmi les fichiers affichés ?

...CORRECTION...

Sur le visuel, on voit que le premier document est un document de type HTML.

Le code 200 permet d'indiquer que la requête et la réponse se sont bien déroulées. Tout est ok.

On voit que le navigateur a fait plusieurs demandes :

  • D'abord le fichier HTML
  • Ensuite deux fichiers CSS
  • Ensuite des images

Voici un visuel des choses qu'on peut obtenir avec https://www.infoforall.fr :

Résultats d'une requête

Nous verrons plus tard comment le navigateur sait quels fichiers demandés en plus du premier fichier HTML recu. Ne vous posez pas trop de questions pour le moment.

07° Cliquer sur la première ligne : celle du fichier HTML. Vous devriez obtenir un affichage proche de celui présenté ci-dessous.

Détails d'une requête

08° En regardant le détail de la demande, répondre aux questions suivantes :

  • Avez-vous effectué une requête de type GET (obtenir du serveur) ou de type POST (envoyer/poster des informations au serveur) ?
  • Quelle est l'adresse IP (adresse numérique) du site joignable par www.infoforall.fr ?
  • Le port 443 est-il bien compatible avec une liaison à un serveur HTTPS ou un serveur HTTP ?

...CORRECTION...

Nous avons fait une requête de type GET : on veut juste recevoir des informations (et au pire en fournir quelques unes peu nombreuses)

L'adresse IP du site est notée : [2a00:b6e0:1:20:2::1]:443.

Nous avions vu que le port 80 est le port des serveurs HTTP et 443 le port des serveurs HTTPS.

09° Cliquer sur le bouton En-têtes brutes de la REPONSE de façon à voir le contenu de l'en-tête telle que le navigateur l'a reçu avant de vous le remettre en forme. Vous devriez constater qu'il s'agit bien d'un simple contenu texte.

Un exemple de réception 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 !

10° Descendre encore un peu plus bas : activer également En-têtes brutes mais cette fois sur l'en-tête de la REQUETE que votre navigateur a réellement envoyé. Comme vous pourrez le voir, nulle trace à ce moment de votre adresse IP : sur l'en-tête reçu par le site, c'est bien qu'on a rajouté l'information à un moment.

Un exemple de requête :

Host: www.infoforall.fr
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://www.infoforall.fr/act/archi/composition-de-portes-logiques/
Connection: keep-alive
Cookie: _ga=GA1.X.XXXXXXXXXX.XXXXXXXXX;
_pk_id.XXXXX.XXX=XXXXXXXXXXXXXXXX.XXXXXXXXXXXXX;
_pk_ref.XXXXXXX; csrftoken=XXXXXXXXXx
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

11° Faire une demande inconnue comme https://www.infoforall.fr/ast/snt/historique-du-webeeux/. Comment le navigateur va-t-il savoir que quelque chose s'est mal passé ? Quelle est le numéro de la réponse cette fois ?

Erreur 404

...CORRECTION...

Il s'agit de la fameuse erreur 404 !

Lorsque le navigateur reçoit une réponse http de ce type du serveur, il sait que le serveur lui dit que sa requête n'a pas pu aboutir pour une raison simple : la ressource demandée n'existe pas ! La plupart du temps, il s'agit d'une ressource qui a existé mais qu'on a supprimé du serveur.

La plupart des sites proposent des pages 404 personnalisées.

12° Faire la requête inconnue suivante sur le site de blizzard :

https://www.blizzard.com/fr-fr/testrate/.

Répondre ensuite aux questions suivantes :

  • Quel protocole a été utilisé ?
  • Quel est le nom du serveur à contacter ?

...CORRECTION...

  • Quel protocole a été utilisé ? https
  • Quel est le nom du serveur a contacté ? www.blizzard.com
  • Quelle est la requête demandée à ce serveur ? /fr-fr/testrate/
  • Quel est son IP ? 52.50.176.12:443 au moment où moi j'ai fait le test
  • Quel est le numéro de sa réponse ? 404 !
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 ? 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 0 Seq 1 CS XXXXX

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

Tout simple limpide et simple 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/archi/communication-tcp-ip-couches/

Nous avons donc :

  • Le protocole : https
    • https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
  • Le nom du serveur à joindre www.infoforall.fr
    • https://www.infoforall.fr/act/archi/communication-tcp-ip-couches/
  • L'adresse absolue 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 ? 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 de SNT, vous avez peut-être vu 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/archi/communication-tcp-ip-couches/

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/archi/communication-tcp-ip-couches/

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.

✎ 13° 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 une adresse stockée à l'aide de 16 bits (2 octets).

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.

✎ 14° QCM : Avec 16 bits, que vaut la valeur maximale des PORTS ?

  • A : 216, soit 65536
  • B : 216 - 1, soit 65535
  • C : 162, soit 256
  • D : 162 - 1, soit 255

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. Ici, nous n'allons voir que le principe général et le bit alterné pour "garantir" la transmission dans le bon ordre. Si vous voulez en savoir plus, vous pouvez aller vous renseigner sur Internet ou aller voir les fiches à ce sujet sur ce site (si j'ai eu le temps de les mettre en ligne, c'est pas gagné !).

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 (2 octets) : 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 (2 octets): 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, 2 octets) pour signaler au destinataire la place du segment dans l'ensemble. Remarque : dans le vrai TCP, ce n'est pas juste un numéro de segment : cette valeur permet de connaitre le nombre d'octets transmis. Ici, on simplifie.
  • 1

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 :

  • Les deux premiers octets du segment encodent le PORT SRC.
  • Les deux octets suivants encodent le PORT DST
  • ect ...

Et ce sont donc ces segments (header TCP + sous-message) qui sont transportés d'une couche TRANSPORT à une autre couche TRANSPORT.

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

✎ 15° 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 que tous les segments antérieurs ont bien été délivrés au destinataire, on désencapsule et on envoie le message au programme.
    • Exemple : on a déjà recu et envoyé au programme DST les segments 1-2. On reçoit le segment 3. Action : on transmet au programme DST.
    • 3 3 1 1 2 2 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 le stocke et on attend de recevoir le segment manquant.
    • On a déjà reçu et envoyé les segments 1-2. On reçoit le segment 4. Action : on ne transmet pas. On attend le 3.
    • 4 4 4 4 1 2 3 4 4 3 2 1 1 2

16° 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 ?

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

17° 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 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).

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

Petit rappel sur la façon d'encoder un entier supérieur à 255 sur deux octets.

Grands entiers en Big Endian

Lorsqu'on veut encoder un entier supérieur à 255, nous sommes obligés de prendre au moins deux octets.

Exemple : on code un nombre entier avec les octets suivants : 90 120.

En Big Endian, on considère que lors de la lecture, on obtient d'abord l'octet de poids fort.

Le nombre encodé sur les deux octets 90 120 en Big Endian est donc
N = 90 * 28 + 120 * 1
N = 90 * 256 + 120 * 1
N = 23160.

En Little Endian, on considère que lors de la lecture, on obtient d'abord l'octet de poids faible.

Avec 90 120 lu en Little Endian, on aurait eu
N = 90 * 1 + 120 * 256
N = 30810

✎ 19° on veut transmettre un PORT destination de 443. On transmet alors les octets suivants (en big endian) 001 187. Vérifiez s'il s'agit bien du port 443. Justifiez votre résultat.

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 les segments contenant les informations permettant d'identifier le programme-émetteur (SRC, sur 2 octets), le programme-récepteur (DST, sur 2 octets) et la place du segment dans l'ensemble (Seq, sur 2 octets). L'autre reçoit les segments et fournit à son tour une réponse en inversant bien entendu les valeurs placées dans SRC et DST.

Dans la partie suivante, nous allons voir comment TCP parvient à détecter les erreurs de transmission et comment il parvient à faire face aux éventuelles pertes de segments sur le réseau.

3 - Acquittement TCP

Nous avons vu qu'avec la couche TRANSPORT et le protocole TCP nous pouvions découper le message d'un programme en plusieurs segments qu'on peut alors envoyer vers la couche TRANSPORT d'un autre ordinateur. Celui-ci peut alors retrouver le message et le transférer à un programme destinataire.

Comme TCP veut dire Transmission Control Protocol, nous allons maintenant voir :

  • Comment le récepteur parvient à savoir que le segment reçu n'est pas bon (quelques bits ont peut-être été mal interprétés lors du transfert)
  • Comment l'émetteur sait que le segment est arrivé correctement à destination
Rappel - Header TCP

Nous avons vu que l'en-tête (header) TCP qu'on place devant le sous-message comporte déjà :

  • le PORT SRC source (2 octets) : celui du programme émetteur, sans lui l'ordinateur-récepteur ne sera pas à quel programme répondre ! Prenons ici l'exemple d'un programme-émetteur dont le PORT SRC serait 2050.
  • 1
  • le PORT DST destination (2 octets): 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, 2 octets) pour signaler au destinataire la place du segment dans l'ensemble.
  • 1

Nous allons maintenant rajouter encore quelques indications.

  • Un code F de communication (1 octet dans notre version simpliste) : un simple ensemble de drapeau (flag en anglais) encodant quelques informations basiques :
    • ACK (16): ce segment contient un accusé de réception ou acquittement (acknowledgement) (ce qui veut dire "J'ai bien reçu le segment indiqué")
    • PSH (8) : données à envoyer tout de suite sans nécessairement attendre les autres segments (push) (ce qui veut dire "N'utilise pas de mémoire-tampon, transfère vraiment")
    • RST (4) : rupture anormale de la connexion (reset) (ce qui veut dire "Il faut recommencer, ça a coupé !")
    • SYN (2) : demande de synchronisation ou établissement de connexion (ce qui veut dire "On peut parler ?")
    • FIN (1) : demande la fin de la connexion (pour dire "On peut arrêter ?")
    • (18) est à comprendre comme deux drapeaux d'un coup : (2+16), soit SYN et ACK
    1
  • Du coup, un système de numérotation des accusés de réception (Suiv, 2 octets) pour signaler le numéro du segment dont on accuse réception. En réalité, on va même plutôt y placer le numéro du segment suivant qu'on veut bien accepter. Si on acquitte le segment 5, on placera donc 6 dans cette zone pour dire : j'ai bien reçu le 5, envoie le 6 si tu en as un. Sinon, le destinataire ne peut que savoir qu'on a bien reçu un segment, mais lequel ? On va le placer avant Com.
  • 1
  • Un système de contrôle de transmission (CS pour Check Sum, 2 octets) pour vérifier que le message initial est bien le message reçu : certains bits pourraient avoir été inversé (0 en 1 ou 1 en 0) pendant la transmission. Nous verrons le fonctionnement en fin d'activité. C'est un nombre compris entre 0 et 65535 puisqu'on travaille avec deux octets. On notera XXXXX sur tous les exemples mais la valeur change pour chaque segment.
  • 1

Voilà. Il y a encore quelques autres octets dans un header TCP réel mais nous ne les étudierons pas ici. Au total, il y a une vingtaine d'octets au total dans les headers TCP actuellement.

Tiens, pour une fois on va commencer par la fin : le Check Sum.

Ce mécanisme permet à TCP de savoir si le segment qu'il vient de recevoir est valide ou non.

S'il est valide, il l'accepte. Sinon, ben, il le refuse et n'en tient pas compte.

Comment ça marche ?

Le fonctionnement va nous permettre de refaire un peu de révision sur les additions binaires.

Fonctionnement global 

  • L'émetteur réalise un calcul basé sur les bits de son segment. Il insère ce calcul dans le segment (ce sont les 16 bits des deux octets de CS, Check Sum)
  • Le segment est envoyé et reçu
  • Le récepteur réalise à nouveau le calcul sur les bits et vérifie que le CS permet bien d'obtenir le bon résultat (ou pas !)

Côté Emetteur : regardons le calcul du Check Sum du côté de l'émetteur.

  • On réalise des additions binaires en additionnant les 16 bits des octets 1-2 avec les 16 bits des octets 3-4.
  • On continue ensuite avec les 16 bits suivants jusqu'à atteindre la fin du segment.
  • A la fin, on complémente la somme : 0 devient 1 et 1 devient 0 (on parle de complément à 1)

Ces opérations sont longues à faire par un humain mais basiques et rapides pour l'UAL. Voir le cours précédent.

Rappel sur l'addition en base 2
  • 0+0 = 0 en base 2
  • 0+1 = 1 en base 2
  • 1+1 = 10 en base 2
  • 1+1+1 = 11 en base 2 : il y a donc une retenue pour la case de gauche.

20° On considère le cas d'un segment imaginaire à émettre qui ne contient que les ports SRC (2 octets, d'où 16 bits) et DST (16 bits aussi).

1 - Réaliser l'addition sur 16 bits des deux ports (vous pouvez le faire de tête et cliquez sur les _ pour changer l'affichage).

2 - Réaliser le complément à 1 de la somme : c'est le Check Sum

     SRC 443 10   0000 0001 1011 1011 2 
     DST 2050 10   0000 1000 0000 0010 2 
     Somme   ____ ____ ____ ____ 2 
     CS   ____ ____ ____ ____ 2 

...CORRECTION...

 SRC 443 10   0000 0001 1011 1011 2 
 DST 2050 10   0000 1000 0000 0010 2 
 Somme   0000 1001 1011 1101 2 
 CS 63042 10   1111 0110 0100 0010 2 

En inversant via le complément à 1, on obtient donc le check sum suivant :

CS = 1111 0110 0100 0010 2 = 63042 10

Pour obtenir rapidement la valeur en base 10, il suffit de taper ceci dans Python :

>>> int('1111011001000010', 2) 63042

On émet le segment hypothétique précédent qui ne contient donc que 16 * 3 bits.

Contenu binaire réel du segment :

0000 0001 1011 1011 0000 1000 0000 0010 1111 0110 0100 0010

En lisant les 16 premiers bits comme l'entier SRC, les 16 suivants comme DST et les 16 restants comme le CS, on peut en retrouver la signification :

En Base 2  : 0000 0001 1011 1011 0000 1000 0000 0010 1111 0110 0100 0010

En Base 10 : 443 2050 63042

Comme le binaire n'est pas facile à lire pour un humain, on préfèrera donc la représentation suivante :

443 2050 63042

Ou pour ceux qui n'aiment pas la représentation graphique :

Segment : SRC 403 - DST 2050 - CS 63042 - Data None

Côté Récepteur : regardons maintenant ce que va devoir faire le récepteur de ce Check Sum.

Imaginons d'abord que le récepteur a bien reçu le segment précedent, sans altération de bits.

21° Réaliser l'addition des 3 ensembles de 16 bits.

Sachant que sur cet exemple, les 6 octets reçus sont bien les 6 octets envoyés, quelle doit visiblement être la somme du segment si le segment n'a pas été altéré lors du transport ?

Rappel : 1+1+1+1 = 100 en base 2. On retrouve bien que 1+1+1+1 = 4 en base 10.

SRC 443 10 0000 0001 1011 1011 2
DST 2050 10 0000 1000 0000 0010 2
CS  63042 10 1111 0110 0100 0010 2
Somme ____ ____ ____ ____ 2

...CORRECTION...

SRC 443 10 0000 0001 1011 1011 2
DST 2050 10 0000 1000 0000 0010 2
CS  63042 10 1111 0110 0100 0010 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 ne donne pas 1.

Un exemple avec un problème lors de la transmission.

L'émetteur envoie le paquet de droite mais le récepteur reçoit le paquet de gauche.

443 2050 63042 442 2050 63042

Si vous regardez les segments, vous verrez qu'au départ le SCR est bien 443 mais qu'à l'arrivé la SRC vaut 442. Comment est-ce possible ? Et bien, juste un bit qui a mal été interprété.

Segment émis :

En base  2 : 0000 0001 1011 1011 0000 1000 0000 0010 1111 0110 0100 0010
En base 10 : 443 2050 63042

Contenu du segment reçu :

En base  2 : 0000 0001 1011 1010 0000 1000 0000 0010 1111 0110 0100 0010
En Base 10 : 442 2050 63042

Et voilà, tout ça à cause d'un bit mal transmis.

22° Réaliser l'addition des 3 ensembles de 16 bits.

Peut-on détecter qu'il ne s'agit pas d'un segment valide ?

SRC 442 10 ? 0000 0001 1011 1010 2
DST 2050 10 ? 0000 1000 0000 0010 2
CS  63042 10 1111 0110 0100 0010 2
Somme ____ ____ ____ ____ 2

...CORRECTION...

SRC 442 10 0000 0001 1011 1010 2
DST 2050 10 0000 1000 0000 0010 2
CS  63042 10 1111 0110 0100 0010 2
Somme 1111 1111 1111 1110 2

La somme ne donne pas un ensemble de 1 : il y a eu un problème quelque part : le segment n'est pas valide !

Check Sum

Un Check Sum est donc un moyen efficace de détecter qu'il y a eu une altération du message entre l'émission et la réception.

Par contre, on ne peut pas savoir où ici.

Vous ne devez connaître que le principe suivant :

  • 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 recéption 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 du Check Sum est à retenir.

Bon, on a presque fini :

  • On sait localiser un programme avec son PORT
  • On sait détecter qu'un segment reçu n'est pas valide

Il reste à voir comment l'émetteur détecte qu'un segment n'a pas été reçu ou a été mal reçu.

Ce que nous n'avons pas encore utilisé va nous permettre de réaliser cette fonction fondamentale de TCP pour contrôler la transmission de données : l'accusé de réception. On parle également d'acquittement. En anglais, c'est acknowledgment.

Cette notion d'acquittement est même certainement le point fondamental du contrôle de la transmission par TCP : à chaque fois qu'on émet un segment, on attend du récepteur qu'il réponde par un acquittement pour signaler qu'il a bien reçu notre segment.

Encore une fois, comprennez bien qu'on ne vous demande pas de connaître ce protocole mais de comprendre son élément fondamental : quand je reçois un message légitime et valide, j'envoie à mon tour un message contenant un accusé de réception pour ce message.

Voyons une version simplifiée des échanges.

Et ça commence dès l'établissement d'une connexion qui se fait en trois temps :


  • Etape 1 : Le côté-client envoie un segment contenant un drapeau SYN : il indique qu'il envoie le segment de connexion.
    • En gros, le client dit Serveur, tu veux bien commencer à discuter (SYN) ?

    Avec beaucoup de segments à passer (dont beaucoup ne transportant par de data mais uniquement des informations stockées dans le header), cette présentation est un peu lourde. Nous allons maintenant passer à une représentation plus simple du paquet :

    SYN + data vide
  • Etape 2 : Le côté-serveur reçoit la demande : il acquitte cette demande en envoyant un segment contenant un drapeau ACK. Il place Suiv à 1 pour dire qu'il veut donc bien du segment de données 1. Il demande également confirmation de la connexion en plaçant un drapeau SYN.
    • En gros, le serveur dit Je veux bien (ACK). Toujours ok pour toi client (SYN) ?
    SYN + data vide ACK 1 + SYN + data vide

    J'ai encore simplifié la vue : je n'affiche pas les segments qui ne transporte pas d'informations à part celles contenues dans le header (drapeaux ACK, SYN, ...).


  • Etape 3 : Le serveur reçoit l'accusé de réception de son premier message et une demande de communication SYN de la part du serveur : il acquitte cette demande en envoyant un drapeau ACK et 1 dans Suiv pour dire qu'il veut bien la suite, le segment 1 du coup.
    • En gros, le client dit Bien reçu. Toujours bon pour moi.
SYN + Data vide ACK 1 + SYN + data vide ACK 1 + data vide

A partir de là, la connexion est établie : le client peut envoyer sa REQUETE (certainement dans un seul segment car elle ne contient pas grand chose).


Si tout se passe bien, la couche transport du côté-client a généré un segment contenant la requête http.

  • Le client envoie le segment de données 1 en précisant SEQ 1 et indique ack 1 pour indiquer qu'il attend éventuellement un segment de données 1 de la part du serveur.
  • Le côté-serveur reçoit le segment. Il répond ACK 2 (pour dire qu'il veut bien le segment de données 2 éventuellement).
  • SEQ 1 + ack 1 Data 1 (la requête http) ACK 2 + Data vide
  • La couche TRANSPORT du serveur envoie alors la requête au programme-serveur qui travaille.
  • Le programme-serveur envoie sa réponse à la couche TRANSPORT. Segmentation en deux segments par exemple.
  • Le côté-serveur envoie le premier-segment : SEQ 1 (pour dire qu'il envoie le segment de données 1) et ack 2 (pour dire qu'il attend toujours un segment de données 2 éventuel)
  • Le côté-client reçoit le segment et répond ACK 2 pour dire qu'il veut bien du segment 2.
  • 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
  • Le côté-client transmet le début de la réponse au programme-client
  • Le côté-serveur envoie le deuxième-segment, SEQ 2. Il précise également ack 2 pour dire qu'il veut bien du segment 2.
  • Le côté-client reçoit le segment et répond ACK 3 pour dire qu'il veut bien du segment 3 (qui n'arrivera pas tout de suite puisque la réponse http tenait en deux segments)
  • Le côté-client transmet le début de la réponse au programme-client
  • La page HTML est complète, Firefox va la lire et voir s'il faut demander d'autres fichiers au serveur (images, CSS...)
  • 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 SEQ 2 + ack 2 Data 2 (la réponse http) ACK 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...

Et comment fait TCP pour remarquer qu'il manque un segment ? Il gère les accusés de réception / acquittements.

Imaginons que lors du premier envoi de la requête TCP détecte une erreur de transmission à l'aide du Check Sum. Il ne va alors pas acquitter ce segment.

Du côté client, après un certain temps sans réponse du serveur, il va simplement renvoyer le segment. Et voilà.

SEQ 1 + ack 1 Data 1 (la requête http) Erreur de transmission détectée SEQ 1 + ack 1 Data 1 (la requête http) Délai d'attente dépassé ACK 2 + Data vide

Le mieux, c'est que ça marche également avec les segments qui n'atteindraient pas la couche transport d'en face pour une raison quelconque.

Imaginons ainsi que lors du premier envoi, le segment contenant la requête n'arrive pas à destination jusqu'à la couche transport côté-serveur.

Ben oui : on dépasse le délai d'attente encore une fois, tout simplement. Et donc, on renvoie encore une fois.

SEQ 1 + ack 1 Data 1 (la requête http) Le segment a disparu ! SEQ 1 + ack 1 Data 1 (la requête http) Délai d'attente dépassé ACK 2 + Data vide

Et voilà pour la culture générale sur TCP.

Que devez-vous connaitre sur TCP au final ?

  • Son rôle : contrôler et gérer la transmission des communications entre deux programmes distants
  • Le nom des unités élémentaires qu'il gère : les segments
  • Le nom des adresses des programmes : les PORTS.
  • Ses deux principes fondamentaux :
    • La segmentation des communications en segments numérotés justement
    • L'acquittement constant des segments reçus et le renvoi régulier des segments non acquittés.
Résumé animé d'une communication TCP

Cliquer sur le message Req pour visualiser le déroulement de la communication.

Rep http Rep TCP Req TCP ACK TCP

Une petite question pour finir ?

Envoyer le segment et attendre l'acquittement, c'est long.

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 : on envoie les deux segments de la réponse HTTP au client. Mais le segment 1 n'arrive pas.

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

✎ 23° 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 à votre avis ?

Dernière possibilité : le premier segment n'est pas perdu. Il arrive juste en retard mais avant le délai d'attente maximum !

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

✎ 24° Que va-t-il pouvoir se passer au niveau des acquittements cette fois ? Le serveur va-t-il devoir renvoyer le segment 2 ?

Fiabilité de la transmission

TCP permet donc de garantir la fiabilité de la transmission.

Par contre, 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 s'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 - Couche Réseau ou Internet

La fois prochaine, nous verrons qu'en réalité, les deux couches TRANSPORT ne peuvent pas vraiment discuter ainsi aussi facilement : elles ne sont pas sur le même ordinateur !

Il faudra alors encapsuler notre segment TCP dans un paquet IP : nous rajouterons des informations devant le segment, notamment les adresses IP de l'ordinateur source et de l'ordinateur de destination.

Voici une façon visuelle de comprendre le principe :

>

Et voilà, notre paquet prêt à partir sur Internet !

Couche Réseau

Lorsqu'un programme veut faire communiquer deux programmes distants, on doit utiliser l'un des protocoles de la couche TRANSPORT.

Or, les deux couches TRANSPORT sont bien sur deux ordinateurs différents : pour faire communiquer deux ordinateurs distants, on doit passer par l'un des protocoles de la couche RESEAU. Sur Internet, il s'agit d'IP.

Lorsqu'on veut transporter un segment, il faut donc lui rajouter un en-tête de façon à intégrer les adresses IP source et destinataire.

Le nom de cette nouvelle unité de transport de l'information est le paquet.

5 - Couche liaison ou accès réseau

Et comment fonctionne la couche IP au fait ?

Elle communique avec la carte réseau de votre ordinateur en utilisant la couche Accès Réseau dans le modèle Internet.

Couche Accès Réseau

Lorsqu'un programme veut faire communiquer deux programmes distants, on doit utiliser l'un des protocoles de la couche TRANSPORT.

Pour deux ordinateurs distants, on doit passer par l'un des protocoles de la couche RESEAU. Sur Internet, il s'agit d'IP.

Or il faut que deux cartes réseaux d'ordinateurs connectés puissent communiquer entre elles pour transmettre ensuite le message de proche en proche. Et pour cela, on utilise la couche accès réseau où les cartes sont identifiées par leur adresse dites MAC (Media Access Control).

On va donc placer notre beau paquet IP à l'intérieur d'une trame : elle possède un début détectable par les cartes électroniques et une fin détectable également. Comme on communique ici avec du "vrai matériel" (ce n'est pas juste une communication entre codes informatiques), on a besoin d'un début et d'un fin clairement indiqués.

>

Et pour le transfert global en partant de TCP :

Lorsqu'on veut transporter un segment, il faut donc lui rajouter un en-tête de façon à intégrer les adresses IP source et destinataire.

Le nom de cette nouvelle unité de transport de l'information est le paquet.

On entoure alors le paquet entre deux ensembles de données qui vont permettre à la carte réseau de savoir où transporter la trame et à la carte de destination de savoir qu'un message arrive.

Et le nom de cette nouvelle unité de communication est la trame.

Voilà, nous verrons la prochaine fois comme faire circuler le paquet IP transportant votre segment TCP de routeur en routeur.

Et pour cela, il faudra bien encapsuler votre segment dans votre paquet et votre paquet dans une trame...

6 - FAQ

On peut avoir la réponse à la question 23 ?

Rappel du problème : le serveur doit envoyer deux segments mais seul le deuxième arrive bien du côté-client.

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

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.

SEQ 1 + ack 1 Data 1 (la requête http) ACK 2 + Data vide SEQ 1 + ack 2 Data 1 (la réponse http) SEQ 2 + ack 2 Data 2 (la réponse http) Délai dépassé pour seq 1 Délai dépassé pour seq 2 ACK 2 + data vide ACK 3 + data vide

Le côté-client peut alors renvoyer

  • un acquittement ACK 2 après avoir reçu le segment 1 et
  • ACK3 après avoir reçu le segment 2

On peut avoir la réponse à la question 24 ?

Rappel du problème : le serveur envoie deux segments mais le premier arrive un peu après le deuxième.

SEQ 1 + ack 1 Data 1 (la requête http) ACK 2 + Data vide Délai max pour seq 1

La réponse est très simple en réalité : le client va acquitté le segment 1 et 2 d'un coup en envoyant ACK 3 pour dire : je veux bien le segment 3 s'il existe..

SEQ 1 + ack 1 Data 1 (la requête http) ACK 2 + Data vide Délai max pour seq 1 ACK 3 + data vide

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.

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

Et nous parlerons un peu de la couche accès au réseau, mais pas trop. On atteint la couche plus physique et électronique du transport de l'information. D'ici à ce que vous soyez sur le monde du travail, il y a des grandes chances que les technologies actuelles ne soient plus d'actualité !

Activité publiée le 19 03 2020
Dernière modification : 22 03 2020
Auteur : ows. h.