TCP vs UDP — Fiabilité ou vitesse ?

Votre API ne répond pas et vous ne savez pas comment tester si le port est accessible ? Ce module vous explique les deux protocoles de transport d’Internet : TCP (fiable) et UDP (rapide). Vous apprendrez à tester une connexion TCP avec netcat et à interpréter les erreurs — des compétences essentielles pour diagnostiquer les problèmes de connectivité en production.

TL;DR — L’essentiel en 30 secondes

• TCP = fiable (HTTP, SSH, bases de données) — UDP = rapide (DNS, streaming, jeux)
• Tester un port TCP : nc -zv hôte port
• Connection refused = port fermé (service absent)
• Timeout = paquet filtré (pare-feu) ou machine inaccessible

Je sais que c’est bon si…

• nc -zv google.com 443 affiche “succeeded”
• Je sais distinguer “refused” (port fermé) de “timeout” (filtré)
• ss -tlnp me montre les ports en écoute sur ma machine

Commandes minimales à retenir

# 1. Tester un port TCP
nc -zv github.com 443

# 2. Voir les ports ouverts localement
ss -tlnp

# 3. Tester avec timeout court
nc -zv -w 3 192.168.1.1 22

UDP se teste autrement

Contrairement à TCP, UDP n’a pas de handshake. Un nc -zu qui “réussit” ne prouve pas qu’un service écoute — juste que le paquet est parti.

Pour tester UDP, utilisez l’outil applicatif : dig @serveur domaine pour DNS, snmpget pour SNMP, etc.

Prérequis

• Module 4 complété : vous comprenez le routage et les passerelles
• Connaissance des ports : vous savez qu’un port identifie un service (cf. Module 2)
• Une machine Linux connectée à Internet
• Un terminal ouvert

Installation de netcat

La commande nc (netcat) est préinstallée sur la plupart des distributions. Si elle manque :

# Debian/Ubuntu
sudo apt install netcat-openbsd

# Fedora/RHEL
sudo dnf install nmap-ncat

Attention : plusieurs implémentations existent (netcat-openbsd, ncat, netcat-traditional). Les options et sorties peuvent varier. Vérifiez avec nc -h ou man nc.

Ce que vous allez apprendre

• TCP vs UDP : comprendre quand utiliser chaque protocole
• Le handshake TCP : comment une connexion s’établit
• Les ports bien connus : SSH, HTTP, HTTPS, DNS et autres
• Tester avec netcat : vérifier si un port est ouvert
• Interpréter les erreurs : refused vs timeout vs reset
• Cas pratiques : diagnostiquer un service qui ne répond pas

Recommandation rapide : TCP ou UDP ?

Avant d’entrer dans les détails, voici le tableau de décision :

Situation	Protocole	Pourquoi
Site web, API REST	TCP	Fiabilité requise
Base de données	TCP	Intégrité des données
SSH, transfert de fichiers	TCP	Pas de perte acceptable
Requête DNS simple	UDP	Rapidité, petite taille
Streaming vidéo/audio	UDP	Latence prime
Jeux en ligne	UDP	Réactivité critique
VoIP, visioconférence	UDP	Temps réel
HTTP/3, QUIC	UDP	Transport fiable implémenté au-dessus

Glissez pour voir

Règle simple : si vous ne pouvez pas vous permettre de perdre des données → TCP. Si la vitesse prime sur la fiabilité → UDP.

TCP vs UDP : les deux protocoles de transport

Quand votre machine envoie des données sur le réseau, elle utilise l’un de ces deux protocoles. Ils ont des philosophies opposées.

TCP : le protocole fiable

TCP (Transmission Control Protocol) garantit que vos données arrivent intégralement et dans l’ordre. C’est le protocole utilisé par la majorité des services : HTTP, SSH, email, bases de données.

Caractéristiques :

• Connexion établie avant d’envoyer des données (handshake)
• Accusé de réception pour chaque paquet
• Retransmission automatique si un paquet est perdu
• Ordre garanti : les paquets arrivent dans l’ordre d’envoi
• Contrôle de flux : évite de saturer le destinataire

Analogie : TCP, c’est comme envoyer un courrier recommandé avec accusé de réception. C’est plus lent, mais vous êtes sûr que ça arrive et dans quel état.

UDP : le protocole rapide

UDP (User Datagram Protocol) envoie les données sans vérification. Pas de connexion, pas d’accusé, pas de retransmission. C’est le protocole utilisé quand la vitesse prime : DNS, streaming, jeux.

Caractéristiques :

• Pas de connexion : on envoie directement
• Pas de garantie : les paquets peuvent être perdus
• Pas d’ordre : les paquets peuvent arriver dans le désordre
• Overhead minimal : en-tête très petit (8 octets vs 20 minimum pour TCP)
• Latence très faible : pas d’attente d’accusé

Analogie : UDP, c’est comme envoyer une carte postale. C’est rapide et léger, mais pas de garantie que ça arrive.

Pourquoi le DNS utilise UDP ?

Les requêtes DNS sont petites (quelques octets) et fréquentes. Établir une connexion TCP pour chaque requête serait trop lent. UDP permet des réponses en quelques millisecondes.

Exception : les transferts de zone DNS et les grosses réponses (DNSSEC) utilisent TCP. C’est une exigence de mise en œuvre, pas un cas exotique (RFC 7766).

QUIC et HTTP/3 : UDP fiable ?

QUIC (RFC 9000, base de HTTP/3) utilise UDP mais implémente fiabilité, chiffrement et contrôle de congestion au-dessus. Preuve que “UDP = rapide” ne veut pas dire “forcément non fiable” — la fiabilité peut être gérée par l’application.

Transport vs Application

Rappel important : TCP et UDP sont des protocoles de transport (couche 4). Ils transportent des données, mais ne définissent pas ce qu’elles contiennent.

• TCP : fournit un “flux d’octets” fiable et ordonné
• UDP : fournit des “datagrammes” indépendants, sans état

Le port identifie le service (application), pas le protocole applicatif. HTTP/2 sur TCP et HTTP/3 sur UDP utilisent tous deux le port 443.

Le handshake TCP : comment une connexion s’établit

Avant d’échanger des données, TCP doit établir une connexion. Ce processus s’appelle le three-way handshake (poignée de main en trois temps).

1. SYN (Synchronize)

   Le client envoie un paquet SYN au serveur : “Je veux me connecter”.

2. SYN-ACK (Synchronize-Acknowledge)

   Le serveur répond avec SYN-ACK : “OK, je t’écoute, je suis prêt”.

3. ACK (Acknowledge)

   Le client confirme avec ACK : “Bien reçu, on peut commencer”.

Après ces trois échanges, la connexion est établie et les données peuvent circuler dans les deux sens.

Ce que ça implique en diagnostic

Quand vous testez une connexion TCP avec netcat, vous testez en réalité ce handshake :

Résultat	Signification
Connection succeeded	Handshake complet → service accessible
Connection refused	Le serveur a répondu RST → port fermé
Timeout	Pas de réponse → paquet perdu ou filtré

Glissez pour voir

Les ports bien connus

Un port est un numéro (0–65535) qui identifie un service sur une machine. Certains ports sont réservés par convention :

Port	Protocole	Service	Description
22	TCP	SSH	Connexion à distance sécurisée
80	TCP	HTTP	Sites web non chiffrés
443	TCP	HTTPS	Sites web chiffrés (TLS)
53	UDP/TCP	DNS	Résolution de noms
25	TCP	SMTP	Envoi d’emails
3306	TCP	MySQL	Base de données MySQL
5432	TCP	PostgreSQL	Base de données PostgreSQL
6379	TCP	Redis	Cache/base Redis
8080	TCP	HTTP alt	Tests, proxys
27017	TCP	MongoDB	Base de données MongoDB

Glissez pour voir

Ports privilégiés

Les ports inférieurs à 1024 sont dits “privilégiés”. Par défaut, binder sur ces ports nécessite des privilèges (root ou capability CAP_NET_BIND_SERVICE). C’est pourquoi les applications utilisateur écoutent souvent sur 3000, 8000 ou 8080.

Sur les noyaux récents, le sysctl net.ipv4.ip_unprivileged_port_start peut abaisser cette limite.

Source officielle des ports

L’IANA maintient le registre officiel des ports : Service Name and Transport Protocol Port Number Registry.

Tester une connexion TCP avec netcat

netcat (ou nc) est l’outil de référence pour tester si un port TCP est ouvert et accessible.

Syntaxe de base

nc -zv <hôte> <port>

Options :

• -z : mode scan (ne pas envoyer de données)
• -v : mode verbeux (afficher le résultat)

Exemples concrets

Port ouvert

nc -zv github.com 443

Sortie :

Connection to github.com 443 port [tcp/https] succeeded!

Le port 443 (HTTPS) de GitHub est accessible. Le handshake TCP a réussi.

Port fermé

nc -zv github.com 22

Sortie :

nc: connect to github.com port 22 (tcp) failed: Connection refused

Le port 22 (SSH) est fermé sur les serveurs publics de GitHub. Le serveur a répondu avec un paquet RST (reset).

Port filtré

nc -zv -w 3 192.0.2.1 80

Sortie (après ~3 secondes) :

nc: connect to 192.0.2.1 port 80 (tcp) timed out

Pas de réponse du tout. Le paquet est probablement bloqué par un pare-feu (DROP).

L’option -w 3 limite le timeout à 3 secondes.

Plusieurs ports

nc -zv google.com 80 443

Sortie :

Connection to google.com 80 port [tcp/http] succeeded!
Connection to google.com 443 port [tcp/https] succeeded!

Vous pouvez tester plusieurs ports d’un coup.

Interpréter les résultats

Message	Signification	Cause probable
succeeded	Connexion établie	Service accessible
refused	Port fermé	Aucun service n’écoute
timed out	Pas de réponse	Pare-feu (DROP), routage, ou rate-limit
No route to host	Routage impossible	Problème réseau

Glissez pour voir

Refused vs Timeout

Cette distinction est cruciale en diagnostic :

• Refused = le serveur a répondu “non” → le réseau fonctionne, mais le port est fermé
• Timeout = pas de réponse → le paquet n’arrive pas (pare-feu DROP, routage asymétrique, rate-limit)

Un timeout n’est pas toujours un “problème” : certains firewalls DROP silencieusement les paquets plutôt que de les rejeter.

Tester UDP avec netcat ?

Contrairement à TCP, UDP est connectionless. Avec nc -zu, un “succeeded” ne garantit pas qu’un service écoute — il signifie juste que le paquet a été envoyé sans erreur ICMP.

Pour tester un service UDP, utilisez l’outil applicatif : dig pour DNS, snmpget pour SNMP, etc.

Voir les ports ouverts localement

Pour voir quels services écoutent sur votre machine :

ss -tuln

Options :

• -t : TCP
• -u : UDP
• -l : en écoute (listening)
• -n : numérique (pas de résolution DNS)

Sortie typique :

Netid  State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port
tcp    LISTEN  0       128      0.0.0.0:22            0.0.0.0:*
tcp    LISTEN  0       511      127.0.0.1:3000        0.0.0.0:*
tcp    LISTEN  0       128      0.0.0.0:80            0.0.0.0:*
udp    UNCONN  0       0        127.0.0.53:53         0.0.0.0:*

Lecture :

Local Address	Signification
0.0.0.0:22	SSH écoute sur toutes les interfaces
127.0.0.1:3000	App écoute uniquement en local
127.0.0.53:53	DNS local (systemd-resolved)

Glissez pour voir

Voir le processus associé

Ajoutez -p pour voir quel processus écoute (nécessite sudo) :

sudo ss -tulnp

Sortie :

tcp  LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))

Cas pratique : diagnostiquer un service inaccessible

Scénario : votre API déployée sur api.example.com ne répond pas.

1. Vérifier la résolution DNS

   dig +short api.example.com

   Si pas de réponse → problème DNS. Sinon, notez l’IP.

2. Tester la connectivité réseau

   ping -c 3 api.example.com

   Si timeout → problème réseau ou ICMP bloqué. Ne concluez pas trop vite : continuez avec un test TCP.

3. Tester le port TCP

   nc -zv api.example.com 443

   • succeeded → le port est ouvert, problème applicatif
   • refused → le service n’écoute pas
   • timeout → pare-feu ou routage

4. Vérifier côté serveur (si vous avez accès)

   sudo ss -tulnp | grep :443

   Le service écoute-t-il ? Sur quelle interface ?

5. Vérifier le pare-feu

   # iptables (legacy, encore courant)
   sudo iptables -L -n | grep 443
   
   # nftables (moderne, Debian 10+, Ubuntu 20.04+)
   sudo nft list ruleset | grep 443

   Une règle bloque-t-elle le trafic entrant ?

Travaux pratiques

TP 1 : Exploration des ports de services locaux

1. Testez un port fermé local

   nc -zv localhost 12345

   Observez le message “Connection refused” — aucun service n’écoute.

2. Testez un port ouvert local (si SSH actif)

   nc -zv localhost 22

   Observez “succeeded” si sshd écoute.

3. Listez les services de votre machine

   ss -tuln

   Quels services écoutent ? Sur quelle interface ?

4. Identifiez les processus (avec sudo)

   sudo ss -tulnp | grep LISTEN

   Quel processus écoute sur chaque port ?

TP 2 : Tester des services distants

1. Testez les ports web de Google

   nc -zv -w 3 google.com 80
   nc -zv -w 3 google.com 443

   Les deux devraient répondre “succeeded”.

2. Simulez un timeout

   nc -zv -w 2 192.0.2.1 80

   L’adresse 192.0.2.1 est réservée pour la documentation et ne répond jamais.

3. Mesurez le temps de réponse

   time nc -zv -w 5 google.com 443

   La connexion TCP prend combien de temps ?

4. Testez plusieurs ports d’un coup

   nc -zv -w 2 google.com 80 443

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• TCP = fiable, connexion établie, retransmission → HTTP, SSH, bases de données
• UDP = rapide, sans connexion, sans garantie → DNS, streaming, jeux
• QUIC/HTTP/3 = UDP + fiabilité applicative (la fiabilité n’est pas réservée à TCP)
• Handshake TCP : SYN → SYN-ACK → ACK (3 échanges avant de communiquer)
• nc -zv <hôte> <port> : teste si un port TCP est accessible
• refused = port fermé (service absent), timeout = filtré (pare-feu DROP)
• UDP non testable comme TCP : “succeeded” ne garantit pas un service actif
• ss -tuln : voir les ports en écoute sur votre machine
• Ports privilégiés : < 1024, nécessitent root ou CAP_NET_BIND_SERVICE

Prochaines étapes

Module 7 : DHCP Comment votre machine obtient automatiquement son adresse IP

Module 8 : ICMP et ping Comprendre les messages de contrôle réseau

Retour au parcours Vue d'ensemble de la formation réseau

×

📖 Voir la documentation →