Вы находитесь на странице: 1из 97

M3102 - Services Réseaux

1 - Rappels : Ethernet, IP, ARP, ICMP, UDP, TCP

Cyril Pain-Barre

IUT Aix-Marseille - Dept INFO Aix

version du 3/11/2015

Cyril Pain-Barre 1 - Rappels 1 / 97


Modèle OSI vs architecture TCP/IP
L’architecture TCP/IP ne comprend que 5 couches, où OSI en
contient 7 :
Application FTP, SMTP, HTTP, TELNET, ... DNS, ... DHCP, TFTP, ...

Présentation
message
Session

Transport TCP UDP

Réseau paquet IP (+ ICMP)


ARP
Liaison
trame Hôte−Réseau
Physique

OSI TCP/IP
FTP : File Transfer Protocol
IP : Internet Protocol SMTP : Simple Mail Transfer Protocol
ICMP : Internet Control and Error Message Protocol HTTP : HyperText Transfer Protocol
ARP : Address Resolution Protocol TELNET : Terminal Virtuel
TCP : Transmission Control Protocol DNS : Domain Name Service
UDP : User Datagram DHCP : Dynamic Host Configuration Protocol
TFTP : Trivial File Transfer Protocol

Cyril Pain-Barre 1 - Rappels 2 / 97


Ethernet : couche hôte-réseau
Ethernet rend un service simple (et efficace) à la couche 3 :
adressage MAC pour unique identifiant d’une interface réseau
envoi/réception de trames sans garantie de remise ni de délai
plusieurs possibilités (d’adresse) de destination d’une trame :
unicast : un seul hôte est destinataire ;
multicast : un ensemble d’hôtes sont destinataires ;
broadcast : tous les hôtes (actifs) sont destinataires.
multiplexage : plusieurs (protocoles) réseaux peuvent
fonctionner simultanément au dessus d’Ethernet sans
interférer (ni même le savoir)
Variantes :
Ethernet partagé : plusieurs hôtes se partagent un canal de
communication −→ CSMA/CD
Ethernet commuté : réduction des domaines de collision par
les commutateurs (switch)
Si que des switch et liaisons full-duplex : pas de collision
possible donc pas de CSMA/CD
Cyril Pain-Barre 1 - Rappels 3 / 97
Datagramme IP sur Ethernet V2

trame Ethernet v2 contenant un datagramme IP (EtherType en Hexa) :


EtherType données
Adresse Adresse
Préambule
Destination Source
08 00 Datagramme IP CRC

(dé)multiplexage Ethernet v2 selon valeur de l’EtherType :


ARP RARP IP ...
le protocole destinataire des données
est indiqué par le champ EtherType 0x0806 0x8035 0x0800

trame
Ethernet V2 données

Cyril Pain-Barre 1 - Rappels 4 / 97


Internet Protocol (IP) : couche réseau
opère par routage de paquets
laisse une bonne partie de l’intelligence et du contrôle du réseau aux
machines terminales (protocole TCP)
service rendu de type best-effort : non fiable et non connecté (mode
datagramme)
=⇒ perte, duplication, déséquencement possible des paquets
le paquet (Protocol Data Unit) IPv4 s’appelle le datagramme IP
IPv4 assure 3 fonctions élémentaires :
adressage uniforme
routage
fragmentation
et s’adapte aux réseaux physiques sous-jacents (fiables ou non), à leur
charge utile (payload)
fournit des éléments de contrôle du fonctionnement des réseaux avec le
protocole ICMP

Cyril Pain-Barre 1 - Rappels 5 / 97


Datagramme IP

en-tête : nombre variable d’octets (multiple de 4)


données : nombre quelconque d’octets (limité à 65 315)
0 1 1 2 2 3 3
bits : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
VER HLEN TOS Longueur Totale
partie fixe (20 octets)

Identification Flags Déplacement

Time To Live Protocole Total de Contrôle


en−tête

Adresse IP Source

65 535 octets max


Adresse IP Destination
taille variable

Options IP (éventuelles)

Bourrage
taille variable

Données

Cyril Pain-Barre 1 - Rappels 6 / 97


ARP : Address Resolution Protocol

Méthode de résolution d’adresse dynamique et décentralisée :


diffusion d’une requête demandant l’adresse MAC
correspondant à une IP
l’hôte concerné renvoie la réponse ARP en unicast
Format du datagramme ARP :
bits : 0 8 16 31
Type de réseau Protocole

L. @phy L. @pro Opération (1 ou 2)

adresse physique source


taille variable

adresse protocole source

adresse physique destination

adresse protocole destination

Cyril Pain-Barre 1 - Rappels 7 / 97


ICMP : Internet Control and Error Message Protocol

ICMP est un module obligatoire d’IP


qui assure deux fonctions principales :
rendre compte d’un problème réseau
tester l’accessibilité d’une machine
les messages ICMP sont de deux natures :
les messages d’erreur : suite à une erreur constatée sur un datagramme
(qui entraı̂ne le plus souvent sa destruction)
les messages d’interrogation/information : messages divers contribuant
au (ou informant sur le) bon fonctionnement des équipements

Cyril Pain-Barre 1 - Rappels 8 / 97


Envoi des messages ICMP
Les messages ICMP sont encapsulés dans des datagrammes IP (champ
Protocole vaut 1) :
en−tête
Message ICMP ICMP données ICMP

en−tête
Datagramme IP IP données IP

Trame en−tête données trame en−queue


(ou PDU hôte−réseau)

mais IP utilisant ICMP pour envoyer ses


messages d’erreur, les deux se situent au
même niveau ! Transport (TCP et UDP)

les protocoles de transport (TCP et IP & ICMP


UDP) utilisent aussi ICMP pour certaines
Hôte−Réseau
erreurs (sur la station destinataire)
Cyril Pain-Barre 1 - Rappels 9 / 97
UDP et TCP : Protocoles de transport

Aller au-delà des limites d’IP


Assurer, si possible, la correction d’erreurs :
signalées par ICMP
non signalées
2 protocoles de transport disponibles dans TCP/IP :
UDP : transport rapide, non connecté, permettant la
multi-diffusion
TCP : transport fiable en mode connecté point-à-point
⇒ distinguent les applications au sein d’un même hôte
⇒ garantissent l’indépendance des communications

Cyril Pain-Barre 1 - Rappels 10 / 97


Adressage des applications Internet
Plusieurs applications réseaux peuvent s’exécuter en parallèle sur un
ordinateur
Problème : comment un émetteur peut-il préciser à quelle application
est adressé un message ?
La solution retenue sur Internet est l’utilisation de destinations
abstraites : les ports (ne pas confondre avec les ports physiques des
hubs/switchs)
entiers positifs sur 16 bits
UDP et TCP fournissent chacun un ensemble de ports indépendants : le
port n de UDP est indépendant du port n de TCP
le système permet aux applications de se voir affecter un port UDP et/ou
TCP (choisi ou de manière arbitraire)
certains numéros de port sont réservés et correspondent à des services
particuliers

L’adresse d’une application Internet est le triplet :


(adresse IP, protocole de transport, numéro de port)

Cyril Pain-Barre 1 - Rappels 11 / 97


Démultiplexage des ports

applications UDP applications UDP/TCP applications TCP

DHCP TFTP ... DNS ... FTP SMTP HTTP ...


(serveur)

67 69 53 selon Port 53 21 25 80

UDP TCP

17 selon champ Protocole 6

IP

Cyril Pain-Barre 1 - Rappels 12 / 97


Le protocole UDP : User Datagram Protocol
(RFC 768)

Cyril Pain-Barre 1 - Rappels 13 / 97


Services d’UDP
UDP repose sur IP à qui il confie l’acheminement de ses messages
d’un ordinateur à un autre.

Service rendu :
envoi/réception de messages entre applications (processus) à
travers Internet
adressage des applications par numéro de port
multiplexage/démultiplexage par numéros de port
contrôle facultatif de l’intégrité des données

Même type de service non fiable, non connecté que IP :


possibilité de perte, duplication, déséquencement de messages
pas de régulation de flux

Un programme utilisant UDP doit gérer lui-même ces


problèmes si besoin !
Cyril Pain-Barre 1 - Rappels 14 / 97
Format des datagrammes UDP

En-tête : pas d’option possible, nombre fixe d’octets = 8


Données : nombre variable d’octets (≤ 65 535)

bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port UDP Source Port UDP Destination
en−tête

Longueur Totale Checksum


taille variable

Données

Cyril Pain-Barre 1 - Rappels 15 / 97


Champs UDP : ports source et destination

Port UDP Source : indique le numéro de port de l’émetteur.


Peut être à 0 si aucune réponse n’est attendue.
Port UDP Destination : numéro de port du destinataire. Si ce
port n’a été alloué à aucun processus, UDP renverra un
message ICMP de destination inaccessible car port non alloué
(type 3, code 3) et détruit le datagramme
Démultiplexage UDP selon le port destination :

Appli 1 Appli 2 Appli 3

port x port y port z

UDP

selon champ Protocole (17)

IP

Cyril Pain-Barre 1 - Rappels 16 / 97


Serveurs et ports réservés UDP
Voir http://www.iana.org/assignments/port-numbers
Well known Port Assignment : certaines applications bien connues
ont des ports UDP réservés [0, 1023]
Exemples :
Num (décimal) Application
7 Serveur echo
13 Serveur daytime
19 Serveur chargen
53 Serveur DNS
67 Serveur BOOTP/DHCP
68 Client BOOTP/DHCP
69 Serveur TFTP
123 Serveur NTP

les ports [1024, 49151] sont enregistrés (mais peuvent être utilisés)
les ports [49152, 65535] sont dits dynamiques et/ou à usage privé
Cyril Pain-Barre 1 - Rappels 17 / 97
Champs UDP : Checksum

Facultatif : tout à 0 si non calculé


Vérifie la totalité du datagramme + Pseudo en-tête UDP.
Permet de s’assurer :
que les données sont correctes
que les ports sont corrects
que les adresses IP sont correctes
Même calcul que IP sur tout le datagramme UDP (bourrage
éventuel 1 octet à 0) + pseudo en-tête UDP
Pseudo en-tête UDP (interaction avec IP) : (12 octets)
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Adresse IP Source

Adresse IP Destination

Zone à Zéro Protocole Longueur Datagramme UDP

17 (en décimal) pour IP

Cyril Pain-Barre 1 - Rappels 18 / 97


Interface socket BSD (Unix) pour UDP
int socket(int domain, int type, int protocol) : retourne un Service
Access Point (SAP) auprès d’UDP, utilisé en premier paramètre des
primitives ci-après

int bind(int sock, const struct sockaddr *addr, socklen t addrlen)


associe au SAP l’adresse d’application addr

ssize t sendto(int sock, const void *buf, size t len, int flags,
const struct sockaddr *to, socklen t tolen)
demande l’envoi de len octets contenus dans buf, à l’adresse to

ssize t recvfrom(int sock, void *buf, size t len, int flags,


struct sockaddr *from, socklen t *fromlen)
reçoit dans buf un message d’au plus len octets ; l’adresse de l’émetteur
est placée dans from

int close(int sock) : libère le SAP

Cyril Pain-Barre 1 - Rappels 19 / 97


Modèle Client/Serveur utilisant UDP
Le serveur est démarré sur un ordinateur en écoute sur un port. Son
adresse est le triplet : (adresse IP, UDP, port)
L’écoute consiste à attendre qu’un message parvienne à ce port ; les clients
devront connaı̂tre le port du serveur (intérêt des ports réservés)
Le client envoie une requête au serveur (à son adresse) :
pour recevoir une réponse du serveur, il doit avoir acquis un numéro de port
UDP. Le plus souvent, ce port est quelconque. Rares sont les clients (comme
BOOTP/DHCP) qui nécessitent un port précis.
la requête est un message applicatif : suite d’octets constituant un PDU
(Protocol Data Unit) du protocole qu’implémentent le client et le serveur.
UDP fabrique un datagramme UDP avec pour champ Données ce message,
et pour champ Port Destination celui du serveur. Le Port Source est celui du
client.
Le datagramme UDP est ensuite envoyé via un datagramme IP avec les
adresses IP du serveur (destination) et du client (source).
Le serveur reçoı̂t le message du client, ainsi que son adresse. Il peut alors
traiter le message et répondre au client.
Selon le protocole, la discussion peut se poursuivre, ou s’arrêter là.
Cyril Pain-Barre 1 - Rappels 20 / 97
Files d’attente et réception

Attribution de port ⇒ allocation file d’attente


Réception d’un datagramme :
port destination non attribué : destruction + message ICMP
port alloué : si file non pleine, ajouté dans la file,
sinon détruit (pas de message ICMP !)
Appli consomme les éléments de la file, par accès synchrone :
si aucun datagramme, processus placé en attente
sinon, consommation du premier datagramme (FIFO)
Une application peut demander plusieurs ports

Cyril Pain-Barre 1 - Rappels 21 / 97


Utilisation UDP : modèle requête/réponse

Soit AppliB qui utilise 2 ports :


si reçoit datagramme sur port x, renvoie les données en
majuscules
si reçoit datagramme sur port y, renvoie les données à l’envers
pour ce genre de service, AppliB peut traiter les datagrammes
au fûr et à mesure

A1 A2 AppliB C1

x y

UDP UDP UDP

Hôte A Hôte B Hôte C

Cyril Pain-Barre 1 - Rappels 22 / 97


Utilisation UDP : suivis de discussions
Difficulté de suivre/gérer des discussions longues avec plusieurs clients
Exemple : un serveur TFTP délègue le transfert de fichier à un fils
reçoit un premier datagramme d’un client sur le port 69
demande un nouveau port
crée un fils pour traiter ce client sur ce nouveau port
renvoie un datagramme au client indiquant sur quel port poursuivre la
discussion (transfert de fichier)
retourne à l’écoute de l’arrivée de nouveaux clients
la discussion se poursuit entre le client et le fils TFTP ”dédié”

Client Fils Serveur Fils Client


TFTP TFTP TFTP TFTP TFTP

69

UDP UDP UDP

Hôte A Hôte B Hôte C


Cyril Pain-Barre 1 - Rappels 23 / 97
Utilisation UDP : multidiffusion

UDP offre un service en mode non connecté


Une application peut ainsi exploiter la multidiffusion IP et
émettre un seul datagramme qui sera reçu par un ensemble de
stations, en utilisant comme destination, une adresse :
broadcast : diffusion dirigée à toutes les stations d’un réseau,
ou du réseau local pour l’adresse de diffusion limitée
(255.255.255.255)
multicast : adresses de classe D pour diffuser à un ensemble de
stations se trouvant éventuellement sur des réseaux différents
(les routeurs qui les séparent doivent être configurés pour cela).
Utilisées notamment pour la diffusion de médias audio/vidéo.

Exemple
Envoi par un client DHCP d’un message à tous les serveurs
DHCP du réseau local. L’adresse destination du message DHCP est
(255.255.255.255, UDP, 67)

Cyril Pain-Barre 1 - Rappels 24 / 97


Mise en œuvre du transfert fiable

Cyril Pain-Barre 1 - Rappels 25 / 97


Transfert fiable en mode connecté

Bien souvent les applications ont besoin d’échanger de gros


volumes de données de manière fiable
Exemples : FTP, SMTP, HTTP, . . .
Il est toujours possible d’offrir ce service en s’appuyant sur un
service non fiable non connecté comme IP ou UDP
Pour cela, on a besoin de quelques éléments essentiels :
les accusés de (bonne) réception (ACK)
des temporisateurs : alarmes qui expirent (timeout)
la numérotation des paquets (ou données)

Cyril Pain-Barre 1 - Rappels 26 / 97


Accusés de réception (ACK)

L’émetteur d’un paquet attend une confirmation de réception


de la part du récepteur avant d’envoyer un autre paquet
Le récepteur accuse réception d’un paquet en envoyant un
ACK
Émetteur Réseau Récepteur

émission paquet 1

réception paquet 1
envoi d’un ACK

réception ACK
émission paquet 2

Protocole de type envoyer et attendre

Cyril Pain-Barre 1 - Rappels 27 / 97


Temporisateurs
Des paquets peuvent être perdus dans le réseau
Si paquet ”perdu”, pas d’ACK donc blocage
Utilisation d’un timer armé lors de l’émission du paquet :
si expire (timeout), renvoie le paquet
si réception ACK avant expiration, désactivation du timer

Émetteur Réseau Récepteur

émission paquet 1
+ armement timer

timeout
émission paquet 1

envoi de l’ACK

Cyril Pain-Barre 1 - Rappels 28 / 97


Temporisateurs : problème de réglage
Scénario du timer trop court et mise en cause fiabilité :

Émetteur Réseau Récepteur


émission paquet 1
+ armement timer

timeout envoi de l’ACK


émission paquet 1

émission paquet 2
envoi de l’ACK

émission paquet 3

Le paquet 1 est accepté deux fois par le récepteur !


Le deuxième ACK est pris pour celui du paquet 2 !
Mais si timer trop long, on perd en efficacité. . .
Cyril Pain-Barre 1 - Rappels 29 / 97
ACK : problème de l’ACK perdu

Scénario de l’ACK perdu et mise en cause fiabilité :

Émetteur Réseau Récepteur

émission paquet 1
+ armement timer

envoi de l’ACK

timeout
émission paquet 1

envoi de l’ACK

émission paquet 2

Le paquet 1 est accepté 2 fois par le récepteur !

Cyril Pain-Barre 1 - Rappels 30 / 97


Numérotation des paquets et des ACK

Les paquets et les ACK portent des numéros : résoud les problèmes
d’ACK perdu et d’alarme trop courte.

Émetteur Réseau Récepteur

émission paquet 1
+ armement timer

envoi de l’ACK n°1


(paquet 2 attendu)

timeout
émission paquet 1

ignore paquet 1
envoi de l’ACK n°1

émission paquet 2

Cyril Pain-Barre 1 - Rappels 31 / 97


Numérotation des paquets et des ACK

Les paquets et les ACK portent des numéros : résoud les problèmes
d’ACK perdu et d’alarme trop courte.

Émetteur Réseau Récepteur

émission paquet 1
+ armement timer

timeout envoi de l’ACK n°1


émission paquet 1 (paquet 2 attendu)

émission paquet 2 ignore paquet 1


envoi de l’ACK n°1
accepte paquet 2
ACK n°1 ignoré envoi de l’ACK n°2
timeout
émission paquet 2

Cyril Pain-Barre 1 - Rappels 32 / 97


Fenêtre glissante (ou à anticipation)

Principe :
émettre n paquets sans attendre d’ACK (n est la taille de la
fenêtre)
fenêtre initiale (taille 8)

1 2 3 4 5 6 7 8 9 10 11 ...
envoyés envoi autorisé envoi interdit

un temporisateur par paquet émis


la réception du ACK du premier paquet de la fenêtre la fait
glisser :
la fenêtre a glissé

1 2 3 4 5 6 7 8 9 10 11 ...
acquittés envoyés envoi autorisé envoi interdit

Cyril Pain-Barre 1 - Rappels 33 / 97


Efficacité de la fenêtre glissante

La fenêtre glissante permet d’exploiter au mieux le réseau :

Émetteur Réseau Récepteur

émission paquet 1
émission paquet 2
émission paquet 3
envoi de l’ACK n°1
émission paquet 4
envoi de l’ACK n°2
émission paquet 5
envoi de l’ACK n°3
émission paquet 6
envoi de l’ACK n°4
émission paquet 7
envoi de l’ACK n°5
émission paquet 8
envoi de l’ACK n°6
émission paquet 9
envoi de l’ACK n°7

Cyril Pain-Barre 1 - Rappels 34 / 97


Fenêtre glissante et gestion des acquittements

Si un paquet de données est perdu, deux possibilités :


rejet total (ou global)

rejet sélectif

Cyril Pain-Barre 1 - Rappels 35 / 97


Fenêtre glissante et gestion des acquittements
Rejet total : aucun paquet suivant celui perdu n’est acquitté

Émetteur Réseau Récepteur


émission paquet 1
émission paquet 2
émission paquet 3
accepté : envoi de l’ACK n°1
émission paquet 4
accepté : envoi de l’ACK n°2
émission paquet 5
accepté : envoi de l’ACK n°3
émission paquet 6
émission paquet 7
rejeté : envoi de l’ACK n°3
émission paquet 8
rejeté : envoi de l’ACK n°3
émission paquet 9
rejeté : envoi de l’ACK n°3
timeout, réémission paquet 4
rejeté : envoi de l’ACK n°3
réémission paquet 5

⇒ la fenêtre en réception a une taille de 1


Cyril Pain-Barre 1 - Rappels 36 / 97
Fenêtre glissante et gestion des acquittements
Rejet sélectif : paquet de données i perdu
la fenêtre en réception a une certaine taille m (de préférence m = n)
ceux qui entrent dans la fenêtre sont gardés, les autres sont ignorés
mais les ACK pour ces paquets ont pour numéro i − 1
si timeout, l’émetteur n’envoie que le premier paquet non acquitté
lorsque paquet i réémis et reçu, l’ACK renvoyé est celui du dernier
paquet reçu (ou celui avant un autre paquet éventuellement perdu)

Fenêtre d’émission (taille 15) :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...

Fenêtre de réception (taille 10) :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...

Cyril Pain-Barre 1 - Rappels 37 / 97


Rejet sélectif : exemple

Émetteur Réseau Récepteur


émission paquet 1
émission paquet 2
émission paquet 3
émission paquet 4 accepté : envoi de l’ACK n°1
émission paquet 5
émission paquet 6 gardé : envoi de l’ACK n°1
émission paquet 7 gardé : envoi de l’ACK n°1
émission paquet 8 gardé : envoi de l’ACK n°1
émission paquet 9 gardé : envoi de l’ACK n°1
émission paquet 10 gardé : envoi de l’ACK n°1
émission paquet 11 gardé : envoi de l’ACK n°1
émission paquet 12 gardé : envoi de l’ACK n°1
réémission paquet 2 gardé : envoi de l’ACK n°1
émission paquet 13 gardé : envoi de l’ACK n°1
émission paquet 14 rejeté : envoi de l’ACK n°1
émission paquet 15 accepté : envoi de l’ACK n°11
émission paquet 16 gardé : envoi de l’ACK n°11
gardé : envoi de l’ACK n°11

émission paquet 17 gardé : envoi de l’ACK n°11

Cyril Pain-Barre 1 - Rappels 38 / 97


Rejet sélectif : amélioration par NACK

Envoi d’un (seul) NACK si récepteur se rend compte d’une erreur :


Émetteur Réseau Récepteur
émission paquet 1
émission paquet 2
émission paquet 3
émission paquet 4 accepté : envoi de l’ACK n°1
émission paquet 5
émission paquet 6 gardé : envoi de NACK n°2
émission paquet 7 gardé : envoi de l’ACK n°1
émission paquet 8 gardé : envoi de l’ACK n°1
émission paquet 9 gardé : envoi de l’ACK n°1
réémission paquet 2 gardé : envoi de l’ACK n°1
émission paquet 10 gardé : envoi de l’ACK n°1
émission paquet 11 gardé : envoi de l’ACK n°1
émission paquet 12 gardé : envoi de l’ACK n°9
émission paquet 13 gardé : envoi de l’ACK n°10
émission paquet 14 gardé : envoi de l’ACK n°11
émission paquet 15 gardé : envoi de l’ACK n°12
émission paquet 16 gardé : envoi de l’ACK n°13
émission paquet 17 gardé : envoi de l’ACK n°14

Cyril Pain-Barre 1 - Rappels 39 / 97


Transmission bidirectionnelle et superposition

Pour une transmission bidirectionnelle :


équiper les deux côtés de fenêtres d’émission et de réception
pas forcément de même taille de chaque côté !

amélioration par superposition ou piggybacking :


les paquets de données contiennent un indicateur ACK (oui ou
non le paquet contient aussi un ACK) et un champ no ACK :
... ACK Num ACK Num Paquet Données

Cyril Pain-Barre 1 - Rappels 40 / 97


Le protocole TCP : Transmission Control Protocol
(RFC 793 corrigée par RFC 1122 et 1323)

Cyril Pain-Barre 1 - Rappels 41 / 97


Propriétés du service de TCP

Orienté connexion : transfert de flots d’octets. La suite


d’octets remise au destinataire est la même que celle émise
Circuits virtuels : une fois une connexion demandée et
acceptée, les applications la voient comme un circuit dédié
Transferts tamponnés : quelle que soit la taille des blocs de
données émis par les applications, TCP est libre de les
découper ou de les regrouper
Connexions non structurées : pas de frontière placée par
TCP entre les messages émis par les applications
Connexions full-duplex : les données s’échangent dans les
deux sens (mais un côté peut libérer un sens de transmission
quand il n’a plus de données à émettre)

Cyril Pain-Barre 1 - Rappels 42 / 97


Adresse d’application, port et connexion
Comme pour UDP, l’adresse d’une application est un triplet (adresse
IP, TCP, port) : le serveur et le client doivent en posséder une. Le port
du client est généralement quelconque.
Mais à la différence d’UDP, on ne peut envoyer un message directement
à une adresse : il faut que le client établisse une connexion avec le
serveur. Ils ne peuvent échanger des messages que via une connexion
Établissement d’une connexion :
Serveur : effectue une ouverture passive en écoutant sur un port, c’est
à dire en demandant un port et en attendant qu’un client s’y connecte
Client : effectue une ouverture active en demandant l’établissement
d’une connexion entre son adresse et celle du serveur. Le serveur doit
être en écoute. Les modules TCP du client et du serveur intéragissent
pour établir cette connexion.
Une fois la connexion établie, le serveur et le client doivent l’utiliser
pour envoyer/recevoir des messages. TCP est chargé d’assurer la
fiabilité de la connexion (notamment s’occupe des acquittements/
retransmissions)
Cyril Pain-Barre 1 - Rappels 43 / 97
Serveurs et ports réservés TCP
Voir http://www.iana.org/assignments/port-numbers
Well known Port Assignment : certaines applications bien connues
ont des ports TCP réservés [0, 1023]. Exemples :
Num (décimal) Application
7 Serveur echo
13 Serveur daytime
20 Serveur FTP (données)
21 Serveur FTP (commandes)
22 Serveur SSH
23 Serveur TELNET
25 Serveur SMTP (transfert de mail)
53 Serveur DNS
80 Serveur HTTP (www)
119 Serveur NNTP (news)
les ports [1024, 49151] sont enregistrés (mais peuvent être utilisés)
les ports [49152, 65535] sont dits dynamiques et/ou à usage privé
Cyril Pain-Barre 1 - Rappels 44 / 97
Interface socket BSD (Unix) pour TCP
socket() et bind() ont la même fonction que pour UDP
int listen(int sock, int backlog)
(serveur) prépare le SAP pour une ouverture passive
int accept(int sock, struct sockaddr *addr, socklen t *addrlen)
(serveur) attend une demande de connexion (ouverture passive).
Renvoie un SAP pour la connexion établie et addr contient l’adresse du
client
int connect(int sock, const struct sockaddr *addr,
socklen t addrlen)
(client) demande l’établissement d’une connexion (ouverture active) au
serveur d’adresse addr
ssize t send(int sock, const void *buf, size t len, int flags)
envoie len octets contenus dans buf à travers la connexion sock
ssize t recv(int sock, void *buf, size t len, int flags)
reçoit dans buf au plus len octets de la connexion sock
int close(int sock) : libère un SAP (socket d’écoute ou connexion)
Cyril Pain-Barre 1 - Rappels 45 / 97
Ports et connexions

Plus complexe qu’UDP car un port peut être utilisé pour plusieurs
connexions simultanément :
un serveur peut accepter plusieurs clients à la fois : chaque appel
d’accept() retourne une nouvelle connexion utilisant le port du serveur
plus rare, un client peut aussi utiliser son port pour établir plusieurs
connexions (mais pas vers la même adresse serveur)
En dehors des SAP d’ouverture passive, TCP gère surtout des ”objets”
connexion
Une connexion est identifiée par le quadruplet formé avec l’adresse de
ses deux extrémités :
(adresse IP locale, port local, adresse IP distante, port distant)
Les connexions sont gérées indépendamment les unes des autres
Chaque connexion dispose de ses propres tampons en émission/
réception et de chaque côté

Cyril Pain-Barre 1 - Rappels 46 / 97


Ports et connexions : exemple

AppliB
(serveur)

Interface TCP

TCP

Hôte B
(139.124.187.4)

Cyril Pain-Barre 1 - Rappels 47 / 97


Ports et connexions : exemple

AppliB
(serveur) Ouverture passive

socket socket()
bind()
listen()
accept()

port 80

TCP

Hôte B
(139.124.187.4)

Cyril Pain-Barre 1 - Rappels 48 / 97


Ports et connexions : exemple

A1 AppliB
(client) (serveur)

socket Interface TCP

port 80

TCP TCP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 49 / 97


Ports et connexions : exemple

A1 AppliB
(client) (serveur)
Ouverture active

socket() socket Interface TCP


connect()

port 80

TCP TCP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 50 / 97


Ports et connexions : exemple

A1 AppliB
(client) (serveur)
Ouverture active

socket() socket socket socket Interface TCP


connect() E R E R

connexion #1

port 4321 port 80

TCP TCP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321)

Cyril Pain-Barre 1 - Rappels 51 / 97


Ports et connexions : exemple

A1 AppliB
(client) (serveur)

socket socket socket Interface TCP


E R E R

connexion #1

port 4321 port 80

TCP TCP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321)

Cyril Pain-Barre 1 - Rappels 52 / 97


Ports et connexions : exemple

A1 AppliB C1
(client) (serveur) (client)

socket socket socket

E R E R

connexion #1

port 4321 port 80

TCP TCP TCP

Hôte A Hôte B Hôte C


(32.128.54.97) (139.124.187.4) (195.10.134.12)

Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321)

Cyril Pain-Barre 1 - Rappels 53 / 97


Ports et connexions : exemple

A1 AppliB C1
(client) (serveur) (client)

socket socket socket socket socket

E R E R E R E R

connexion #1 connexion #2

port 4321 port 80 port 5678

TCP TCP TCP

Hôte A Hôte B Hôte C


(32.128.54.97) (139.124.187.4) (195.10.134.12)

Connexion #1 : (139.124.187.4, 80) et (32.128.54.97, 4321)


Connexion #2 : (139.124.187.4, 80) et (195.10.134.12, 5678)

Cyril Pain-Barre 1 - Rappels 54 / 97


Flots d’octets et segments

pour TCP une connexion sert à transmettre des flots d’octets


dans les deux sens
les flots sont transmis par des segments (PDU de TCP)
un segment est transmis dans un seul datagramme IP (sauf
fragmentation pendant l’acheminement)
l’émetteur confie à (son) TCP des blocs de données de taille
quelconque
le récepteur récupère des blocs de données de taille quelconque
mais le nombre d’octets transportés par un segment est
décidé par TCP :
pour des raisons d’efficacité
pour la régulation de flux

Cyril Pain-Barre 1 - Rappels 55 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 56 / 97


Flots d’octets et segments : exemple

AppliA AppliB
données à transmettre
send()

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 57 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R
placement dans le
tampon d’émission
connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 58 / 97


Flots d’octets et segments : exemple

AppliA AppliB
autres données à transmettre
send()

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 59 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie
placement dans le
tampon d’émission

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 60 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 TCP décide de transmettre port 80


un segment

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 61 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

en−tête TCP

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 62 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

en−tête IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 63 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP
traversée du réseau
(fragmentation possible)

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 64 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP
traversée du réseau
(fragmentation possible)

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 65 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 66 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

placement dans le
connexion établie tampon de réception

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 67 / 97


Flots d’octets et segments : exemple

AppliA AppliB

socket socket socket

E R E R

connexion établie

port 4321 port 80


TCP peut envoyer un ACK
maintenant ou plus tard

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 68 / 97


Flots d’octets et segments : exemple

AppliA AppliB
lecture des données
recv()

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 69 / 97


Flots d’octets et segments : exemple

AppliA AppliB

mise à jour des tampons

socket socket socket

E R E R

connexion établie

port 4321 port 80

TCP TCP

IP IP

Hôte A Hôte B
(32.128.54.97) (139.124.187.4)

Cyril Pain-Barre 1 - Rappels 70 / 97


Numéro de séquence et fenêtre glissante

Pour une transmission efficace, TCP utilise une fenêtre glissante


TCP n’acquitte pas les segments mais les octets reçus
Tous les octets de données transmis portent un numéro : le numéro de
séquence
Les acquittements indiquent le numéro du prochain octet attendu
La fenêtre glissante (émission) comporte alors 3 pointeurs :
Fenêtre d’émission

... 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ...

octets transmis octets transmis mais octets non encore transmis octets qu’on n’est pas encore
et acquités non encore acquittés mais qui peuvent l’être autorisé à transmettre

Chaque côté de la connexion possède une fenêtre d’émission et une


fenêtre de réception
Les acquittements peuvent transiter avec les données (superposition)

Cyril Pain-Barre 1 - Rappels 71 / 97


Taille de fenêtre variable et contrôle de flux
La fenêtre glissante n’a pas une taille fixe
Les segments (en particulier ACK) contiennent une information taille
de fenêtre :
segment avec taille = x
A B
... ... ... ... ... ... ...
fenêtre actuelle

A indique à B la place disponible dans son tampon de réception


La réaction de B dépend de la taille annoncée :
augmentation : B augmente sa fenêtre et envoie les octets
supplémentaires qu’elle comprend
B
... ... ... ... ... ... ...
fenêtre augmentée

diminution : lors du glissement, B diminue sa fenêtre (sans exclure les


octets qui y étaient déjà)
B
... ... ... ... ... ... ...
fenêtre diminuée
Cyril Pain-Barre 1 - Rappels 72 / 97
Format des segments TCP

Unité de données de protocole (PDU) échangée pour établir/libérer


une connexion et transférer/acquitter des données
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port TCP Source Port TCP Destination
partie fixe (20 octets)

Numéro de Séquence

Numéro d’Accusé de Réception


en−tête

LET Réservé Flags Fenêtre

Checksum Pointeur Urgent


taille variable

Options TCP (éventuelles)


Bourrage
taille variable

Données

Cyril Pain-Barre 1 - Rappels 73 / 97


Format des segments TCP

Unité de données de protocole (PDU) échangée pour établir/libérer


une connexion et transférer/acquitter des données
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port TCP Source Port TCP Destination
partie fixe (20 octets)

Numéro de Séquence

Numéro d’Accusé de Réception


en−tête

LET Réservé Flags Fenêtre

Checksum Pointeur Urgent


U A P R S F
taille variable

R C S S Y I
Options TCP (éventuelles)
G K H T N N
Bourrage

6 bits
taille variable

Données

Cyril Pain-Barre 1 - Rappels 74 / 97


Segment TCP : champ Numéro de séquence
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port TCP Source Port TCP Destination
partie fixe (20 octets)

Numéro de Séquence

Numéro d’Accusé de Réception


en−tête

LET Réservé Flags Fenêtre

Indique le numéro que porte Pointeur


Checksum le premier
Urgent
octet de données
taille variable

Options TCP (éventuelles)


Bourrage

premier octet
taille variable

Données

Cyril Pain-Barre 1 - Rappels 75 / 97


Segment TCP : champ LET
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port TCP Source à multiplierPort
parTCP Destination
4 pour
partie fixe (20 octets)

Numéro longueur de l’en−tête


de Séquence
(à cause
Numéro d’Accusé des options)
de Réception
en−tête

LET Réservé Flags Fenêtre

Checksum Pointeur Urgent


taille variable

Options TCP (éventuelles)


Bourrage
taille variable

Données

Cyril Pain-Barre 1 - Rappels 76 / 97


Segment TCP : champ Fenêtre
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Port TCP Source Port TCP Destination
partie fixe (20 octets)

Numéro de Séquence

Numéro d’Accusé de Réception


en−tête

LET Réservé Flags Fenêtre

Checksum Pointeur Urgent


taille variable

Options TCP (éventuelles)


Bourrage
indique la place disponible
dans le tampon de réception
taille variable

Données

Cyril Pain-Barre 1 - Rappels 77 / 97


Segment TCP : Checksum

Obligatoire
Vérifie la totalité du segment + Pseudo en-tête TCP.
Comme pour UDP, permet de s’assurer :
que les données sont correctes
que les ports sont corrects
que les adresses IP sont correctes
Même calcul que IP/UDP (bourrage éventuel 1 octet à 0) +
pseudo en-tête TCP
Pseudo en-tête TCP (interaction avec IP) : (12 octets)
bits :
0 1 1 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Adresse IP Source

Adresse IP Destination

Zone à Zéro Protocole Longueur Segment TCP

6 (en décimal) pour IP

Cyril Pain-Barre 1 - Rappels 78 / 97


Segment TCP : option MSS

Utilisée éventuellement pendant la phase de connexion (uniquement)


Format (4 octets) :
8 bits 8 bits

Type (2) Longueur Option (4)

Valeur MSS

Chaque côté indique la taille max des données des segments qu’il veut
recevoir, appelée MSS (Maximum Segment Size) :
souvent MTU - 40 (en-têtes IP et TCP sans option)
dépendant de la taille des buffers de reception
par défaut 536 (576 octets pour le datagramme IP)
Difficile à choisir pour l’Internet :
si trop petit, perte d’efficacité
si trop grand, risque de fragmentation
L’idéal est le plus grand tel qu’aucun datagramme n’est fragmenté

Cyril Pain-Barre 1 - Rappels 79 / 97


Données Urgentes (Hors Bande)
Émetteur veut envoyer des données en urgence, sans attendre que le
récepteur ait lu les données précédentes
Exemple : envoi de Ctrl-C pour arrêter le traitement de l’application
destinataire
Le TCP émetteur place les données urgentes et envoie immédiatement
le segment
Le TCP récepteur interrompt l’application destinataire (sous Unix,
signal SIGURG)
Mise en œuvre par bit URG et Pointeur Urgent :
si bit URG = 1 : données urgentes présentes et Pointeur Urgent indique
leur fin dans le segment (mais pas leur début)
si bit URG = 0 : pas de données urgentes, Pointeur Urgent ignoré

flags (6 bits)
16 bits
U A P R S F
R C S S Y I Pointeur Urgent
G K H T N N

Cyril Pain-Barre 1 - Rappels 80 / 97


Remise forcée

Application émettrice demande de ne pas retarder l’émission


des données, plutôt que de tamponner
Particulièrement utile dans le cas d’un terminal virtuel : après
le retour à la ligne, il faut envoyer, voire même pour chaque
caractère tapé ou déplacement de souris (X-Window)
TCP émetteur place le bit PSH à 1 :
flags (6 bits)

U A P R S F
R C S S Y I
G K H T N N

Le TCP récepteur doit remettre les données au plus vite (ne


pas tamponner dans sa mémoire)

Cyril Pain-Barre 1 - Rappels 81 / 97


Acquittements et Retransmissions

Le bit ACK à 1 indique que le champ Numéro d’Accusé de


Réception doit être utilisé
flags (6 bits)
32 bits
U A P R S F
R C S S Y I Numéro d’Accusé de Réception
G K H T N N

Un segment non acquitté est retransmis après timeout


Un segment retransmis peut contenir plus de données que le
précédent
Numéro ACK n’acquitte pas le segment : indique le numéro
du prochain octet attendu
L’ACK est cumulatif : a des avantages et des inconvénients
Rejet global ou sélectif (le plus courant)
En pratique l’émetteur ne renvoie que le premier segment non
acquitté

Cyril Pain-Barre 1 - Rappels 82 / 97


Établissement d’une connexion

U A P R S F
R C S S Y I
G K H T N N
En 3 temps, avec bits SYN et ACK
Émetteur Réseau Récepteur

Émission SYN, séq=x

Réception SYN
Émission SYN séq=y, ACK x+1

Réception SYN, ACK


Émission ACK y+1
(connexion établie)
Réception ACK
(connexion établie)

Permet d’ignorer des demandes retardées


Résoud aussi les connexions simultanées des deux côtés
Numéro de Séquence choisi (presque) aléatoirement dans
chaque sens

Cyril Pain-Barre 1 - Rappels 83 / 97


Libération d’une connexion
U A P R S F
R C S S Y I
G K H T N N
Processus en trois temps modifié, avec bits FIN et ACK
Connexion libérée lorsque chaque côté a indiqué qu’il n’avait plus de
données à émettre :
Émetteur Réseau Récepteur
Émission FIN séq=x

Réception FIN
Émission ACK x+1

Réception ACK des données peuvent


être transmises
plus de données
vers récepteur
Émission FIN séq=y, ACK x+1

Réception FIN
Émission ACK y+1
Armement timer
Réception ACK
Armement timer

À la fin, un temporisateur est utilisé pour laisser le temps aux segments


retardés d’arriver ou d’être détruits
Puis les données relatives à la connexion sont détruites
Cyril Pain-Barre 1 - Rappels 84 / 97
Fermeture brutale d’une connexion

Bit RST à 1 :
U A P R S F
R C S S Y I
G K H T N N

Signifie qu’il a y eu un problème grave


Connexion libérée immédiatement
Données non traitées/segments retardés sont perdus
Applications sont informées
Utilisé aussi pour refuser une demande de connexion

Cyril Pain-Barre 1 - Rappels 85 / 97


Temporisation et retransmission

Un segment (données) non acquitté doit être retransmis


Problèmes importants sur Internet :
comment calculer/estimer le RTT (Round Trip Time) ?
quelle durée du temporisateur ?

source : TCP/IP
Architecture, protocoles,
applications. D. Comer,
Edts Dunod

Cyril Pain-Barre 1 - Rappels 86 / 97


Ajustement dynamique du RTT estimé

Pour chaque connexion, TCP gère une variable RTT


Soit M = temps mis pour retour de l’ACK d’un segment
RTT est mis à jour selon la formule :

RTT = αRTT + (1 − α)M

où 0 ≤ α ≤ 1 (généralement 7/8) est le poids attribué à


l’anciennce valeur de RTT
Valeur du timer T = βRTT (à l’origine du standard β = 2)
Jacobson (1988) a proposé une amélioration du calcul de
RTT et de T , pour tenir compte de la variance. Devenu la
règle depuis 1989 :
Diff = M − RTT
RTT = RTT − δ × Diff , où généralement δ vaut 1/23
Dev = Dev + ρ × (|Diff | − Dev ), où généralement ρ vaut 1/22
T = RTT + η × Dev , où généralement η vaut 4

Cyril Pain-Barre 1 - Rappels 87 / 97


Ajustement dynamique du timer : exemple
En pointillés, des valeurs aléatoires de RTT. En trait plein, le timer
calculé :

source : TCP/IP Architecture, protocoles, applications. D. Comer, Edts Dunod

Cyril Pain-Barre 1 - Rappels 88 / 97


RTT et Algorithme de Karn

Problème : si un segment est retransmis et un ACK reçu,


doit-il être pris pour le premier ou le dernier segment ?
Selon le choix, le calcul de RTT et de T peut être
grandement faussé !
Algorithme de Karn (radio amateur) :
Ne pas mesurer M pour un segment retransmis
Mais augmenter T , selon la formule :

T =γ×T

où généralement γ vaut 2.

Cyril Pain-Barre 1 - Rappels 89 / 97


Timer et grandes variations RTT

source : TCP/IP
Architecture, protocoles,
applications. D. Comer,
Edts Dunod

Il reste des situations impossibles à prévoir mais la réaction est gé-


néralement très bonne.

Cyril Pain-Barre 1 - Rappels 90 / 97


Syndrome de la fenêtre stupide

Soit une application qui ne lit les données qu’octet par octet
L’émetteur envoie suffisamment d’octets pour remplir le
tampon de réception
Le TCP récepteur envoie une taille de fenêtre nulle
Lorsque l’application lit un octet, TCP enverra une taille de
fenêtre de 1
L’émetteur peut alors envoyer 1 octet !
Puis taille de fenêtre 0
etc.
C’est pas mieux si c’est l’émetteur qui envoie de lui-même des petits
segments !

Cyril Pain-Barre 1 - Rappels 91 / 97


Éviter la fenêtre stupide
Côté récepteur : (Algorithme de Clark) n’annoncer une
réouverture de la fenêtre que lorsque sa taille est :
soit égale à la moitié du tampon de réception
soit égale au MSS

Côté émetteur : (Algorithme de Nagle) retarder le plus


possible l’envoi :
si des données n’ont pas été acquittées, placer les nouvelles
données en tampon
ne les envoyer que si atteint taille maximale du segment ou la
moitié de la fenêtre d’émission
lorsqu’un ACK arrive, envoyer ce qu’il y a (même si le segment
n’est pas plein)
ceci même en cas de PUSH !
Il est parfois nécessaire de désactiver l’algo de Nagle, notam-
ment pour X-Window (il faut envoyer les mouvements de la
souris de suite et non les tamponner. . . ).
Cyril Pain-Barre 1 - Rappels 92 / 97
TCP et la congestion

La congestion produit des retards importants et des pertes de


datagrammes
Retransmettre des segments retardés/détruits aggrave la
congestion jusqu’à l’effondrement congestif
TCP en tient compte et cherche à éviter la congestion et
réagit en cas de congestion :
démarrage lent
diminution dichotomique
Nécessite la gestion d’une fenêtre de congestion
Fenêtre utilisée = min(Fenêtre récepteur, Fenêtre congestion)

Cyril Pain-Barre 1 - Rappels 93 / 97


TCP et la congestion : démarrage lent

Au début de la connexion ou suite à une congestion, effectuer


un démarrage lent avec fenêtre congestion = 1 segment
Démarrage lent : pour chaque segment acquitté, augmenter
de 1 segment la fenêtre de congestion
lent mais croissance exponentielle !

Cyril Pain-Barre 1 - Rappels 94 / 97


TCP et la congestion : diminution dichotomique

TCP estime que la perte d’un segment est due à la congestion


Si segment perdu, fixer un seuil à la moitié de la fenêtre de
congestion (taille mini = 1 segment)
Augmenter la temporisation (algo de Karn)
Recommencer un démarrage lent jusqu’à atteindre le seuil
phase d’évitement de congestion : à partir du seuil,
n’augmenter que de 1 segment pour l’ensemble des segments
acquittés (croissance linéaire)

Cyril Pain-Barre 1 - Rappels 95 / 97


TCP et la congestion : illustration

taille fenêtre
(nombre de segments)

17
non acquitté : nouvelle fenêtre (évitement à partir de 8)
16 + doublement temporisateur
15
14
13 non acquitté : nouvelle fenêtre
12 (évitement à partir de 6)
11 + doublement temporisateur

10
er
T et tim

9
8 er

er
tim
jour RT

tim
7
et

et
TT

TT
6

R
rR
mise à

ur
ou

jo
5

à
àj

e
is
se

m
mi

3
2
1
temps

démarrage lent évitement démarrage lent évitement


congestion congestion

Cyril Pain-Barre 1 - Rappels 96 / 97


Automate d’états fini de TCP
Début Fermé
transitions d’états :
événement / action, où : Ouverture
Fermer
passive

événement : Ouverture active / SYN

Écoute
italiques : primitive
appelée par le SYN / SYN + ACK

programme RST/− Émission / SYN

ACK, SYN, etc. : SYN SYN / SYN + ACK SYN


réception d’un segment reçu émis
Fermer /
tempo
avec ce bit positionné ACK / −
SYN + ACK / ACK
action :
ACK, SYN, etc. : envoi Fermer / FIN Connexion Attente
établie Fermer
FIN / ACK
segment
Fermer / FIN
- : rien Fermer / FIN

tempo : temporisation Fin FIN / ACK Fermer


Dernier

de 2 fois la durée de vie Attente−1 en cours


ACK
ACK /
tempo
d’un segment
ACK / − FIN + ACK / ACK ACK / −

en pointillés, les événements Fin Tempori−

exceptionnels Attente−2
FIN / ACK
sation

Cyril Pain-Barre 1 - Rappels 97 / 97