Reseaux Nupped

Cours de réseaux classique
Introduction aux Réseaux et Internet Approche bottom-up
Frédéric Suter (Frederic.Suter@loria.fr) Applications

Utiliser des applications évoluées
M2 IMOI
Communiquer des données Transport
2006-2007 structurées
Connecter deux réseaux Réseau
Connecter deux ordinateurs

Liaison de données
Ouvrage de référence Envoyer des signaux sur un cable
Computer Networking : A top-Down Approach Featuring the Internet. Physique
Jim Kurose and Keith Ross. Addison-Wesley.
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2006-2007 1 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2006-2007 2 / 365
Pourquoi une approche Top-Down Plan du cours

Introduction
Approche top-down Qu’est-ce qu’Internet ? ; Les bords et le cœur du réseau ; Réseaux
d’accès ; Structure ; Délais et pertes ; Modèle en couches ; Historique.
Applications
Couche Application
Principes des applications ; Web et HTTP ; Transfert de fichiers ;
Courrier électronique ; DNS ; Pair-à-Pair ; Programmation socket.
Partir d’applications connues (Web, email, Transport
P2P), voir comment elles fonctionnent et Couche Transport
Services ; Multiplexage/Démultiplexage ; UDP ; TCP ; Contrôle de
comprendre comment aller de l’écriture Réseau
congestion ;
d’un mail jusqu’à sa réception en passant
par une suite de 0 et de 1 sur un cable Liaison de données Couche Réseau
OMG ; Circuit virtuels et réseaux de datagrammes ; Routeurs ; IP ;
Physique Routage.
Sécurité des réseaux
Qu’est-ce que la sécurité ? ; Authentification ; Intégrité ; Pare-feux ;
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2006-2007 3 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2006-2007 4 / 365
Première partie Première partie
Introduction Introduction
Objectifs Aperçu Qu’est-ce qu’Internet ?
Grandes lignes et Qu’est-ce qu’Internet ?
Les bords du réseau
terminologie Qu’est-ce qu’un protocole ?
Plus de détails Le cœur du réseau
dans les chapitres Le cœur du réseau Réseau d’accès
suivants
Accès au réseau Structure d’Internet
Approche :
exemple d’Internet Internet, structure des FAI
Délais et pertes dans les réseaux à commutation de paquets
Performances : pertes, délais
Couches de protocoles, modèles de Couches de protocoles, modèles de services
services Historique
Modèle de réseau
Internet : une vue d’ensemble Internet : une vue d’ensemble
Des protocoles contrôlant

Des millions d’ordinateurs l’émission et la réception de
connectés messages
Hôtes ou systèmes terminaux
Ex. : TCP, IP, HTTP, FTP, PPP
Exécutent des applications réseau
Internet : le réseau des
Des liens de communication
Cuivre, fibre optique, radio, satellite
réseaux
Faiblement hiérarchique
Taux de transfert = bande passante
Public vs. Intranet privé
Des routeurs
Standards Internet
Transmettent des paquets RFC : Request for comments
(morceaux d’information) IETF : Internet Engineering Task
Force
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 1 - Introduction 7 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 1 - Introduction 8 / 365
Internet : une vue orientée services Qu’est ce qu’un protocole
Protocoles humains Protocoles réseaux

Infrastructure de Quelle heure est-il ? Plutôt entre machines
communication J’ai une question ! Gouvernent toute activité
→ Applications distibuées de communication sur
Présentations
Web, email, jeux en réseau, partage Internet
de fichiers (MP3, DiVX)
Services de communication . . . Messages spécifiques Les protocoles définissent le

offerts aux applications envoyés format et l’ordre des messages
Non-connecté non-fiable envoyés et reçus par les entités
. . . Actions spécifiques
Connecté fiable
effectuées à la réception du réseau et les actions
des messages ou autres effectuées à la transmission ou
événements à la réception d’un message
Exemples de protocoles Plan
Qu’est-ce qu’Internet ?
Le cœur du réseau
Réseau d’accès
Structure d’Internet
Couches de protocoles, modèles de services
Historique
Zoom sur la structure du réseau Les bords du réseau
Systèmes terminaux (hôtes)

Exécutent les programmes
applicatifs
Ex. : Web, email
Bords du réseau
au “bord du réseau”
Applications et hôtes
Modèle client/serveur
Cœur du réseau Les hôtes client émettent des
Routeurs requêtes et reçoivent des services
Réseau des réseaux de serveurs toujours actifs
Ex. : Navigateur/Serveur Web,
Client/Serveur Mail
Liens de communication
Modèle pair-à-pair
Utilise peu (ou pas) de serveurs
dédiés
Ex. : Gnutella, KaZaA, Skype
Service orienté connexion Service non connecté
Objectif : transfert de Service TCP [RFC 793]

données entre systèmes Transfert de flux d’octets Objectif : transfert de Applications TCP
terminaux fiable et ordonné données entre systèmes HTTP (Web), FTP
Poignée de main : Si perte :
terminaux (transfert de fichiers),
établissement du Comme avant
dialogue accusés-réception et Telnet (connexion à
retransmissions UDP - User Datagram distance), SMTP (email)
Le ”bonjour, bonjour”
du protocole humain Contrôle de flot Protocol [RFC 768]
Fixe l’”état” des L’émetteur ne sature pas non connecté Applications UDP
hôtes communiquants le récepteur transfert non fiable
Pas de contrôle de flot
flux multimédia, vidéo
TCP - Transmission Control Contôle de congestion
Pas de contrôle de conférence, DNS,
Protocol
Réseau congestionné : congestion Téléphonie sur Internet
Service orienté connexion l’émetteur ”ralentit son
d’Internet taux d’émission”
Plan Le cœur du réseau

Interconnexion de routeurs
Question fondamentale :
Réseau d’accès Comment sont transférées les
données sur le réseau
Structure d’Internet Commutation de circuits : un
circuit dédié par appel (Téléphone)
Délais et pertes dans les réseaux à commutation de paquets Commutation de paquets : données
envoyées sur le réseau en morceaux
Historique
Commutation de circuits Commutation de circuits
Ressources réservées de bout

Ressources réseau (ex. : bande passante) découpées en morceaux
en bout pour un ”appel” Morceaux alloués aux appels
Pas de partage (ressources Ressource inactive si non utilisée par l’appel (pas de partage)
dédiées) Deux manières de découper
Par fréquence
Performances garanties
Par temps
Établissement de l’appel
nécessaire
Commutation de circuits : FDM et TDM Application numérique
FDM (frequency division multiplexing) Question

Combien de temps faut-il pour envoyer un fichier de 640 000 bits
de l’hôte A vers l’hôte B sur un réseau à commutation de circuit ?
fréquence Tous les liens ont une bande passante de 1,536 Mbps
Chaque lien utilise TDM avec 24 slots/sec
temps
Il faut 500 ms pour établir le circuit de bout en bout
4 utilisateurs
TDM (time division multiplexing)
Réponse (à compléter)
Débit réel du circuit : . . .
fréquence
Temps pour transférer le fichier : . . .
Temps total : . . .
temps
Application numérique Autre application numérique
Question Question
Combien de temps faut-il pour envoyer un fichier de 640 000 bits Combien de temps faut-il pour envoyer un fichier de 640 000 bits
de l’hôte A vers l’hôte B sur un réseau à commutation de circuit ? de l’hôte A vers l’hôte B sur un réseau à commutation de circuit ?
Tous les liens ont une bande passante de 1,536 Mbps Tous les liens ont une bande passante de 1,536 Mbps
Chaque lien utilise TDM avec 24 slots/sec Chaque lien utilise FDM avec 24 canaux/fréquence
Il faut 500 ms pour établir le circuit de bout en bout Il faut 500 ms pour établir le circuit de bout en bout
Réponse Réponse
Débit réel du circuit : 1.536Mbps/24 = 64kbps D’après vous ? ?
Temps pour transférer le fichier : 640000/64000 = 10 secondes
Réponse
Temps total : 10 + 0.5 = 10.5 secondes
C’est pareil que pour TDM !
Commutation de paquets Commutation de paquets : Multiplexage statistique
Division du flux de données en paquets
Partage des ressources par les paquets des utilisateurs A et B
Totalité de la bande passante pour un paquet
Utilisation des ressources quand nécessaire
Pas de division de la bande passante
Pas d’allocation ou de réservation de ressources dédiées
Dispute des ressources

Demande cumulée > Quantité de ressources disponible
Pas de motif fixe dans la séquence de paquets issus de A et de B
Congestion : file d’attente des paquets pour utilisation d’un lien
Partage à la demande ← multiplexage statistique
Stocker et Acheminer : avancée des paquets lien par lien
Réception complète d’un paquet avant de réémettre TDM : même hôte = même slot dans une trame TDM récurrente
Commutation de paquets ou de circuits Commutation de paquets ou de circuits
Plus d’utilisateurs avec la commutation de paquets Commutation de paquets : grand gagnant ?

Lien à 1 Mbps Bien pour les données éclatées
Utilisateur Partage de ressources
Émet 100 kbps si actif Plus simple, pas d’établissement de circuit
N utilisateurs
Actif 10% du temps
1 Mbps Congestion excessive : perte et délai de paquets
Commutation de circuits Besoin de protocoles avec fiabilité et contrôle de congestion
10 utilisateurs concurrents Peut-on simuler la commutation de circuits ?
Commutation de paquets Applications audio/vidéo → besoin de bande passante garantie
Avec 35 utilisateurs : probabilité d’avoir plus de 10 actifs < 0,0004 Problème toujours ouvert
Stocker et acheminer Réseaux à commutation de paquets : routage
Objectif
Transmettre des paquets de la source à la destination au travers de routeurs
Algorithmes de sélection de chemin (plus tard)
Réseau datagramme
Prend L/R secondes pour Exemple L’adresse de destination du paquet détermine le prochain saut
transmettre (pousser L = 7,5 Mbits Les routes peut changer au cours d’une session
dehors) un message de L R = 1,5 Mbps Analogie : conduire en demandant son chemin
bits sur un lien à R bps
Délai = 15 s
Tout le paquet doit arriver Réseau à circuit virtuel
sur le routeur avant son Chaque paquet porte un tag (identifiant du circuit virtuel)
Le tag détermine le prochain saut
transfert sur le lien suivant :
Un chemin fixe déterminé à la connexion (reste fixe ensuite)
stocker et acheminer Information conservée par les routeurs
Délai = 3L/R
Taxonomie des réseaux Plan
Réseaux de Qu’est-ce qu’Internet ?

télécommunication
Réseaux à Réseaux à
commutation de circuits commutation de paquets
Réseaux à Réseaux
FDM TDM circuits virtuels datagramme
Internet fournit aux applications des services en mode connecté (TCP) Historique
et en mode non-connecté (UDP)
Réseau d’accès Accès domestiques point à point
Accès via modem

Q : Comment connecter les Accès direct au routeur jusqu’à 56kbps (souvent moins)
systèmes terminaux aux Impossible de surfer et de téléphoner en même temps
routeurs périphériques ?
Accès domestiques
Accès institutionnels (fac, ADSL : Asymmetric Digital Subscriber Line
entreprise)
Jusqu’à 1Mbps en débit montant
Accès nomades
Caractéristiques Jusqu’à 10Mbps en débit descendant (20Mbps en dégroupé)

Bande passante (en bits par Découpage des fréquences
seconde) des réseaux d’accès ?
50 kHz - 1 MHz en débit descendant
Partagé ou dédié ?
4 kHz - 50 kHz en débit montant
0 kHz - 4 kHz pour le téléphone
Réseaux d’entreprise : Local Area Network Réseaux sans fil
Les LAN (local area network)

Connexion système
connectent les systèmes terminal/routeur par un réseau
terminaux des sans fil partagé
entreprises/universités aux Via une base appelée ”point d’accès”
routeurs périphériques
LAN sans fil
Ethernet 802.11b (Wifi) : 11 Mbps
Connexion système
802.11g : 54 Mbps
terminal/routeur : lien partagé ou
dédié A plus grande échelle
10 Mbps, 100Mbps, Gigabit Fourni par opérateurs de téléphonie
Ethernet WAP / GPRS / 3G (environ 384 kps)
A la maison Plan
Historique
Structure d’Internet : Réseau des réseaux Structure d’Internet : Réseau des réseaux
Vaguement hiérarchique FAI ”tier-2” : couverture régionale
Centre : FAI ”tier-1” → couverture nationale ou internationale Connectés à un ou plusieurs FAI tier-1
Se parlent d’égal à égal Et parfois à d’autres FAI tier-2
FAI FAI
Tier−2 Tier−2
FAI FAI
Tier−1 Tier−1
FAI
Tier−2
FAI FAI FAI FAI FAI
Tier−1 Tier−1 Tier−1 Tier−1
Tier−2
FAI FAI
Tier−2 Tier−2
Structure d’Internet : Réseau des réseaux Structure d’Internet : Réseau des réseaux
FAI ”tier-3” locaux Chemin d’un paquet
Clients de FAI tier-2 qui les connectent à Internet Traverse de nombreux réseaux
Plus proches des systèmes terminaux
FAI
FAI Local
FAI FAI
FAI Local Tier−3
FAI FAI Local
FAI Tier−3 Local FAI FAI
FAI FAI Local
Local Tier−2 Tier−2
Tier−2 Tier−2 FAI
FAI Tier−1
Tier−1
FAI
FAI Tier−2
Tier−2 FAI FAI FAI
FAI FAI FAI Tier−1 Tier−1
Tier−2
Tier−1 Tier−1 FAI FAI
Tier−2
FAI FAI Tier−2 Tier−2 FAI
Tier−2 Tier−2 FAI FAI FAI FAI Local
FAI FAI FAI Local Local Local Local
Local Local Local
Plan Comment perd-on des paquets et du temps ?
Les paquets font la queue sur le routeur
Les bords du réseau Taux d’arrivée >> capacité de sortie du lien
Chacun attend son tour
Réseau d’accès Paquet sur le point d’etre transmis (délai)
Délais et pertes dans les réseaux à commutation de paquets Paquets dans la file (délai)
Couches de protocoles, modèles de services Si plus de place dans la file

les paquets sont rejetés (perte)
Historique
Quatre sources de retard Quatre sources de retard
1. Traitement du nœud 2. File d’attente

Contrôle d’erreurs Temps d’attente pour transmission sur le lien de sortie
Détermination du lien de sortie Dépend du niveau de congestion du routeur
Quatre sources de retard Quatre sources de retard
3. Délai de transmission 4. Délai de propagation

R = bande passante (bps), L=Taille du paquet (bits) d = longueur du lien, s=vitesse de propagation ( 2 × 108 m/sec)
Temps d’envoi des bits sur le lien = L/R Délai de propagation = d/s
À noter : s et d sont des quantités très différentes
Analogie : caravane de voitures Analogie : caravane de voitures
100 kms 100 kms 100 kms 100 kms
Caravane de 10 voitures Péage Péage Caravane de 10 voitures Péage Péage
voiture = bit et caravane = paquet voiture = bit et caravane = paquet

Les voitures se ”propagent” à 100 km/h Les voitures se ”propagent” à 100 km/h
Chaque péage prend 12 secondes pour faire passer une voiture Chaque péage prend 12 secondes pour faire passer une voiture
(temps de transmission) (temps de transmission)
Question Réponse : 62 minutes

Combien de temps faut-il pour que la caravane soit alignée devant le Temps pour faire passer toute la caravane à travers le péage : 12 × 10 = 120sec.
Temps pour que la dernière voiture se propage jusqu’au second péage : 100 km / (100
second péage ? km/h) = 1h
Analogie : caravane de voitures (suite) Analogie : caravane de voitures (suite)
100 kms 100 kms
100 kms 100 kms

Caravane de 10 voitures Péage Péage
Les voitures se ”propagent” maintenant à 1000 km/h

Caravane de 10 voitures Péage Péage
Chaque passage de péage prend maintenant 1 minute
Les voitures se ”propagent” maintenant à 1000 km/h
Chaque passage de péage prend maintenant 1 minute Réponse : Oui
Après 7 mn la première voiture est au second péage et il en reste
Question 3 au premier
Des voitures arriveront-elles au deuxième péage avant que les toutes
les voitures aient passées le premier ? Conclusion
Le premier bit d’un paquet peut arriver au second routeur avant que le
paquet soit entièrement transmis par le premier routeur !
Délai d’un noeud Délai d’attente
dnoeud = dtrait + datt + dtrans + dprop

R : bande passante (bps)
L : taille du paquet (bits)
dtrait = délai de traitement a : taux moyen d’arrivée des
Généralement quelques microsecondes ou moins paquets
datt = délai d’attente → Intensité du traffic = LaR
Dépend de la congestion
dtrans = délai de transmission La/R proche de 0 : délai court
L/R, important pour les réseaux peu rapides La/R → 1 : le délai augmente
dprop = délai de propagation La/R > 1 : plus de travail arrive qu’il peut en être fait, le délai est
de quelques microsecondes à plusieurs centaines de millisecondes infini !
Perte de paquets Vrais routes et délais sur Internet
File d’attente (ou buffer) précédant le lien dans un routeur

A quoi ressemblent de ”vrais” délais et pertes sur Internet ?
→ Capacité finie
Programme traceroute → délais point-à-point (routeur à
Arrivée d’un paquet dans une file pleine routeur) de la source à la destination. Pour tout i :
→ Paquet rejeté (ou perdu) Envoie 3 paquets qui vont atteindre le routeur i sur le chemin
Retransmission possible des paquets perdus vers la destination
Par le nœud précédent Le routeur i renvoie ces paquets l’émetteur
Par l’hôte source qui mesure le temps entre envoi et réception
Pas de retransmission
Vrais routes et délais sur Internet Plan
traceroute : gaia.cs.umass.edu vers www.eurecom.fr Qu’est-ce qu’Internet ?
1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms
2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms
3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms
4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms
5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms Le cœur du réseau
6 abilene-vbns.abilene.ucaid.edu (198.32.11.9) 22 ms 18 ms 22 ms
7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms
8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms Réseau d’accès
9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms
10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms Structure d’Internet
11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms
12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms
13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms Délais et pertes dans les réseaux à commutation de paquets
14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms
15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms Couches de protocoles, modèles de services
16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms
17 * * *
18 * * * Historique
19 fantasia.eurecom.fr (193.55.113.142) 132 ms 128 ms 136 ms
”Couches” de protocoles Organisation du trafic aérien
Les réseaux sont

complexes !
Beaucoup d’entités
Question
Hôtes
Y a-t-il l’espoir d’une
Routeurs organisation structurée des
Liens de différents types réseaux ?
Applications Ou au moins de ce cours ?
Protocoles
Matériel, logiciel
Une suite d’étapes

Vue en couches du trafic aérien Pourquoi un modèle en couches ?
Les systèmes sont complexes

Structure explicite → identification des relations entre les
différentes parties
Modularité → facilité de maintenance et de mise à jour
Changer l’implantation d’une couche est transparent pour le reste
du système
Ex. : changer la procédure d’embarquement n’affecte pas le
Couches
contrôle aérien, ni la gestion des bagages.
Chacune implante un service
Via ses propres actions internes
Repose sur les services de la couche inférieure
Pile des protocoles Internet Encapsulation
Application : implante des

applications réseaux
FTP, SMTP, HTTP
Applications
Transport : Transfert de données
hôte à hôte
Transport
TCP, UDP
Réseaux : routage de datagrammes Réseau
de la source à la destination
IP, protocoles de routages Liaison de données
Liaison : Transfert de données entre
deux éléments réseau voisins Physique
PPP, Ethernet
Physique : Signaux sur un cable
Plan Histoire d’Internet
1961-1972 : premiers principes de la commutation de
paquets
Les bords du réseau 1961 : théorie de file d’attente ⇒ efficacité de la commutation de
paquets (Kleinrock)
1964 : commutation de paquets dans les réseaux militaires
Réseau d’accès (Baran)
1967 : ARPAnet (Advanced Research Projects Agency Network)
1969 : premier noeud opérationnel de ARPAnet
Délais et pertes dans les réseaux à commutation de paquets 1972
ARPAnet montré au public
NCP (Network Control Protocol) premier protocole de machine à
Historique machine
Premier programme de courrier électronique
ARPAnet a 15 noeuds
Histoire d’Internet Histoire d’Internet

1972-1980 : interconnexion, nouveaux réseaux et réseaux 1972-1980 : interconnexion, nouveaux réseaux et réseaux
propriétaires propriétaires
1970 : ALOHANet, réseau satellitaire à Hawaii (Kleinrock) 1970 : ALOHANet, réseau satellitaire à Hawaii (Kleinrock)
1973 : Metcalfe propose Ethernet dans sa thèse 1973 : Metcalfe propose Ethernet dans sa thèse
1974 : architecture des réseaux d’interconnexion (Cerf et Kahn)
Minimalité, autonomie : interconnexion sans changements internes

Modèle de service best effort
Routeurs sans états
Contrôle décentralisé
→ définissent l’architecture actuelle d’Internet
Histoire d’Internet Histoire d’Internet
1972-1980 : interconnexion, nouveaux réseaux et réseaux
propriétaires
1970 : ALOHANet, réseau satellitaire à Hawaii (Kleinrock) 1980-1990 : nouveaux protocoles, prolifération des réseaux
1973 : Metcalfe propose Ethernet dans sa thèse 1983 : déploiement de TCP/IP
1974 : architecture des réseaux d’interconnexion (Cerf et Kahn) 1982 : définition du protocole de mail SMTP
fin 70’s : architectures propriétaires : DECnet, SNA, XNA 1983 : définition de DNS pour la transformation nom / adresse IP
fin 70’s : commutation de paquets à taille fixe (précurseur d’ATM) 1985 : définition du protocole FTP
1979 ARPANET a 200 nœuds 1988 : contrôle de congestion dans TCP
Nouveaux réseaux nationaux : Csnet, BITnet, NSFnet, Minitel
100 000 hôtes connectés à une confédération de réseaux
Histoire d’Internet
1990-2000’s : commercialisation, Web et applications
début des 90’s : ARPAnet mis de coté
1991 : la NSF lève les restrictions sur l’utilisation commerciale de
NSFnet (mis de coté en 1995)
début des 90’s : le Web
Hypertext [Bush 1945, Nelson 1960’s]
HTML, HTTP : Berners-Lee
1994 : Mosaic (futur Netscape)
fin des 90’s : commercialisation du Web
Fin des 90’s- 2000’s :
Plus d’applications : messagerie instantanée, P2P (KaZaa)
Sécurité au premier rang
Env. 50 millions d’hôtes, 100 millions d’utilisateurs
Liens backbone au Gigabit par seconde
Résumé de l’introduction Deuxième partie
Une ”tonne” d’informations Couche Application

Apercu d’ensemble d’Internet
Qu’est-ce qu’un protocole ? Objectifs
Aspects conceptuels et pratiques des protocoles des applications réseau
Les bords, le cœur et les moyens d’accès du réseau
Modèles de services de niveau transport
Commutation de paquets vs. commutation de circuits Paradigme client-serveur
Structure d’Internet Paradigme Pair-à-Pair
Performances : pertes et délais Apprendre sur les protocoles au travers des protocoles de niveau application
Modèle en couches et de services les plus connus
HTTP
Historique FTP
SMTP/POP3/IMAP
Vous avez maintenant DNS
Le contexte, un aperçu et une idée de ce que sont les réseaux Programmation d’applications réseau
Plus de détails à venir ! API socket
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 1 - Introduction 62 / 365
Deuxième partie Quelques applications réseau
Couche Application Courrier électronique

Principes des applications réseau Web
Messagerie instantanée
Web et HTTP
Connexion à distance
FTP Partage de fichiers pair-à-pair
Courrier électronique Jeux en réseau
SMTP, POP3, IMAP Vidéo diffusion
DNS Téléphonie sur Internet
Vidéo conférence temps réel
Partage de fichiers pair-à-pair
Calcul massivement parallèle (SETI@Home)
Programmation socket ...
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2 - Couche Application 65 / 365
Créer une application réseau Plan
Principes des applications réseau

Écrire des programmes qui
Tournent sur différents systèmes
terminaux et Web et HTTP
communiquent sur un réseau
Ex. Web : le serveur web FTP
communique avec le navigateur
Courrier électronique
Des petits logiciels pour le SMTP, POP3, IMAP
cœur du réseau
Les entités du cœur n’exécutent
DNS
pas d’applications utilisateur
Applications sur les systèmes Partage de fichiers pair-à-pair
terminaux → développement et
déploiement rapides
Programmation socket
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2 - Couche Application 66 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 2 - Couche Application 67 / 365
Architecture des applications Architecture client-serveur
Serveur
Hôte toujours actif
Adresse IP permanente
Client - Serveur
Fermes de serveurs → passage à
Pair-à-Pair l’échelle
Hybride de client-serveur et de pair-à-pair Clients
Communiquent avec le serveur
Connexion intermittente (parfois)
Adresses IP dynamiques
Ne communiquent pas entre eux
Vraie architecture pair-à-pair Hybrides entre client-serveur et pair-à-pair
Napster
Serveur pas toujours actif
Systèmes terminaux
communiquent directement Recherche centralisée :
Enregistrement du contenu des pairs sur le serveur central
Pairs connectés de façon Requêtes sur le même serveur central pour trouver un fichier
intermittente
Changement d’adresses IP Messagerie instantanée
Ex. : Gnutella Deux utilisateurs qui ”chattent” → Pair-à-pair
Hautement extensible Détection de présence centralisée
Enregistrement de l’adresse IP sur le serveur central à la connexion
Mais difficile à gérer
Serveur central contacté pour trouver les adresses IP des contacts
Processus communiquants Sockets
Processus envoie/reçoit
Processus : programme vers/depuis sa socket
s’exécutant sur un hôte Processus client : initie la
communication Analogie avec une porte
Sur un même hôte : Un processus émetteur
communications Processus serveur : attend ”balance” des messages par la

porte
inter-processus (définies par d’être contacté
et se repose sur l’infrastructure
l’OS) de transport de l’autre coté
Note : applications P2P → pour acheminer le message
Entre deux hôtes : échange processus clients ET serveurs
de messages entre processus API : (1) choix du protocole de transport, (2) capacité de fixer
quelques paramètres (beaucoup plus de détails plus tard)
Identifier les processus Identifier les processus
Pour qu’un processus reçoive des messages, il doit posséder un Pour qu’un processus reçoive des messages, il doit posséder un
identifiant identifiant
Un hôte a une adresse IP unique de 32 bits Un hôte a une adresse IP unique de 32 bits
Question Réponse
Est-ce que l’adresse IP de l’hôte sur lequel s’exécute un processus
Non ! Plusieurs processus peuvent s’exécuter sur un même hôte
suffit pour l’identifier ?
Identifier les processus Ce qui est défini par un protocole de la couche

application
Types des messages échangés (messages de requêtes et de
Pour qu’un processus reçoive des messages, il doit posséder un
réponses)
identifiant
Syntaxe des types de messages (quels champs et délimitation des
Un hôte a une adresse IP unique de 32 bits
champs)
L’identifiant inclue l’adresse IP et un numéro de port associé au
Sémantique des champs (sens du contenu)
processus sur l’hôte
Règles d’envoi / réponses des / aux messages (quand et
Exemples de numéros de ports
Serveur HTTP → 80
comment)
serveur mail → 25
On en reparlera
Protocoles du domaine public
Définis par des RFC (Requests For Comments)
Interopérables
Ex. : HTTP, SMTP
Ce qui est défini par un protocole de la couche Services transport demandés par une application
application
Perte de données
Certaines applications supportent un peu de perte (audio)
Types des messages échangés (messages de requêtes et de D’autres nécessitent un transfert de données 100% fiable
réponses) (transfert de fichiers)
Syntaxe des types de messages (quels champs et délimitation des
champs) Temps de réponse
Sémantique des champs (sens du contenu) Certaines applications ont besoin de délais courts pour être
Règles d’envoi / réponses des / aux messages (quand et efficaces (téléphonie, jeux)
comment)
Bande passante
Protocoles propriétaires Certaines applications ont besoin d’un minimum de bande
Ex. : KaZaA passante pour être efficaces (multimédia)
D’autres utilise ce qu’elles peuvent avoir (applications élastiques)
Besoins d’applications courantes Services des protocoles transport d’Internet

Service TCP
Application Perte Bande passante Sensibilité Orienté connexion : poignée de mains nécessaire
Transfert non élastique non Transport fiable entre processus émetteur et récepteur
de fichiers Contrôle de flot : l’émetteur ne sature pas le récepteur
e-mail non élastique non Contôle de congestion : l’émetteur ralentit si le réseau est
Web non élastique non congestionné.
Audio/Vidéo oui audio : 5kbps-1Mbps 100’s msec
Ne fournit pas de garanties de délai et bande passante minimale
temps réel vidéo : 10kbps-5Mbps
Audio/Vidéo oui audio : 5kbps-1Mbps quelques
stocké vidéo : 10kbps-5Mbps sec.
Service UDP
Jeux oui quelques kbps de + 100’s msec Transfert de données non fiable entre processus émetteur et
Chat non élastique oui et non récepteur
Ne fournit pas de poignée de main, de fiabilité, contrôle de flot ou
de congestion, ni de garanties de délai et bande passante minimale
Quel protocole pour quelle application ? Plan
Application Protocole de Protocole de Web et HTTP

niveau Application niveau Transport
FTP
e-mail SMTP [RFC 2821] TCP
connexion à distance Telnet [RFC 854] TCP Courrier électronique
Web HTTP [RFC 2616] TCP SMTP, POP3, IMAP
transfert de fichiers FTP [RFC 959] TCP
flux audio/vidéo Propriétaire (real) TCP ou UDP DNS
Téléphonie Propriétaire TCP ou UDP
Web et HTTP Aperçu de HTTP
HTTP : HyperText Transfer Protocol

Protocole de niveau
Un peu de jargon application du Web
Page web composée d’objets Modèle client-serveur
Fichier HTML, image JPEG, applet Java, fichier audio, . . . Client : navigateur qui
demande, reçoit, et affiche des
Un fichier HTML de base contenant plusieurs objets référencés objets
Chaque objet adressable par une URL Serveur : serveur web qui
envoie des objets en réponse
www.uhp-nancy.fr/M2-IMOI/trombi.jpg Nom d’hôte + Nom de chemin
aux demandes
HTTP 1.0 → [RFC 1945]

HTTP 1.1 → [RFC 2068]
Aperçu de HTTP Connexions HTTP
Utilise TCP
1 Demande de connexion TCP du client au serveur (socket, port 80)
2 Le serveur accepte la connexion TCP HTTP non persistant
3 Échange de messages HTTP entre le navigateur (client HTTP) et Au plus un objet envoyé par connexion
le serveur Web (serveur HTTP) Utilisé par HTTP/1.0
4 Fermeture de la connexion TCP
HTTP persistant
HTTP est ”sans état” Plusieurs objets peuvent être envoyés lors d’une même connexion
Pas de conservation d’informations sur les requêtes passées
Utilisé par défaut dans HTTP/1.1
Un protocole qui conserve l’état est complexe !
Conservation de l’historique
En cas de panne, conciliation d’état inconsistants
HTTP non persistant HTTP non persistant
L’utilisateur veut l’URL : www.uhp-nancy.fr/M2-IMOI/index.html qui

L’utilisateur veut l’URL : www.uhp-nancy.fr/M2-IMOI/index.html qui
contient du texte et référence 10 images
contient du texte et référence 10 images
1a ) Client HTTP initie une connexion s

sur serveur HTTP (processus) de
www.uhp−nancy.fr sur le port 80 1b ) Serveur HTTP de l’hote 3 ) Serveur HTTP reçoit message
www.uhp−nancy.fr attend des de requete, crée un message
connexions TCP sur le port 80 de réponse contenant l’objet
accepte la connexion et notifie demandé et l’envoie sur sa socket
2 ) Client HTTP envoie un message le client
de requete (contenant l’URL) sur la 5 ) Client HTTP reçoit le message de
socket TCP. Le message indique réponse contenant le fichier HTML, 4 ) Fermeture de la connexion par
que le client veut l’objet l’affiche, l’interprètre et trouve 10 le serveur
M2−IMOI/index.html 3 ) Serveur HTTP reçoit message objets référencés
de requete, crée un message
de réponse contenant l’objet 6 ) Répétition des étapes 1 à 5 pour
demandé et l’envoie sur sa socket chacun des 10 objets
Temps
Temps
Modélisation du temps de réponse HTTP persistant
Définition du RTT Problèmes du HTTP non persistant

Round Trip time
2 RTT par objet
Temps mis par un petit paquet pour
aller du client au serveur et retour
Surcoût de l’OS pour chaque connexion TCP
Les navigateurs ouvrent plusieurs connexions TCP en parallèle
Temps de réponse pour récupérer les objets
1 RTT pour initier la connexion TCP
1 RTT pour la requête HTTP et les HTTP persistant
premiers octets de la réponse HTTP Le serveur laisse la connexion ouverte après l’envoi de la réponse
Temps de transmission du fichier
Les messages HTTP suivants sont envoyés sur la connexion déjà
Total = 2 RTT + temps de ouverte
transmission
HTTP persistant Message de requête HTTP

Deux types de messages HTTP : requête et réponse
Message de requête HTTP
Sans pipeline
Format ASCII (lisible)
Le client n’émet une nouvelle requête que lorsque la réponse
précédente est arrivée
1 RTT par objet référencé ligne de requête (commandes GET, POST, HEAD)
GET /repertoire/page.html HTTP 1.1
Avec pipeline lignes d’entête
Host : www.uhp-nancy.fr
Par défaut dans HTTP 1.1
User-agent : Mozilla/4.0
Requête émise dès la rencontre d’un objet référencé Connection : close
A peu près un RTT pour tous les objets référencés Accept-language : fr
Retour à la ligne supplémentaire
Format général d’un message HTTP Envoyer une information au serveur
Méthode Post
Formulaire dans une page Web
L’information saisie est transmise au serveur dans le corps du
message
Méthode URL
Utilise la méthode GET
La saisie est transmise dans le champ URL de la ligne de requête
www.uhp-nancy.fr/annuaire ?etudiants&IMOI
Types de méthodes Message de réponse HTTP
HTTP 1.0
GET ligne de statut (protocole, code + phrase de statut)
POST HTTP 1.1 200 OK
HEAD lignes d’entête
Demande au serveur de laisser l’objet demandé sans réponse Connection : close
Date : Tue, 19 Sep 2005 10 :12 :43 GMT
HTTP 1.1 Server : Apache/1.3.0 (Unix)
Last-Modified : Mon 18 Sep 2005 22 :48 :12 GMT
GET, POST, HEAD
Content-Length : 6821
PUT Content-Type : text/html
Charge un fichier du corps du message à l’adresse contenue dans le
champ URL
données (le fichier HTML demandé)
DELETE data data data data data ...
Supprime le fichier spécifié dans le champ URL
Codes HTTP de statut de réponse Essayer HTTP par soi même
Faites un telnet sur votre serveur web préféré
Dans la première d’une réponse du serveur à un client telnet www.loria.fr 80

200 OK succès, l’objet demandé est plus loin dans ce message Ouvre une connexion sur le port 80 sur www.loria.fr
301 Moved Permanently l’objet a été déplacé, voici la nouvelle Tout ce qui est tapé est envoyé sur ce port
adresse (Location :) Tapez une requête HTTP GET
400 Bad Request le serveur n’a pas compris la demande
GET / suter/ HTTP/1.1
404 Not Found le document demandé n’existe pas sur ce serveur Host : www.loria.fr
505 HTTP Version Not Supported
En tapant cela (avec deux fois entrée), vous envoyez la plus
petite requête GET complète au serveur HTTP
Regardez la réponse renvoyée par le serveur HTTP
Conservation d’état au moyen de cookies Les cookies

Quatre composants Utilisés pour
1 Ligne d’entête du cookie dans le message de réponse HTTP Autorisation
2 Ligne d’entête du cookie dans le message de requête HTTP Panier d’achats
3 Fichier cookie sur la machine de l’utilisateur, géré par son Profil de consommation
navigateur État de la session utilisateur (webmail)
4 Base de données sur le site web
Cookies et vie privée
Exemple
Les cookies permettent au site d’en apprendre beaucoup sur vous
Suzanne accède à Internet toujours depuis le même PC
Vous pouvez fournir vos nom et e-mail
Elle visite un certain site de vente en ligne pour la première fois
Les moteurs de recherche les utilisent pour en apprendre encore
Lorsque la première requête HTTP arrive sur le site, sont créés : plus
Un identifiant unique
Une entrée dans la base pour cet identifiant Les publicitaires obtiennent des informations
Caches web (serveurs proxy) Caches web
Objectif : Satisfaire la requête du client sans impliquer le serveur Détails

d’origine Agit à la fois comme client et comme serveur
Configuration du navigateur
Généralement installé par un FAI (université, entreprise, . . . )
pour passer par un cache
Le navigateur envoie toutes les
requêtes HTTP au cache Pourquoi mettre en cache ?
Objet dans le cache → retour Réduire le temps de réponse à une requête
de l’objet caché Réduire le trafic sur un lien d’accès
sinon → demande de l’objet au
serveur d’origine puis envoi à
Permet aux fournisseurs de contenu ”lent” de livrer efficacement
l’utilisateur leur contenu (comme pour le P2P)
Exemple de mise en cache Exemple de mise en cache

Hypothèses
Taille moyenne des objets = 100 Solution possible
000 bits
Augmenter la bande passante du
Taux moyen de requêtes des lien d’accès à 10 Mbps
navigateurs aux serveurs = 15/sec
Délai du routeur vers n’importe Conséquence
quel serveur et retour = 2 sec
Utilisation du LAN = 15%
Utilisation du lien d’accès = 15%
Conséquence
Délai total = Internet + accès +
Utilisation du LAN = 15%
LAN = 2sec + msec + msec
Utilisation du lien d’accès = 100%
Option chère !
LAN = 2sec + minutes + msec
Exemple de mise en cache GET conditionnel
Installation d’un cache

Taux d’accès supposé de 4
Objectif : ne pas envoyer l’objet si le cache contient une version à
Conséquence jour
40% des requêtes satisfaites Cache : spécifie la date de la copie cachée dans la requête HTTP
immédiatement
If-modified-since : <date>
60% satisfaites par les serveurs
Serveur : la réponse ne contient pas l’objet si la copie est à jour
Utilisation du lien d’accès réduite
à 60% → délais négligeables (10 HTTP/1.0 304 Not Modified
msec)
LAN = 0,6 *(2,01 sec) + msec <
1,4 secs
Plan FTP : protocole de transfert de fichiers
Web et HTTP
FTP
SMTP, POP3, IMAP
Transférer un fichier depuis/vers un hôte distant
DNS
Modèle client/serveur
Partage de fichiers pair-à-pair Client : coté qui initie le transfert
Serveur : hôte distant
Programmation socket Défini par la RFC 959
Serveur FTP écoute sur le port 21
Connexions de contrôle et de données séparées Commandes et réponses FTP
Commandes
texte ASCII sur la connexion de contrôle
USER nom d’utilisateur
PASS mot de passe
LIST contenu du répertoire courant
1 Le client FTP contacte le serveur FTP sur le port 21, avec TCP comme
protocole de transport RETR nom de fichier récupération
2 Le client obtient une autorisation sur la connexion de contrôle STOR nom de fichier chargement sur le serveur
3 Quand le serveur reçoit une demande de transfert, ouverture d’une connexion
TCP de données Codes de retour
4 Fermeture à la fin de la transmission Code + phrase (comme pour HTTP)
5 Ouverture d’une deuxième connexion pour transférer un autre fichier 331 Username OK, password required
6 Connexion de contrôle → hors bande 125 data connection already open ; transfer starting
7 Conservation d’état par le serveur : répertoire courant, authentification 425 Can’t open data connection
précédente 452 Error writing file
Plan Courrier électronique

Trois composants majeurs
Agents utilisateurs
Web et HTTP Serveurs mail
FTP SMTP : Simple Mail Transfer
Protocol
SMTP, POP3, IMAP Agent utilisateur
Le lecteur d’e-mails
DNS
Composition, édition, lecture
Partage de fichiers pair-à-pair des e-mails
Outlook, Messenger, Eudora
Messages sortants et entrants
stockés sur le serveur
Serveurs mail SMTP [RFC 2821]
Boı̂te aux lettres : contient les Utilise TCP pour transférer les e-mails de façon fiable (port 25)
messages entrants Transfert direct de serveur à serveur
File de messages : des e-mails Transfert en trois phases
sortant (à envoyer) Poignée de mains
Protocole SMTP : entre Transfert de messages
serveurs de e-mails pour Clôture
envoyer les e-mails Interaction commande/réponse
client : serveur mail émetteur commande : texte ASCII
réponse : code et phrase de statut
”serveur” : serveur mail
récepteur Les messages doivent être en ASCII 7 bits
Scénario : Alice écrit un e-mail à Bob Exemple d’interaction SMTP

1 Alice utilise son mailer pour composer son message ”à”
S : 220 hamburger.edu
bob@someschool.edu C : HELO crepes.fr
2 L’agent utilisateur d’Alice envoie le message à son serveur mail. S : 250 Hello crepes.fr, pleased to meet you
Le message est placé dans la file d’attente C : MAIL FROM : <alice@crepes.fr>
S : 250 alice@crepes.fr... Sender ok
3 Le client SMTP ouvre une connexion TCP avec le serveur mail de C : RCPT TO : ¡bob@hamburger.edu¿
Bob S : 250 bob@hamburger.edu ... Recipient ok
4 Le client SMTP envoie le message d’Alice sur la connexion TCP C : DATA
S : 354 Enter mail, end with ”.” on a line by itself
5 Le serveur mail de Bob place le message dans sa boı̂te aux lettres C : Do you like ketchup ?
6 Bob invoque son agent utilisateur pour lire le message C : How about pickles ?
C:.
S : 250 Message accepted for delivery
C : QUIT
S : 221 hamburger.edu closing connection
Essayer SMTP par soi même Derniers mots sur SMTP
SMTP utilise des connexions persistantes

SMTP oblige un format ASCII 7 bits pour les messages (en-tête
Faites un telnet sur votre serveur mail préféré et corps)
Fin des messages par un ”.” seul sur une ligne
telnet mailhost.loria.fr 25
Observez la réponse 220 du serveur Comparaison avec HTTP
Entrez les commandes HELO, MAIL, FROM, RCPT TO, DATA et HTTP → pull / SMTP → push
QUIT
Interaction commande / réponse ASCII, code de statut pour les
Tout cela vous permet d’envoyer un e-mail sans client mail deux
HTTP : Chaque objet encapsulé dans son propre message de
réponse
SMTP : plusieurs objets envoyés dans un même message
Format d’un e-mail Extensions multimédia du format

MIME : Multimedia Mail Extension RFC 2045 et 2056
Lignes supplémentaires dans l’en-tête déclarant le type de contenu
SMTP : protocole d’échange d’e-mails MIME
RFC 822 standardisation du format de messages texte
Lignes d’en-tête From : alice@crepes.fr
To : To : bob@hamburger.edu
From : Subject : Picture of a Yummy crepe
Subject : version de l’extension MIME
MIME-Version : 1.0
différent des commandes SMTP
Méthode d’encodage des données
Corps du message Content-Transfer-encoding : base64
Le message proprement dit Déclaration des type et sous-type de la donnée multimédia
Caractères ASCII seulement Content-Type : image/jpg
Donnée encodée
base64 encoded data .....
.........................
...... base64 encoded data
Protocoles d’accès au mail Protocole POP3
Phase d’autorisation S : +OK POP3 server ready

Commandes client C : user bob
S : +OK
user déclare le nom
C : pass hungry
pass mot de passe
S : +OK user succesfully logged on
Réponses serveur
+OK
SMTP : livraison /stockage sur le serveur du récepteur C : list
-ERR S : 1 498
Protocole d’accès au mail : récupération sur le serveur S : 2 912
POP : Post Office Protocol [RFC1939] Phase de transaction S : .
Autorisation (agent ↔ serveur) et download C : retr 1
list numéros des
IMAP ; Internet Mail Access Protocol [RFC 1730] messages S : <contenu message 1>
Plus de fonctionnalités (plus complexes) S : .
retr récupère un message C : dele 1
Manipulation de messages stockés sur le serveur
dele supprime C : quit
HTTP : Hotmail, Yahoo !Mail, . . .
quit S : +OK POP3 server signing off
POP3 et IMAP Plan

POP3 IMAP
Exemple précédent → Garde tous les messages Web et HTTP
mode ”charger et sur le serveur FTP
supprimer” Permet de classer ses
Bob ne peut pas relire ses e-mails Courrier électronique
e-mails s’il change de client Conservation d’état SMTP, POP3, IMAP
”Charger et garder” → noms des dossiers et
DNS
copies des messages sur correspondances entre
plusieurs clients numéro de message et Partage de fichiers pair-à-pair
nom de dossier
POP3 est sans état entre
sessions Programmation socket
DNS : Domain Name System DNS
Services DNS
Gens : beaucoup d’identifiants (N˚ Sécu, nom, N˚ de passeport) Translation nom d’hôte → adresse IP
Hôtes et routeurs d’Internet : Alias d’hôtes et de serveurs de mail
Adresse IP (32 bits) pour adresser les datagrammes
Alias et noms canoniques
Nom (www.google.fr) utilisé par les humains
Question : comment faire correspondre adresse et nom ? Distribution de la charge
Serveurs Web répliqués : plusieurs adresses IP pour un seul nom
canonique
Domain Name System
Base de données distribuée → hiérarchie de serveurs de noms Pourquoi ne pas centraliser ?
Protocole de niveau application : hôtes, routeurs et serveurs de Un seul point de défaillance
noms communiquent pour résoudre des noms (translation) Volume du trafic
Note : fonction clé d’Internet implantée par un protocole de niveau
Base de donnée centralisée distante
application
Complexité sur les bords du réseau Maintenance
Ça ne passe pas à l’échelle !
Base de données distribuée hiérarchique DNS : Serveurs de noms racine

Serveurs DNS
racine Contactés par des serveurs de noms locaux qui ne peuvent pas
résoudre un nom
Serveurs de noms racine (13 dans le monde) :
Serveurs DNS Serveurs DNS Serveurs DNS
com org fr Contactent le serveur de noms d’autorité si correspondance inconnue
obtiennent la correspondance
la retournent au serveur de noms local
Serveurs Serveurs Serveurs Serveurs Serveurs
DNS DNS DNS DNS DNS
ebay.com yahoo.com pbs.org uhp.fr loria.fr
Je veux l’IP de www.ebay.com

1 Je demande à un serveur racine de trouver le serveur DNS com
2 Je demande au serveur DNS com de de trouver le serveur DNS
ebay.com
3 Je demande au serveur DNS ebay.com l’IP de www.ebay.com
TLD et serveurs d’autorité Serveur de noms local
Serveurs Top-Level Domain (TLD) N’appartient pas vraiment à la hiérarchie

Responsables de com, org, net, edu, etc et des uk, fr, ca, jp, . . . Chaque FAI en a un)
Également appelé ”serveur de noms par défaut”
Serveurs DNS d’autorité Lorsqu’un hôte fait une requête DNS elle est envoyée à son
Serveurs DNS des organisations serveur DNS local
Autorité pour la correspondance Nom / IP pour les serveurs de qui agit comme un proxy
l’organisation (ex. : Web et mail) et transmet la requête dans la hiérarchie
Exemple Requêtes récursives
cis.poly.edu : IP de
gaia.cs.umass.edu ? Requête récursive
1 Envoi du nom à transformer au Laisse travailler le serveur
serveur local
contacté
2 Transfert au serveur racine
Forte charge → ? ? ?
3 Liste de serveur TLD pour edu
4 Contact d’un des TLD edu
5 Retour du serveur d’autorité de
Requête itérative
umass.edu Le serveur contacté répond par le
6 Contact de ce serveur nom d’un autre serveur à contacter
7 Retour de l’IP de gaia (”Je sais pas mais lui peut-être”)
8 messages !
Cache et mise à jour Enregistrements DNS
DNS : Base de données distribuée d’enregistrements de ressources
(nom, valeur, type, ttl)
Mise en cache dès qu’une nouvelle correspondance est apprise par Type = A
un serveur nom → hôte
L’entrée disparaı̂t du cache au bout d’un certain temps valeur → adresse IP
Les TLD sont cachés sur les serveurs locaux Type = NS
Peu de visites pour les serveurs racine nom → domaine (ex. : ebay.com)
Mécanismes de mise à jour et de notification conçus par l’IETF valeur → nom d’hôte du serveur d’autorité de ce domaine
RFC 2136 Type = CNAME
nom → alias d’un nom canonique
www.ibm.com ⇔ servereast.backup2.ibm.com
valeur → nom canonique
Type = MX
valeur → nom du serveur de mail associé à nom
Protocole et messages DNS Protocole et messages DNS
Protocole : messages de requête et réponse avec le même format Protocole : messages de requête et réponse avec le même format
identification drapeaux Champs nom et type pour
Identification nb de questions nb d’enreg. réponse 12 octets une requête
N˚ sur 16 bits pour une nb d’enreg. autorité nb d’enreg. supp.
Enregistrements en
requête et ses réponses questions
réponse à une requête (nombre variable de questions)
Drapeaux
Requête ou réponse
Enregistrements pour les réponses
(nombre variable d’enregistrements)
Récursif souhaité serveurs d’autorité autorité

(nombre variable d’enregistrements)
Récursif disponible Autres informations informations supplémentaires
Réponse faisant autorité ”utiles” pouvant servir (nombre variable d’enregistrements)
Insérer des enregistrements dans le DNS Plan

Création d’une startup ”Utopie réseau”
Enregistrez le nom utopiereseau.com auprès d’un officier d’état Web et HTTP
civil (ex. : Networks Solutions)
Fournissez les noms et adresses IP de vos serveurs d’autorité (primaire FTP
et secondaire)
L’officier insère deux enregistrements dans les serveurs TLD com Courrier électronique
SMTP, POP3, IMAP
(utopiereseaux.com, dns1.utopiereseau.com, NS)
(dns1.utopiereseaux.com, 212.212.212.1, A)
DNS
Placez un enregistrement de Type A pour www.utopiereseaux.com et
un de type MX pour utopiereseaux.com sur le serveur d’autorité Partage de fichiers pair-à-pair
Comment font les gens pour avoir l’adresse IP de votre site web ?
Partage de fichiers pair-à-pair P2P : annuaire centralisé

Exemple
Alice exécute son client P2P sur son portable
Connexion intermittente à Internet : adresse IP dynamique
Conception originale de Napster
Cherche ”Hey Jude” 1 À la connexion, un pair
L’application montre les autres pairs qui en ont une copie informe le serveur central de
Alice en choisit un : Bob Son adresse IP
Son contenu
Copie du fichier depuis le PC de Bob vers le portable d’Alice
(HTTP) 2 Alice demande ”Hey Jude”
Pendant qu’Alice charge, d’autres utilisateurs chargent ses fichiers 3 Alice demande le fichier à Bob
Le pair d’Alice est à la fois un client Web et un serveur Web
provisoire
Tous les pairs sont serveurs → haute extensibilité !
Problèmes de l’annuaire centralisé Gnutella : Inondation de requêtes
Totalement distribué → pas de serveur central

Unique point de défaillance Protocole du domaine public
Goulot d’étranglement des performances Beaucoup de clients Gnutella qui implante le protocole
Violation du copyright
Réseau de couverture : graphe
Arc entre pairs X et Y si connexion TCP
Le transfert de fichier est décentralisé mais la recherche du contenu est
fortement centralisée Les pairs et les liens forment le réseau de couverture
Un arc n’est pas un lien physique
Un pair aura généralement moins de 10 voisins
Gnutella : protocole Gnutella : connexion d’un pair
Message de requête
envoyé sur des 1 Le nouveau pair X doit trouver un autre pair Gnutella : liste de
connexions TCP
pairs candidats
existantes
2 X essaie chacun des pairs de la liste jusqu’à établir une connexion
Les pairs propage le
TCP avec Y
message de requête
3 X envoie un message Ping à Y qui le propage
Une réponse est
envoyée sur le chemin
4 Tous les pairs recevant Ping répond par un message Pong
inverse 5 X reçoit plusieurs messages Pong. Il peut alors établir d’autres
connexions TCP
Extensibilité
Inondation à portée limitée
Exploiter l’hétérogénéité : KaZaA KaZaA : requêtes
Un pair est soit chef de groupe soit assigné à un chef de groupe
Connexion TCP entre un pair et son chef de groupe
Connexions TCP entre quelques paires de chefs Chaque fichier possède une clé et un descripteur
Un chef de groupe suit le contenu de tous ses enfants Le client envoie une requête de mots clés à son chef de groupe
Le chef de groupe répond par des réponses correspondantes
Pour chacune : méta-données, clé, adresse IP
Si le chef de groupe propage la requête à d’autres chefs de
groupe, ceux-ci renvoient aussi des réponses correspondantes
Le client choisit ensuite les fichiers à télécharger
Des requêtes HTTP utilisent la clé comme identifiant sont envoyées
aux pairs possédant le fichier désiré
Spécificités KaZaA Plan
Web et HTTP
Limitation des chargements (upload) simultanés FTP
File d’attente des requêtes
Priorités incitatives (plus on partage plus on est prioritaire)
SMTP, POP3, IMAP
Téléchargements en parallèle
DNS
Programmation socket Programmation socket
Objectif
Apprendre comment développer une application client / serveur Objectif
communiquant par sockets Apprendre comment développer une application client / serveur
communiquant par sockets
Socket
Interface (”porte”) locale, créée par l’application, contrôlée par le API Socket
système par laquelle l’application peut envoyer et recevoir des Introduite en 1981 dans UNIX BSD4.1
messages vers ou depuis un autre processus applicatif
Créées, utilisées et libérées explicitement par les applications
Paradigme client / serveur
Deux types de service transport disponibles
Datagrammes non fiables
Flux d’octets fiables
Programmation socket avec TCP Programmation socket avec TCP

Socket : porte entre un processus applicatif et un protocole de TCP → transfert d’octets fiable et ordonné entre client et serveur
transport de bout en bout (TCP ou UDP)
Service TCP : transfert fiable d’octets d’un processus à un autre Le client doit contacter le serveur
Le processus serveur doit d’abord être lancé
Le serveur doit avoir créé une socket qui accueille le contact du client
Le client contacte le serveur en
Créant une socket TCP locale
Spécifiant l’adresse IP et le port du processus serveur
Lorsque le client crée la socket : connexion entre client et serveur TCP
Quand il est contacté par le client, le serveur TCP crée une nouvelle
socket pour communiquer avec le client
Permet au serveur de parler à plusieurs clients
Utilisation des numéros de port source pour distinguer les clients
Jargon des flux Programmation socket avec TCP
Exemple d’application
1 Le client lit une ligne sur l’entrée
Un flux est une séquence de caractères qui entre ou sort d’un standard (flux inFromUser) et
processus l’envoie au serveur par la socket
Un flux d’entrée est attaché à une source d’entrée d’un processus (flux outToServer)
(ex. : clavier ou socket) 2 Le serveur lit la ligne sur la socket
Un flux de sortie est attaché à une source de sortie d’un processus 3 Le serveur convertit la ligne en
majuscule et la renvoie au client
(ex. : écran ou socket)
4 Le client lit et affiche la ligne
modifiée depuis la socket (flux
inFromServer
Interactions entre sockets client et serveur avec Programmation socket avec UDP
TCP
Serveur (sur hostid) Client
Point de vue de l’application
crée sur socket (port = x) UDP fournit un transfert non fiable de groupes d’octets entre un client
pour une requete entrante
welcomeSocket = ServerSocket () et un serveur
attend une requete crée une socket, se UDP : pas de ”connexion” entre client et serveur
de connexion Etablissement connecte sur hostid, port =x
connectionSocket = connexion TCP clientSocket = Socket () Pas de poignée de mains
welcomeSocket ()
L’émetteur attache explicitement l’adresse IP et le port de
Envoie une requete
lit une requete sur via clientSocket destination à chaque paquet
connectionSocket
Le serveur doit extraire l’adresse IP et le port de l’émetteur du
paquet reçu
écrit une réponse sur
lit une réponse sur
connectionSocket
clientSocket UDP : les données transmises peuvent être reçues dans le désordre ou
être perdues
ferme connectionSocket
ferme clientSocket
Programmation socket avec UDP Interactions entre sockets client et serveur avec
UDP
Envoi et réception de paquets et non de flux d’octets
Serveur (sur hostid) Client
crée sur socket (port = x) crée une socket

pour une requete entrante clientSocket =
ServerSocket = DatagramSocket ()
DatagramSocket ()
crée adresse (hostid,

port = x) et envoie une
lit une requete sur requete datagramme sur
serverSocket clientSocket
écrit une réponse sur

serverSocket
en spécifiant l’adresse
lit une réponse sur
et le numéro de port de
clientSocket
l’hote client
ferme clientSocket
Chapitre 2 : résumé Chapitre 2 : résumé
Notre étude des applications réseaux est maintenant terminée ! Plus important : On en a appris sur les protocoles
Architectures des applications Protocoles spécifiques Échange classique de messages requête/réponse
Client / Serveur HTTP Le client demande des informations ou des services
Pair-à-Pair FTP Le serveur répond par des données et un code d’état
Hybride SMTP, POP, IMAP
DNS
Formats de messages
Besoins de services En-tête : champs décrivant les données
Fiabilité Programmation socket Données : informations à communiquer
Bande passante Messages de contrôle et de données (sur ou hors bande)
Délai Centralisé ou décentralisé
Modèle de service transport d’Internet Sans ou avec état
Fiable orienté connexion : TCP Transfert fiable ou non
Non fiable, datagrammes : UDP Complexité au bord du réseau
Troisième partie
Troisième partie
Couche Transport
Couche Transport
Services de la couche Transport
Objectifs Multiplexage et démultiplexage
Comprendre les principes des services de la couche transport Transport sans connexion : UDP
Multiplexage / démultiplexage Principes du transfert fiable de données
Transfert fiable de données
Contrôle de flot Transport orienté connexion : TCP
Contrôle de congestion Structure des segments
Apprendre sur les protocoles de la couche transport dans Internet Transfert fiable de données
UDP : transport sans connexion Contrôle de flot
TCP : transport orienté connexion Gestion de connexion
Contrôle de congestion de TCP Principes du contrôle de congestion
Contrôle de congestion dans TCP
Plan Services et protocoles transport

Services de la couche Transport Fournit une communication logique
Multiplexage et démultiplexage entre processus applicatifs
s’exécutant sur différents hôtes
Transport sans connexion : UDP
Les protocoles transport s’exécutent
Principes du transfert fiable de données sur les systèmes terminaux
Émetteur : découpe les
Transport orienté connexion : TCP
messages des applications en
Structure des segments segments et les passe à la
Transfert fiable de données couche réseau
Contrôle de flot Récepteur : réassemble les
Gestion de connexion segments en messages et les
passe à la couche application
Principes du contrôle de congestion
Plusieurs protocoles disponibles
Internet : TCP et UDP
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 3 - Couche Transport 158 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 3 - Couche Transport 159 / 365
Couches transport et réseau Protocoles de niveau transport d’Internet
Couche réseau : communication logique entre hôtes

Livraison fiable et ordonnée
Couche transport : communication logique entre processus Contrôle de congestion
S’appuie sur et augmente les services de la couches réseau Contrôle de flot
Établissement de connexion
Analogie Livraison non fiable et non
12 enfants envoient des lettres à 12 enfants ordonnée
Processus = enfants Extension ”sans fioritures” du
Messages des applications = lettres dans enveloppes best effort d’IP
Hôtes = maisons Services non disponibles
Protocole de Transport = parents Garanties de délai et de bande
passante
Protocole de la couche réseau = service postal
Plan Multiplexage et démultiplexage

Démultiplexage sur receveur Multiplexage sur émetteur
Multiplexage et démultiplexage Livraison des segments reçus sur Collection de données de
Transport sans connexion : UDP la bonne socket plusieurs sockets, ajout d’un
en-tête (utilisé par le
Principes du transfert fiable de données
démultiplexage)
Structure des segments
Contrôle de flot
Gestion de connexion
Comment marche le démultiplexage Démultiplexage sans connexion
L’hôte reçoit des datagrammes IP Création de sockets avec un numéro de port

Chaque datagramme a une DatagramSocket maSocket1 = new DatagramSocket(99111) ;
adresse IP source et une adresse DatagramSocket maSocket2 = new DatagramSocket(99222) ;
IP destination
Chaque datagramme contient 1
segment de niveau transport Une socket UDP est identifiée par le couple (adresse IP
Chaque segment a un numéro de destination, numéro de port destination)
port source et un numéro de port Lorsqu’un hôte reçoit un segment UDP
destination Il vérifie le numéro de port destination dans le segment et
L’hôte utilise les adresses IP et les dirige le segment UDP vers la socket ayant ce numéro de port
numéros de port pour diriger le Des datagrammes IP ayant des adresses IP ou des numéros de
segment vers la bonne socket port source différents sont dirigés vers la même socket
Démultiplexage sans connexion Démultiplexage sans connexion
Le numéro de port source sert aux messages de retour même numéro → même socket
Démultiplexage orienté connexion Démultiplexage orienté connexion
Une socket TCP est identifiée par le quadruplet

Adresse IP source
Numéro de port source
Adresse IP destination
Numéro de port destination
Le récepteur utilise les quatre valeurs pour diriger le segment vers
la bonne socket
Un serveur peut supporter simultanément plusieurs sockets TCP
Chaque socket est identifiée par son propre quadruplet
Les serveurs web ont plusieurs sockets pour chaque client
connecté source différents sont dirigés vers la même socket
HTTP non-persistant → plusieurs sockets pour chaque requête
Plan UDP : User Datagram Protocol [RFC 768]

Services de la couche Transport Protocole transport ”sans fioritures” d’Internet
Multiplexage et démultiplexage Service best effort, les segments UDP peuvent être
Perdus
Transport sans connexion : UDP Délivrés dans le désordre
Principes du transfert fiable de données Sans connexion
Pas de poignée de mains entre émetteur et récepteur
Transport orienté connexion : TCP Chaque segment UDP est traité indépendamment des autres
Pourquoi UDP ?
Contrôle de flot
Gestion de connexion Pas d’établissement de connexion (source de délai)
Simple : pas d’état de connexion
En-tête de segment court
Pas de contrôle de congestion : UDP émet aussi vite qu’il veut
Détails sur UDP Checksum UDP
Objectif
Souvent utilisé pour les Détecter les ”erreurs” (ex. : bits inversés) dans les segments transmis
applications de flux multimédia
Tolérantes aux pertes
Sensibles au délai Émetteur Récepteur
Autre utilisations courantes Traite le contenu du segment Calcule le checksum du segment
DNS comme une suite d’entiers sur 16 reçu
SNMP (Simple Network bits Vérifie l’égalité avec le contenu
Management Protocol) Checksum ; addition du champ
Transfert fiable sur UDP (complémentaire à 1) du contenu Si non → erreur détectée
→ au niveau application du segment
Si oui → pas d’erreur
Place la valeur du checksum dans détectée mais peut-être
le champ UDP correspondant une erreur tout de même
Exemple de checksum Internet Plan

Multiplexage et démultiplexage
Note : une retenue sur le bit le plus significatif doit être ajoutée
au résultat
Exemple : Addition de deux entiers 16-bits Principes du transfert fiable de données
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 Structure des segments
Retenue 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Transfert fiable de données
Somme 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 Contrôle de flot
Checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Gestion de connexion
Principes du transfert fiable de données Principes du transfert fiable de données
Important dans les couches application, transport et liaison
Dans le top ten des sujets importants en réseaux
Important dans les couches application, transport et liaison

Dans le top ten des sujets importants en réseaux
Les caractéristiques d’un canal non fiable vont déterminer la

complexité du protocole de transfert fiable de données
→ Reliable Data Transfer (RDT)
Transfert fiable de données pour débutant Transfert fiable de données pour débutant
Nous allons :
Développer petit à petit les cotés émetteur et récepteur du
rdt send() : appelé du dessus (par une application, par ex.). protocole rdt
Les données passées sont à livrer à la couche supérieure du Considérer uniquement des transferts de données unidirectionnels
récepteur Mais les informations de contrôle iront dans les deux sens !
udt send() : appelé par rdt pour transférer un paquet vers le Utiliser des automates à états finis pour décrire l’émetteur et le
récepteur sur un canal non fiable récepteur
rdt rcv() : appelé lorsque le paquet du coté récepteur du canal Evénement causant une transition d’état
Action prise lors d’une transition d’état
deliver data() : appelé par rdt pour livrer les données à la
Etat
couche supérieure
1 Evénement
Action Etat
2
Rdt 1.0 : transfert fiable sur un canal fiable Rdt 2.0 : canal avec erreurs de bits
Canal sous-jacent parfaitement fiable Le canal sous-jacent peut inverser des bits dans le paquet
Pas d’erreurs de bits Checksum pour détecter les erreurs
Pas de perte de paquets
Question : comment réparer les erreurs ?
Automates à états finis distincts pour l’émetteur et le récepteur Accusés réceptions (acknowlegments (ACK)) : le récepteur dit
L’émetteur envoie des données sur le canal explicitement à l’émetteur que le paquet est bien arrivé
Le récepteur lit des données depuis le canal Accusés de non réception (negative acknowlegments (NAK)) : le
récepteur dit explicitement à l’émetteur que le paquet contient des
erreurs
Émetteur Récepteur L’émetteur réémet un paquet à la réception d’un NAK
Nouveaux mécanismes dans Rdt 2.0
Attend rdt_send(data) Attend rdt_rcv(packet)
un appel un appel Détection d’erreurs
du packet = make_pkt(data) du extract (packet,data)
dessus dessous
deliver_data(data)
Retour à l’envoyeur : messages de contrôle (ACK, NAK)
udt_send(packet)
Rdt 2.0 : spécification Rdt 2.0 : fonctionnement sans erreur
rdt_send(data) rdt_send(data)
sndpkt = make_pkt(data, checksum) sndpkt = make_pkt(data, checksum)
udt_send(sndpkt) udt_send(sndpkt)
Attend Attend rdt_rcv(rcvpkt) && isNAK(rcvpkt) Attend Attend rdt_rcv(rcvpkt) && isNAK(rcvpkt)
un appel un ACK un appel un ACK
du ou un udt_send(sndpkt) du ou un udt_send(sndpkt)
dessus NAK dessus NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) &&corrupt (rcvpkt) rdt_rcv(rcvpkt) &&corrupt (rcvpkt)

sndpkt =make_pkt(NAK) sndpkt =make_pkt(NAK)
Attend udt_send(sndpkt) Attend udt_send(sndpkt)
un appel un appel
du du
dessous dessous
rdt_rcv(rcvpkt) && notcorrupt (rcvpkt) rdt_rcv(rcvpkt) && notcorrupt (rcvpkt)
extract (rcvpkt, data) extract (rcvpkt, data)
deliver_data (data) deliver_data (data)
sndpkt =make_pkt(ACK) sndpkt =make_pkt(ACK)
Rdt 2.0 : fonctionnement sans erreur Rdt 2.0 : scénario avec erreur

un appel un appel
du du
dessous dessous
Rdt 2.0 : scénario avec erreur Rdt 2.0 : scénario avec erreur

un appel un appel
du du
dessous dessous
Rdt 2.0 : scénario avec erreur Rdt 2.0 a un défaut fatal ! ! !
rdt_send(data)
sndpkt = make_pkt(data, checksum)
Qu’arrive-t-il si l’ACK/NAK est corrompu ?
udt_send(sndpkt)
L’émetteur ne sait pas ce qui est arrivé au récepteur !
Attend Attend rdt_rcv(rcvpkt) && isNAK(rcvpkt) Peut juste réémettre : duplication possible
un appel un ACK
du ou un udt_send(sndpkt)
dessus NAK
Gestion des doublons
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Réémission seulement si l’ACK/NAK est corrompu
rdt_rcv(rcvpkt) &&corrupt (rcvpkt)
sndpkt =make_pkt(NAK)
L’émetteur ajoute un numéro de séquence à chaque paquet
udt_send(sndpkt)
Attend
un appel Le récepteur ne livre pas les paquets dupliqués
du
dessous
rdt_rcv(rcvpkt) && notcorrupt (rcvpkt)
extract (rcvpkt, data) Stop and Wait
deliver_data (data)
sndpkt =make_pkt(ACK) L’émetteur envoie un paquet et attend la réponse du récepteur
udt_send(sndpkt)
Rdt 2.1 : émetteur, gestion des ACK/NAK Rdt 2.1 : émetteur, gestion des ACK/NAK
corrompus corrompus
rdt_send(data)
sndpkt = make_pkt(0, data, checksum) rdt_rcv(rcvpkt) && notcorrupt (rcvpkt)
udt_send(sndpkt) && has_seq0(recvpkt)
rdt_rcv(rcvpkt)
&& (corrupt(rcvpkt) || extract (rcvpkt, data)
deliver_data (data)
isNAK(rcvpkt))
Attend Attend sndpkt =make_pkt(ACK,checksum)
un appel un ACK udt_send(sndpkt) udt_send(sndpkt)
0 du ou un rdt_rcv(rcvpkt) &&corrupt (rcvpkt) rdt_rcv(rcvpkt) &&corrupt (rcvpkt)
dessus NAK 0
sndpkt =make_pkt(NAK, checksum) sndpkt =make_pkt(NAK, checksum)
rdt_rcv(rcvpkt) rdt_rcv(rcvpkt) udt_send(sndpkt) udt_send(sndpkt)
Attend Attend
&& notcorrupt (rcvpkt) && notcorrupt (rcvpkt) un appel un appel
&& isACK(rcvpkt) && isACK(rcvpkt) 0 du 1 du
rdt_rcv(rcvpkt) && notcorrupt (rcvpkt) dessous dessous
&& has_seq1(recvpkt) && has_seq0(recvpkt)
Attend sndpkt = make_pkt(data, checksum) sndpkt = make_pkt(data, checksum)

Attend
un ACK un appel udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt (rcvpkt) udt_send(sndpkt)
ou un 1 du && has_seq1(recvpkt)
rdt_rcv(rcvpkt) NAK 1 dessus
&& (corrupt(rcvpkt) || extract (rcvpkt, data)
deliver_data (data)
isNAK(rcvpkt))
sndpkt =make_pkt(ACK,checksum)
udt_send(sndpkt) rdt_send(data) udt_send(sndpkt)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
Rdt 2.1 : Discussion Rdt 2.2 : un protocole sans NAK
Émetteur Récepteur
N˚ de séquence ajouté au Doit vérifier si le paquet
Même fonctionnalités que rdt 2.1 mais en n’utilisant que des ACK
paquet reçu est dupliqué
L’état indique si le n˚ de
Plutôt qu’un NAK, le récepteur envoie un ACK pour le dernier
Deux numéros (0,1) paquet bien reçu (OK)
séquence attendu est 0 ou 1
suffisent. Le récepteur doit explicitement inclure le numéro de séquence du paquet
Doit vérifier si l’ACK/NAK Le récepteur ne peut pas
savoir si son dernier Un ACK en double sur l’émetteur entraı̂ne la même action qu’un
reçu est corrompu NAK : la réémission du paquet courant
ACK/NAK a été bien reçu
Deux fois plus d’états
par l’émetteur
L’état doit ”se souvenir” si
le paquet ”courant” a 0 ou
1 comme n˚ de séquence
Rdt 2.2 : fragments de l’émetteur et du récepteur Rdt 3.0 : canaux avec erreurs et pertes
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt)
Nouvelle hypothèse
&& (corrupt(rcvpkt) ||
Attend Attend
isACK(rcvpkt, 1)) Le canal sous-jacent peut aussi perdre des paquets (données ou ACK)
un appel un ACK udt_send(sndpkt)
0 du
dessus
ou un
NAK 0
Les checksum, n˚ de séquence, ACK, réémission vont aider mais
rdt_rcv(rcvpkt) pas suffire
&& notcorrupt (rcvpkt)
&& isACK(rcvpkt, 0)
Approche
Attend
L’émetteur attend l’ACK pendant un temps ”raisonnable”
un appel

0 du
dessous
Réémission si aucun ACK n’est arrivé pendant ce temps
|| has_seq1(recvpkt)
Si le paquet (ou l’ACK) est juste retardé (pas perdu)
udt_send(sndpkt)
La réémission sera dupliqué, mais les n˚ de séquence gèrent déjà ça
&& has_seq1(recvpkt)
Le récepteur doit spécifier le n˚ de séquence du paquet ACKé
extract (rcvpkt, data)
deliver_data (data)
sndpkt =make_pkt(ACK,1,checksum)
Nécessite un compte à rebours
udt_send(sndpkt)
Rdt 3.0 : émetteur Rdt 3.0 en action
rdt_send(data)
rdt_rcv(rcvpkt)
udt_send(sndpkt) && (corrupt(rcvpkt) ||
start_timer isACK(rcvpkt,1)) Cas idéal
Emetteur Récepteur
rdt_rcv(rcvpkt) Attend timeout
un appel Attend
un udt_send(sndpkt) émet pqt0 pqt0
0 du
dessus ACK 0 start_timer
reçoit pqt0
rdt_rcv(rcvpkt)
&& notcorrupt (rcvpkt)
ACK0 émet ACK0
&& isACK(rcvpkt, 1) reçoit ACK0
rdt_rcv(rcvpkt)
stop_timer && notcorrupt (rcvpkt) émet pqt1 pqt1
&& isACK(rcvpkt, 0) reçoit pqt1
timeout stop_timer ACK1 émet ACK1
Attend
udt_send(sndpkt) Attend un appel reçoit ACK1
un
start_timer 1 du rdt_rcv(rcvpkt) émet pqt0 pqt0
ACK 1 dessus
reçoit pqt0
rdt_rcv(rcvpkt) ACK0 émet ACK0
&& (corrupt(rcvpkt) || rdt_send(data)
isNAK(rcvpkt),0)) sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
Rdt 3.0 en action Rdt 3.0 en action

Perte d’un paquet Perte d’un ACK
Emetteur Récepteur Emetteur Récepteur
émet pqt0 pqt0 émet pqt0 pqt0

reçoit pqt0 reçoit pqt0
ACK0 émet ACK0 ACK0 émet ACK0
reçoit ACK0 reçoit ACK0
x perte
perte x
expiration expiration
réémet pqt1 pqt1 réémet pqt1 pqt1 reçoit pqt1
reçoit pqt1 (détection du
ACK1 émet ACK1 ACK1 dupliquat)
émet ACK1
reçoit ACK1 reçoit ACK1
reçoit pqt0 reçoit pqt0
ACK0 émet ACK0 ACK0 émet ACK0
Rdt 3.0 en action Performances de Rdt 3.0
Rdt 3.0 marche, mais c’est pas terrible :(
Expiration prématurée
Exemple : lien à 1 Gbps, délai de propagation bout en bout de
Emetteur Récepteur
15ms, paquets d’un Ko :
émet pqt0 pqt0
reçoit pqt0
ACK0 émet ACK0
L (longueur du paquet en bits) 8kb/paquet
Ttransmis = = = 8ms
reçoit ACK0 R (taux de transmission, bps 109 b/sec
émet pqt1 pqt1
L/R 0, 008
Uemetteur = = = 0, 00027
RTT + L/R 30, 008
expiration
réémet pqt1 pqt1 reçoit pqt1 Uemetteur : utilisation → fraction de temps durant laquelle
reçoit ACK1 (détection du
émet pqt0 ACK1 dupliquat) l’émetteur émet vraiment
émet ACK1
pqt0 reçoit pqt0 Un paquet d’1Ko toutes les 30 secondes → rendement de
ACK0 émet ACK0 33Ko/sec sur un lien à 1 Gbps
Le protocole réseau limite l’utilisation des ressources physiques ! !
Rdt 3.0 : stop-and-wait Protocoles pipelinés
Pipeline : l’émetteur autorise plusieurs paquets ”en vol” pas

encore accusés
L’intervalle des numéros de séquence doit être augmenté
Mise en tampon sur l’émetteur et/ou le récepteur
L/R 0, 008
Deux formes génériques de protocoles pipelinés : go-Back-N et
Uemetteur = = = 0, 00027 répétition sélective
RTT + L/R 30, 008
Pipeline : augmentation de l’utilisation Go-Back-N
Émetteur
Numéros de séquence sur k bits dans l’en-tête du paquet
”Fenêtre” d’un maximum de N paquets consécutifs non-accusés
autorisés
ACK(n) : accuse réception de tous les paquets (jusqu’au n˚ n)

3 ∗ L/R 0, 024 Compteur pour chaque paquet en vol
Uemetteur = = = 0, 0008
RTT + L/R 30, 008 Timeout(n) : retransmet le paquet n et tous ceux de la fenêtre de
Augmentation par un facteur 3 ! n˚ de séquence supérieurs
Go-Back-N : émetteur Go-Back-N : récepteur

rdt_send(data)
if (nextseqnum< base + N) { default rdt_rcv(rcvpkt)
sndpkt[nextseqnum] = make_pkt(nextseqnum, && notcorrupt(rcvpkt)
data,checksum) udt_send(sndpkt) && hasseqnum(rcvpkt, expectedseqnum)
udt_send(sndpkt[nextseqnumm]) extract_data(rcvpkt, data)
if (base == nextseqnum) deliver_data (data)
start_timer Attend
nextseqnum++ sndpkt = make_pkt(expectedseqnum,
} else expectedseqnum=1 ACK, checksum)
sndpkt = make_pkt(expectedseqnum,
base =1 refuse_data(data) udt_send(sndpkt)
ACK, checksum) expectedseqnum++
nextseqnum=1
timeout
start_timer
Attend udt_send(sndpkt[base]) ACK seulement : envoi systématique d’un ACK pour le paquet
rdt_rcv(rcvpkt) udt_send(sndpkt[base]+1)
&& corrupt(rcvpkt)
correctement reçu dans l’ordre ayant le plus grand n˚ de séquence
...
udt_send(sndpkt[nextseqnum −1]) Peut générer des ACK en double
Necéssite de mémoriser expectedsum seulement
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
base = getacknum (rcvpkt)+1 Paquet dans le désorde
if (base == nextseqnum) Négligé → pas de mise en tampon sur le récepteur
stop_timer
else Boucle avec l’ACK contenant le plus grand n˚ de séquence
start_timer
Go-Back-N en action Répétition sélective
Le récepteur accuse réception de tous les paquets correctement

reçus individuellement
Stocke les paquets, au besoin, pour une éventuelle livraison dans l’ordre
à la couche supérieure
L’émetteur ne renvoie que les paquets pour lesquels l’ACK n’a pas
été reçu
Un compteur sur l’émetteur pour chaque paquet non-accusé
Fenêtre émetteur
N n˚ de séquence consécutifs
Limite les n˚ de séquence des paquets envoyés et non-accusés
Répétition sélective : fenêtres émetteur et récepteur Répétition sélective
Émetteur
Données du dessus
Si le prochain n˚ dans la fenêtre est disponible → envoyer le paquet
Sinon renvoi à la couche supérieure pour envoi ultérieur
timeout (n)
Renvoyer le paquet n, redémarrer le compteur
ACK(n)
Marquer le paquet n comme reçu
Si n = send base, avancer le début de la fenêtre jusqu’au prochain n˚
non-accusé
Répétition sélective Répétition sélective en action
Récepteur
Paquet n dans [recvbase, recvbase+N-1] → paquet
correctement reçu
Envoyer ACK(n)
Dans le désordre → mise en tampon
Dans l’ordre → livraison (valable pour ceux mal ordonnés mis en
tampon), avance la fenêtre jusqu’au prochain paquet non reçu
Paquet n dans [recvbase-N, recvbase-1] → paquet reçu
ACK(n)
Sinon
Ignorer ce paquet
Répétition sélective : dilemme Plan

N˚ de séquence : 0, 1, 2, 3 Transport sans connexion : UDP

Taille de fenêtre = 3 Principes du transfert fiable de données
Pas de différence entre les Structure des segments
scénarios pour le récepteur Transfert fiable de données
Des données dupliquées Contrôle de flot
deviennent ”correctes” Gestion de connexion
dans (a) Principes du contrôle de congestion
TCP : Aperçu [RFC 793, 1122, 1323, 2018, 2581] TCP : Aperçu [RFC 793, 1122, 1323, 2018, 2581]
Point-à-point → Un émetteur, un récepteur Point-à-point → Un émetteur, un récepteur

Flux fiable et ordonné d’octets → Pas de ”limites de messages” Flux fiable et ordonné d’octets → Pas de ”limites de messages”
Pipeliné → Les contrôles de flot et de congestion TCP fixent la Pipeliné → Les contrôles de flot et de congestion TCP fixent la
taille de la fenêtre taille de la fenêtre
Tampons d’émission et de réception Tampons d’émission et de réception
Données full duplex → Flot bi-directionnel de données dans une
même connexion
Orienté connexion → Poignée de mains (échange de messages de
contrôle) initie l’état de l’émetteur et du récepteur avant
l’échange de données
Contrôle de flot → L’émetteur ne surchage pas le récepteur
Structure d’un segment TCP Structure d’un segment TCP
URG : donnée urgente

N˚ de séquence et
(généralement pas
d’accusé réception :
utilisé)
comptés en octets de
données (pas en ACK : n˚ d’ACK valide
segments) PSH : pousser la
checksum : comme donnée maintenant
dans UDP (généralement pas
utilisé)
Fenêtre réception :
nombre d’octets que le RST, SYN, FIN :
récepteur veut accepter établissement de la
connexion
N˚ de séquence et d’ACK de TCP N˚ de séquence et d’ACK de TCP
N˚ de séquence Question
N˚ du premier octet du Comment sont gérés
segment dans le flux les segments reçus
d’octets dans le désordre ?
N˚ d’ACK Réponse
N˚ du prochain octet Pas dans la
attendu de l’autre coté spécification de TCP
Accusés réceptions À la responsabilité de
groupés l’implanteur
Scénario Telnet Scénario Telnet
RTT et délai d’expiration TCP Exemple d’estimation du RTT
Comment fixer le délai d’expiration TCP ?

Plus long que le RTT → mais le RTT varie
Trop court → retransmissions pas nécessaires
Trop long → réaction lente à la perte de segments
Comment estimer le RTT ?

SampleRTT mesure du temps de la transmission du segment
jusqu’à la réception de l’ACK
ignore les retransmissions
Le SampleRTT varie et on veut un RTT estimé plus ”lisse” EstimatedRTT = (1 − α) EstimatedRTT + α SampleRTT
Moyenne de plusieurs mesures récentes et pas seulement la valeur
L’influence du passé décroı̂t de façon exponentielle
courante de SampleRTT
Valeur classique : α = 0, 125
RTT et délai d’expiration TCP Transfert TCP fiable de données
Fixer le délai d’expiration TCP crée un service rdt au dessus du service non-fiable d’IP
EstimatedRTT + marge de sécurité Segments pipelinés
Grosse variation de EstimatedRTT → grande marge de sécurité ACKs groupés
Estimation préalable de la déviation de SampleRTT par rapport à Un seul compte à rebours pour la retransmission
EstimatedRTT Retransmissions déclenchées par
DevRTT = (1 − β) DevRTT + β|SampleRTT − EstimatedRTT| Expirations de délais
ACK dupliqués
Généralement β = 0.25
Considérons d’abord un émetteur TCP simplifié
Puis fixer l’intervalle du timeout Pas de gestion des ACK dupliqués
IntervalleTimeout = EstimatedRTT + 4 DevRTT Ni contrôle de flot, ni contrôle de congestion
Évenements d’un émetteur TCP Évenements d’un émetteur TCP
Donnée reçue de l’application Expiration du délai

Crée un segment avec un n˚ de séquence Retransmet le segment qui a causé l’expiration
Le n˚ de séquence est le n˚ du premier octet du segment dans le Redémarre le compte à rebours
flux d’octets
Démarre le compte à rebours s’il n’est pas déjà lancé Réception d’un ACK
Compte à rebours démarrant au segment non-accusé le plus ancien S’il accuse des segments non-accusés précédents
Met à jour ce qui est maintenant accusé
Intervalle d’expiration : IntervalleTimeout
Démarre le compte à rebours s’il y a des segments en attente
TCP : Scénarios de retransmission TCP : Scénarios de retransmission
Expiration prématurée
Perte d’un ACK
Segment 100 non retransmis

TCP : Scénarios de retransmission Génération d’ACK dans TCP [RFC 1122, 2581]
ACK groupé Evénement Action TCP

Arrivée d’un segment dans Retarder l’ACK. Attendre le
l’ordre avec le bon n˚ de seq. Les prochain segment jusqu’à 500
données sont toutes ACKées ms. Si aucun nouveau segment,
jusqu’à ce n˚ envoyer l’ACK
Arrivée d’un segment dans l’ordre Envoyer immédiatement un ACK
avec le bon n˚ de seq. Un autre groupé, accusant les deux
segment a son ACK en attente segments dans l’ordre
Arrivée d’un segment dans le Envoyer immédiatement un ACK
désordre avec un n˚ supérieur à dupliqué indiquant le n˚ de
celui attendu. Détection d’un séquence du prochain octet
trou attendu
Arrivée d’un segment comblant Envoyer immédiatement un ACK
partiellement ou complètement le si le segment ”bouche” le début
Segment 92 non retransmis trou du trou
Retransmission rapide Contrôle de flot TCP
Le coté récepteur d’une connexion TCP possède un tampon de
réception
Tampon de réception (RcvBuffer)
Les délais d’expiration sont souvent longs
Fenetre de réception
Long délai avant de retransmettre un paquet perdu (RcvWindow)
Détection de segments perdus via les ACK dupliqués

Données Processus
L’émetteur envoie souvent plusieurs segments consécutifs IP Données applicatif
Espace
Si un segment est perdu, il y aura certainement des ACK dupliqués TCP dans
libre
le tampon
Si l’émetteur reçoit 3 ACK pour la même donnée, il suppose que
le segment suivant la donnée ACKée est perdu
Retransmission rapide : renvoie le segment avant expiration du délai
Le processus applicatif peut lire le tampon trop lentement
Contrôle de flot
L’émetteur ne va pas déborder le tampon de réception en envoyant
trop et trop vite
Contrôle de flot TCP Contrôle de flot TCP : comment ça marche ?

Le coté récepteur d’une connexion TCP possède un tampon de
réception Fenetre de réception
(RcvWindow)
Fenetre de réception Données Processus

(RcvWindow) IP Données applicatif
Espace
TCP dans
libre
le tampon
Données Processus
IP Données applicatif
Espace
TCP dans
libre
le tampon
Supposons que le récepteur rejette les paquets dans le désordre
Espace libre = RcvWindow = RcvBuffer - [DernierOctetRecu -
Le processus applicatif peut lire le tampon trop lentement DernierOctetLu]
Service de mise en correspondance des vitesses Le récepteur indique son espace libre dans le champ ”fenêtre de réception”
Adapter le débit d’émission au débit d’extraction de l’application des segments
réceptrice L’émetteur limite la quantité de données non-accusées à RcvWindow
Garantit que le tampon de réception ne débordera pas
Gestion de connexion TCP Poignée de mains en trois étapes
1 Le client envoie un segment
TCP SYN au serveur
Rappel Spécifie le n˚ de séquence
initial
L’émetteur et le récepteur établissent une connexion avant
Ne contient pas de données
d’échanger des segments de données.
2 Le serveur reçoit SYN et
Initialisation des variables TCP
répond par un segment
N˚ se séquences
SYNACK
Tampons, informations de contrôle de flot (RcvWindow)
Allocation des tampons par le
Client : initiateur de la connexion (fonction socket()) serveur
Serveur : contacté par le client (fonction accept()) Spécifie le n˚ de séquence
Poignée de mains en trois étapes initial du serveur
3 Le client reçoit SYNACK et
répond par un segment ACK
qui peut contenir des données
Fermeture d’une connexion TCP Cycles de vie

Le client ferme la socket : close()
1 le client envoie le segment TCP
de contrôle FIN au serveur Client TCP Serveur TCP
2 le serveur reçoit FIN, répond
par un ACK, ferme la
connexion et envoie FIN au
client
3 le client reçoit FIN, répond par
un ACK
Entre en attente bornée et
répondra par un ACK aux FIN
reçus
4 le serveur reçoit ACK, la
connexion est fermée
Plan Principes du contrôle de congestion
Congestion
Informellement : trop de sources envoient trop de données trop
Principes du transfert fiable de données vite pour que le réseau puisse gérer
Transport orienté connexion : TCP Différent du contrôle de flot
Structure des segments Manifestations
Transfert fiable de données Paquets perdus (débordement de la file d’attente sur les routeurs)
Contrôle de flot Long délais (mise en file d’attente sur les routeurs)
Gestion de connexion Problème dans le top 10 ! !
Causes et coûts de la congestion : scénario 1 Causes et coûts de la congestion : scénario 2
2 émetteurs,
1 routeur, tampons bornés
2 récepteurs
Retransmission des paquets perdus par l’émetteur
1 routeur,
tampons infinis
Pas de
retransmission
Coût de la Congestion
Grand délais
R/2 : débit
maximal
possible
Cas idéal Cas un peu plus réaliste
Émission uniquement quand le paquet est sur de passer Retransmission parfaite
Complètement irréaliste ! Uniquement quand le paquet est sûr d’être perdu
Pas de pertes λin = λ0in = λout (débit efficace) λ0in = R/2 → R/3(données) + R/6(retransmission)

Cas encore plus réaliste
Retransmission prématurée
Paquets rétardés dans la file mais pas perdus
Données originale et retransmise arrivent → λout = λ0in /2 Coût de la congestion
Plus de travail (retransmission) pour un débit efficace donné
Retransmission dans l’ordre
Retransmission inutiles : plusieurs copies d’un paquet circulent sur
le lien
Quatre
émetteurs
Chemins
multi-sauts
Délai
d’expiration et
retransmission
Que se passe-t-il Autre coût de la congestion

quand λin et λ0in
augmentent ? Lorsqu’un paquet est rejeté, toute la capacité de transmission
utilisée en amont pour ce paquet est gaspillée
Si R2 rejette un paquet de A → C, R1 aurait a travaillé pour rien
Approches pour le contrôle de congestion Étude de cas : contrôle de congestion ABR d’ATM
Rappels sur ATM
Contrôle de congestion par les systèmes terminaux Réseau à circuits virtuels
et donc pas à commutation de paquets
Pas d’informations explicites de la part du réseau
Vocabulaire
Congestion inférée par les systèmes terminaux d’après les pertes Paquet = Cellule
et délais Routeur = Commutateur
Approche adoptée par TCP Chaque commutateur sur le chemin conserve l’état du circuit
Taux de transmission moyen
Contrôle de congestion assistée par le réseau Idéal pour le contrôle de congestion assisté par le réseau
Les routeurs fournissent des informations aux systèmes terminaux
Un bit indique la congestion (SNA, DECbit, TCP/IP ECN, ATM ABR)
Explicite le débit auquel l’émetteur peut émettre
Étude de cas : contrôle de congestion ABR d’ATM Étude de cas : contrôle de congestion ABR d’ATM
ABR : available bit rate
Service élastique
Si le chemin de l’émetteur est en sous charge
L’émetteur peut utiliser la bande passante disponible
Si le chemin de l’émetteur est congestionné
L’émetteur se limite au débit minimum garanti
Cellules RM (Resource Management) ER (Explicit Rate) : champ de 2 octets dans une cellule RM
Envoyées par l’émetteur au milieu des cellules de données Un commutateur encombré peut diminuer la valeur de ER
Débit d’émission → débit minimum supportable par le chemin
Bits d’une cellule RM fixé par les commutateurs
Bit NI : No Increase (pas d’augmentation du débit - faible congestion) Bit EFCI (Explicit Forward Congestion Indication) dans les cellules de
bit CI : indication de congestion données : mis à 1 par les commutateurs encombrés
Les cellules RM sont renvoyées telles quelles par le récepteur à Si la cellule de données précédant une cellule RM à son bit EFCI à 1, le
l’émetteur récepteur fixe le bit CI dans la cellule RM retournée
Plan Contrôle de congestion dans TCP

Services de la couche Transport Contrôle par les systèmes terminaux (pas d’assistance du réseau)
Multiplexage et démultiplexage L’émetteur limite la transmission :
Transport sans connexion : UDP DernierOctetEnvoyé-DernierOctetAccusé ≤ FenCong
Grossièrement
Principes du transfert fiable de données
débit = FenCong
RTT
Octets/sec
Transport orienté connexion : TCP FenCong est dynamique, fonction de la congestion réseau perçue
Comment l’émetteur perçoit-il la congestion ?
Évenement de perte = expiration ou 3 ACK dupliqués
Contrôle de flot
L’émetteur TCP réduit le débit (FenCong) après un évenement de perte
Gestion de connexion
Trois mécanismes
Principes du contrôle de congestion AIMD
Démarrage lent (slow start)
Contrôle de congestion dans TCP Conservateur après expirations
TCP : AIMD TCP : Démarrage Lent
Multiplicative Decrease
Couper FenCong en 2 à chaque perte Au début de la connexion : FenCong = 1 MSS
Exemple : MSS = 500 octets et RTT = 200 msec
Additive Increase Débit initial = 20 kbps
Augmenter FenCong de 1 MSS (Maximum Segment Size) en l’absence La bande passante disponible peut être bien supérieure à
de perte MSS/RTT
Il serait souhaitable d’atteindre rapidement un débit acceptable
Quand la connexion démarre, le débit augmente de façon
exponentielle jusqu’au premier évenement de perte
FenCong double à chaque RTT
Augmentation à chaque ACK reçu
En résumé : débit initial lent mais croissance exponentielle
Connexion TCP durable

TCP : Démarrage Lent (précisions) Contrôle de congestion TCP : résumé

Après trois 3 ACKs dupliqués
FenCong coupée en deux
puis croissance linéaire FenCong est en dessous de seuil → émetteur en phase de
démarrage lent → croissance exponentielle de la fenêtre
Mais après une expiration
FenCong est au dessus de seuil → émetteur en phase de
FenCong reprend une taille de 1 MSS évitement de congestion → croissance linéaire de la fenêtre
La fenêtre croı̂t ensuite exponentiellement Triple ACK dupliqué → seuil fixé à FenCong/2 et FenCong
jusqu’à un certain seuil, puis croı̂t linéairement fixée à seuil
Expiration→ seuil fixé à FenCong/2 et FenCong fixée à 1 MSS
Philosophie
3 ACK dupliqués indiquent que le réseau est capable de livrer
quelques segments
Une expiration après 3 ACK dupliqués est ”plus alarmant”
Débit TCP Futur de TCP
Petit exemple
Quel est le débit moyen de TCP en fonction de la taille de fenêtre
et du RTT ? Segments de 1500 octets, RTT de 100ms, débit désiré de 10 Gbps
En ignorant le démarrage lent Nécessite une taille de fenêtre de 83 333 segments en vol
C’est beaucoup !
Soit W la taille de la fenêtre au moment de la perte Quel est le taux de perte autorisé pour ”tenir” le débit de 10 Gbps ?
Le débit est alors de W/RTT Débit en fonction du taux de perte (L)
Juste après la perte, la fenêtre retombe à W/2 et le débit à 1.22MSS
√
W/2RTT RTT L
Le débit moyen croı̂t entre ces deux valeurs → 0,75W/RTT L = 2 × 1010 soit 1 perte pour 5 milliards de segments ! ! !
On a besoin de nouvelles versions rapides de TCP
Equité Pourquoi TCP est-il équitable

Deux sessions concurrentes
Objectif Additive increase → pente de 1
Si K sessions TCP partagent le même lien limitant de bande passante Multiplicative decrease → diminution proportionnelle du débit
R, chacune pourra avoir un débit moyen de R/K
R
partage équitable de
la bande passante
Débit connexion 2
Débit connexion 1 R
Équité (détails) Modélisation du délai
Équité et UDP
Les applications multimédia n’utilisent pas souvent TCP
Ne veulent pas d’un débit limité par le contrôle de congestion Question
Utilisent UDP à la place Combien de temps faut-il pour recevoir un objet de la part d’un
Pompe audio/vidéo à débit constant, pertes tolérées
serveur web une fois la requête émise ?
En ignorant la congestion, le délai est dominé par

Équité et connexions TCP parallèles
L’établissement de la connexion TCP
Rien n’empêche des applications d’ouvrir plusieurs connexions
TCP parallèles entre deux hôtes Le délai de transmission des données
Les navigateurs web le font Le démarrage lent
Exemple : lien de débit R supportant 9 connexions
nouvelle application demandant 1 connexion TCP → obtient R/10
nouvelle application demandant 11 connexions TCP → obtient R/2 !
Modélisation du délai Fenêtre de congestion fixe
Notations et hypothèses
Un lien entre client et serveur de débit R
S → MSS (en bits) Premier cas
O → Taille de l’objet (en bits) WS/R > RTT + S/R → l’ACK
du premier segment de la fenêtre
Pas de retransmissions (ni pertes, ni corruptions)
avant que celle-ci soit pleine
Taille de fenêtre Délai = 2 RTT + O/R

Première hypothèse : fenêtre de congestion fixe, W segments
Puis fenêtre dynamique, modélisant le démarrage lent
Fenêtre de congestion fixe Démarrage lent
Deuxième cas Supposons maintenant que la fenêtre augmente à la manière du

WS/R < RTT + S/R → démarrage lent
Attente de l’ACK quand la Nous allons montrer que le délai pour un objet est de
fenêtre est pleine
Délai = 2 RTT + OR + P RTT + RS − (2p − 1) RS

Délai = 2 RTT + O/R Où P est le nombre de temps d’inactivité TCP du serveur :
+(K − 1)[S/R + RTT − WS/R]+ P = min(K − 1, Q)
où [x]+ = max(0, x) et Où Q est le nombre de fois où le serveur bloquerait si O était
K = 0/WS → nombre de composé d’une infinité de segments
Où K est le nombre de fenêtre couvrant l’objet
fenêtres couvrant l’objet
Démarrage lent Démarrage lent
Inactivité du serveur
P = min(K − 1, Q) fois
Composantes du délai
2 RTT pour l’établissement et Exemple
la requête
O/S = 15 segments
O/R pour transmettre l’objet
K = 4 fenêtres
Temps d’inactivité du serveur à
Q=2
cause du démarrage lent
P = min(K − 1, Q) = 2
Le serveur attend 2 fois
Démarrage lent Démarrage lent
Temps d’inactivité Modèle de délai TCP avec démarrage lent

S
1
R
+ RTT = temps (sur le P
serveur) entre envoi segment et O X
Délai = + 2 RTT + Ik
réception ACK R k=1
2 2k−1 RS = temps pour O
P
S

k−1 S
X
transmettre la k ieme fenêtre = + 2 RTT + + RTT − 2
R k=1
R R

(1) - (2) = Ik = temps O S S
= + 2 RTT + P RTT + − (2p − 1)
d’inactivité après la k ieme R R R
fenêtre
Modélisation du délai TCP Modélisation de HTTP
Rappel : K = nombre de fenêtres couvrant l’objet

Comment calculer K ?
K = min{k : 2˚S + 21 S + · · · + 2k−1 S ≥ O}

= min{k : 2˚+ 21 + · · · + 2k−1 ≥ O/S} Page Web composée de
= min{k : 2k − 1 ≥ O/S} 1 fichier HTML principal (de taille O bits)
O M images (chacune de taille O bits)
= min{k : k ≥ log2 ( + 1)}
S
O
= log2 ( + 1)
S
Le calcul de Q est similaire

l m
Q = log2 (1 + RTT
S/R
) +1
Modélisation de HTTP Temps de réponse HTTP (en secondes)
HTTP non-persistant RTT = 0, 1 sec, O = 5Ko, M = 10 et X = 5
M + 1 connexions TCP à la suite
Temps de réponse = (M + 1)O/R + (M + 1)2 RTT + somme des
temps d’inactivité
HTTP persistant
2 RTT pour demander et recevoir le fichier HTML principal
1 RTT pour demander et recevoir M images
Temps de réponse = (M + 1)O/R + 3 RTT + somme des temps
d’inactivité
HTTP non-persistant avec X connexions parallèles
Supposons M/X entier
1 connexion TCP pour le fichier principal
M/X établissements de connexions parallèles pour les images Faible bande passante → temps transmission >> temps de
Temps de réponse = (M + 1)O/R + (M/X + 1)2 RTT + somme des connexion et de réponse
temps d’inactivité Connexions persistantes ' Connexions parallèles
Temps de réponse HTTP (en secondes) Chapitre 3 : Résumé

RTT = 1 sec, O = 5Ko, M = 10 et X = 5
Principes derrière les services de la couche transport
Contrôle de flot
Contrôle de congestion
Instantiation et implantation dans Internet
UDP
TCP
La suite
RTT plus important → domination des délais d’établissement et de On quitte les bords du réseau (couches Application et Transport)
démarrage lent
pour aller vers le cœur du réseau
Connexions persistantes >> Connexions parallèles (surtout si grande bande
passante)
Quatrième partie
Quatrième partie Couche Réseau

Introduction
Couche Réseau Réseaux à circuits virtuels ou de datagrammes
Qu’y a-t-il dans un routeur ?
Objectifs IP : Internet Protocol
Comprendre les principes derrière les services de la couche réseau Format des datagrammes
Routage (sélection de chemin) Adressage IPv4
Gestion de l’échelle ICMP (Internet Control Message Protocol)
Comment marche un routeur IPv6
Instantiation et implantation sur Internet Algorithmes de routage
État de lien
Vecteur de distances
Routage hiérarchique
Routage sur Internet
Couche réseau Fonctions clés de la couche réseau
Retransmission
Transporte des segments d’un hôte
émetteur à un hôte récepteur
Déplacer des paquets depuis une entrée d’un routeur vers la sortie
appropriée du routeur
Coté émetteur : encapsulation des
segments en datagrammes
Routage
Coté récepteur : livre des segments à
la couche transport Déterminer la route prise par les paquets de la source à la
destination
Les protocoles de la couche réseau
se situent sur tous les hôtes et tous Algorithmes de routage
les routeurs
Un routeur examine les champs Analogie
d’en-tête de tous les paquets qui Routage : préparer son itinéraire
passent par lui
Retransmission : passer sur un échangeur autoroutier
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 4 - Couche Réseau 257 / 365 F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 4 - Couche Réseau 258 / 365
Relations entre routage et retransmission Établissement de la connexion
Troisième fonction clé de certaines architectures réseaux

ATM, Frame-relay, X.25
Avant d’envoyer des datagrammes, deux hôtes et les routeurs
participant établissent une connexion virtuelle
Implication des routeurs
Services de connexion des couches réseau et transport
Réseau : entre deux hôtes
Transport : entre deux processus
Modèle de service réseau Modèles de service réseau
Question
Garanties ?
Quel modèle de service pour un ”canal” transportant des datagrammes Architecture Modèle de Bande Perte Ordre Délai Info pour
d’un émetteur à un récepteur ? Réseau service passante congestion
Internet best aucun non non non non
Exemples de services pour un datagramme effort
Livraison garantie ATM CBR débit oui oui oui pas de
Livraison garantie en moins de 40 msec constant congestion
ATM VBR débit oui oui oui pas de
Exemples de services pour un flot de datagrammes garanti congestion
Livraison ordonnée des datagrammes ATM ABR minimum non oui non oui
garanti
Bande passante minimum garantie pour le flot
ATM UBR aucun non oui non non
Restrictions sur les modifications de l’espacement des paquets
Plan Services connecté et sans connexion de niveau
Introduction
réseau
Réseaux à circuits virtuels ou de datagrammes
IP : Internet Protocol Un réseau datagramme fournit un service sans connexion de
Format des datagrammes niveau réseau
Adressage IPv4 Un réseau à circuits virtuels fournit un service connecté de niveau
ICMP (Internet Control Message Protocol) réseau
IPv6 Analogue aux services de niveau transport mais
Algorithmes de routage Service : hôte à hôte
État de lien Pas de choix : le réseau fournit l’un ou l’autre
Vecteur de distances Implantation : au cœur du réseau
Circuits virtuels Implantation d’un circuit virtuel
Le chemin de la source à la destination ressemble à un circuit

téléphonique
Un circuit virtuel est composé
Activation et désactivation pour chaque appel.. Les données ne
1 D’un chemin de la source à la destination
peuvent circuler avant l’activation
2 De n˚ de circuits virtuels, un pour chaque lien du chemin
3 D’entrées dans les tables de routage des routeurs du chemin
Chaque paquet porte l’identifiant du circuit (et pas l’adresse de la
Les paquets appartenant à un circuit portent un n˚ de circuit
destination)
Le n˚ de circuit doit être changé pour chaque lien
Chaque routeur sur le chemin maintient un ”état” de chaque
Le nouveau n˚ provient de la table de routage
connexion le traversant
Des ressources peuvent être allouées au circuit virtuels sur les
liens et les routeurs (bande passante, tampons)
Table de routage Circuits virtuels : protocoles de signalisation
Utilisés pour activer, maintenir et désactiver un circuit virtuel

Table de routage du routeur R1 Utilisés par ATM, Frame-relay, X.25
Interface N˚ de circuit Interface N˚ de circuit mais pas dans l’Internet actuel
entrante entrant sortante sortant Nous n’en parlerons donc pas beaucoup plus
1 12 3 22
2 63 1 18
3 7 2 17
1 97 3 87
... ... ... ...
Les routeurs maintiennent des informations sur l’état des connexions

Circuits virtuels : protocoles de signalisation Réseau de datagrammes
Activation d’un circuit Pas d’activation d’appel au niveau réseau

1 Initie l’appel 2 Appel entrant Routeurs : pas d’état concernant les connexions point-à-point
Pas de concept de ”connexion” au niveau réseau
4 Appel connecté 3 Accepte l’appel
Retransmission des paquets selon l’adresse de destination
5 Début du flux de données 6 Reçoit les données
Des paquets échangés par une paire source-destination donnée
peuvent prendre des chemins différents
”Protocole” : 1 envoi des données et 2 réception des données
Table de routage Plus long préfixe commun
Adresses 32 bits → 4 milliards d’entrées possibles → Intervalles Réduction de la taille de la table
Intervalle d’adresse de destination Interface Routeur : adresse ↔ liste de préfixes
Si plusieurs préfixes correspondent → le plus long prime
11001000 00010111 00010000 00000000
à 0 Préfixes Interface
11001000 00010111 00010111 11111111
11001000 00010111 00010 0
11001000 00010111 00011000 00000000
11001000 00010111 00011000 1
à 1
11001000 00010111 00011 2
11001000 00010111 00011000 11111111
sinon 3
11001000 00010111 00011001 00000000
à 2 Exemples
11001000 00010111 00011111 11111111
11001000 00010111 00010110 10100001 → 0
sinon 3 11001000 00010111 00011000 10101010 → 1
Réseaux à circuits virtuels ou de datagrammes : Réseaux à circuits virtuels ou de datagrammes :

pourquoi ? pourquoi ?
Internet ATM
Échange de données entre ordinateurs Évolution à partir des réseaux téléphoniques
Service ”élastique”
Conversation humaine
Systèmes terminaux ”intelligents” (ordinateurs) Délais stricts, besoins de fiabilité
Peuvent s’adapter, contrôler, récupérer des erreurs Besoin d’un service garanti
Cœur du réseau simple, compléxité aux bords
Systèmes terminaux ”idiots”
Plusieurs types de liens Téléphones à cadrans
Caractéristiques différentes Complexité dans le cœur du réseau
Service uniforme difficile
Plan Aperçu de l’architecture d’un routeur
Introduction Deux fonctions clés
Réseaux à circuits virtuels ou de datagrammes Exécuter algorithmes et protocoles de routage (RIP, OSPF, BGP)
Qu’y a-t-il dans un routeur ? Retransmettre les datagrammes du lien entrant vers le lien sortant
IP : Internet Protocol
Format des datagrammes
Adressage IPv4
ICMP (Internet Control Message Protocol)
IPv6
Algorithmes de routage
État de lien
Fonctions du port d’entrée Trois types de commutateurs
Commutateur
Traitement de Recherche,
Terminaison liaison de données retransmission,
de ligne (protocole, mise en attente
décapsulage)
Couche Physique Couche liaison
Commutation décentralisée
D’après la destination du datagramme, cherche le port de sortie
en utilisant la table de routage dans la mémoire du port d’entrée
Objectif : traiter à la ”vitesse de la ligne”
File d’attente : si les paquets arrivent plus vite que le débit de
retransmission du commutateur
Commutation en mémoire Commutation via un bus
Commutateurs de première génération Un datagramme va de la mémoire du port d’entrée à celle du port

de sortie via un bus partagé
Ordinateurs traditionnels avec commutation sous contrôle direct
du processeur Contention du bus : vitesse de commutation limitée par la bande
passante du bus
Paquets copiés dans la mémoire du système
Ex : Bus 1Gbps Cisco 1900 → vitesse suffisante pour des routeurs
Vitesse limitée par la bande passante de la mémoire (2 passages
d’accès (ADSL) ou d’entreprises (LAN) mais pas pour du régional
par le bus par datagramme)
ni sur un backbone
Commutation via un réseau d’interconnexion Ports de sortie
Commutateur
Mise en attente Traitement de
Surmonte les limitations dues à la bande passante du bus gestion des liaison de données
(protocole,
Terminaison
tampons de ligne
encapsulage)
Réseaux de Banyan (ou autres) → initialement conçus pour
connecter les processeurs d’un multi-processeurs
Couche liaison Couche Physique
Conception avancée : fragmenter les datagrammes en cellules de
taille fixe puis commuter les cellules
Ex : Cisco 12000 : commute des Gbps via son réseau Mise en attente nécessaire arrivent du commutateur plus vite que
d’interconnexion le débit de transmission
La politique d’ordonnancement choisit les datagrammes à
transmettre parmi ceux mis en attente
Mise en attente en sortie Mise en attente en entrée
Commutateur plus lent que la combinaison des ports → mise en
attente possible dans les files d’entrée
Blocage de la tête de file (HOL, Head of the line) : le premier
datagramme de la file empêche les autres de passer
Délais d’attente et pertes dues au débordement du tampon du
port de sortie
Quand le taux d’arrivée est supérieur à la vitesse de la ligne

Délais d’attente et pertes dues au débordement du tampon du
port de sortie
Mise en attente en entrée Plan

Commutateur plus lent que la combinaison des ports → mise en Introduction
attente possible dans les files d’entrée Réseaux à circuits virtuels ou de datagrammes
Blocage de la tête de file (HOL, Head of the line) : le premier Qu’y a-t-il dans un routeur ?
datagramme de la file empêche les autres de passer
Délais d’attente et pertes dues au débordement du tampon du Format des datagrammes
port de sortie Adressage IPv4
IPv6
État de lien
La couche réseau d’Internet Plan
Introduction
Couche Transport : TCP, UDP
Protocoles de routage Protocole IP

sélection de chemin conventions d’adressage
RIP,OSPF, BGP format des datagrammes
conventions de gestion Format des datagrammes
Couche Réseau
des paquets
Adressage IPv4
Table de
routage Protocole ICMP IPv6
rapport d’erreur
"signalisation" du routeur Algorithmes de routage
État de lien
Couche Liaison Vecteur de distances
Couche Physique
Format de datagramme IP Format de datagramme IP

32 bits 32 bits
Taille Taille
Version Type de service Longueur du datagramme (octects) Version Type de service Longueur du datagramme (octects)
en−tete en−tete
Identifiant 16 bits Drap. Offset de fragmentation 13 bits
Version : N˚ de version
du protocole IP Utilisés pour la
Adresse IP source 32 bits Adresse IP source 32 bits fragmentation et le
Type de service =
Adresse IP destination 32 bits Adresse IP destination 32 bits
réassemblage
”type” de données
Données Données
(Taille variable, généralement un segment TCP ou UDP) (Taille variable, généralement un segment TCP ou UDP)
Format de datagramme IP Format de datagramme IP
32 bits 32 bits
Taille Taille
Version Type de service Longueur du datagramme (octects) Version Type de service Longueur du datagramme (octects)
en−tete en−tete

Durée de validité : Identifiant 16 bits Drap. Offset de fragmentation 13 bits
Protocole de la
Checksum en−tete
nombre max. de sauts Protocole de la
Checksum en−tete Étiquette temporelle
Durée de validité Durée de validité
couche supérieure couche supérieure
restants (décrémenté à Route prise
Adresse IP source 32 bits
chaque routeur) Adresse IP source 32 bits
Liste des routeurs à
Protocole de la couche visiter
Adresse IP destination 32 bits Adresse IP destination 32 bits
supérieure : à qui livrer
...
la charge utile Options (facultatif)
Données Données
(Taille variable, généralement un segment TCP ou UDP) (Taille variable, généralement un segment TCP ou UDP)
Format de datagramme IP Fragmentation et réassemblage IP

32 bits
Taille
Version Type de service Longueur du datagramme (octects)
en−tete
Les liens réseaux ont un MTU (maximal transfer unit) - plus
Quel surcoût avec TCP ?

grande trame de niveau liaison possible
Protocole de la
Durée de validité
couche supérieure
Checksum en−tete
20 octets de TCP
Différents types de liens → différents MTU
Adresse IP source 32 bits 20 octets d’IP Les grands datagrammes IP sont fragmentés sur le réseau
= 40 octets + surcoût de
Un datagramme devient plusieurs datagrammes
Adresse IP destination 32 bits
Réassemblés uniquement à destination
la couche application
Options (facultatif) Bits de l’en-tête IP pour identifier et ordonner les fragments reliés
Données
(Taille variable, généralement un segment TCP ou UDP)
Fragmentation et réassemblage IP Plan
Introduction
Adressage IPv4
IPv6
État de lien
Adressage IP : introduction Sous-réseaux
Adresse IP : identifiant 32 Adresse IP

bits de l’interface d’un Partie sous-réseau (bits de
hôte ou d’un routeur poids forts)
Interface : connexion entre Partie hôte(bits de poids
un hôte/routeur et un lien faibles)
physique
Un routeur a plusieurs
Qu’est-ce qu’un sous-réseau
interfaces
Un hôte a généralement Interfaces de périphériques
une interface ayant le même sous-réseau
Adresse IP associée à dans leur adresse IP Réseau composé de 3
chaque interface Peuvent s’atteindre sous-réseaux
mutuellement sans passer par
223.1.1.1 = 11011111 00000001 00000001 00000001 un routeur
Sous-réseaux Sous-réseaux
Mode d’emploi
Pour déterminer les sous réseaux,
détachez chaque interface de son
hôte ou routeur, créez des iles de
réseaux isolés. Chaque réseau isolé
est appelé sous-réseau Masque de sous-réseau : /24
Les 24 bits de gauche forment
l’adresse du sous-réseau
Question
Combien y a-t-il de sous réseaux ?
Adressage IP : CIDR Comment obtenir une adresse IP ?
Comment un hôte obtient-il son adresse IP

CIDR : Classless InterDomain Routing Codée en dur dans un fichier par l’administrateur système
La partie sous-réseau de l’adresse est de taille arbitraire Windows & Co. : panneau de configuration → réseau →
format d’adresse : a.b.c.d/x où x est le nombre de bits de la configuration → tcp/ip → propriétes
partie sous-réseau de l’adresse UNIX : /etc/rc.config
DHCP (Dynamic Host Configuration Protocol) : obtention
11001000 00010111 00010000 00000000 dynamique de l’adresse auprès du serveur
200.23.16.0/23 Fonctionnalité plug-and-play
Détaillée dans le chapitre 5 du livre
Comment obtenir une adresse IP ? Adressage hiérarchique : aggrégation de routes
L’adressage hiérarchique permet une publication efficace des
Question informations de routage
Comment le réseau fait-il pour obtenir la partie sous-réseau de
l’adresse IP ?
Réponse
Il obtient une portion de l’espace d’adressage de son FAI
Bloc FAI 11001000 00010111 00010000 00000000 200.23.16.0/20
Organisation 0 11001000 00010111 00010000 00000000 200.23.16.0/23
Organisation 1 11001000 00010111 00010010 00000000 200.23.18.0/23
Organisation 2 11001000 00010111 00010100 00000000 200.23.20.0/23
... ... ...
Organisation 7 11001000 00010111 00011110 00000000 200.23.30.0/23
Adressage hiérarchique : routes plus spécifiques Derniers mots sur l’adressage IP

Free a une route plus spécifique vers l’organisation 1
Question
Comment un fournisseur d’accès obtient-il un bloc d’adresses ?
Réponse
ICANN (Internet Corporation for Assigned Names and Numbers)
Alloue les adresses
Gère le DNS
Assigne les noms de domaines et résout les conflits
NAT : Network Address Translation NAT : translation d’adresse réseau
Motivation
Le réseau local n’utilise qu’une adresse IP pour ce qui concerne le
monde extérieur
Pas besoin que le FAI alloue un intervalle d’adresses IP : une seule
adresse suffit pour toutes les machines
Possibilité de changer les adresses de machines du réseau local
sans avertir le monde extérieur
Possibilité de changer de fournisseur d’accès sans changer les
Tous les datagrammes quittant le réseau local ont la même
adresses des machines du réseau local
adresse IP NAT source unique : 128.76.29.7 mais des ports source
différents Les machines du réseau local ne peuvent être accéder depuis le
monde extérieur (avantage du point de vue sécurité)
Les datagrammes avec des adresses source ou destination dans ce
réseau ont l’adresse 10.0.0/24 (comme d’habitude)
NAT : translation d’adresse réseau NAT : translation d’adresse réseau
Implantation
Un routeur NAT doit :
Datagrammes sortants : convertir (adresse IP source, n˚ de port)
→ (adresse IP NAT, nouveau n˚ de port)
Les clients/serveurs distants répondront en utilisant (adresse IP
NAT, nouveau n˚ de port) comme adresse de destination
Conserver (dans la table de translation NAT) chaque
correspondance (adresse IP source, n˚ de port) ↔ (adresse IP
NAT, nouveau n˚ de port) 1 L’hôte 10.0.0.1 envoie un datagramme à 128.119.40.186, 80
2 Le routeur NAT change l’adresse source du datagramme
Datagrammes entrants : convertir (adresse IP NAT, nouveau n˚ 10.0.0.1, 3345 → 138.76.29.7, 5001. Met à jour la table
de port) → (adresse IP source, n˚ de port) 3 La réponse arrive. Adresse de destination 138.76.29.7, 5001
4 Le routeur NAT change l’adresse destination du datagramme
138.76.29.7, 5001 → 10.0.0.1, 3345
NAT : translation d’adresse réseau Plan
Champ n˚ de port sur 16 bits Introduction
60 000 connexions simultanées avec une seule adresse du coté Réseaux à circuits virtuels ou de datagrammes
LAN Qu’y a-t-il dans un routeur ?
Le NAT est controversé (par les puristes de l’IETF) IP : Internet Protocol
Les routeurs ne devraient effectuer des traitements que jusqu’à la Format des datagrammes
couche réseau Adressage IPv4
et donc ne devraient pas jouer avec les n˚ de ports qui servent à
adresser des processus
IPv6
Viole l’argument de connexion bout-en-bout
Deux hôtes peuvent se parler directement sans que leurs adresses
IP soient modifiées en chemin État de lien
Pose des problèmes aux applications P2P : un hôte derrière un Vecteur de distances
NAT ne peut pas être serveur → contournement Routage hiérarchique
La pénurie d’adresse devrait plutôt être résolue par IPv6 Routage sur Internet
ICMP : Internet Control Message Protocol ICMP : Internet Control Message Protocol
Types et codes ICMP
Type Code Description
Utilisé par hôtes et routeurs pour communiquer des informations 0 0 réponse écho (ping)
de niveau réseau 3 0 réseau dest. injoignable
3 1 hôte dest. injoignable
Rapport d’erreur : hôte, réseau, port, protocole injoignable 3 2 protocole dest. injoignable
Ping : requête/réponse en écho 3 3 port dest. injoignable
Couche réseau ”au dessus” d’IP 3 6 réseau dest. inconnu
Les messages ICMP portés par les datagrammes IP 3 7 hôte dest. inconnu
4 0 atténuation de la source
Message ICMP : type, code et les 8 premiers octets du (contrôle de congestion, pas utilisé)
datagramme IP causant l’erreur 8 0 requête écho (ping)
9 0 publication de routeur
10 0 découverte de routeur
11 0 TTL expiré
12 0 mauvais en-tête IP
traceroute et ICMP Plan
La source envoie une série de segments UDP à la destination Introduction
Le premier a TTL=1, le deuxième a TTL=2, etc. Réseaux à circuits virtuels ou de datagrammes
Lorsque le nieme datagramme arrive au nieme routeur Qu’y a-t-il dans un routeur ?
Le routeur rejette le datagramme IP : Internet Protocol
et envoie un message ICMP à la source (type 11, code 0) Format des datagrammes
Le message inclue le nom du routeur et l’adresse IP Adressage IPv4
Quand le message ICMP arrive, la source calcule le RTT ICMP (Internet Control Message Protocol)
traceroute fait ça trois fois IPv6
Critère d’arrêt État de lien
Le segment UDP arrive finalement à l’hôte destination Vecteur de distances
Il renvoie un paquet ICMP ”hôte injoignable” (type 3, code 3) Routage hiérarchique
Lorsque la source le reçoit, elle arrête Routage sur Internet
IPv6 En-tête IPv6

Classe de trafic : identifie la priorité entre les datagrammes du flot
Label de flot : identifie les datagramme d’un même flot (le
Motivation première : l’espace d’adressage 32-bit sera bientôt concept de flow n’est pas clairement défini)
complètement alloué En-tête suivant : identifie le protocole de la couche supérieure
Motivation supplémentaire pour les données
Format d’en-tête augmente la vitesse de
traitement/retransmission
L’en-tête change pour faciliter la qualité de service
Format de datagramme IPv6
En-tête d’une taille fixe de 40 octets
Aucune fragmentation autorisée
Autres changements par rapport à IpV4 Transition d’IPv4 à IPv6
Checksum : complètement supprimé pour réduire le temps de

Tous les routeurs ne peuvent pas être mis à jours simultanément
traitement à chaque saut
Pas de ”jour en berne”
Options : autorisées, mais hors de l’en-tête, indiquées par le Comment le réseau peut-il fonctionner avec un mélange de
champ ”En-ête suivant” routeurs IPv4 et IPv6
ICMPv6 : nouvelle version d’ICMP Tunneling : IPv6 transporté comme charge utile dans les
Types de messages supplémentaires. Ex. : ”Paquet trop gros” datagrammes IPv4 sur les routeurs IPv4
Fonctions de gestion de groupes de diffusion
Tunneling Plan
Introduction
Adressage IPv4
IPv6
État de lien
Relations entre routage et retransmission Abstraction par l’intermédiaire d’un graphe
Graphe : G = (N, E )
N = ensemble de routeurs
= u, v , w , x, y , z
E = ensemble de liens =
{(u, v ), (u, x), (v , x), (v , w ),
(x, w ), (x, y ), (w , y ), (w , z),
(y , z)}
Remarque
Abstraction utilisée dans d’autres contextes réseau
Ex. : P2P où N est un ensemble de pairs et E est un ensemble de
connexions TCP
Abstraction : coûts Abstraction : coûts

c(x, x 0 ) = coût du lien (x, x 0 ). c(x, x 0 ) = coût du lien (x, x 0 ).
Ex. : c(w , z) = 5 Ex. : c(w , z) = 5
Coûts pourrait être toujours 1, Coûts pourrait être toujours 1,
ou inversement proportionnel ou inversement proportionnel
à la bande passante ou à la bande passante ou
inversement proportionnel à la inversement proportionnel à la
congestion congestion
Coût du chemin (x1 , x2 , x3 , · · · , xp ) = Coût du chemin (x1 , x2 , x3 , · · · , xp ) =
c(x1 , x2 ) + c(x2 , x3 ) + · · · + c(xp−1 , xp ) c(x1 , x2 ) + c(x2 , x3 ) + · · · + c(xp−1 , xp )
Question Réponse
Quel est le chemin de coût minimum entre u et z ? Un algorithme de routage va trouver ce chemin de coût minimum
Classification des algorithmes de routage Classification des algorithmes de routage
Informations globales ou décentralisées

Globales Statique ou dynamique ?
Tous les routeurs connaissent la topologie complère et les Statique
informations de coût de tous les liens
Les routes changent lentement au cours du temps
Algorithmes à ”état de lien”
Dynamique
Décentralisées Les routes changent plus rapidement
Un routeur connaı̂t ses voisins et le coût des liens vers ses voisins Mise à jour périodique
Processus itératif de calcul et d’échange d’informations entre en réponse aux changements des coûts des liens
voisins
Algorithmes à ”vecteurs de distances”
Plan Un algorithme de routage à état de lien

Introduction
Qu’y a-t-il dans un routeur ? Algorithme de Dijkstra
Topologie réseau et coûts des liens connus de tous les nœuds
Format des datagrammes Possible par une ”diffusion de l’état des liens”
Tous les nœuds ont la même information
Adressage IPv4
ICMP (Internet Control Message Protocol) Calcule les plus courts chemins depuis une source vers tous les
IPv6 autres nœuds
Fournit donc la table de routage pour ce nœud
État de lien Itératif : après k itérations, on connaı̂t le plus court chemin vers k
Vecteur de distances destinations
Un algorithme de routage à état de lien Algorithme de Dijkstra
1 Initialisation :
2
3 N 0 = {u}
Notations 4 Pour tous les nœuds v
5 Si v voisin de u
c(x, y ) : coût du lien du nœud x au nœud y . Égal à +∞ si pas
6 alors D(v ) = c(u, v )
voisins directs 7 sinon D(v ) = ∞
D(v ) : valeur courante du chemin de la source à la destination v 8
9 Répéter
p(v ) : nœud précédant v dans le chemin de la source à v 10 Trouver w ∈ / N 0 tel que D(w ) est minimal
N 0 : ensemble de nœuds pour lesquels le plus court chemin est 11 Ajouter w à N 0
définitivement connu 12 Mettre à jour D(v ) pour tout v voisin de w et ∈/ N0
13 D(v ) = min(D(v ), D(w ) + c(w , v ))
14 /* Le nouveau coût pour v est soit l’ancien coût pour v , soit le
15 coût du plus court chemin vers w plus le coût de w à v */
16 jusqu’à ce que tous les nœuds soient dans N 0
Algorithme de Dijkstra : exemple Algorithme de Dijkstra : résultats
Arbre des plus courts Table de routage pour u

chemins depuis u Destination Lien
v (u, v )
x (u, x)
y (u, x)
w (u, x)
N0 D(v ), p(v ) D(w ), p(w ) D(x), p(x) D(y ), p(y ) D(z), p(z)
z (u, x)
0 u 2, u 5, u 1, u ∞ ∞
1 ux 2, u 4, x 2, x ∞
2 uxy 2, u 3, y 4, y
3 uxyv 3, y 4, y
4 uxyvw 4, y
5 uxyvwz
Algorithme de Dijkstra : discussion Plan
Complexité de l’algorithme pour n nœuds Introduction
Chaque itération : verification de tous les nœuds w ∈
/N Réseaux à circuits virtuels ou de datagrammes
n(n + 1)/2 comparaisons : O(n2 ) Qu’y a-t-il dans un routeur ?
Versions plus efficaces en O(n log n) IP : Internet Protocol
Oscillations possibles Adressage IPv4
Ex. : coût du lien = trafic sur le lien
IPv6
x et z envoient 1 à w , y envoie e à w
État de lien
Algorithme à vecteur de distances Bellman-Ford : exemple
On peut voir que dv (z) = 5,

dx (z) = 3, dw (z) = 3
Équation de Bellman-Ford L’équation de Bellman-Ford
dit que :
Définit
dx (y ) ← coût du plus court chemin de x à y du (z) = min{ c(u, v ) + dv (z),
c(u, x) + dx (z),
puis
c(u, w ) + dw (z)}
dx (y ) = minv {c(x, v ) + dv (y )}
= min{ 2 + 5, 1 + 3, 5 + 3}
où le minimum est trouvé parmi tous les voisins v de x = 4
Le nœud qui donne le minimum est le prochain saut dans le plus court
chemin → table de routage
Algorithme à vecteur de distances Algorithme à vecteur de distances
Idée de base
Dx (y ) estimation du moindre coût de x à y Chaque nœud envoie périodiquement sa propre estimation du
Vecteur de distances : Dx = [Dx (y ) : y ∈ N] vecteur de distances à ses voisins
Le nœud x connaı̂t le coût pour chacun de ses voisins v : c(x, v ) Lorsqu’un nœud x reçoit un nouveau vecteur d’un voisin, il met à
Le nœud x maintient Dx = [Dx (y ) : y ∈ N] jour son propre vecteur en utilisant l’équation de Bellman-Ford
Le nœud x maintient aussi les vecteurs de distances de ses voisins Dx (y ) ← minv {c(x, v ) + Dv (y )}, ∀y ∈ N
Pour chaque voisin v , x maintient Dv = [Dv (y ) : y ∈ N] Sous quelques conditions réalistes, le Dx (y ) estimé converge vers
le véritable moindre coût dx (y )
Algorithme à vecteur de distances Algorithme à vecteur de distances
Itératif, aynchrone
Chaque itération locale provoquée par Comportement d’un nœud
Un changement de coût d’un lien local 1 Attend (changement de coût d’un lien local ou message d’un
Un message de mise à jour de vecteur de la part d’un voisin voisin)
2 Recalcule ses estimations
Distibrué 3 Si un vecteur change, nofitie ses voisins
Chaque nœud ne notifie ses voisins que lorsque son vecteur
change
1 Attend . . .
Les voisins notifient alors leurs voisins si besoin est
Algorithme à vecteur de distances Vecteur de distances
Changement du coût d’un lien

Un nœud détecte un changement de
coût local
Met à jour les informations de routage,
recalcule le vecteur de distances
Si le vecteur change → notifie les voisins
Les bonnes nouvelles vont vite

T0 : y détecte un changement → met à jour son vecteur → informe ses voisins
T1 : z reçoit la mise à jour de y → met à jour sa table → calcule un nouveau
moindre coût pour x → envoie son vecteur à ses voisins
T2 : y reçoit la mise à jour de z → met à jour sa table → les moindres coûts de y
ne changent pas → y n’envoie donc aucun message à z
Vecteur de distances Vecteur de distances
Changements de coût des liens Changements de coût des liens

Les bonnes nouvelles vont vite Les bonnes nouvelles vont vite
Les mauvaises vont lentement → Les mauvaises vont lentement →
problème du ”comptage à l’infini” problème du ”comptage à l’infini”
44 itérations avant la stabilisation de 44 itérations avant la stabilisation de
l’algorithme ! l’algorithme !
Comptage à l’infini Solution : réponse empoisonnée

Avant changement : Dy (x) = 4, Dy (z) = 1, Dz (y ) = 1 et Dz (x) = 5 Si la route de z à x passe par y
T0 : y détecte un changement → met à jour son vecteur
→ Dy (x) = min{c(x, y ) + Dx (x), c(y , z) + Dz (x)} = min{60 + 0, 1 + 5} = 6 z prévient y que sa distance à x est infinie (y ne passera donc
Faux bien sûr → boucle de routage pas par z pour aller à x)
T1 : z reçoit la mise à jour de y → met à jour sa table → calcule un nouveau Réponse partielle → limitée au cas d’une boucle entre deux
moindre coût pour x → Dz (x) = min = min{50 + 0, 1 + 6} = 7 voisins directs
État de lien (EL) vs. vecteur de distance (VD) État de lien (EL) vs. vecteur de distance (VD)
Complexité en nombre de messages

EL : n nœuds et E liens → O(nE ) messages envoyés Robustesse : qu’arrive-t-il si le routeur est défectueux ?
VD : échanges entre voisins uniquement → le temps de EL
convergence varie Un nœud peut publier un coût de lien erroné
Chaque nœud calcule sa propre table
Vitesse de convergence VD
EL : un algorithme en O(n2 ) demande O(nE ) messages Un nœud peut publier un coût de chemin erroné
(oscillations possibles) La table de chaque nœud est utilisé par les autres → propagation
des erreurs
VD : Temps variable (problème du comptage à l’infini et boucles
de routage)
Plan Routage hiérarchique

Introduction Constat
Réseaux à circuits virtuels ou de datagrammes Étude idéalisée du routage pour l’instant
Qu’y a-t-il dans un routeur ? Tous les routeurs sont identiques
IP : Internet Protocol Réseau ”à plat”
Format des datagrammes . . . fausse en pratique
Adressage IPv4
IPv6
État de lien
Routage hiérarchique Routage hiérarchique
Constat
Étude idéalisée du routage pour l’instant . . . fausse en pratique
Aggréger les routeurs en régions → systèmes autonomes (SA)
Échelle : 200 millions de destinations Les routeurs d’un même SA exécutent le même protocole de
routage
Impossible de les stocker toutes dans les tables de routage !
Protocole de routage ”intra-SA”
Échanges de tables → gaspillage des liens ! ! Des routeurs dans des SA différents peuvent exécuter des
protocoles de routage intra-SA différents
Autonomie administrative Routeur passerelle → liaison directe vers un routeur d’un autre SA
Internet : réseau de réseaux
Chaque administrateur réseau peut vouloir contrôler le routage
dans son propre réseau
AS interconnectés Tâches inter-SA

Supposons qu’un routeur dans SA1 reçoive un datagramme dont
la destination est en dehors de SA1
Le routeur doit retransmettre le paquet vers un des routeurs
passerelle, mais lequel ?
SA1 doit
1 apprendre quelles destinations peuvent être atteintes au travers
de SA2 et au travers de SA3
2 propager ces informations à tous les routeurs de SA1
Travail du routage inter-SA
La table de routage est configurée par les algorithmes de routage

intra- et inter-SA
Intra-SA → entrées pour destinations internes
Inter-SA et Intra-SA → entrées pour destinations externes
Fixer la table de routage du routeur 1d Choisir parmi plusieurs SA
Exemple Exemple
Supposons que SA1 apprenne par le protocole inter-SA que le
Supposons maintenant que SA1 apprenne du protocole inter-SA
sous-réseau x est atteignable par SA3 (passerelle 1c) mais pas par
que le sous réseau x est atteignable par SA3 et par SA2
SA2
Pour configurer la table de routage, le routeur 1d doit déterminer
Le protocole inter-SA propage l’information à tous les routeurs
par quelle passerelle retransmettre les paquets destinés à x
internes
C’est aussi le travail du protocole de routage inter-SA !
Le routeur 1d détermine à partir du routage intra-SA que son
interface I est sur le chemin de moindre coût vers 1c Routage en patate chaude : envoyer le paquet vers le plus proche
routeur des deux
Ajoute l’entrée (x,I) dans la table de routage
Plan Routage intra-SA

Introduction
IP : Internet Protocol Également connu sous le nom de Interior Gateway Protocol (IGP)
Format des datagrammes Protocoles de routage intra-SA les plus courants
Adressage IPv4
RIP : Routing Information Protocol
ICMP (Internet Control Message Protocol) OSPF : Open Shortest Path First
IPv6 IGRP : Interior Gateway Routing Protocol (Cisco)
État de lien
RIP Routing Information Protocol Publications RIP
Algorithme à vecteur de distances

Inclus dans la distribution BSD-Unix en 1982
Mesure de distance : nombre de sauts (maximum = 15 sauts)
Vecteurs de distances : échangés entre voisins toutes les 30
secondes via des messages de réponses (aussi appelés
publications)
Publication : liste composée d’un maximum de 25 réseaux
destinations au sein du SA
RIP : exemple RIP : exemple

Publication de A à D
Dest. Prochain Sauts
w – 1
y – 1
z C 4
... ... ...
Table de routage de D
Réseau destination Prochain routeur Nombre de sauts Table de routage de D
w A 2 Réseau destination Prochain routeur Nombre de sauts
y B 2 w A 2
z B 7 y B 2
x – 1 z A 5
... ... ... x – 1
... ... ...
RIP : panne de lien et récupération RIP : traitement des tables
Gestion des tables de routage de RIP par un processus de niveau

application appelé route-d (démon)
Si aucune publication reçue après 180s → voisin/lien déclaré mort Publications envoyées dans des paquets UDP réémis
Invalidation des routes passant par ce voisin périodiquement
Nouvelles publications envoyées aux voisins
qui envoient à leur tour de nouvelles publications (si les tables ont
changé)
Propagation rapide de l’information de panne
Utilisation de réponses empoisonnées pour éviter les boucles
ping-pong (distance infinie = 16 sauts)
OSPF (Open Shortest Path First) Caractéristiques ”avancées” d’OSPF (pas dans
RIP)
”Open” : disponible publiquement

Utilise un algorithme à état de lien Sécurité : authentification de tous les messages OSPF (pour
Dissémination de paquets EL éviter les intrusions malveillantes)
Carte de la topologie sur chaque nœud Plusieurs chemins de même coût autorisés (un seul pour RIP)
Calcul des routes par l’algorithme de Dijkstra
Pour chaque lien, plusieurs mesures de coût pour différents Temps
Publication OPSF → une entrée par routeur voisin
de service (ex. : coût d’un lien satellite fixé à ”faible” pour du
Publications disséminées dans tout le SA (par inondation) best effort et à ”élevé” pour du temps réel)
Messages OPSF directement sur IP (plutôt que TCP ou UDP)
OSPF hiérarchique dans les grands domaines
OSPF hiérarchique OSPF hiérarchique
Hiérarchie à deux niveaux : zone locale et épine dorsale

Publication de l’état des liens seulement dans la zone
Chacun des nœuds à une vision détaillée de la topologie de la
zone
et ne connaı̂t que la direction (plus court chemin) vers des
réseaux situés dans d’autres zones
Routeurs de bord de zone : ”résument” les distances vers les
réseaux de leurs propres zones et les diffusent vers les autres
routeurs de bord de zone
Routeurs de l’épine dorsale : exécutent un routage OSPF limité à
l’épine dorsale
Routeurs de frontière : connectent aux autres SA
Routage inter-SA d’Internet : BGP Fondements de BGP

Des paires de routeurs échangent des informations de routage sur
des connexions TCP semi-permanentes : sessions BGP
Les sessions BGP ne correspondent pas aux liens physique
BGP Border Gateway Protocol : le standard de facto
Lorque SA2 publie un préfix à SA1, SA2 promet qu’il
BGP fournit à chaque SA un moyen de
retransmettra tous les datagrammes destinés à ce préfixe par ce
1 Savoir comment atteindre un sous-réseau d’un SA voisin préfixe
2 Propager cette information à tous les routeurs du SA
SA2 peut agréger les préfixes dans sa publication
3 Déterminer les ”bonnes” routes vers les sous réseaux en fonction
de l’information d’atteignabilité et de la politique choisie
Permet à un sous-réseau de publier son existence au reste
d’Internet ; ”Je suis là”
Distribution de l’information d’atteignabilité Attributs de chemins et routes BGP
Avec la session eBGP entre 3a et 1c, SA3 envoie l’information
d’atteignabilité d’un préfixe à SA1
1c peut alors utiliser la session iBGP pour distribuer ce Publication d’un préfixe → ajout d’attributs BGP
l’information sur ce nouveau préfixe à tous les routeurs de SA1 préfixe+attributs = ”route”
1b peut ensuite re-publier la nouvelle information vers SA2 par la Deux attributs importants
session eBGP 1b-2a AS-PATH : contient les SA par lesquels la publication est passée :
Lorsqu’un routeur apprend un nouveau préfixe, il crée une entrée SA 67 SA 17
pour ce préfixe dans sa table de routage NEXT-HOP : indique le routeur interne vers le prochain SA (il
peut y avoir plusieurs liens du SA courant vers le prochain SA)
Lorsqu’un routeur passerelle reçoit une publication de route, il
utilise une politique d’importation pour accepter/refuser
Sélection de route BGP Messages BGP
Messages BGP échangés en utilisant TCP

Un routeur peut apprendre plus d’une route vers un préfixe
Messages BGP
Il doit choisir une route
OPEN : ouvre la connexion TCP avec le pair et authentifie
Règles d’élimination l’émetteur
1 Attribut de préférence locale : décision politique UPDATE : publie un nouveau chemin (ou supprime l’ancien)
2 AS-PATH le plus court KEEPALIVE : garde la connexion vivante en l’absence de mises à
3 Routeur NEXT-HOP le plus court : routage en patate chaude jour. Accuse réception d’une requête OPEN
4 Critère supplémentaire NOTIFICATION : rapporte les erreurs des messages précédents.
Également utilisé pour clore une connexion
Politique de routage BGP Politique de routage BGP
A publie le chemin AW vers B

A, B et C sont des réseaux fournisseurs B publie le chemin BAW vers X
X, W et Y sont clients B doit-il publier le chemin BAW vers C
X est doublement hébergé : rattaché à deux réseaux Pas question ! B n’a aucun intérêt à router CBAW puisque ni W
X ne veut pas router de B vers C en passant par X ni C ne sont clients de B
. . . X ne publiera pas de route vers C à l’intention de B B veut forcer C à router vers W en passant par A
B ne veut router que de et vers ses clients !
Pourquoi des routages inter- et intra-SA différents ? Chapitre 4 : Résumé

Politique
Inter-SA : l’administrateur veut contrôler comment son trafic est
routé et qui route à travers son réseau
Principes derrière les services de la couche réseau
Intra-SA : un seul administrateur → pas besoin de décisions Routage (sélection de chemin)
politiques Gestion de l’échelle
Comment marche un routeur
Échelle Instantiation et implantation sur Internet

Le routage hiérarchique réduit la taille des tables et le trafic de RIP
mise à jour OSPF
BGP
Performance
Intra-SA : peut se focaliser sur les performances
Inter-SA : la politique peut influer sur les performances
Chapitre 3 : Résumé Chapitre 2 : résumé
Architectures des applications Protocoles spécifiques

Principes derrière les services de la couche transport Client / Serveur HTTP
Multiplexage et démultiplexage Pair-à-Pair FTP
Transfert fiable de données Hybride SMTP, POP, IMAP
Contrôle de flot DNS
Besoins de services
Contrôle de congestion
Fiabilité Programmation socket
Instantiation et implantation dans Internet Bande passante
UDP Délai
TCP Modèle de service transport d’Internet
Fiable orienté connexion : TCP
Non fiable, datagrammes : UDP
Chapitre 2 : résumé Chapitre 1 : Résumé
Échange classique de messages requête/réponse Apercu d’ensemble d’Internet

Le client demande des informations ou des services
Qu’est-ce qu’un protocole ?
Le serveur répond par des données et un code d’état
Les bords, le cœur et les moyens d’accès du réseau
Formats de messages
Commutation de paquets vs. commutation de circuits
En-tête : champs décrivant les données
Données : informations à communiquer Structure d’Internet
Messages de contrôle et de données (sur ou hors bande)
Performances : pertes et délais
Centralisé ou décentralisé
Sans ou avec état Modèle en couches et de services
Transfert fiable ou non Historique
Complexité au bord du réseau
Ce à quoi vous avez échappé
Couche liaison
Détection et correction d’erreurs
Accès multiples → partage d’un canal de diffusion
Adressage de niveau liaison
Ethernet, ATM, PPP
Couche physique
Plus électronique qu’informatique
Même pas abordé dans l’ouvrage de référence !
F. Suter (M2 IMOI) Introduction aux Réseaux et Internet 4 - Couche Réseau 365 / 365

Reseaux Nupped

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Reseaux Nupped

Загружено:

Авторское право:

Доступные форматы

Cours de réseaux classique

Introduction aux Réseaux et Internet Approche bottom-up

Frédéric Suter (Frederic.Suter@loria.fr) Applications

Connecter deux ordinateurs

Pourquoi une approche Top-Down Plan du cours

Internet : une vue d’ensemble Internet : une vue d’ensemble

Des protocoles contrôlant

Protocoles humains Protocoles réseaux

Services de communication . . . Messages spécifiques Les protocoles définissent le

Exemples de protocoles Plan

Les bords du réseau

Délais et pertes dans les réseaux à commutation de paquets

Couches de protocoles, modèles de services

Systèmes terminaux (hôtes)

Service orienté connexion Service non connecté

Objectif : transfert de Service TCP [RFC 793]

Les bords du réseau

Commutation de circuits Commutation de circuits

Ressources réservées de bout

FDM (frequency division multiplexing) Question

Application numérique Autre application numérique

Dispute des ressources

Commutation de paquets ou de circuits Commutation de paquets ou de circuits

Plus d’utilisateurs avec la commutation de paquets Commutation de paquets : grand gagnant ?

Taxonomie des réseaux Plan

Réseaux de Qu’est-ce qu’Internet ?

Les bords du réseau

Couches de protocoles, modèles de services

Accès via modem

Caractéristiques Jusqu’à 10Mbps en débit descendant (20Mbps en dégroupé)

Réseaux d’entreprise : Local Area Network Réseaux sans fil

Les LAN (local area network)

Les bords du réseau

Délais et pertes dans les réseaux à commutation de paquets

Couches de protocoles, modèles de services

Plan Comment perd-on des paquets et du temps ?

Réseau d’accès Paquet sur le point d’etre transmis (délai)

Couches de protocoles, modèles de services Si plus de place dans la file

1. Traitement du nœud 2. File d’attente

Quatre sources de retard Quatre sources de retard

3. Délai de transmission 4. Délai de propagation

À noter : s et d sont des quantités très différentes

100 kms 100 kms 100 kms 100 kms

Caravane de 10 voitures Péage Péage Caravane de 10 voitures Péage Péage

voiture = bit et caravane = paquet voiture = bit et caravane = paquet

Question Réponse : 62 minutes

Analogie : caravane de voitures (suite) Analogie : caravane de voitures (suite)

100 kms 100 kms

100 kms 100 kms

Les voitures se ”propagent” maintenant à 1000 km/h

dnoeud = dtrait + datt + dtrans + dprop

Perte de paquets Vrais routes et délais sur Internet

File d’attente (ou buffer) précédant le lien dans un routeur

”Couches” de protocoles Organisation du trafic aérien

Les réseaux sont

Une suite d’étapes

Les systèmes sont complexes

Pile des protocoles Internet Encapsulation

Application : implante des

Histoire d’Internet Histoire d’Internet

Minimalité, autonomie : interconnexion sans changements internes

Une ”tonne” d’informations Couche Application

Deuxième partie Quelques applications réseau