HTTP/3 : pré­sen­ta­tion du nouveau Hypertext Transfer Protocol

Le HTTP/3 est le nouveau membre de la famille de pro­to­coles HTTP et doit remplacer ses pré­dé­ces­seurs : HTTP/1, HTTP/2 et HTTP-over-QUIC. À l’heure actuelle, le HTTP/3 est encore en dé­ve­lop­pe­ment, mais il est déjà supporté par Microsoft Edge, Firefox et depuis avril 2020 par Safari.

La troisième version du standard HTTP a tout d’abord été lancée en tant que « HTTP-over-QUIC » et se base, en tant que protocole ex­pé­ri­men­tal, sur l’UDP. Au départ, HTTP-over-QUIC devait succéder au HTTP/2, mais depuis janvier 2020, ce projet est développé sous le nom de HTTP/3. Il reste à voir à quelle vitesse ce nouveau standard saura s’imposer. Dans tous les cas, le HTTP/3 promet des temps de char­ge­ment réduits et encore plus de sécurité grâce au transfert sécurisé des données par UDP. Cependant, si l’on considère, par exemple, que le protocole HTTP/2 est pris en charge par 80 % des na­vi­ga­teurs depuis sa pu­bli­ca­tion en 2015, mais que son uti­li­sa­tion par les four­nis­seurs progresse lentement, on ne peut pas s’attendre à une aug­men­ta­tion immédiate de la prise en charge du HTTP/3.

En novembre 2018, seulement trois ans après le lancement du standard HTTP/2, la Internet En­gi­nee­ring Task Force (IETF) publiait un nouvel Hypertext Transfer Protocol Standard : le protocole HTTP/3. Avec le HTTP/3 cependant, l’IETF n’a en aucun cas réinventé l’Hypertext Transfer Protocol : elle a seulement pris la mesure de l’époque et conçu un protocole Web qui offre une trans­mis­sion des données plus rapide, plus de sécurité et une connexion plus efficace. En 2012 déjà, Google avait développé le suc­ces­seur du HTTP/2 nommé QUIC (Quick UDP Internet Con­nec­tions) et l’avait im­plé­menté en tant que HTTP-over-QUIC dans de nombreux produits.

Le HTTP/3 réunit désormais les avantages du protocole de transfert HTTP/2 et de HTTP-over-QUIC dans un seul standard pour une trans­mis­sion des données plus rapide et plus stable. Selon les pré­vi­sions, le HTTP/3 devrait remplacer le HTTP/2 basé sur le protocole TCP par une approche basée sur QUIC et donc UDP.

Pour com­prendre la com­po­si­tion du protocole HTTP/3, il faut d’abord com­prendre la fonction de QUIC, UDP et du HTTP/2. En effet, le HTTP/3 est par essence un amalgame de ces trois com­po­sants. Le nom HTTP-over-QUIC indique que le transfert de données s’effectue par UDP au lieu de TCP.

HTTP/2 utilise TCP, le protocole de trans­mis­sion le plus utilisé sur Internet. Le protocole TCP gère les con­nexions via des handshake à plusieurs niveaux et transmet les paquets de données de manière chro­no­lo­gique. Une trans­mis­sion utilisant le protocole TCP ne se poursuit qu’une fois le paquet transmis et reçu. La trans­mis­sion est sécurisée par ce qu’on appelle des ACK, c’est-à-dire des con­fir­ma­tions de commande et de livraison et des numéros de test. Dans le protocole TCP, les données trans­mises con­tien­nent un en-tête avec des pa­ra­mètres qui aident les processus de l’ex­pé­di­teur à se connecter aux processus peer du des­ti­na­taire.

En termes de trans­mis­sion complète des données, TCP est très fiable, mais s’ac­com­pagne cependant « d’em­bou­teil­lages » de données et de temps de char­ge­ment plus longs, car toutes les trans­mis­sions s’arrêtent jusqu’à ce que les paquets de données perdus soient transmis avec succès. Avec le HTTP/2, la famille de protocole Internet atteint donc ses limites dans une certaine mesure, car une ac­cé­lé­ra­tion de la trans­mis­sion de données est im­pos­sible sans nouveau protocole.

Google a donc développé proac­ti­ve­ment son propre protocole de transfert : QUIC. QUIC évite les « em­bou­teil­lages » de données en ayant recours à une trans­mis­sion UDP sans connexion basée sur les da­ta­grammes. Comme TCP, l’UDP travaille au niveau de la couche de transport, mais renonce à la con­fir­ma­tion ex­pé­di­teur-des­ti­na­taire. Les autres flux ne doivent plus attendre la trans­mis­sion réussie des pré­cé­dents. Les allers-retours entre client et serveur sont donc con­si­dé­ra­ble­ment rac­cour­cis. L’IETF a su re­con­naître les avantages de ce nouveau protocole et, en 2018, a lancé HTTP-over-QUIC comme suc­ces­seur du HTTP/2.

Sur le principe, le protocole HTTP reste identique. Il se compose toujours d’un en-tête et d’un corps de message et utilise des verbes, des cookies et la mise en cache. La dif­fé­rence réside dans la manière de trans­mettre les données et le chif­fre­ment intégré en amont.

Le fait de faire fonc­tion­ner le protocole HTTP/2 via QUIC a permis d’apporter des mo­di­fi­ca­tions fonc­tion­nelles concrètes qui ont conduit via HTTP-over-QUIC à la création du HTTP/3.

La fonction majeure de la troisième édition du HTTP est l’uti­li­sa­tion exclusive d’URL HTTPS. Toutes les anciennes URL non sé­cu­ri­sées seront signalées comme dan­ge­reuses ou non chiffrées. Grâce à l’uti­li­sa­tion de QUIC et UDP, HTTP/3 évite notamment l’étape du chif­fre­ment TSL au niveau TCP et utilise au­to­ma­ti­que­ment un chif­fre­ment TLS 1.3. Le HTTP/3 est ainsi uti­li­sable uni­que­ment lorsqu’un chif­fre­ment existe.

Parmi les nouvelles fonctions, on retrouve notamment la connexion per­ma­nente en cas de chan­ge­ment de réseau lors de la trans­mis­sion des données (du côté client ou serveur), un nombre con­si­dé­ra­ble­ment réduit de paquets de données, car les trans­mis­sions de paquets s’ef­fec­tuent via des flux pa­ral­lèles et une « forward error cor­rec­tion », cor­rec­tion d’erreur directe, qui s’effectue di­rec­te­ment au niveau de QUIC.

Les avantages du HTTP/3 sont notamment une vitesse de trans­mis­sion plus élevée, des temps de char­ge­ment plus courts et une connexion stable. En se basant sur UDP, le HTTP/3 évite les points faibles du TCP tout en con­ser­vant les avantages du HTTP/3 et de HTTP-over-QUIC.

Si le HTTP/2 utilise le mul­ti­plexage, c’est-à-dire le té­lé­char­ge­ment simultané de données, cette seconde version souffre encore du Head-of-line Blocking (blocage de tête de ligne (HOL)). Il s’agit d’un goulot d’étran­gle­ment numérique, qui bloque tous les flux lorsqu’une perte de paquet se produit dans un flux. Avec l’uti­li­sa­tion de UDP, le HTTP/3 n’attend pas la réussite de la trans­mis­sion et continue le transfert.

Le HTTP/3 évite les hand­shakes pré­li­mi­naires pour vérifier la sécurité d’une connexion. Au lieu d’envoyer des requêtes de sécurité à la couche TLS su­pé­rieure, le cryptage se fait di­rec­te­ment via le protocole de transfert. Le HTTP/3 réduit ainsi le temps d’éta­blis­se­ment de la connexion de deux à un seul passage.

Pour assurer les té­lé­char­ge­ments, le HTTP/3 n’est plus lié aux adresses IP, mais utilise des iden­ti­fiants de connexion in­di­vi­duels qui per­met­tent un té­lé­char­ge­ment constant même en cas de chan­ge­ment de réseau.

Pour les uti­li­sa­teurs de réseau mobile, le HTTP/3 devrait assurer une na­vi­ga­tion plus agréable grâce à une connexion plus stable, plus flexible et plus sûre.

Découvrez ci-dessous un rapide résumé des si­mi­la­ri­tés et dif­fé­rences entre le HTTP/2 et le HTTP/3.

Dif­fé­rences :

• Le HTTP/3 utilise UDP con­trai­re­ment au HTTP/2 qui utilise TCP.
• Grâce au chif­fre­ment intégré TLS 1.3, le HTTP/3 évite une requête de chif­fre­ment sup­plé­men­taire (handshake) au niveau TLS et supprime ainsi les requêtes de sécurité su­per­flues.
• Con­trai­re­ment au HTTP/2, le HTTP/3 supporte uni­que­ment les con­nexions chiffrées en raison du chif­fre­ment intégré TLS 1.3.

Si­mi­la­ri­tés :

• Les deux pro­to­coles utilisent la com­pres­sion d’en-tête. Le HTTP/3, cependant, remplace la com­pres­sion HPACK HTTP/2 liée à une séquence de paquets par QPACK.
• Comme le HTTP/2, le HTTP/3 prend en charge le Server Push, c’est-à-dire l’ex­pé­di­tion accélérée des données CSS et Ja­vaS­cript dont le na­vi­ga­teur a besoin pour afficher une page.
• Les deux pro­to­coles utilisent le mul­ti­plexage requête-réponse, c’est-à-dire les flux pa­ral­lèles de données de dif­fé­rentes res­sources.
• La prio­ri­sa­tion des flux dans les deux pro­to­coles assure que le contenu de la page est chargé en priorité sans attendre la no­ti­fi­ca­tion de réussite des autres requêtes.

De nom­breuses critiques du HTTP/3 se basent sur le fait qu’il arrive très tôt après le lancement du protocole HTTP/2 et que l’UDP est un protocole réseau critiqué. En outre, ce sont avant tout les uti­li­sa­teurs qui bé­né­fi­cie­ront du nouveau protocole HTTP. Les four­nis­seurs se voient en revanche con­fron­tés à un certain nombre d’obstacles avec le rem­pla­ce­ment de TCP et TLS par UDP et QUIC

La vé­ri­fi­ca­tion de sécurité et le chif­fre­ment ne se font plus par TLS, mais di­rec­te­ment par UDP et UDP doit livrer autant de paquets aussi vite que possible et les four­nis­seurs craignent que le trafic de données ne soit plus suf­fi­sam­ment contrôlé sans l’au­then­ti­fi­ca­tion TLS. La sécurité des ap­pli­ca­tions et des données est donc la prin­ci­pale critique des four­nis­seurs d’accès à Internet. Le TCP était considéré comme un protocole fiable et axé sur la connexion en raison de sa règle claire de requête-réponse. Le fait que QUIC prenne lui-même en charge un certain nombre d’étapes se­con­daires fait craindre une réduction des pos­si­bi­li­tés de contrôle par les four­nis­seurs en HTTP/3 et donc une mul­ti­pli­ca­tion des logiciels mal­veil­lants dans les flux de données.

Dans la mesure où l’offre crois­sante de données mé­dia­tiques – telles que les images, les vidéos et autres éléments de réseaux sociaux – exige une trans­mis­sion de données plus rapide, il faut espérer, dans l’intérêt des uti­li­sa­teurs, que la famille des pro­to­coles Internet se mette en mouvement et que les four­nis­seurs seront en mesure de suivre l’évolution toujours plus rapide d’Internet.