En-tête TCP

Pour suivre l'état d'une session, le protocole TCP enregistre les informations qu'il a envoyées et les informations qu'il a reçues. La
session en état commence avec l'établissement de la session et se termine avec la clôture de la session

Un segment TCP ajoute 20 octets (c'est-à-dire 160 bits) de surcharge lors de l'encapsulation des données de la couche
d'application

14.3aperçu de l'UDP

Fonctions du protocole UDP

UDP est un protocole de transport optimal. UDP est un protocole de transport léger qui offre la même

Champ d'en-
Description
tête TCP
Port source Champ 16 bits utilisé pour identifier l'application source par le numéro de port.
Port de
Champ 16 bits utilisé pour identifier l'application de destination par numéro de port.
destination
Numéro d'ordre Champ 32 bits utilisé à des fins de réassemblage de données.
Numéro d’accusé Champ 32 bits utilisé pour indiquer que les données ont été reçues et que le prochain octet est attendu
de réception de la source.
Longueur d’en- Un champ 4 bits connu sous le nom de «offset de données» qui indique la longueur de l'en-tête du
tête segment TCP.
Réservé Un champ de 6 bits qui est réservé pour une utilisation future.
Champ 6 bits qui inclut des codes de bits, ou des indicateurs, qui indiquent l'objectif et la fonction du
Bits de contrôle
segment TCP.
Taille de fenêtre Champ 16 bits utilisé pour indiquer le nombre d'octets pouvant être acceptés à un moment donné.
Somme de
Un champ de 16 bits utilisé pour la vérification des erreurs de l'en-tête du segment et des données.
contrôle
Urgent Champ 16 bits utilisé pour indiquer si les données contenues sont urgentes.

segmentation et le même réassemblage de données que TCP, mais sans la fiabilité et le contrôle de flux de TCP.

Les caractéristiques de l'UDP sont les suivantes :

Les données sont reconstituées selon l'ordre de réception.

 Les segments qui sont perdus ne sont pas renvoyés.

 Il n'y a pas d'établissement de session.
 L'expéditeur n'est pas informé de la disponibilité des ressources.
 En-tête UDP
8 octets (c'est-à-dire 64 bits)

Champ d'en-tête UDP Description

Port source Champ 16 bits utilisé pour identifier l'application source par le numéro de port.
Port de destination Champ 16 bits utilisé pour identifier l'application de destination par numéro de port.
Longueur Champ 16 bits indiquant la longueur de l'en-tête de datagramme UDP.
Champ 16 bits utilisé pour la vérification des erreurs de l'en-tête et des données du
Somme de contrôle
datagramme.

Applications utilisant l'UDP

Applications vidéo et multimédia en direct
Applications simples de demande et de réponse DNS et le DHCP.
Applications qui gèrent elles-mêmes la fiabilité - Communications unidirectionnelles où le contrôle de flux, la
détection des erreurs, les accusés de réception et la récupération des erreurs ne sont pas nécessaires, ou peuvent
être gérés par l'application. Exemples incluent: SNMP et TFTP.

Bien que DNS et SNMP utilisent UDP par défaut, ces deux protocoles peuvent également utiliser TCP. Le DNS
utilisera TCP si la requête ou la réponse DNS est supérieure à 512 octets, par exemple lorsqu'une réponse DNS
comprend de nombreuses résolutions de noms. De manière similaire, dans certaines situations, il se peut que
l'administrateur réseau souhaite configurer SNMP de manière à utiliser TCP.

14.4 numéros de port

Communications Multiples et Séparées

Les protocoles de couches de transport TCP et UDP utilisent des numéros de port pour gérer plusieurs
conversations simultanées

le numéro de port source est généré dynamiquement par l'hôte pour identifier de manière unique la conversation.
Chaque requête générée par un hôte utilisera un numéro de port source différent, créé dynamiquement. Ce
processus permet d'avoir plusieurs conversations simultanément.

Paires d'interfaces de connexion

Les ports sources et de destination sont placés à l'intérieur du segment. Les segments sont ensuite encapsulés dans
un paquet IP. Le paquet IP contient l'adresse IP de la source et de la destination. La combinaison de l'adresse IP
source et du numéro de port source, ou de l'adresse IP de destination et du numéro de port de destination, est
appelée interface de connexion.

L'interface de connexion sert à identifier le serveur et le service demandés par le client. Une interface de connexion
cliente peut se présenter comme suit, 1099 représentant le numéro du port source : 192.168.1.5:1099
L'interface de connexion d'un serveur web peut être 192.168.1.7:80

Ensemble, ces deux interfaces de connexion constituent une paire d'interfaces de connexion: 192.168.1.5:1099 et
192.168.1.7:80

Groupes de numéros de port

L'IANA (Internet Assigned Numbers Authority) est l'organisme de normalisation chargé d'attribuer diverses normes
d'adressage, notamment les numéros de port de 16 bits. Les 16 bits utilisés pour identifier les numéros de port
source et de destination fournissent une gamme de ports comprise entre 0 et 65535.

L'IANA a divisé la gamme de numéros en trois groupes de ports suivants.

Well-Known Port Numbers

Numéro
Protocole Application
de port

20 TCP FTP (File Transfer Protocol) - Données

21 TCP FTP (File Transfer Protocol) - Contrôle

22 TCP SSH (Secure Shell)

23 TCP Telnet

25 TCP Protocole SMTP

Service de noms de domaine (Domain Name

53 UDP, TCP
System, DNS)

Serveur DHCP (Dynamic Host Configuration

67 UDP
Protocol)

Protocole DHCP (Dynamic Host Configuration

68 UDP
Protocol) (client)

69 UDP Protocole TFTP (Trivial File Transfer Protocol)

80 TCP Protocole HTTP (Hypertext Transfer Protocol)

110 TCP protocole POP3 (Post Office Protocol version 3)

143 TCP IMAP (Internet Message Access Protocol)

161 UDP Simple Network Management Protocol (SNMP)

protocole HTTPS (Hypertext Transfer Protocol

443 TCP
Secure)

Commande netstat
 entrez la commande netstat pour lister les protocoles utilisés, l'adresse et les numéros de port locaux, l'adresse et
les numéros de port étrangers et l'état de la connexion.

Cette -n option peut être utilisée pour afficher les adresses IP et les numéros de port sous leur forme numérique.

14.5Processus de communicationTCP

Établissement d'une connexion TCP

le client hôte établit la connexion avec le serveur en utilisant le processus de poignée de main à trois voies.

Étape 1. SYN

Le client demande l'établissement d'une session de communication client-serveur avec le serveur.

Étape 2. ACK et SYN

Le serveur accuse réception de la session de communication client-serveur et demande l'établissement d'une

session de communication serveur-client.

Étape 3. ACK

Le client accuse réception de la session de communication serveur-client

Interruption de session
Pour mettre fin à une connexion, l'indicateur de contrôle FIN (Finish) doit être défini dans l'en-tête de segment.
Pour mettre fin à chaque session TCP unidirectionnelle, on utilise un échange en deux étapes constitué d'un
segment FIN et d'un segment ACK.

Étape 1. FIN

Quand le client n'a plus de données à envoyer dans le flux, il envoie un segment dont l'indicateur FIN est défini.

Étape 2. ACK

Le serveur envoie un segment ACK pour informer de la bonne réception du segment FIN afin de fermer la session
du client au serveur.

Étape 3. FIN

Le serveur envoie un segment FIN au client pour mettre fin à la session du serveur au client.

Étape 4. ACK

Le client répond à l'aide d'un segment ACK pour accuser réception du segment FIN envoyé par le serveur.

Analyse de la connexion TCP en trois étapes

TCP est un protocole full-duplex, où chaque connexion représente deux sessions de communication à sens
unique.

Ce sont les fonctions de la poignée de main à trois voies:

 Elle vérifie que le périphérique de destination est bien présent sur le réseau.
 Elle s'assure que le périphérique de destination a un service actif et qu'il accepte les requêtes sur le numéro de
port de destination que le client qui démarre la session a l'intention d'utiliser.
 Elle informe le périphérique de destination que le client source souhaite établir une session de communication sur
ce numéro de port.
Champ des bits de contrôle
Les six bits du champ des bits de contrôle de l'en-tête du segment TCP sont également des indicateurs. Un
indicateur est un bit qui est actif ou inactif.

Les six indicateurs de bits de contrôle sont les suivants:

URG - Champ de pointeur urgent significatif (Urgent pointer field significant)

ACK - Indicateur d'accusé de réception utilisé dans l'établissement de la connexion et la fin de la

session

PSH - Fonction push (Push function)

RST - Réinitialisation de la connexion en cas d'erreur ou de dépassement de délai

SYN - Synchroniser les numéros de séquence utilisés dans l'établissement de connexion

FIN - Plus de données de l'expéditeur et utilisées dans la fin de session

Video

14.6 Fiabilité et contrôle des flux

Fiabilité du TCP - Livraison garantie et commandée
Lors de la configuration de la session, un numéro d'ordre initial, ou ISN, est défini. Cet ISN représente la valeur de
départ des octets de cette session qui est transmise à l'application destinataire. Lors de la transmission des
données pendant la session, le numéro d'ordre est incrémenté du nombre d'octets ayant été transmis. Ce suivi des
octets de données permet d'identifier chaque segment et d'en accuser réception individuellement. Il est ainsi
possible d'identifier les segments manquants.

L'ISN ne commence pas à un mais est en fait un nombre aléatoire. Cela permet d'empêcher certains types
d'attaques de programmes malveillants

Les numéros d'ordre des segments indiquent comment réassembler et réordonnancer les segments reçus

Le processus TCP récepteur place les données d'un segment dans une mémoire tampon de réception. Les
segments sont ensuite placés dans l'ordre approprié et transmis à la couche d'application lorsqu'ils sont
réassemblés. Tous les segments qui arrivent en désordre sont conservés en vue d'un traitement ultérieur. Ces
segments sont ensuite traités dans l'ordre lorsque les segments contenant les octets manquants sont reçus.

Fiabilité du TCP - Perte de données et retransmission

Le numéro d'ordre (SEQ) et le numéro d'accusé de réception (ACK) sont utilisés ensemble pour confirmer la
réception des octets de données contenus dans les segments envoyés. Le numéro SEQ identifie le premier octet
de données dans le segment transmis. Le protocole TCP utilise le numéro ACK renvoyé à la source pour indiquer
l'octet suivant que le destinataire s'attend à recevoir. C'est ce que l'on appelle un accusé de réception prévisionnel.

Aujourd'hui, les systèmes d'exploitation hôtes utilisent généralement une fonctionnalité TCP facultative appelée
reconnaissance sélective (SACK), négociée au cours de la poignée de main à trois voies. Si les deux hôtes
prennent en charge SACK, le récepteur peut explicitement reconnaître quels segments (octets) ont été reçus, y
compris les segments discontinus. L'hôte émetteur n'aurait donc qu'à retransmettre les données manquantes. Par
exemple, dans la figure suivante, à nouveau en utilisant des numéros de segment pour simplifier, l'hôte A envoie
les segments 1 à 10 à l'hôte B. Si tous les segments arrivent à l'exception des segments 3 et 4, l'hôte B peut
reconnaître qu'il a reçu les segments 1 et 2 (ACK 3) et reconnaître sélectivement les segments 5 à 10 (SACK 5-
10). L'hôte A n'aurait besoin que de renvoyer les segments 3 et 4
Contrôle de flux TCP - Taille de fenêtre et accusés de réception
Le protocole TCP offre des mécanismes de contrôle des flux. Le protocole TCP inclut également des mécanismes
de contrôle de flux, qui correspond au volume de données que l'hôte de destination peut recevoir et traiter de
manière fiable. Le contrôle de flux aide à maintenir la fiabilité des transmissions TCP en réglant le flux de données
entre la source et la destination pour une session donnée. Pour cela, l'en-tête TCP inclut un champ de 16 bits
appelé taille de fenêtre.

La taille de fenêtre est le nombre d'octets que le périphérique de destination d'une session TCP peut accepter et
traiter en une fois.

La taille de fenêtre initiale est déterminée lors de l'établissement de la session TCP par l'intermédiaire de la
connexion en trois étapes. Le périphérique source doit limiter le nombre d'octets envoyés au périphérique de
destination en fonction de la taille de la fenêtre de la destination. Une fois que le périphérique source a reçu un
accusé de réception l'informant que les octets ont été reçus, il peut continuer à envoyer plus de données pour la
session. D'une manière générale, la destination n'attend pas que tous les octets de sa taille de fenêtre aient été
reçus avant de répondre par un accusé de réception. Une fois que tous les octets ont été reçus et traités, la
destination envoie des accusés de réception afin d'informer la source qu'elle peut continuer à envoyer des octets
supplémentaires.

Si l'espace libre dans la mémoire tampon de la destination diminue, cette dernière peut réduire sa taille de fenêtre
afin de demander à la source de diminuer le nombre d'octets envoyés avant de recevoir un accusé de réception

Remarque: Les appareils d'aujourd'hui utilisent le protocole des fenêtres coulissantes. Le récepteur envoie
généralement un accusé de réception tous les deux segments qu'il reçoit. Le nombre de segments reçus avant
l'envoi d'un accusé de réception peut varier. L'avantage des fenêtres dynamiques est de permettre à l'expéditeur
de transmettre des segments en continu, tant que le destinataire accuse réception des segments précédents

Contrôle de flux TCP - Taille maximale du segment (MSS)

Il s'agit généralement de la taille maximale de segment (MSS) que le périphérique de destination peut recevoir. Le
MSS fait partie du champ d'options de l'en-tête TCP qui spécifie la plus grande quantité de données, en octets,
qu'un périphérique peut recevoir dans un seul segment TCP. La taille MSS n'inclut pas l'en-tête TCP. Le MSS est
généralement inclus lors de la poignée de main à trois voies.

Un MSS commun est de 1 460 octets lors de l'utilisation d'IPv4. Un hôte détermine la valeur de son champ MSS en
soustrayant les en-têtes IP et TCP de la MTU Ethernet. La MTU par défaut d'une interface Ethernet est de 1500
octets. En retranchant l'en-tête IPv4 de 20 octets et l'en-tête TCP de 20 octets, la taille par défaut du MSS sera de
1460 octets, comme le montre la figure.
Contrôle de flux TCP - Prévention des encombrements
Lorsque la congestion se produit sur un réseau, elle a pour conséquence que les paquets sont rejetés par le
routeur surchargé. Lorsque les paquets contenant des segments TCP n'atteignent pas leur destination, ils sont
laissés sans accusé de réception. En déterminant la vitesse à laquelle les segments TCP sont envoyés, mais non
reçus, la source peut estimer le niveau d'encombrement du réseau.

Chaque fois qu'il y a encombrement, les segments TCP perdus sont retransmis par la source.

Afin d'éviter et de contrôler l'encombrement du réseau, le protocole TCP utilise divers mécanismes, minuteurs et
algorithmes de gestion des encombrements.

Si la source détermine que les segments TCP n'ont pas été reçus ou qu'ils n'ont pas été reçus à temps, elle peut
diminuer le nombre d'octets à envoyer avant la réception d'un accusé de réception. Comme illustré dans la figure

14.7 communication UDP

Faible surcharge et fiabilité du protocole UDP

UDP n'établit pas de connexion. Le protocole UDP fournit un transport de données à faible surcharge car il utilise
de petits en-têtes de datagrammes et n'offre pas de gestion du trafic réseau.

Réassemblage de datagrammes UDP

Le protocole UDP n'effectue pas de suivi des numéros d'ordre comme le fait le protocole TCP. Le protocole UDP
ne peut pas réassembler les datagrammes dans leur ordre de transmission, comme illustré dans la figure.

Le protocole UDP se contente donc de réassembler les données dans l'ordre dans lequel elles ont été reçues, puis
de les transmettre à l'application. Si l'ordre des données est important pour l'application, cette dernière doit
identifier l'ordre correct et déterminer le mode de traitement des données.

Le serveur RADIUS (Remote Authentication Dial-in User Service) illustré dans la figure fournit des services
d'authentification, d'autorisation et de comptabilité pour gérer l'accès des utilisateurs.