Applications en Réseaux

🔗

1. TCP — Transmission Control Protocol

TCP est un protocole de transport orienté connexion, fiable et ordonné. Il s'appuie sur IP (couche réseau) et ajoute des mécanismes de contrôle de flux, de congestion, et d'acquittement.

🤝 Établissement de connexion — 3-Way Handshake

Client Serveur

Client ──── SYN (seq=x) ────▶ Serveur

Client ◀── SYN-ACK (seq=y, ack=x+1) ── Serveur

Client ──── ACK (ack=y+1) ────▶ Serveur

Détail des flags

SYN (Synchronize) : initie la connexion, transmet le numéro de séquence initial ISN (choisi aléatoirement, ex. seq = 1000)
SYN-ACK : le serveur accuse réception (ack = ISN_client + 1 = 1001) et propose son propre ISN (seq = 5000)
ACK : le client confirme (ack = ISN_serveur + 1 = 5001) — connexion établie

RTT (Round Trip Time) = temps entre l'envoi du SYN et la réception du SYN-ACK

🔒 Fermeture de connexion — 4-Way Handshake (FIN)

La fermeture est half-duplex : chaque côté ferme indépendamment sa direction d'envoi.

FIN (client → serveur) : le client n'a plus rien à envoyer
ACK (serveur → client) : le serveur accuse réception
FIN (serveur → client) : le serveur n'a plus rien à envoyer
ACK (client → serveur) : le client confirme — état TIME_WAIT (2 × MSL ≈ 60 s)

💡 TIME_WAIT : Le client attend 2 × MSL (Maximum Segment Lifetime, ~30 s) avant de libérer le port, pour garantir que l'ACK final est bien arrivé et éviter la réutilisation prématurée du port.

⚙️ Extensions TCP notables

SACK — Selective Acknowledgement (RFC 2018)

Permet d'accuser réception de segments non consécutifs, évitant la retransmission de segments déjà reçus. Encodé dans les options TCP.

Window Scaling (RFC 7323)

Le champ fenêtre TCP est limité à 65 535 octets (16 bits). L'option window scale permet un facteur multiplicateur jusqu'à 2¹⁴ → fenêtre max ≈ 1 Go.

Timestamps (RFC 7323)

Mesure précise du RTT et protection contre les numéros de séquence trop anciens (PAWS — Protection Against Wrapped Sequences).

Nagle Algorithm

Regroupe les petits segments pour réduire la surcharge réseau. Peut être désactivé avec TCP_NODELAY pour les applications temps-réel.

TCP Fast Open (RFC 7413)

Permet d'envoyer des données dès le SYN (cookie TFO), réduisant la latence d'un RTT pour les connexions répétées au même serveur.

Congestion Control

Algorithmes : Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery. Variantes : Reno, CUBIC (Linux), BBR (Google).

⚡

2. UDP — User Datagram Protocol

UDP est un protocole de transport sans connexion, non fiable, non ordonné. Très léger (en-tête = 8 octets seulement contre 20 pour TCP).

✅

Avantages

Pas de handshake → faible latence
Pas de contrôle de flux → débit maximal
Supporte le multicast/broadcast
Idéal : DNS, DHCP, VoIP, jeux en ligne, streaming

❌

Inconvénients

Pas de garantie de livraison
Pas d'ordre des paquets
Pas de contrôle de congestion natif
Fiabilité à implémenter côté applicatif si besoin

⚙️ Extensions UDP

QUIC (RFC 9000) — UDP+TLS+HTTP

Protocole Google basé sur UDP, intègre chiffrement TLS 1.3, multiplexage de flux, reprise de session 0-RTT. Base de HTTP/3. Évite le head-of-line blocking de TCP.

DTLS — Datagram TLS

TLS adapté à UDP. Utilisé dans WebRTC pour les flux médias temps-réel. Ajoute la fiabilité optionnelle et le chiffrement sans les contraintes de TCP.

RTP / RTCP

Real-time Transport Protocol sur UDP. RTP transporte les médias, RTCP transporte les statistiques (perte, jitter, RTT). Base de VoIP (SIP), visioconférence.

SCTP — Stream Control Transmission Protocol

Protocole hybride : fiabilité de TCP + multi-streaming + multi-homing. Utilisé dans les télécoms (SS7 over IP).

📏

3. MTU, MMS, RTT et Calculs de Débit

MTU — Maximum Transmission Unit

Taille maximale d'une trame au niveau liaison (couche 2).

Ethernet : 1500 octets
Wi-Fi (802.11) : 2304 octets
PPPoE (ADSL) : 1492 octets (1500 − 8)
IPv6 minimum : 1280 octets
Loopback : 65 535 octets

MMS — Maximum Message Size (TCP)

Taille maximale des données TCP dans un segment (sans en-têtes).

MSS = MTU − IP_header − TCP_header
MSS = 1500 − 20 − 20 = 1460 octets

Negocié lors du handshake (option MSS dans le SYN).

⏱️ RTT — Round Trip Time

Temps de propagation aller-retour entre client et serveur.

RTT = 2 × délai de propagation

Exemple : Paris → New York ≈ 6 000 km, vitesse signal ≈ 200 000 km/s
RTT ≈ 2 × (6000 / 200 000) = 2 × 30 ms = 60 ms

📊 Débit Réel vs Débit Global

Débit Brut (capacité du lien)

Débit_brut = capacité physique du lien (ex. 100 Mbit/s)

Débit Global (Goodput)

Données utiles réellement transmises par unité de temps (sans les en-têtes, retransmissions, paquets perdus).

Débit_global = taille_données_utiles / temps_total_transmission

Exemple :
Fichier = 10 Mo = 80 Mbit
Lien = 100 Mbit/s, RTT = 20 ms, taille fenêtre TCP = 65 535 octets

Temps de transmission = 80 / 100 = 0.8 s
→ Débit réel ≈ 80 Mbit / 0.8 s = 100 Mbit/s (sans overhead)

Impact du RTT sur TCP (sans SACK)

Débit_max_TCP = Fenêtre_TCP / RTT

Fenêtre = 65 535 octets = 524 280 bits
RTT = 60 ms = 0.06 s
Débit_max = 524 280 / 0.06 ≈ 8.7 Mbit/s

→ Même sur un lien 1 Gbit/s, TCP sans window scaling est limité à ~8.7 Mbit/s à 60 ms RTT !

💡 Bandwidth-Delay Product (BDP)
BDP = Débit × RTT = quantité de données "en vol" sur le réseau
Ex : 1 Gbit/s × 60 ms = 7.5 Mo → la fenêtre TCP doit être au minimum de 7.5 Mo pour saturer ce lien.

⚠️ Pièges d'examen fréquents

Ne pas confondre débit en bits/s et en octets/s (×8)
Un segment TCP de 1460 octets de données a 40 octets d'en-têtes (IP+TCP) → overhead = 40/1500 ≈ 2.7%
Le RTT inclut les délais de propagation, de transmission ET de traitement

📦

4. Formats de Données et Architectures API

🗂️ Pourquoi JSON plutôt que le reste ?

Format	Avantages	Inconvénients	Usages typiques
JSON	Léger, lisible humain, natif JS, quasi-universel, simple à parser	Pas de schéma natif, verbeux (clés répétées), pas de types binaires	REST API, config, NoSQL, localStorage
XML	Schéma strict (XSD), namespace, très mature, SOAP	Très verbeux (balises ouvrantes/fermantes), parsing lourd	Banque, assurance, EDI, configs Java
Protobuf (Google)	Binaire compact, très rapide, schéma fort (.proto)	Non lisible humain, tooling nécessaire	gRPC, microservices haute perf
MessagePack	Binaire, compatible JSON, plus compact	Moins répandu	Redis, IoT, mobile
CSV	Très simple, Excel-compatible	Pas de types, pas de hiérarchie	Exports tabulaires, data science
YAML	Lisible, commentaires, superset JSON	Sensible à l'indentation, lent à parser	Config (Docker, Kubernetes, CI/CD)
Avro	Schéma JSON + binaire, évolution de schéma	Complexité	Kafka, Hadoop, big data

💡 JSON gagne car : natif dans les navigateurs (JavaScript), support universel dans tous les langages, lisible sans outil, suffisamment compact pour la majorité des usages web, parse rapide avec JSON.parse().

🏦 SOAP + XML — Le monde bancaire

SOAP (Simple Object Access Protocol) utilise XML comme format de message. Encore très présent dans :

Banques et assurances : systèmes legacy, interopérabilité mainframes, normes SEPA/SWIFT
Services web d'entreprise (Java EE, .NET WCF)
Gouvernements, hôpitaux (HL7/FHIR)

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:GetVirement xmlns:m="https://banque.fr">
      <m:IBAN>FR76...</m:IBAN>
    </m:GetVirement>
  </soap:Body>
</soap:Envelope>

SOAP garantit : WS-Security (chiffrement + signature XML), WSDL (description du service), transactions ACID via WS-Transaction.

🌍 API REST

Architecture basée sur les ressources et les verbes HTTP. Stateless, cacheable, layered.

Verbe	Action CRUD	Exemple
`GET`	Read	`GET /users/42`
`POST`	Create	`POST /users`
`PUT`	Update complet	`PUT /users/42`
`PATCH`	Update partiel	`PATCH /users/42`
`DELETE`	Delete	`DELETE /users/42`

Codes HTTP clés : 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

📡 GraphQL

Créé par Facebook (2015). Langage de requête côté client — le client choisit exactement les champs qu'il veut. Un seul endpoint (POST /graphql).

Avantages

Pas de sur-/sous-fetching
Schéma typé fort (SDL)
Subscriptions temps-réel intégrées
Introspection du schéma

Inconvénients

Complexité côté serveur (resolvers, N+1)
Cache HTTP difficile
Courbe d'apprentissage

# Requête GraphQL
query {
  user(id: 42) {
    name
    email
    posts {
      title
    }
  }
}

⚡ gRPC (Google RPC)

Basé sur HTTP/2 + Protobuf. 5× à 10× plus rapide que REST+JSON. Supporte le streaming bidirectionnel. Utilisé dans les microservices.

📊 Comparatif des modèles

Critère	REST	GraphQL	gRPC	SOAP
Format	JSON/XML	JSON	Protobuf (binaire)	XML
Transport	HTTP/1.1+	HTTP/1.1+	HTTP/2	HTTP
Contrat	OpenAPI	SDL	.proto	WSDL
Cache HTTP	✅ Natif	⚠️ Difficile	❌	❌
Streaming	❌	Subscriptions	✅ Bidirectionnel	❌
Perf	Moyenne	Moyenne	Très haute	Basse
Usage	Web public	Mobile/SPA	Microservices	Entreprise legacy

🔌

5. WebSocket

WebSocket (RFC 6455) permet une communication bidirectionnelle full-duplex persistante sur une connexion TCP unique. Démarre via un upgrade HTTP.

🔄 Handshake WebSocket (Upgrade HTTP)

# Requête du client (HTTP → WebSocket)
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

# Réponse du serveur
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Après le 101 Switching Protocols, la connexion TCP reste ouverte et les deux parties peuvent s'envoyer des frames à tout moment.

💻 Code WebSocket — Côté Client (JavaScript)

// Connexion au serveur WebSocket
const ws = new WebSocket('wss://mon-serveur.fr/chat');

// Événement : connexion établie
ws.addEventListener('open', (event) => {
    console.log('Connecté au serveur !');
    ws.send(JSON.stringify({
        type: 'message',
        content: 'Bonjour !',
        author: 'Alice'
    }));
});

// Événement : réception d'un message
ws.addEventListener('message', (event) => {
    const data = JSON.parse(event.data);
    console.log(`Message de ${data.author}: ${data.content}`);
});

// Événement : fermeture de connexion
ws.addEventListener('close', (event) => {
    console.log(`Connexion fermée. Code: ${event.code}`);
});

// Événement : erreur
ws.addEventListener('error', (error) => {
    console.error('Erreur WebSocket :', error);
});

// Fermer proprement
// ws.close(1000, 'Au revoir');

🖥️ Code WebSocket — Côté Serveur (Node.js / ws)

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });
const clients = new Set();

wss.on('connection', (ws, req) => {
    clients.add(ws);
    console.log(`Nouveau client : ${req.socket.remoteAddress}`);

    // Réception d'un message
    ws.on('message', (rawData) => {
        const msg = JSON.parse(rawData.toString());

        // Broadcast à tous les clients connectés
        const payload = JSON.stringify({
            ...msg,
            timestamp: new Date().toISOString()
        });

        for (const client of clients) {
            if (client.readyState === WebSocket.OPEN) {
                client.send(payload);
            }
        }
    });

    // Déconnexion
    ws.on('close', () => {
        clients.delete(ws);
        console.log('Client déconnecté');
    });

    // Ping / Keepalive
    ws.on('ping', () => ws.pong());
});

console.log('Serveur WebSocket démarré sur ws://localhost:8080');

Codes de fermeture WebSocket

1000 : Fermeture normale
1001 : Going Away (page fermée)
1006 : Connexion perdue anormalement
1011 : Erreur interne serveur

WebSocket vs HTTP

HTTP : requête-réponse, stateless, connexion fermée après chaque échange
WebSocket : persistant, bidirectionnel, full-duplex
Use cases : chat, jeux, trading, notifications push, collaboration temps-réel

🔐

6. Certificat X.509

Un certificat X.509 est un document numérique standardisé qui lie une clé publique à une identité (personne, organisation, domaine). Il est signé par une Autorité de Certification (CA).

📋 Structure d'un certificat X.509 v3

Version : v3 (le plus courant)
Numéro de série : identifiant unique dans le CA
Algorithme de signature : ex. SHA-256 with RSA, ECDSA
Émetteur (Issuer) : DN du CA (ex. CN=Let's Encrypt R3, O=Let's Encrypt, C=US)
Validité : NotBefore et NotAfter (en UTC)
Sujet (Subject) : DN de l'entité certifiée (ex. CN=www.example.com)
Clé publique : avec son algorithme (RSA 2048 bits, ECDSA P-256...)
Extensions X.509 v3 :
- Subject Alternative Name (SAN) : domaines alternatifs couverts
- Key Usage : usage autorisé (signature, chiffrement...)
- Basic Constraints : CA:TRUE si c'est un cert de CA
- CRL Distribution Points : URL de la liste de révocation
- OCSP : Online Certificate Status Protocol
Signature du CA : chiffré avec la clé privée du CA

🌲 Chaîne de confiance (Chain of Trust)

Root CA (auto-signé, pré-installé dans l'OS/navigateur)
↓ signe
Intermediate CA (ex. R3 de Let's Encrypt)
↓ signe
Certificat feuille (ex. www.monsite.fr)

🔄 TLS Handshake (simplifié TLS 1.3)

ClientHello : versions TLS supportées, cipher suites, client_random, extensions (SNI)
ServerHello : cipher choisi, server_random, envoi du certificat
Vérification : le client vérifie la chaîne de confiance et la validité du certificat
Key Exchange : échange de clés (ECDHE), dérivation des clés de session
Finished : canal chiffré établi

💡 AFNA1 : Dans le contexte AFNA, le certificat X.509 permet l'authentification mutuelle (mTLS) entre clients et serveurs, garantissant la non-répudiation des échanges réseau.

⚠️ Révocation :

CRL (Certificate Revocation List) : liste téléchargeable, peut être volumineuse
OCSP : requête en temps réel — plus rapide mais dépend du CA
OCSP Stapling : le serveur joint lui-même la réponse OCSP dans le handshake TLS

📐

7. Diagramme de Séquence & Logigramme

📊 Diagramme de Séquence (UML)

Représente les interactions chronologiques entre acteurs/objets. Lecture de haut en bas.

Éléments clés

Acteurs (colonnes) : Client, Serveur, BDD, Service externe...
Lifelines : barres verticales de vie de chaque acteur
Messages synchrones ─────▶ (appel bloquant, attend réponse)
Messages asynchrones ───--▷ (fire-and-forget)
Retour ◀- - - - (réponse, trait pointillé)
Alt : bloc conditionnel (if/else)
Loop : répétition
Opt : optionnel
Par : parallèle

Exemple : Requête REST avec auth JWT

Client Auth API Resource API

Client ──── POST /login {user, pwd} ────▶ Auth API

Client ◀- - - { token: "eyJhbG..." } - - - Auth API

Client ──── GET /users/42 [Authorization: Bearer token] ────────────▶ Resource API

Client ◀- - - - - - - - - - 200 OK { user data } - - - - - - - - - - - Resource API

🔀 Logigramme (Flowchart)

Représente un algorithme ou processus avec des décisions (losanges) et des actions (rectangles).

Symboles standards

Ovale : Début / Fin
Rectangle : Action / Traitement
Losange : Décision (Oui/Non)
Parallélogramme : Entrée / Sortie
Flèches : Flux de contrôle

🧮

8. Algorithmique Distribuée — 25 points

Les 7 problématiques classiques des systèmes distribués — ce que vous devez maîtriser pour l'oral.

⏰ 1. Horloges Logiques de Lamport

Permettent d'ordonner les événements dans un système distribué sans horloge globale.

Règles

Chaque processus incrémente son horloge locale à chaque événement interne : L = L + 1
Avant d'envoyer un message : L = L + 1, puis envoyer (msg, L)
À la réception de (msg, L_reçu) : L = max(L_local, L_reçu) + 1

💡 Relation précède (→) : Si a → b, alors L(a) < L(b). Mais L(a) < L(b) n'implique pas a → b (événements concurrents possibles).

🔢 2. Horloges Vectorielles

Chaque processus Pᵢ maintient un vecteur V[1..n]. Permettent de détecter la concurrence (ce que Lamport ne permet pas).

Règles

Événement interne : V[i] = V[i] + 1
Envoi de msg par Pᵢ : V[i] = V[i] + 1, envoyer (msg, V)
Réception par Pⱼ de (msg, V_reçu) : V[k] = max(V[k], V_reçu[k]) pour tout k, puis V[j] = V[j] + 1

Comparaison de vecteurs

V = V' si ∀k : V[k] = V'[k]
V < V' (précède) si ∀k : V[k] ≤ V'[k] ET ∃k : V[k] < V'[k]
Concurrents si ni V < V' ni V' < V (incomparables)

🔒 3. Exclusion Mutuelle Distribuée

Algorithme de Lamport (token-based avec file de priorité)

Chaque processus qui veut entrer en SC envoie REQUEST(ts, i) à tous
Il attend un ACK de tous ET que sa requête soit en tête de sa file locale
À la sortie de SC : envoie RELEASE à tous
Complexité : 3(n-1) messages par accès à la SC

Algorithme de Ricart-Agrawala (optimisé)

Variante : supprime les messages RELEASE explicites
À la sortie : envoie les ACK différés aux processus en attente
Complexité : 2(n-1) messages par accès
Plus efficace mais même garanties d'équité (FIFO sur les timestamps)

Maekawa / Quorum (avancé)

N'interroge qu'un sous-ensemble de processus (quorum). Complexité réduite : ~√n messages.

📸 4. Snapshot Global — Algorithme de Chandy-Lamport

Permet de capturer un état global cohérent d'un système distribué (sans arrêter le système).

Principe

Le processus initiateur enregistre son état local et envoie un marqueur (MARKER) sur tous ses canaux sortants
Un processus recevant un marqueur pour la première fois sur le canal C_ij :
- Enregistre son état local
- Enregistre l'état du canal C_ij comme vide
- Envoie un marqueur sur tous ses canaux sortants
Pour les autres canaux entrants : enregistre tous les messages reçus entre le début du snapshot et la réception du marqueur

💡 Hypothèse : Canaux FIFO obligatoires. Le snapshot est cohérent (aucun message "fantôme" ne manque).

📡 5. Diffusion — Totale vs Causale

📢

Diffusion Totalement Ordonnée (Atomic Broadcast)

Tous les processus reçoivent tous les messages dans le même ordre total — même des messages sans relation causale.

Garantit la cohérence forte
Implémentée via Paxos, Raft, ZooKeeper...
Utilisation : base de données distribuée, blockchain

🔗

Diffusion Causalement Ordonnée (Causal Broadcast)

Si l'envoi de m1 précède causalement l'envoi de m2, alors tous les processus reçoivent m1 avant m2. Les messages sans relation causale peuvent être reçus dans n'importe quel ordre.

Moins coûteux que la diffusion totale
Implémentée via horloges vectorielles
Utilisation : réseaux sociaux, forums

⚠️ Différence fondamentale :

Diffusion totale : ordre global sur tous les messages, même non liés causalement → plus fort, plus coûteux
Diffusion causale : respecte uniquement les relations cause-effet → cohérent avec la causalité, mais deux processus peuvent voir des messages non causaux dans des ordres différents

Exemple : m1 "Bonjour" et m2 "Réponse à m1" → la diffusion causale garantit que tout le monde voit m1 avant m2. Mais si m3 est indépendant, il peut arriver avant ou après m1/m2 selon les processus.

🏁 6. Détection de Terminaison — Algorithme de Dijkstra-Scholten

Détecte quand un calcul distribué est terminé (tous les processus inactifs, aucun message en transit).

Construit un arbre couvrant dynamique des processus actifs
Un processus devient "déficit 0" quand il n'a plus de messages en attente
Les feuilles de l'arbre se retirent en envoyant un signal au parent
L'initiateur détecte la terminaison quand tous ses enfants se sont retirés

👑 7. Élection de Leader

Algorithme de Chang-Roberts (anneau)

Chaque nœud envoie son ID dans le sens de l'anneau
Un nœud transmet un ID uniquement s'il est supérieur au sien
Le nœud qui reçoit son propre ID est élu leader
Complexité : O(n log n) messages en moyenne, O(n²) au pire

Algorithme du Bully (réseau complet)

Un nœud qui détecte l'absence du leader envoie ELECTION à tous les nœuds d'ID supérieur
Le plus grand ID répond OK et démarre une nouvelle élection
S'il n'y a pas de réponse → ce nœud devient leader
Envoie COORDINATOR à tous

📊 Récapitulatif des algorithmes

Algorithme	Problème résolu	Mécanisme clé	Complexité
Lamport (horloges)	Ordre causal des événements	max(local, reçu) + 1	O(1) par message
Horloges vectorielles	Causalité + concurrence	Vecteur max composante par composante	O(n) par message
Ricart-Agrawala	Exclusion mutuelle	Timestamps + ACK différés	2(n-1) messages
Chandy-Lamport	Snapshot global cohérent	Marqueurs sur canaux FIFO	O(e) messages (e = nb d'arêtes)
Diffusion totale	Cohérence forte	Paxos / Raft / séquenceur	O(n²) messages
Diffusion causale	Cohérence causale	Horloges vectorielles	O(n) par message
Chang-Roberts	Élection (anneau)	Propagation du max ID	O(n log n) moy.