Introduction aux réseaux

En 1969, quatre ordinateurs américains sont reliés pour former ARPANET. Aujourd'hui, plus de cinq milliards de personnes partagent un même réseau planétaire, et vous y êtes connecté en lisant cette page. Entre les deux, aucune rupture technologique unique : la même poignée d'idées, répétée et empilée. Ce cours démonte ces idées une à une.

Ce premier chapitre pose le vocabulaire et, surtout, les grandeurs qui mesurent un réseau. Il paraît descriptif ; il contient déjà la confusion la plus tenace de la matière — celle entre débit et latence — que nous allons désamorcer par le calcul plutôt que par une phrase.

Qu'est-ce qu'un réseau ?

Un réseau informatique est un ensemble de machines reliées pour échanger de l'information. « Machine » se prend au sens large : un ordinateur, un téléphone, une imprimante, un capteur, une voiture. Chacune est un nœud ; les échanges suivent des règles communes, les protocoles, qui occuperont tout le cours.

L'intérêt d'un réseau croît vite avec sa taille : relier $n$ machines crée de l'ordre de $n^2$ communications possibles. C'est ce qui explique qu'un réseau, une fois amorcé, tende à absorber tous les autres — l'histoire d'Internet est celle de réseaux séparés qui ont fini par se raccorder à un seul.

Classer par la taille : LAN, MAN, WAN

On classe d'abord les réseaux par leur étendue géographique, parce que la distance change les techniques employées.

La distinction n'est pas qu'une affaire de taille : un LAN est rapide (courtes distances, faible latence, un seul propriétaire), un WAN est lent et hétérogène (grandes distances, équipements de multiples opérateurs). Internet est le WAN par excellence — non pas un réseau, mais un réseau de réseaux, ce que son nom dit littéralement.

Les topologies

La topologie décrit la forme des liaisons — qui est connecté à qui.

• Bus : toutes les machines partagent un même câble. Simple et bon marché, mais une coupure du câble paralyse tout, et les machines se disputent le médium (d'où le CSMA/CD du chapitre 4).
• Étoile : toutes les machines se relient à un équipement central (commutateur). C'est la topologie dominante aujourd'hui : une panne de câble n'isole qu'une machine, et le central arbitre les échanges.
• Anneau : chaque machine est reliée à la suivante en boucle. Historique.
• Maillée : les nœuds sont reliés par des chemins redondants. Coûteuse, mais résistante aux pannes — c'est la structure du cœur d'Internet, où plusieurs routes mènent au même endroit.

Un réseau réel combine ces formes à différentes échelles : des étoiles locales, raccordées par un cœur maillé. La redondance du maillage est ce qui permet à Internet de survivre à la coupure d'un câble sous-marin sans que l'utilisateur s'en aperçoive.

Commutation de circuits contre commutation de paquets

Voici le choix fondateur, celui qui distingue le téléphone d'antan de l'Internet. Comment transporter l'information à travers le réseau ?

La commutation de circuits, héritée du téléphone, réserve un chemin de bout en bout pour toute la durée de la communication. Le circuit est dédié : débit garanti, mais gaspillé dès qu'on se tait, et le réseau refuse de nouvelles communications quand tous les circuits sont pris.

La commutation de paquets, celle d'Internet, découpe l'information en petits morceaux autonomes, les paquets, envoyés indépendamment. Chaque paquet porte son adresse de destination ; les équipements du réseau le relaient de proche en proche, et différents paquets peuvent même emprunter des routes différentes.

La commutation de paquets a gagné pour deux raisons : elle partage efficacement les liens entre de nombreux flux intermittents (le trafic informatique est fait de rafales, pas de flux continus), et elle résiste aux pannes — si un lien tombe, les paquets suivants contournent. Son prix est l'absence de garantie native : un paquet peut être perdu, dupliqué, désordonné. Rattraper cela sera le travail de TCP, au chapitre 7.

Les grandeurs : débit, latence, bande passante

Trois nombres mesurent un réseau, et les confondre est l'erreur la plus répandue.

Le débit (ou bande passante, dans l'usage courant) est la quantité de données par seconde qu'un lien peut écouler : en bits par seconde (bit/s, Mbit/s, Gbit/s). C'est la largeur du tuyau.

La latence est le délai pour qu'un bit traverse le lien d'un bout à l'autre : en millisecondes. C'est la longueur du tuyau. On mesure souvent le temps aller-retour (le RTT, round-trip time), celui que renvoie la commande ping.

Ces deux grandeurs sont indépendantes, et c'est le point à graver. Un lien peut avoir un énorme débit et une énorme latence (une liaison satellite : beaucoup de données par seconde, mais un quart de seconde de délai à cause de la distance), ou l'inverse. Le temps total d'un transfert combine les deux :

$\text{temps} = \underbrace{\text{latence}}_{\text{délai fixe}} + \underbrace{\frac{\text{taille}}{\text{débit}}}_{\text{temps d'émission}}.$

La conséquence pratique est décisive. Pour un petit transfert (une requête web), c'est la latence qui domine : élargir le tuyau ne change rien. Pour un gros transfert (une sauvegarde), c'est le débit qui domine : la latence devient négligeable. Optimiser un réseau commence donc par savoir laquelle des deux grandeurs limite — ce sont deux problèmes différents, avec deux solutions différentes. L'exercice vous le fera calculer, jusqu'au cas extrême du camion de disques durs.

À vous

L'exercice attaque la confusion débit/latence par le calcul. Vous mesurez le temps de transfert d'une petite requête puis d'un gros fichier sur le même lien — et vous constatez que la première est limitée par la latence, le second par le débit. Puis vous comparez « transférer 100 To par Internet » à « les transférer par un camion de disques durs », et vous découvrez, chiffres à l'appui, pourquoi le camion gagne.

C'est le meilleur antidote à l'idée fausse que « plus de débit = plus rapide » : cela dépend entièrement de ce qu'on transfère.

// Temps pour transférer un fichier = temps d'ACHEMINEMENT (la latence, une
// durée fixe pour aller-retour) + temps d'ÉMISSION (taille / débit).
//
//   débit    : combien de bits par seconde le lien peut écouler (bit/s)
//   latence  : temps qu'un bit met à traverser le lien (s)
//
// Attention aux unités : 1 octet = 8 bits ; débits en bits/s, tailles en octets.

function tempsTransfert(tailleOctets, debitBitParSec, latenceSec) {
  const tailleBits = tailleOctets * 8;
  const tempsEmission = tailleBits / debitBitParSec;
  return latenceSec + tempsEmission;
}

// ── À VOUS (1) : deux scénarios ─────────────────────────────────────────────
// Scénario A : une petite requête web de 2 ko sur une fibre à 100 Mbit/s,
//   latence 20 ms.
// Scénario B : le MÊME lien, mais un fichier de 5 Go (une sauvegarde).
const ko = 1000, Mo = 1e6, Go = 1e9;
const Mbit = 1e6;

const tA = tempsTransfert(2 * ko, 100 * Mbit, 0.020);   // à observer
const tB = tempsTransfert(5 * Go, 100 * Mbit, 0.020);   // à observer
console.log("A (2 ko)  :", tA.toFixed(3), "s");
console.log("B (5 Go)  :", tB.toFixed(1), "s");

// ── À VOUS (2) : le camion de disques durs ──────────────────────────────────
// Transférer 100 To d'un data-center à un autre. Deux options :
//   - Internet : lien dédié à 1 Gbit/s, latence 30 ms.
//   - Un camion qui emporte les disques : 4 h de route, mais 100 To « d'un coup ».
// Calculez les deux temps. Lequel gagne ? Que dit ce résultat sur débit vs latence ?
const To = 1e12, Gbit = 1e9, heure = 3600;
const parInternet = 0; // à compléter avec tempsTransfert(...)
const parCamion   = 0; // à compléter (indice : la "latence" du camion, c'est la route)
console.log("");
console.log("100 To par Internet :", (parInternet / heure).toFixed(1), "h");
console.log("100 To par camion   :", (parCamion   / heure).toFixed(1), "h");

const parInternet = tempsTransfert(100 * To, 1 * Gbit, 0.030);
// 100 To = 8e14 bits ; / 1e9 bit/s = 8e5 s ≈ 222 h ≈ 9,3 JOURS.
const parCamion = 4 * heure;
// Le camion : 4 h de route, peu importe la latence — il « émet » 100 To en un
// seul voyage. Débit effectif : 100 To / 4 h ≈ 55 Gbit/s. Le camion gagne
// très largement (4 h contre 9 jours).

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. DÉBIT et LATENCE sont deux choses INDÉPENDANTES.
//    - La latence est un DÉLAI (le temps du premier bit pour arriver). Elle
//      domine pour les petits transferts : le scénario A (2 ko) est limité par
//      les 20 ms de latence, pas par le débit — émettre 2 ko à 100 Mbit/s ne
//      prend que 0,16 ms.
//    - Le débit est un VOLUME PAR SECONDE. Il domine pour les gros transferts :
//      le scénario B (5 Go) est entièrement décidé par le débit, la latence y
//      est négligeable.
//
// 2. Le camion de disques est l'exemple canonique : ÉNORME débit (55 Gbit/s),
//    ÉNORME latence (4 h avant le premier octet). On ne l'utiliserait jamais
//    pour charger une page web (latence catastrophique), mais il bat Internet
//    pour déplacer 100 To. « Ne jamais sous-estimer la bande passante d'un
//    camion de bandes sur l'autoroute » — la boutade est un vrai principe.
//
// 3. Conséquence pratique : optimiser un réseau, c'est d'abord savoir si on
//    est limité par la latence (jeux en ligne, requêtes courtes : réduire les
//    aller-retours) ou par le débit (sauvegardes, vidéo : élargir le tuyau).
//    Ce sont deux problèmes différents, avec deux solutions différentes.

Ce que la suite en fait

Vous savez ce qu'est un réseau, comment le classer, comment l'information y circule (en paquets), et comment le mesurer. Reste une question : comment fait-on tenir ensemble tant de protocoles, de techniques et d'équipements différents sans que l'ensemble devienne ingérable ?

La réponse est l'idée la plus importante de tout le cours, celle qui structure Internet et les huit chapitres suivants : le découpage en couches. C'est l'objet du chapitre 2 — et une fois ce modèle en tête, chaque protocole que vous rencontrerez trouvera sa place dans une case précise.

À retenir