La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: minidou le 12 novembre 2018 à 20:03:32
-
(https://lafibre.info/images/logo/logo_http3.svg)
The protocol that's been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham.
The QUIC Working Group in the IETF works on creating the QUIC transport protocol. QUIC is a TCP replacement done over UDP. Originally, QUIC was started as an effort by Google and then more of a "HTTP/2-encrypted-over-UDP" protocol.
When the work took off in the IETF to standardize the protocol, it was split up in two layers: the transport and the HTTP parts. The idea being that this transport protocol can be used to transfer other data too and its not just done explicitly for HTTP or HTTP-like protocols. But the name was still QUIC.
People in the community has referred to these different versions of the protocol using informal names such as iQUIC and gQUIC to separate the QUIC protocols from IETF and Google (since they differed quite a lot in the details). The protocol that sends HTTP over "iQUIC" was called "hq" (HTTP-over-QUIC) for a long time.
https://daniel.haxx.se/blog/2018/11/11/http-3/
Les ingénieurs de Litespeed et de Facebook ont réussis la première communication entre deux implèmentation d'HTTP/3 le 7 novembre dernier.
https://twitter.com/dmitri_tikhonov/status/1059998989557395457
Pleins d'infos sur le protocole :
QUIC (Quick UDP Internet Connections) is a new encrypted-by-default Internet transport protocol, that provides a number of improvements designed to accelerate HTTP traffic as well as make it more secure, with the intended goal of eventually replacing TCP and TLS on the web. In this blog post we are going to outline some of the key features of QUIC and how they benefit the web, and also some of the challenges of supporting this radical new protocol.
https://blog.cloudflare.com/the-road-to-quic/
Edit Vivien :
HTTP/3 - QUIC : Quels impacts sur la sécurité ?
https://lafibre.info/videos/securite/202304_haproxy_http3_quic_impacts_sur_la_securite.mp4
Vidéo du FRnOG 37, avec pour intervenants Amaury Denoyelle & Willy Tarreau de HAProxy
-
Pour rappel, à l'origine HTTP/2 s'appelait SPDY et était aussi une technologie développée par Google. J'ai entendu parler de QUIC et SPDY pour la première fois en même temps d'ailleurs.
QUIC et SPDY sont déployés tous les deux depuis bien longtemps dans Chrome, en fait, Google se sert largement des protocoles qu'il développe d'abord sur sa propre infrastructure et dans son navigateur pour pouvoir pousser le processus de normalisation.
-
HTTP/3 est une version de HTTP finalisée en 2020 qui est plus adapté au Web (évite les blocages). HTTP/3 utilise le protocole QUIC encapsulé dans des paquets UDP.
Le draft IETF : https://tools.ietf.org/html/draft-ietf-quic-http-19
Un article qui explique bien HTTP/3 : https://kinsta.com/fr/blog/http3/
Support HTTP/3 des navigateurs web :
- Chrome 87 : 17 novembre 2020
- Edge 87 : 20 novembre 2020
- Vvivaldi 3.5 : 5 décembre 2020
- Opera 74 : 2 février 2021
- Firefox 88 : 19 avril 2021
- Samsung Internet 14 : 16 avril 2021
- Safari Mac : non
- iOS : non
(https://lafibre.info/images/ssl/http3_support.webp) (https://lafibre.info/images/ssl/tls13_support.webp)
-
Dans cette session, Nick Shadrin (Consulting Manager F5 Networks) examine l'historique du protocole, les raisons des mises à jour majeures et les défis critiques pour l'adoption de nouveaux protocoles dans des environnements plus vastes. Il décrit l'historique et des exemples de la suite HTTP/1, SPDY et HTTP/2, QUIC et HTTP/3, les composants internes du serveur Web, l'adoption du trafic UDP dans un environnement étendu, le dépannage, SSL/TLS et comment choisir le bon protocole pour vos connexions HTTP.
Les participants comprendront les compromis qui accompagnent la mise en œuvre du nouveau protocole et sauront clairement quand mettre en œuvre HTTP/3 et quand rester sur les anciennes versions du protocole, pour différentes parties des applications distribuées.
https://lafibre.info/videos/logiciels/201909_http3_explique_par_nick_shadrin.mp4
-
Cloudflare, Google Chrome et Firefox ajoutent le support HTTP/3
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 APIs 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.
(https://lafibre.info/images/ssl/201909_http3_partenaires.png)
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 APIs. 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 possible 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.
(https://lafibre.info/images/ssl/201909_http_request_over_tcp_tls.png)
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.
A 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.
(https://lafibre.info/images/ssl/201909_http_request_over_quic.png)
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.
Source : developpez.com (https://reseau.developpez.com/actu/278865/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/) et Cloudflare,le 27 septembre 2019
-
Je me demande si le SNI (Server Name Indication), extension du protocole TLS afin que le serveur présente le certificat du bon nom de domaine, quand plusieurs sites web sont hébergées derrière la même IP.
Aujourd'hui beaucoup d'équipements de sécurité ou de DPI se basent sur le SNI.
-
https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.3.3
HTTP/3 relies on QUIC as the underlying transport. The QUIC version being used MUST use TLS version 1.3 or greater as its handshake protocol. HTTP/3 clients MUST indicate the target domain name during the TLS handshake. This may be done using the Server Name Indication (SNI) [RFC6066] extension to TLS or using some other mechanism.
Donc ça ne change pas, SNI (DPI possible) ou ESNI (DPI impossible) si le DNS fournit l'information.
-
Apres Cloudflare y'a quelques temp, c'est autour de Facebook de mettre en avant HTTP/3 - QUIC.
75% du trafic Facebook est désormais fait avec HTTP/3 - QUIC donc au dessus d'UDP.
https://engineering.fb.com/networking-traffic/how-facebook-is-bringing-quic-to-billions/
-
HTTP/3, ce n'est pas seulement HTTP/2 avec un numéro plus grand
Conférence de Stéphane Bortzmeyer d 37 minutes à Paris Web 2021, le 7 octobre 2021.
Le Web est très demandeur en performances, notamment en faible latence, et a des exigences particulières, par exemple quand il faut récupérer en parallèle plusieurs ressources (JavaScript, CSS, images, etc). HTTP/2 a amélioré les choses par rapport au bon vieil HTTP/1 mais nous voici désormais avec HTTP/3, qui va peut-être permettre de gagner encore du temps, en passant au nouveau protocole de transport QUIC.
QUIC augmente le parallélisme, durcit la sécurité (encore moins d'informations disponibles pour un indiscret qui scrute le réseau), fusionne le transport et le chiffrement, et, normalement, réduit la latence. Normalisé par l'IETF en mai 2021, il sert de substrat à HTTP/3.
En quoi consiste QUIC ? Que va-t-on vraiment gagner ? Que risque-t-on de perdre ? Quel est l'avenir de HTTP ? Je ne suis pas YouTube, alors ça change quoi pour mon petit site et ses dix requêtes par heure ? C'est ce qu'on verra dans cette conférence.
https://lafibre.info/videos/logiciels/202110_stephane_bortzmeyer_http3.mp4
Vidéo encodée en AV1 avec la ligne de commande suivante : ffmpeg -i "in.mp4" -filter:v "scale=1280:-1" -pix_fmt yuv420p -c:v libaom-av1 -crf 45 -b:v 0 -g 150 -row-mt 1 -tiles 2x1 -threads 8 -cpu-used 4 -c:a libopus -b:a 64k -f mp4 "202110_stephane_bortzmeyer_http3.mp4"
Le résultat est bluffant, le fichier de 37 minutes fait moins de 60 Mo en 720p en AV1, contre plus de 1137 Mo pour du 1080p en H.264.
-
Le fichier vidéo n'est pas jouable avec Edge (OK avec Chrome et FF).
-
Tiens je remarque que sur Fennec (Firefox compilé par F-droid) non plus...
-
Mozilla Firefox sous Android : Le support de l'AV1 a été désactivé suite à un bug, cf Bug 1583144 (https://bugzilla.mozilla.org/show_bug.cgi?id=1583144) du 23 septembre 2019.
Microsoft Edge sous Windows 10 / 11 : Il faut aller dans le Microsoft Store télécharger l'extension AV1.
Copie d'écran sous Windows 11 :
(https://lafibre.info/testdebit/windows11/202202_microsoft_store_av1_extention.png)
C'est pour moi incompréhensible que cela ne soit pas installé de base avec Windows 11.
Microsoft Edge sous Linux : Je n'ai pas trouvé comment mettre le support de l'AV1.
Microsoft Edge sous iOS : Pas de support de l'AV1, limitation Apple qui impose le moteur de rendu Safari.
-
à ce jour il est possible d'implémenter HTTP/3 dans apache ?
La dernière fois que je m'étais penché dessus ce n'était pas possible...des fois qu'un type perdu au milieu de la toile ait fait un module ?
-
Non aucune implémentation même pour du test n'est disponible dans Apache. C'est pas le genre d'Apache d'intégrer les dernières technologies.
Il y a Nginx qui propose une implémentation en expérimental. J'ai eu un mauvais retour en terme de perf : Débit faible en http/3, mais ok en http/2 sur le même serveur (https://lafibre.info/cryptographie/debit-faible-en-http3/)
Je n'ai pas la certitude que ce soit Nginx le fautif, mais la problématique est la même avec Firefox et Chrome pour les 4 opérateurs, donc il est probable que la conf HTTP/3 de Nginx par défaut soit pas au top.
-
J'ai fait des tests avec haproxy qui supporte http3 (dans la branche de dev) en front avec http2 ou http1.1 en backend, ça marche vraiment bien (j'ai pas d'élément de comparaison avec nginx cependant). haproxy.org est dispo en http/3 depuis 15j environ (avec haproxy naturellement ;) ).
-
Milestone important:
La RFC d'HTTP/3 vient d'être publiée: https://www.rfc-editor.org/rfc/rfc9114.html ainsi que la mise a jour générale d'HTTP: https://www.rfc-editor.org/rfc/rfc9110.html
il manque plus que la finalisation et l'adoption de DNS SVCB / HTTPS RRs (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10) pour évoluer vers un monde ou on pourra directement joindre un serveur HTTP/3 (donc via QUIC en udp) sur n'importe quel port juste avec une url normal:
monsite.com --> reso DNS SVCB/RRs donne ip=A.B.C.D, port=8080, h3 -> connexion directe en udp / Http/3 a A.B.C.D sur le port 8080
-
J'espérais que HTTP/3 étant devenu RFC en juin 2022, Apple le prendrait en charge.
Mais non...
Petit schéma de la prise en charge de HTTP/3 :
(https://lafibre.info/images/ssl/http3_support.webp)
-
Toujours les mêmes en retard... Limite ils font exprès
-
J'espérais que HTTP/3 étant devenu RFC en juin 2022, Apple le prendrait en charge.
Mais non...
A noter que c'est disponible dans Safari (au moins sur MacOS) dans les Experimental Features (menu "Develop"), et ça fonctionne si on l'active.
Mais effetivement, je ne suis pas très optimiste quant à une activation rapide par défaut. Cela étant, c'est quand même beaucoup moins gênant de ne pas avoir de support dans Safari pour HTTP/3 par rapport à d'autres API Web ou fonctionnalités qui ont mis beaucoup de temps à arriver dans Safari : ça reste quand même de l'optimisation, et l'absence de support de HTTP/3 côté client ne rend pas un site non fonctionnel.
-
Apple c’est une grosse boîte, je pense qu’ils ont des roadmaps bien déterminées et à partir du moment où ils commencent le développement de nouvelles versions de leurs OS il n’y a plus rien qui peut entrer dans la roadmap (déjà qu’ils n’arrivent pas à livrer tout ce qu’ils y mettent…).
La clairement la RFC est sortie après la WWDC début juin donc il était bien trop tard pour cette itération puisque les nouveaux OS étaient déjà suffisamment avancés pour être disponibles en beta (même si comme déjà dit HTTP3 est en experimental depuis un moment dans Safari). Peu d’espoir donc avant iOS 17 et la prochaine version de macOS.
-
Le support de HTTP/3 est présent depuis septembre 2020 (iOS 14) dans "Experimental Features".
C'est long.
-
aujourd'hui safari ios supporte http3 (l'option a meme disparue dans experimental feautures)
-
Tu aurais une source, pour que je demande la correction de https://caniuse.com/http3 ?
Aujourd'hui, je ne trouve des articles qui ne parlent que d'une prise en charge non activée par défaut de HTTP/3 par Safari.
-
Je viens de tester à l'instant avec mon iPhone 12 Pro dernière version d'iOS (16.4): https://cloudflare-quic.com m'indique que mon navigateur utilise HTTP/2, même après plusieurs refreshs.
-
12 Mini 16.4 et j'ai bien HTTP/3 (aujourd'hui mais pas hier ... peut-être qu'il y a un rollout progressif de la fonctionnalité)
-
Ok, donc j'ai reessayé ce matin et maintenant je suis bien en HTTP/3... ???
Hier soir d'ailleurs pareil sur mon MacBookPro M2 Pro tout neuf: HTTP/2. Je reessayerai à mon retour du bureau pour voir si ça a aussi évolué.
-
Pas de HTTP/3 avec un iPhone SE 2020 sous iOS 16.4 :
(https://lafibre.info/images/ssl/202304_ios164_safari_http3_test.webp)
-
Réessaye demain ;D (ou essaye de vider le cache de Safari, je ne sais plus comment on fait sur iOS).
-
Mouais..
(https://pix.milkywan.fr/fcfmgmBH.png)
(https://pix.milkywan.fr/4q2mpTMe.png)
http3 est bien activé...
-
Même résultat que Hugues avec Brave (Chromium 111) sur Ubuntu 22.04 alors que HTTP/3 fonctionne sur d'autres sites
EDIT : je viens de retenter et ça fonctionne
-
Firefox 111 sous Ubuntu 22.10 :
(https://lafibre.info/images/ssl/202304_ubuntu2210_firefox111_http3_test.webp)
-
Milestone important:
La RFC d'HTTP/3 vient d'être publiée: https://www.rfc-editor.org/rfc/rfc9114.html ainsi que la mise a jour générale d'HTTP: https://www.rfc-editor.org/rfc/rfc9110.html
il manque plus que la finalisation et l'adoption de DNS SVCB / HTTPS RRs (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10) pour évoluer vers un monde ou on pourra directement joindre un serveur HTTP/3 (donc via QUIC en udp) sur n'importe quel port juste avec une url normal:
monsite.com --> reso DNS SVCB/RRs donne ip=A.B.C.D, port=8080, h3 -> connexion directe en udp / Http/3 a A.B.C.D sur le port 8080
J'étais passé à côté de ce message.
Depuis le temps, je suppose que cela a été implémenté, sinon, il y a moyen de simuler :
D'après le doc ietf :
Implémenter le RR type 64
2. The SVCB record type
The SVCB DNS resource record (RR) type (RR type 64) is used to locate alternative endpoints for a service.
See Section 9.1 for the HTTPS RR behavior.
As an example, the owner of example.com could publish this record:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
to indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of example.net, in turn, could publish this record:
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" ech="..." )
Sinon, pour le test Cloudfare,cela fonctionne sur safari et ios 16.4 ainsi que sur Chrome Canary.
-
J'étais passé à côté de ce message.
Depuis le temps, je suppose que cela a été implémenté, sinon, il y a moyen de simuler :
D'après le doc ietf :
Implémenter le RR type 64
2. The SVCB record type
The SVCB DNS resource record (RR) type (RR type 64) is used to locate alternative endpoints for a service.
See Section 9.1 for the HTTPS RR behavior.
As an example, the owner of example.com could publish this record:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
to indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of example.net, in turn, could publish this record:
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" ech="..." )
C'est le cas, dans Firefox, à condition d'avoir DoH activé, on peut voir dans about:networking#dnslookuptool :
1 cloudflare-quic.com (alpn="h3,h3-29,h2" ipv4hint="104.22.8.38, 104.22.9.38, 172.67.9.235" echConfig="0045FE0D0041CE002000200CCA4453F0E8CE33B2CE790907FB0E05860E9691DF440DB7645C4707B8D12B630004000100010012636C6F7564666C6172652D6563682E636F6D0000" ipv6hint="2606:4700:10::6816:826, 2606:4700:10::6816:926, 2606:4700:10::ac43:9eb" )
Le alpn="h3,h3-29,h2" indique le support HTTP/3.
Sinon le browser fait une première requête HTTP/2, et voit le header alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400.
Dans ce cas, en rechargeant il peut basculer en HTTP/3, mais uniquement s'il ne réutilise pas la connexion déjà ouverte.
-
A noter que pour la découverte via DNS (https RR), les navigateurs ont un mécanisme de "fallback" de HTTP/3 vers HTTP/2.
Suivant les conditions réseau HTTP/3 peut ne pas fonctionner.
Sur Firefox le délai est a 50ms (option:network.dns.httpssvc.http3_fast_fallback_timeout)
-
Tu aurais une source, pour que je demande la correction de https://caniuse.com/http3 ?
Aujourd'hui, je ne trouve des articles qui ne parlent que d'une prise en charge non activée par défaut de HTTP/3 par Safari.
https://h3.speed.cloudflare.com/cdn-cgi/trace
https://cloudflare-quic.com/
-
Alors tres étrangement sur mon ipad c’est ko
-
À noter que j'ai eu l'information d'Amaury Denoyelle & Willy Tarreau au FRnOG qu'Apache travaille sur un module HTTP/3.
Ils ont fait une superbe présentation sur la sécurité et HTTP/3 que je vous partagerais dès qu'elle sera publiquement disponible.
-
Du côté de NGINX, on a maintenant droit à une beta officielle: https://www.nginx.com/blog/binary-packages-for-preview-nginx-quic-http3-implementation/
Installée sur mon serveur web, tourne depuis une semaine sans soucis (mais bon, pas de gros volume, je fais principalement tourner une instance Nextcloud et une instance Mastodon).
Du coup j’ai pu tester un peu plus en detail mes équipements Apple:
- iPhone iOS 16.4.1 : HTTP/3 OK
- iPad iPadOS 16.4.1 : HTTP/3 KO
- MacBook Pro M2 macOS Ventura 13.3.1: HTTP/3 OK
J’ai du mal à comprendre à quel jeu joue Apple.
-
sur mon mac book air m2 ko sur safari...
et sur l'iphone 12 de ma mere ios 16.4.1 ko egalement
meme sur mon iphone 12 pro ça ne fonctionne plus maintenant, alors que Apple parle bien de Quic dans leurs vidéos
https://developer.apple.com/videos/play/wwdc2021/10094/
https://developer.apple.com/documentation/network/quic_options
-
À noter que j'ai eu l'information d'Amaury Denoyelle & Willy Tarreau au FRnOG qu'Apache travaille sur un module HTTP/3.
Ils ont fait une superbe présentation sur la sécurité et HTTP/3 que je vous partagerais dès qu'elle sera publiquement disponible.
La video est ici :
HTTP/3 - QUIC : Quels impacts sur la sécurité ?
https://lafibre.info/videos/securite/202304_haproxy_http3_quic_impacts_sur_la_securite.mp4
Vidéo du FRnOG 37, avec pour intervenants Amaury Denoyelle & Willy Tarreau de HAProxy
-
Je recommande la lecture de cette vidéo pour ceux qui se posent des questions sur HTTP/3.
Félicitations aux intervenants Amaury Denoyelle & Willy Tarreau de HAProxy, c'est rare d'avoir un contenu de qualité, aussi technique, mais qui reste accessible.
-
Le rapport Sandvine 2023 "Global Internet Phenomena Report" analyse le trafic internet et on voit que si HTTP/3 QUIC rend le travail plus difficile, ils arrivent à catégoriser le trafic HTTP/3, probablement via les IP.
En examinant les données de plusieurs réseaux, nous montrons ci-dessous une ventilation de ce que nous voyons en termes de volumes QUIC pour Google, Meta, FaceTime, TikTok et HBO Max.
La QoE vidéo doit-elle signifier un compromis de visibilité ?
La réponse est non." Le défi pour les opérateurs est d'accélérer et de masquer ce qui se passe sur les réseaux. C'est vrai dans l'ensemble avec l'augmentation du chiffrement (c'est-à-dire Apple iCloud Private Relay), du trafic QUIC et HTTP/3, qui entraînent tous un flot de trafic « inconnu » ou « autre », en particulier sur les réseaux qui reposent sur techniques de base pour identifier le trafic des applications. En utilisant des techniques de classification des applications de plus en plus sophistiquées, il est possible de classer le trafic « inconnu » pour évaluer ce qui se passe sur les réseaux et mesurer les expériences d'application des abonnés.
(https://lafibre.info/images/environnement/202301_sandvine_global_internet_phenomena_report_http3.webp)
Trafic internet réparti par catégories :
(https://lafibre.info/images/environnement/202301_sandvine_global_internet_phenomena_report_categories.webp)
Le rapport Sandvine 2023 et 2014 complet :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/environnement/202301_sandvine_global_internet_phenomena_report.webp) (https://lafibre.info/images/environnement/202301_sandvine_global_internet_phenomena_report.pdf) (https://lafibre.info/images/doc/201405_sandvine_raport_internet_global_t1_21014.jpg) (https://lafibre.info/images/doc/201405_sandvine_raport_internet_global_t1_21014.pdf)
-
Avec la beta 1 de ios 17 ca fonctionne
Malheureusement toujours pas sur mac
-
L'Apnic met en place une carte indiquant le pourcentage de client compatible avec HTTP/3 :
=> https://stats.labs.apnic.net/quic
(https://lafibre.info/images/ssl/202306_apnic_carte_http3.webp)
Certains pays bloquent HTTP/3 (ex: Iran 3%, Éthiopie 23%, Chine 24%, Érythrée 27%, Maroc 34%) mais d'autres ont un % faible (ex: Canada 43%, USA 44%), lié à une forte part de marché d'Apple dans le pays ?
-
Certains pays bloquent HTTP/3 (ex: Iran 3%, Éthiopie 23%, Chine 24%, Érythrée 27%, Maroc 34%) mais d'autres ont un % faible (ex: Canada 43%, USA 44%), lié à une forte part de marché d'Apple dans le pays ?
difficile de savoir la carte ne présente sa méthode de compilation des données. c'est "use" en volume ou par utilisateurs ? c'est compté comment ? visites sur leur site ?
Pour ce qui est du blocage, les techniques de "anti-fingerprinting" de QUIC ne sont pas encore répandu dans toutes les implémentations de QUIC et peut-être que certains pays bloquent tout simplement UDP.
Le support de QUIC est l'affaire des applications pas de l'OS donc je doute que la pdm d'Apple joue non ? sauf si seul le traffic web 'mobile' est compté ?
En volume, QUIC est surtout utilisé par Facebook, Google, etc donc en mobile via leurs applications natives même sur iOS.
-
Le comptage ne se fait pas via leur site, mais via des espaces publicitaires qu'ils achètent qui font des accès à leurs serveurs (sans avoir besoin de cliquer sur la publicité).
Les connexions leur permettent de faire des statistiques IPv6, des statistiques sur le nombre d'utilisateurs par AS (https://stats.labs.apnic.net/aspop), mais aussi d'autres analyses : HTTP/3, DNSSEC,... : https://stats.labs.apnic.net/
Oui, je regrette que la méthodologie précise ne soit pas détaillée dans un document (ou je ne l'ai pas trouvé).
-
Ils ont fait une présentation sur leur système de mesure l'an dernier, il n'y a pas tout les détails mais c'est déjà pas mal pour avoir une idée de ce qu'ils font https://labs.apnic.net/presentations/store/2022-09-13-measurement.pdf
-
Étrangement dans la version finale seul l’iPhone, garde le support de HTTP3
Mac m2 et ipad m1 avec les dernières versions logiciele c’est KO
Encore plus étrange sur iPhone 12, ça fonctionne pas, mais sur iPhone 15 oui
-
Bizarrement j'ai bien de l'HTTP3 sur Safari sous macOs Sonoma sur mon MBP M2 Pro (vérifié avec l'inspecteur de Safari).