Objectifs de certification

CCNA 200-301

• 1.5 Comparer TCP à UDP

Couche Transport TCP et UDP

Les protocoles TCP et UDP de la couche Transport des modèles OSI et TCP/IP, vus de manière comparative, font partie des sujets vérifiés dans les certifications ICND1 et CCNA. On trouvera dans ce chapitre une tentative d’éclairage sur le sujet.

1. Introduction

Les protocoles de la couche de transport peuvent résoudre des problèmes comme la fiabilité des échanges (“est-ce que les données sont arrivées à destination ?”) et assurer que les données arrivent dans l’ordre correct.

Dans la suite de protocoles TCP/IP, les protocoles de transport déterminent aussi à quelle application chaque paquet de données doit être délivré.

Les protocoles de couche transport font le lien entre les hôtes (IP) et les services applicatifs (HTTP, FTP, DNS, et d’autres).

Mais on retiendra principalement que la couche transport est responsable des dialogues (sessions) entre les hôtes terminaux. Elle permet de multiplexer les communications entre les noeud IP en offrant un support à la couche application de manière :

• Fiable et connectée avec le protocole TCP
• Non-fiable et non-connectée avec le protocole UDP

Les ports TCP ou UDP (65536 sur chaque interface) permettent aux hôtes terminaux d’identifier les dialogues.

1.1. TCP

TCP, Transmission Control Protocol, offre des services d’établissement et de fin de dialogue ainsi que des messages de maintenance de la communication en mode fiable et connecté avec :

• des accusés de réception
• du séquençace, de l’ordonnancement
• du contrôle de flux (fenêtrage)
• de la reprise sur erreur
• du contrôle de congestion
• de la temporisation

1.2. UDP

UDP, User Datagram Protocol, s’occupe uniquement du transport non fiable.

• Il est une simple passerelle entre IP et l’application.
• Il est conseillé pour les applications pour du trafic en temps réel à taille fixe et régulier (voix, vidéo).
• Il supporte des protocoles simples (TFTP, SNMP) ou souffrant des délais (DHCP, DNS, NTP).

1.3. Comparaison UDP et TCP

Il est utile de comparer UDP et TCP :

• UDP est un en-tête amoindri des fonctionnalités TCP.
• UDP dispose presque uniquement des champs ports source et port destination.

1.4. En-tête TCP

Source de l’image : TCP/IP Reference nmap.org

1.5. En-tête UDP

Source de l’image : TCP/IP Reference nmap.org

En téléchargeant les livres du Guide CCNA 200-301 vous encouragez son auteur !

2. Numéros de ports

Les ports sont des portes d’entrée entre les hôtes terminaux. Ils sont codés sur 16 bits de 0 à 65535.

Un client IP ouvre un port à l’origine à destination d’un serveur IP écoutant sur un port de destination. La réponse émane du port de l’application sur le serveur à destination du couple IP:port client ouvert à l’origine.

La commande netstat -a sur un PC permet de connaître tous les ports à l’écoute et les liaisons maintenues à l’instant (UDP et TCP sur IPv4 et IPv6).

C’est ce qu’on appelle un “socket” : l’adresse IP combinée au port identifie chaque partenaire de communication.

La liste complète des ports se trouve ici : Service Name and Transport Protocol Port Number Registry.

Les hôtes utilisent les ports TCP ou UDP pour identifier les sessions à l’origine (port source) et à la destination.

Par exemple, pour établir une session HTTP, l’hôte utilisera un port local au-delà de TCP1024 et le port TCP80 en destination.

Les numéros de ports par défaut des services applicatifs sont gérés par l’IANA.

3. Protocole TCP

Le texte qui suit sur le protocole TCP est directement inspiré de la page Wikipedia sur TCP. Ce propos suffit amplement à maîtriser les objectifs de la certification CCNA.

3.1. TCP : fonctionnement

Une session TCP fonctionne en trois phases :

• l’établissement de la connexion ;
• les transferts de données ;
• la fin de la connexion.

L’établissement de la connexion se fait par un handshaking en trois temps. La rupture de connexion, elle, utilise un handshaking en quatre temps. Pendant la phase d’établissement de la connexion, des paramètres comme le numéro de séquence sont initialisés afin d’assurer la transmission fiable (sans perte et dans l’ordre) des données.

3.2. Machine à état TCP

Source de l’image.

3.3. TCP Three Way Handshake

Même s’il est possible pour deux systèmes d’établir une connexion entre eux simultanément, dans le cas général, un système ouvre une ‘socket’ (point d’accès à une connexion TCP) et se met en attente passive de demandes de connexion d’un autre système. Ce fonctionnement est communément appelé ouverture passive, et est utilisé par le côté serveur de la connexion.

Le côté client de la connexion effectue une ouverture active en 3 temps :

• Le client envoie un segment SYN au serveur,
• Le serveur lui répond par un segment SYN/ACK,
• Le client confirme par un segment ACK.

Source de l’image.

Durant cet échange initial, les numéros de séquence des deux parties sont synchronisés :

• Le client utilise son numéro de séquence initial dans le champ “Numéro de séquence” du segment SYN (x par exemple),
• Le serveur utilise son numéro de séquence initial dans le champ “Numéro de séquence” du segment SYN/ACK (y par exemple) et ajoute le numéro de séquence du client plus un (x+1) dans le champ “Numéro d’acquittement” du segment,
• Le client confirme en envoyant un ACK avec un numéro de séquence augmenté de un (x+1) et un numéro d’acquittement correspondant au numéro de séquence du serveur plus un (y+1).[^source-wikipedia]

En téléchargeant les livres du Guide CCNA 200-301 vous encouragez son auteur !

3.4. Transfert des données

Pendant la phase de transferts de données, certains mécanismes clefs permettent d’assurer la robustesse et la fiabilité de TCP. En particulier :

• les numéros de séquence sont utilisés afin d’ordonner les segments TCP reçus et de détecter les données perdues,
• les sommes de contrôle permettent la détection d’erreurs,
• et les acquittements ainsi que les temporisations permettent la détection des segments perdus ou retardés.[^source-wikipedia]

Source de l’image.

3.5. Numéro de séquence et numéro d’acquittement

Le numéro d’acquittement est le numéro de séquence attendu du partenaire de communication.

ACK+1 signifie j’ai reçu les premiers segments donne-moi la suite.

On parle de numéro d’acquittement anticipatif.

3.6. Temporisation

La perte d’un segment est gérée par TCP en utilisant un mécanisme de temporisation et de retransmission. Après l’envoi d’un segment, TCP va attendre un certain temps la réception du ACK correspondant. Un temps trop court entraîne un grand nombre de retransmissions inutiles et un temps trop long ralentit la réaction en cas de perte d’un segment.

Dans les faits, le délai avant retransmission doit être supérieur au RTT moyen d’un segment, c’est-à-dire au temps que prend un segment pour effectuer l’aller-retour entre le client et le serveur. Comme cette valeur peut varier dans le temps, l’ordinateur “prélève” des échantillons à intervalle régulier et on en calcule une moyenne pondérée.

3.7. Somme de contrôle

Une somme de contrôle sur 16 bits, constituée par le complément à un de la somme complémentée à un de tous les éléments d’un segment TCP (en-tête et données), est calculée par l’émetteur, et incluse dans le segment émis. Le destinataire recalcule la somme de contrôle du segment reçu, et si elle correspond à la somme de contrôle reçue, on considère que le segment a été reçu intact et sans erreur.

3.8. Contrôle de flux

Chaque partenaire dans une connexion TCP dispose d’un tampon de réception dont la taille n’est pas illimitée. Afin d’éviter qu’un hôte ne surcharge l’autre, TCP prévoit plusieurs mécanismes de contrôle de flux. Ainsi, chaque segment TCP contient la taille disponible dans le tampon de réception de l’hôte qui l’a envoyé. En réponse, l’hôte distant va limiter la taille de la fenêtre d’envoi afin de ne pas le surcharger. D’autres algorithmes comme Nagle ou Clarck facilitent également le contrôle du flux.

3.9. Contrôle de congestion

La congestion intervient lorsque trop de sources tentent d’envoyer trop de données trop vite pour que le réseau soit capable de les transmettre. Ceci entraîne la perte de nombreux paquets et de longs délais.

Les acquittements des données émises, ou l’absence d’acquittements, sont utilisés par les émetteurs pour interpréter de façon implicite l’état du réseau entre les systèmes finaux. À l’aide de temporisations, les émetteurs et destinataires TCP peuvent modifier le comportement du flux de données. C’est ce qu’on appelle généralement le contrôle de congestion.

Il existe une multitude d’algorithmes d’évitement de congestion pour TCP.

3.10. Autres fonctionnalités TCP

TCP utilise un certain nombre de mécanismes afin d’obtenir une bonne robustesse et des performances élevées. Ces mécanismes comprennent l’utilisation d’une fenêtre glissante, l’algorithme de démarrage lent (slow start), l’algorithme d’évitement de congestion (congestion avoidance), les algorithmes de retransmission rapide (fast retransmit) et de récupération rapide (fast recovery), etc.

Des recherches sont menées actuellement afin d’améliorer TCP pour traiter efficacement les pertes, minimiser les erreurs, gérer la congestion et être rapide dans des environnements très haut débit.

3.11. Fin d’une connexion

La phase de terminaison d’une connexion utilise un handshaking en quatre temps, chaque extrémité de la connexion effectuant sa terminaison de manière indépendante. Ainsi, la fin d’une connexion nécessite une paire de segments FIN et ACK pour chaque extrémité.

Source de l’image.

4. Exemple de trafic TCP et UDP

Voici un exemple de trafic TCP et UDP obtenu à partir de la commande :

wget http://cisco.goffinet.org/logo.png

• Résolution DNS (UDP)
• Trafic HTTP (TCP)

On apprendra à distinguer :

• les numéros de ports source et destination
• les numéros de séquence et d’acquittement
• les trois étapes établissement, maintien et fin d’une connexion

Voici un autre exemple avec l’utilitaire Netcat :

5. Sources

• https://fr.wikipedia.org/wiki/Transmission_Control_Protocol
• https://en.wikipedia.org/wiki/Transmission_Control_Protocol
• https://commons.wikimedia.org/wiki/File:Tcp_state_diagram_fixed_new.svg
• https://commons.wikimedia.org/wiki/File:Tcp_connect.svg
• https://commons.wikimedia.org/wiki/File:Tcp_talk.svg
• https://commons.wikimedia.org/wiki/File:Tcp_close.svg
• http://nmap.org/book/tcpip-ref.html