Différences

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

--- ietf:http3 [2019/01/26 02:05]
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 75: / Ligne 75: @@
 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 ======
+=== 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.
@@ Ligne 85: / Ligne 85: @@
-====== TCP Fast Open est problématique ======
+=== 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.
@@ Ligne 119: / Ligne 119: @@
 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.

OSC 242 - Wiki

Outils pour utilisateurs

Outils du site

Différences

Outils de la page