QUIC: Un protocole de transport moderne

QUIC est un protocole de transport moderne, orienté connexion et chiffré, conçu initialement par Google. Il sert principalement de base à HTTP/3 : au lieu de reposer sur la pile classique HTTP/2 → TLS → TCP → IP, HTTP/3 repose sur HTTP/3 → QUIC → UDP → IP.

Le problème de TCP

TCP garantit la livraison des données dans l’ordre. C’est excellent pour un fichier ou une page Web, mais cette garantie peut créer un blocage : si un paquet est perdu, TCP attend sa retransmission avant de remettre les données suivantes à l’application.

Avec HTTP/2, plusieurs ressources — HTML, CSS, JavaScript, images — peuvent partager une seule connexion TCP. Si un paquet TCP manque, tous les flux de cette connexion peuvent être temporairement arrêtés, y compris ceux qui n’étaient pas concernés : c’est le head-of-line blocking au niveau transport.

Ce que fait QUIC

QUIC reprend les avantages recherchés avec TCP, mais les implémente au-dessus d’UDP :

• Connexion fiable : numéros de séquence, accusés de réception et retransmissions.
• Contrôle de congestion pour ne pas saturer le réseau.
• Contrôle de flux pour ne pas submerger le récepteur.
• Multiplexage de plusieurs flux indépendants.
• Chiffrement intégré avec TLS 1.3.

Autrement dit, QUIC utilise UDP comme support de paquets, mais n’est pas de l’UDP “brut”. Il reconstruit au-dessus d’UDP les garanties dont une application Web a besoin.

HTTP/1.1 ou HTTP/2
        ↓
TLS
        ↓
TCP
        ↓
IP

HTTP/3
        ↓
QUIC : fiabilité + flux + TLS 1.3
        ↓
UDP
        ↓
IP

Pourquoi utiliser UDP ?

UDP est choisi parce qu’il est simple : il fournit un datagramme avec des ports, mais n’impose ni connexion, ni retransmission, ni ordre global des données. QUIC peut donc définir lui-même ses règles, sans être contraint par le comportement de TCP.

Les raisons principales sont les suivantes :

Avantage	Pourquoi c’est utile
Évolution plus rapide	TCP est implémenté dans les systèmes d’exploitation, les routeurs et les pare-feux ; modifier son comportement est difficile. QUIC peut être mis à jour dans les navigateurs et serveurs
Flux indépendants	La perte de données dans un flux n’empêche pas forcément les autres flux QUIC de progresser
Connexion plus rapide	QUIC intègre TLS et réduit le nombre d’allers-retours nécessaires pour démarrer une session sécurisée
Migration de réseau	Une connexion peut mieux survivre au passage du Wi‑Fi à la 4G/5G, même si l’adresse IP du client change
Chiffrement natif	QUIC chiffre les échanges de transport avec TLS 1.3, au lieu d’ajouter TLS séparément au-dessus de TCP

Le multiplexage sans blocage global

QUIC découpe une connexion en plusieurs flux (streams). Chaque flux reste fiable et ordonné, mais il est indépendant des autres.

Exemple : un navigateur charge simultanément le HTML, une feuille CSS, un script et une image.

Flux 1 : HTML       ────────── OK
Flux 2 : CSS        ────────── OK
Flux 3 : JavaScript ── paquet perdu → retransmission
Flux 4 : image      ────────── OK

En QUIC, la perte du paquet du flux JavaScript ralentit essentiellement ce flux ; les données HTML, CSS ou image déjà reçues peuvent continuer à être délivrées. QUIC réduit ainsi le blocage global présent lorsque tous les flux dépendent d’un même ordre TCP.

Démarrage et reprise

Dans une connexion HTTPS classique, TCP doit d’abord établir sa connexion, puis TLS négocie les clés de chiffrement. QUIC combine plus étroitement la connexion et TLS 1.3, ce qui réduit le délai avant les premières données applicatives.

Lorsqu’un client a déjà visité un serveur, QUIC peut dans certains cas utiliser un mode 0-RTT : le client envoie des données dès le premier paquet, sans attendre un aller-retour complet. Cela accélère les connexions répétées, mais les requêtes envoyées ainsi doivent être conçues avec prudence car elles peuvent être rejouées.

Une précision importante

QUIC n’est pas « plus rapide parce qu’UDP est plus rapide ». UDP est seulement une fondation minimale. Le gain vient principalement de l’architecture de QUIC : démarrage plus court, chiffrement intégré, flux indépendants et logique de transport pouvant évoluer dans les logiciels.

UDP n’offre pas à lui seul la fiabilité. QUIC ajoute donc ses propres accusés de réception, retransmissions et mécanismes de congestion pour éviter de perdre des données ou d’encombrer Internet.

Limites pratiques

Certaines entreprises filtrent ou limitent l’UDP, souvent sur le port 443. Dans ce cas, un navigateur peut revenir à HTTPS sur TCP, généralement HTTP/2 ou HTTP/1.1.

Le chiffrement généralisé améliore la confidentialité, mais limite aussi l’inspection fine du trafic par certains équipements réseau. Enfin, comme tout protocole basé sur UDP, QUIC doit être correctement protégé contre les abus et les attaques par saturation.

En bref : QUIC utilise UDP pour repartir d’une base légère et contrôlable par les applications, puis ajoute les fonctions fiables et sécurisées de TCP + TLS, avec une meilleure gestion des flux Web modernes.