Un support préliminaire avait été lancé en septembre 2018. Après plus d’un an de tests divers, notamment avec Google et Mozilla, Cloudflare annonce que HTTP/3 est prêt de son côté. La dernière préversion Canary de Chrome est compatible, Firefox Nightly le sera très bientôt.
HTTP/3 est pour rappel la troisième version majeure du protocole HTTP. La plupart de ses nouveautés proviennent du protocole QUIC, initialement créé par Google. HTTP/3 s’appelait d’ailleurs au départ « HTTP-over-QUIC ».
Principale différence, HTTP/3 est basé sur UDP, et non TCP. Accompagné de nouveaux mécanismes de contrôle, prévu directement pour TLS 1.3 et le chiffrement de bout en bout, HTTP/3 permet notamment une hausse des performances et un passage plus transparent entre les connexions, par exemple lors d’une bascule du Wi-Fi vers la 4G, ou entre plusieurs antennes cellulaires.
L’ensemble reste donc expérimental. Le protocole est toujours à l’état de brouillon entre les mains de l’IETF, mais Cloudflare résume la situation par une analogie au programme de l’œuf et la poule. Il est toujours complexe d’intervenir sur un protocole réseau : qui doit initier le support, le serveur ou le client ?
Les sites inscrits chez Cloudflare peuvent quoi qu’il en soit activer le support de HTTP/3 et commencer à tester le protocole.
Commentaires (35)
#1
Si quelqu’un a déjà vu le truc, ca marche comment derrière un load-balancer ca ? Car autant du HTTP 1⁄2, c’est du TCP du coup connecté, autant UDP c’est des paquets indépendants.
#2
Y a que moi que ça surprend que cette techno utilise UDP ?
Va falloir revoir toutes les règles de pare-feu si le HTTP/3 devient la norme ?
#3
De l’UDP.
" />
C’est vrai que le web est TELLEMENT lent aujourd’hui.
Si un paquet est perdu, il faudra recharger la page du coup?
#4
#5
Donc si je comprends bien, quand quelques années avec le HTTP/3, tout le web sera en UDP?
#6
C’est géré par le protocole. Et dis toi que tu n’es pas la cible de ces améliorations de performances. C’est plutôt pour tous les pays aux connexion erratiques ou lentes.
#7
Ca te fait si peur que ça ?
#8
Pour moi l’UDP c’est + pour le streaming et les jeux en ligne, pas pour de l’info texte.
" />
#9
On a toujours dit que l’UDP c’était pour les données qui “pouvaient se perdre”, comme le streaming. Mais si tu y repenses, dans le cas du jeu vidéo, t’as pas vraiment envie que les données se perdent, et pourtant ça passe bien par de l’UDP, parce que ce protocole est bien plus rapide.
En fait il suffit de déporter la vérification de réception des données dans une couche supérieure du protocole d’échange et d’utiliser l’UDP. Aujourd’hui on sait faire plus efficace que le TCP pour éviter les pertes de packets, et c’est ce que propose google avec le HTTP/3.
#10
#11
#12
J’ai eu la même question.
Apparemment les LB comment à intégrer une option pour (je n’ai trouvé que le lien, pas regardé le contenu en détail):https://cloud.google.com/blog/products/gcp/introducing-quic-support-https-load-b…
Je vais quand même creuser le sujet dans la semaine.
#13
#14
L’avantage de TCP c’est que ça garde http très simple vu que TCP s’occupe de la partie retransmission, remise en l’ordre des segments, checksum, etc…
Si on deporte cette complexité dans le protocole http directement , les lib http vont être plus grosses, plus complexes, et donc plus buggé. Autant pour firefox et chrome, ça ne sera pas un problème pour patcher. Autant pour les milliards d’objets connectés, j’ai plus de doute.
#15
100% d’accord.
Pour compléter ton commentaire sur le Doh, autant pour un pays surveillé ou censuré, c’est une évolution.
Autant pour un pays libre, c’est une régression. Doh est sensé protéger la vie privée, mais le seul truc que ça fait, c’est de centraliser toutes les requêtes DNS chez le géant américain cloudflare… Pour la protection de la vie privée, on a vu mieux…
#16
Quelques rappels :
#17
La description « HTTP/3 est basé sur UDP, et non TCP » est à la fois exacte et très trompeuse. Et cela explique beaucoup des questions posées ici. QUIC est un concurrent de TCP. Il en assure toutes les fonctions (dont la réémission en cas de perte de paquet).
QUIC devrait, dans un monde idéal, fonctionner directement sur IP. Mais comme les « middleboxes » à la c… l’empêchent, il tournera sur UDP, comme tout autre protocole de transport nouveau (SCTP avait déjà montré le chemin). UDP n’est donc qu’une très mince couche entre IP et QUIC, le « vrai » protocole de transport.
#18
Non, en QUIC. UDP n’est là que pour calmer les middleboxes stupides.
#19
Il n’est pas prévu de faire traiter les problèmes de congestion, de réémission, etc, par HTTP. C’est QUIC qui le fera. « HTTP/3 » n’est qu’une étiquette marketing, sans significtaion technique. (Le passage de HTTP/1 à HTTP/2 avait entrainé bien plus de changements.)
#20
Euh non, rien à voir. Vous confondez DoH (un protocole) avec Cloudflare (une société).https://www.bortzmeyer.org/doh-et-ses-adversaires.html
#21
C’est possible d’activer le http3 sur son propre serveur ou il faut absolument s’appeler Cloudflare pour le faire ? Je trouve aucune info sur le sujet. Je veux pas mettre ça en prod mais j’aimerai bien voir les résultats sur mes benchs de performance pour voir si c’est vraiment plus rapide.
#22
Non, tout dépend du protocole. UDP n’indique n’a
#23
#24
Personnellement, je trouve que l’usa
#25
#26
Apparement, sur NXI, les corrections de commentaires ne sont plus prises en compte depuis le passage à UDP
#27
Le RFC n’est pas encore sorti. Il existe des mises en œuvre en logiciel libre (dont une de Cloudflare) mais rien de très intégré aux serveurs HTTP existants, je crois.
#28
L’hybridation de protocole existe déjà en entreprise. Pour avoir un peu bossé sur le protocole de citrix , dtls/ edt, basé sur udt, la partie tcp s’occupe du checksum et rentransmission.l’udp s’occupe de la données. Et si il y a un problème sur la connexion, la données bascule en tcp (retour en udp possible quand la connexions le permet). C’est actif par défaut depuis 2ans chez les clients. Ça marche bien et le troubleshooting n’est pas trop compliqué. Et de mémoire udt fonctionne de la même manière que quic (je serais curieux de savoir quels sont les différences)
#29
Il se passe dans les protocole de niveau 4 du modèle OSI ce qui s’est passé pour les couches les plus basses il y a (oups, déjà!) quelques décennies.
Le fait que la couche 1 a largement progressé en terme de fiabilité de transmission du signal qu’on a pu alléger les contrôles faits sur la couche 2, ce qui a accéléré les protocoles. En allégeant X25 on a fait Frame Relay, et ISDN (RNIS en français) est à la base de l’ATM. Le taux de perte de trames dont il faut demander la retransmission est suffisamment faible pour garder l’avantage apporté par l’abandon du CRC. En ATM, les équipements réseau commencent à transmettre au peer suivant dès l’en-tête reçu: puisqu’on se moque de tester la trame, pourquoi attendre qu’elle soit complètement reçue? Dès que’on peut faire un check de l’en-tête, c’est bon. En terme de latence, le gain est la différence entre émettre un en-tête et émettre tout une trame, environ 10 fois plus rapide.
L’intérêt de ces avancées y compris maintenant sur la couche 4 permet d’avoir le support de protocoles hauts dans lesquels on ajoute des mécanismes de sécurité qui ont pour conséquence d’alourdir les échanges.
#30
#31
Le navigateur ne peut pas faire la résolution en TLS, il n’y a pas (encore ?) de norme pour parler en TLS aux serveurs faisant autorité. (Le RFC 7858, DNS sur TLS, est pour le lien entre M. Michu et le résolveur.)
#32
#33
QUIC utilise le numéro d’UDP.
Le choix d’UDP a été fait parce que c’etait le seul dispo avec TCP de facon universelle dans les stacks IP des OS.
QUIC est né du fait qu’il est très lent de faire évoluer les stacks réseaux des OS. Chacun a sa mis en oeuvre avec des fois des optimisations bas niveau dans les drivers des cartes réseaux (offload udp et tcp par exemple, calcul de checksum etc).
Faire évoluer les couches basses et communes des réseaux est donc tres lent , trop lent pour des sociétés comme Google et Cloudflare. L’objectif initial de QUIC était de remplacer TCP par quelque chose de plus moderne, performant et adapter au débit et contraintes des liaisons réseau actuelles. La solution retenue est donc d’utiliser UDP qui est dispo, géré et optimisé partout et de batir dessus un “nouveau TCP”. C’est plus immédiat et ne dépend pas du bon vouloir des autres acteurs du réseau (OS, drivers, routeurs, FAI, etc).
#34
Le problème de ce qui est disponible dans les systèmes d’exploitation est secondaire (tout le monde utilise un Unix donc a SCTP depuis longtemps, par exemple) par rapport au problème des middleboxes (boitiers intermédiaires) qui bloquent tout ce qu’ils ne connaissent pas.
#35
c’est toute la chaine pas que les middlesboxes. je ne suis pas certain que le SCTP dispo sur certains OS soit aussi optimisé que le sont TCP et UDP (notamment par les optis dans les drivers). et y’a pas que Unix, le gros des clients est sur Windows.
Apres je ne reprenais que les propos des créateurs de QUIC pas les miens. Il est certain que c’est plusieurs facteurs qui ont contribué a ce choix.