Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2018
    Messages
    606
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2018
    Messages : 606
    Points : 18 071
    Points
    18 071
    Par défaut Cloudflare, Google Chrome et Firefox ajoutent le support HTTP/3
    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

    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.

    Nom : cf01.png
Affichages : 4891
Taille : 53,5 Ko

    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.

    Nom : cf03.png
Affichages : 1483
Taille : 35,0 Ko

    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.

    Nom : cf02.png
Affichages : 1483
Taille : 28,0 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Homme Profil pro
    WANT
    Inscrit en
    juin 2011
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Finlande

    Informations professionnelles :
    Activité : WANT

    Informations forums :
    Inscription : juin 2011
    Messages : 30
    Points : 113
    Points
    113
    Par défaut
    D’ou sorte les 40% des sites en http/2 je ne trouve pas dans la source ?

  3. #3
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    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.

  4. #4
    Membre actif
    Profil pro
    Inscrit en
    juin 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 86
    Points : 251
    Points
    251
    Par défaut
    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

  5. #5
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    8 051
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 8 051
    Points : 20 339
    Points
    20 339
    Par défaut
    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 ?
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  6. #6
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    @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.

Discussions similaires

  1. Réponses: 9
    Dernier message: 12/10/2018, 13h56
  2. Réponses: 0
    Dernier message: 30/11/2011, 00h08
  3. Google ajoute le support de WebP dans Chrome, Picasa et Gmail
    Par Hinault Romaric dans le forum Actualités
    Réponses: 13
    Dernier message: 31/05/2011, 20h57
  4. Réponses: 30
    Dernier message: 23/07/2009, 15h27
  5. Réponses: 22
    Dernier message: 06/07/2009, 09h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo