Réseaux informatiques

Dirksen Maxime

2020-2021
Préface

Vous pourrez retrouver dans ces notes / cette synthèse, un résumé complet du cours pour l’année
académique 2020-2021.
Cependant, je ne le garantis pas sans erreurs. En effet, j’ai parfois dû faire des interprétations afin
de rendre ce résumé le plus complète possible, ce qui signifie que mes interprétations sont peut être
fausses.
De plus, il y a certainement (c’est sûr), une grande quantité de fautes d’orthographe, principalement
d’accord du pluriel. Mais bon, est-ce vraiment dérangeant ?
Pour finir, les laboratoires du cours apportent certaines informations que je n’ai pas réécrites dans
cette synthèse. Elle prend uniquement compte ce qui a été vu au cours.
Un conseil pour l’examen, il est important de pouvoir faire des liens entre les différents chapitres.
Ce qui n’a pas forcément tout le temps était abordé lors du cours (et donc pas toujours présent dans
mes notes). Alors, n’hésitez pas à vous poser des questions, afin d’au mieux réussir l’examen.

Merci à Dorian Cayphas et Simon Renard pour leur relecture.

1
Table des matières

1 Internet - Introduction 5
1.1 Vue "nuts and bolts" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Vue services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Les protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Dial-Up Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Types de modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Modem DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Modem coaxial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8 Le matériel d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9 Le sans fils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.10 Transmission des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.11 Câble RJ45 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.12 Câble coaxial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.13 Fibre optique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.13.1 Types de fibres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.14 Radio (WiFi, cellulaire, satellite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.15 Paquets switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.16 Circuit switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.17 Circuit switching vs paquet switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.18 Structure du réseau de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.19 Délais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.20 Système en couche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Couche applicative 15
2.1 Vue d’ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Application Client-Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Application P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3 Application Hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.4 Communication entre les processus . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.5 Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.6 Adresse des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.7 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.8 Quelle service est nécessaire lors du transport . . . . . . . . . . . . . . . . . . 16
2.1.9 TCP et UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.10 Sécurité - SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Non-persistent HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Persistent HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Structure de la requête HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.4 Structure de la réponse HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2
 2.3.5 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6 Proxy serveur - Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 Local DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.3 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.4 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.5 Requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Programmation socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Couche de transport 25
3.1 Multiplexage/Demultiplexage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Structure du segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Demultiplexage de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Demultiplexage d’UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Principe de fiabilité du transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Canal fiable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Canal avec erreurs binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3 Canal avec perte de paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Alternating-Bit protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Pipelined protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 Go-Back-N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.2 Selective Repeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.3 Dépassement de paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.2 ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.3 Calibration du timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.4 Receveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.5 Émetteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.6 Contrôle de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.7 Etablir la connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7.8 Fermer la connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.9 Les congestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.10 Contrôle de congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7.11 Modèle de congestion de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.12 Equité de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.13 Autres mécanismes de contrôle de congestion . . . . . . . . . . . . . . . . . . . 45
3.8 Equité de UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Couche réseau 47
4.1 Forwarding et Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Services réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Adressage IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Classe d’adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 CIDR - Classless InterDomain Routing . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Adresse IP spécial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 DHCP - Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Comment obtenir un subnet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Table de forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3
 4.7 NAT - Network Adress Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Datagram IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9.1 MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9.2 Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9.3 Éviter la fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10.1 Datagram IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10.2 Représentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.10.3 Hiérarchie et DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.10.4 Adresse locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.11 Transition IPv4 vers IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.11.1 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.12 Routeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Plan de contrôle de la couche de réseau 61

5.1 Internet Control Message Protocol - ICMP . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Graphe abstrait du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.1 Déterminer le coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Algorithme de routage intra-domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Algorithme "link state" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.2 Algorithme "Open Shortest Path First" - OSPF . . . . . . . . . . . . . . . . . 64
5.3.3 Algorithme "distance vector" . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.4 Algorithme "Routing Information Protocol" - RIP . . . . . . . . . . . . . . . . 66
5.3.5 Comparaison entre LS et DV . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Algorithme de routage inter-domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.1 Algorithme "Border Gateway Protocol" - BGP . . . . . . . . . . . . . . . . . . 68
5.4.2 Intra et Inter domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 Couche de liaison 71
6.1 Protocole à accès multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.1 Channel partitioning MAC protocols . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.2 Random Acces Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.3 ALOHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.4 Carrier-sense multiple access - CSMA . . . . . . . . . . . . . . . . . . . . . . . 74
6.1.5 CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Taking Turns MAC protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.1 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.2 Token passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Accès par câble sur un réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4 Accès sans fil sur un réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5 Réseaux locaux - LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5.1 Les adresses MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5.2 ARP protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.3 Se rendre dans un autre LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5.5 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5.6 Switches Vs Routeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.5.7 Data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.6 Détection d’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.6.1 CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7 Récapitulatif 86

4
Chapitre 1

Internet - Introduction

1.1 Vue "nuts and bolts"

C’est un réseau de réseaux. Avec par exemple le réseau d’une entreprise, le réseau d’une résidence,
les réseaux mobiles et ceux-ci sont relier par des ISP "Internet service provider". On a ici une vue
"nuts and bolts", qui est une vue de l’équipement.
En périphérie du réseau on a les hosts, les appareils qui font tourner nos applications. Et ces hôtes
sont connectés au réseau soit par câbles ou sans fils. Les vrais commutateurs de nos données sont les
routeurs et switches.
Pour mettre en place tout cela, il faut utiliser des protocoles. Ces standards d’Internet appelé RFC
sont établis par des consensus entre constructeurs et universitaires.

1.2 Vue services

Ce sont les services utilisé par les applications ex : Web, VoIP, email, jeux, etc ... C’est les manières
de s’interfacer avec le réseaux. Ces services nécessitent de se connecter à Internet pour envoyer et
recevoir des informations. Mais il existe aussi des services qui ne nécessitent pas de connections
"permanente" à Internet, tel un mail qu’on enverrait sans se soucier de s’il est bien arrivé ou pas.

1.3 Les protocoles

Les protocoles nécessitent un format et un ordre précis d’échanges qui doivent être minimalistes
et non ambigües.

1.4 Structures
Comme dit précédemment nos hosts sont connectés à des ISP, pas tous les mêmes, certain sont
régionaux, d’autres national, parfois propre à des institutions et d’autres global.

Le premier routeur, appelé "edge router", est le premier routeur qui va nous connecter avec un
ISP.

1.5 Dial-Up Modem

A l’époque, le seul moyen de se connecter à l’ISP était le réseau téléphonique, ce réseau transmet
des ondes électromagnétiques mais l’ordinateur et le routeur ne savent pas faire ça. Alors un modem
transformait le flux binaire en un onde électromagnétique et inversement.

5
 Problème, le réseau téléphonique n’a qu’une bande de fréquence de 4kHz. Quel débit binaire peut
on utilisé ? La bande passante est définie par largeur de la bande de fréquence. Et avec le réseau
téléphonique on a au maximum 56Kbps. Et ça coutait un os de faire transiter une information sur le
réseau et donc l’ordinateur ne restait pas constamment connecté sur le réseau.

1.5.1 Types de modulation

Figure 1.1 – Types de modulation d’un flux binaire en des ondes électromagnétique

On peut combiner aussi des modulations, par exemple l’amplitude avec la phase. On parle alors
en baud. 1 baud = 1 symbol par seconde 6= 1 bit. Car un symbole peut contenir plus d’un bit.

Figure 1.2 – Types de modulation d’un flux binaire en des ondes électromagnétique

Pour augmenter le débit de données, on peut donc jouer sur deux facteurs : le débit de baud et
le nombre de bit par baud. Le débit de baud étant limité par la période de max 1/2 et le signal de
max 4khz. Le nombre de bit par baud, est mathématiquement infini, mais pas en pratique, car plus
on s’écarte de l’origine, plus il faut envoyer de la puissance en watt, et ce n’est pas possible de monter

6
trop haut en amplitude sinon on va faire cramer les câbles. Mais bon, la limite de point reste très
grande dans un disque, cependant des perturbations extérieur (bruit) peuvent intervenir et donc on
ne peut pas trop "bourrer" les points qui vont finir par se juxtaposer en cas de bruit.

Le baud-rate est donc limiter par la largeur de la bande H. La loi de Nyquist définit que le baud-rate
≤ 2H. Ce qui implique que la durée du symbole doit être de au moins 1/H.

Le data-rate est de toute façons lui aussi limiter par la capacité du canal. La loi de Shanon a
définit que le data-rate ≤ H log2 (1 + S/N ) où S/N est le rapport de la puissance du signal sur la
puissance du bruit. On a donc que pour un H = 4 kHz et un S/N = 1000 un data-rate = 40 kbps.

1.6 Modem DSL

Toujours sur les lignes téléphoniques, à la différence que, à un moment sur la ligne (à quelques
m/klm de la maison), on va splitter l’ancien réseaux téléphonique et un nouveau réseau internet. On
a donc plus la contrainte du 4kHz et de la sinusoïde. Pour ce faire un splitter sera mis à la sortie de la
ligne de la maison, la voix sera toujours envoyé dans la même zone de fréquence qu’avant mais plus la
data. Le DSLAM (DSL access multiplexer) va séparer ce qu’il y a en dessus des 4kHz vers le réseau
téléphonique et au dessous vers le réseau des ISP.

Du coups, la bande de fréquence Internet peut maintenant être divisé pour un canal montant et
descendant, typiquement de quelques Mbps en montant et 20-30 Mbps en descendant. (Aussi appelé
aDSL car il y a une différence très asymétrique entre ces deux bandes. La vDSL pour "very hight"
(mdr ça reste pas fou) existe aussi et elle permet d’atteindre de plus haut débit sur les deux bandes.)

Le DSLAM étant sur la ligne téléphonique, dans les grandes villes on a un DSLAM tout les quelques
mètres alors que en campagne, c’est tout les quelques klm. D’où une différence de débit significative.

Figure 1.3 – Débit de la DSL en fonction de la distance

La loi de Shanon est donc bien respectée, avec la distance le signal diminue et donc le rapport
S/N devient plus petit et donc moins de débits.

1.7 Modem coaxial

On va faire la même chose qu’avec la DSL, sauf qu’ici c’est le réseau télévisé qui est utilisé.

Un problème qui intervient, c’est le partage des données. Car avec la télé, les chaines passe sur
leur channel de fréquence et sont capturés par chaque maison. Sauf que maintenant, chaque maison
pourrait intercepter les paquets des autres maisons alors. Ce qui pose un problème de sécurité où il
va falloir chiffrer et gérer le partage des ressources.

7
 Le nom de channel/canal a été introduit pour signifier le découpage des fréquences en canaux.
(déjà implémenter avec la DSL).

Ce que certains opérateurs font avec le câble coaxial, c’est qu’il le remplace par de la fibre optique
pour parcourir de plus grande distance. On parle alors de HFC hybrid fibre coax.

On peut attendre des débits de 30Mbps en descendant et 2 en montant. Soit des débits équivalent
à la DSL, du faite qu’il faut partager entre les maisons.

1.8 Le matériel d’accès

Il y a en premier lieu le modem nécessaire pour se connecter au réseau, ensuite le routeur qui
contient un firewall, NAT etc et enfin un émetteur WiFi pour les appareils sans fils. Bien entendu ces
appareils sont souvent combiner dans le même boitier.
Dans un réseau avec beaucoup d’appareils (entreprise) on va mettre entre le routeur et l’émetteur
WiFi, un switch qui va faire office d’intermédiaire pour les appareils et en général le switch renvoie à
travers de la fibre les datas vers un routeur.

1.9 Le sans fils

Le WiFi est fait pour être utilisé à l’intérieur d’un bâtiment de maximum une dizaine de mètres,
car à peu prêt tout corps diminue le signal électromagnétique. On l’utilise alors dans des réseaux LAN
et pas WAN. Sur des routeurs plus récent, on a le MIMO qui va utiliser la capacité à avoir plusieurs
antenne afin de rayonner dans une direction définie afin de courir un maximum avec un signal maximal.
Alors que sans, les antennes rayonnent dans tout les sens, le signal est donc plus faible. Idem pour
l’écoute, on peut améliorer la qualité du signal si on a plusieurs antennes.

Le cellulaire (3G,4G,5G,etc) permet d’atteindre sur des klm des débits d’une centaine de Mbps.
Utiliser en extérieur, grâce à un espace assez vide, les ondes peuvent mieux se répandre.

1.10 Transmission des paquets

Un lien de débit R (bits/sec) va directement limiter le nombre de paquets par seconde. Si un
paquet de longueur L (bits) veut s’envoyer, il va falloir L/R sec. Donc pour limiter les délais, on va
essayer d’envoyer des petits paquets, étant donné que le récepteur va devoir attendre de récupérer
tout les morceaux du gros paquet avant de pouvoir y avoir accès.

1.11 Câble RJ45

Ce sont deux paires (4 fils) de cuivre torsader. Utiliser aussi dans les lignes téléphoniques. En
fonction de leur torsadage, on parle de catégorie.

La catégorie 3 (initialement celle du téléphone), est faiblement torsadé et donne un débit de 10

Mbps. La cat5, moyennement torsadé a un débit théorique de 1 Gbps. Et la cat6, fortement torsader
a un débit théorique de 10 Gbps. Et cat7 encore plus.

Pourquoi torsader les fils ? Si on ne le fait pas, du à la nature électromagnétique de deux fils, cela
va induire des courants (loi de Lenz ) parasite, et donc du bruit. Et donc en faisant des torsades, on
annule les courants. Et plus on torsade, plus on annule les courants induit entre eux.

Et donc directement, si il y a moins de bruit plus on torsade, alors loi de Shanon, le débit augmente.

8
 On pourrait aussi blinder les fils (cage de Faraday) pour éviter une boucle entre les fils. Mais, ça
coute plus cher.

1.12 Câble coaxial

On a toujours deux conducteurs, sauf qu’ils sont l’un dans l’autre. Et du fait de cela, il y a beaucoup
moins de bruit induit.

Figure 1.4 – Structure du câble coaxial

1.13 Fibre optique

La fibre est totalement insensible aux effets électromagnétique. Elle envoie des photons dans le
câble principale en verre. Aucun blindage n’est donc nécessaire. La largeur de bande passante est très
large, le bruit très petit. Loi de Shanon, débit extrêmement grand.

Figure 1.5 – Structure de la fibre optique

Pour éviter la réfraction de la lumière, on va entourer le coeur de verre par un autre type de verre.
On aura donc que de la réflexion dans le coeur de verre. Et dans ce verre, les photons vont se propager
à 28 m/s.

1.13.1 Types de fibres

On a la fibre multi-mode (celle expliqué précédemment) et à cause de la réflexion dans un coeur
de verre de 64µ, certains photons vont mettre plus de temps à arriver que d’autre. Il va donc falloir
prendre un compte un temps de sécurité entre deux émissions pour qu’ils arrivent de manière certaine
dans l’ordre émis. Et donc cela va diminuer le débit, vu qu’il faut attendre.

On a aussi de la fibre single-mode, alors le photon vont tous tout droit, mais c’est plus compliqué
à fabriquer étant donné que le coeur de verre doit être très très fin 2.4µ. (Lorsqu’il s’agira de relier
deux câble de fibre, il faudra qu’ils soient parfaitement aligné.) Le débit sera donc maximale, étant
donné que les photons vont tout droit, on peut les envoyer sans délais.

Le multi-mode améliorer. On va faire un coeur de verre de 50µ avec un indice de réfraction non
uniforme. Alors il y aura toujours de la réflexion, mais celle-ci sera "contrôlée" en une courbes. Et on
a un indice de réfraction plus élevé au centre, et plus on s’éloigne du centre plus l’indice de réfraction
est faible, alors le photon sera accélérer. Ainsi, si cela est fait de manière parfaite (ce qui n’est pas
possible mais on s’en rapproche) on aura l’avantage du single-mode où chaque photon arrive dans
l’ordre de départ et avec un prix équivalent à celui du multi-mode.

9
 Figure 1.6 – Structure de la fibre optique

Autres points ; en multi-mode, plus le câble sera long, plus il faudra augmenter l’espace entre deux
photons d’un même paquet et donc plus le débit sera faible. Ce n’est pas parce que c’est de la fibre
qu’il ne faut pas régénérer le signal car les photons s’atténue, par exemple, celle qui passe sous l’océan.
(Digression : des bateaux placent sans interruption des fibres optiques sous l’océan !)

1.14 Radio (WiFi, cellulaire, satellite)

Très vulnérable aux autres rayonnement électromagnétique et aux obstacles physiques. Ainsi qu’a
la réflexion, comme la fibre multi-mode, qui oblige à mettre en place des traitements sur les paquets
(ex : MIMO).

Et le problème avec les satellites c’est les temps nécessaire à l’information de parcourir la distance
qui pose problème, ainsi que pour les satellites en orbite basse leur mouvement pose problème et donc
il faut mettre en place une constellation de satellites qui communiquent entre eux, afin d’offrir une
grande couverture.

1.15 Paquets switching

On va transférer un flux de données sous formes de paquets, et un routeur va rediriger les paquets
vers le bon chemin. Un paquet ne s’émet pas en un instant, on parle donc de store-and-forward, une
partie du paquet s’envoie, se stock sur le routeur jusqu’à ce qu’il soit totalement reçu il est envoyé
vers le noeud suivant.

Pour un paquet de L bits. Si le débit est de R. Alors le temps total pour faire 2 noeud, hôte
intial-routeur-hôte final prendra 2L/R. Donc plus le paquet sera petit moins il y aura de délais.

Dans le routeur, si trop de paquets arrivent, le temps nécessaire pour en envoyer augmente, ils
vont être mis dans une queue.

Une série d’informations dans le paquet vont être utilisé pour déterminer le chemin à prendre.
Celui-ci n’est pas nécessairement le plus court. C’est ce qu’on appel une table d’envoi (forward table)

10
et elles sont dynamique en fonction des événements sur le réseau (ex : serveur lent, serveur down etc)
par un algorithme de routage. Et donc les paquets peuvent arriver dans un ordre différent que celui
émit. C’est donc les deux hôtes aux extrémité qui vont réarrangé cela.

Router (routing) c’est déterminer la route prise par les paquets et envoyer (forwarding) c’est bouger
les paquets d’un routeur à un autre.

1.16 Circuit switching

Les lignes vont être découpé en canaux et donc en fonction de l’occupation ou non d’un canaux,
le premier paquet va essayer de trouver un itinéraire parmi les canaux libres. Une fois que l’hôte final
a été atteint, le circuit est réservé pour l’utilisateur et ses paquets suivants. Cependant, cela pose des
soucis en cas de surcharge du réseau par trop d’utilisateur.

Mais comment diviser une ligne en canaux ? On peut diviser en terme de fréquence (FDM) et
de temps (TDM). Si on divise en terme de fréquence alors le débit diminue pour l’utilisateur (loi de
Shannon). Si c’est en terme de temps, toute la bande est disponible pour l’utilisateur et tout les X
ms il pourra envoyer un octet du paquet. Ces deux techniques sont assez identique, avant on utilisait
plus le FDM, et maintenant plus du TDM.

Il existe aussi un partage de la longueur d’onde WDM. Qui reste assez similaire à du FDM. Et
on arrive à avoir des débits de 100Gpbs par longueur d’onde et plus de 100 longueurs d’ondes sont
disponibles dans une fibre.

1.17 Circuit switching vs paquet switching

Prenons une ligne de 1 Mbps, et chaque utilisateur utilise 0.1 Mbps 10% du temps.
En circuit-switching, on aura alors 10 utilisateur maximum.
En paquet-switching, même avec 35 utilisateurs, en terme de probabilité avoir plus de 10 utilisateur
actif au même moment est moins de 0.0004. Et on aura un maximum de 100 utilisateurs avec ce
systèmes sans perdre de paquets à cause de la queue trop petite dans le routeur. Soit beaucoup
beaucoup plus qu’en circuit-switching.

L’avantage du paquet-switching est une simplicité dans la mise en place, et un partage des
ressources plus souple. Cependant, il n’empêche pas la congestion en cas de trop de paquets à envoyer.
Et de nous jour, nous sommes quasiment tout le temps en train d’envoyer des paquets et donc le
circuit switching serait peut être une meilleur solution (livre chap 9 pour plus d’infos).

1.18 Structure du réseau de réseau

Un fournisseur d’accès global (global ISP) va faire un dispatching de toute les communications,
car ça ne serait pas possible de faire des connections direct entre chaque réseau local. Il n’existe pas
qu’un seul global ISP autour du monde, cela fait donc encore plusieurs réseaux isolé. On fait donc
des "peering link" entre les global ISP. Et même, les ISP vont partager du matériel ensemble pour
s’interconnecter, on appel ça un "internet exchange point". Comme dit en début de cet introduction,
il existe aussi des ISP régionaux.

Depuis 15 ans, ce système à changé ; des "Content provider network" sont arrivés et se sont
implantés partout à travers le monde. Et leur réseaux est uniquement utilisé pour lui et ses services.
(Akamai en est à l’origine, Google, Microsoft, Amazon, etc).

11
 Figure 1.7 – Structure du réseau de réseau, vue 1

Figure 1.8 – Structure du réseau de réseau, vue 2

Un tier one ISP est un ISP connecté à tout les autres ISP tier one. On pourrait donc dire que les
ISP régionaux sont tier two, et les autres tier three.

Figure 1.9 – Structure du réseau de réseau, vue 3

Chaque ISP a donc plusieurs sorties vers les autres réseaux et entrées vers son propre réseau.
Certaines de ses entrées/sorties sont des ISP client (gagne de l’argent pour prendre en charge l’acheminement
des datas) qui sont de tier inférieur. Des entrées/sorties vers des ISP de tier égal (échange gratuit). Et
enfin des sorties vers des ISP fournisseur qui sont de tier supérieur, autrement dit l’inverse de l’ISP

12
client (paye de l’argent pour demander à acheminer des datas) (ce cas n’est pas représenté par la
figure ci dessus car l’ISP est de tier 1).

Et donc les ISP, peuvent faire des chemins plus long pour acheminer l’information, s’il est moins
cher en fonction des ISP sur la route. Et inversement s’il peut gagner de l’argent en faisant passer les
datas par des clients. (Buisness is buisness)

1.19 Délais
On a quatres facteurs qui rentre en compte.

Figure 1.10 – Délais sur l’envoie du paquet

En premier lieu on a le temps mis par le processeur du routeur pour récupérer les informations
sur l’envoie du paquet, et la vérification d’erreur dans les bits du paquet. Ce temps est donc plus ou
moins constant.

Ensuite il y a le temps passé dans une queue, qui est très variable. Le phénomène est similaire à
celui d’un bouchon sur l’autoroute, plus y il a de paquets plus le délais sera long et cela de manière
exponentielle. L’utilisation peut se mesurer avec (L · a)/R où a est le nombre moyen de paquets, L
le nombre de bits et R le débits. Quand le délais tend vers 0, la ligne est donc sous utilisé alors que
lorsqu’elle tend vers 1, elle l’est trop et donc le délais est énorme. Il faut donc trouver le juste milieu.

Le temps de transmission est "l’envoie sur la ligne", il peut se mesurer en fonction de L/R.

Le temps de propagation est le "transport sur la ligne", et se mesure en fonction de d/s, où d est
la distance physique de la ligne et s la vitesse de propagation sur la ligne.

Le débit, lier à la propagation donc, peut aussi poser soucis dans le cas où on passe d’un grand débit
à un petit, cela pose une zone de rétrécissement "un bottleneck", où les paquets doivent de nouveau
attendre plus longtemps dans une queue et risqué d’être détruit. C’est pour cela qu’il faudrait un
système qui va réguler le débit sur toute la route. Un algorithme de contrôle du flux sera donc utiliser.

Pour connaitre le délais et la route d’acheminement d’un paquet vers une destination on peut
utiliser la commande "traceroute" qui va donner le temps d’aller retour entre les différents noeud
composant le chemin vers la destination. Et avec cette commande, on découvre alors la structure
d’Internet que vont emprunter nos données.

1.20 Système en couche

L’avantage est de pouvoir changer des couches, sans impacter tout le fonctionnement et sans devoir
ce soucier des problèmes lié aux différentes étapes de l’acheminement de l’information. Cependant, on
a une perte d’efficacité lors des transitions entre les couches.

13
 Le réseau de transport informatique, va du plus abstrait au plus physique. Application (HTTP,
FTP, ..) -> transport (TCP, UDP, ...) -> réseau (IP, routage, ...) -> lien (WiFi, Ethernet, ...) ->
physique (bits d’encodage/décodage).

En 1978, ISO voulait créer après application deux couches supplémentaires, la première de présentation,
qui gère par exemple la compression, la sécurité, etc. Et ensuite une couche de session qui gère la
synchronisation etc. Mais à l’époque, on avait pas vu l’utilité ces couches.

Travailler en couche, permet donc l’encapsulation des données. Plus on avance dans les couche,
plus le paquet contiendra des entêtes qui sera utilisé au besoin par les couches suivantes. Et celles-ci
seront modifié quand ça sera nécessaire mais l’information de base elle, n’a pas été modifiée.

14
Chapitre 2

Couche applicative

2.1 Vue d’ensemble

2.1.1 Application Client-Serveur
Il faut au minimum un serveur (il peut avoir des clones de ce serveur et qui se trouve ailleurs pour
répartir les charges), ce serveur doit toujours être présent et son adresse doit toujours être connue.

Le client lui peut ne pas toujours être connecté et n’est pas obligé d’avoir toujours la même adresse.

2.1.2 Application P2P

Avec le P2P les échanges se font directement entre Client-Client. Un exemple type du P2P est la
téléphonie. Contrairement au Client-Serveur, il n’y a aucun problème en terme de charge, car pour le
Client-Serveur il y aura toujours plus de Client que de Serveur. Autrement dit en P2P chaque Client
est aussi Serveur (pas forcément mais plus ou moins).

Maintenant, il faut connaître l’adresse des pairs ? La gestion de la communication entre les clients
est donc assez complexe. Du pure P2P n’existe donc que très peu.

2.1.3 Application Hybride

On va utiliser le principe du P2P mais quelques serveurs vont être mis en place pour facilité la
gestion de l’application. Par exemple : savoir quand une personne se connecte, se déconnecte, son
adresse, les fichiers qu’ils possèdent (File-Sharing) etc. Ex : Skype, BitTorrent.

2.1.4 Communication entre les processus

Sur un ordinateur avec OS c’est facile avec le partage de mémoire. Mais sur un réseau, il n’y a que
l’échange de messages qui est possible. Et au final ça ne change presque rien, il y a en plus du délais
et des pertes. Mais ce n’est pas si grave en fonction des applications, par exemple avec un system de
VoIp (Téléphone par Internet) ce n’est pas grave si des paquets de quelques micro secondes de voix
se perdent.

2.1.5 Sockets
On va intégré au système d’exploitation une fonctionnalité appelé socket pour traiter l’envoie et la
réception des messages. On peut voir le socket comme l’intermédiaire entre l’OS et l’application afin
de faire abstraction.

15
2.1.6 Adresse des processus
Il faut donc un identifiant/une adresse pour ce système connecté à internet : l’adresse. Mais un
système possède beaucoup de processus, pour donc accéder au processus, on va utiliser un numéro de
port.

2.1.7 Protocole
L’échange des messages va varier en fonction du type de message échangé, des champs qu’il possède,
des règles associé au processus de sa structure. Tout ça donne une sémantique au message reçu. C’est
ce qu’on appel un protocole.

2.1.8 Quelle service est nécessaire lors du transport

Quelle intégrité de la data l’application à besoin ? 100% des paquets sont ils nécessaires ?
Quel délais maximum est autorisé ? Est-ce que l’application est instantanée ?
Un débit minimal est il requis ? Est il faible ou élevé ?
Faut-il sécuriser le transport ? Ou l’application sécurise elle même son information ?

Figure 2.1 – Besoin des applications 1

2.1.9 TCP et UDP

Figure 2.2 – Besoin des applications 2

Le service TCP est totalement fiable, les paquets seront donnés à l’application sans perte. Il contrôle
le flux entre l’envoyeur et le receveur afin d’éviter une congestion. Par contre, dû à la fiabilité, il ne
garantie aucun timing. Tout cela peut avoir un impact négatif sur les performances car le "tuyaux"
pour envoyer les données est assez petit.

16
 L’UDP, ne propose aucune fiabilité sur les paquets ni de contrôle de flux et de congestion. Mais il
n’y a donc aucun frein à la vitesse pour l’envoie des données.

TCP et UDP sont donc deux opposés, on a donc en fonction de l’application qu’on a le choix en
fonction de ce qu’on a besoin.

2.1.10 Sécurité - SSL

A la base d’Internet, la sécurité n’a pas été envisagé et donc on a du venir rajouter par dessus des
API de sécurités. Ni TCP ni UDP n’ont été sécurisé donc l’information se transporte en claire. Il faut
donc que l’application s’en charge. Par exemple les applications vont utiliser l’API SSL pour chiffrer
les informations avant d’être envoyer sur le socket.

On voit donc l’avantage du système en couche c’est de pouvoir en rajouter au besoin.

2.2 URL
La page web est un ensemble d’objet mis en place par l’HTML. Et chaque objet est référencé par
une URL. Voici la structure d’une requête url : http ://www.domain.be :port/path/to/ressource.png.
Où http est le nom du protocole, domain.be peut être remplacé par l’ip, et enfin le port peut être
omis sur il est standard (80 pour l’HTTP et 443 pou l’HTTPS).

2.3 HTTP
HTTP : hypertext transfer protocol. C’est un protocole pour les application web qui est basé sur
le modèle du client-serveur. Le client va demander les objets de la page web. Et le serveur va envoyer
les objets en réponses des requêtes du client.

L’HTTP va utiliser le TCP car toute l’information est nécessaire et il ne faudra pas gérer les erreurs
de manières applicatives. HTTP est "stateless", autrement dit le serveur ne garde pas d’historique
des requêtes passé du client. Et on a deux types de requête HTTP : non persistent et persistent.

Figure 2.3 – Exemple d’une requête entre client-serveur

RTT : Temps pour l’aller retour entre client serveur.

Pour chaque requête d’objet, il faudra 2 RTT + le temps qu’il y a fallu pour totalement transmettre

17
le contenu de la requête. Et le temps de transmission d’un fichier est égal à la taille du fichier sur le
le débit moyen du liens TCP.

2.3.1 Non-persistent HTTP

Celui utilisé à l’origine de l’HTTP, à chaque requête, une ouverture et fermeture de connections
était établis. Ce qui a un certain coups en terme de temps pour le client.

2.3.2 Persistent HTTP

Plusieurs requêtes peuvent être réalisés par la même connexion si les requêtes vont toutes en un
même endroit. Cependant, le serveur n’apprécie pas ça car ce n’est pas rentable en terme de gestion
de ses ressources. On fait donc du persistent mais avec une limite dans le temps. Il faut donc dans la
requête signaler au serveur qu’il faut attendre avant de fermer la connexion.
Depuis, le mode persistent est donc devenu le standard. Mais le non persistent peut toujours être
utilisé.

2.3.3 Structure de la requête HTTP

Figure 2.4 – Requête HTTP

Pourquoi on remet l’adresse de l’hôte ? Étant donné que la connections a déjà été établie. Et en
plus c’est le seul champ qui est obligatoire. Voir plus tard lors du "caching".

Figure 2.5 – Structure d’une requête HTTP

La requête on peut la faire de deux manières. POST : en la mettant dans le corps body de la
requête HTTP. Ou GET : directement à l’arrière de la requête URL.

18
2.3.4 Structure de la réponse HTTP

Figure 2.6 – Réponse HTTP

Sur la première ligne, on a la présence du code de réponse (ici 200) qui correspond au statut de la
requête. En voici quelques exemple :
• 200 OK Requête réussie.
• 301 Moved Permanently L’objet de la requête a été changé d’adresse, et la nouvelle adresse
est transmise.
• 400 Bad Request La requête n’a pas été comprise.
• 404 Not Found L’objet de la requête n’a pas été trouvé.
• 505 HTTP Version Not Supported
• 408 Request Timeout La requête a mis trop de temps à arriver, la connexion a été fermé.

2.3.5 Cookies
Le fait que le premier HTTP ne stockait aucun état, avec l’arrivée du commerce au tour du web
on s’est rendu compte qu’il en fallait peut être en faire. On va donc stocker sur le disque du coté du
client dans un fichier dit cookie et du coté du serveur dans une base de données.
Par exemple, lors de la première connexion à un serveur web, le serveur va répondre comme
habituellement mais en répondre mais avec un attribut set-cookie : id supplémentaire qui contiendra
le numéro d’id de l’ordinateur dans sa base de données et il va stocker cet id dans le fichier de cookie.
Lors dans ses prochaines requête, le client va envoyer au serveur l’attribut cookie : id. Et donc le
serveur peut fournir une page web personnalisé.

Cependant, on a donc un échange de données qui deviennent sensibles, il faut donc penser à
sécuriser la connexion de bout en bout car le socket TCP ne chiffre rien. A l’aide du standard TLS
(Sécurité de la couche de transport) qui est une bibliothèque de chiffrement pour le réseau ou son
prédécesseur le SSL (Couche de sockets sécurisée).

2.3.6 Proxy serveur - Caching

Le client va simplement établir une connexion à un serveur intermédiaire dit proxy et qui va
rediriger les requêtes au serveur ciblé par la requête, la réponse du serveur se fera aussi vers le proxy
qui la transmettra au client.

19
 Lorsqu’un autre client se connectera à ce proxy pour envoyé la même requête, le proxy ayant déjà
exécuté cette requête il a mis en cache le contenus et va directement lui répondre.
On va donc avoir un très grand gain de temps, surtout dans les grandes infrastructures qui font
beaucoup de requêtes. Et aussi d’argents car l’entreprise ayant moins consommé, elle devra moins
d’argent au fournisseur du réseau. De plus, augmenter le débit de la ligne va coûter plus cher à
l’entreprise. Et de l’autre coté le serveur de destination aura aussi moins de charge.
On a un peu une analogie avec le P2P hybride.

Pour savoir si la page qui se trouve dans le cache a été modifiée par le serveur ; le cache va faire
la requête au serveur avant de répondre au client, mais en rajoutant l’attribut if-modified-since :
<date> si l’information n’a pas été modifié par le serveur depuis, alors il ne retournera que le code
304 Not Modified et pas le contenu de la page et donc le cache peut donner l’objet qu’il avait
sauvegardé. On a donc un gain de temps est et la page est à jour. Si les données ont été modifiées, le
serveur va retourner son traditionnel code 200 ok avec les données de la pages. Le cache se recharge
et l’information est transmise au client. Du coups ici on a aucun gain de temps (éventuellement une
petite perte de temps mais pas grand chose).

Digression : dans le cours on parle du caching avec proxy serveur, mais les navigateurs web peuvent
aussi (et le font) faire du caching en local, cela fonctionne de la même manière.

2.4 DNS
Étant donné que ce n’est pas très pratique d’utiliser des adresses IP qui sont sur 32 bits, on aimerait
utiliser des noms qui vont rediriger vers l’adresse tel un pointeur.
Car à l’époque de ArpaNet, tout les mapping entre adresses et noms étaient stocké dans un
fichier hosts que tout le monde téléchargeait d’Internet. Cependant, cela n’était plus envisageable
avec l’expansion d’Internet. C’est pour cela que le DNS (dynamic name server) a été créé et qui va
aussi apporter d’autres avantages et fonctionnalités :
• Traduction de nom d’hôte à adresse IP. (premier niveau d’indirection)
• Alias : redirection vers un autre nom d’hôte. (deuxième niveau d’indirection)
• Redirection des mails vers un serveurs pour les mails. (redirection des services)
• Répartir la charge entre plusieurs serveurs pour un même service. (idéalement celui le plus
proche du client)(et donc aussi éviter l’inaccessibilité en cas de panne)

2.4.1 Structure
On va utiliser la structure naturelle qu’il y a dans les noms qui sont séparé par des point, on peut
donc les organiser tel un arbre :

Figure 2.7 – Réponse HTTP

On peut donc se dire que pour faire une requête à un serveur, on va interroger la racine, qui va
nous dire où ce trouve le serveur de l’extension qui peut amener jusqu’au domaine principal etc ...
celui qui fait la requête n’a donc besoin que d’un minimum de connaissance qui permet d’être efficace
et robuste en cas de changement au niveau de tout ces serveurs.

20
 Pour ce faire on a réparti équitablement au tour du globe et gérer par 13 organisations différentes
(il y en a bien plus que 13 serveur physique, wikipedia parle de 1000 en 2019 (contre 130 en 2007)).

L’extension des noms qui représente le deuxième niveau de l’arbre est appelé TLD server pour
top-level domain server. Ce sont les serveurs responsable des .be, .com, .net etc ...
Au troisième niveau qui représente le nom du domaine, le DNS est dit autoritative car il est
l’unique (ou un des uniques) gestionnaire du domaine, ils sont gérés par des organisations privés ou
des instituts tel l’ULB qui peuvent faire se qu’ils veulent avec les niveaux suivant.
Du coups, ensuite, il y a d’autres niveaux qui peuvent être un sous domaine authoritative s’il est
gérer par un autre organisation que le domaine du dessus etc. Et vu qu’ils sont géré de manière libre
par celui qui le possède, il peuvent le vendre, créer autant de niveau qu’ils souhaites etc ...

2.4.2 Local DNS

Le DNS local est le DNS par défaut, c’est lui qui va exécuter la recherche de l’adresse parmi les
autres DNS root puis TLD et authoritative afin de retracer le chemin de l’adresse et qui va retourner
la réponse au client. De plus il peut faire du caching de sa recherche, pas seulement de l’adresse du
serveur recherché mais de tout les DNS qui ont composé la route, afin de gagner du temps sur celles
futures. C’est la méthode itérative.

On a aussi la méthode récursive où c’est chaque serveur qui va faire la recherche pour le suffixe
suivant et pas uniquement le serveur local. Ici le caching peut se faire sur tout les serveurs. Cependant,
la répartition des charges est mauvaises, surtout pour les DNS root et TLD car ils reçoivent des requêtes
identiques de manières multiples.

On va donc plutôt utiliser le modèle itératif car chaque serveur authoritative peut aussi être le
local du coups pas de recherche à faire. On aura une meilleur répartition car chacun va plus ou moins
s’occuper du même nombre de requêtes.

Figure 2.8 – Requête DNS - méthode itérative à gauche et récursive à droite

2.4.3 Caching
Dans la sous section précédente on a parler de comment peut être mis en place le caching avec
le contenue des pages. Et bien avec le DNS on va faire la même chose avec les adresses des serveurs

21
contenants les pages web car dans la réalité les adresses des serveurs ne change que très peu. On va
donc mettre en place un champ TTL lors des réponses qui dira combien de temps il peut garder en
cache son adresse.
On peut aussi mettre en place un système de notification au DNS quand le serveur change son
adresse, c’est appelé DDNS pour dynamic DNS.

2.4.4 Records
Les entrées du DNS sont appelés ressources records ou RR qui est représenté par un 4-uplet :
(name, value, type, ttl) où le type va définir la relation entre le nom et la valeur. Voici quelques
exemples de records :
Quelques notions avant de voir les exemples :
• IPv4 est sur 32 bits et l’IPv6 sur 128.
• FQDN signifie nom d’hôte autrement dit le nom complet du domaine qui comprends alors le
sous domaine par exemple www.domaine.com est un FQDN mais pas domaine.com (attention
ceci dépend de l’infrastructure, si elle ne comporte qu’un serveur qui est domaine.com alors il
est FQDN).
• Un nom canonique signifie le vrai nom.
• Un nom alias signifie un un nom synonyme.
• Une zone DNS c’est l’ensemble de sous domaine et du domaine géré par une même personne/institut.
On pourrait donc avec des sous domaine dans différentes zones.

RR :
• type=A ou AAAA alors name=FQDN et value=ipv4 ou ipv6. On va mappé un domaine sur
une adresse ip.
• type=CNAME alors name=nom alias value=nom canonique. On va mappé des nom entre eux,
autrement ce n’est qu’une redirection.
• type=NS alors name=le domaine value=authotitative serveur DNS. Cela permet d’identifié
quel DNS est responsable de la zone.
• type=MX alors name=le domaine et value=serveur mail

2.4.5 Requête

Figure 2.9 – Structure requête DNS

22
 Les requêtes vont se faire via UDP car pour un simple paquet il n’est pas nécessaire d’établir
une connexion sûr entre les serveurs DNS, on utilisera au niveau des DNS un petit programme de
réparation des erreurs et au pire des cas la requête renvoyé car il n’a pas reçu de réponse et voilà.
Pour des raisons de sécurités les informations additionnelles sont souvent ignorées.

2.5 Programmation socket

Le socket c’est l’interface (API) entre l’application et le protocole de transport.

Figure 2.10 – Socket réseau

Comme on l’a déjà expliqué on peut utiliser soit un transport en TCP ou UDP. Ce que va donc
devoir faire le socket n’est pas la même chose en fonction du choix. Dans le cas d’UDP, le paquet
formé par le socket doit être autoportant et donc doit contenir toutes les informations sur l’envoyeur,
le processus etc. Tandis qu’avec TCP, il y a une connexion que le socket doit établir avec un autre
socket distant et ensuite il peut envoyer les segments contenant les bytes ainsi qu’un quadruplet (IP
dest, port dest, IP source, port source), rien de plus.

2.5.1 UDP
Bind c’est lier port au socket.

Figure 2.11 – Interaction entre socket client/serveur en UDP

23
 Communiquer en UDP est en faite ce qu’il y a de plus simple, le serveur n’a besoin que d’un
socket et d’un port particulier puisqu’il n’a qu’a écouter les paquets entrant et répondre à l’adresse
qui l’envoie. Le client quant à lui va créer un socket générique, peut importe le port, les informations
du serveur distant (adresse + port) ne sont nécessaire que pour créer le paquet. On a donc coté serveur
1 seul socket d’ouvert et 1 seul pour le client également.

2.5.2 TCP
Listen call , permet de faire une liste d’attente sur le socket.

Figure 2.12 – Interaction entre socket client/serveur en TCP

Communiquer en TCP va demander de créer un socket qui va recevoir les demandes de connexions
et lorsque cette demande de connexion est acceptée on va créer un nouveau socket dédier au client.
Le client lui va devoir créer un socket uniquement dédié au serveur et les bytes peuvent être envoyé
sans aucune autre informations. Il faut donc coté serveur autant de socket que de client connecté plus
1 (le welcomeSocket). Et coté client 1 socket par serveur connecté ce qui signifie qu’on ne peut avoir
qu’une seule application par port.

24
Chapitre 3

Couche de transport

Il est important de bien dissocier la couche de transport de la couche réseau. La couche de réseau
et les couches en dessous assurent une connectivité de bout en bout entre les deux systèmes. Et la
couche de transport assure une connectivité entre deux processus qui vont s’échanger ce qu’on appel
des segments (des parties de données).

Il existe deux protocoles de transport, TCP et UDP qu’on a déjà plusieurs fois abordés. Et il est
important de noter qu’aucun des deux ne fournis une garantie de performance qui assure le débits ou
le délais car les couches inférieurs n’ont pas de mécanisme pour cela.

3.1 Multiplexage/Demultiplexage
Le multiplexage c’est de traiter indépendamment l’envoie de chaque paquet à travers les couches
de protocoles. Et à l’inverse le demultiplexage c’est de traiter indépendamment la réceptions de chaque
paquet à travers les couches pour les donner au socket associé au processus.

3.1.1 Structure du segment

Other header filds sera des champs qui seront différents en fonction du protocole.

Figure 3.1 – Structure du segment

Peut importe le protocole de transport, ce qu’il y aura dans la section message sera le même. On
remarque qu’il n’y a pas la présence d’IP, uniquement le port source et de destination. En effet ici
c’est le segment visible par la couche de transport, il sera complété par les couches du dessous qui
enlèverons à la réception de ce qu’elles avaient rajoutée et l’IP en fait partis.

25
3.2 Demultiplexage de TCP

Figure 3.2 – Transport en TCP

Il va falloir changer au pire cas chaque socket coté serveur pour chaque domaine si la connexion
HTTP est non persistante. Il y aura donc beaucoup de socket associé à un même port, mais vu que
une connexion = un socket càd un ip1/port1 = ip2/port2, il n’y pas d’ambiguïté pour trouver le
bon socket. (il faut que la couche réseaux retransmette à la couche de transport l’IP qu’elle est sensé
enlever du segment)

3.2.1 Demultiplexage d’UDP

Figure 3.3 – Transport en UDP

Il faut que le socket transmettent un datagram, autrement dit tout ce qu’il faut pour construire le
segment car il doit être autoportant. Dans le cas d’UDP lors du démultiplexage on regardera le port

26
de destination, c’est très simple. Et le serveur répondra en inversant ces ports dans le segment qu’il
envoie.

Le protocole UDP va aussi rajouter à la structure du segment que l’on a vu la taille (sur 16 bits)
de la section de données vu qu’elle est de taille variable ainsi que un checksum (sur 16 bits) qui est
une petite fonctionnalité pour détecter les erreurs.
A l’envoie le checksum va sommer les 4 autres champs et à la réception on va resommer les 4 autres
champs pour voir si le checksum correspond. S’il y a une différence, on ne sait pas combien de bits
sont erronés ni dans quelle section (peut être même dans le checksum lui même), dans ce cas UDP va
supprimer le segment ou si l’application le souhaite elle peut désactiver le checksum pour qu’UDP ne
le supprime pas en cas d’erreur, c’est elle qui va gérer.
Il est important de noté que même en cas de bon checksum on ne peut pas être sûr que les données
sont correctes, il y a peut être eu deux erreurs qui on compensé la somme.

Calcul du checksum - digression

Vu que le checksum somme des valeurs sur 16 bits et qu’il est sur 16 bits il faut avoir recours à
une astuce ; le complément à 1 (cf cours de fonctionnement des ordinateurs).
C’est donc très rudimentaire, ce choix a été fait car il y a déjà des détections d’erreurs dans les
couches plus basses, on ne veut donc pas surcharger le nombre d’opérations pour trouver des erreurs
sachant que ce n’est jamais à 100% fiable.

3.3 Principe de fiabilité du transport

Il va falloir implémenter quelque chose qui va donner l’impression que le canal est fiable alors qu’il
ne l’est pas. On va représenter ce mécanisme sous forme de diagramme à automate fini, où on a des
états et les transitions entre eux sont atomiques. Nous décrirons les transitions de cette manière :
evênement .
action

3.3.1 Canal fiable

Pour commencer on va faire l’hypothèse que le canal est faible. On doit donc uniquement former
le paquet pour l’envoyer et le lire quand on le reçoit.

Figure 3.4 – Communication sur un canal fiable

27
3.3.2 Canal avec erreurs binaire
Maintenant, on va faire la supposition qu’il peut y arriver des erreurs binaires lors du transport.
Pour cela on va devoir avoir un détecteur d’erreur et un mécanisme de retour pour informer l’émetteur
qu’il y a eu une erreur : NAK (négative acknowledgement) ou qu’il n’y en a pas eu : ACK (acknowledgement).
Pour cela on peut utiliser un checksum (plus élaboré que celui d’UDP pour éviter la compensation
de deux erreurs) comme détection d’erreur, lorsque la réponse sera NAK on renvoie le paquet, si c’est
ACK on ne fait rien et on passe au suivant.
Le problème avec cette technique, c’est que la réponse NAK ou ACK peut elle aussi avoir été
soumise à des erreurs et peut être inversé la réponse. On peut donc aussi utiliser la technique de
checksum pour cette confirmation. Mais que faire dans ce cas-ci ? Renvoyer le paquet et possiblement
créer un doublons au niveau du receveur et donc créer une ambiguïté ? (car le receveur ne peut pas
savoir si c’est normal d’avoir un doublon ou non) Il faudrait donc distingué une retransmission du
paquet et ce qui est l’envoie d’un nouveau paquet en les numérotant. Et ainsi savoir si le paquet qu’on
reçoit est nouveau ou s’il a déjà été reçu et donc que c’est une retransmission.
On appel ce style de protocole est stop and wait.

Figure 3.5 – Communication avec erreurs sur les bits sans numérotation des paquets

Figure 3.6 – Communication avec erreurs sur les bits avec numérotation des paquets coté receveur

28
3.3.3 Canal avec perte de paquet
Maintenant rajoutons le fait qu’on puisse perdre des paquets. Ce qui avec le système précédent
donne un blocage total (deadlock) car chaque échange de paquet était basé sur une réponse de l’autre.
On va donc mettre un place un timer (watchdog) qui après ce temps écoulé déduira que le paquet a
été perdu étant donné qu’il ne reçoit rien en retour (soit un nouveau paquet pour le receveur soit la
réponse ACK pour l’émetteur).
Mais on pourrait améliorer cette échange, en utilisant uniquement le timer et plus les réponses
NAK. Lorsque le receveur pense qu’il y a une erreur, il ne va rien faire, et du coups l’envoyeur va
penser qu’il ne l’a pas reçu et va lui renvoyer. On va donc économiser des échanges de messages inules.
Mais il peut se produire un problème de "course", où les échanges vont se croiser du fait que
c’est un full-duplex channel (autrement dit qu’on peut échanger des messages dans les deux sens
simultanément) :

Figure 3.7 – Canal avec timer et réponse ACK

On peut arranger ce problème de la même manière qu’on a fait avec les paquets, en numérotant
les ACK au paquet correspondant :

Figure 3.8 – Canal avec timer et réponse ACK numéroté

3.4 Alternating-Bit protocol

On arrive donc avec la solution dit Alternating-Bit conçu en 1969. Cependant, il y a encore un
problème qui n’avait pas été imaginé à l’époque car c’était une liaison physique avec un fil entre deux
machines soit un unique chemin. Mais notre structure d’Internet actuel possède plein de chemins pour
arriver à une machine et donc un paquet envoyé après un autre peut arriver dans l’ordre inverse si le
premier a été ralenti sur son chemin.

29
 Figure 3.9 – Alternating-Bit avec paquets se dépassant

Le problème commence à la flêche "pkt reordering" où le paquet 1 arrivant avant la réémission

inutile du paquet 0. Et vu que les paquets sont numéroté en alternance 0 ou 1, le tout premier paquet
va apparaître comme le 3ième. Ce qui aurait pu être rattrapé par le vrai troisième paquet portant le
numéro 0 qui s’est perdu et le ACK du faux troisième paquet arrive du coups l’émetteur pense que
tout est bon alors que rien ne l’est.

La meilleur solution serait de numéroté avec plus de nombre que 0 et 1, dans l’idéal avoir une
nombre non borné permettrait de jamais se tromper dans l’ordre des paquets. Sauf que en pratique
la taille du paquet est borné mais en soit il restera assez grand pour avoir une probabilité très faible
que au moment où on va réutiliser 0 que le premier paquet soit toujours sur le chemin.

3.5 Performance
Avec un système stop and wait on obtient ces performances :

Figure 3.10 – Temps pour l’envoie d’un paquet

On sait déjà comment calculer le temps de transmission t = L/R (taille du paquet sur le débit)
et que le RTT est le temps pour un échange envoie-réponse donc la durée totale d’un cycle pour un

30
paquet est RTT + t. Maintenant, U est la charge de l’émetteur, on aimerait donc qu’elle soit maximum
(=1) ce qui signifierait qu’il ne passe pas de temps à rien faire. Pour cela il faudrait avoir un (R ·
RTT)/L petit. Notons que R · RTT/2 est le nombre de bits en transit si on envoie à la total capacité
du canal ce qui est le décalage entre l’émetteur et le récepteur. Du coups on peut joueur sur 2 facteurs,
en augmentant L et donc t augmente la ligne bleu devient plus large ou en augmentant R qui diminue
t et donc la ligne bleu serait plus fine ce qui signifie que il y aura moins de décalage entre l’émetteur
et le récepteur (dû à l’explication dans la phrase précédente) et donc un pourra diminuer le temps du
cycle. On ne peut pas directement jouer sur le RTT car il est lier à la distance ; plus les deux machines
sont loin plus obligatoirement le RTT sera grand car le temps nécessaire aux bits pour parcourir la
distance augmente.

Exemple chiffré : sur une ligne à 1Gbps et un RTT de 30 ms ainsi que des paquets de 1 KB. Ce qui
3 bits
donne : Ttransmit = R L
= 810109 bps = 8 µs = 0.008 ms et Usender = RT TL/R
+L/R
0.008
= 30.008 = 0.0002667.
Alors toutes les 30 ms on envoie un paquet et le reste du temps on ne fait rien soit 266.7 kbps de
débits sur un liens de pourtant de 1 Gbps donc quelque chose de vraiment NAZE.

3.6 Pipelined protocol

On veut pouvoir s’enlever du modèle stop and wait. Pour cela on va envoyer tout les paquets l’un
à la suite de l’autre et le receveur enverra les ACK au fur à mesure qu’il reçoit les paquets ils doivent
donc avoir une numérotation unique pour chaque afin de les différencier.

Voici un exemple utilisant les chiffres précédent avec l’envoie sur 3 pipe et l’on remarque que on a
augmenter l’utilisation par un facteur 3 et donc linéaire.

Figure 3.11 – Pipelining

Mais on a un maximum de pipeline possible, sur cette figure environs 7-8 et l’envoyeur sera actif
tout le temps.

Il existe deux familles de protocoles pipelines : Go-back-N et Selective Repeat. On dit que dans le
Go-back-N les ACK sont cumulatifs c’est à dire que le receveur ne va pas envoyer un ACK pour chaque
paquet mais va dire qu’il a reçu jusqu’à tel paquet et n’utilisera qu’un seul timer qui commence au
plus vieux paquet pour lequel on a pas encore reçu de ACK qui le couvre. Si le timer vient à terme on
retransmet tout les paquets qui n’ont pas été couvert par un ACK. Tandis qu’avec Selective Repeat
on envoie un ACK par paquet et chaque paquet aura son timer.

31
3.6.1 Go-Back-N

Figure 3.12 – Buffer de l’émetteur

L’émetteur aura un buffer (tableau) pour stocker les messages afin de savoir si il a reçu un ACK
le couvrant. En effet, comme dit précédemment les ACK peuvent être cumulatif : "tout reçu jusqu’à
X" qui incrémentera jusqu’à X le pointeur sendbase. (Le ACK doit avoir été transmis sans erreur, s’il
a été reçu avec erreur on l’ignore, ce n’est pas grave vu qu’ils sont cumulatif). Quand on veut envoyer
un nouveau paquet on incrémente le pointer nextseqnum.
On aura un unique timer qui démarre à chaque nouveau paquet pointer par sendbase et si le timer
vient à terme tout les paquets jaune se trouvant dans la fenêtre vont être renvoyé.
L’émetteur enverra un ACK positif quand un paquet arrive et que c’est le paquet attendu, en
effet vu qu’il n’y a pas de buffer coté receveur, il a juste un compteur, il va jeter les paquets qui sont
arrivés "trop vite" et ils seront renvoyé par l’émetteur à la fin du timer. Mais le problème c’est qu’un
décalage induit directement une retransmission de tout les paquets plus vieux que lui, on perd alors
tout l’intérêt du pipelining.
La taille de la fenêtre (et donc le nombre de pipe) doit au maximum être de taille k-1, où k est le
nombre de numéros distinct pour les paquets. Car dans le cas où ils ont bien été reçu mais les ACK
se perdent l’émetteur va donc tout renvoyer et le receveur va penser que c’est bien une nouvelle suite
et pas une réémission. Alors que si on enlève 1 à la fenêtre le receveur va attendre le kième et quand
il va rerecevoir le 0, il aura compris que c’est une réémission.

3.6.2 Selective Repeat

Presque la même chose que le Go-Back-N à deux différences. Premièrement l’émetteur aura un
timer différent pour chaque paquet et donc on peut dans la fenêtre avoir un mélange entre ceux qui

32
ont été ACK (non cumulatif ici) et ceux pas encore ACK. Deuxièmement, le receveur aura aussi un
buffeur qui va garder les paquets qui sont arrivé avant celui attendu.

Voyons la relation entre les deux fenêtres. Au départ elles sont toutes deux au même niveau. On
pourrait aussi avoir la fenêtre du receveur en avance, ce qui signifie que des ACK se sont perdus. Mais
l’inverse est impossible car cela signifierai qu’il a reçu un ACK et s’il a reçu un ACK c’est que le
receveur a reçu le paquet et donc qu’il a avancé sa fenêtre. Le receveur ne peut pas avoir une fenêtre
totalement en avance d’au plus 1 paquet (aucun paquet en commun), se qui signifierai que tout a été
reçu et qu’il attend de nouveau paquet. Si on avait plus de un paquet en décalage cela voudrait dire
que le récepteur a reçu des paquets non envoyé.
En résumé l’émetteur :
— Si une place est libre dans la fenêtre, on envoie un paquet et on démarre un timer pour lui.
— Si un timer vient à terme, on revoie le paquet associé et on redémarre ce timer.
— Si on reçoit un ACK pour le paquet n compris dans la fenêtre
— On marque le paquet comme reçu et on arrête le timer
— Si le paquet n était le plus vieux de la fenêtre on peut avancer la fenêtre jusqu’au suivant
qui n’est pas encore ACK
En résumé le receveur :
— Si on reçoit un paquet n compris dans la fenêtre :
— On envoie le ACK
— Si ce n’est le premier attendu, on le place dans le buffer
— Autrement on le délivre au socket pour l’application et on avance la fenêtre jusqu’à celui
qui qui n’est pas encore dans le buffer tout en les délivrant à l’application.
— S’il est avant la fenêtre on envoie le ACK
— S’il se trouve après la fenêtre il est ignoré
Maintenant, on aimerait savoir la plus grande de taille de fenêtre possible, elles doivent au maximum
être de taille k/2 chacune (plus petit chez l’un ou l’autre est bien entendu possible). Car la fenêtre
du receveur ne peut pas créer d’intersection (commencer une nouvelle numérotation avant l’émetteur)
avec celle de l’émetteur car ils sont susceptible d’être retransmis et être interprété tel un nouveau et
donc qu’elles peuvent être au maximum décalé d’un paquet comme envisagé précédemment.

On peut donc généraliser la taille de la fenêtre par la formule Ne + Nr ≤ K. En effet dans le cas
du GBN on a dit que Nr = 1, Ns ≤ K − 1, pour le SR on vient de voir que Ne = Nr ≤ K2 et pour
l’alternating-bit on avait vu que K = 2, Ne = Ns = 1.

De plus, on a dit qu’il a un timer par paquet mais c’est assez laborieux de gérer plein de timer, on
peut en pratique en utiliser un seul et à la fin de chaque rajouter le temps qu’il faut comme si il était
le timer du paquet suivant.

3.6.3 Dépassement de paquet

GBN
Prenons un K = 4 et N = 3
On a ici que l’ancien 0 qui est réémis car le ACK est arrivé en retard est pris coté récepteur comme
le 0 de la nouvelle itération.
On pourrait augmenter le timer mais ce n’est pas très malin et dangereux. Le mieux serait d’avoir
un K très grand afin de réduire la probabilité que énormément de paquet soit passé devant et vu que
K est très grand on pourrait avoir une fenêtre N beaucoup plus petit K et donc encore diminuer les
chances de ce cas de figure. Mais si un paquet peut rester indéfiniment dans le réseau et donc avoir
un très très grand retard ça peut toujours poser soucis, on va donc mettre un place un mécanisme de
destruction de paquet quand il transite dans le réseau s’il est trop vieux. Avec tout ça les chances que
ça ce produise sont plus que négligeable.

33
 Figure 3.13 – Dépassement de paquet pour le GBN

SR
Même problème avec le SR, prenons un K = 4 et N = 2,

Figure 3.14 – Dépassement de paquet pour le SR

Et on peut le résoudre de la même manière sauf que bien sûr ici il faut que la fenêtre N soit
beaucoup plus petite que K/2 et non K.

3.7 TCP
Comme on l’a déjà dit, la connexion est point à point avec ouverture de connexion, il est fiable,
il envoie des bytes groupé en segment et pas des paquets, il est full duplex (bi-directionnel). Et
maintenant on sait qu’il utilise des pipelines.

3.7.1 Structure
On retrouve ce qu’on avait avec celle de l’UDP mais avec plus d’éléments et d’options.
Le flag S signale qu’il est le segment pour l’ouverture d’une connexion. Le flag F signale la fin
d’une connexion. Et le flag R pour refuser l’ouverture de la connexion. Le bit A signifie que la champ
acknoledgement number est à considérer.

34
 Figure 3.15 – Segment de tcp

3.7.2 ACK
Les ACK seront cumulatif comme le GBN à la différence qu’ils informent le prochain byte attendu
et pas jusqu’à quel byte on a reçu autrement dit : "tout reçu jusqu’à X non compris". Mais à l’aide
de l’option SACK on peut aussi envoyer un simple ACK pour mettre de ACK des paquets qui ne sont
pas arriver dans le bon ordre et éviter la retransmission. Du coups cela permet coté client d’utiliser
ou non un buffer ou un petit car on peut modifier la taille de la fenêtre comme paramètre dans le
segment. On a donc quelque chose d’hybride entre GBN et SR.

Figure 3.16 – Fenêtre pour TCP

35
3.7.3 Calibration du timer
On ne peut pas avoir un timer constant car on passe dans un réseau et pas un câble, il y a donc
des fluctuations dû à différent facteur. Donc s’il est trop petit on va renvoyer trop de paquet et s’il est
trop long on va trop attendre. TCP va donc estimer le RTT. Il va inclure l’heure du timer à l’envoie
dans le segment et quand le récepteur va envoyer le ACK il va retransmettre ce timer, le récepteur
va donc pouvoir regarder combien de temps cela a pris, on appel cet échantillon SampleRTT qu’il va
répéter plusieurs fois.

Et à chaque test du RTT il va faire un

EstimateRTT = (1 − α) · EstimatedRTT + α · SampleRTT

dans cette formule on voit donc que le nouveau SampleRTT aura plus d’importance que les anciens
du fait que à chaque fois les anciens SampleRRT seront pondéré (1 − α) et ainsi de suite. Typiquement
α vaudra 0.125

Mais une moyenne ne suffit pas il faut une marge de sécurité avec

DevRTT = (1 − β) · DevRTT + β · |SampleRTT − EstimateRTT|

Typiquement β vaudra 0.25

Maintenant on déterminera le timer avec

TimeoutInterval = EstimateRTT + 4 · DevRTT

3.7.4 Receveur
On va essayer d’en envoyer le moins de ACK possible.
— Si le segment est celui de l’ordre attendu, on va attendre un peu avant d’envoyé le ACK,
environs 200 ms, on parle alors de ACK pending
— Si le segment est celui de l’ordre attendu et qu’il y a un ACK pending, alors on envoie un ACK
cumulatif pour ces deux-ci. (on pourrait aussi attendre plus que 1 sur 2)
— Si le paquet n’est pas celui de l’ordre attendu, il est mis de coté et on détecte donc un gap
(trou) on va alors renvoyer un ACK dupliqué qui est celui précédemment envoyé. (ou si l’option
SACK a été activé à la connexion, on va rajouté en option au ACK, le fait qu’il a aussi reçu
ce paquet).
— Si le segment qui arrive est celui comblant au moins le début du gap, on va envoyer un ACK.
S’il n’est pas au début on le met de coté comme fait précédemment.

3.7.5 Émetteur
Lorsque l’envoyeur TCP reçoit des bytes, il va créer un segment et le bufferiser. Il sera envoyé
lorsqu’il rentre dans la fenêtre et il va en lancer un timer valant TimeoutInterval. Lorsqu’un timer
d’un paquet déclenche on va juste renvoyer le paquet en question et redémarrer le timer. Lorsqu’il
recevra un ACK, il regardera s’il peut glisser la fenêtre pour envoyer de nouveaux segments.

Les numéros de segments ne seront pas continue car on envoie des bytes et donc l’incrément se
fera en fonction de la taille de la data envoyé.

Lorsqu’il reçoit un ACK portant le numéro n, on va faire glisser la fenêtre (le pointeur sentbase)
jusqu’au paquet n (car le receveur informe qu’il a tout reçu jusqu’au paquet n non compris).

TCP est dit fast retransmit, c’est à dire qu’il va tenter de détecter les pertes plus rapidement
que le timer. Il va retransmettre sans attendre la fin du timer. En effet, si par exemple on envoie le

36
paquet numéro 92 puis 100 puis d’autre. Le 100 se perd et donc le receveur envoie des ACK "j’ai tout
reçu jusque 100 non compris" pour les autres segments aussi. Alors directement après avoir reçu X
doublons de ACK = 100. L’émetteur se dit directement que visiblement le paquet 100 a été perdu.

En résumé :
— Comme le fait le GBN :
— Utilise des ACK cumulatif
— Utilise un seul timer
— Comme le fait le SR :
— Utilise un buffeur coté receveur
— Retransmet seulement le plus vieux paquet à la fin du timer
— On peut faire des ACK seul (non cumulatif)
— Et vient rajouter :
— Le mécanisme de retransmission rapide
— Utilise des ACK retardé (pending)

3.7.6 Contrôle de flux

On veut éviter que le buffer du récepteur déborde. Car l’application lis sur le socket les bytes
qui attendent dans la file (aussi appelé recieve window). Cette file a donc une limite en taille et si
l’application ne les lit pas, la fenêtre peut se retrouver pleine et elle déborde (paquet détruit). On
aimerait donc pouvoir dire à l’émetteur d’arrêter car la file va être pleine. Le récepteur pourrait alors
dans ses ACK dire combien de bytes sont encore disponibles dans la file et donc il n’enverra pas plus
que cette quantité de byte jusqu’à recevoir dans le prochain ACK la nouvelle quantité.

Cependant ce n’est pas très performant pour le débit de TCP. En effet, l’émetteur ne pourra
pas envoyer plus de la taille du buffer . En TCP la taille du header pour informer la taille du buffer
RTT
disponible est sur 16 bits ce qui fait 216 bytes pour celui-ci et donc au maximum un débit de 65 KB
par RTT. Ce qui est très faible, surtout avec des grands RTT et on aura donc des performances limités
même si coté récepteur le buffer est quasi toujours vide.
Pour palier à ce problème, on va passer en option à TCP un facteur 2k où k ≤ 14 de multiplication
de la taille du buffer. On aura des buffer (N) de 230 bytes par RTT et le nombre de valeur pour la
numérotions (K) sera de 232 bytes. Ce qui permet de toujours être à l’abri en cas de dépassement de
paquet car le buffer est donc 4x plus petit que le nombre de valeur, on a bien N « K/2 vu qu’ici N =
K/4.

Mécanisme de Naggle
On va essayer de diminuer le nombre de segment envoyé en les groupant, on ne va pas envoyer
dans un segment un byte (ou juste quelque bytes) mais un grand nombre. Mais il ne faut pas non plus
en vouloir en grouper trop, si un byte est urgent on veut qu’il soit envoyé tout de suite et pas qu’il
attende pour être groupé ou qu’il est peut être le dernier byte qu’il n’y a aura plus rien à grouper
avant longtemps.

Pour commencer, on va envoyer la première quantité de byte que donne l’application et ensuite
on récoltes les autres jusqu’à recevoir le premier ACK (donc après avoir attendu un RTT) et on va
envoyer les données qu’on a stocké sur le temps de ce RTT. Cette option est bien entendu désactivable
en signalent à l’ouverture de la connexion TCP NoDelay.

Cependant, si on rajoute ce mécanisme on va avoir "un petit soucis" avec le mécanisme de ACK
retardé chez le receveur. En effet, prenons le cas où on envoie un segment sur deux qui comporte des
données groupés. On va envoyer un segment groupé et qu’il ne reste qu’un envoie à faire de seulement
quelque bytes. Du coups coté receveur on attend pour faire un ACK groupé mais vu que rien arrive

37
on a attendu pour rien et il envoie son ACK, lorsque le ACK arrive le tout dernier petit segment peut
enfin être envoyé. C’est un donc un des cas possible où on a perdu du temps pour rien.
On va donc mettre en place ce qu’on appel une relaxation de Naggle et permettre d’après avoir
envoyé un segment qui est groupé de directement en envoyer un autre segment seul.

Syndrome de la fenêtre folle - Mécanisme de Clark

Ici on va supposer que l’application va lire plusieurs bytes à la fois dans le buffer. Car si l’application
d’un programmeur non averti lis un byte à la fois on pourrait se retrouver dans le cas où l’émetteur
doit envoyer un segment à la fois lorsque le buffer est plein d’où le fait d’appeler ça le syndrome de
la fenêtre folle. Si le buffer est plein, on ne va pas dire dans les premiers ACK qu’il y a de la place,
on informera l’émetteur qu’au moment où le buffer sera à moitié vide ou qu’un segment de donnés
groupé au maximum peut être envoyé.

3.7.7 Etablir la connexion

Avant de s’échanger de l’information, le serveur/client vont faire un "handshake" afin d’établir la
connexion avec des paramètres qu’ils ont établi tel la taille maximale des segments. Des deux côtés
ont va avoir un certain nombre de variables pour connaître l’état,

Figure 3.17 – Etat du client/serveur

— connection state : l’état actuel de la connexion : ESTAB(établie), CLOSED(fermé), SYN

SENT(demande envoyée), LISTEN(attende de demande), SYN RCVD(demande reçue)
— le numéro de séquence de client au serveur
— le numéro de séquence du serveur au client
— la taille du buffer

Etablir la connexion - 2-way handshake

Vu qu’on a un échange aussi de paquet pour ouvrir cette connexion, on aura les même problèmes
qu’avant du au ralentissement sur le réseaux.
Comme on le voit sur la figure, l’acceptation de la connexion par le serveur à trainé et donc le client
en a renvoyé une. Mais le serveur pense qu’il a bien réussi à établir une connexion, ne voyant aucune
requête arrivé il va la fermer. Et recevoir ensuite la redemande de connexion, l’accepter, mais le client
lui aura été fermé car ces deux demandes sont pour une même connexion et non deux différentes. Et
si on envoi en plus de ça des données, le serveur va les traiter plusieurs fois.

38
 Figure 3.18 – Problèmes avec le 2-way handshake

Etablir la connexion - 3-way handshake

Figure 3.19 – 3-way handshake

Au moment où le client demande une ouverture de connexion , il va utiliser un flag "SYNBit"

et va renseigner à partir de quelle numérotation il va numéroter les segments (autrement dit, il va
commencer à numéroter par autre chose que 0). Une fois reçu par le serveur il va utiliser ce flag ainsi
que le flag ACKbit, et va ACK le segment précédemment reçu. En plus de ça le serveur va préciser à
partir de quel nombre il va numéroter ses segments. Et le client va ACK le ACK reçu en utilisant le
flag ACKbit. Et à ce moment, le serveur et le client passent à l’état de connexion établie.

Si on reprends l’exemple du problème avec le 2-way handshake, on remarque que ce n’en est pas
un avec le 3-way. On voit aussi l’importance de ne pas toujours commencer à numéroter à partir de
0. Cela permet aussi d’éviter des attaques faisant uniquement des envoie de données avec une fausse
IP qu’il a réussi à intercepter après un SYN. Car il ne connait pas le y qui a été utilisé, il faudrait en
plus de ça qu’il intercepte le SYNACK.

39
 Si on garde en mémoire les numéros qui on récemment été utilisé, si le système plante alors tout
est fichu. Afin d’éviter de diminuer au maximum les risques, on va choisir le début de numérotation
aléatoirement. Sur 32 bits cela n’est pas gênant. Et en plus de ça on ne peut pas deviner le choix qui
sera fait et donc encore une protection contre des attaques.

Figure 3.20 – Diagramme 3-way handshake

3.7.8 Fermer la connexion

On va fermer la connexion de manière non brutal pour être certain de ne perdre aucune information.
On va aussi avoir une fermeture individuelle. Par exemple le client peut fermer la partie d’envoi du
canal pour l’application qui l’utilise mais il pourra toujours recevoir ce que va lui répondre le serveur.

Figure 3.21 – Fermeture de connexion

40
 Ici le client va demander la fermeture de la connexion, pour cela il envoie un segment (qui continue
d’être numéroté comme avant) avec le flag FINbit. Ensuite le serveur lui répondre un ACK avec le flag
ACKbit (si le ACK est inférieur de plus de 1 au segment de fermeture c’est que des paquets précédent
ont été perdu et donc le client devra lui renvoyer). Après cela le serveur va encore envoyer un segment
mais ici pour signaler que lui aussi ferme sa connexion et donc il utilise le flag FINbit. Enfin le client
va confirmer avec un ACK mais il va rester en attente pendant 2 RTT (2 temps de vie, si 1 RTT = 1
TTL) afin de pouvoir renvoyer un ACK si le serveur lui renvoie sa demande de fermeture en pensant
qu’elle a été perdue alors que c’est le ACK qui s’est perdu.
Un problème pourrait survenir si le FIN du serveur se perd toujours, on pourrait alors mettre
en place au niveau du serveur, après k FIN envoyé, il ferme quoi qu’il arrive son socket mais on
aura toujours un problème coté client qui va attendre alors que le serveur s’est fermé. (cf wikiepdia :
problème des deux armées) On ne peut donc pas avoir de mécanisme de fermeture de connexion
parfaite car il faudrait une chaine sans fin de ACK qui ACK un ACK ! (selon moi on va mettre un
place un timer général des des cotés qui si après longtemps sans n’avoir rien reçu comme signe de vie,
on fermera le socket, un time out).

Il y a un mécanisme qui n’a pas été abordé qui est le heart beat qui est tout les X ms, chacun
envoie un signe de vie à l’autre et si après après k ms sans signe de vie, on déduit qu’il y a un problème
sur le réseau.

Le délais 2 RTT permet aussi d’assurer que éventuellement tout ce qui appartient à l’ancienne
connexion sur le réseau ait été supprimé, ainsi que du coté serveur il se dise que le client a fermé
la connexion et donc après ça il pourra accepté une nouvelle connexion de ce même client, peut
importe les problèmes qui se sont produit avant on peut repartir comme si de rien ne s’était passé
sans ambiguité entre l’ancienne et la nouvelle connexion.

Figure 3.22 – Diagramme fermeture de connexion

3.7.9 Les congestions

Gérer la congestion c’est gérer le nombre de données qu’on envoie sur le canal. Premièrement que
le canal lui même ne déborde pas et que des données sortes de se canal et se perdent. Et deuxièmement
mais ce n’est pas le but recherché, d’éviter que le buffer du receveur déborde

41
 De plus si on a des buffer plus grand que la vitesse à laquelle les données sont traitées et qu’on
arrête pas tant que le buffer n’est pas rempli, on va augmenter les délais que vont attendre les nouveaux
paquets de ce buffer de manière exponentielle. Ainsi que inversement, si la vitesse de traitement est
bien plus grande que le buffer, le buffer sera quasi toujours vide et donc le receveur va parfois attendre
et on va aussi perde du temps. Il faut donc rester dans une zone de fonctionnement où le délais et le
débit sont raisonnable.

On va noter λin les données transmises, λout , λ0in les données transmises et retransmise. On
dira que les deux premiers sont des "goodput" (uniquement ce qui est utile pour l’application) car
λin = λout , et le troisième troughtput. Notons que λ0in ≥ λin

Prenons le cas où l’émetteur a une connaissance parfaite d’un buffer sur le réseau et il sait quand
il peut envoyer ou non des paquets quand le buffer est libre. Et bien dans l’idéal si on a un réseau
avec un débit R, on envoie des données avec ce même débit et donc λin = λout

Prenons le cas où l’émetteur a juste une connaissance des perdes dans le buffer peut être plein,
alors il en renvoie un quand il se perd. Mais donc λ0in > λout et donc coté récepteur on va avoir un
débit inférieur à R. Si on veut de nouveau l’atteindre il faut augmenter celui du coté de l’émetteur.

Maintenant, prenons le cas de la réalité où des paquets sont retransmis inutilement et donc lu 2x
par le récepteur, le débit du coté récepteur sera donc inférieur à R et on ne pourra pas le rattraper
car il a consommé du débit. A nouveau λ0in > λout

On aura donc comme coût du travail supplémentaire dû aux retransmissions afin de vouloir avoir
un maximum de "goodput" mais le fait d’augmenter les retransmissions va comme on l’a vu aussi
diminuer ce "goodput". De plus dans la vraie vie il y a énormément d’émetteur en même temps et
donc plus les λ0in augmentent plus le réseau va se charger et va finir par s’effondrer. Il faut donc réussir
à trouver un débit optimale qui n’est pas trop haut pour éviter l’effondrement, ni trop bas évidement.

Pour TCP le réseau est une boite noire, TCP ne peut pas se baser sur des informations que
pourraient lui fournir le réseau afin d’être informé des congestions. Il va alors utiliser une approche
end-end, il va devoir déterminer à partir de ce qu’il peut analyser tel les délais, le nombre de paquets
supposés perdus etc.

Il existe aussi une méthode network-assisted, par exemple quand les paquets passent dans les
routeurs, si ceux-ci pense qu’il y aura de la congestion, il peuvent basculer un flag du paquet. Et
lorsque TCP va le recevoir il pourra dans ses accusés de réceptions indiquer à l’émetteur qu’il y a de
la congestion. Des variantes de TCP utilises ce mécanisme, ainsi que d’autres protocoles de transport.
Dans des protocoles encore plus poussé le routeur peut même informé du débit à ne pas dépasser
etc. C’est donc plus complexe et TCP a fait le choix de rester simple pour être indépendant des
technologies des routeurs et donc mieux durer dans le temps.

3.7.10 Contrôle de congestion

Donc TCP va essayer d’envoyer avec un débit le plus grand possible sans provoquer de congestion.

Quand il va recevoir un ACK, bonne nouvelle, il va considérer qu’il n’y a pas de congestion et va
augmenter le débit. S’il détecte une possible perte de segment (timer se déclenche) il va diminuer le
débit. Cette technique n’est pas parfaite car un paquet peut être perdu pour d’autre raison qu’une
congestion, par exemple il y a eu une erreur binaire et donc le paquet a été détruit par un routeur.

Mais il faut être plus prudent quand on augmente le débit car on pourrait se trouver à une limite, et
on pourrait être plus agressif quand il faut diminuer le débit afin de rapidement "sortir" des problèmes
des congestions. C’est ce que va faire TCP, il va faiblement augmenter le débit et fortement le diminuer.
Ce mécanisme s’appelle AIMD.

42
 Pour ce faire TCP va se baser sur le fenêtre et il faudra toujours que le dernier segment envoyé
moins le dernier segment ACK soit inférieur à une variable dynamique cwnd qui sera la taille de la
fenêtre. (Bien entendu la valeur de cwnd ne pourra pas être plus grande que celle de rwnd comme
vu précédemment qui est la taille maximale d’une fenêtre) Le débit sera plus ou moins égal à rate ≈
cwnd bytes/sec
RTT
Mais au démarrage, TCP n’a pas encore d’info pour déterminer cmwd, il va donc prendre pour
valeur 1 MSS (maximum segment size) déterminer à l’ouverture de la connexion. Et à chaque fois que
les ACK seront bien reçu donc à chaque RTT, il va doubler la valeur de cwnd. On appellera cette
étape slow start.

TCP Reno
Voyons comment TCP va détecter une congestion par la déduction des paquets perdu par la
variante dite de TCP Reno (la plus classique) :
Si après 3 doublons de ACK reçu, TCP va considérer ça comme une congestion légère car on aurait
perdu qu’un paquet qui doit être fast recovery (renvoyé) et que les précédents sont bien arrivé vu qu’on
reçoit des ACK (note : il faut que la fenêtre soit au moins de taille 4 car pour cette technique car il
faut avoir au moins envoyé 3 paquets + celui qui c’est perdu). Dans ce cas, la fenêtre (définie par la
valeur de cwnd) va être divisée par deux et ensuite la fenêtre va grandir de manière linéaire.
Si le timer ce déclenche, TCP va considérer qu’il y a une congestion sévère car il y a probablement
une grande quantité de paquets qui c’est perdu. La fenêtre va être réinitialisé à 1 MSS et la fenêtre
continuera à grandir de manière exponentielle jusqu’à un certaine valeur où après ça sera linéaire.
L’incrément linaire sera calculer de cette manière : cwndt+1 = cwndt + (MSS/cwndt ) MSS

Figure 3.23 – Diagramme contrôle de congestion et renvoie de paquet perdu - TCP Reno

43
TCP Tahoe
Il y a aussi la variante TCP Tahoe (la plus ancienne) qui dans les deux cas réinitialisera la fenêtre
à 1 MSS. Mais elle n’est plus utilisée car c’est inutilement défensif, ont arrivera jamais à avoir un bon
débit.

On va appeler ssthresh, la valeur à lequel le débit va augmenter linéairement à partir de la. Cette
valeur sera la moitié de celle qui a été atteint avant la congestion. Donc dans le cas de TCP Reno, vu
qu’on divise par deux, le débit augmente directement linéairement et avec Tahoe, ça sera une fois que
ssthresh est dépassé en multipliant par deux le débit vu qu’il est toujours réinitialisé.

3.7.11 Modèle de congestion de TCP

Figure 3.24 – Taille de la fenêtre en fonction du temps

Afin de déterminer si l’algorithme de contrôle de congestion est bon, on va se placer dans le cas
simplifié, c’est à dire dans un régime établi (l’étape slow start terminé) et on va s’intéresser juste au
goodput (pas les retransmissions). On mesure qu’à partir de la valeur W on est en congestion donc on
va diviser par 2 et ce retrouver à W/2, remonté à W après W/2 RTT, rediviser par 2 ainsi de suite.
On a donc un goodput (en MSS/sec) de W/RTT quand on est à W, et (1/2)·W/RTT quand on
est à W/2. Le goodput moyen est donc de 3W/(4 RTT). Ce qui donne 3W/4 · W/2 MSS envoyé par
cycle. Soit 1/p où p est le taux de paquets perdu qui vaut p = 1/(3W2/8 ).
On peut donc aussi calculer la taille de la fenêtre W =p 8/3p. On a donc compris que p pet W
p
√
sont lié. On peut donc réexprimer le goodput moyen avec 3/2 · 1/(RTT p) MSS/sec ou 3/2 ·
√
MSS/(RTT p) bps.

On a donc intérêt à définir de grand segment pour augmenter le débit car plus le RTT sera grand
ainsi que le taux d’erreur plus le débit diminuera.

On voit donc que TCP sera très mauvais sur de longue distance à haut débit. Imaginons une fibre
qui envoie des segments de 1500 bytes (MSS), un RTT de 100 ms ainsi que 10 Gbps de débit. Si on veut
atteindre ce débit avec TCP on devrait avoir une fenêtre W de 83333 segments ! (question examen ? car
(83333 * 1500) / 100 = 1 249 995 byte par ms = 1 249 995 000 Bps = 1,249995 GBps = 9,99996 Gbps
≈ 10 Gbps). Ce qui est énorme et dès lors qu’on va commencer à augmenter linéairement, atteindre
la valeur de W (= la taille de la fenêtre) va prendre énormément de temps voir impossible à cause des
paquets perdu qui divise par 2 à chaque fois. En effet si on veut que ce soit possible d’atteindre un
√
aussi grand W, il faut que le throughput en terme de taux de perte soit de (1.22 MSS)/(RTT p) et
donc un p = 2·10−10 ce qui est impossible, c’est trop peu.

On a donc aujourd’hui de nouvelles versions de TCP conçu pour les hauts débits.

3.7.12 Equité de TCP

Est ce que si on a k connexions TCP sur un même bottleneck (ligne) de débit R, est ce que chaque
connexion aura R/k de débit ? Prenons le cas de 2 connexions, dont la première consomme une plus

44
grande partie de R car cela fait plus longtemps qu’il émet et donc à un moment vu que les deux
augmentes linéairement leur débit, on va dépasser R. A ce moment ils divisent par 2 leur débits et
reprennent, redépassent ainsi de suite. Mais vu qu’on divise par 2 à chaque fois des deux coté, à chaque
fois l’écart entre les deux va diminuer vu que la deuxième connexion partant de moins bas qu’avant
va pouvoir aller plus haut que la fois d’avant. On va donc voir que le débit tend à s’équilibrer entre
les deux.

Figure 3.25 – Partage du débit avec deux connexions avec un même RTT

Ici on a fait l’hypothèse que le RTT est le même. Si ce n’est pas le cas, exemple la première
connexion à un RTT de fois plus petit que celui du deuxième, il ne vont plus augmenter leur débit
de la même manière, sur le temps que la deuxième connexion augmente son MSS de 1, la première
l’aura déjà augment de 2. Au final le débit de la connexion 1 sera deux fois plus grand que celui de la
connexion 2. TCP n’a donc pas une équité parfaite mais proportionnelle au RTT.

Figure 3.26 – Partage du débit avec deux connexions avec un même RTT différent

Mais cette équité peut être contourné par les applications, par exemple si elle ouvre plusieurs
connexion TCP.

3.7.13 Autres mécanismes de contrôle de congestion

— TCP CUBIC qui va affiner les paramètres, il ne va pas commencer par 1 MSS, et pas forcément
divisé par 2.
— TCP BBR qui va essayer d’estimer le débit disponible au bottleneck.
— MPTCP (multipath tcp) utilise par exemple le réseau 4G en même temps que celui filaire pour
augmenter son débit. Le but est de faire passer les paquets par des réseaux différents.
— QUIC développé par Google qui utilise une couche UDP va permettre de contrôler les congestions
et débits à l’aide de ses serveurs et infrastructures qui constitue le chemin des flux de données
de manière plus intelligente que TCP ne peut le faire. Et donc l’écosystème Google pourra être
plus performant.

45
3.8 Equité de UDP
UDP comme on l’a vu n’a pas de mécanisme de gestion et donc il va prendre l’opportunité de
s’imposer sur le débit car TCP va le diminuer le siens afin de réduire la congestion. On dira donc
que UDP n’est pas amicale alors que TCP si. Mais il faut aussi prendre en considération que UDP
n’engendre pas autant de paquets que TCP le fait. Heureusement TCP étant la norme pour tous ce
qui est web etc, on a majoritairement des flux TCP et donc cela ne bloque pas Internet le fait d’utiliser
aussi un peu d’UDP.

46
Chapitre 4

Couche réseau

La couche de réseau est la troisième couche du réseau sur nos ordinateurs et elle est également
cette fois ci présente sur les routeurs en temps que troisièmes couche aussi (la plus haute).
La couche de réseau repose sur deux fonctions, le forwarding (l’acheminement) et le routing (le
routage). Le forwarding c’est choisir la sortie où il faut acheminer un paquet c’est une décision qui
est prise localement au routeur. Tant dis que le routage c’est planifier le trajet, il faut donc une
connaissance globale du réseau et donc cela nécessite des algorithmes de calcul.
On peut faire l’analogie suivante : le routage c’est l’itinéraire que va faire l’avion et le forwarding
c’est trouver dans l’aéroport la porte d’embarquement de notre avion.

4.1 Forwarding et Routing

On dira que le forwarding fait du data plane et le routing du control plane. Et on peut trouver
deux modèles de fonctionnement.
Le premier est que le control plane sera fait par chaque routeur individuellement en local. Une fois
qu’il aura défini les routes, il mettra à jour le data plane qui donnera la sortie à emprunter. C’est la
technique traditionnelle.

Figure 4.1 – Control plane local

Le deuxième est que le control plane est logiquement centralisé par des serveurs. Les routeurs vont
communiqué par un agent de contrôle à contrôleur distant. Qui comme avant une fois son control plane
reçu il mettra à jour le data plane. Ce qui a pour avantage de pouvoir développé des algorithmes de
routage plus intelligent. Cette technique existe depuis 10-15 ans mais n’est pas encore rependu partout.

47
 Figure 4.2 – Control plane distant

4.2 Services réseaux

On aimerait donc savoir maintenant quel service la couche de réseau va offrir à la couche de
transport. Est ce que la couche réseaux va garantir un débit, être sans perte, garantir un ordre
d’arrivé, un timing régulier et un feedback de la congestion ?
Au final on a opté pour Internet le modèle de service "best effort" et donc qu’il ne va rien garantir
et ne va pas donner d’information sur la congestion (on a vu que TCP devait déduire la congestion
en fonction des pertes) mais il va faire de son mieux.

On avait les réseaux ATM qui garantissait en fonction des versions, différentes choses et pouvait
donner un feedback de la congestion, mais c’est arrivé trop tard pour s’imposer comme standard
d’Internet.

4.3 Adressage IPv4

Une adresse IP va être associé à une interface réseau, donc si un routeur est connecté à trois réseaux
(ligne physique), il aura 3 IP. Dans le cas d’un ordinateur il peut aussi avoir plusieurs interface certaine
carte mère ont plusieurs port ethernet par exemple, et il y a aussi l’interface WiFi, donc l’ordinateur
peut lui aussi avoir plusieurs IP.

Les adresses IPv4 sont sur 32 bits, 4x8 bits, qu’on représente souvent en décimal pour que ce soit
lisible ex : 192.168.1.1.

Celle-ci ne sont pas attribués n’importe comment, il se fait en fonction de subnets, tous les appareils
d’un même subnet peuvent communiquer entre eux sans avoir besoin de l’intervention du routeur qui
lui se trouve à l’extrémité de ce subnet. Par exemple un subnet 192.168.1.X où chaque appareil de ce
subnet aura un nombre différent pour le X mais le reste sera identique ce qui se note par 192.168.1.0/24
qui signifie que la plus petite adresse est 192.168.1.0 et le /24 signifie que les 24 bits seront fixes, il
reste donc 8 bits qui peuvent varié qui correspondent à ce qu’il y a après le dernier point.

48
 Figure 4.3 – Subnet

4.3.1 Classe d’adresse

A l’époque une adresse IP va respecter ce qu’on appel une classe d’adresse, il y avait les classes A B
C D E. Donc une adresse IP est codé sur 32 bits et la classe représente où se situera la séparation entre
le préfixe (le subnet = network) et le suffixe (les interfaces = host) de l’adresse. Et donc à l’époque
on pouvait en regardant les premiers bits on pouvait connaître la classe.

Figure 4.4 – Classe d’adresse

Cependant ce n’était pas pratique car après avoir épuisé toutes les adresses du réseau pour la classe
A et B à des universités etc, il ne restait que des petits subnet donné par les classe C qui n’est pas
pratique.

4.3.2 CIDR - Classless InterDomain Routing

Pour palier à ce problème on va utilise la notion de "/" comme on l’a vu. Le préfixe sera défini
par le nombre de bit indiqué après le "/X" ième bit. Ce qui permet donc d’avoir beaucoup plus de
flexibilité de l’adressage IP.

49
4.3.3 Adresse IP spécial
Certaine adresse IP sont réservés à un une utilisation spéciale.
— L’adresse avec des 0 partout, qui est utilisé lorsqu’un système va justement demander une
adresse.
— Avec des 0 au préfixes pour implicitement l’utiliser si on ne le connait pas
— Avec des 255 partout qui est en faite un braodcast sur tout le subnet, on peut communiquer à
toute les adresses du subnet en utilisant cette adresse. Ce qui est utile pour découvrir les hôtes
du subnet.
— Avec des 255 sur le suffixe pour broadcast un préfixe/subnet spécifique.
— Commençant par 127, qui est un loopback, autrement dit les paquets ne sortiront pas du
système. Comme avec 127.0.0.1 (Localhost) qui envoie les paquets sur lui même.

4.4 DHCP - Dynamic Host Configuration Protocol

A l’époque tout les IP était directement attribué par un administrateur système mais cela n’est
pas pratique et cela peut être "dangereux" si deux ont la même ip cela va les bloquer, ou si le subnet
a mal été encodé l’appareil ne sera pas joignable.

On a donc inventé le DHCP qui est un programme qui va s’occuper d’attribuer à une IP à un
appareil lorsque celui-ci va ce connecter au subnet.

DHCP va allouer de manière temporaire une adresse IP, car si un appareil n’est pas constamment
connecté cela ne sert à rien de lui réserver une place alors que peut être il ne reviendra jamais sur ce
réseaux. On a alors un côté dynamique aux adresses.

Pour ce faire DHCP va fonctionner en 4 étapes

1. Optionnelle : DHCP discover, l’hôte broadcast le réseau pour qu’il puisse connaître où ce trouve
le DHCP
2. Optionnelle : DHCP offer, le serveur DHCP répond en broadcast et lui donne une proposition
d’adresse IP et l’hôte peut donc savoir quelle est l’adresse du serveur.
3. DHCP request, l’hôte demande une nouvelle fois en broadcast s’il peut utiliser l’adresse qu’il
lui a été proposé (ou une autre).
4. DHCP ack, le serveur DHCP lui répond aussi en boreadcast pour lui confirmer qu’il peut (ou
pas).
Le fait de toujours communiquer en broadcast est que tout les autres hôtes du subnet puissent
savoir qu’un nouvel hôte est arrivé, et s’il existe plusieurs serveur DHCP les autres vont être informé
que leur proposition a été rejeté pour une autre.

Pour cet échange c’est le protocole UDP qui va être utilisé car pour TCP il faut établir une
connexion entre deux adresses IP et vu que l’hôte n’en a pas ce n’est pas possible et il ne connait
même pas l’adresse IP du serveur DHCP non plus.

Par défaut, le client a comme on l’a vue l’adresse IP avec des 0 partout et utilisera le port 68 pour
faire sa demande, l’adresse broadcast est 255.255.255.255 et par défaut le port d’un serveur DHCP
est 67. Le champs yiaddr est l’adresse proposé. On a aussi le champ lifetime qui permet de négocier
combien de temps on souhaite disposer de cette adresse précise. Et le numéro de transaction pour
identifier de manière unique.
En plus de tout ça, le serveur DHCP va fournir des informations complémentaires au client. Il va
fournir ce qu’on appel le masque, grâce à ce masque on peut déterminer quel est le subnet ex : il lui
donne l’adresse IP 192.168.1.25 et un masque de 255.255.255.0, on en conclut alors que le subnet est
192.168.1.1/24. Il va aussi fournir l’adresse d’un (ou plus) serveur DNS que le client peut utiliser par

50
défaut. Ainsi que l’adresse du routeur responsable du subnet (dans un réseau de maison c’est souvent
le routeur qui est serveur DHCP donc ça sera la même adresse). (Il y a aussi beaucoup d’autres
options)

Il est important de noté que DHCP est une couche applicative, ce n’est pas parce qu’il sert la
couche de réseau qu’il ne sera pas empaqueté par toutes les couches.

Figure 4.5 – DHCP client-serveur

4.5 Comment obtenir un subnet ?

Imaginons qu’une organisation souscrit à un ISP, et bien il va lui vendre un subnet de son subnet
encore disponible. Exemple : il a le subnet 200.23.16.0/20 et bien par exemple il peut vendre à partir
de 200.23.16.0/23, puis 200.23.18.0/23 ... jusque 200.23.30.0/23 après ça elle aura épuisé tout son
subnet.
Mais donc quand on vient d’Internet on sait que tout ce qui vient du subnet 200.23.16.0/20 sera
des ip appartenant à cet ISP.

Imaginons maintenant qu’une organisation souscrit à deux ISP, et bien il est impossible d’avoir
un seul subnet contenu dans les deux subnet de l’ISP on va donc lui attribuer un subnet qui n’a rien
avoir avec celle des ISP, ce subnet est dit PI. Il faut donc que l’ISP informe "Internet" que "tout ce
qui vient de ce subnet malgré qu’il n’a rien avoir avec le miens soit rediriger vers moi quand même".

L’organisation a donc son subnet de la même manière que les ISP ont reçu le leur. C’est l’ICANN
(qui gère aussi les DNS root et TLD) qui va gérer toutes les adresses IP pour les attribuer aux ISP et
aux grosses organisations. Au jour d’aujourd’hui toutes le blocs d’adresses IPv4 on été attribué par
l’ICANN.

4.6 Table de forwarding

Les tables de forwarding vont donc contenir les subnet des ISP, car ça ne sert à rien d’avoir plus,
vu que, toutes les adresses d’un même subnet mène à un même endroit. Après avoir passer cet endroit

51
en question il peut se encore se diviser mais alors c’est à cet endroit que la table sera différente.
Cependant comme on l’a vu, on peut avoir des subnet qui n’ont rien avoir avec le subnet de l’ISP.
Les tables de forward vont donc être avec une précision que pour un tel subnet.
En plus de ça, on pourrait très bien avec un sous subnet d’un ISP qui se trouve chez un ISP d’un
autre car il lui a vendu. Du coups, on va aussi spécifier ce subnet dans la table de routage. Mais la
on va avoir ce qu’on appel un overlap, car en effet ce sous subnet sera donc contenu dans un subnet
mais pourtant il ne vont pas au même endroit et donc dans la table il y a une ambiguïté car ça donne
l’impression d’avoir deux possibilités pour ce (sous) subnet. On va donc établir que on ira toujours en
cas d’ambiguïté vers le subnet le plus précis, autrement dit on enverra vers la sortie su subnet qui a
le plus de correspondance avec l’adresses IP une fois écrit en binaire.
Cela permet aussi d’avoir une sortie par défaut avec des "*" partout qui signifie que s’il n’a
pas trouvé de correspondance il emprunta cette sortie, ça sera toujours la sortie avec le moins de
correspondance vu que son subnet est de taille 0.

Figure 4.6 – Longest prefix matching - table de forwarding

Tout cela faisait donc quand même beaucoup d’entrée dans la table de forwarding et donc au
début vu que c’était fait en software les performances était assez faible. Depuis on utilise du hardware
spécifique des TCAM (Ternary Content Addressable Memories) qui sont de la mémoire qui s’adresse
à partir du contenu et pas par l’adresse comme dans une mémoire traditionnelle. Ce qui permet en
un tour d’horloge au CPU de comparer l’adresse IP à toute les entrées de la table. Il reste donc après
à choisir celle avec le plus long préfix matching dans celle avec une correspondance. Cependant, il est
quand même possible avec des tries (cf projet de ldp) de faire quelque chose d’efficace en software.

4.7 NAT - Network Adress Translation

Cependant, jusqu’à maintenant on a considéré que une machine avait une adresse IP mais comme
on l’a vu, il n’y a pas tant que ça d’adresse IPv4 disponible et donc si on devait en donner une
différente à chaque appareil surtout aujourd’hui ça serait la catastrophe. C’est pour cela que la NAT
a été créé.
On va créer un réseau dit local qui aura sont propre subnet d’adresses IPv4 et cela permettra de
ne donner qu’une seule "vrai" IP à un routeur qui va gérer ce réseau local. Exemple, dans une maison
on a une adresse IP externe qui est donné par notre fournisseur internet au modem/routeur et ensuite
ce routeur va attribuer (via le DHCP) des IP dite locale à chaque appareil qui vient se connecter
à lui. Pour cela sur internet il y existe trois subnet d’adresses privées 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16 qui vont pouvoir être utilisé (notons que le routeur aura aussi une adresse privé car il
aura 2 interfaces une vers le réseau locale dit LAN et une vers le réseau externe dit WAN).
Donc ces subnets ne seront pas dans les table de forwarding publique, par contre on trouvera dans
toute les maisons un même subnet avec de même IP. Mais ce n’est pas grave car à l’extérieur de ce
réseau ces adresses IP n’existes pas.

52
 On gagne donc aussi en facilité, on peut changer de fournisseur internet très simplement et une
entreprise/maison pourra gérer de la manière dont elle souhaite ses adresses IP locale aussi, mais
surtout on va gagner en sécurité car les appareils ne seront plus directement atteignable par l’extérieur
le routeur pourra faire office de garde du corps.

Par contre maintenant, il faut un mécanisme pour savoir vers quelle adresse IP locale, l’IP externe
demande à échanger des paquets. Le routeur aura donc une table qui va apparier pour chaque l’adresse
WAN avec lequel on communique (en général toujours la même mais on pourrait avoir plusieurs
fournisseur Internet) à l’adresse LAN qui envoie des paquets. Afin de permettre à plusieurs adresse
LAN d’échanger avec une même adresse WAN, le routeur va artificiellement changer le numéro de
port source, et donc au moment ou un paquet revient en réponse sur ce port source, il sait à qui il l’a
attribuer.

Figure 4.7 – Table NAT

Cependant, on peut avoir un problème de sécurité avec cette table dite "full cône" car n’importe
quelle adresse IP WAN peut répondre, on peut donc rajouter un champ du coté "WAN side addr" en
y mettant l’adresse IP à qui on a envoyé le paquet.

Mais étant donné que les ports sont codés sur 16 bits soit un maximum de 65536 appareils pouvant
faire une même requête.

Le NAT porte aussi à controverse car il modifie le port alors que le routeur n’est pas sensé pouvoir
le faire vu qu’il n’a pas de couche de transport. Et donc il viole l’intégrité mis en place par les couches.
Et si l’application demande que la couche de transport soit chiffré et bien ça ne marche plus car
le routeur ne comprends pas ce qu’il doit modifier. Et imaginons le serveur veut absolument que le
port source soit un précisément, cela pose problème si le routeur le change. De plus, pourquoi on
ne déploie pas l’IPv6 vu qu’il résout les problèmes de pénurie ? (business is buinsess, des solutions
NAT performantes se vendent cher et donc on utilisera ce bricolage jusqu’à la moelle, on changera
uniquement lorsque ça ne sera plus envisageable)

Un problème de plus avec le NAT c’est que depuis l’extérieur on ne peut pas communiquer vers
l’intérieur. Il faut donc mettre en place une redirection dans le routeur pour un port X venant des IP
externes il redirige vers tel IP locale. Mais du coups une redirection ne peut se faire que pour un seul
appareil c’est donc une solution statique pas très pratique.

53
 On a donc mis une place des protocoles dynamiques : UPnP (Universal Plug and Play) ou IGD
(Internet Geteway Device) pour que le client LAN puisse configurer de manière autonome le routeur
en lui disant "attention à partir de maintenant on va peut être me contacter sur le port X" et ensuite
lui dire "ok je n’ai plus besoin du port X".
Un autre problème pourrait être si un client du réseau local fait de l’illégal, l’ISP va black lister
l’ip WAN et donc les autres client du LAN seront aussi bloquer alors qu’ils n’ont rien fait et ne sont
peut être même pas au courant, typiquement sur des réseaux publiques.

Encore un autre problème est avec le pear to pear comme on l’a vu dans le premier chapitre, à
cause du NAT ce n’est pas possible d’en faire directement, il faut passer par des serveurs qui centralise
le P2P pour un service donné. Par exemple Skype qui fonctionne avec, lorsqu’un client se met en ligne
il doit informer un serveur et si un autre client veut communiquer avec lui, il doit passer par le serveur
car seul ce serveur peut passer dans l’autre sens la table NAT (qui pourrait pour une question de
sécurité comme on l’a vu autoriser la réponse uniquement de l’adresse WAN à qui on a envoyé un
paquet).

Le NAT est donc une bonne solution mais a imposé beaucoup de restriction et de complication.

4.8 Datagram IPv4

Figure 4.8 – Datagram IPv4

Le paquet IP est un conteneur générique qui permet d’avoir dans la charge utile "data" ce qu’on
veut. (même des paquets IP imbriqués)
"type of service", est un champ qui permet de déterminer la priorité d’un paquet. Car comme on
l’a vu, Internet utilise le système de "best effort" et donc n’est pas toujours adapté à des paquets
utilisé dans des services urgents.
On a aussi la présence d’un checksum qui porte uniquement sur le header car les protocoles TCP,
UDP, etc font déjà le leur.

54
4.9 Fragmentation
Quand on découpe des données en fragments, comment peut on les reconstruites ?

4.9.1 MTU
Le MTU c’est la taille maximale d’un paquet IP, qui peut transiter sur le réseau. Et le paquet IP
devant être autoportant, on doit dupliquer l’entête dans chaque fragment.

Cependant, une fois qu’un paquet a été découpé par un routeur, il ne sera que rassembler par
l’interface du destinataire (l’ordinateur pas le routeur). Le paquet sera reformer à l’identique de
comment il était à l’envoie. Le paquet doit être donné en entier à la couche de transport (TCP ou
UDP) car elle n’a pas conscience de cette fragmentation provoqué par la couche de réseau.
Si on ne rassemble pas dans les routeurs, c’est pour peut être éviter un travail inutile. Cela ne sert
à rien de rassembler si dans un routeur plus loin il va refragmenter. On aura perdu du temps du fait
qu’il faut tous les attendre et en plus ça utilise des ressources de calcul et un buffeur du fait que les
fragments doivent attendre. Qui plus est, peut être risqué de tout devoir jeter car le TTL (rappel :
temps de vie du paquet avant d’être déclaré comme perdu par la source) sera arrivé à expiration.

4.9.2 Fragment

Figure 4.9 – Fragmenter un paquet IP

L’entête va donc être modifié sur 3 paramètres : lenght (nbr de bytes), fragflag(1 pour dire qu’il y a
encore d’autre fragment après lui), offset (à partir d’où il commence ; voir plus loin pour explication),
afin de comprendre quel fragment c’est. Un paquet qui n’est pas fragmenté sera toujours avec un
fragflag et un offset de 0 et 0.

On a choisit d’utiliser un offset à la place d’une numérotation. Car si on veut diviser un fragment
cela pose problème. L’offset n’a pour unité le byte mais 8 bytes. Car on considère qu’on fragmentera
pas plus petit qu’un paquet de 8 bytes. Du coups, dans cette exemple le deuxième fragment on fait
185*8 = 1480 bytes, on comprend donc aussi que le header fait 20 bytes vu qu’on signale une longueur
de 1500.

55
 Il faut aussi faire attention quant on fragmente un fragment de laisser le fragflag à 1 si il l’est déjà
même pour le dernier sous fragment car ce n’est pas le "vrai" dernier fragment. C’est uniquement vrai
dans le cas du dernier sous fragment d’un fragment qui a le fragflag à 0.

4.9.3 Éviter la fragmentation

Il faudrait envoyer des paquets plus petit que le plus petit MTU du chemin qui sera emprunter.
On pourrait le faire par une découverte par essais erreur sur le chemin pour connaître sa limite.
En effet, on pourrait aussi mettre un flag signalement de ne pas fragmenter. Et si ce paquet se
retrouver sur un routeur qui est obliger de le fragmenter il va le détruire et informer la source de son
MTU pour qu’il le modifie. Ce message d’erreur est appelé ICMP.

Cependant, on a aucune garantie que le routeur envoie un ICMP, il pourrait le jeter sans rien dire
car en soit quelqu’un qui veut imposer ses règles sur le réseau ne suit pas un code de conduite fair
play qui est le partage égale du réseau pour tous. De plus ce ICMP peut se perdre sur le réseau dans
un congestion et ne jamais arriver.

De plus même si le ICMP arrive, la route peut changer après ça car les tables de routages ont
changée entre temps. Ce qui oblige a recommencer la découverte.

La raison par laquelle on aimerait empêcher la fragmentation c’est que le routeur de la destination
ne passe pas son temps à attendre car elle ne peut pas comprendre un paquet TCP ou UDP s’il n’est
pas complet (du moins son entête). Mais cela c’est à cause du NAT et du parefeu qui viole l’intégrité
de la couche IP pour aller directement voir l’entête du protocole TCP ou UDP afin de connaître l’IP
et le port.

4.10 IPv6
D’abord pourquoi 6 et pas 5 ? IPv5 a exister mais est "mort né" car il voulait modifier trop de
chose dans le paquet switching du réseau en essayant de grouper les flux. Et IPv6 va garder le principe
de IPv4 sur ce point ci. Il y a eu aussi beaucoup d’autre version (j’ai trouvé sur internet au moins
jusqu’à l’IPv16, digression : j’ai lu que la chine pense à utiliser l’IPv9 pour palier au manque d’adresse
IPv4 dû à sa population et pour ne pas être sous l’emprise de l’ICANN (USA)) mais n’ont pas été
sélectionner pour être appliquer à Internet. En effet, IPv6 a été conçu dans les années 80 ! C’est donc
dire le temps qu’il faut pour changer les choses alors que à l’heure d’aujourd’hui IPv6 n’est même pas
encore déployé partout.

La motivation initiale est d’agrandir l’entête de l’adresse IP. Et en même temps rajouter dans
l’entête des choses qui peuvent améliorer la qualité du service et le processing/forwarding des paquets.
Et surtout ne pas modifier les autres couches.

Son datagram prendra comme taille de l’entête une longueur de 40 bytes et n’autorisera plus la
fragmentation par les routeurs.

4.10.1 Datagram IPv6

On remarque qu’il n’y a plus la présence des champs destiné à la fragmentation.
"payload len" : qui est la longueur de la charge utile et plus la longueur totale, vu que le header
est fixé à 40 bytes et non libre comme dans IPv4 (champ options).
"next hdr" : permet de dire quel est le protocole de transport utilisé (en faite le protocole utilisé
dans sa section data qui n’est pas forcément la couche de transport, car la data peut être chiffré par
un protocole on aura donc le nom du protocole de chiffrage et dans la couche de chiffrage le "next
hdr" sera celui du protocole de transport).

56
 Figure 4.10 – Datagram IPv6

"hop limit" : anciennement appelé time to live

"pri" : anciennement appelé type of service, défini une priorité.
"flow label" : permet de déterminer à quel flux il appartient afin d’optimiser l’acheminement sur
base du trio "source address", "destination address", "flow label". Vu que c’est la source qui va
déterminer le "flow label" elle pourra sans ambiguïté passer les routeurs qui ne devront plus aller
regarder les entêtes tcp et au final n’avoir aucune certitude. C’est donc une possibilité de plus value
pour la qualité du réseau mais pas une obligation du changement fondamentale du flow control.
Le checksum a été supprimé, car la couche physique qui est celle du dessus utilise une technique
beaucoup plus poussée et donc inutile de continuer à faire des checksums ailleurs.
Étant donné la taille fixe, il n’y a plus de champ option mais celle-ci peuvent être implémenter par
le champ "next hdr" car comme on l’a vu avec le chiffrement on peut créer des couches intermédiaire.

4.10.2 Représentation
On l’a déjà dit, l’IPv6 ne sera plus représenter sous forme décimale mais hexadecimal qui permet
de simplifier la lecture entre binaire et hexadécimale.
De plus, les "." seront remplacé par des ":" et quand une partie de l’adresse est composé de 0
successif on peut la compacter en écrivant "::". Exemple : FF01:0:0:0:0:0:0:1 peut s’écrire FF01::1.
Mais FF01:0:0:1:0:0:0:1 ne peut pas s’écrire FF01::1::1 car on ne sait pas savoir comment sont répartis
les zéros. 0:0:0:0:0:0:0:1 (loop back) peut s’écrire ::1 et 0:0:0:0:0:0:0:0 (this host) peut s’écrire ::

4.10.3 Hiérarchie et DHCP

Comme pour IPv4 on peut distinguer une partie network et une partie host, en général on divise
en deux part égale. Du coups, on va passer à la version DHCPv6 pour attribuer les adresses d’hosts
mais on peut très bien se passer de ça. Comme on le verra dans le chapitre suivant chaque interface à
une interface physique (mac) unique au monde sur 48 bits, on peut donc attribuer comme IP d’host
celle du mac ou alors une méthode pseudo aléatoire car la chance est infime de produire deux fois la
même IP sur 64 bits.

L’envie de se détacher de DHCP est dû au fait que cela prend des ressources machines. Cependant,
si on garde la même IP que le mac, cela pose un problème de vie privée car on pourrait nous tracer
ainsi qu’un problème de sécurité car vu qu’elle est propre à un constructeur on pourrait viser une
faille de tel constructeur. Le random permet donc d’éviter cela mais rend la gestion du réseau par un
administrateur compliqué. Par défaut l’aléatoire sera utilisé mais dans le cas des entreprises (ou dans
la maison d’un informaticien curieux) on gardera DHCPv6.

57
4.10.4 Adresse locale
On a aussi créer une adresse non routable, uniquement sur le liens physique actuel (le câble ou
l’onde wifi) qui commencera par FE80:0:0:0 et ensuite les 48 bits du mac, qui permettront de signaler
au routeur/DHCP qu’on a besoin d’un IP.

4.11 Transition IPv4 vers IPv6

Cependant, la transition n’est toujours pas terminée et elle est compliquée car utiliser l’IPv6
implique que de bout en bout ce soit IPv6 qui est utilisé et donc si le serveur ne supporte pas IPv6
mais l’ordinateur oui, et bien on est obliger d’utiliser IPv4, idem si des routeurs du chemin n’est pas
IPv6. Ou bien si le routeur de la maison est vieux et n’a pas ce protocole ou encore si la personne
décide de désactiver IPv6. Et en plus de ça il faut encore que l’opérateur du réseau donne des adresses
IPv6, ce qui est à l’heure d’aujourd’hui peu le cas. Depuis plus de 20 ans, IPv6 a été standardisé
comme le futur protocole d’Internet ... En 2018 Google a recensé uniquement 20% de ses utilisateurs
qui utilise l’IPv6. En effet, Google Amazon etc, on le 06/06/12 (lol 6/6, v6) on décidé d’ouvrir leurs
serveur en IPv6. En 2018 la Belgique était le leader mondiale avec 57% de ses adresses IP en v6. Il a
donc eu plein du contrainte qui nous force encore aujourd’hui à devoir utiliser les deux car il existe
trop d’appareil encore incompatible IPv6 pour désactiver IPv4 du jour au lendemain comme il avait
été fait en 1983 avec TCP.

La solution est donc de mettre dans un paquet IPv6 un paquet IPv4 comme on a vu que c’est
possible de mettre autre chose que du TCP/UDP dans la section Data ou même inversement ! Ce
n’est pas parce qu’il n’y a pas le champs next hdr dans IPv4 que ce n’est pas possible. On appel cela
le tunneling.

4.11.1 Tunneling

Figure 4.11 – Tunneling

58
4.12 Routeur
On peut représenter un routeur sous cette vue théorique :

Figure 4.12 – Routeur - vue à haut niveau

Si on zoom sur une porte d’entrée on peut voir ce-ci

Figure 4.13 – Porte d’entrée - vue à haut niveau

— "physical layer" : couche physique ; il aura pour fonction de reformer l’onde : les photons en du
numérique, un bloque binaire.
— "link layer protocole" : couche de liens ; il va regarder l’entête de la couche physique et voir si
il n’y a pas eu d’erreur.
— "lookup, forwarding" : on est donc au niveau de la couche de réseau, on va mettre les paquets
ip en attente dans un buffer jusqu’à être forward par la table vers la bonne interface.

Maintenant allons voir du coté du "switch fabric" qui va s’occuper de transférer les paquets du
buffer d’input vers le bon buffer d’output. Le "switching rate" représentera la vitesse à laquelle cette
opérations peut se faire ou plutôt quelle quantité de paquets. Il existe alors 3 types de switching
fabrics.

59
 Figure 4.14 – Type de switching fabrics

Le premier mécanisme n’est pas très efficace état donné qu’il faut passer par une mémoire intermédiaire
qui est plus lente et si on a beaucoup d’interface elle peut être remplie et devenir un bottleneck. C’est
à l’origine le premier mécanisme inventé. La deuxième est mieux car les paquets transite sur un bus
qui est donc très rapide mais on ne peut transiter qu’un seul paquet à la fois sur un bus et donc c’est
peut être pas encore assez rapide si il y a beaucoup de paquets et donc il deviendrait un bottleneck.
Et enfin le crossbar on va mettre de multiple bus pour éviter qu’il soit un bottleneck, le paquet va
itinéraire sur les différents noeud qui vont l’aiguiller et on peut donc faire transiter plusieurs paquet
à la fois ; on parle alors de parallélisme, qui permet de potentiellement transiter N paquets à la fois si
il y a N entrées.

Mais dans tout les cas si sur sur deux entrées on a deux paquets qui veulent la même sortie, l’un
va devoir attendre et donc bloquer ce qui est derrière lui provoquant une queue. On appel cela du
HOL (head of the line) blocking. Si on veut éviter ça, il faut ordonnancer les paquets dans les queues.

Zoomons maintenant sur la porte de sortie, la switch frabric étant extrêmement efficace (capable
de gérer 100% du nombre de paquets possible pouvant rentrer dans le routeur) c’est en général la
sortie qui va poser soucis. Il faut donc impérativement mettre en place sur son buffur différentes files
à différentes priorités afin de ne perdre qu’un minimum de paquets peut important. C’est aussi dans
ce buffur que devra être fait l’étape de fragmentation.

Figure 4.15 – Porte de sortie - vue à haut niveau

60
Chapitre 5

Plan de contrôle de la couche de réseau

Pour rappel, précédemment nous avons vu le data plane c’est le mécanisme de forwarding qui
consiste à orienter vers la bonne sortie les paquets entrant du routeur. Ici nous verrons le control
plane c’est le mécanisme de routing qui consiste à déterminer quelle route va emprunter le paquet
pour atteindre sa destination

Pour ce faire nous avons vu qu’il existe deux approche, une locale ou routeur et une centralisé par
des serveurs. Ici nous aborderons uniquement la première qui est la traditionnelle (figure 4.1).

5.1 Internet Control Message Protocol - ICMP

On ne a aussi déjà parler des ICMP, ce sont les messages envoyés par les routeurs à l’émetteur
lorsqu’il y eu un problème avec son paquet. Ce message d’erreur consiste en deux entier qui forme une
pair, de manière à identifier un problème ainsi que les 8 premiers byte de ce paquet.

Le paquet ICMP est bien sûr lui aussi en capsuler dans un paquet IP. C’est aussi grâce à lui qu’on
peut profiter de la commande ping.

Figure 5.1 – Table des erreurs

La commande traceroute va fonctionner grâce à ça aussi, elle va envoyer des paquets avec successivement
un TTL de 1,2,3 ... sur un port improbable, de sorte que une fois qu’elle a atteint sa destination elle
va recevoir un ICMP 3,3 qui signifie que le port n’est pas ouvert.

61
5.2 Graphe abstrait du réseau
On peut représenter le réseau comme un graphe pondéré avec comme noeuds les routeurs, comme
arêtes les lignes de câbles qui relie ces routeurs et sur ces liens un coût qui va permettre de déterminer
le plus court chemin. Ce choix du coût par liens va être crucial pour l’efficacité du réseau, si on met
un poids de 1 partout, on prendra toujours le chemin composé du plus petit nombre de routeur. Ou
attribué l’inverse de la bande passante, plus le liens aura de faible débit plus le poids sera grand et
donc moins de paquet l’emprunterons pour éviter de la congestion sur les petits liens.

5.2.1 Déterminer le coût

C’est donc un problème d’optimisation, où on va recevoir une matrice de trafic et à partir de
celle-ci on va déterminer les poids des liens. Cependant, dans la vraie vie on ne fait pas comme ça
étant donné que le trafic varie tout le temps. On veut donc avoir des poids statiques qui ne dépendent
pas du trafic.

Une première manière serait d’attribuer un poids de 1 à tout les liens ce qui minimisera la charge
moyennePdes liens peut importe le trafic. Disons que l’ont veut minimiser un score = chaque moy des
charge i
liens = i∈liensN où i = 0...N est l’identifiant d’un liens.
Si on veut rajouter un flux d’un débit R sur un chemin P, le score va augmenter de i∈P R =
P
R × nbr noeuds(P). Et si on veut minimiser cette augmentation R étant une constante, il faut utiliser
un minimum de noeuds et cela ce fait automatiquement si le poids de chaque liens entre les noeuds
est de 1.

Si ce que l’on cherche est de minimiser la charge sur les liens alors le score = util moy des liens =
util i charge i / capacité i
P P
i∈liens
N
= i∈liens N
Ensuite on veut rajouter un flux de débit R sur un chemin P le score va augmenter de i∈P capacitéR
P
i=
R × i∈P capacité i . Afin de le minimiser il faut minimiser 1/capacité du liens i. Rien de plus simple
1
P

que d’assigner pour chaque liens l’inverse de sa capacité. La charge va donc plus se répartir sur les
lignes à haut débits.

Mais quand est-il du facteur de délais ? Le délais dépends comme on l’a vu du temps de propagation
et de transmission ainsi que du temps dans les queues des routeurs qui vont grosso modo dépendre de
la charge.

On a donc deux manières de calculer les routes et ce sera à l’opérateur du réseau de faire ce choix.
On aura donc en fonction des routeurs des choix différents sur la manière de calculer les tables.

Ainsi pour calculer les plus cours chemin d’un routeur vers tout les autres, il effectueras un
algorithme du plus cours chemin sur un graphe pondéré ce qui donnera un arbre propre au routeur
où il n’existe qu’un chemin pour se rendre de ce routeur vers un autre.

5.3 Algorithme de routage intra-domaine

On vient de voir deux méthodes pour définir les plus cours chemin via leur coût. Cependant, jusqu’à
maintenant on a supposé qu’un routeur connait toute la topologie du réseau, on appelé ces algorithme
global ou "link state". Il existe cependant des algorithmes qui n’ont pas besoin de connaître toute la
topologie du moins pas directement, ils vont à chaque fois entre routeur s’échanger les poids de ses
lignes voisines jusqu’à tout le monde connaissent tout monde, ils sont dit décentralisé ou "distance
vector" qui était la technique utilisé à l’origine d’Internet.

62
 La deuxième question qui se pose c’est mettons les poids des chemins à jour souvent ou non ? On a
remarqué au cours du temps que le fait de trop changer les poids complique les choses provocant des
problèmes et le mieux est de ne mettre à jour les poids qu’en cas de problème critique tel les pannes.

5.3.1 Algorithme "link state"

C’est la norme recommandé sur Internet, il va fonctionner en deux phases, la première qui est
la découverte de la topologie du graphe (réseau) via broadcasting. Ensuite on passe dans la phase
de calcul du moindre coups. Chaque noeud va calculer les plus cours chemin vers chaque noeud (via
l’algorithme de Dijstra). Et cela donne la table de forwarding.
Pour construire le graphes, chaque voisins va donner à son voisins sa tables des noeuds voisins avec
le poids du liens et donc au final chacun aura l’entièreté du graphes.

Figure 5.2 – Construction du graphes

Pour le partage, il va y avoir un mécanisme d’inondation contrôlée, en effet, s’il n’était pas contrôlé,
dès qu’une la table d’un noeud est mis à jour, elle serait envoyé à tous ses voisins et donc au final il
y aura des duplications si il y a des voisins en commun etc.
Donc on va mettre un numéro de séquences sur les paquets contenant une partie du graphe.
Lorsqu’un un paquet est reçu d’un autre noeud, il sera ack et envoyé à ses voisins et va retenir qu’il
l’a fait via des flags. Si ce paquet en questions revient par un autre voisins il sera détruit. On va en
plus de ça rajouter un champ âge (timer), qui à chaque fois qu’il reçoit un paquet du noeud source
non antérieur à l’actuel, il va reset le timer et si ce timer tombe à 0, c’est que à priori le noeud est
"mort". Et qu’il va peut être redémarrer et donc envoyer avec une nouvelle numérotation de séquence.
La ligne correspondante sera donc supprimée pour éviter ce soucis.
Cependant, les actions de ACK à la source et de send aux voisins ne seront pas fait immédiatement.
(mais pour quelle raison ? c’est pas expliqué. Peut être au cas où qu’un paquet plus "récent" arrive et
donc éviter de propager pour rien).

Figure 5.3 – Distribution des paquets pour la construction du graphes

63
 Ici on a fait l’hypothèse que le poids des liens est statique, s’il est par exemple dépendant du trafic
cela peut provoquer beaucoup d’oscillation sur le trafic futur (en plus du fait qu’il faut à chaque fois
refaire l’algo de Dijkstra en n log n), en effet le trafic sera toujours surchargé d’un coté puis de l’autre
etc. Exemple :

Figure 5.4 – Osciallations du trafic à cause de poids dynamique

Cette pour cette raison que comme on l’a dit on préfère utiliser des poids statiques où la matrice
de trafic ne varie pas.

5.3.2 Algorithme "Open Shortest Path First" - OSPF

Il utilise tout les principes du link state, et son communiqué dans des paquets IP. Afin de contrôler
encore plus le mécanisme d’inondation pour éviter l’inondation du réseau justement, on va désigner un
routeur qui se chargera de gérer les échanges. Il va aussi ajouter un mécanisme d’authentification pour
éviter les faux paquets. Il peut aussi exister plusieurs chemin de même coups, au lieu de supprimer
un aléatoirement on peut garder chaque possibilité pour par exemple équilibrer la charge en envoyant
une fois sur l’un, une fois sur l’autre. On peut aussi garder plusieurs métriques de poids sur les liens,
on est pas obligé d’un choisir une. Et donc en fonction du type de paquet, choisir un chemin soit
avec moins de noeuds, soit avec moins de délais, soit peu charger etc. Il possède aussi la notion de
hiérarchie :

Figure 5.5 – Hiérarchie d’un réseau

Si une zone (area) est coupé du reste du graphe par un seul noeuds, alors le coeur du réseau
(backbone) fera son mécanisme de découverte du réseau uniquement avec le routeur qui fait la liaison.
Et en interne au area, il y aura aussi une découverte du réseau. Grâce à ça la table de forwarding sera
moins grande et il y aura moins de trafic engendré par la découverte du réseau.

64
 OSPF est donc un algorithme "link state" avec beaucoup de flexibilité.

5.3.3 Algorithme "distance vector"

L’algorithme prends une approche de programmation dynamique en se basant sur l’équation de
Bellman-Ford : dx (y) = minv {c(x, v) + dv (y)} où dx (y) et le plus faible coût pour aller de x à y. minv
c’est prendre le minimum sur les voisins v de x. c(x, v) est le coups pour aller jusqu’au voisin v et
dv (y) qui est le coups pour aller de v à y. Exemple :

Figure 5.6 – Bellman-Ford

Notons maintenant Dx (y) l’estimation du plus faible coups pour aller de x à y. Et Dx = [Dx (y) :
y ∈ N ] qui est le vecteur des estimations pour aller de x à chaque noeuds.
Ce vecteur Dx va être échangé avec les voisins. La différence avec le link state est que le LS
échange une connaissance des distances avec ses voisins, tant dis que le distance vector échange une
connaissance (approximative) de tout le réseau.
Donc dans chaque noeuds x, on aura le coût pour aller jusqu’au voisin qui est c(x, v) et le vecteur
d’estimations des distances de ses voisins aussi Dv = [Dv (y) : y ∈ N ].

L’idée de l’algorithme est de temps en temps diffuser à ses voisins (juste à eux, pas d’inondation
comme avec link state). Et au moment où le noeud x reçoit le vecteur d’un voisin, il va mettre à
jour le siens : Dx (yi ) = minx {c(x, v) + Dv (yi )}. Si on itère se processus, on ce rends compte que les
estimations converge (uniquement si les liens ont des coups positif)
Maintenant, définissons "temps en temps" : un noeud va attendre un événement, lorsque le coups
d’un liens à changé, il va suite à cela recalculer ses estimations et si au moins une composantes à
changé, il va partager son vecteur à ses voisins. Voici un exemple en figure 5.7.

Ensuite imaginons une bonne nouvelle (toujours avec le graphe de la figure 5.7), le poids du liens
entre x et y devient 1. y va recalculer et informer dans son vecteur que maintenant Dy (x) = 2) donc
z met à jour sa matrice pour Dz (x). X aura lui aussi recalculer et va en informer z que Dx (y) = 1),
mais z ne change rien car son ancienne valeur Dz (y) est toujours plus petite. Donc on remarque que
dans le cas d’une bonne nouvelle, les valeurs des tables converges très vite.

Mais dans le cas d’une mauvaise nouvelle, exemple z plante donc le liens entre x et z devient
infini. Alors x recalcule sa matrice et décide de passer par y pensant que c’est possible, le poids Dx (z)
augmente alors. Ensuite il communique son vecteur des distance à y qui lui aussi à son liens vers z
qui passe à l’infini, il va donc mettre à jour son vecteur pour passer par x ! Et Dy (z) augmente aussi
vu que Dx (z) a augmenter. Mais vu qu’aucun des deux ne connais la topologie, juste le poids des
distances et vu que x ne sait pas que y passe par lui, ni y ne sait que x passe par lui, c’est un dialogue
de sourd. Ensuite y ré-informe x, qui remet à jour vu que le coût a aussi changé pour aller de x à y,
renvoie son vecteur, y remet à jour et ce cycle continue indéfiniment les valeurs des distances vers z
augmentant jusqu’à l’infini elle aussi.

65
 Figure 5.7 – Initalisation de l’estimations des tables

Un autre cas de mauvaise nouvelle, le liens entre x et y passe à 60. On aura le même problème que
ci dessus, sauf que on aura pas un nombre infini d’échange car Dy (x) = 2, 4, 6, 8 et Dz (x) = 3, 5, 7 car
à un moment z va se rendre compte qu’il est mieux qu’il passe par son liens direct que par y ce qui
met fin à la boucle.

Pour palier à ce problème, on a inventé le "poisoned reverse" qui consiste à mentir lors d’une
mauvaise nouvelle. Prenons le cas où x plante, y informe z que sa distance à changé, et z au lieu de
lui informer de sa vraie nouvelle valeur (qui est de passer par y) pour aller vers x, il va lui dire que sa
distance est infinie. Donc y est coincé, entre l’infini du liens direct vers x et l’infini du liens vers z, il
en déduit alors que x est inatteignable et informe z que Dy (x) = ∞ et donc z va lui aussi être coincé
entre infini et infini pour déduire que x est inatteignable et le cycle infini est donc terminé.
Cela marche de la même manière si le liens entre x et y change de poids vers 60. y recalcule les
poids, informe z mais z va mentir en retour et y ne va plus passer par z qui va lui dire que Dz (y) = ∞
mais emprunter le liens à 60 et réinformer z. Cette fois-ci z décide donc de passer par son lien direct
vu que 7 c’est mieux que 61 et le dire à y qui à son tour choisira de passer par z et cela met fin aux
échange.

Cependant, cela ne fonctionne pas toujours, si on rajoute un routeur w et un liens w-y. Si w vient
à tomber en panne, z va mentir à y mais pas à x, et x lui va dire la vérité à tous et donc le mensonge
de z à y va être ignoré. Et un cycle infinie se recrée.

Le seul moyen de contrer cet ultime problème est de mettre une limite au nombre d’itérations. Ce
protocole à l’origine a été créé par ApraNet. Mais il est toujours utilisé dans des petits réseaux étant
donné que son implémentation est plus simple que le link state.

5.3.4 Algorithme "Routing Information Protocol" - RIP

RIP reprend les principes du distance vector qui a été introduit en 1982 dans Unix. La métrique
sur les liens qu’il utilise sont toujours unitaire (des 1) et 0 représentera l’infini.

66
 Mais il faut préciser que jusqu’ici on a établi (même lors du link state) que ce sont des IP que l’on
veut atteindre directement, or que dans la réalité ce sont des subnets que l’on veut atteindre qui eux
contienne l’IP. Et donc RIP va avoir dans sa table de routage les subnets attaché aux routeurs de ses
voisins et les siens au lieu du routeur directement. Et vu que la métrique est des 1, la table contiendra
le nombre de "hops" (de routeurs composant le chemin), ainsi que le routeur suivant du chemin. On
aura donc une table et plus une matrice comme avec la figure 5.7.
Le protocole ne prends en charge qu’au maximum 15 hops. Cependant, RIP ne va pas directement
implémenter le mécanisme de mensonge, mais plutôt quand un routeur va recevoir la table du voisin,
il va ignorer la ligne dont il est le routeur suivant. Ce n’est donc pas le même raisonnement, mais le
même concept. Exemple :

Figure 5.8 – RIP : Calcul de la table du noeud D

5.3.5 Comparaison entre LS et DV

Complexité des messages :
LS avec un graphe à n noeud et E liens soit O(nE) messages envoyé lors de l’inondation.
DV : le nombre de messages envoyé est compliqué à déterminer car il dépend du nombre d’itérations.

Complexité de la convergence :
LS : l’algorithme de Dijkstra est en O(n log(n)).
DV : encore compliqué à déterminer vu que ça dépends aussi des itérations.

C’est pour cela que DV a été abandonné pour Internet, il est difficile à prédire et utiliser de manière
optimale. Mais il reste très intéressant car on peut sans connaitre le réseau acheminer les paquets.

— OSPF : est un protocole de link stake qui est recommandé par IETF (consensus de recommandation
pour Internet). Actuellement utilisé.
— IS-IS : qui est pratiquement identique à OSPF et standardiser par ISO. Actuellement largement
utilisé étant donné qu’il est plus vieux.
— RIP : est un protocole de distance vecteur, recommandé par IETF uniquement pour les petit
réseaux.
— EIGRP : qui améliore RIP pour le rendre peu plus souple, développé par Cisco.

67
5.4 Algorithme de routage inter-domaine
Notons que la notions de domaine n’est pas la même que celle du DNS, ici domaine désigne une
entité physique, un ensemble de machine d’un opérateur. On peut aussi les appelé AS pour autonomous
systems.

Avec les algorithme intra-domaine on considérait que le réseau était "plat" car chaque routeur
sont dans le même domaine, s’échange tout entre eux etc (un peu moins avec la notion de zone dans
OSPF). De plus, ces algorithmes ne passe pas bien à l’échelle, avec des millions de destinations ça
serait impossible d’exécuter Dijkstra ou de stocker les tables. Et le second problème est que Internet
est un réseau de réseau et il faut que les réseaux puissent fonctionner comme ils le veulent avec la
technique de routage qu’ils préfèrent.

Le routage sera découpé en une partie intra-AS : fait du routage entre les routeurs de l’AS, des
routeurs serviront de liens entre l’extérieur et l’AS (gateway routeur), chaque routeur de l’AS devront
avoir le même intra-domaine protocole.
L’autre partie est l’inter-AS : fait du routage entre les AS avec les gateway.

On sait déjà comment faire du routage pour les acheminements intra-AS. Et pour les destinations
d’autre AS, on aura un algorithme faisant une combinaison de celui intra-AS ainsi que d’un inter-AS.
En effet, imaginons un AS connecté par deux de ses routeurs à deux autres AS. La question qui
se pose c’est pour aller à AS donné (par forcément un voisin), par lequel faut-il passer ? Une fois
qu’on sait par lequel passer, c’est un problème intra-AS. Pour ce faire, il faudra que les routeurs des
extrémités se renseigne sur les zones voisines et propages les informations dans leur AS.

5.4.1 Algorithme "Border Gateway Protocol" - BGP

BGP est le (il n’y en a qu’un) protocole de routage inter-domaine qui est standard à tout Internet.
Il est divisé en deux partie ; external (eBGP) qui sert à communiquer avec les AS voisins et internet
(iBGP) pour propager dans son AS se qu’il a appris de l’extérieur.

Figure 5.9 – iBGP et eBGP

Il est important de remarquer que les liens en bleu ne sont pas forcément physique !

Un exemple d’échange entre les AS : imaginons AS3 contient un préfixe X, il va alors transmettre
à AS2 un tuple (X, AS3) qui signifie si AS2 lui envoie des paquets vers X, il lui promet de les prendre
en charge. AS2 va propager l’information à ses routeurs et à AS1 il va dire (X, AS2 AS3) pour dire
qu’il se chargera d’acheminer les paquets vers X ainsi de suite.

Ce tuple, est une route, mais simplifié. En effet une route contient un préfixe + des attributs.
Comme attribut, on aura l’AS-PATH qui est la liste des AS possibles pour atteindre le préfixe (chaque

68
AS est numéroté par un organisme) ce qui est donc un vecteur de chemin (et non de distance comme
avec RIP). On aura aussi un attribut qui est le NEXT-HOP qui est la gateway de l’AS à emprunter
pour sortir du domaine et enchainer les AS suivant pour arriver au préfixe.

De plus on remarquera que BGP est une bonne solution pour éviter les boucles de chemins comme
on avait avec les algorithme à vecteur de distance, grâce à son vecteur de chemin. Si un routeur reçoit
de la part d’un autre un chemin, il pourra voir si ce chemin le contient et donc éviter la boucle en
ignorant le chemin proposé.

Politique de routage
Tout cela est régis par une politique de routage.
Une politique d’import pourrait être qu’un domaine décide de ne pas faire ce qu’un autre domaine
lui dit pour atteindre le préfixe et va plutôt emprunter un autre chemin peut être beaucoup plus long
(ex : si la société est rivale) ou plus court (ex : si il se rend compte que le chemin fait un boucle pour
repasser par lui ou qu’il est déjà connecté physiquement à un AS directement connecté au préfixe).
Une politique d’export serait de ne pas dire tout ce que sait un domaine à son voisin.

Messages
BGP aura une série de message dans son protocole :
— OPEN : pour ouvrir une connexion TCP entre deux routeurs
— UPDATE : envoyer un nouveau chemin, ou en supprimer un ancien
— KEEPALIVE : le heartbeat pour signaler que le routeur est toujours en vie
— NOTIFICATION : envoyer des messages d’erreurs

Propagation interne
Lorsqu’un noeud propage dans son AS qu’il est une sortie vers le nouveau préfixe, chaque table
des routeurs de l’AS rajouterons une ligne, avec le préfixe et l’interface de sortie qui a été déterminée
par Dijkstra ou autre pour se rendre au routeur de la frontière.

Politique d’import (de décision)

Quel choix va faire un routeur quand il a plusieurs routes pour aller vers un préfixe donné ? On
peut résumer cela en 4 critères par ordre de préférence :
1. Préférence local, les politiques de décisions. En général : l’argent (cf chap 1), il est préférable
de passer par AS client de service qu’un AS paire (échange gratuit) et encore moins par un AS
fournisseur de service plus haut encore. Car un client paye un fournisseur et le fournisseur paye
un fournisseur plus important.
2. "Le chemin le plus court" difficile à déterminer vu qu’il ne connait que le nombre d’AS que
compose le chemin, mais cela donne déjà une certaine corrélation.
3. A la gateway la plus proche (aussi appelé routage de patate chaude), par exemple si un routeur
de l’AS reçoit des deux gateway de son AS deux chemins vers le préfixe X, qui ont le même
prix et sont de même longueur, il va préféré envoyer le paquet à son gateway le plus proche.
4. Autres critères

Politique d’exportation
On a aussi dit que un AS n’est pas obligé de dévoiler tous les chemins qu’il connait. Imaginons
un petit AS X connecté à aucun autre autre AS à par ses fournisseur qui sont deux grands AS A et
B qui eux sont connectés entre eux et qui sont paires. Comme ça X a deux connexions à Internet ce
qui assure plus de robustesse pour son réseau interne. Cependant, X pourrait subir de la part de A et

69
de B du trafic qui ne le concerne pas, A pourrait passer ses paquets par X vers B ce qui obligerait X
à payer A et B alors que le paquet ne lui est même pas destiner. Donc X ne va ni dire à A qu’il est
connecté à B, ni à B qu’il est connecté à A. BUISNESS IS BUISNESS

Imaginons maintenant trois gros paires A, B, C où C est a un client Y. Si A veut envoyer un paquet
à Y, C lui ayant dit qu’il peut passer par lui, il pourrait le faire, sauf que B aussi lui a dit qu’il peut
passer par lui pour aller vers C et enfin Y. Alors par exemple A pourrait décider de le passer par B
pour l’ennuyer, et donc B aura initialement utilisé des ressources. Donc il serait intelligent que B ne
dise pas à A qu’il peut passer par lui pour aller à Y. BUISNESS IS BUISNESS

BGP est dit sans vallée, voir figure 5.9.

Figure 5.10 – Politique d’export

On peut avoir une route qui part d’un client, monte par l’AS local (par ex un ISP de tier 2 cf
chap1), et monte par le provider (ici ISP de tier 1 donc) puis peut redescendre ailleurs. On a donc
une route comme une colline.
On peut aussi avoir une route qui part d’un client, monte, et va vers un paire (ISP de tier 2) et
descendre plus tard. On a donc une route avec une montée et un plateau.
Mais une route venant d’un fournisseur (tier 1) descendra vers un AS (tier 2) et remontra vers un
fournisseur. Ce qui est une route en vallée, car l’AS de tier 2, aura trop à perde à faire ça.

5.4.2 Intra et Inter domaine

La différence au niveau des politiques et que l’intra n’en a pas.
Grâce à ces deux protocoles on peut appliquer un routage à l’échelle mondiale. Le passage à l’échelle
est donc facile.
Enfin, pour la conséquence des politiques : l’intra a ses routes configurées pour gérer au mieux le
trafic et donc avoir les meilleurs performances. Tant dis que avec l’inter les routes sont uniquement la
pour gagner des l’argent via ses politiques, la gestion des performances est secondaire.
BUISNESS IS BUISNESS, tel sont les trois mots à retenir de ce chapitre.

70
Chapitre 6

Couche de liaison

On descend encore d’un niveau dans les couches de protocoles, à la couche de liaison qui est la
deuxième.

Un lien c’est une câble physique entre deux noeuds (machine avec 3 couches), on parle alors de point
à point, il est généralement en full-duplex donc qui fonctionne dans les deux sens simultanément ou
half-duplex l’un envoie dans un sens ensuite l’autre dans l’autre sens, mais il peut aussi être uniquement
utilisé dans un sens unique. Un liens peut aussi être sans fil ce qui engendre de la compétitions entre
les appareils voulant échanger sur ce lien.

La couche de liaison de données est responsable du transfert des datagram IP d’un noeud au
suivant. Il existe beaucoup de protocoles de liens tel Ethernet, WiFi, MPLS mais les paquets IP ne
doivent pas être impacter par ces changements de liens. Pour faire une analogie, le datagram c’est un
touriste et les liens sont les moyens de transports pour arriver à sa destination.

Il y aura un processus de framing qui consiste à encapsuler le datagram en y mettant un header

et en fin de frame le code détecteur d’erreur. Il va donc aussi devoir gérer l’accès au channel s’il est
partagé pour ne pas créer trop de d’interférence, de collision. Et à qui est destiné la frame ? Ainsi
que de s’assurer à l’aide de différent procédé plus ou moins poussé, que la frame ne contient pas
d’erreur provoqué par son transport sur le liens. Cependant, cette couche ne s’occupera que rarement
de contrôle de flux etc car elle fera souvent pire que mieux, si elle retient les paquets dans un noeuds
pour ne pas encombrer un autre déjà plein, celui-ci va aussi devenir plein et il va provoquer des
problèmes de flux en chaine. Il vaut mieux donc laisser la source gérer cela.

Les techniques misent en oeuvre pour détecter et corriger des erreurs seront plus ou moins évolué
en fonction des liens. Par exemple sur une fibre otique, il y a très peu de chance d’avoir des erreurs
lors du transport, les techniques utilisées pour la détection seront donc très basique. Tant dis qu’un
liens sans fil va provoquer beaucoup d’erreurs binaires. Il ne faut pas laisser le protocole de transport
ce charger de toute la récupération des erreurs, étant donné qu’il est beaucoup plus haut dans les
couches on perdrait en efficacité.
Quand une erreur est détectée la plus part du temps la frame sera supprimée sans être amené
à la destination. Récupérer l’erreur est rarement fait car cela implique d’utiliser des ressources pour
mettre en place un mécanisme de retransmission. Qui peut se faire de deux manières : soit le noeud
précédent garde en mémoire la frame au cas où il y a eu une erreur jusqu’au noeud suivant afin de
la retransmettre, soit on rajoute dans la frame des données permettant de recalculer les données du
paquets mais cette technique demande pas mal de bits supplémentaire donc en général on ne corrigera
que l’en tête.

La couche de liaison se trouvera principalement au niveau des ports sur le hardware.

71
6.1 Protocole à accès multiple
Cette section n’a de sens que pour les réseaux à accès multiple (sans fils ou coax partagé voir chap
1) car une connexion filaire point à point ne provoque de concurrence étant donné que l’interface est
seule à émettre sur le liens.

Un lien partagé est donc un canal où tout le monde écoute ce qui est transmis dessus et on va
partir du principe simplifié que si plusieurs interface communique en même temps cela ne marche plus
car il y a interférence.

Il nous faut donc un protocole qui va déterminer quel noeud du canal peut transmettre ou pas, on
appellera aussi ce protocole à accès multiple : MAC protocol (medium access control).

Un protocole idéal serait le suivant : prenons un canal avec un débit R, alors on aimerait que
ce débit totale soit partagé équitablement pour M noeuds soit un débit moyen de R/M pour chaque
noeud. Et que le système soit totalement décentralisé, qu’il n’existe pas d’ordonnanceur avec un noeud
dédié, ainsi qu’il n’y ai pas de synchronisation sur une horloge. Et qu’il soit aussi simple possible pour
lui donner de la flexibilité.

On peut deviser les protocoles qui résolvent ce problème en trois classes :

— Channel partitioning : le channel sera découpé en petite fraction de temps où chacun aura la
sienne.
— Random Access : le channel ne sera pas découpé, donc les collisions seront autorisé mais on
essayera de les anticiper.
— Taking turns : reprends le principe du channel partitionning mais autorise à envoyé en dehors
de son time slot comme le Random Acess.

6.1.1 Channel partitioning MAC protocols

TDMA
Via un standard, le channel va être divisé en X slots et chaque noeud va recevoir statiquement un
slot de temps sur une période donnée. Et le noeud ne pourra que émettre sur ce temps, du coups si
on a qu’un seul noeud qui veut émettre il n’aura quand même accès qu’à un slot sur la période, le
channel sera alors sous utilisé et donc on aura pas le débit moyen idéal de R/M, ce ne sera vrai que
quand tout le channel est utilisé qu’il sera équitable.

FDMA
Une autre technique est de partitionner les fréquences en X bandes, cette technique est souvent
utilisée sur les câbles coaxiaux (pour la télédistributions ou téléphonique par exemple), et donc une
fréquence sera attribué à chaque noeuds. Mais le problème est le même qu’avant le débit max étant la
somme de toute les fréquences, ça ne sera pas possible d’atteindre un débit de R même en étant seul
à cause de cette division.

Conclusion
Ces techniques sont donc bien pour les réseaux téléphoniques ou les anciennes télédistributions qui
ne demande pas beaucoup de débits, mais pour Internet c’est plus problématique.

6.1.2 Random Acces Protocols

S-ALOHA
S-ALOHA une amélioration de ALOHA (voir après) qui implémente quand même des slots. Chaque
frame aura la même taille, les plus grandes seront alors fragmentée et le temps sera lui aussi divisé

72
pour exactement envoyer une frame il faut donc que les noeuds soient synchronisés pour qu’ils aient
tous le même découpage en slots. Si aucune collision, il peut directement envoyé dans le slot suivant.
Si une collision est détectée, c’est qu’un autre noeud a transmis dans le même slot alors dans ce cas-ci
une probabilité p déterminera si le noeud retente dans le slot suivant, si pas il refait une lancé de
probabilité jusqu’à ce qu’il ait la permission. On a donc aussi la possibilité pour un noeud d’envoyer
des paquets à tout les slots de temps et donc la possibilité d’exploiter tout le débits. Le système est
donc fort décentralisé, il n’y a que une synchronisation pour les slots. Cependant, vu qu’il n’y a pas
d’ordonnancement il y aura des slots non exploités et lorsqu’il y a une collision le slot est perdu car
tous ceux qui en essayé d’envoyé sur ce laps de temps doivent recommencer.

La question la plus importante est que devient l’efficacité si il y a beaucoup de noeuds qui
communiquent ce sur channel ? Pour ce faire, on va supposer que pour envoyer son premier paquet,
le noeud fera aussi en fonction de la probabilité p (même si normalement S-ALOHA ne fait pas
ça). Donc la probabilité qu’un noeud réussisse son envoie est de p(1 − p)N −1 (la probabilité qu’un
noeud transmette et que les autres ne transmettent pas). Et la probabilité qu’un noeud quelconque
réussisse est de N p(1 − p)N −1 qui est l’efficacité. Elle dépend donc de p, pour la maximiser on peut
dériver cette équation par rapport à p, p∗ = 1/N qui est le p maximiser. Ainsi l’équation devient
N p∗ (1 − p∗ )N −1 = (1 − 1/N )N −1 . Si on regarde cette fonction quand N tend vers l’infini on obtient
l’inverse de l’exponentielle soit 1/e = 0.37. Ce protocole donnera au mieux 37% de transmissions
réussies.

6.1.3 ALOHA
ALOHA est la version sans slot de S-ALOHA, il n’y a donc plus besoin d’être synchroniser. Et
les frame peuvent être envoyé n’importe quand. Mais donc la probabilité de collision augmente car à
chaque fois il faut que personne ne commence sa transmission entre le début et la fin d’un noeud.

Figure 6.1 – ALOHA

Si par une vue d’esprit un découpe en slot, comme sur la figure, on voit que afin qu’une frame ne
soit pas gênée par une autre, il faut qu’aucune autre frame ait commencé le slot précédent et le slot
actuel soit 2 slot. Contre 1 avec S-ALOHA. En effet la probabilité qu’un noeud quelconque réussisse
devient N p(1 − p)2(N −1) . Ce qui donne quand N tends vers l’infini 1/(2e) = 0.18 soit 2 fois moins
efficace.

Voyons son efficacité au niveau de la charge, posons G = pN qui est la charge moyenne on peut
alors réécrire l’équation sous cette forme : G(1 − G/N )2(N −1) et quand N tend vers l’infini on obtient
Ge−2G . Mais donc si la charge augmente, e−2G diminue plus vite que G augmente donc l’efficacité va
s’effondrer.

73
 Figure 6.2 – Efficacité en fonction de la charge ALOHA et S-ALOHA

6.1.4 Carrier-sense multiple access - CSMA

Son but est d’améliorer ALOHA, et il va mettre en place le mécanisme : écouter avant de parler.
C’est à dire on écoute le canal et s’il est déjà occupé on attend sinon on envoie. Mais cela n’empêche
pas les collisions, en effet imaginons deux appareils qui écoutent, l’un commence car le canal est libre
mais l’autre étant plus loin sur la ligne ne sait pas que l’autre a commencé et donc va aussi envoyer
son paquet et bam collision. Le problème intervient donc à l’instant suivant la libération du canal.
Pour régler ce problème, au lieu de directement commencer quand le canal devient libre, il va
définir un temps aléatoire pour recommencer à écouter plus tard et donc cet aléatoire devrait laisser
le temps à celui qui a commence en premier de se propager. On parlera alors de CSMA non persistant.
On peut mixer le mode persistant et non persistant pour donner le p-persistant, c’est à dire qu’au
moment où le canal se libère le noeud a une chance p de pouvoir directement transmettre sinon il
va attendre pendant un temps τ (voir plus loin pour détail de ce τ ). S’il est occupé, on écoute pour
savoir quand il aura finis.
Il a donc un trade-off entre efficacité et délais, à cause d’un petit p les délais seront plus long mais
l’efficacité du canal sera meilleur car il sera souvent utilisé.

Figure 6.3 – Efficacité en fonction de la charge CSMA

On voit sur le figure que la droite "idéal" représentante les délais idéals et on voit que plus on
augmente l’efficacité plus on s’éloigne de la courbe donc idéalement on aimerait avec un p adaptatif
en fonction de la charge.
Avant de continuer voici quelques notations :

74
 — B : Débit (bps)
— F : Taille de la fenêtre (bits)
— L : Longueur du câble (m)
— c : Vitesse de propagation (m/s)
Voyons maintenant ce que doit valoir le paramètre τ (s), il sera égale au temps de propagation,
qui est égale à la longueur du canal sur la vitesse de propagation du milieu. Et donc on est sûr qu’en
ayant attendu τ secondes, un byte aura parcouru tout le canal. ⇒ τ = L/c
Cependant, la transmission durera plus que τ , en effet appelons T le temps de transmission, qui
est égale à la longueur de la frame sur le débits. ⇒ T = F/B.
Et donc si on divise Tτ = BL cF
on obtient le risque d’avoir une collision, on aimerait donc que ce
taux soit le pus petit possible. Pour ce faire il n’y a donc que la taille de la frame (F ) qu’on peut faire
varier en terme de software, il faut donc augmenter F .

6.1.5 CSMA/CD
CD pour collision détection. Pendant qu’un noeud émet, il va continuer à écouter tout de même
afin de voir si quelqu’un d’autre transmet aussi et donc qu’il y a collision. Et à ce moment la, il arrête
d’émettre pour éviter de perdre plus de temps.
Cette technique marche bien sur un réseau filaire mais pas sur un réseau sans fil. Car le problème
avec les réseaux sans fil c’est que les ondes ne passent pas de la même manière partout et donc il n’est
pas facile d’écouter tout ce qui s’y passe à cause des obstacles, de la perde en puissance du signal sur
la distance, d’une trop grande différence entre les intensités de signaux où certains peuvent en masqué
d’autre etc. On va plutôt utiliser le CSMA/CA dans le cas des réseaux sans fil mais n’est pas abordé
ici.
Cependant, il faut faire attention à la taille de la frame, si elle est trop petite elle peut rentrer
en collision sans que l’émetteur s’en rende compte car pour lui tout a été envoyé et pendant qu’il a
envoyé personne ne l’a gêné alors qu’une collision c’est produite pendant la transmission sur la ligne.
Et donc uniquement l’un des deux va renvoyer son paquet. Pour éviter cela, il faut que T > 2τ (on
prend un facteur 2 par sécurité) et à partir de la, on peut isoler la taille minimale pour la frame.
Mais cela signifie que si le débit augmente, la taille minimale doit augmenter du même facteur (car
F > 2B(L/c)). Mais une trop grande frame, ce n’est pas très "rentable" en terme de tournante, vu que
les émetteurs doivent émettre plus longtemps, les autres doivent attendre plus longtemps leur tours.
Si on veut donc garder une relativement petite frame (mais pas trop pour pas avoir trop de collisions,
rappel : τ /T ), il faudra diminuer la taille des câble mais avec des débits énormes on aura des câbles
de quelques mètres ou centimètres seulement. De plus, une trop grande frame peut être sous efficace
pour une autre raison ; si on a pas grand chose à envoyer, il faudra remplir le reste de la frame avec
des bits inutiles.
Récapitulatif :
1. La carte réseau (NIC) prépare un datagram à envoyer
2. Si le canal n’est pas occupé on envoie (1-persistant). Sinon on attend qu’il le soit.
3. S’il ne détecte pas de collision tant mieux c’est terminé
4. Sinon il annule et envoie un signal de jam (de confiture mdr) très puissant (mdr) pour que tout
le monde soit sûr d’avoir compris qu’il y a eu collision.
5. Il incrémente un conteur m de collision (max m = 10), et tire un nombre K au hasard entre 0
et 2m−1 qui détermine un facteur. Il va ensuite attendre K · 2τ secondes et retente l’étape 2.
CSMA/CD fonctionne donc en 1-peristant jusqu’à ce qu’il rencontre une collision où il va rentrer
dans une sorte de p-persistent qui devient plus stricte plus il y a de collision.
Si on regarde l’efficacité du canal on voit que plus la frame est grande mieux c’est, peut importe
le nombre de noeud sur le lien car on diminue le risque de collision.

75
 Figure 6.4 – Efficacité du canal pour CSMA/CD

6.2 Taking Turns MAC protocols

Le channel partioning est efficace et équitable à haute charge mais complètement inefficace à faible
charge.

Avec les protocoles à accès aléatoire, ils sont efficaces à faible charge et à haute charge les collisions
augmente et donc ça ce dégrade mais grâce à certaines améliorations il ne s’effondre pas.

Donc on en a un bon à haute charge et l’autre à faible charge. Est ce qu’il existe un protocole
pouvant être bon dans les deux cas ?

6.2.1 Polling
On a une première solution dit de "Polling" avec un noeud qui ordonnance les autres en envoyant
un paquet à celui qui peux lui transmettre sa frame et une fois que c’est fais il en choisit un autre.
Cependant on a une perte d’efficacité du fait qu’il faut transmettre le message d’autorisation pour
parler et donc une occupation "inutile", de plus si l’ordonnanceur crash ça va poser un problème.

6.2.2 Token passing

Développé par IBM, il avait pour but de donner une meilleur alternative au Random Access utilisé
par Ethernet qui ne garanti pas le nombre de collision pour une même frame qu’on peut avoir et donc
possiblement des problèmes si une frame urgente doit être envoyé et qu’elle échoue toujours. Et il va
mettre une place un Polling mais autonome.

Ici il n’y aura pas d’ordonnanceur mais un token qui, s’il est en possession d’en noeud, le noeud
peut communiquer sur le canal et vu que par canal il n’existe qu’un token alors pas de problème de
collision. Ce token serait un paquet qui tourne entre les noeuds, si un noeud n’a rien à dire, il le passe
au suivant si il veut envoyer une frame il le fait puis attend le retour de sa frame avec le bit d’ACK,
qui lui permet de voir si sa frame a bien été reçu et sans erreur. Si aucun problème, il passe le token

76
au noeud suivant (ou le garde pendant x secondes pour une autre frame par ex) si pas il renvoie la
frame.

Le risque est que le token soit "perdu" soit par le canal à cause d’erreur binaire, soit par un noeud
qui crash au moment où il en a la possession. Mais ceci peut être déduit si on a n noeud sur le réseau
et que chacun garde le token pendant x secondes alors si le token ne revient pas à un noeud après
n × x secondes c’est qu’il y a un problème. Cependant comment fait on si un noeud veut venir se
rajouter ? C’est compliqué.

Cette technique n’est donc pas utilisée aujourd’hui mais a longtemps été un concurrent à Ethernet
et son CSMA/CD.

6.3 Accès par câble sur un réseau

Sur un réseau de distribution il y a une multitude de service à faire passer, il faudra donc découper
ce canal en fréquence pour les services et en slot de temps pour les modems.

Figure 6.5 – Réseau cablé

Pour ce faire on va découper le canal montant en time slot et le descendant en fréquence. Et ces
slots vont être attribué par le CMTS. Certains slots du canal montant ne seront pas utilisés pour
permettre au modem de faire une demande au CMTS qui va lui répondre les slots qu’il pourra utiliser
lors de la période suivante. Le problème de collision intervient donc ici sur ces slots de demande.

Pour Ethernet on utilise comme on l’a vu le CSMA/CD, tant dis que sur le réseau de distribution
on fait une combinaison de plusieurs protocole.

6.4 Accès sans fil sur un réseau

S-ALOHA est aussi utilisé dans le cadre des réseau 3G, 4G. Le WiFi lui, utilisera le CMSA/CA.
Quant au Bluethooth il utilisera le Token passing.

6.5 Réseaux locaux - LAN

6.5.1 Les adresses MAC
A chaque fois qu’on envoie une frame sur un lien partagé il faut indiquer à qui est destiner cette
frame. Pour cela on va utiliser des adresses MAC qui sont uniquement utilisé localement et sont
représenter sur 48-bits. Elles sont stockés dans une ROM dans la carte réseau (NIC) de l’appareil.

77
 On fait un abus de langage en parlant d’adresse mais en faite ce n’est qu’un identifiant unique au
monde propre à l’appareil et n’indique en rien la localisation de l’appareil tant dis que les adresses IP
oui. Afin d’avoir un numéro unique les fabricants de matériel reçoivent un préfixe et après il gère le
suffixe comme il le souhaite.

Afin d’identifier le couple adresse IP et MAC, chaque noeud va tenir une table appelé ARP qui
aura des 3-uplet dans ses entrées : IP, MAC, TTL. Après que le TTL soit écoulée l’entrée est supprimée
de la table.

6.5.2 ARP protocol

Le protocole ARP est uniquement utilisé dans les LAN. Imaginons qu’un noeud A veut envoyer un
datagram à un autre noeud B, si son couple IP/MAC n’est pas dans la table, comment fait on ? Pour
ce faire A va envoyer en broadcast une query ARP et qui va demandé "je cherche la MAC associé à
l’IP X", suite à ça B répondra à A en lui donnant son adresse MAC.

Afin d’optimiser la demande, lorsque A fait la requête en broadcast il va y renseigner son adresse
IP et la mac pour que tout le monde puisse mettre à jour sa table.

Le protocole est donc plug and play, il n’y a rien à faire manuellement.

6.5.3 Se rendre dans un autre LAN

Figure 6.6 – Deux LAN relié par un routeur

Imaginons que A veut envoyer un paquet à B. Premièrement, comment A connait l’adresse IP (de
gauche) de R ? Grâce au DHCP. Ensuite comment A connait l’adresse IP de B ? Grâce à un DNS
(généralement fournis par le routeur). Et enfin comment A a connait l’adresse MAC (de gauche) de
R grâce à ARP.

A va déterminer comme adresse MAC de destination celle de R mais l’IP est bien celle de B.
Lorsque le paquet sera capturer par R, il va décapsuler par sa couche Eth et donc le paquet IP se
retrouve en couche IP, il cherche alors l’adresse MAC de l’IP (ici B) en effectuant une requête ARP
en broadcast et il transmet la frame sur ce réseau qui sera intercepté par B.

78
6.5.4 Ethernet
Le cable Ethernet est devenue l’incontournable pour les réseau local, dû à sa simplicité il a pu
évoluer pour s’adapter à l’augmentation des débits. A l’époque c’était un très gros câble coaxial
jaune.

Figure 6.7 – Ethernet à l’origine

On voit que l’interface vient à l’aide d’une prise vampire se mettre sur le câble (afin de faire un
contact électrique) et les contrôleurs utilise le CSMA/CD pour détecter les collisions comme on l’a vu
précédemment.
En voit que à chaque extrémité il fallait mettre une résistance qui "consume" le courant afin qu’il
ne rebondisse pas dans le câble pour repartir dans l’autre sens.

Liaisons entre les appareils

Figure 6.8 – Topologie physique d’Ethernet

On voit donc qu’a l’origine on avait une topologie en "bus" où tout le monde est sur le même
câble. Mais cela n’était pas pratique car le câble étant très long, un défaut dans le câble pourrait faire
rebondir le courant et créer une collision avec lui même.

Par la suite on est passé à une topologie en "étoile" où un hub retransmet dans chacun des câbles
ce qu’il a reçu et si l’hôte attaché à se ce câble n’avait pas la même adresse mac il ignorait le datagram.
Le hub n’avait aucune intelligence, il répétait juste l’information.
Mais le hub n’empêchait pas les collisions, car le hub ne fait aucun stockage il retransmet aussi vite
ce qu’il reçoit donc les collisions dans un cable sont reproduit sur les autres par conséquent chaque
host peut détecter une collision. Et chaque liens devait avoir le même débits que tout les autres pour
que cela fonctionne.

Le hub a évolué en quelque chose de plus intelligent qui est un switch qui va posséder des interfaces
et donc aussi utilisé CSMA/CD.

79
Structure d’une frame Ethernet

Figure 6.9 – Structure d’une frame Ethernet

On y retrouve l’adresse MAC de destination et source, le type de ce qu’il transporte que data (IP,
ARP etc), CRC sera la pour faire de la détection d’erreur et enfin le preamble est une suite de 0 et
1 sur 7 bytes (commençant par 10101010 et finissant par 10101011) permettant à la destination de
connaître la vitesse d’horloge de la source pour lire à la même vitesse que ce qui est envoyé. Les deux
horloges sont donc synchroniser sans mécanisme externe.

On comprends donc qu’il n’est pas fiable, il n’y a pas de mécanisme de handshake entre les deux
et que s’il y a une erreur binaire la frame est jetée sans ACK (ce sera donc à TCP de détecter les
pertes).

Standard Ethernet
Il existe beaucoup de standard de câble :
— Matériaux : cuivre, de la fibre, du coax ...
— Vitesse 2, 10, 100 Mbps, 1, 2.5, 10 Gbps ...
— Full duplex ou non.
— Le nombre de paire de cuivre utilisé.
— Pour la fibre : si elle est en multi-mode, mono mode ...
— ...

6.5.5 Switches
On a vu que les hub on évolué en switch. Au final le switch va très fort ressembler à ce que fais un
routeur, il va analyser le frame Ethernet, bufferiser et forward. Ainsi qu’utiliser le CSMA/CD pour
détecter les collisions de ses transferts. Son but est d’autre complètement transparent, plug and play,
les host ne savent pas qu’il existe et font comme s’il n’existait pas.

Les collisions interviendrons si l’host connecté au swtich envoie un paquet en même temps que le
switch lui transfert quelque chose sauf si le câble est fullduplex. Donc le point positif avec le full duplex,
c’est qu’il n’y aura pas de collision et donc la contrainte sur la taille de la frame vu précédemment
peut être relâchée qui réduisait les débits ou la longueur du câble.

Pour faire ses forwards, le switch va avoir une switch table (tel la forwarding table du routeur).
Dans le routeur, on avait un algorithme qui découvrait la topologie pour faire la table de routage et
ensuite faire des calculs pour remplir la table. Mais dans un switch vu que son but est quelque chose
de plus simple le mécanisme lui aussi sera plus léger.

Partons du principes que le switch et les appareils viennent d’être câblé, donc la switch table
est vide. Lorsque le switch intercepte un paquet, il va pouvoir renseigner dans sa table la MAC et
l’interface au quel la machine est branchée (+ un TTL pour alléger la table). Maintenant, s’il ne
connait pas le destinataire ? Pour ce faire il va envoyer la frame sur toute les interfaces comme le
faisait le hub. S’il la connait, il l’envoie dans l’interface correspondante à sa table.

On dit qu’un switch fait du self-learning car au début sa table est vide et au fur de transfert elle
se remplie grâce à l’entête des frames Ethernet.

80
 Si l’hôte est un peu plus avancé, il enverra à sa connexion un petit paquet pour se présenter et
l’adresse de destination sera la même que la source, donc quand le switch va regarder ces adresses il
va l’écrire dans sa table et détruire le paquet, car ça ne sers à rien d’envoyer le paquet à la source.

Interface
Jusqu’à ici on a fait l’hypothèse que les switch n’ont pas besoin d’avoir des adresses MAC (il ne
mentionne pas IP, mais dans la pratique, les switchs plus avancés auront une adresse IP) car vu qu’ils
ont une interface Ethernet, ils en ont une et cela leur permettra d’être configurer pour tout un tas de
chose.

Switches inter connecté

Cela va fonctionner de la même manière, quand un hôte peut envoyer un paquet qui se trouve sur
un autre switch, le switch vu qu’il ne connait pas l’hôte il va envoyer la frame à tout le monde et donc
à un autre switch qui contient peut être l’hôte qui fera de même si il ne connait pas l’hôte ainsi de
suite. Et par la même occasion les switchs vont pouvoir remplir leur table en pouvant renseigner que
tel adresse MAC est arrivé à tel interface et donc plus tard il ne faudra plus inonder tout le réseau.

La faiblesse d’un réseau avec des switch inter connecté est que si un switch tombe en panne tout
ce qu’il reliait se retrouve déconnecté du réseau. Et donc on aimerait connecter les switch dans tous
les sens et donc avoir une structure de graphe cyclique et non plus un arbre tel le fait un routeur.
Mais cela est interdit ! Car en cas de flooding, aucun switch ne connait la destination donc les switchs
vont se balancer en cycle le paquet et cela ne va jamais s’arrêter. Et vu que dans une frame Ethernet
il n’y a pas de TTL, il n’y a donc pas de garde fou à un paquet perdu.

Afin de quand même pouvoir se prévenir de panne, on va connecter les switches entre eux dans
tout les sens mais on ne va pas respecter la topologie physique. On va créé ce qu’on appel un spanning
tree, autrement dit un arbre qui va ignorer les cycles entre les switches et si il y a un problème, un
switch crash, un autre arbre spanning tree sera créé.

Spanning tree
Comment est construit le spanning tree ? On va définir comme étant le root switch de l’arbre celui
avec le plus petit id (le mac et une priorité, la priorité peut être utilisé par un administrateur pour
manipuler les id et décider de qui est la racine). Afin de faire cette élection, des messages appelé BDPU
sont échangés. Ce message sera composé de trois informations : id de qui il pense être la racine, la
distance qu’il a vers cette racine (nombre de noeud à franchir ou une autre métrique) et son id.

Chacun inonde avec son avis et compare pour voir s’il s’est trompé sur qui est le Root Switch et
re inonde si c’est le cas (sauf à celui qui lui a donner la bonne réponse je suppose). Une fois que tout
le monde a vu juste, le mécanisme s’arrête et l’arbre est créé.

Ensuite une fois que chacun sait qui est la racine il faut définir l’interface à utiliser pour se rendre
vers la Root Switch appelé Root Port. Mais s’il y a plusieurs possibilité, que faire ? Il va comparer
les BDPU qu’il a reçu lui indiquant la racine et si il en a plusieurs qui indique la racine c’est qu’il
a plusieurs possibilités. Le premier choix sera de choisir celui avec la plus petit distances, mais si les
distances sont les même il choiera celui avec le plus petit id. Le switch relié au Root Port sera appelé
Designed Switch de celui qui l’a désigné avec un Root Port.

Les autres interfaces seront soit Forwarding Port soit Blocking Port. C’est à dire que les Blocking
Port empêcherons le cycle. Pour chaque port restant on va comparé le BDPU reçu et celui envoyé.
Si celui qu’on a envoyé a une distance plus petite que celui reçu, alors le port est Forwarding, sinon
Blocking.

81
 Figure 6.10 – Choix des interfaces

Dans l’exemple de la figure, ce n’est pas parce que D a bloqué l’interface entre C et lui qu’il
n’écoute plus. Car C va envoyer des BDPU régulièrement pour informer possiblement d’une panne et
donc cela modifiera le spanning tree. De plus, si B tombe en panne, D va aussi tôt choisir C comme
Rooting Port.

Mais donc, on remarque que le forwarding n’est pas aussi optimal que celui du routeur. En effet,
pour envoyer un paquet de D à C il fait tout le tour alors qu’un chemin plus court existe.

6.5.6 Switches Vs Routeur

Le switche et le routeur buffurise tout deux et foward. Mais le routeur lui prend la décision en
fonction de la couche network donc l’IP, tant dit que le switch prend la décision en fonction de la
couche de liens et donc la MAC. (Note à moi même : le switch n’a donc pas de table ARP)
Et le mécanisme utilisé pour former les tables n’est pas le même : le routeur le fait avec Dijkstra
et les switches par flooding et self-learning.

On a aussi que le routeur isole le trafic et le switch à moitié car il envoie du trafic sur des interfaces
qui ne sont pas celles de destination lors de flooding, mais en général rapidement il ne le fera plus, ce
n’est que lorsqu’il y a un nouvel appareil que cela se produira.

Par contre un switch est plug and play, c’est à dire qu’il n’impactera pas les hôtes. Alors qu’un
routeur ne l’est pas.

Et pour finir un routeur prend toujours la route optimale alors qu’un switch non.

6.5.7 Data center

La figure montre qu’on a visiblement le réseau divisé en deux subnet. Cependant, on a vu que l’on
peut interconnecter les switches ensembles pourquoi on ne le fait pas ? En faite la résilience (résistance
au panne) sera effectuée autrement, ce sont les rack de serveurs qui seront copiés comme cela si un
switch tombe en panne l’accès se fera par un autre switch.

On a aussi la présence d’un load balancer qui va faire faire un petit crochet au paquet intrant dans
le switch au quel il est connecté, et ce load balancer va rediriger le paquet vers un serveur qu’il aura
décidé pour répartir la charge entre tous.

82
 Figure 6.11 – Topologie d’un data center

6.6 Détection d’erreur

Figure 6.12 – Détection d’erreur

La détection n’est pas fiable à 100% peut importe la fonction f. Car une erreur peut aussi intervenir
sur l’EDC et sur D, et que, par mal chance, elles correspondent via la fonction f.

Si f est une fonction de détection simple tel un bit de parité de D cela ne permettra pas la correction
d’erreur et trop facilement deux erreurs peuvent se compenser.

Mais si f est plus avancée, si on place les data en matrices carrée, on fera un bit de parité mais à
deux dimension, un bit de parité par colonne et par chaque ligne et à la fin un bit de parité se fera
sur les bits de parités des lignes. On aura donc un vecteur de bit de parité qui nous permettra de faire
machine arrière et de trouver d’où viens l’erreur, on a donc aussi la capacité de correction. Mais s’il
n’y en a au moins 2 impossible de corriger. Cependant, ce n’est pas si efficace que ça (1 erreur max
corrigeable) et cela prend pas mal d’espace (racine de la longueur des données).

On a aussi vu le checksum comme le fait TCP/UDP mais ce n’est pas si robuste que ça car
maximum une erreur peut être corrigée. On se souvient qu’on avait dit que ça suffisait pour la couche
TCP/UDP car la couche de liens avait quelque chose de plus robuste, mais qu’elle est cette technique ?

83
6.6.1 CRC
Cyclic reduancy check. Si on a d bits de donnée D et r bits de CRC. On peut représenter cette
suite binaire comme un nombre binaire : <D,CRC> = D × 2r xor CRC
Ensuite on va introduire un générateur G qui contient r+1 bits qui est un diviseur de <D, CRC>.
Donc que D × 2r xor CRC = n · G
Et ce mécanisme de détection avance qu’il pourra détecter jusqu’à r bits successif qui sont erronés.

On peut réécrire l’équation du dessus comme G · 2r = n · G xor CRC ≡ G · 2r = n · G + CRC on

voit donc ce que doit valoir CRC = D · 2r mod G.

Ceci est donc une vision binaire mais on peut le représenter comme un polynôme en effet :

Figure 6.13 – CRC exemple (R = CDC)

L’avantage de voir cela de manière polynomiale, c’est que si T (x) = D(x) · xr + R(x) alors
T (x) mod G(x) = 0, si le récepteur fait cela et obtient autre chose que 0 c’est qu’il y a eu une
erreur.

Une erreur dans le cas de notre polynôme, c’est soit ajouter, soit supprimé un terme. On peut
alors dire que E(x) est le polynôme représentant les erreurs donc sans le savoir le récepteur aura T(x)
+ E(x). Mais (T(x) + E(x)) mod G(x) = E(x) mod G(x) car T(x) mod G(x) = 0. On a donc trouvé
E(x) et il suffit de le soustraire au T’(x) reçu.

Cependant, ce n’est pas garanti comme on l’a dit aucune fonction f ne peut garantir la détection
d’erreurs à 100%. En effet si par mal chance, E(x) est aussi multiple de G(x) le résultat sera 0. Voici
deux G(x) typiques permettant de trouver certaines erreurs :

84
Figure 6.14 – G(x) exemple 1

Figure 6.15 – G(x) exemple 2

85
Chapitre 7

Récapitulatif

Un ordinateur se branche au réseau et veut accéder à une page web. Que va-t-il se passer ?

On se trouve dans un réseau local donc grâce à DHCP via un paquet UDP/IP, on nous fournis
une IP ainsi que celle du routeur et d’un DNS. Les paquets étant passé à travers un switch, il va aussi
pouvoir mettre dans sa switch table la paire MAC-interface.

86
 Maintenant, on peut faire une requête au DNS dans un paquet UDP/IP. Cependant, pour faire
sortir le paquet du réseau local, il doit l’envoyer au routeur, très bien il connait son adresse IP, mais
Ethernet lui a besoin d’une adresse MAC, donc une requête ARP est émise sur le réseau.

L’adresse MAC est mise dans la frame et elle est en envoyée sur le réseau local. Le routeur
l’intercepte décapsule la frame et regarde l’IP et il envoie le paquet vers le subnet de son ISP (qui ici
contient le DNS). Le mécanisme de routage se poursuit dans ce réseau jusqu’à arriver au DNS et un
réponse est renvoyée à l’ordinateur donnant l’adresse du serveur de la page web.

Une requête HTTP peut être créée et mise dans un paquet TCP/IP, mais elle ne peut pas être
envoyée car la connexion n’est pas encore ouverte avec le serveur. Du coups TCP envoie un paquet
SYN sur le welcom socket du serveur, qui lui répond un SYNACK. Dès lors la connexion est établie.

87
 La requête HTTP peut être envoyée et récupérée de l’autre coté ; TCP s’assure que tout c’est
bien passé et renvoie la page au client qui s’assure que tout s’est bien passé. Et le browser peut enfin
afficher la page.

88