#Modèle TCP/IPCopier le lien

Le modèle TCP/IP est un ensemble de protocoles de communication qui permet l'interconnexion de réseaux hétérogènes. Il est organisé en quatre couches principales.

Objectifs d'apprentissage

• Expliquer l'encapsulation entre couches et l'adressage (IP, ports).
• Différencier TCP et UDP (fiabilité, ordre, congestion) et savoir quand utiliser l'un ou l'autre.
• Comprendre MTU/MSS, fragmentation et Path MTU Discovery (PMTUD).
• Décrire le 3-way handshake, les flags TCP et les états de fermeture.

#Couches du modèle TCP/IPCopier le lien

#1. Couche ApplicationCopier le lien

• Protocoles : HTTP, FTP, SMTP, DNS, etc.
• Responsabilités : Fournir des services réseau aux applications utilisateur.

#2. Couche TransportCopier le lien

• Protocoles : TCP (fiable) et UDP (rapide).
• Responsabilités :
  • TCP : Contrôle de flux, correction d'erreurs, segmentation.
  • UDP : Transmission rapide sans garantie.

#3. Couche Internet (IP)Copier le lien

• Protocole principal : IP (IPv4/IPv6).
• Responsabilités : Routage des paquets entre réseaux, adressage logique.

#4. Couche Lien (ou Accès réseau)Copier le lien

• Protocoles : Ethernet, WiFi, PPP, etc.
• Responsabilités : Transmission physique, adressage matériel (MAC).

#EncapsulationCopier le lien

L'encapsulation est le processus par lequel chaque couche ajoute ses propres en-têtes aux données reçues de la couche supérieure.

1. Données applicatives (message)
2. Couche Transport : Ajout en-tête TCP/UDP, le segment
3. Couche Internet : Ajout en-tête IP, le paquet
4. Couche Lien : Ajout en-tête Ethernet, la trame
5. Transmission sur le support physique : les bits

Tailles réelles pour une requête HTTP typique sur Ethernet: en-tête Ethernet 14 octets, IP 20, TCP 20, HTTP plusieurs centaines. Sur un MTU de 1500, il reste 1460 octets utiles par segment TCP: c'est la MSS.

#TCP en bref: fiabilité et contrôle de congestionCopier le lien

• Handshake à 3 temps: SYN, SYN-ACK, ACK. Fermeture: FIN/ACK et états (TIME_WAIT, CLOSE_WAIT).
• Séquencement: numéro de séquence/ack; retransmission sur timeout (RTO) et Fast Retransmit (dupACKs).
• Contrôle de flux: fenêtre (rwnd). Contrôle de congestion: slow start, congestion avoidance (cwnd).
• Flags: SYN (ouverture), ACK (accusé), FIN (fermeture), RST (réinitialisation), PSH/URG (peu utilisés aujourd'hui).

#Diagramme: 3-way handshake et fermetureCopier le lien

#Animation: contrôle de congestion TCPCopier le lien

#MTU, MSS et fragmentationCopier le lien

• MTU (Ethernet typique 1500 octets): taille maximale d'une trame L2.
• MSS: taille utile TCP maximale (MTU moins les en-têtes IP/TCP, soit 1460 pour IPv4 sur Ethernet). Trop grande, elle entraîne fragmentation IP si DF=0, sinon un ICMP « Fragmentation needed » avec PMTUD.
• Recommandation: éviter la fragmentation; PMTUD ajuste la MSS; attention aux pare-feux qui bloquent ICMP, cause de « black hole ».

#Ports, NAT et étatCopier le lien

• Ports: identifient les processus (TCP/UDP). Paires {IP src, port src, IP dst, port dst} définissent un flux.
• NAT: traduit adresses et ports; garde un état (table); timeouts différents TCP/UDP.
• Effet: le serveur ne peut pas initier de connexion vers un client NATé; attention au keep-alive.

#États de fermeture (aperçu)Copier le lien

• TIME_WAIT côté qui envoie le dernier ACK (double de MSL); évite que d'anciens segments ne perturbent une nouvelle connexion.
• CLOSE_WAIT quand l'app n'a pas encore fermé après réception de FIN; souvent signe d'app qui ne close() pas.

#Lab: observer un handshake réelCopier le lien

Sur votre machine, capturez l'ouverture d'une connexion et lisez les numéros:

1# Ouvrir une connexion TCP et la capturer en une commande2sudo tcpdump -ni any 'tcp port 80 and host 93.184.216.34' &3curl -s http://93.184.216.34/ > /dev/null

Trace attendue (adresses et numéros varient):

1IP 192.168.1.23.45812 > 93.184.216.34.80: Flags [S], seq 1234567890, win 64240, length 02IP 93.184.216.34.80 > 192.168.1.23.45812: Flags [S.], seq 987654321, ack 1234567891, win 65535, length 03IP 192.168.1.23.45812 > 93.184.216.34.80: Flags [.], ack 987654322, length 0

Observations à relever: (1) trois lignes, S, S., . (le point seul signifie ACK); (2) le ack du serveur vaut le seq client plus un, et réciproquement: c'est le comptage d'octets en base relative; (3) le client choisit un port source élevé aléatoire, le serveur reste sur 80. Le flag R (reset) à la place de cette séquence signale un refus immédiat: port fermé ou pare-feu.

#Diagnostic: trois échecs TCP typiques et leur signatureCopier le lien

• SYN sans réponse (tcpdump montre des S répétés, jamais de S.): le paquet n'atteint pas un port ouvert; soit filtré (pare-feu silencieux), soit l'hôte est injoignable. ping puis traceroute distinguent routage et filtrage.
• RST immédiat (Flags [R.] dès le SYN): un processus écoute ailleurs ou pas du tout; le port est fermé mais joignable. C'est une réponse, donc la couche IP fonctionne.
• Connexion qui gèle après le handshake (les trois lignes passent puis plus rien): MTU/PMTUD cassé; les petits paquets passent, les gros sont perdus. Testez avec ping -M do -s 1472 <hôte> (1472 + 28 d'en-têtes = 1500): si cette taille échoue alors que 1400 passe, le chemin a un MTU inférieur.

#Quiz éclairCopier le lien

#Exercice : Simulation d'encapsulation/décapsulationCopier le lien

Simulez le processus d'encapsulation et de décapsulation d'un message à travers les couches TCP/IP, avec vérification automatique de l'aller-retour.

#InstructionsCopier le lien

1. Représentez chaque couche par une fonction qui préfixe son en-tête à l'émission et le retire à la réception.
2. Ordonnez les couches dans deux listes (émission, réception) et appliquez-les en séquence.
3. Vérifiez que le message décodé est identique à l'original, et que les en-têtes retirés correspondent, dans l'ordre inverse, aux en-têtes ajoutés.

#PlaygroundCopier le lien

Sortie attendue: la trame vaut [ETH][IP][TCP][DATA]Bonjour, ceci est un test! (la couche Lien enveloppe tout), le décodage retire les en-têtes en ordre inverse, et la dernière ligne affiche True. L'assertion échoue si une couche retire le mauvais en-tête: c'est exactement le symptôme d'un démultiplexage raté dans une vraie pile.

Exercice d'extension (corrigé): ajoutez la couche TLS entre Transport et Application. Correction: insérez ("TLS", "[TLS]") dans COUCHES juste après la couche Application; à l'émission, l'en-tête TLS se retrouve entre [TCP] et [DATA], et le décodage le retire au bon niveau. Chiffrer réellement consisterait à transformer le contenu plutôt qu'à ajouter un préfixe, mais l'ordre d'emboîtement est le même.