Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Cloudflare, Google Chrome et Firefox ajoutent le support HTTP/3,
Donnant ainsi un coup de pouce dans l'adoption rapide de la prochaine version du protocole HTTP

Le , par Stan Adkens

58PARTAGES

9  0 
Cloudflare a annoncé jeudi que le support HTTP/3 est maintenant disponible sur son réseau edge. Dorénavant, ses clients pourront activer une option dans leurs tableaux de bord et activer le support HTTP/3 pour leurs domaines. Le réseau de diffusion de contenu (CDN) a aussi indiqué que Google Chrome et Mozilla Firefox, deux des principaux fournisseurs de navigateurs, se sont joints à lui dans ses efforts pour rendre le Web plus rapide et plus fiable. L’ajout par Cloudflare, Google Chrome et Firefox du support HTTP/3, constitue un grand coup de pouce pour la prochaine itération majeure du protocole HTTP et un début d’un changement majeur pour les utilisateurs d’Internet.

Cloudflare dit qu’une fois que le support HTTP/3 activé pour le domaine d’un client dans son tableau de bord Cloudflare, ce client pourra interagir avec ses sites Web et API en utilisant HTTP/3. Google a ajouté, dans Chrome Canary, la prise en charge du nouveau protocole au début du mois. Cela signifie que chaque fois que les utilisateurs visitent un site Web hébergé sur Cloudflare à partir du Chrome Canary ou autres navigateurs compatibles HTTP/3, la connexion passe automatiquement au nouveau protocole, plutôt que d'être gérée via des versions antérieures. Mozilla va également déployer la prise en charge de HTTP/3. Le fabricant du navigateur devrait livrer HTTP/3 dans une prochaine version de Firefox Nightly plus tard cet automne.


Depuis l'année dernière, Cloudflare avait annoncé un support préliminaire pour QUIC et HTTP/3 (ou "http-over-QUIC" comme on l'appelait à l'époque, avant d’être rebaptisé en novembre 2018 pour devenir officiellement HTTP / 3). Le nouveau standard du Web permet des connexions plus rapides, plus fiables et plus sécurisées aux terminaux web comme les sites Web et les API. Cloudflare avait permis également à ses clients de s'inscrire sur une liste d'attente pour essayer QUIC et HTTP/3 dès qu'ils seront disponibles.

HTTP/3 est la prochaine version majeure de HTTP, le protocole par lequel le contenu passe des serveurs aux clients, où il est affiché dans les navigateurs, applications mobiles ou autres applications. Cloudflare dit qu’il a depuis lors travaillé en collaboration avec ses pairs de l'industrie par l'intermédiaire de l'Internet Engineering Task Force, y compris Google Chrome et Mozilla Firefox, pour itérer sur les documents des normes HTTP/3 et QUIC.

Selon Ryan Hamilton, ingénieur logiciel chez Google, « HTTP/3 devrait rendre le Web meilleur pour tous. Les équipes Chrome et Cloudflare ont travaillé en étroite collaboration pour faire passer HTTP/3 et QUIC des normes naissantes aux technologies largement adoptées pour améliorer le Web. Un partenariat solide entre les leaders de l'industrie est ce qui rend possibles les innovations en matière de normes Internet, et nous nous réjouissons de continuer à travailler ensemble ».

HTTP v3 ou HTTP/3, la prochaine version majeure de HTTP différente des versions précédentes

Pour rappel, HTTP (un protocole de couche 7 du modèle OSI) utilise TCP, Transmission Control Protocol (un protocole de couche 4), comme base par défaut. TCP est utilisé pour négocier les connexions entre les clients et les serveurs, puis déplacer les données entre les deux parties, d'où sa catégorisation en tant que protocole de transport.

Il faut rappeler également que le protocole TCP a été conçu dans les années 70, et personne ne s'attendait à ce qu'il soit utilisé pour les communications en temps quasi réel, comme c'est le cas aujourd'hui. Au fur et à mesure que le temps passe, les applications évoluent et requièrent de la vitesse, et les ingénieurs en logiciel ont commencé à comprendre que TCP n'a jamais été conçu pour répondre aux exigences de la rapidité. Ils ont donc commencé à envisager d’autres options de protocole pour rendre l’Internet plus rapide.


C’est ainsi que les ingénieurs de Google ont d'abord créé le protocole réseau SPDY qui corrigeait certains des problèmes de TCP. L’Internet est passé donc au HTTP-over-SPDY, un protocole qui est finalement devenu officiellement HTTP/2 et qui est maintenant utilisé sur environ 40 % des sites Internet.

À partir de SPDY, les ingénieurs de Google se sont rendu compte qu'ils pourraient faire beaucoup mieux s'ils combinaient la fiabilité de TCP et la vitesse d'UDP ensemble dans un protocole totalement nouveau. C'est ainsi qu'est né QUIC, ou « Quick UDP Internet Connections », un nouveau protocole qui fusionne les meilleures fonctionnalités de TCP et UDP, afin de construire un protocole de transport de couche 4 encore plus rapide.

C’est en cela que HTTP-over-QUIC, devenu HTTP/3 ensuite, est différent de toutes les versions qui l'ont précédé. Il s'agit d'une réécriture complète du protocole HTTP qui utilise le protocole QUIC au lieu du protocole TCP, et est également livré avec un support TLS, une norme de sécurisation par chiffrement du transport de l'information, intégré. Avec HTTP/3, il n’y aura pas de blocage en tête de ligne de tous les flux lorsqu'une connexion multiplexée a une défaillance dans un flux. Le HTTP/3 permettra également une configuration plus rapide de la connexion sur les réseaux à temps de latence élevée.


L’ajout du support HTTP/3, un coup de pouce au processus d’adoption du nouveau protocole

Du côté navigateur, Cloudflare a indiqué dans son article de blog que le support initial a été ajouté dans Chrome 29 et Opera 16. Firefox ajoutera également le support HTTP/3 en automne. Du côté serveur, les serveurs LiteSpeed ont déjà le support. Mais la grande nouveauté est Cloudflare qui rend le protocole généralement disponible pour ses clients.

En effet, le réseau de diffusion de contenu (CDN) est un acteur majeur sur le Web, avec environ 10 % de l'ensemble des sites Internet. Le fait que l'entreprise déploie le support HTTP/3, l’adoption sera plus large et plus rapide. Un porte-parole de Cloudflare a déclaré :

« Cloudflare a été l'un des principaux moteurs de l'adoption du H2 après avoir lancé son support HTTP/2 pour tous ses clients en décembre 2015. En fait, Cloudflare est toujours le moteur de la majorité du Web HTTP/2 ».

QUIC et HTTP/3 promettent de combler bon nombre des lacunes des normes précédentes et d'inaugurer une nouvelle ère de performance sur le Web. Afin d'utiliser le navigateur Chrome pour vous connecter à votre site Web via HTTP/3, vous devez avoir installé la dernière version de Chrome Canary. Ensuite, tout ce que vous aurez à faire pour activer le support HTTP/3 est de démarrer Chrome Canary avec les arguments « --enable-quic » et « --quic-version=h3-23 » en ligne de commande.

Sources : Cloudflare

Et vous ?

Que pensez-vous de l’ajout du support HTTP/3 par Cloudflare ?
Quels sont les avantages du HTTP/3 que vous retenez ?

Lire aussi

Le protocole HTTP-over-QUIC change de nom et devient officiellement HTTP / 3, pour éviter la confusion avec QUIC, le protocole de transport
Google dévoile son nouveau protocole QUIC dans Chrome, qui combine le meilleur de TCP et UDP
Google projette de proposer son protocole QUIC à l'IETF, pour un internet plus rapide

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Bardotj
Membre régulier https://www.developpez.com
Le 27/09/2019 à 17:15
D’ou sorte les 40% des sites en http/2 je ne trouve pas dans la source ?
2  0 
Avatar de defZero
Membre actif https://www.developpez.com
Le 28/09/2019 à 0:23
Article très intéressant.
Si je comprend bien ils ont juste décidés de faire passer la couche Transport de HTTP du TCP vers UDP.
Donc on va perdre les avantages du TCP (ACK/Re-EMIT, Sessions, ..etc) qui devrons, de faite, être re-coder dans la couche Applicative et gagner les avantages d'UDP (low latency, Datagram, ...etc).

À partir de SPDY, les ingénieurs de Google se sont rendu compte qu'ils pourraient faire beaucoup mieux s'ils combinaient la fiabilité de TCP et la vitesse d'UDP ensemble dans un protocole totalement nouveau.
C'est ainsi qu'est né QUIC, ou « Quick UDP Internet Connections », un nouveau protocole qui fusionne les meilleures fonctionnalités de TCP et UDP, afin de construire un protocole de transport de couche 4 encore plus rapide.
Je veut pas être méchant, mais sans être ingénieur chez Google je croit que toutes les personnes ayant fait du réseau s'en étaient rendu compte de ça, TCP plus sure mais plus lent vs. UDP plus rapide mais sans garanties.
De plus, ils ne réinvente rien mais vont tout faire passer dans UDP.
Le côté faire beaucoup mieux m'as fait rigolé du coup.

Il faut rappeler également que le protocole TCP a été conçu dans les années 70, et personne ne s'attendait à ce qu'il soit utilisé pour les communications en temps quasi réel, comme c'est le cas aujourd'hui.
Oui et ? UDP c'est les années 80 et TCP n'as jamais été conçue pour du Soft ou Hard RealTime.
C'est pas de la faute aux protocoles si les Ingénieurs de Google les utilisent mal.
Je peut toujours enfoncer un clou avec une pierre, maintenant est-ce que je vais dire que c'est de la faute au marteaux si ça ne fonctionnent pas terrible ?
C'est exactement pour ça qu'il existe moultes autres protocoles chacun ayant son utilité/sa spécificité (communications temps réelle, Sync/Async ...etc).
Ce que je retient et ne comprend absolument pas, justement d'un point de vu ingénierie, c'est POURQUOI ?
Il ne réinvente, ni n’améliore rien, ils veulent juste inclure un max de truc dans 1 seule protocole à tout faire, ce qui est Uber stupide.

Au fur et à mesure que le temps passe, les applications évoluent et requièrent de la vitesse, et les ingénieurs en logiciel ont commencé à comprendre que TCP n'a jamais été conçu pour répondre aux exigences de la rapidité.
C'est bien qu'il commencent à comprendre , parce que ceux qui ont conçue le protocole ne le destinez simplement pas à cet usage dès le départ.
Dans le cahier des charges originel c'était "HyperText Transport Protocole", pas "Client à tout faire Protocole".

Ils ont donc commencé à envisager d’autres options de protocole pour rendre l’Internet plus rapide.
Sauf qu'encore une fois il n'invente rien ils ce contente d'encapsuler toute leur machinerie dans UDP et en adaptant HTTP par dessus.

Un jour je pense qu'ils vont nous vendre un Protocole Applicatif en pure "Bytecode" (HTTP/5 over UDP), c'est ce qui serait le plus logique si on ne vise que la vitesse.
1  0 
Avatar de defZero
Membre actif https://www.developpez.com
Le 10/10/2019 à 23:59
@walfrat
Etant donné que n'importe quel étudiant qui n'a pas été dispensé d'apprendre le model OSI sait ça.
Je pense surtout que l'article qu'on a là est probablement trop sommaire pour qu'on puisse vraiment se permettre une tel critique.
A moins d'avoir fait ses propres recherches.

La seule info que je vois est qu'il y a une passe de connexion en Quic, il n'ya plus les flag SYN/ACK mais il y a peut-être toujours les champs qui vont bien pour vérifier que les trames arrivent entière.
Ou peut-être pas car on en a peut-être plus autant besoin que ça aujourd'hui ?
J'en sais rien et malheureusement cet article n'est pas assez détaillé pour qu'on puisse le savoir.

De plus, il est clairement dit que s'ils ont choisi de se baser sur UDP, c'est parce que les pare-feu ne le bloque pas par défaut, comme TCP.
Et si ça peut te sembler anodin, je peux te dire que cette raison me paraît déjà très solide.

En parlant de faire ses propres recherches, un petit tour sur Wikipedia indique bien que Quic gère les paquet perdus à son niveau.
Mais si, on a plein d'info utile d'un point de vue implémentation :
  • HTTP/3 est basé sur QUIC, lui même basé sur UDP.
    On a dès lors plus de Trame TCP, mais des Datagram UDP, dans lesquels la payload contient des messages QUIC, contenant eux même une payload HTTP/3 encrypter via TLS.
  • QUIC est un protocole de niveau Applicatif, puisqu'il fait lui même sont contrôle d'erreur par dessus UDP.
    Pour rappelle le modèle OSI est théorique, la pile TCP/IP réellement implémenté n'as que 4 couches NetAcces/Internet/Transport/Application.
  • UDP comme TCP sont/doivent être bloquer (et ouvert seulement au besoin) par tous Firewall/AdminSys qui ce respect.
    Où est-il fait mention de cela dans l'article ?
    MAis dans tous les cas, c'est juste faux.
  • En fait lorsque l'article évoque HTTP/3 c'est la même chose que lorsque l'on évoque HTML5, sa ne représente que la partie visible.
    En l’occurrence pour qu'une implémentation de HTTP/3 soit valide il faut, à minima, un transport via UDP, contenant des messages QUIC (qui s'occupe de l'intégrité, multiplexage, ..etc), contenant eux même le fameux HTTP/3 obligatoirement encrypter via TLS (contenant peut-être de nouveaux Header, ..etc, ça en effet ce n'est pas précisé dans l'article).


D'ailleurs en suivant ton lien on voit bien ce que j'expliquais dans mon 1er poste.
Avant on avait un protocole par usage et c'est comme ça que l'Internet devrait être construit, pas en voulant tout faire passer dans un seule protocole four tout, pour qu'un seule client/serveur soit plus simple à implémenter/maintenir/administrer.
Google essais de créer un problème, pour justifier une solution, c'est quand même singulier.

@Neckara
Je n'ai pas tout suivi.

Google et Firefox poussent un HTTP/3 et HTTP/2 qui améliorer les performances de l'usuel HTTP over TCP.

Pourtant, la tendance n'était-elle pas à la suppression/obsolescence de HTTP au profit de HTTPS ?
D'où l'initiative de Let's encrypt, ou l'annonce de Google de marquer "non-sûre" les connexions HTTP ?
Quand on parle de HTTP/2 ou 3, on parle de la pile protocolaire/plateforme en générale.
Sachant que HTTP/2 devait rendre obligatoire le chiffrement par TLS, mais qu'au dernier moment ce n'est devenue qu'optionnel dans la spec.
Avec HTTP/3 toutes les connexions devront être chiffré en TLS (pas d'info sur la version cependant, mais j’espère un 1.3).
En effet la tendance va à l' abandon/interdiction du trafic non chiffré (d'où le comportement de Google/Chrome), on peut voir ça comme une forme de dépréciation dans une API logiciel.
Enfin, l'initiative Let's Encrypt (grand merci à eux), permet de mettre gratuitement des certificats, signés par une CA reconnu par les OS/Navigateur, à disposition du plus grand nombre.
Les certificats coutant honteusement cher pour ce qu'ils sont et le chiffrage des communication devenant de fait la norme/obligatoire, il aurait était mal venue de demander à tous de banquer pour ce conformer à une norme ouverte tel que HTTP.
De plus grâce à eux et à la communauté, les AdminSys/DevOPS ont put avoir accès à des outils standardisé/multiplateform de renouvellement automatisé des certificats en fin de validité, ce qui n'est pas rien.
1  0 
Avatar de walfrat
Membre actif https://www.developpez.com
Le 30/09/2019 à 9:01
Citation Envoyé par defZero Voir le message
Article très intéressant.
Si je comprend bien ils ont juste décidés de faire passer la couche Transport de HTTP du TCP vers UDP.
Donc on va perdre les avantages du TCP (ACK/Re-EMIT, Sessions, ..etc) qui devrons, de faite, être re-coder dans la couche Applicative et gagner les avantages d'UDP (low latency, Datagram, ...etc).

Je veut pas être méchant, mais sans être ingénieur chez Google je croit que toutes les personnes ayant fait du réseau s'en étaient rendu compte de ça, TCP plus sure mais plus lent vs. UDP plus rapide mais sans garanties.
De plus, ils ne réinvente rien mais vont tout faire passer dans UDP.
Le côté faire beaucoup mieux m'as fait rigolé du coup.

Oui et ? UDP c'est les années 80 et TCP n'as jamais été conçue pour du Soft ou Hard RealTime.
C'est pas de la faute aux protocoles si les Ingénieurs de Google les utilisent mal.
Je peut toujours enfoncer un clou avec une pierre, maintenant est-ce que je vais dire que c'est de la faute au marteaux si ça ne fonctionnent pas terrible ?
C'est exactement pour ça qu'il existe moultes autres protocoles chacun ayant son utilité/sa spécificité (communications temps réelle, Sync/Async ...etc).
Ce que je retient et ne comprend absolument pas, justement d'un point de vu ingénierie, c'est POURQUOI ?
Il ne réinvente, ni n’améliore rien, ils veulent juste inclure un max de truc dans 1 seule protocole à tout faire, ce qui est Uber stupide.

C'est bien qu'il commencent à comprendre , parce que ceux qui ont conçue le protocole ne le destinez simplement pas à cet usage dès le départ.
Dans le cahier des charges originel c'était "HyperText Transport Protocole", pas "Client à tout faire Protocole".

Sauf qu'encore une fois il n'invente rien ils ce contente d'encapsuler toute leur machinerie dans UDP et en adaptant HTTP par dessus.

Un jour je pense qu'ils vont nous vendre un Protocole Applicatif en pure "Bytecode" (HTTP/5 over UDP), c'est ce qui serait le plus logique si on ne vise que la vitesse.
Etant donné que n'importe quel étudiant qui n'a pas été dispensé d'apprendre le model OSI sait ça. Je pense surtout que l'article qu'on a là est probablement trop sommaire pour qu'on puisse vraiment se permettre une tel critique. A moins d'avoir fait ses propres recherches.

La seule info que je vois est qu'il y a une passe de connexion en Quic, il n'ya plus les flag SYN/ACK mais il y a peut-être toujours les champs qui vont bien pour vérifier que les trames arrivent entière.
Ou peut-être pas car on en a peut-être plus autant besoin que ça aujourd'hui ? J'en sais rien et malheureusement cet article n'est pas assez détaillé pour qu'on puisse le savoir.

De plus, il est clairement dit que s'ils ont choisi de se baser sur UDP, c'est parce que les pare-feu ne le bloque pas par défaut, comme TCP. Et si ça peut te sembler anodin, je peux te dire que cette raison me paraît déjà très solide.

En parlant de faire ses propres recherches, un petit tour sur Wikipedia indique bien que Quic gère les paquet perdus à son niveau.

QUIC uses UDP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.
https://en.wikipedia.org/wiki/QUIC
0  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 01/10/2019 à 5:38
Je n'ai pas tout suivi.

Google et Firefox poussent un HTTP/3 et HTTP/2 qui améliorer les performances de l'usuel HTTP over TCP.

Pourtant, la tendance n'était-elle pas à la suppression/obsolescence de HTTP au profit de HTTPS ?
D'où l'initiative de Let's encrypt, ou l'annonce de Google de marquer "non-sûre" les connexions HTTP ?
0  0