Aller au contenu

Protocole TCP

Limites d'IP et principe de TCP

Le protocole IP sert à acheminer les paquets à travers Internet par le biais de routeur. Des paquets pour une même destination peuvent prendre des routes différentes. Ce qui veut dire que qu'il n'y a aucune garantie que les paquets arriveront dans l'ordre où ils ont étés envoyés.

Activité

Supposons que l'on doive acheminer le message Equipe A a battu Equipe B, qui rend compte d'un match entre deux équipes, avec le découpage en paquets suivant : Equipe A, a battu, Equipe B.

Donnez un exemple d'ordre d'arrivée des paquets qui rends le message incompréhensible.

Par exemple : Equipe AEquipe B a battu.

Donnez un exemple d'ordre d'arrivée des paquets qui change le sens du message.

Par exemple Equipe B a battu Equipe A.

Expliquez pourquoi le message reconstitué question 2 est plus problématique que le message question 1.

Le message question 1 est incompréhensible, on peut donc déterminer facilement qu'une erreur a eu lieu. Le message question 2 en revanche a un sens, mais pas le sens du message initial, on risque donc de l'interpréter à tort comme valide.

Que pourrait-on ajouter dans les paquets pour être sûr de pouvoir les remettre dans le bon ordre ?

On pourrait ajouter un numéro de paquet : 1:Equipe A, 2: a battu, 3:Equipe B.

IP est aussi sensible aux erreurs du réseau. Par exemple, si un routeur tombe en panne pendant qu'il transmet un paquet, le paquet est perdu. IP ne garantis donc pas que les paquets arriveront à coup sûr à destination.

Activité

Supposons que seuls ces deux paquets arrivent à destination : 1:Equipe A, 3:Equipe B.

Comment peut-on savoir qu"un paquet n'a pas été transmis ?

On regarde les numéros de paquet. Ici, 1 puis 3, et on en déduis qu'il nous manque le paquet numéro 2.

Comment pourrait-on résoudre cette erreur ?

Le destinataire redemande le paquet numéro 2 à l'envoyeur.

Si le paquet 3:Equipe B avait été perdu, notre méthode de détection des pertes ne marcherait pas. Pourquoi ?

Comme le paquet 3 est le dernier de la transmission, on ne peut pas deviner qu'il était là.

Voici une solution au problème :

Pour résoudre le problème soulevé question 3, on pourrait avoir la solution suivante :

A chaque fois que le destinataire reçoit un paquet, il envoie à l'émetteur un accusé de réception. Si après un certain temps après l'envoi d'un paquet, l'émetteur ne reçoit pas d'accusé de réception, il renvoie le paquet à l'émetteur.

Le comptage des paquets et les accusés de réception son implémentés dans le protocole TCP (pour Transmission Control Protocol), qui permet une transmission de paquets fiable.

Remarque

En réalité, les paquets TCP sont appelés segments. Mais dans le langage courant, il est fréquent de parler de paquet TCP. On gardera donc cette dernière terminologie.

Un paquet TCP comporte dans son en-tête, entre autres: - deux champs sur 32 bits : le numéro de séquence, qui permet de retrouver l'ordre des paquets, et le numéro d'acquittement, qui sert d'accusé de réception. - des champs sur un seul bit, appelés flags, qui transportent des informations sur la connection et la transmission. Si un flag est à 1, on dit qu'il est présent, sinon il est absent.

Etablissement de la connection

Le protocole TCP est en mode connecté. C'est à dire que les échanges de paquets se font dans une "conversation", appelée session. Pour établir une session, on fait l'échange suivant, appelé handshake :

  • Le logiciel A établissant la connection envoie TCP envoie au receveur un paquet TCP avec le flag SYN, et un numéro de séquence N initial pris au hasard, par exemple 99.
  • Le logiciel B recevant la connection réponds au logiciel A un paquet TCP avec les flags SYN et ACK. Le numéro de séquence M est pris au hasard (par exemple, 458). Le numéro d'acquittement est N+1 (dans notre cas, 100).
  • Le logiciel A réponds au logiciel B un paquet TCP avec le flag ACK. Le numéro de séquence est N+1 (dans notre cas 100). Le numéro d'acquittement est M+1 (dans notre cas 459).

A ce point, la connection est établie, A et B ont un chacun reçu numéro de séquence qui leur permet d'organiser les données pour l'envoi.

TODO ajouter schema ici

Echange de données

La connection est établie, et A souhaite maintenant transmettre des messages. Le dernier numéro d'acquittement reçu par A dans notre cas est 100. Il correspond au prochain numéro de séquence attendu par B. Dans TCP, le numéro de séquence n'est pas un numéro de paquet, mais la position en octets dans le flux de données envoyé par l'émetteur au destinataire.

  • Supposons que A veuille envoyer 13 octets de données à B. Il crée donc un paquet TCP avec pour numéro de séquence 100 + 1 = 101, et avec les 13 octets en charge utile, puis l'envoie à B.
  • Quand B reçoit le paquet, il renvoie un paquet TCP avec le flag ACK, et pour numéro d'acquittement 101 + 13 = 113. Celà veut dire "j'ai reçu les données jusqu'à l'octet 114.
  • A peut continuer encore d'envoyer des données à B.

TODO schema ici

*Si le numéro de séquence dépasse la valeur maximale d'un entier sur 32 bits, il boucle et revient à zéro.

Bien entendu, B peut également envoyer des données à A en parallèle. L'acquittement peut se faire par le biais d'un paquet de données.

TODO schema ici

Fenêtre de transmission

Envoyer un paquet à la fois et attendre un accusé de réception est relativement peu efficace. TCP permet donc l'envoi de plusieurs paquets par un émetteur avant d'attendre l'accusé de réception du permier paquet. La quantité de donnée totale dans la charge utiles de ces paquets est renseignée dans les accusés de réception du receveur, par un champs de l'en tête TCP appelé fenêtre de transmission. Par exemple un paquet avec ACK, un numéro d'acquittement de 145 et une fenêtre de transmission de 2000 veut dire "J'ai reçu les données jusqu'à l'octet 145, je peux recevoir jusqu'à 2000 octets en parallèle".

TODO expliquer le buffer etc ?

Fermeture de la connection

Un des logiciels, par exemple A, peut signifier à l'autre qu'il n'enverra plus de donnée :

  • Il envoie un paquet TCP avec le flag FIN et le numéro de séquence courant.
  • Le logiciel B lui réponds par un ACK avec le numéro de séquence reçu + 1.

Après celà, B peut continuer d'envoyer des données à A, mais A n'en enverra plus. Quand B décide de fermer également son côté de la connection, il fait l'opération inverse.

  • Il envoie un paquet TCP avec le flag FIN et le numéro de séquence courant.
  • Le logiciel A lui réponds par un ACK avec le numéro de séqutence reçu + 1.

La connection est alors complètement fermée.

TODO schéma ici

Limites de TCP

Le protocole TCP, qui permet une communication fiable sans efforts, rends l'implémentation d'applications communiquant par Internet relativement facile, il est donc quasiment systématiquement utilisé pour la communication entre logiciels.

Toutefois, TCP a une limite majeure : il n'a pas de garantie temporelle. Autrement dit, le protocole garantis que les données envoyées seront reçues un jour, mais on ne sait pas quand.

TODO plus d'explications ici, un exemple ?

De plus, l'attente d'accusés de réception ralentis légèrement la transmission de données massives.

Activité

On préfère donc parfois accepter que des paquets soient perdus, ou encore implémenter un mécanisme de fiabilité sur-mesure.

Trouvez un exemple de données pour lequelles une perte de quelques paquets n'est pas grave.

Dans le cas d'un streaming video, la perte d'un paquet, même gros, entrainera la perte de quelques pixels uniquement, ce qui ne va pas détériorer l'image.

Donnez un exemple d'une adaptation qui peut être faite pour une perte de paquet dans l'application de la réponse question 1.

Trouvez un exemple d'application pour laquelle on veut un délais de transmission faible.

Un jeu vidéo en temps réel en ligne peut difficilement être implémenté avec TCP, parce que l'on veut que le temps pour qu'une commande arrive au serveur soit le plus petit possible.

Si une application comme mentionné à la question 3 n'a que peu de données à envoyer, comment peut-on augmenter la probabilité qu'une partie des données donné arrive à destination ?

Si les données transmises sont relativement légères, on peut simplement envoyer plusieurs paquets contenant les mêmes données. Plus les paquets sont nombreux, et plus on a de chance qu'au moins un des paquets ne soit pas affecté par une panne et arrive a destination.

Un des protocoles alternatifs à TCP est UDP, pour User Datagram Protocol. UDP s'appuie sur IP, mais ne propose pour un paquet (appelés Datagramme), que de renseigner des ports sources et destination, et un mécanisme permettant de savoir si les données du paquet ont étés altérées ou non pendant le transit. Ce mécanisme, appelé somme de contrôle, est également présente dans TCP.