Trois ans et demi se sont écoulés depuis l'adoption de la norme HTTP / 2: la spécification RFC 7540 a été publiée en mai 2015, mais n'est pas encore utilisée universellement. Le protocole a été mis en œuvre dans tous les navigateurs depuis la fin de 2015 et après trois ans, seulement 31,2% des 10 millions de sites Internet les plus populaires prennent en charge HTTP / 2. Parmi les sites les plus populaires, Google, Youtube, Wikipedia, Twitter, Vk.com et d'autres y sont passés.

Néanmoins, les progrès ne sont pas en reste - et des travaux sont déjà en cours sur la prochaine version de HTTP / 3. Comme il est devenu connu maintenant, les développeurs de deux options alternatives ont atteint la compatibilité, et le protocole HTTP sur QUIC change maintenant de nom et s'appelle officiellement HTTP / 3 . En conséquence, dans une future version de HTTP, le transport TCP sera remplacé par QUIC.

Confusion avec différentes options QUIC

QUIC est un remplacement TCP qui fonctionne par dessus UDP. Initialement, cette technologie a été créée par les ingénieurs de Google, comme le précédent protocole SPDY, qui est devenu le fondement de HTTP / 2. Au début, QUIC s'appelait «HTTP / 2-crypté sur UDP».

Le développement QUIC a ensuite été transféré à l'IETF pour normalisation. Ici, il était divisé en deux parties: transport et HTTP. L'idée est que le protocole de transport peut également être utilisé pour transférer d'autres données, et pas seulement exclusivement pour les protocoles HTTP ou de type HTTP. Cependant, le nom reste le même: QUIC. Le protocole de transport est développé par le groupe de travail QUIC de l'Internet Engineering Council (IETF).

Dans le même temps, Google a continué de travailler sur sa propre implémentation - et l'a implémentée dans le navigateur Chrome. Bien que les tests montrent que l'implémentation QUIC de Google est bien pire que TCP, si le réseau ne garantit pas la livraison des paquets .


Différence en pourcentage des performances entre QUIC avec TCP (en pourcentage) sur un réseau avec RTT 112 ms et gigue 10 ms, source


Différence de performances entre QUIC avec TCP (en pourcentage) sur un réseau avec RTT 112 ms et une gigue de 10 ms, ce qui modifie l'ordre des paquets, la source

Certains développeurs appellent généralement n'importe quelle version de QUIC sur UDP une «expérience la plus folle» .

La discorde dans les versions QUIC et la dénomination est expliquée par Daniel Stenberg, développeur principal de curl chez Mozilla, qui suit cette histoire depuis longtemps.

Selon lui, les noms informels des deux versions de QUIC se sont répandus parmi les développeurs, car les options de l'IETF et de Google varient considérablement dans les détails de mise en œuvre:

• iQUIC (version IETF)
• gQUIC (version Google)

Le protocole d'envoi HTTP sur iQUIC (version IETF) a longtemps été appelé «hq» (HTTP sur QUIC).

En général, il n'y avait pas de nom établi pour les différentes versions. Au séminaire de l'atelier QUIC, Mike Bishop a effrayé tout le monde avec une diapositive comme si c'était un logo.


Diapositive de la présentation de Mike Bishop

Les animateurs de l'atelier ont demandé à Mike de ne plus jamais le montrer .

Cependant, le 7 novembre 2018, l'un des principaux développeurs du protocole, Dmitry Tikhonov, a annoncé que LiteSpeed ​​Tech et Facebook avaient atteint la compatibilité du protocole, et maintenant le développement se poursuivra dans le même sens.

Combiner iQUIC et gQUIC appelé HTTP / 3 en septembre a été proposé par Mark Nottingham, l'un des ingénieurs les plus influents de l'IETF, co-auteur de plusieurs normes Web. Selon lui, cela contribuera à éliminer la confusion entre le transport QIUC et l'encapsuleur QUIC pour HTTP.

Ainsi, HTTP / 3 est la nouvelle version de HTTP qui utilisera le transport QUIC .

QUIC Transport

Quels sont les avantages du protocole de transport QUIC sur TCP? Il existe de nombreux avantages, et selon Mark Nottingham lui-même, la transition d'un protocole TCP obsolète à de nouveaux protocoles est tout simplement inévitable, car il est désormais évident que TCP souffre de problèmes d'inefficacité.

«Étant donné que TCP est un protocole de livraison de paquets dans l'ordre, la perte d'un paquet peut interférer avec la livraison des paquets suivants du tampon à l'application. Dans un protocole multiplexé, cela peut entraîner une grande perte de performances », explique Mark Nottingham. "QUIC essaie de résoudre ce problème en reconstruisant efficacement la sémantique de TCP (ainsi que certains aspects du modèle de flux HTTP / 2) sur UDP."



En plus de passer une quantité importante de trafic de TCP à UDP, Google QUIC (gQUIC) et IETF QUIC (iQUIC) nécessitent un cryptage obligatoire: le QUIC non crypté n'existe pas du tout . iQUIC utilise TLS 1.3 pour définir les clés de session, puis crypter chaque paquet. Mais comme il est basé sur UDP, la plupart des informations de session et des métadonnées ouvertes dans TCP sont chiffrées dans QUIC.

Dans l'article «L'avenir des protocoles Internet», Mark Nottingham parle d'améliorations de sécurité importantes avec le passage à QUIC:

En fait, l'actuel iQUIC «en-tête court» - qui est utilisé pour tous les paquets à l'exception d'une poignée de main - ne donne que le numéro de paquet, l'identificateur de connexion facultatif et l'octet d'état, nécessaires pour des processus tels que la modification des clés de chiffrement et du type de paquet (qui peuvent également être chiffrés). Tout le reste est crypté, y compris les paquets ACK, ce qui augmente considérablement la barre des attaques avec analyse du trafic .

De plus, il devient impossible d'évaluer passivement la RTT et la perte de paquets en surveillant simplement la connexion; il n'y a pas assez d'informations pour cela.

Le manque d'observabilité a suscité de vives inquiétudes chez certains représentants de la communauté des opérateurs de télécommunications. Ils disent que ces mesures passives sont essentielles pour le débogage et l'analyse de leurs réseaux.

L'une des suggestions pour résoudre ce problème est l'introduction d'une mèche . C'est un peu dans l'en-tête qui change sa valeur une fois sur l'aller-retour, afin que l'observateur puisse évaluer le RTT. Comme il n'est pas lié à l'état de l'application, il ne doit pas produire d'informations sur les points de terminaison, à l'exception d'une estimation approximative de l'emplacement du réseau.

L'adoption de la norme QUIC se serait peut-être produite plus tôt si Google ne s'était pas précipité pour implémenter son implémentation dans le navigateur Chrome, alors maintenant la version propriétaire d'iQUIC représente plus de 7% du trafic Internet.

Néanmoins, des progrès sont inévitables - et dans les années à venir, la normalisation et la mise en œuvre généralisée de divers protocoles de nouvelle génération, y compris HTTP / 3 sur le transport QUIC, se poursuivront certainement.

---