Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ietf:http3 [2019/01/25 19:04]
Serge GOMA
+++ ietf:http3 [2019/01/26 03:41] (Version actuelle)
Serge GOMA [Pourquoi QUIC]
@@ Ligne 3: / Ligne 3: @@
 QUIC est un acronyme  qui se prononce comme le mot anglais "quick"
-QUIC est défini [[https://datatracker.ietf.org/doc/draft-ietf-quic-transport/]] celui qui pourrait être perçu comme un moyen de créer un nouveau protocole de transport fiable Fiable et sécurisé, qui pourrait etre adopté a n importe quel autre protocole comme le DNS, le HTTP, dans le cadre de cet article il vient pour résoudre certains des inconvénients connus de HTTP/2 sur le TCP et TLS ce qui forcement une prochaine étape de l évolution de WEB.
+QUIC est défini [[https://datatracker.ietf.org/doc/draft-ietf-quic-transport/]] celui qui pourrait être perçu comme un moyen de créer un nouveau protocole de transport fiable  et sécurisé, qui pourrait s' adopté a n importe quel autre protocole comme le DNS, le HTTP. Dans le cadre de cet article, QUIC vient pour résoudre certains des inconvénients connus de HTTP/2 sur le TCP et TLS ce qui forcement une prochaine étape de l évolution de WEB.
 Dans le souci de rendre le web et les données en général plus rapides pour les end user est la principale raison qui à initier le développement de ce protocole.
@@ Ligne 70: / Ligne 70: @@
 il existe plusieurs standard améliorer par IETF qui ne sont pas suffisamment déployés ou utilisés
+===== Sécurisé =====
+Considéré comme un sécurisé QUIC n pas de version en texte clair ou du clair protocole, ainsi une négociation d "une connexion se fait par la cryptographie et la sécurité TLS1.3, justement pour empêcher l ossification  ainsi que d autres types de blocages et traitements spéciaux, à coté de cela il y a quelques paquets handshakes initiaux qui sont envoyés en claire, avant que les protocoles de cryptages aient été négociés
+=== Données antérieures ===
+QUIC offre à la fois des handshakes 0-RTT et 1-RTT qui réduisent le temps nécessaire pour négocier et établir une nouvelle connexion. Comparez avec le handshake à 3 voies du TCP.
+En plus de ça, QUIC offre une prise en charge des "données antérieures" dès le départ, ce qui est fait pour autoriser plus de données et est utilisé plus facilement que TCP Fast Open.
+Avec le concept de flux, vous pouvez établir une autre connexion logique avec le même hôte sans avoir à d'abord attendre la  fin de la connexion existante
+{{https://wiki.osc.cg/_media/ietf/0rtt-graphic.png}}
+=== TCP Fast Open est problématique ====
+TCP Fast Open a été publié en décembre 2014 en tant que la RFC 7413 {{https://tools.ietf.org/html/rfc7413}} et cette spécification explique comment les applications peuvent transmettre des données au serveur afin qu'elles soient déjà livrées dans le premier paquet TCP SYN.
+La prise en charge effective de cette fonctionnalité a pris du temps et pose encore de nombreux problèmes, même aujourd'hui en 2018. Les responsables de la mise en œuvre de la stack TCP ont rencontré des problèmes, tout comme les applications qui ont essayé de tirer parti de cette fonctionnalité, en sachant dans quelle version d'OS essayer pour l'activer mais également pour savoir comment revenir en arrière avec élégance et régler les problèmes qui surviennent. Plusieurs réseaux ont été identifiés pour interférer avec le trafic TFO et ont donc activement ruiné de telles handshakes TCP.
+===== La procédure =====
+Le protocole QUIC originel a été conçu par Jim Roskind chez Google et a été initialement mis en œuvre en 2012, puis annoncé publiquement au monde en 2013 lorsque l'expérimentation de Google s'est élargie.
+À l'époque, il était toujours prétendu que QUIC était l'acronyme de "Quick UDP Internet Connections", mais il a été
+abandonné depuis.
+Google a mis en œuvre le protocole et l'a ensuite déployé à la fois dans son navigateur beaucoup utilisé (Chrome) et dans ses services côté serveur beaucoup utilisés (Google search, gmail, youtube, etc...). Ils ont répété les versions du protocole assez rapidement et, avec le temps, ils ont prouvé que le concept fonctionnait de manière fiable pour une grande partie
+des utilisateurs.
+En juin 2015, le premier brouillon Internet pour QUIC a été envoyé à l'IETF pour une standardisation, mais il a fallu attendre la fin de l'année 2016 pour qu'un groupe de travail QUIC soit approuvé et lancé. Mais ensuite, il a immédiatement décollé avec beaucoup d'intérêt de la part de nombreux partis.
+En 2017, des chiffres cités par les ingénieurs de QUIC chez Google ont indiqué qu'environ 7% de tout le trafic Internet utilisait déjà ce protocole. La version de Google du protocole
+===== IETF =====
+Le groupe de travail QUIC mis en place pour standardiser le protocole au sein de l'IETF a rapidement décidé que le protocole QUIC devait pouvoir transférer des protocoles autres que "simplement" HTTP. Google-QUIC ne transportait jamais que HTTP - en pratique, il transportait ce qui était en réalité des trames HTTP/2, en utilisant la syntaxe HTTP/2.
+Il a également été indiqué que l'IETF-QUIC devrait baser son cryptage et sa sécurité sur TLS 1.3 au lieu de l'approche"personnalisée" utilisée par Google-QUIC.
+Afin de satisfaire la demande d'envoi-plus-que-HTTP, l'architecture de protocole IETF QUIC a été scindée en deux couches distinctes: la couche de transport QUIC et la couche "HTTP sur QUIC" (cette dernière parfois appelée "hq").
+Cette division de couche, bien que cela puisse paraître inoffensif, a entraîné une grande différence entre l'IETF-QUIC etl'original de Google-QUIC.
+Cependant, le groupe de travail a rapidement décidé que pour se concentrer correctement et délivrer la version 1 de QUIC à temps, il se concentrerait sur la livraison de HTTP, laissant les transports non-HTTP à un travail ultérieur.
+Alors que les travaux sur l’IETF-QUIC ont progressé, l’équipe de Google a incorporé les détails de la version de l’IETF et a commencé à faire progresser lentement sa version du protocole vers ce que pourrait devenir la version de l’IETF. Google a continué d'utiliser sa version de QUIC dans son navigateur et ses services.
+La plupart des nouvelles implémentations en cours de développement ont décidé de se concentrer sur la version de l'IETF et ne sont pas compatibles avec la version de Google.
+=====  De http/2 à Maintenant =====
+le RFC 7540 du protocole HTTP/2  à été publiée en Mai 2015, un mois avant  que QUIC ne soit présenté pour la première fois à l IETF
+Pour partir de http1 à http2 il a fallu environ 16 ans, les bases de la modification de HTTP sur le réseau ont été aménagés et le groupe de travail qui a créé HTTP/2 était déjà convaincu que cela aiderait à effectuer une itération sur de nouvelles versions HTTP plus rapidement, mais il faut note que l adoption d un protocole nécessite du temps.
+Avec HTTP/2, les utilisateurs et les stacks logiciels se sont habitués à l'idée que le protocole HTTP ne peut plus être supposé être exécuté en série avec un protocole texte.
+HTTP-over-QUIC a été renommé HTTP/3 en novembre 2018
+===Status ===
+Le groupe de travail de QUIC a travaillé d'arrache-pied depuis fin 2016 pour spécifier les protocoles et le plan est maintenant de le faire d'ici juillet 2019.
+En novembre 2018, il n'y avait toujours pas de tests d'interopérabilité plus grands avec HTTP/3 - uniquement avec les deux implémentations existantes et aucun d'entre eux n'est effectué par un navigateur ou un logiciel populaire de serveur ouvert.
+Il y a une quinzaine de différentes implémentations de QUIC répertoriées dans les pages de wiki des groupes de travail de QUIC, mais toutes ne peuvent pas interagir sur les dernières revisions des spécifications.
+L'implémentation de QUIC n'est pas facile et le protocole a continué à évoluer, même à cette date
+=== les serveurs ===
+Il n'y a eu aucune déclaration publique en termes de soutien à QUIC d'Apache ou de nginx.
+=== les clients ===
+Aucun des plus gros éditeurs de navigateurs n’a encore fourni de version, quel que soit son état, pouvant exécuter la version IETF de QUIC ou de HTTP/3.
+Google Chrome est livré avec une implémentation fonctionnelle de la version QUIC de Google depuis de nombreuses années, mais cela n'interagit pas avec le protocole QUIC officiel et son implémentation HTTP est différente de HTTP/3.
+=== Obstables d implémentation ===
+QUIC a décidé d'utiliser TLS 1.3 comme base pour la couche de chiffrement et de sécurité pour éviter d'inventer quelque  chose de nouveau et plutôt s'appuyer sur un protocole fiable et existant. Cependant, ce faisant, le groupe de travail a également décidé que, pour rationaliser réellement l'utilisation de TLS dans QUIC, il ne devrait utiliser que des "messages TLS" et non des "enregistrements TLS" pour le protocole.
+Cela peut sembler être un changement anodin, mais cela a en fait créé un obstacle considérable pour de nombreux développeurs de stack QUIC. Les bibliothèques TLS existantes qui prennent en charge TLS 1.3 n'ont tout simplement pas assez d'API pour exposer cette fonctionnalité et permettre à QUIC d'y accéder. Bien que plusieurs développeurs QUIC proviennent de grandes organisations qui travaillent sur leur propre stack TLS en parallèle, cela n’est pas vrai pour tout le monde.
+OpenSSL, le poids lourd open source dominant, par exemple, n’a pas d’API et n’a manifesté aucun désir de la fournir dans les meilleurs délais (à partir de novembre 2018).
+Cela entraînera éventuellement des obstacles de déploiement puisque les stacks QUIC devront se baser sur d'autres bibliothèques TLS, utiliser une version OpenSSL corrigée ou nécessiter une mise à jour d'une version future d'OpenSSL.
+=== Fonctionnalités du protocole ===
+Le protocole QUIC d'un niveau élevé.
+Illustré ci-dessous, la stack réseau HTTP/2 à gauche et la stack réseau QUIC à droite, quand utilisées comme transport HTTP
+{{https://wiki.osc.cg/_media/ietf/fonctionnement.png}}
+===== Protocole de transfert sur UDP =====
+QUIC est un protocole de transfert implémenté au-dessus d'UDP. Si vous surveillez votre trafic réseau par hasard, vous verrez QUIC apparaître sous forme de paquets UDP.
+Basé sur UDP, il utilise également les numéros de port UDP pour identifier des serveurs spécifiques sur une machine donnée.
+Toutes les implémentations QUIC connues se trouvent actuellement dans l'espace utilisateur, ce qui permet une évolution plus rapide que ne permettent généralement pas les implémentations noyau
+===== Est-ce que ça va fonctionner ? =====
+D'autres limitent ces données de manière à rendre QUIC moins performant que les protocoles basés sur TCP. Il n'y a pas de fin à ce que certains opérateurs peuvent faire.
+Dans un avenir prévisible, toute utilisation de transports basés sur QUIC devra probablement être en mesure de faire appel à une autre alternative (basée sur TCP). Les ingénieurs de Google ont précédemment mentionné les taux d'échec mesurés dans de faibles pourcentages à un chiffre.
+===== Cela va-t-il s'améliorer ? =====
+Il est fort probable que si QUIC s'avère être un atout précieux au monde d'Internet, les utilisateurs voudront l'utiliser et le feront fonctionner dans leurs réseaux, ce qui permettra aux entreprises de reconsidérer leurs obstacles. Au fil des années, le développement de QUIC a progressé, le taux de réussite de l’établissement et de l’utilisation de connexions QUIC sur Internet a augmenté.
+===== Transferts de données fiables =====
+Bien qu'UDP ne soit pas un transport fiable, QUIC ajoute une couche au-dessus d'UDP qui introduit la fiabilité. Il offre la retransmission de paquets, le contrôle de congestion, la stimulation et les autres fonctionnalités présentes par ailleurs dans TCP.
+Les données envoyées sur QUIC depuis un point de terminaison apparaîtront dans l'autre tôt ou tard, tant que la connexion est maintenue
+=====  Plusieurs flux au sein de connexions =====
+Semblable à SCTP, SSH et HTTP/2, QUIC propose des flux logiques séparés au sein des connexions physiques. Un
+certain nombre de flux parallèles pouvant transférer des données simultanément sur une seule connexion sans affecter lesautres flux.
+Une connexion est une configuration négociée entre deux points de terminaison, similaire au fonctionnement d'une
+connexion TCP. Une connexion QUIC est établie sur port UDP et une adresse IP, mais une fois établie, la connexion est associée à son "ID de connexion".
+Sur une connexion établie, chaque côté peut créer des flux et envoyer des données à l'autre terminaison. Les flux sont livrés dans l'ordre et ils sont fiables, mais différents flux peuvent être livrés dans le désordre.
+QUIC offre un contrôle de flux sur la connexion et les flux.
 ===== Référence =====
@@ Ligne 79: / Ligne 212: @@
 [[https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ ]]
-[[]]
+[[https://tools.ietf.org/html/rfc7540 ]]

OSC 242 - Wiki

Outils pour utilisateurs

Outils du site

Différences

Outils de la page