The Transport Layer
Comprends le rôle de la couche Transport, les protocoles TCP et UDP, le mécanisme du three-way handshake, les numéros de ports et comment les données sont acheminées de manière fiable à travers le réseau.
- Expliquer le rôle de la couche Transport (segmentation, multiplexage, fiabilité)
- Décrire TCP, son en-tête et le three-way handshake
- Décrire UDP, son en-tête et ses cas d'usage
- Comparer TCP et UDP et savoir quand utiliser chacun
- Identifier les plages de ports et les ports importants à connaître
🚚 8.1 — Rôle de la couche Transport
La couche Transport (Layer 4 du modèle OSI) est responsable de la communication logique de bout en bout (end-to-end) entre les applications sur des hôtes différents. Elle ne se soucie pas du chemin physique emprunté par les données — c'est le travail des couches inférieures. La couche Transport s'assure que les données arrivent correctement à la bonne application.
Imagine un bureau de poste. Quand tu envoies un gros colis, le bureau de poste le découpe en plusieurs paquets numérotés (segmentation), s'assure que chaque paquet porte l'adresse de l'expéditeur et du destinataire (multiplexage), et le destinataire peut vérifier qu'il a bien reçu tous les paquets et les remettre dans l'ordre (fiabilité). La couche Transport est ce bureau de poste pour les données numériques.
Les fonctions principales
| Fonction | Description | Analogie |
|---|---|---|
| Segmentation | Découpe les données en segments (TCP) ou datagrammes (UDP) de taille adaptée au réseau | Couper un livre en chapitres pour l'envoyer par la poste |
| Multiplexage | Permet à plusieurs applications d'utiliser le réseau simultanément grâce aux numéros de ports | Plusieurs boîtes aux lettres dans un même immeuble (chaque port = une boîte) |
| Réassemblage | Remet les segments dans le bon ordre à destination | Reclasser les chapitres du livre dans l'ordre à la réception |
| Contrôle de flux (Flow Control) |
Régule la vitesse d'envoi pour éviter de surcharger le récepteur | Parler moins vite si ton interlocuteur ne comprend pas |
| Fiabilité (TCP uniquement) |
Garantit la livraison complète, dans l'ordre, sans erreur ni duplication | Accusé de réception pour chaque colis envoyé |
Identification des conversations : Socket et Socket Pair
Un socket est la combinaison d'une adresse IP et d'un numero de port, note IP:Port. Il identifie de maniere unique un endpoint de communication sur un hote. Une socket pair (paire de sockets) identifie de maniere unique une conversation complete entre deux processus et se compose de 5 elements (5-tuple) : protocole, IP source, port source, IP destination, port destination.
IP source : 192.168.1.10 (adresse de l'hôte client)
Port source : 49152 (port dynamique attribué à l'application)
IP destination : 93.184.216.34 (adresse du serveur)
Port destination : 443 (HTTPS — port bien connu)
🔗 8.2 — TCP (Transmission Control Protocol)
TCP est un protocole de transport orienté connexion (connection-oriented) et fiable (reliable). Il garantit que toutes les données arrivent complètes, dans l'ordre et sans erreur. C'est le protocole le plus utilisé sur Internet (HTTP, HTTPS, SSH, FTP, SMTP, etc.).
Caractéristiques de TCP
| Caractéristique | Description |
|---|---|
| Connection-oriented | Établit une connexion (three-way handshake) avant d'envoyer des données |
| Reliable delivery | Accusés de réception (ACK) pour chaque segment reçu |
| Ordered delivery | Numéros de séquence pour remettre les segments dans l'ordre |
| Flow control | Window size pour réguler le débit d'envoi |
| Error detection | Checksum pour détecter les erreurs de transmission |
| Retransmission | Les segments non acquittés sont retransmis automatiquement |
| Full-duplex | Communication bidirectionnelle simultanée |
TCP, c'est comme un appel téléphonique. Avant de parler, tu décroches et tu vérifies que ton interlocuteur est là ("Allô ?" — "Oui, je t'écoute" — "OK, je commence"). Pendant la conversation, si l'autre ne comprend pas, il demande de répéter. Et à la fin, vous vous dites au revoir avant de raccrocher. C'est exactement le fonctionnement de TCP.
En-tête TCP (TCP Header) — 20 octets minimum, 60 octets maximum
L'en-tête TCP contient 10 champs obligatoires totalisant 20 octets (160 bits) minimum, plus un champ Options variable pouvant aller jusqu'à 40 octets supplémentaires. Chaque champ a un role precis :
Source Port (16 bits) : identifie l'application emettrice (souvent un port dynamique, ex: 49152). Valeur de 0 a 65535.
Destination Port (16 bits) : identifie l'application receptrice (souvent un port bien connu, ex: 80 pour HTTP).
Ensemble, les ports source et destination + les adresses IP forment un socket pair qui identifie la connexion de maniere unique.
Numero de sequence du premier octet de donnees dans ce segment.
Utilise pour reordonner les segments a destination et detecter les segments manquants.
Lors du SYN initial, c'est l'ISN (Initial Sequence Number) — un nombre aleatoire pour la securite.
Espace de numerotation : 0 a 2^32 - 1 (4 294 967 295), puis rebouclage (wrap-around).
Numero du prochain octet attendu par le recepteur.
Ex : si ACK = 1001, cela signifie "J'ai bien recu tous les octets jusqu'a 1000, envoie-moi a partir de 1001".
C'est le mecanisme fondamental de la livraison fiable de TCP.
Ce champ n'est valide que si le flag ACK est active (= 1).
Data Offset (4 bits) : taille de l'en-tete TCP en mots de 32 bits. Minimum = 5 (20 octets), Maximum = 15 (60 octets).
Reserved (3 bits) : reserve pour usage futur, doit etre a 0.
Flags / Control Bits (9 bits) — 9 drapeaux de controle (du bit 103 au bit 111) :
| Bit | Flag | Nom complet | Role |
|---|---|---|---|
| 103 | NS | ECN-nonce | Nonce Sum — protection experimentale contre le masquage ECN (RFC 3540) |
| 104 | CWR | Congestion Window Reduced | Indique que l'emetteur a reduit sa fenetre de congestion apres reception d'un segment ECE |
| 105 | ECE | ECN-Echo | Signale la congestion detectee par le reseau (Explicit Congestion Notification). Pendant le handshake, indique le support ECN |
| 106 | URG | Urgent | Indique que le champ Urgent Pointer est valide — les donnees urgentes doivent etre traitees en priorite |
| 107 | ACK | Acknowledgment | Confirme la reception de donnees — le champ Acknowledgment Number est valide |
| 108 | PSH | Push | Demande au recepteur de transmettre immediatement les donnees en buffer a l'application sans attendre |
| 109 | RST | Reset | Reinitialise (coupe) brutalement la connexion — pas de negociation |
| 110 | SYN | Synchronize | Initie une connexion, synchronise les numeros de sequence (ISN) |
| 111 | FIN | Finish | Demande la fermeture gracieuse de la connexion — plus de donnees a envoyer |
Taille de la fenetre de reception (en octets) : quantite de donnees que le recepteur peut accepter avant de recevoir un accuse de reception.
Valeur maximale brute : 65 535 octets (2^16 - 1). Avec Window Scaling (option), la fenetre peut atteindre jusqu'a 1 Go.
C'est le mecanisme de controle de flux (flow control) de TCP.
Une fenetre de 0 signifie "Stop ! Je suis sature, ne m'envoie plus rien pour l'instant." (Zero Window).
Checksum (16 bits) : verifie l'integrite de l'en-tete, des donnees et d'un pseudo-header (IP source, IP dest, protocole, longueur TCP). Obligatoire en TCP. Si le checksum ne correspond pas, le segment est silencieusement rejete.
Urgent Pointer (16 bits) : utilise uniquement si le flag URG est active. Indique l'offset de la fin des donnees urgentes par rapport au Sequence Number.
Champ optionnel pour des fonctionnalites avancees. Doit etre un multiple de 32 bits (padding si necessaire) :
MSS (Maximum Segment Size — Kind 2) : taille maximale d'un segment de donnees (typiquement 1460 octets sur Ethernet). Negocie lors du handshake SYN.
Window Scaling (Kind 3) : facteur multiplicateur (shift count 0-14) pour la Window Size. Permet des fenetres jusqu'a 2^30 octets (~1 Go). Negocie lors du handshake.
SACK Permitted (Kind 4) + SACK (Kind 5) : Selective ACK — permet d'acquitter des blocs non contigus (optimise la retransmission en evitant de tout retransmettre).
Timestamps (Kind 8) : mesure le RTT (Round-Trip Time) pour ajuster les timeouts de retransmission (RTO). Contient TSval et TSecr.
NOP (Kind 1) : No-Operation, utilise pour l'alignement des options.
Taille maximale : 60 octets (480 bits) = 20 octets fixes + 40 octets d'options.
Nombre total de champs : Source Port (16b) + Dest Port (16b) + Seq Number (32b) + Ack Number (32b) + Data Offset (4b) + Reserved (3b) + Flags (9b) + Window Size (16b) + Checksum (16b) + Urgent Pointer (16b) + Options (variable) = 160 bits minimum.
🤝 8.3 — Three-Way Handshake (Établissement de connexion TCP)
Avant de pouvoir échanger des données, TCP doit d'abord établir une connexion entre le client et le serveur. Ce processus s'appelle le three-way handshake (poignée de main en trois étapes).
C'est comme un appel téléphonique :
1. Tu décroches et tu dis : "Allô, c'est moi !" (SYN)
2. L'autre répond : "Oui je t'entends, et toi tu m'entends ?" (SYN-ACK)
3. Tu confirmes : "Oui je t'entends aussi, on peut parler !" (ACK)
La conversation peut commencer.
Les 3 étapes détaillées
Le client envoie un segment avec le flag SYN = 1.
Il choisit un ISN (Initial Sequence Number) aléatoire, ex : Seq = 100.
Message : "Je veux établir une connexion. Mon numéro de séquence initial est 100."
Flags : SYN=1, ACK=0
Seq = 100 | Ack = 0
Le serveur répond avec les flags SYN = 1 et ACK = 1.
Il choisit son propre ISN, ex : Seq = 300.
Il acquitte le SYN du client : Ack = 101 (ISN du client + 1).
Message : "J'accepte ta connexion. Mon numéro de séquence initial est 300. J'ai bien reçu ton SYN."
Flags : SYN=1, ACK=1
Seq = 300 | Ack = 101
Le client envoie un segment avec le flag ACK = 1.
Seq = 101 (ISN + 1) et Ack = 301 (ISN du serveur + 1).
Message : "OK, connexion confirmée. J'ai bien reçu ton SYN-ACK."
Flags : SYN=0, ACK=1
Seq = 101 | Ack = 301
La connexion est ESTABLISHED. Le transfert de données peut commencer.
Visualisation du handshake
👋 8.4 — TCP Termination (Fermeture de connexion)
TCP offre deux méthodes pour fermer une connexion : la fermeture gracieuse (four-way handshake avec FIN/ACK) et la fermeture brutale (RST).
Fermeture gracieuse — Four-Way Handshake (FIN/ACK)
Chaque côté de la connexion TCP doit être fermé indépendamment. La fermeture gracieuse utilise le flag FIN et nécessite 4 segments :
Le client envoie un segment avec FIN = 1.
Message : "J'ai fini d'envoyer des données, je veux fermer ma direction."
Le serveur acquitte la demande de fermeture avec ACK = 1.
Message : "OK, j'ai bien noté que tu as fini. Mais moi, je peux encore envoyer des données."
La connexion est maintenant en état half-close (semi-fermée).
Quand le serveur a fini aussi, il envoie son propre FIN = 1.
Message : "Moi aussi j'ai fini, on peut fermer complètement."
Le client acquitte le FIN du serveur avec ACK = 1.
La connexion est maintenant complètement fermée (CLOSED).
Le client entre en état TIME-WAIT pendant quelques secondes avant de libérer le port.
Fermeture brutale — RST (Reset)
RST — Réinitialisation de connexion
Fermeture immédiate, sans négociation
Un segment RST (Reset) coupe immédiatement la connexion sans le processus de FIN/ACK. Il est envoyé dans les cas suivants :
- Port fermé : une demande de connexion arrive sur un port où aucune application n'écoute
- Connexion abandonnée : une application décide d'annuler une connexion en cours
- Segment invalide : réception d'un segment qui ne correspond à aucune connexion connue
- Timeout : absence prolongée de réponse (l'hôte distant est probablement hors ligne)
🔄 8.4b — TCP States (Etats d'une connexion TCP)
Une connexion TCP passe par differents etats au cours de sa vie. Ces etats sont visibles avec la commande netstat ou ss. Connaitre ces etats est essentiel pour le diagnostic reseau et la cybersecurite.
Les 11 etats TCP (RFC 793)
| Etat | Description | Cote |
|---|---|---|
| CLOSED | Pas de connexion. Etat initial et final. Aucune ressource allouee. | Les deux |
| LISTEN | Le serveur attend des connexions entrantes sur un port (socket passive). Pret a recevoir un SYN. | Serveur |
| SYN-SENT | Le client a envoye un SYN et attend le SYN-ACK du serveur. | Client |
| SYN-RECEIVED | Le serveur a recu le SYN et a envoye un SYN-ACK. Attend le ACK final du client. | Serveur |
| ESTABLISHED | Connexion ouverte et active. Les deux cotes peuvent envoyer et recevoir des donnees. Etat normal de transfert. | Les deux |
| FIN-WAIT-1 | L'hote a envoye un FIN pour initier la fermeture. Attend l'ACK ou le FIN du pair. | Initiateur de fermeture |
| FIN-WAIT-2 | Le FIN a ete acquitte (ACK recu). Attend le FIN de l'autre cote. | Initiateur de fermeture |
| CLOSE-WAIT | Un FIN a ete recu et acquitte. L'application locale n'a pas encore ferme de son cote. L'hote peut encore envoyer des donnees. | Recepteur du FIN |
| CLOSING | Les deux cotes ont envoye un FIN simultanement (cas rare). Attend l'ACK du pair. | Les deux |
| LAST-ACK | L'hote en CLOSE-WAIT a envoye son propre FIN. Attend l'ACK final avant de fermer. | Recepteur du FIN |
| TIME-WAIT | Le dernier ACK a ete envoye. L'hote attend 2 x MSL (Maximum Segment Lifetime, typiquement 60s) avant de liberer le port. Permet aux segments retardes d'expirer et garantit que le dernier ACK est bien recu. | Initiateur de fermeture |
Serveur : CLOSED → (socket passive ouverte) → LISTEN → (recu SYN, envoye SYN-ACK) → SYN-RECEIVED → (recu ACK) → ESTABLISHED
Client : CLOSED → (envoye SYN) → SYN-SENT → (recu SYN-ACK, envoye ACK) → ESTABLISHED
Initiateur : ESTABLISHED → (envoye FIN) → FIN-WAIT-1 → (recu ACK) → FIN-WAIT-2 → (recu FIN, envoye ACK) → TIME-WAIT → (timeout 2xMSL) → CLOSED
Recepteur : ESTABLISHED → (recu FIN, envoye ACK) → CLOSE-WAIT → (envoye FIN) → LAST-ACK → (recu ACK) → CLOSED
Un SYN flood remplit la file de connexions en etat SYN-RECEIVED sur le serveur, empechant les connexions legitimes. Les SYN cookies sont une defense contre cette attaque.
De nombreuses connexions en CLOSE-WAIT indiquent un probleme applicatif (l'application ne ferme pas ses sockets). De nombreuses connexions en TIME-WAIT sont normales sur un serveur tres sollicite.
🌊 8.4c — TCP Flow Control et Congestion Control
TCP utilise deux mecanismes distincts pour reguler le debit : le controle de flux (flow control) protege le recepteur, et le controle de congestion (congestion control) protege le reseau.
Flow Control — Controle de flux (Sliding Window)
Le controle de flux empeche l'emetteur de submerger le recepteur. Il repose sur le mecanisme de fenetre glissante (Sliding Window) :
Sliding Window (Fenetre glissante)
Mecanisme de controle de flux de TCP
- Window Size : chaque segment TCP contient un champ Window Size (16 bits) indiquant combien d'octets le recepteur peut encore accepter dans son buffer
- Fenetre glissante : l'emetteur peut envoyer plusieurs segments sans attendre d'ACK, tant que le volume total n'excede pas la Window Size du recepteur
- Zero Window : quand le recepteur envoie Window = 0, l'emetteur s'arrete et envoie periodiquement des Window Probes (segments de 1 octet) pour verifier si la fenetre s'est rouverte
- Window Update : quand le buffer du recepteur se vide (l'application consomme les donnees), il envoie un ACK avec une nouvelle Window Size plus grande
Window Scaling (RFC 7323)
Extension pour les reseaux a haute capacite
- Le champ Window Size de 16 bits limite la fenetre a 65 535 octets (64 Ko) — insuffisant pour les liens haut debit a haute latence
- Window Scale Option : negocie lors du SYN/SYN-ACK un facteur de decalage (shift count) de 0 a 14
- La fenetre reelle = Window Size x 2^(scale factor)
- Avec un scale factor de 14 : fenetre max = 65535 x 2^14 = 1 073 725 440 octets (~1 Go)
- Exemple : Window Size = 5840, Scale = 7 → fenetre effective = 5840 x 128 = 747 520 octets
Congestion Control — Controle de congestion
Le controle de congestion empeche l'emetteur de surcharger le reseau (routeurs intermediaires). TCP utilise une fenetre de congestion (Congestion Window, cwnd) distincte de la fenetre de reception. Le debit reel est limite par : min(cwnd, rwnd).
Quand une connexion TCP s'ouvre, cwnd commence a 1 MSS (Maximum Segment Size, ~1460 octets).
A chaque ACK recu, cwnd augmente de 1 MSS → la fenetre double a chaque RTT (croissance exponentielle).
Progression : 1 MSS → 2 MSS → 4 MSS → 8 MSS → 16 MSS → ...
Le slow start continue jusqu'a atteindre le seuil ssthresh (slow start threshold), puis passe en congestion avoidance.
En cas de perte detectee par timeout : cwnd revient a 1 MSS et ssthresh = cwnd/2.
Une fois cwnd >= ssthresh, TCP passe en mode congestion avoidance.
cwnd augmente de 1 MSS par RTT (au lieu de doubler) → croissance lineaire.
Plus prudent : l'emetteur sonde progressivement la capacite du reseau sans provoquer de congestion.
En cas de perte (timeout) : retour au slow start (cwnd = 1 MSS, ssthresh = cwnd/2).
Quand le recepteur recoit un segment hors sequence, il renvoie immediatement un ACK duplique (duplicate ACK) pour le dernier segment recu dans l'ordre.
Si l'emetteur recoit 3 ACK dupliques consecutifs pour le meme numero de sequence, il retransmet immediatement le segment manquant sans attendre le timeout.
C'est beaucoup plus rapide que d'attendre l'expiration du timer de retransmission (RTO).
Apres un fast retransmit (3 duplicate ACKs), TCP ne retourne pas en slow start. A la place :
ssthresh = cwnd / 2
cwnd = ssthresh + 3 MSS (pour les 3 duplicate ACKs)
Puis reprise en congestion avoidance (croissance lineaire).
Le retour au slow start n'a lieu que lors d'un timeout (perte plus severe).
Slow Start : cwnd double a chaque RTT (exponentiel) jusqu'a ssthresh → Congestion Avoidance : cwnd +1 MSS par RTT (lineaire).
3 duplicate ACKs → Fast Retransmit + Fast Recovery (cwnd = ssthresh + 3, pas de retour a 1).
Timeout → retour au Slow Start (cwnd = 1 MSS, ssthresh = cwnd/2). C'est la reaction la plus agressive.
⚡ 8.5 — UDP (User Datagram Protocol)
UDP est un protocole de transport sans connexion (connectionless) et non fiable (unreliable). Il n'établit pas de connexion, ne garantit pas la livraison et ne réordonne pas les segments. En contrepartie, il est beaucoup plus rapide et consomme moins de ressources que TCP.
UDP, c'est comme envoyer une carte postale. Tu l'écris, tu la mets dans la boîte aux lettres, et c'est fini. Tu ne sais pas si elle arrivera, dans quel ordre elle sera lue, ni si le destinataire la recevra. Mais c'est rapide et simple. Parfois, la vitesse compte plus que la garantie.
Caractéristiques d'UDP
| Caractéristique | Description |
|---|---|
| Connectionless | Pas de handshake — les données sont envoyées immédiatement |
| Unreliable | Pas d'accusé de réception, pas de retransmission |
| Unordered | Pas de numéro de séquence — les datagrammes peuvent arriver dans le désordre |
| Lightweight | En-tête de seulement 8 octets (vs 20-60 pour TCP) |
| Fast | Pas de délai d'établissement de connexion, overhead minimal |
| No flow control | L'émetteur envoie à sa vitesse sans se soucier du récepteur |
En-tete UDP — 8 octets fixes exactement (64 bits)
L'en-tete UDP contient exactement 4 champs de 16 bits chacun = 64 bits = 8 octets. Pas d'options, pas de variabilite. C'est ce qui lui confere sa rapidite :
Source Port (16 bits) : identifie l'application emettrice. Optionnel — peut etre mis a 0 si aucune reponse n'est attendue (ex : syslog). Utilise pour le multiplexage et pour permettre au destinataire de repondre.
Destination Port (16 bits) : identifie l'application receptrice. Obligatoire. Memes plages que TCP (0-65535).
Length (16 bits) : taille totale du datagramme UDP (en-tete + donnees), en octets. Minimum : 8 octets (en-tete seul, sans donnees). Maximum theorique : 65 535 octets (2^16 - 1), mais limite en pratique par le MTU.
Checksum (16 bits) : verifie l'integrite du datagramme (en-tete + donnees + pseudo-header IP). Optionnel en IPv4 (valeur 0 = pas de checksum), obligatoire en IPv6. Le pseudo-header inclut IP source, IP destination, protocole (17 pour UDP) et longueur UDP.
TCP : 10 champs + options, 20-60 octets variables.
L'overhead minimal d'UDP (12 octets de moins au minimum) est l'une des raisons de sa superiorite en termes de vitesse.
Cas d'usage d'UDP
UDP est le choix idéal quand la vitesse et la faible latence sont plus importantes que la fiabilité :
Les requêtes DNS sont courtes et simples. Utiliser TCP pour chaque requête ajouterait un overhead inutile (three-way handshake juste pour demander l'IP d'un site). Si la réponse est perdue, le client redemande tout simplement.
Note : DNS utilise TCP quand la réponse dépasse 512 octets (zone transfers) ou avec DNSSEC.
En appel vocal, un paquet perdu est préférable à un paquet en retard. Retransmettre un fragment de voix arrivant 2 secondes plus tard est inutile — la conversation a déjà avancé. UDP permet de maintenir un flux audio en temps réel.
Le streaming vidéo en direct ne peut pas attendre la retransmission de paquets perdus. Quelques pixels manquants pendant une fraction de seconde sont acceptables. L'expérience globale est meilleure avec UDP qu'avec TCP.
Les jeux multijoueurs en temps réel (FPS, MOBA) envoient des mises à jour de position en continu. Un paquet de position obsolète ne vaut pas la peine d'être retransmis — la nouvelle position est déjà envoyée dans le paquet suivant. La latence minimale est critique.
SNMP (Simple Network Management Protocol) : monitoring réseau avec des requêtes légères.
TFTP (Trivial File Transfer Protocol) : transfert de fichiers simple (pas de sécurité, juste de la vitesse).
DHCP : attribution d'adresses IP — le client n'a même pas encore d'IP, donc pas de connexion TCP possible.
⚔️ 8.6 — TCP vs UDP — Comparaison détaillée
Le choix entre TCP et UDP dépend des besoins de l'application. Voici une comparaison complète :
| Critère | TCP | UDP |
|---|---|---|
| Type de connexion | Orienté connexion (connection-oriented) | Sans connexion (connectionless) |
| Fiabilité | Fiable — accusés de réception (ACK), retransmission | Non fiable — best effort delivery |
| Ordre de livraison | Garanti — numéros de séquence | Non garanti — les datagrammes peuvent arriver dans le désordre |
| Contrôle de flux | Oui — window size | Non |
| Taille de l'en-tête | 20 à 60 octets | 8 octets |
| Vitesse | Plus lent (overhead du handshake, ACK, etc.) | Plus rapide (pas de handshake, pas d'ACK) |
| Overhead réseau | Élevé (segments de contrôle, retransmissions) | Faible (envoyer et oublier) |
| Handshake | Three-way handshake obligatoire | Aucun |
| Détection d'erreurs | Checksum + retransmission | Checksum uniquement (pas de retransmission) |
| Communication | Full-duplex | Pas de notion de connexion |
| Unité de données | Segment | Datagramme |
| Protocoles typiques | HTTP, HTTPS, FTP, SSH, SMTP, Telnet, POP3, IMAP | DNS, DHCP, TFTP, SNMP, VoIP (RTP), streaming |
Quand utiliser quoi ?
Utilise TCP quand...
- Chaque octet de données doit arriver (transfert de fichiers, emails)
- L'ordre est important (pages web, requêtes base de données)
- La perte de données est inacceptable (transactions financières)
- Tu as besoin de contrôle de flux et de congestion
Utilise UDP quand...
- La vitesse est critique (temps réel, gaming)
- La perte de quelques paquets est tolérable (voix, vidéo)
- Les requêtes sont simples et courtes (DNS)
- Le protocole gère lui-même la fiabilité si besoin
- Tu veux minimiser l'overhead réseau
🚪 8.7 — Les numéros de ports
Les numeros de ports sont des identifiants numeriques codes sur 16 bits (donc de 0 a 65 535, soit 65 536 ports possibles) qui permettent a la couche Transport de diriger les donnees vers la bonne application sur un hote. C'est le mecanisme de multiplexage. Les ports sont geres par l'IANA (Internet Assigned Numbers Authority).
L'adresse IP, c'est l'adresse d'un immeuble. Le numéro de port, c'est le numéro de l'appartement. Le facteur (IP) trouve l'immeuble, puis le numéro d'appartement (port) lui indique à qui livrer le courrier. Sans numéro d'appartement, le courrier ne peut pas atteindre le bon destinataire.
Les trois plages de ports
| Plage | Numéros | Nom | Description |
|---|---|---|---|
| 0 — 1 023 | 1 024 ports | Well-Known Ports (Ports bien connus) |
Réservés aux services et protocoles standard (HTTP, FTP, SSH...). Assignés par l'IANA. Nécessitent des privilèges administrateur pour être utilisés. |
| 1 024 — 49 151 | 48 128 ports | Registered Ports (Ports enregistrés) |
Attribués par l'IANA à des applications spécifiques (ex: 3306 MySQL, 3389 RDP, 8080 HTTP alt). Pas besoin de privilèges admin. |
| 49 152 — 65 535 | 16 384 ports | Dynamic / Private Ports (Ports dynamiques / éphémères) |
Attribués automatiquement par l'OS aux applications clientes. Utilisés temporairement pour une connexion sortante. |
Ports importants à connaître
Ces ports sont fréquemment testés dans l'examen CyberOps Associate :
| Port | Protocole | Transport | Description |
|---|---|---|---|
| 20 | FTP Data | TCP | Transfert de fichiers — canal de données |
| 21 | FTP Control | TCP | Transfert de fichiers — canal de commandes |
| 22 | SSH | TCP | Accès distant sécurisé (chiffré) — remplace Telnet |
| 23 | Telnet | TCP | Accès distant non chiffré (obsolète, dangereux !) |
| 25 | SMTP | TCP | Envoi d'emails (Simple Mail Transfer Protocol) |
| 53 | DNS | TCP/UDP | Résolution de noms de domaine |
| 67/68 | DHCP | UDP | Attribution dynamique d'adresses IP (serveur/client) |
| 69 | TFTP | UDP | Transfert de fichiers simplifié (sans authentification) |
| 80 | HTTP | TCP | Web non chiffré |
| 110 | POP3 | TCP | Réception d'emails (télécharge et supprime du serveur) |
| 143 | IMAP | TCP | Réception d'emails (synchronisation avec le serveur) |
| 161/162 | SNMP | UDP | Monitoring et gestion de réseau |
| 443 | HTTPS | TCP | Web chiffré (HTTP + TLS/SSL) |
| 514 | Syslog | UDP | Journalisation centralisée (logs réseau) |
| 993 | IMAPS | TCP | IMAP chiffré (avec TLS/SSL) |
| 995 | POP3S | TCP | POP3 chiffré (avec TLS/SSL) |
| 3389 | RDP | TCP | Remote Desktop Protocol — Bureau à distance Windows |
Commandes utiles pour identifier les ports
🔬 8.8 — Exercice : Associe les protocoles à leurs ports
Fais glisser chaque protocole vers le bon numéro de port :
Port 21
Port 22
Port 23
Port 25
Port 53
Port 80
Port 110
Port 143
Port 443
Port 3389
📝 8.9 — Quiz de révision
Points cles du Module 8
- La couche Transport (Layer 4) assure la communication de bout en bout via la segmentation, le multiplexage et le reassemblage
- TCP est oriente connexion, fiable, avec un en-tete de 20 octets minimum (60 max) contenant 10 champs : Source/Dest Port (16b), Seq Number (32b), Ack Number (32b), Data Offset (4b), Reserved (3b), Flags (9b), Window Size (16b), Checksum (16b), Urgent Pointer (16b)
- Les 9 flags TCP : NS, CWR, ECE (congestion ECN), URG, ACK, PSH, RST, SYN, FIN
- Le three-way handshake (SYN → SYN-ACK → ACK) etablit une connexion TCP ; le four-way handshake (FIN/ACK) la ferme gracieusement
- Les 11 etats TCP : CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT
- Flow control : sliding window + window scaling (fenetre jusqu'a 1 Go). Congestion control : slow start (exponentiel) → congestion avoidance (lineaire) → fast retransmit (3 dup ACKs) → fast recovery
- UDP : sans connexion, non fiable, rapide, en-tete de 8 octets fixes (4 champs x 16 bits : Source Port, Dest Port, Length, Checksum)
- Les Well-Known Ports (0-1023), les Registered Ports (1024-49151), et les Dynamic/Private Ports (49152-65535)
- Ports essentiels : 20/21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS, 67/68 DHCP, 69 TFTP, 80 HTTP, 110 POP3, 143 IMAP, 161/162 SNMP, 443 HTTPS, 514 Syslog, 993 IMAPS, 995 POP3S, 3389 RDP
- Un socket = IP:Port identifie un endpoint ; une socket pair (5-tuple : protocole + IP src:port src + IP dst:port dst) identifie une conversation complete