QUIC : qu’est-ce qui se cache derrière le protocole expérimental de Google ?

Grâce à un accès Internet encore plus rapide, les temps de chargement des sites ont considérablement diminué. En conséquence, le chargement rapide des pages est désormais acquis, ce qui signifie que les sites Web à chargement lent ont peu de chances de survivre sur le marché.

Pour aggraver les choses, le sujet du chiffrement devient de plus en plus important : le http standard est un allié de confiance lorsqu'il s'agit de protéger la confidentialité des utilisateurs, mais demande une mise en place de connexion sécurisée par TLS, un certificat et un échange de clés qui entraîneront des retards supplémentaires dans le processus de chargement. Le protocole QUIC de Google veut résoudre ce problème.

QUIC est un protocole expérimental, créé par le moteur de recherche Google et présenté au public en 2013. Le nom signifie « Quick UDP Internet Connections » (connexions Internet UDP rapides), car il permet l'envoi rapide de paquets simples via le protocole UDP (User Datagram Protocol) sans connexion. La raison du développement de QUIC était le désir de fournir une alternative aux solutions de sécurité TCP, HTTP/2 et TLS/SSL en développant la même protection mais avec un délai de connexion et de transport réduit, et en permettant des connexions de multiplexage.

Google a conçu QUIC afin que le protocole lui-même contrôle la connexion. Lors de la première prise de contact entre l'expéditeur et le destinataire, ils échangent les certificats et les clés nécessaires pour chiffrer les datagrammes envoyés. Les communications ultérieures éliminent cet échange, ce qui minimise la latence. Le protocole de chiffrement est la version 1.3 actuelle de TLS, optimisée en vitesse (standardisée en mars 2017), préférée à la solution de chiffrement interne. Concernant le multiplexage, le protocole QUIC suit le protocole SPDY développé par Google, qui fournit le modèle pour HTTP/2 : une connexion client-serveur unique pouvant être utilisée pour transmettre plusieurs flux de données, ce qui réduit considérablement le temps de chargement.

Certaines caractéristiques importantes du système QUIC ont déjà été mentionnées, mais elles seront abordées plus en détail ci-après, en référence à d’autres améliorations. Le TCP, qui joue un rôle majeur en tant que pionnier dans le concept du protocole de transport, sert de bonne comparaison de protocole. Cependant, il est clairement inférieur au protocole de Google à certains égards, comme le montre le guide suivant :

L'aspect principal des performances qui confère à QUIC un avantage sur le TCP est que la configuration de la connexion est beaucoup plus rapide. Même sans chiffrement via SSL/TLS, une connexion utilisant le protocole de transport traditionnel avec le « triple-handshake » prend plus d'étapes que la solution Google basée sur UDP. QUIC démarrera une connexion avec un seul paquet (ou deux paquets s'il s'agit de la première connexion), et transmettra tous les paramètres TLS ou HTTPS nécessaires. Dans la plupart des cas, un client peut envoyer des données directement à un serveur sans recourir à une réponse, tandis que le TCP doit d'abord obtenir et traiter l'accusé de réception du serveur.

Le TCP utilise les ports TCP et les adresses IP des systèmes connectés pour identifier une connexion. De ce fait, il n'est pas possible pour un client de communiquer avec le serveur sur plusieurs ports avec une seule connexion. Le protocole QUIC résout la situation différemment : il utilise une détection de connexion 64 bits et différents « flux » pour transporter les données dans une connexion. Par conséquent, une connexion QUIC n'est pas nécessairement liée à un port spécifique (en l'occurrence un port UDP), à une adresse IP ou à un point de terminaison spécifique. Les modifications de port et d'IP sont deux options viables, tout comme la connexion de multiplexage décrite précédemment.

Chaque segment de données d'une connexion QUIC reçoit son propre numéro de séquence, qu'il s'agisse d'un segment d'origine ou d'un segment transmis. Par défaut, le TCP ne le fait pas, ce qui explique pourquoi un hôte ne peut pas déterminer le statut d'une séquence : seul le protocole de transport classique peut utiliser ce type de distinction en utilisant une extension d'horodatage (en anglais timestamping). Le marquage continu des paquets est avantageux car il permet une estimation plus précise du temps de transmission (RTT = round trip time).

Les paquets perdus ne posent pas de gros problèmes lors du transport de données via QUIC. Grâce à un simple système de correction d'erreurs basé sur XOR, il n'est pas nécessaire de soumettre à nouveau les données correspondantes. Celles-ci peuvent être construites à tout moment à l'aide de packages FEC (Forward Error Correction), sauvegardes des packages d'origine pour un groupe de données. Cependant, la correction d'erreur ne fonctionne pas si plusieurs packages d'un groupe de données sont manquants.

Le TCP essaie toujours d'envoyer les données aussi rapidement que possible, ce qui constitue un avantage en termes de connexion rapide des données, mais est également associé à un certain taux de perte. Si un paquet est perdu, la retransmission (TCP Fast Retransmit) est lancée rapidement. À cette fin, cependant, le TCP réduit temporairement la taille de la fenêtre de la boutique, ce qui entraîne souvent la transmission intermittente des données. Le protocole QUIC contrecarre ces pics de charge avec le « packet pacing ». Cette procédure garantit que le taux de transmission est automatiquement limité. Ainsi, même avec des connexions à faible bande passante, il n'y a pas de surcharge. Cependant, ce n'est pas une nouvelle technique : certains noyaux Linux utilisent également la méthode pour le protocole TCP.

Dès le début, la sécurité a été un aspect essentiel de la planification et de la conception de QUIC. Les développeurs ont également privilégié la recherche d'une solution à l'un des problèmes les plus importants du TCP : l'en-tête d'un paquet envoyé est en texte brut et peut être lu sans authentification préalable. L'attaque de l'homme du milieu (HDM) ou man-in-the-middle attack (MITM) ne sont donc pas rares. Cependant, les packages QUIC sont toujours authentifiés et largement chiffrés (y compris les données utiles). Les parties de l'en-tête qui ne sont pas chiffrées sont protégées contre l'injection et la falsification par une authentification à la fin du destinataire.

Un autre avantage majeur de QUIC sur le TCP est que le protocole Google est détaché du système. Bien que le TCP ait besoin de la prise en charge des plates-formes ou des périphériques respectifs pour pouvoir communiquer, la prise en charge de QUIC n'est requise qu'au niveau de l'application. Il appartient aux sociétés de logiciels individuelles d'intégrer le logiciel - elles ne dépendent pas des fabricants de matériel. À ce jour, ce sont principalement les applications de Google telles que les serveurs Google ou Google Chrome qui ont mis en œuvre QUIC. Cependant, les programmes tels que le navigateur Opera, le logiciel serveur Caddy, l'équilibrage de charge (Load balancing) de LiteSpeed Technologies et les produits de serveur Web ont déjà des applications tierces permettant des connexions via le nouveau protocole de transport.

Le fait que QUIC soit susceptible de devenir plus populaire est dû à l'engagement de l'IETF. Avec des ajustements aux normes communes depuis la création du groupe en 2016, le protocole a évolué d'un protocole centré sur Google à un protocole réseau commun. Toutefois, le processus d’optimisation est loin d’être terminé : l’équipe QUIC continue de s’attaquer aux problèmes existants qui nécessitent toujours la bonne solution.

L'un des problèmes les plus importants auxquels le protocole QUIC reste confronté est la sécurité. Bien que l'authentification et le chiffrement fournissent une méthode plus sûre de transport pour les données, ils sont également responsables de l'un des principaux inconvénients de QUIC. Étant donné que les en-têtes de paquets contiennent des informations de texte moins clair que ceux qui ont des connexions TCP, des tâches telles que le dépannage, la régulation du trafic, ou la gestion du réseau devenir plus difficile avec les connexions QUIC. Pour cette raison, les opérateurs de réseau et les fabricants de pare-feu, entre autres, ont du mal à garantir la qualité de leurs produits.

Un autre problème avec le protocole QUIC est que le contrôle automatique de l'encombrement sur les connexions de données à bande passante élevée peut entraîner des taux de transmission plus faibles dans certains cas.

Si vous souhaitez désactiver le protocole, cliquez simplement sur « Désactivé », puis sur « Démarrer maintenant ». Chrome se fermera alors, mais la prochaine fois que vous lancerez votre navigateur, les nouveaux paramètres seront activés. Si vous souhaitez réactiver le protocole, procédez de la même manière, mais sélectionnez « Par défaut » ou « Activé ».Si vous souhaitez désactiver le protocole, cliquez simplement sur « Désactivé », puis sur « Démarrer maintenant ». Chrome se fermera alors, mais la prochaine fois que vous lancerez votre navigateur, les nouveaux paramètres seront activés. Si vous souhaitez réactiver le protocole, procédez de la même manière, mais sélectionnez « Par défaut » ou « Activé ».