QUIC : qu’est-ce qui se cache derrière le protocole ex­pé­ri­men­tal de Google ?

Grâce à un accès Internet encore plus rapide, les temps de char­ge­ment des sites ont con­si­dé­ra­ble­ment diminué. En con­sé­quence, le char­ge­ment rapide des pages est désormais acquis, ce qui signifie que les sites Web à char­ge­ment lent ont peu de chances de survivre sur le marché.

Pour aggraver les choses, le sujet du chif­fre­ment devient de plus en plus important : le http standard est un allié de confiance lorsqu'il s'agit de protéger la con­fi­den­tia­lité des uti­li­sa­teurs, mais demande une mise en place de connexion sécurisée par TLS, un cer­ti­fi­cat et un échange de clés qui en­traî­ne­ront des retards sup­plé­men­taires dans le processus de char­ge­ment. Le protocole QUIC de Google veut résoudre ce problème.

QUIC est un protocole ex­pé­ri­men­tal, créé par le moteur de recherche Google et présenté au public en 2013. Le nom signifie « Quick UDP Internet Con­nec­tions » (con­nexions 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é­ve­lop­pe­ment de QUIC était le désir de fournir une al­ter­na­tive aux solutions de sécurité TCP, HTTP/2 et TLS/SSL en dé­ve­lop­pant la même pro­tec­tion mais avec un délai de connexion et de transport réduit, et en per­met­tant des con­nexions de mul­ti­plexage.

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'ex­pé­di­teur et le des­ti­na­taire, ils échangent les cer­ti­fi­cats et les clés né­ces­saires pour chiffrer les da­ta­grammes envoyés. Les com­mu­ni­ca­tions ul­té­rieures éliminent cet échange, ce qui minimise la latence. Le protocole de chif­fre­ment est la version 1.3 actuelle de TLS, optimisée en vitesse (stan­dar­di­sée en mars 2017), préférée à la solution de chif­fre­ment interne. Con­cer­nant le mul­ti­plexage, 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 trans­mettre plusieurs flux de données, ce qui réduit con­si­dé­ra­ble­ment le temps de char­ge­ment.

Certaines ca­rac­té­ris­tiques im­por­tantes du système QUIC ont déjà été men­tion­nées, mais elles seront abordées plus en détail ci-après, en référence à d’autres amé­lio­ra­tions. Le TCP, qui joue un rôle majeur en tant que pionnier dans le concept du protocole de transport, sert de bonne com­pa­rai­son de protocole. Cependant, il est clai­re­ment inférieur au protocole de Google à certains égards, comme le montre le guide suivant :

L'aspect principal des per­for­mances qui confère à QUIC un avantage sur le TCP est que la con­fi­gu­ra­tion de la connexion est beaucoup plus rapide. Même sans chif­fre­ment via SSL/TLS, une connexion utilisant le protocole de transport tra­di­tion­nel 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 trans­met­tra tous les pa­ra­mètres TLS ou HTTPS né­ces­saires. Dans la plupart des cas, un client peut envoyer des données di­rec­te­ment à 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 iden­ti­fier une connexion. De ce fait, il n'est pas possible pour un client de com­mu­ni­quer avec le serveur sur plusieurs ports avec une seule connexion. Le protocole QUIC résout la situation dif­fé­rem­ment : il utilise une détection de connexion 64 bits et dif­fé­rents « flux » pour trans­por­ter les données dans une connexion. Par con­sé­quent, une connexion QUIC n'est pas né­ces­sai­re­ment liée à un port spé­ci­fique (en l'oc­cur­rence un port UDP), à une adresse IP ou à un point de ter­mi­nai­son spé­ci­fique. Les mo­di­fi­ca­tions de port et d'IP sont deux options viables, tout comme la connexion de mul­ti­plexage décrite pré­cé­dem­ment.

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é­ter­mi­ner le statut d'une séquence : seul le protocole de transport classique peut utiliser ce type de dis­tinc­tion en utilisant une extension d'ho­ro­da­tage (en anglais ti­mes­tam­ping). Le marquage continu des paquets est avan­ta­geux car il permet une es­ti­ma­tion plus précise du temps de trans­mis­sion (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 cor­rec­tion d'erreurs basé sur XOR, il n'est pas né­ces­saire de soumettre à nouveau les données cor­res­pon­dantes. Celles-ci peuvent être cons­truites à tout moment à l'aide de packages FEC (Forward Error Cor­rec­tion), sau­ve­gardes des packages d'origine pour un groupe de données. Cependant, la cor­rec­tion d'erreur ne fonc­tionne pas si plusieurs packages d'un groupe de données sont manquants.

Le TCP essaie toujours d'envoyer les données aussi ra­pi­de­ment 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 re­trans­mis­sion (TCP Fast Re­trans­mit) est lancée ra­pi­de­ment. À cette fin, cependant, le TCP réduit tem­po­rai­re­ment la taille de la fenêtre de la boutique, ce qui entraîne souvent la trans­mis­sion in­ter­mit­tente des données. Le protocole QUIC con­tre­carre ces pics de charge avec le « packet pacing ». Cette procédure garantit que le taux de trans­mis­sion est au­to­ma­ti­que­ment limité. Ainsi, même avec des con­nexions à 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 pla­ni­fi­ca­tion et de la con­cep­tion de QUIC. Les dé­ve­lop­peurs ont également pri­vi­lé­gié la recherche d'une solution à l'un des problèmes les plus im­por­tants du TCP : l'en-tête d'un paquet envoyé est en texte brut et peut être lu sans au­then­ti­fi­ca­tion 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 au­then­ti­fié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'in­jec­tion et la fal­si­fi­ca­tion par une au­then­ti­fi­ca­tion à la fin du des­ti­na­taire.

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é­ri­phé­riques res­pec­tifs pour pouvoir com­mu­ni­quer, la prise en charge de QUIC n'est requise qu'au niveau de l'ap­pli­ca­tion. Il ap­par­tient aux sociétés de logiciels in­di­vi­duelles d'in­té­grer le logiciel - elles ne dépendent pas des fa­bri­cants de matériel. À ce jour, ce sont prin­ci­pa­le­ment les ap­pli­ca­tions de Google telles que les serveurs Google ou Google Chrome qui ont mis en œuvre QUIC. Cependant, les pro­grammes tels que le na­vi­ga­teur Opera, le logiciel serveur Caddy, l'équi­li­brage de charge (Load balancing) de LiteSpeed Tech­no­lo­gies et les produits de serveur Web ont déjà des ap­pli­ca­tions tierces per­met­tant des con­nexions via le nouveau protocole de transport.

Le fait que QUIC soit sus­cep­tible de devenir plus populaire est dû à l'en­ga­ge­ment de l'IETF. Avec des ajus­te­ments 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’op­ti­mi­sa­tion est loin d’être terminé : l’équipe QUIC continue de s’attaquer aux problèmes existants qui né­ces­si­tent toujours la bonne solution.

L'un des problèmes les plus im­por­tants auxquels le protocole QUIC reste confronté est la sécurité. Bien que l'au­then­ti­fi­ca­tion et le chif­fre­ment four­nis­sent une méthode plus sûre de transport pour les données, ils sont également res­pon­sables de l'un des prin­ci­paux in­con­vé­nients de QUIC. Étant donné que les en-têtes de paquets con­tien­nent des in­for­ma­tions de texte moins clair que ceux qui ont des con­nexions TCP, des tâches telles que le dépannage, la ré­gu­la­tion du trafic, ou la gestion du réseau devenir plus difficile avec les con­nexions QUIC. Pour cette raison, les opé­ra­teurs de réseau et les fa­bri­cants 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 au­to­ma­tique de l'en­com­bre­ment sur les con­nexions de données à bande passante élevée peut entraîner des taux de trans­mis­sion plus faibles dans certains cas.

Si vous souhaitez dé­sac­ti­ver le protocole, cliquez sim­ple­ment sur « Désactivé », puis sur « Démarrer main­te­nant ». Chrome se fermera alors, mais la prochaine fois que vous lancerez votre na­vi­ga­teur, les nouveaux pa­ra­mètres seront activés. Si vous souhaitez réactiver le protocole, procédez de la même manière, mais sé­lec­tion­nez « Par défaut » ou « Activé ».Si vous souhaitez dé­sac­ti­ver le protocole, cliquez sim­ple­ment sur « Désactivé », puis sur « Démarrer main­te­nant ». Chrome se fermera alors, mais la prochaine fois que vous lancerez votre na­vi­ga­teur, les nouveaux pa­ra­mètres seront activés. Si vous souhaitez réactiver le protocole, procédez de la même manière, mais sé­lec­tion­nez « Par défaut » ou « Activé ».