Cours 1 m3102 Dut2

M3102 - Services Réseaux
1 - Rappels : Ethernet, IP, ARP, ICMP, UDP, DNS, TCP
Cyril Pain-Barre
Département Informatique, Aix
version du 14/11/2017
Cyril Pain-Barre 1 - Rappels 1 / 97

Déroulement du module
CM 1 (2 h) : Rappels et BOOTP
CM 2 (2 h) : Fin BOOTP et DHCP
TD 1 (4 h) : Analyse/Capture/Production de trames, Fragmentation IP
CM 3 (2 h) : NAT/PAT
TD 2 (4 h) : TELNET et SSH
CM 4 (2 h) : Parefeux
TD 3 (2 h) : FTP et DHCP
TP 1 (4 h) : NAT/PAT, parefeux
TP 2 (4 h) : Administration LAN et routeurs CISCO - noté
Examen (2 h)
Tous les TD se font en salle machine !

Modèle OSI vs architecture TCP/IP
L’architecture TCP/IP (Internet) comprend 5 couches

Le modèle OSI de référence en contient 7 :
7 Application FTP, SMTP, HTTP, TELNET, ... DNS, ... DHCP, TFTP, ...
6 Présentation 5
Session
message
5
4 Transport TCP UDP 4
3 Réseau paquet IP (+ ICMP) 3

ARP
2 Liaison trame
Hôte−Réseau (ex: Ethernet/IEEE 802.3, PPP+ADSL, ...) 1−2
1 Physique bit
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

Ethernet/IEEE 802.3
implémente la couche Hôte-Réseau (Physique et Liaison)
envoi et réception de trames sans garantie de remise ni de délai
multiplexage : plusieurs réseaux (protocoles de niveau 3) peuvent
cohabiter sur Ethernet sans interférer (ni même le savoir)
trame Ethernet v2 contenant un datagramme IPv4 (EtherType en
hexa) :
EtherType données
Adresse MAC Adresse MAC
Préambule
Destination Source
08 00 Datagramme IPv4 CRC
(dé)multiplexage Ethernet v2 selon valeur de l’EtherType :

IEEE 802.1Q
ARP RARP IPv4 IPv6 ...
(trunk VLAN)
le protocole destinataire des données

0x8100 0x0806 0x8035 0x0800 0x86DD
est indiqué par le champ EtherType
trame
Ethernet V2 données

Ethernet/IEEE 802.3 : adressage MAC IEEE 802
adressage MAC pour identifiant unique d’une interface (carte) réseau
48 bits
OUI Id NIC
(Organizationally Unique Identifier) (Network Interface Controller)
3 octets 3 octets
Exemple : 00:24:9b:1d:3f:5b
plusieurs possibilités (d’adresse) de destination d’une trame :
unicast : seul l’hôte ayant cette adresse MAC est destinataire (s’il existe
et est actif) ;
multicast : un ensemble d’hôtes sont destinataires (ceux actifs et
paramétrés pour accepter cette adresse) ;
broadcast ff:ff:ff:ff:ff:ff : tous les hôtes (actifs) sont
destinataires (acceptent cette adresse).
Dans une adresse MAC, le bit de poids faible du premier octet est fixé
à 0 pour les adresses unicast et à 1 pour les adresses de multidiffusion
(multicast ou broadcast).
L’adresse en exemple est unicast.
Ethernet/IEEE 802.3 : partagé vs commuté
Évolutions d’Ethernet :
Ethernet partagé (obsolète) : bus ou hubs opérant au niveau bit
les hôtes se partagent le canal de communication −→ CSMA/CD
le domaine de collision est l’ensemble du réseau
les hôtes reçoivent toutes les trames
Ethernet commuté : commutateurs (switch) opérant au niveau trame
séparation des domaines de collision par les switchs
si que des switch et liaisons full-duplex : pas de collision donc pas de
CSMA/CD
auto-apprentissage :
les switchs observent les adresses sources des trames qui leur
parviennent et maintiennent une table MAC/port
un switch ne transmet une trame par inondation que si la destination
n’a pas de port associé
autres fonctionnalités : Spanning Tree Protocol, VLAN, priorités,
gestion à distance, etc.
Trames en multidiffusion toujours transmises à tous les hôtes (du VLAN)

Internet Protocol version 4 (IPv4) : couche réseau
regroupe les hôtes d’un réseau physique en un réseau IP logique

(partagent adresse IP du réseau)
adresses IPv4 uniformes pour les hôtes et les réseaux IP
tables de routage pour router les paquets (datagrammes) à travers les
réseaux
$ route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 139.124.187.1 0.0.0.0 UG 1024 0 0 eth0
139.124.187.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
131.38.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
fragmente les paquets pour s’adapter aux réseaux physiques

sous-jacents et à leur charge utile (payload)
service rendu de type best-effort : non fiable et non connecté (mode
datagramme)
=⇒ perte, duplication, déséquencement possible des paquets

Datagramme IPv4
en-tête : nombre variable d’octets (multiple de 4)
données : nombre quelconque d’octets (limité à 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
Fragmentation : produit plusieurs datagrammes qui diffèrent par le

bit More (dans Flags), le Déplacement, la Longueur Totale, les
Données (et le Total de Contrôle)
ARP : Address Resolution Protocol
Méthode de résolution d’adresse dynamique et décentralisée utilisée
dans les réseaux à diffusion (comme Ethernet) :
diffusion d’une requête demandant l’adresse MAC associée à une IP
=⇒ Qui possède l’adresse 139.124.187.1 ?
l’hôte concerné renvoie la réponse ARP en unicast
=⇒ C’est moi ! 139.124.187.1 est attribuée à mon interface d’adresse
MAC 00:23:89:57:5e:a3 !
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
où la taille des adresses dépend des réseaux physiques et logiques

ICMP : Internet Control and Error Message Protocol
module de la couche 3 associé à IP
qui assure deux fonctions principales :
rendre compte d’un problème réseau
tester l’accessibilité d’une machine
2 types de messages ICMP :
les messages d’erreur : transmis à la source du datagramme d’un
datagramme en erreur
les messages d’interrogation/information : messages divers contribuant
au (ou informant sur le) bon fonctionnement des équipements
Exemple : commande ping qui utilise des messages ECHO_REQUEST et
ECHO_REPLY
$ ping -c 3 139.124.187.1
PING 139.124.187.1 (139.124.187.1) 56(84) bytes of data.
64 bytes from 139.124.187.1: icmp_seq=1 ttl=255 time=9.49 ms
--- 139.124.187.1 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 7.578/19.602/41.734/15.669 ms

Envoi des messages ICMP
Les messages ICMP sont encapsulé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
mê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)
UDP et TCP : Protocoles de transport
Aller au-delà des limites d’IP et assurer, si possible, la correction
d’erreurs
2 protocoles de transport disponibles dans TCP/IP :
UDP : transport rapide, non connecté, permettant la multi-diffusion
TCP : transport fiable en mode connecté point-à-point
⇒ distinguent les applications au sein d’un même hôte
⇒ garantissent l’indépendance des communications
Protocoles de bout-en-bout : uniquement sur équipements terminaux
UDP et TCP fournissent chacun un ensemble de ports (entier non signé
sur 16 bits) indépendants :
une application doit demander (au moins) un port UDP et/ou TCP pour
communiquer en utilisant le service de transport correspondant
des ports sont réservés pour des services particuliers
L’adresse d’une application Internet est le triplet :

(adresse IP, protocole de transport, numéro de port)

Démultiplexage des ports UDP et TCP
applications UDP applications UDP/TCP applications TCP
DHCP DHCP TFTP ... DNS ... FTP SMTP HTTP ...
(serveur) (client)
68 53 53 21 25
69 selon Port 80
67
UDP ICMP TCP
17 1 6
selon champ Protocole
ARP IPv4 IPv6
0x0806 0x0800 0x86DD
selon champ EtherType
Ethernet

Le protocole UDP : User Datagram Protocol
(RFC 768)

Services d’UDP
UDP repose sur IP à qui il confie l’acheminement de ses messages
d’un ordinateur à un autre.
Service rendu :
envoi/réception de messages entre applications (processus) à
travers Internet
adressage des applications par numéro de port
multiplexage/démultiplexage par numéros de port
contrôle facultatif de l’intégrité des données
Même type de service non fiable, non connecté que IP :

possibilité de perte, duplication, déséquencement de messages
pas de régulation de flux
Un programme utilisant UDP doit gérer lui-même ces

problèmes si besoin !
Format des datagrammes UDP
En-tête : pas d’option possible, nombre fixe d’octets = 8

Donné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

Champs UDP : ports source et destination
Port UDP Source : indique le numéro de port de l’émetteur.

Peut être à 0 si aucune réponse n’est attendue.
Port UDP Destination : numéro de port du destinataire. Si ce
port n’a été alloué à aucun processus, UDP renverra un
message ICMP de destination inaccessible car port non alloué
(type 3, code 3) et détruit le datagramme
Démultiplexage UDP selon le port destination :
Appli 1 Appli 2 Appli 3
port x port y port z
UDP
selon champ Protocole (17)
IP

Serveurs et ports réservés UDP
Voir http://www.iana.org/assignments/port-numbers
Well known Port Assignment : certaines applications bien connues
ont des ports UDP réservés [0, 1023]
Exemples :
Num (dé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 enregistrés (mais peuvent être utilisés)
les ports [49152, 65535] sont dits dynamiques et/ou à usage privé
Champs UDP : Checksum
Facultatif : tout à 0 si non calculé

Vérifie la totalité du datagramme + Pseudo en-tête UDP.
Permet de s’assurer :
que les données sont correctes
que les ports sont corrects
que les adresses IP sont correctes
Même calcul que IP sur tout le datagramme UDP (bourrage
éventuel 1 octet à 0) + pseudo en-tête UDP
Pseudo en-tê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
Zone à Zéro Protocole Longueur Datagramme UDP
17 (en décimal) pour IP

Interface socket BSD (Unix) pour UDP
int socket(int domain, int type, int protocol) : retourne un Service
Access Point (SAP) auprès d’UDP, utilisé en premier paramètre des
primitives ci-aprè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, à l’adresse to
ssize t recvfrom(int sock, void *buf, size t len, int flags,

struct sockaddr *from, socklen t *fromlen)
reçoit dans buf un message d’au plus len octets ; l’adresse de l’émetteur
est placée dans from
int close(int sock) : libère le SAP

Modèle Client/Serveur utilisant UDP
Le serveur est démarré sur un ordinateur en écoute sur un port. Son
adresse est le triplet : (adresse IP, UDP, port)
L’écoute consiste à attendre qu’un message parvienne à ce port ; les clients
devront connaı̂tre le port du serveur (intérêt des ports réservés)
Le client envoie une requête au serveur (à son adresse) :
pour recevoir une réponse du serveur, il doit avoir acquis un numéro de port
UDP. Le plus souvent, ce port est quelconque. Rares sont les clients (comme
BOOTP/DHCP) qui nécessitent un port précis.
la requête est un message applicatif : suite d’octets constituant un PDU
(Protocol Data Unit) du protocole qu’implémentent le client et le serveur.
UDP fabrique un datagramme UDP avec pour champ Données ce message,
et pour champ Port Destination celui du serveur. Le Port Source est celui du
client.
Le datagramme UDP est ensuite envoyé via un datagramme IP avec les
adresses IP du serveur (destination) et du client (source).
Le serveur reçoı̂t le message du client, ainsi que son adresse. Il peut alors
traiter le message et répondre au client.
Selon le protocole, la discussion peut se poursuivre, ou s’arrêter là.
Files d’attente et réception
Attribution de port ⇒ allocation file d’attente

Réception d’un datagramme :
port destination non attribué : destruction + message ICMP
port alloué : si file non pleine, ajouté dans la file,
sinon détruit (pas de message ICMP !)
Appli consomme les éléments de la file, par accès synchrone :
si aucun datagramme, processus placé en attente
sinon, consommation du premier datagramme (FIFO)
Une application peut demander plusieurs ports

Utilisation UDP : modèle requête/réponse
Soit AppliB qui utilise 2 ports :

si reçoit datagramme sur port x, renvoie les données en
majuscules
si reçoit datagramme sur port y, renvoie les données à l’envers
pour ce genre de service, AppliB peut traiter les datagrammes
au fûr et à mesure
A1 A2 AppliB C1
x y
UDP UDP UDP
Hôte A Hôte B Hôte C

Utilisation UDP : multidiffusion
UDP offre un service en mode non connecté

Une application peut ainsi exploiter la multidiffusion IP et
émettre un seul datagramme qui sera reçu par un ensemble de
stations, en utilisant comme destination, une adresse :
broadcast : diffusion dirigée à toutes les stations d’un réseau,
ou du réseau local pour l’adresse de diffusion limitée
(255.255.255.255)
multicast : adresses de classe D pour diffuser à un ensemble de
stations se trouvant éventuellement sur des réseaux différents
(les routeurs qui les séparent doivent être configurés pour cela).
Utilisées notamment pour la diffusion de médias audio/vidéo.
Exemple
Envoi par un client DHCP d’un message à tous les serveurs
DHCP du réseau local. L’adresse destination du message DHCP est
(255.255.255.255, UDP, 67)

Mise en œuvre du transfert fiable

Transfert fiable en mode connecté
Bien souvent les applications ont besoin d’échanger de gros

volumes de données de manière fiable : tous les messages
envoyés doivent être reçus et remis au destinataire dans le bon
ordre
Exemples : FTP, SMTP, HTTP, . . .
Il est toujours possible d’offrir ce service en s’appuyant sur un
service non fiable non connecté comme IP (ou UDP)
Pour cela, on a besoin de quelques éléments essentiels :
les accusés de (bonne) réception (ACK)
des temporisateurs : alarmes qui expirent (timeout)
la numérotation des paquets (ou données)

Accusés de réception (ACK)
L’émetteur d’un paquet attend une confirmation de réception

de la part du récepteur avant d’envoyer un autre paquet
Le récepteur accuse ré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

Temporisateurs
Des paquets peuvent être perdus dans le réseau
Si paquet ”perdu”, pas d’ACK donc blocage
Utilisation d’un timer armé lors de l’émission du paquet :
si expire (timeout), renvoie le paquet
si réception ACK avant expiration, désactivation du timer
émission paquet 1
+ armement timer
timeout
émission paquet 1
envoi de l’ACK

Temporisateurs : problème de réglage
Scénario du timer trop court et mise en cause fiabilité :

é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 accepté deux fois par le récepteur !

Le deuxième ACK est pris pour celui du paquet 2 !
Mais si timer trop long, on perd en efficacité. . .
ACK : problème de l’ACK perdu
Scénario de l’ACK perdu et mise en cause fiabilité :
émission paquet 1
+ armement timer
envoi de l’ACK
timeout
émission paquet 1
envoi de l’ACK
émission paquet 2
Le paquet 1 est accepté 2 fois par le récepteur !

Numérotation des paquets et des ACK
Les paquets et les ACK portent des numéros : résoud les problèmes
d’ACK perdu et d’alarme trop courte.
émission paquet 1
+ armement timer
envoi de l’ACK n°1

(paquet 2 attendu)
timeout
émission paquet 1
ignore paquet 1
émission paquet 2

Numérotation des paquets et des ACK
Les paquets et les ACK portent des numéros : résoud les problèmes
d’ACK perdu et d’alarme trop courte.
émission paquet 1
+ armement timer
timeout envoi de l’ACK n°1

émission paquet 1 (paquet 2 attendu)
émission paquet 2 ignore paquet 1

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

Fenêtre glissante (ou à anticipation)
Principe :
émettre n paquets sans attendre d’ACK (n est la taille de la
fenê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 émis

la réception du ACK du premier paquet de la fenê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

Efficacité de la fenêtre glissante
La fenêtre glissante permet d’exploiter au mieux le réseau :
émission paquet 1
émission paquet 2
émission paquet 3
émission paquet 4
émission paquet 5
émission paquet 6
émission paquet 7
émission paquet 8
émission paquet 9

Fenêtre glissante et gestion des acquittements
Si un paquet de données est perdu, deux possibilités :

rejet total (ou global)
rejet sélectif

Rejet total : aucun paquet suivant celui perdu n’est acquitté

émission paquet 1
émission paquet 2
émission paquet 3
accepté : envoi de l’ACK n°1
émission paquet 4
émission paquet 5
émission paquet 6
émission paquet 7
rejeté : envoi de l’ACK n°3
émission paquet 8
émission paquet 9
timeout, réémission paquet 4
réémission paquet 5
⇒ la fenêtre en réception a une taille de 1

Rejet sélectif : paquet de données i perdu
la fenêtre en réception a une certaine taille m (de préférence m = n)
ceux qui entrent dans la fenêtre sont gardés, les autres sont ignorés
mais les ACK pour ces paquets ont pour numéro i − 1
si timeout, l’émetteur n’envoie que le premier paquet non acquitté
lorsque paquet i réémis et reçu, l’ACK renvoyé est celui du dernier
paquet reçu (ou celui avant un autre paquet é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 ...

Rejet sélectif : exemple

é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
réémission paquet 2 gardé : envoi de l’ACK n°1
émission paquet 14 rejeté : envoi de l’ACK n°1
gardé : envoi de l’ACK n°11

Rejet sélectif : amélioration par NACK
Envoi d’un (seul) NACK si récepteur se rend compte d’une erreur :

émission paquet 1
émission paquet 2
émission paquet 3
émission paquet 5
émission paquet 6 gardé : envoi de NACK n°2
réémission paquet 2 gardé : envoi de l’ACK n°1

Transmission bidirectionnelle et superposition
Pour une transmission bidirectionnelle :

équiper les deux côtés de fenêtres d’émission et de réception
pas forcément de même taille de chaque côté !
amélioration par superposition ou piggybacking :

les paquets de donné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

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

Propriétés du service de TCP
Orienté connexion : transfert de flots d’octets. La suite

d’octets remise au destinataire est la même que celle émise
Circuits virtuels : une fois une connexion demandée et
acceptée, les applications la voient comme un circuit dédié
Transferts tamponnés : quelle que soit la taille des blocs de
données émis par les applications, TCP est libre de les
découper ou de les regrouper
Connexions non structurées : pas de frontière placée par
TCP entre les messages émis par les applications
Connexions full-duplex : les données s’échangent dans les
deux sens (mais un côté peut libérer un sens de transmission
quand il n’a plus de données à émettre)

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 posséder une. Le port
du client est généralement quelconque.
Mais à la différence d’UDP, on ne peut envoyer un message directement
à une adresse : il faut que le client établisse une connexion avec le
serveur. Ils ne peuvent échanger des messages que via une connexion
Établissement d’une connexion :
Serveur : effectue une ouverture passive en écoutant sur un port, c’est
à dire en demandant un port et en attendant qu’un client s’y connecte
Client : effectue une ouverture active en demandant l’établissement
d’une connexion entre son adresse et celle du serveur. Le serveur doit
être en écoute. Les modules TCP du client et du serveur intéragissent
pour établir cette connexion.
Une fois la connexion établie, le serveur et le client l’utilisent pour
envoyer/recevoir des octets (messages). TCP est chargé d’assurer la
fiabilité de la connexion (notamment s’occupe des acquittements/
retransmissions)
Serveurs et ports réservés TCP
Voir http://www.iana.org/assignments/port-numbers
Well known Port Assignment : certaines applications bien connues
ont des ports TCP réservés [0, 1023]. Exemples :
Num (décimal) Application
7 Serveur echo
13 Serveur daytime
20 Serveur FTP (donné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 enregistrés (mais peuvent être utilisés)
les ports [49152, 65535] sont dits dynamiques et/ou à usage privé
Interface socket BSD (Unix) pour TCP
socket() et bind() ont la même fonction que pour UDP
int listen(int sock, int backlog)
(serveur) pré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 établie et addr contient l’adresse du
client
int connect(int sock, const struct sockaddr *addr,
socklen t addrlen)
(client) demande l’é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 à travers la connexion sock
ssize t recv(int sock, void *buf, size t len, int flags)
reçoit dans buf au plus len octets de la connexion sock
int close(int sock) : libère un SAP (socket d’écoute ou connexion)
Ports et connexions
Plus complexe qu’UDP car un port peut être utilisé pour plusieurs
connexions simultanément :
un serveur peut accepter plusieurs clients à 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 établir plusieurs
connexions (mais pas vers la même adresse serveur)
En dehors des SAP d’ouverture passive, TCP gère surtout des ”objets”
connexion
Une connexion est identifiée par le quadruplet formé avec l’adresse de
ses deux extrémités :
(adresse IP locale, port local, adresse IP distante, port distant)
Les connexions sont gérées indépendamment les unes des autres
Chaque connexion dispose de ses propres tampons en émission/
réception et de chaque côté

Ports et connexions : exemple
AppliB
(serveur)
Interface TCP
TCP
Hôte B
(139.124.187.4)

AppliB
(serveur) Ouverture passive
socket socket()
bind()
listen()
accept()
port 80
TCP
Hôte B
(139.124.187.4)

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)

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)

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)

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)

A1 AppliB C1
(client) (serveur) (client)
socket socket socket
E R E R
connexion #1
port 4321 port 80
TCP TCP TCP

(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)

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

(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)

Flots d’octets et segments
pour TCP une connexion sert à 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’émetteur confie à (son) TCP des blocs de données de taille
quelconque
le récepteur récupère des blocs de données de taille quelconque
mais le nombre d’octets transportés par un segment est
décidé par TCP :
pour des raisons d’efficacité
pour la régulation de flux

Flots d’octets et segments : exemple
AppliA AppliB
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)

AppliA AppliB
données à transmettre
send()
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)

AppliA AppliB
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)

AppliA AppliB
autres données à transmettre
send()
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
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)

AppliA AppliB
lecture des données
recv()
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)

AppliA AppliB
mise à jour des tampons
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)

Numéro de séquence et fenêtre glissante
Pour une transmission efficace, TCP utilise une fenêtre glissante

TCP n’acquitte pas les segments mais les octets reçus
Tous les octets de données transmis portent un numéro : le numéro de
séquence
Les acquittements indiquent le numéro du prochain octet attendu
La fenêtre glissante (é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 côté de la connexion possède une fenêtre d’émission et une

fenêtre de réception
Les acquittements peuvent transiter avec les données (superposition)

Taille de fenêtre variable et contrôle de flux
La fenêtre glissante n’a pas une taille fixe
Les segments (en particulier ACK) contiennent une information taille
de fenêtre :
segment avec taille = x
A B
... ... ... ... ... ... ...
fenêtre actuelle
A indique à B la place disponible dans son tampon de réception

La réaction de B dépend de la taille annoncée :
augmentation : B augmente sa fenêtre et envoie les octets
supplémentaires qu’elle comprend
B
... ... ... ... ... ... ...
fenêtre augmentée
diminution : lors du glissement, B diminue sa fenêtre (sans exclure les

octets qui y étaient déjà)
B
... ... ... ... ... ... ...
fenêtre diminuée
Format des segments TCP
Unité de données de protocole (PDU) échangée pour établir/libérer

une connexion et transférer/acquitter des donné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
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

Format des segments TCP
Unité de données de protocole (PDU) échangée pour établir/libérer

une connexion et transférer/acquitter des donné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

en−tête

U A P R S F
taille variable
R C S S Y I
G K H T N N
Bourrage
6 bits
taille variable
Données

Segment TCP : champ Numéro de sé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

en−tête
Indique le numéro que porte Pointeur

Checksum le premier
Urgent
octet de données
taille variable

Bourrage
premier octet
taille variable
Données

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
Numéro longueur de l’en−tête

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

taille variable

Bourrage
taille variable
Données

Segment TCP : champ Fenê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

en−tête

taille variable

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

Segment TCP : Checksum
Obligatoire
Vérifie la totalité du segment + Pseudo en-tête TCP.
Comme pour UDP, permet de s’assurer :
que les données sont correctes
que les ports sont corrects
que les adresses IP sont correctes
Même calcul que IP/UDP (bourrage éventuel 1 octet à 0) +
pseudo en-tête TCP
Pseudo en-tê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
Zone à Zéro Protocole Longueur Segment TCP
6 (en décimal) pour IP

Segment TCP : option MSS
Utilisée éventuellement pendant la phase de connexion (uniquement)

Format (4 octets) :
8 bits 8 bits
Type (2) Longueur Option (4)
Valeur MSS
Chaque côté indique la taille max des données des segments qu’il veut
recevoir, appelée MSS (Maximum Segment Size) :
souvent MTU - 40 (en-têtes IP et TCP sans option)
dépendant de la taille des buffers de reception
par défaut 536 (576 octets pour le datagramme IP)
Difficile à choisir pour l’Internet :
si trop petit, perte d’efficacité
si trop grand, risque de fragmentation
L’idéal est le plus grand tel qu’aucun datagramme n’est fragmenté

Données Urgentes (Hors Bande)
Émetteur veut envoyer des données en urgence, sans attendre que le
récepteur ait lu les données précédentes
Exemple : envoi de Ctrl-C pour arrêter le traitement de l’application
destinataire
Le TCP émetteur place les données urgentes et envoie immédiatement
le segment
Le TCP récepteur singale l’arrivée de données urgentes à l’application
destinataire (sous Unix, signal SIGURG)
Mise en œuvre par bit URG et Pointeur Urgent :
si bit URG = 1 : données urgentes présentes et Pointeur Urgent indique
leur fin dans le segment (mais pas leur début)
si bit URG = 0 : pas de données urgentes, Pointeur Urgent ignoré
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

Remise forcée
Application émettrice demande de ne pas retarder l’émission

des données, plutôt que de tamponner
Particulièrement utile dans le cas d’un terminal virtuel : après
le retour à la ligne, il faut envoyer, voire même pour chaque
caractère tapé ou déplacement de souris (X-Window)
TCP émetteur place le bit PSH à 1 :
flags (6 bits)
U A P R S F
R C S S Y I
G K H T N N
Le TCP récepteur doit remettre les données au plus vite (ne

pas tamponner dans sa mémoire)

Acquittements et Retransmissions
Le bit ACK à 1 indique que le champ Numéro d’Accusé de

Réception doit être utilisé
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 acquitté est retransmis après timeout

Un segment retransmis peut contenir plus de données que le
précédent
Numéro ACK n’acquitte pas le segment : indique le numéro
du prochain octet attendu
L’ACK est cumulatif : a des avantages et des inconvénients
Rejet global ou sélectif (le plus courant)
En pratique l’émetteur ne renvoie que le premier segment non
acquitté

É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
É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 retardées

Résoud aussi les connexions simultanées des deux côtés
Numéro de Séquence choisi (presque) aléatoirement dans
chaque sens

Libé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 modifié, avec bits FIN et ACK
Connexion libérée lorsque chaque côté a indiqué qu’il n’avait plus de
données à émettre :
É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
À la fin, un temporisateur est utilisé pour laisser le temps aux segments

retardés d’arriver ou d’être détruits
Puis les données relatives à la connexion sont détruites
Fermeture brutale d’une connexion
Bit RST à 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 problème grave

Connexion libérée immédiatement
Données non traitées/segments retardés sont perdus
Applications sont informées
Utilisé aussi pour refuser une demande de connexion

Temporisation et retransmission
Un segment (données) non acquitté doit être retransmis

Problèmes importants sur Internet :
comment calculer/estimer le RTT (Round Trip Time) ?
quelle durée du temporisateur ?
source : TCP/IP
Architecture, protocoles,
applications. D. Comer,
Edts Dunod

Ajustement dynamique du RTT estimé
Pour chaque connexion, TCP gère une variable RTT

Soit M = temps mis pour retour de l’ACK d’un segment
RTT est mis à jour selon la formule :
RTT = αRTT + (1 − α)M
où 0 ≤ α ≤ 1 (généralement 7/8) est le poids attribué à

l’anciennce valeur de RTT
Valeur du timer T = βRTT (à l’origine du standard β = 2)
Jacobson (1988) a proposé une amélioration du calcul de
RTT et de T , pour tenir compte de la variance. Devenu la
règle depuis 1989 :
Diff = M − RTT
RTT = RTT − δ × Diff , où généralement δ vaut 1/23
Dev = Dev + ρ × (|Diff | − Dev ), où généralement ρ vaut 1/22
T = RTT + η × Dev , où généralement η vaut 4

Ajustement dynamique du timer : exemple
En pointillés, des valeurs aléatoires de RTT. En trait plein, le timer
calculé :
source : TCP/IP Architecture, protocoles, applications. D. Comer, Edts Dunod

RTT et Algorithme de Karn
Problème : si un segment est retransmis et un ACK reçu,

doit-il être pris pour le premier ou le dernier segment ?
Selon le choix, le calcul de RTT et de T peut être
grandement faussé !
Algorithme de Karn (radio amateur) :
Ne pas mesurer M pour un segment retransmis
Mais augmenter T , selon la formule :
T =γ×T
où généralement γ vaut 2.

Timer et grandes variations RTT
source : TCP/IP
Architecture, protocoles,
applications. D. Comer,
Edts Dunod
Il reste des situations impossibles à prévoir mais la réaction est gé-

néralement très bonne.

Syndrome de la fenêtre stupide
Soit une application qui ne lit les données qu’octet par octet
L’émetteur envoie suffisamment d’octets pour remplir le
tampon de réception
Le TCP récepteur envoie une taille de fenêtre nulle
Lorsque l’application lit un octet, TCP enverra une taille de
fenêtre de 1
L’émetteur peut alors envoyer 1 octet !
Puis taille de fenêtre 0
etc.
C’est pas mieux si c’est l’émetteur qui envoie de lui-même des petits
segments !

Éviter la fenêtre stupide
Côté récepteur : (Algorithme de Clark) n’annoncer une
réouverture de la fenêtre que lorsque sa taille est :
soit égale à la moitié du tampon de réception
soit égale au MSS
Côté émetteur : (Algorithme de Nagle) retarder le plus

possible l’envoi :
si des données n’ont pas été acquittées, placer les nouvelles
données en tampon
ne les envoyer que si atteint taille maximale du segment ou la
moitié de la fenêtre d’émission
lorsqu’un ACK arrive, envoyer ce qu’il y a (même si le segment
n’est pas plein)
ceci même en cas de PUSH !
Il est parfois nécessaire de désactiver l’algo de Nagle, notam-
ment pour X-Window (il faut envoyer les mouvements de la
souris de suite et non les tamponner. . . ).
TCP et la congestion
La congestion produit des retards importants et des pertes de

datagrammes
Retransmettre des segments retardés/détruits aggrave la
congestion jusqu’à l’effondrement congestif
TCP en tient compte et cherche à éviter la congestion et
réagit en cas de congestion :
démarrage lent
diminution dichotomique
Nécessite la gestion d’une fenêtre de congestion
Fenêtre utilisée = min(Fenêtre récepteur, Fenêtre congestion)

TCP et la congestion : démarrage lent
Au début de la connexion ou suite à une congestion, effectuer

un démarrage lent avec fenêtre congestion = 1 segment
Démarrage lent : pour chaque segment acquitté, augmenter
de 1 segment la fenêtre de congestion
lent mais croissance exponentielle !

TCP et la congestion : diminution dichotomique
TCP estime que la perte d’un segment est due à la congestion

Si segment perdu, fixer un seuil à la moitié de la fenêtre de
congestion (taille mini = 1 segment)
Augmenter la temporisation (algo de Karn)
Recommencer un démarrage lent jusqu’à atteindre le seuil
phase d’évitement de congestion : à partir du seuil,
n’augmenter que de 1 segment pour l’ensemble des segments
acquittés (croissance linéaire)

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

Automate d’états fini de TCP
Début Fermé
transitions d’états :
événement / action, où : Ouverture
Fermer
passive
événement : Ouverture active / SYN
Écoute
italiques : primitive
appelée par le SYN / SYN + ACK
programme RST/− Émission / SYN
ACK, SYN, etc. : SYN SYN / SYN + ACK SYN

réception d’un segment reçu émis
Fermer /
tempo
avec ce bit positionné 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 durée de vie Attente−1 en cours

ACK
ACK /
tempo
d’un segment
ACK / − FIN + ACK / ACK ACK / −
en pointillés, les événements Fin Tempori−
exceptionnels Attente−2
FIN / ACK
sation

Cours 1 m3102 Dut2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours 1 m3102 Dut2

Uploaded by

Copyright:

Available Formats

M3102 - Services Réseaux

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

Département Informatique, Aix

Cyril Pain-Barre 1 - Rappels 1 / 97

Tous les TD se font en salle machine !

Cyril Pain-Barre 1 - Rappels 2 / 97

L’architecture TCP/IP (Internet) comprend 5 couches

4 Transport TCP UDP 4

3 Réseau paquet IP (+ ICMP) 3

Cyril Pain-Barre 1 - Rappels 3 / 97

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

le protocole destinataire des données

Cyril Pain-Barre 1 - Rappels 4 / 97

Trames en multidiffusion toujours transmises à tous les hôtes (du VLAN)

regroupe les hôtes d’un réseau physique en un réseau IP logique

fragmente les paquets pour s’adapter aux réseaux physiques

Cyril Pain-Barre 1 - Rappels 7 / 97

Identification Flags Déplacement

Time To Live Protocole Total de Contrôle

65 535 octets max

Fragmentation : produit plusieurs datagrammes qui diffèrent par le

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

adresse physique source

adresse protocole source

adresse physique destination

adresse protocole destination

où la taille des adresses dépend des réseaux physiques et logiques

--- 139.124.187.1 ping statistics ---

Cyril Pain-Barre 1 - Rappels 10 / 97

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

mais IP utilisant ICMP pour envoyer ses

les protocoles de transport (TCP et IP & ICMP

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

Cyril Pain-Barre 1 - Rappels 12 / 97

UDP ICMP TCP

ARP IPv4 IPv6

0x0806 0x0800 0x86DD

selon champ EtherType

Cyril Pain-Barre 1 - Rappels 13 / 97

Cyril Pain-Barre 1 - Rappels 14 / 97

Même type de service non fiable, non connecté que IP :

Un programme utilisant UDP doit gérer lui-même ces

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

Longueur Totale Checksum

Cyril Pain-Barre 1 - Rappels 16 / 97

Port UDP Source : indique le numéro de port de l’émetteur.

Appli 1 Appli 2 Appli 3

port x port y port z

selon champ Protocole (17)

Cyril Pain-Barre 1 - Rappels 17 / 97

Facultatif : tout à 0 si non calculé

Zone à Zéro Protocole Longueur Datagramme UDP

17 (en décimal) pour IP

Cyril Pain-Barre 1 - Rappels 19 / 97

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

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

int close(int sock) : libère le SAP

Cyril Pain-Barre 1 - Rappels 20 / 97

Attribution de port ⇒ allocation file d’attente

Cyril Pain-Barre 1 - Rappels 22 / 97

Soit AppliB qui utilise 2 ports :

UDP UDP UDP

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