#Réseaux & WebCopier le lien

Cette section construit une compréhension pratique d’Internet et du Web: que transportent les paquets, comment ils sont acheminés, pourquoi choisir TCP plutôt qu’UDP, comment HTTP a évolué vers HTTP/3, et comment sécuriser et accélérer un site ou une API.

Contexte pédagogique: niveau L2 (Valrose — UCA). L’objectif est d’acquérir des réflexes de diagnostic et des bases solides pour comprendre les couches applicatives (HTTP) et les implications de performance/sécurité.

#Pile TCP/IP (rappel)Copier le lien

La pile réseau se décompose en couches qui isolent les responsabilités:

• Liaison (Ethernet/Wi‑Fi): transporte des trames sur un lien local. C’est ici que vivent les adresses MAC et les collisions radio.
• Réseau (IP): adresse et route les paquets entre réseaux. Le CIDR et les tables de routage décident de l’itinéraire.
• Transport (TCP/UDP): fournit un canal d’échange pour les applications, fiable (TCP) ou non (UDP).
• Application (HTTP, DNS, …): les protocoles “métier” qui portent vos données applicatives.

En pratique, diagnostiquer un problème réseau consiste à remonter cette pile: ping vérifie l’accessibilité IP, traceroute expose les sauts (routing), nslookup/dig teste la résolution DNS, et ip route montre comment la machine décide d’acheminer un paquet.

#TCP vs UDPCopier le lien

TCP offre une communication fiable: il numérote, accuse réception (ACK) et retransmet si besoin. Il régule le débit (fenêtre glissante) et s’adapte à la congestion (AIMD). On le choisit pour les pages web, les APIs, ou tout flux qui ne doit pas perdre d’octets.

UDP envoie des datagrammes “bruts” sans garantie. Il réduit la latence et le coût de contrôle, idéal pour la voix, la vidéo en temps réel, ou les jeux. Des protocoles modernes (QUIC) bâtissent par‑dessus UDP leur propre fiabilité adaptée aux usages.

#HTTP: du 1.1 au 3Copier le lien

• HTTP/1.1 garde des connexions ouvertes, mais souffre du blocage de tête de ligne au niveau TCP: une réponse lente retarde les suivantes.
• HTTP/2 multiplexe plusieurs requêtes sur une seule connexion, compresse les en‑têtes (HPACK) et permet de prioriser. Résultat: moins de connexions, plus d’efficacité.
• HTTP/3 repose sur QUIC (UDP). Il supprime le blocage de tête de ligne, supporte le 0‑RTT et la migration de connexion (utile en mobilité). À l’usage: meilleures latences et résilience.

Savoir quelle version est négociée aide à interpréter les performances et à choisir une configuration serveur appropriée.

#TLS et PKI (HTTPS)Copier le lien

TLS chiffre le trafic et authentifie le serveur via la chaîne de certificats (PKI). Le “handshake” négocie les algorithmes, échange des clés (ECDHE) puis bascule en trafic chiffré. Concrètement, vous évitez l’espionnage (confidentialité) et l’altération (intégrité), tout en sachant à qui vous parlez (authenticité).

Bonnes pratiques: rediriger vers HTTPS, activer HSTS une fois prêt, utiliser des suites modernes et surveiller l’expiration des certificats. Les erreurs de certification (nom, CA, date) doivent être traitées comme des incidents sérieux.

#Animation: handshake TLS (vue simplifiée)Copier le lien

#Caching et performanceCopier le lien

Le cache diminue la charge serveur et le temps d’affichage. Côté client et CDN, Cache-Control définit la fraîcheur; ETag/If-None-Match et Last-Modified/If-Modified-Since permettent la revalidation. Vary précise quels en‑têtes influencent la clé de cache (ex.: Accept-Language).

Un CDN rapproche le contenu de l’utilisateur, sert les assets statiques et absorbe des pics. On invalide par chemin/étiquette et on fingerprint les fichiers (hash) pour des mises à jour sûres. Compressez (gzip/brotli) et réduisez les requêtes critiques pour améliorer le TTFB et le LCP.

#DNS en pratiqueCopier le lien

DNS traduit des noms en adresses. Les enregistrements A/AAAA pointent vers des IP, CNAME crée des alias, MX définit la messagerie, TXT véhicule des métadonnées (SPF, vérifications). Le TTL contrôle la durée de mise en cache; des TTL trop bas augmentent la charge, trop hauts ralentissent les bascules.

Comprendre la récursion et la propagation aide à planifier des déploiements sans coupure et à diagnostiquer des “incohérences” pendant les changements.

#Exercices guidésCopier le lien

• Inspectez la négociation HTTP/2/3 d’un site avec curl -I --http3 et identifiez les en‑têtes utiles (cache, sécurité).
• Paramétrez un endpoint JSON avec ETag et montrez la revalidation 304 côté client.
• Créez un sous‑domaine et testez sa résolution avec dig, en observant l’effet du TTL.

Astuce: conservez vos commandes et résultats dans un petit journal (fichier .md). Cela vous permet de comparer avant/après et d’expliquer vos choix.

#Quiz rapideCopier le lien

• Quel protocole sous‑jacent transporte HTTP/3 ? Réponse: QUIC (sur UDP).
• Quel header valide une réponse en cache côté client ? Réponse: ETag via If-None-Match.