- Cloudflare a officiellement dévoilé le tout premier CDN basé sur Media over QUIC (MoQ)
- MoQ est une nouvelle norme pour le transport de médias en temps réel, appelée à remplacer WebRTC, HLS/DASH et RTMP/SRT
- Le service est actuellement en developer preview et peut être testé via le point de terminaison public de Cloudflare avec plusieurs clients et bibliothèques
- Des fonctions de démonstration comme la diffusion en direct, le visionnage et les sous-titres alimentés par l’IA sont proposées sur le web et dans un client Rust
- Des fonctions clés comme l’authentification, la prise en charge de Safari et ANNOUNCE ne sont pas encore implémentées, et les développeurs intéressés peuvent aussi exploiter leur propre relais MoQ
Cloudflare lance officiellement le premier CDN MoQ
Introduction
- Avec le lancement officiel par Cloudflare d’un CDN fondé sur la norme Media over QUIC (MoQ), le domaine du transport média en temps réel pourrait connaître un changement majeur
- MoQ attire l’attention comme norme de nouvelle génération susceptible de remplacer les protocoles existants WebRTC, HLS/DASH, RTMP/SRT pour la transmission de médias live comme la vidéo et l’audio en temps réel
- Cette sortie prend la forme d’un produit officiel, que de vrais utilisateurs peuvent tester directement sur le réseau Anycast mondial
- Cloudflare devient ainsi le premier opérateur de CDN MoQ, et cette technologie devrait stimuler l’innovation dans l’écosystème du transport média en temps réel
Fonctionnalités actuellement disponibles
- Cette technologie est proposée en version preview, avec une stabilité de service et un périmètre fonctionnel encore limités
- Cloudflare ouvre un point de terminaison public à l’adresse
relay.cloudflare.mediaoverquic.com - Elle peut être testée via différentes bibliothèques et différents clients open source, notamment :
- La démo web et les bibliothèques permettent la diffusion en direct et le visionnage en temps réel dans le navigateur
- Mise en démonstration d’une fonction de traitement des sous-titres basée sur l’IA
- Dans le navigateur, les sous-titres sont générés et transmis avec des technologies comme [silero-vad], [whisper], [transformers.js], [onnxruntime-web] et [WebGPU]
- Au-delà d’une API sous forme de Web Component, des usages avancés sont également pris en charge via une API JavaScript
- Un environnement est aussi prévu pour ceux qui préfèrent éviter JavaScript, avec une bibliothèque Rust permettant l’import MP4, l’intégration de ffmpeg, ainsi que la diffusion et la lecture basées sur gstreamer
Fonctionnalités non encore implémentées
- La version actuellement proposée ne prend en charge qu’un sous-ensemble limité du Draft-07
- Principales fonctions encore absentes :
- Pas de prise en charge de l’authentification des flux : il faut attribuer manuellement à chaque flux un nom difficile à deviner
- Pas de prise en charge d’ANNOUNCE : absence de détection du démarrage et de l’arrêt d’un flux
- Pas de prise en charge du navigateur Safari : incompatibilité avec Safari en raison des problèmes de prise en charge de WebTransport
- Optimisations inachevées : l’expérience utilisateur et d’autres aspects seront améliorés progressivement
- Si nécessaire, il est possible de déployer soi-même une instance de moq-relay pour exploiter des fonctions avancées
- Des fonctions supplémentaires sont en cours de développement, comme l’authentification basée sur JWT et un fallback WebSocket pour Safari/TCP
- Il est également possible de constituer un réseau CDN mondial avec un module Terraform
Ce que représentent MoQ et Cloudflare
- Le travail de standardisation de MoQ est en cours depuis plus de trois ans, et son adoption effective à l’échelle mondiale devrait encore prendre du temps
- En lançant rapidement un produit réel avant même l’adoption du RFC, Cloudflare a fait un choix audacieux pour obtenir des retours concrets des développeurs et des utilisateurs
- La technologie MoQ a le potentiel de remplacer des protocoles média existants comme WebRTC, HLS et RTMP
- Les discussions sur les brouillons de standard et les problèmes de code vont se poursuivre, mais l’expérience acquise en exploitation réelle devrait contribuer fortement à l’évolution du standard
- À l’avenir, sur le marché du transport média fondé sur MoQ, des acteurs comme Google, Akamai et Fastly devront eux aussi déployer du code sur leurs propres réseaux et serveurs afin d’identifier les besoins réels
Suite des travaux et communauté
- Il reste encore beaucoup de travail pour réimplémenter WebRTC et les protocoles existants avec des API web modernes
- Il ne faut pas juger l’ensemble de MoQ uniquement sur la base des performances et des fonctions actuelles, et une participation active aux tests et aux retours est nécessaire
- Plus de 900 personnes sont déjà actives dans la communauté (Discord), où il est possible de poser des questions et de proposer des collaborations
1 commentaires
Commentaires sur Hacker News
J’ai testé la démo sur https://moq.dev/publish/ et c’est vraiment très fluide. Très impressionnant. Et merci pour cette excellente technologie. En regardant la démo Big Buck Bunny sur https://moq.dev/watch/?name=bbb depuis un téléphone mobile, j’ai constaté beaucoup de lignes noires horizontales (curieusement, sur un PC utilisant le même Wi‑Fi, tout est normal). Je me demande si cela vient de la taille du buffer. Est‑ce qu’on peut augmenter le buffer côté client, ou est‑ce que cela doit être configuré côté serveur ? Et merci aussi de ne pas avoir oublié la Corée du Sud sur la carte du CDN « global »
Je me demande si cela fonctionne uniquement sur Chrome. Sur Firefox Android, je vois seulement un message indiquant que le navigateur n’est pas pris en charge
Je ne sais pas trop pour les lignes noires horizontales. Le rendu se fait via un élément <canvas>, redimensionné à la taille de la vidéo source, puis redimensionné à nouveau en CSS pour s’adapter à la fenêtre
Sur un OnePlus Ten avec Chrome, les lignes noires clignotent souvent. Surtout en partant du haut de l’écran vers le bas à droite ; c’est peut‑être un artefact de rafraîchissement de l’écran (rolling shutter effect)
Comme la page mentionne beaucoup de code Rust et de WASM, c’est peut‑être simplement que le CPU du téléphone n’exécute pas WASM assez vite. Sur mon Samsung S20, je ne vois aucune ligne noire
J’ai testé avec un MacBook Air M4 et une connexion à 600 Mbps, et j’ai été frappé par la réactivité immédiate
Il y a bien une section « pourquoi est‑ce important ? » dans l’article, mais elle n’explique pas ce que Media over QUIC apporte aux éditeurs de contenus ou aux utilisateurs finaux — c’est‑à‑dire les deux parties les plus importantes (et peut‑être les seules) dans cet échange. Donc je me demande pourquoi je devrais m’intéresser à cette technologie
C’est ma faute. En essayant d’éviter de répéter ce qui était déjà expliqué dans les billets précédents, je n’ai pas assez développé : https://moq.dev/blog/replacing-webrtc/ Et en réalité, MoQ bénéficie surtout aux développeurs. Cela simplifie énormément la montée en charge et l’ajout de fonctionnalités, donc les bénéfices sont surtout indirects
La latence de bout en bout (glass‑to‑glass) est nettement meilleure. Principalement parce que le protocole n’est plus basé sur un modèle request/response
Bonjour ! Je suis développeur sur Cloudflare MoQ, n’hésitez pas si vous avez des questions. Et merci pour la récompense, kixelated xD
Il y avait cette explication : « Pas de head‑of‑line blocking : contrairement à TCP, les flux QUIC sont indépendants. Si un paquet est perdu sur un flux (par exemple une piste audio), les autres pistes (par exemple la piste vidéo) ne sont pas bloquées. Les saccades qu’on voyait toujours avec RTMP disparaissent ainsi ». Mais dans cette architecture, si des paquets sont perdus sur la piste audio et que la vidéo continue à être lue sans s’arrêter, est‑ce que cela ne risque pas de désynchroniser l’audio et la vidéo ? Je ne suis peut‑être pas assez familier avec la technique pour bien comprendre ce point
J’ai une question. Y a‑t‑il un plan concret pour réduire l’écart de goodput entre TCP et QUIC [1] ? L’article lié observe jusqu’à 9,8 % de baisse du bitrate vidéo lors du passage de HTTP/2 (TCP) à HTTP/3 (QUIC). Bien sûr, MoQ a une pile un peu différente, donc on ne peut pas généraliser directement, mais j’imagine qu’un problème similaire peut exister. (De mon côté, j’ai étudié le datapath AF_XDP de MsQuic ces derniers mois dans le cadre de mon mémoire de master. En gros, j’en suis arrivé à la conclusion que GSO/GRO est une meilleure alternative et que QUIC a clairement besoin de plus d’offload matériel :p)
[1]: https://arxiv.org/pdf/2310.09423
J’ai quelques questions :)
À quel point QUIC est‑il proche d’un stade réellement exploitable dans le navigateur (pris en charge à la fois par les navigateurs et par l’infrastructure, au point que « ça marche, tout simplement ») ?
Et comment QUIC gère‑t‑il les problèmes de NAT ? Avec WebRTC, STUN/TURN est indispensable pour traverser un full cone NAT, et TURN est particulièrement pénible, car il faut faire tourner beaucoup d’infrastructure
Je travaille sur le streaming WebRTC chez getstream.io. WebRTC est un peu pénible à configurer, mais une fois la connexion établie, son faible niveau de latence est un gros avantage. Je me demande quels sont les avantages ou les problèmes de MoQ une fois la connexion établie, et comment cela se compare à WebRTC dans la pratique
Je me demande si l’équilibrage de charge des relais sort du périmètre de MoQ. J’ai l’impression que l’article n’aborde pas ce point
J’adore ce projet, je lis aussi parfois le blog de kixelated et je le suis sur GitHub.
Je voulais déjà féliciter kixelated et Cloudflare pour ce travail formidable.
Je me pose une question sur le live streaming en temps réel. En général, les diffusions en direct sont regardées par des centaines ou des milliers de personnes en même temps ; je me demande si MoQ envisage ou permet d’utiliser du multicast. C’était difficile avec HTTP/1.1 et HTTP/2 à cause de TCP, mais maintenant que HTTP/3 utilise UDP, cela me semble enfin une idée réaliste. Qu’en pensez‑vous ? Je sais qu’Akamai et la BBC étudient aussi ce sujet
Le multicast n’est pas nécessaire ! Un CDN revient déjà, en pratique, à implémenter du multicast en L7 (couche applicative). Il n’est pas nécessaire que les routeurs ou les FAI l’implémentent directement en L3. C’est précisément ce que j’ai fait pendant 5 ans chez Twitch
En théorie, le multicast ne réduirait que le trafic entre l’edge du CDN et le FAI, mais cela ne compte vraiment que pour les diffusions gigantesques qui arrivent une fois par an (par ex. le Super Bowl), et n’aide pas pour la majorité des événements. Beaucoup de CDN ont déjà placé leurs edges à l’intérieur des réseaux des FAI pour résoudre ce problème, et pour les petits événements, il est peu probable que deux spectateurs partagent le même chemin, donc le gain est faible
Le multicast pose aussi d’autres problèmes comme le contrôle de congestion ou le chiffrement, et c’est encore plus difficile dans un modèle fédéré
L’endroit où le multicast apporterait le plus serait le P2P, mais cela semble difficile à faire adopter dans l’écosystème gigantesque des CDN
WebRTC serait aussi très bien adapté au multicast et utilise RTP (initialement conçu pour cela), mais il n’y a en pratique aucun intérêt pour la prise en charge du multicast
Cela dit, il paraît que Google utilise du multicast pour Meet dans son propre réseau, donc qui sait
Le lien « just announced » est aussi très utile pour les gens qui n’ont absolument aucune idée de ce dont il s’agit : https://blog.cloudflare.com/moq/ (je l’avais raté moi aussi au début)
« Une latence inférieure à la seconde à l’échelle du broadcast », mais sans multicast réel
La formule « ce n’est pas juste un autre protocole, c’est une nouvelle philosophie de conception » a déclenché mon radar à détection d’IA
Je me demande comment MOQ gère la résolution de repli en cas d’échec et la dégradation progressive de la qualité. Et sur zed, même en plein écran, l’image ne remplit pas toute la surface
En tant qu’utilisateur de Firefox, si vous visitez un site hébergé par Cloudflare qui utilise HTTP/3, je partage ceci à titre d’information :
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
On dirait peut‑être un problème de happy eyeballs ? Je vais transmettre à des gens qui s’y connaissent mieux
Est‑ce que vous utilisez par hasard un résolveur DNS over HTTPS (DoH) intégré au navigateur ? Personnellement, je n’arrive pas à reproduire le problème. J’utilise le DoH via 1.1.1.1
J’ai constaté, sur Chrome comme sur Firefox, que l’utilisation de HTTP/3 est plus cohérente quand ils utilisent un résolveur DoH au lieu du DNS système. Quand ils utilisent le résolveur système, ils récupèrent souvent les enregistrements DNS HTTPS de façon irrégulière — voire pas du tout —,
or la prise en charge de HTTP/3 côté serveur doit être annoncée au navigateur soit via des enregistrements DNS HTTPS, soit via un en‑tête Alt‑Svc mis en cache depuis une précédente connexion HTTP/2/1.1. Les navigateurs ont tendance à réutiliser les connexions existantes et n’en ouvrent pas facilement de nouvelles
Les en‑têtes Alt‑Svc aussi ne sont pas mis en cache de façon très cohérente, surtout dans Firefox
Ce qui complique encore les choses, c’est que les navigateurs (surtout Chrome) finissent par désactiver complètement HTTP/3 après un certain nombre d’échecs de connexion. Cela m’est arrivé sur le Wi‑Fi de mon université, où le trafic UDP était beaucoup (et de façon irrégulière) bloqué, et ensuite HTTP/3 ne fonctionnait plus chez moi non plus. La seule solution a été d’aller dans chrome://flags et de réactiver manuellement la prise en charge de QUIC. Même si l’interface affiche « enabled by default », l’état réel du navigateur peut être différent. Firefox abandonne aussi parfois HTTP/3, mais pas avec autant d’obstination que Chrome, donc c’est moins problématique
Si vous voulez pousser le débogage, vous pouvez vérifier si EncryptedClientHello (ECH) fonctionne sur https://tls-ech.dev ; ce site n’utilise que les enregistrements HTTPS pour la clé ECH, ce qui permet d’isoler le problème.
Ensuite, le test HTTP/3 de Fastly (https://http3.is) permet de voir si seul Alt‑Svc est utilisé pour la négociation.
La page de test Cloudflare (https://cloudflare-quic.com) utilise à la fois les enregistrements DNS HTTPS et Alt‑Svc, donc si HTTP/3 est utilisé immédiatement, c’est que la résolution des enregistrements HTTPS fonctionne correctement
Je serais curieux de connaître vos résultats. Si le problème Firefox n’est pas reproductible de manière cohérente chez tout le monde, c’est justement à cause de toutes ces variables
(Et si quelqu’un de Cloudflare passe par là : https://cloudflare-quic.com/favicon.ico semble mal configuré. Et l’image https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg est chargée depuis la Wayback Machine, ce qui ralentit le chargement de la page ; pour les images, il vaut mieux utiliser un lien « id_ » afin d’éviter la réécriture et d’aller plus vite. Par le passé, cela m’avait permis de restaurer temporairement un site lors d’un échec de migration serveur via Cloudflare Workers. Ou alors, il suffit d’utiliser l’original : https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg. Le fichier existe toujours sur le site actuel)
J’ai énormément expérimenté ces dernières années avec toutes sortes d’implémentations et de déploiements bizarres de HTTP/3. C’est un excellent protocole. Mais il traîne aussi beaucoup de problèmes d’implémentation et de déploiement étranges
Je me demande si c’est spécifique à macOS. Impossible à reproduire sur Firefox 141 et 142 sous Windows
Très impressionnant ! Beau travail. Au début, j’ai lu QUIC CDN et je me suis dit « pas possible », puis en regardant de plus près, j’ai compris que Media over QUIC est quelque chose de distinct, et c’est plutôt intéressant
La première app était intéressante. Cela pourrait faire un bon Show HN. J’ai travaillé sur des plateformes vidéo en direct, et MoQ m’intrigue suffisamment pour me donner envie de refaire ce type de développement
Si « la technologie fonctionne sous le capot », alors j’estime que seule la prise en charge par les principaux navigateurs compte (et je ne vois rien non plus sur caniuse).
Et si c’était pris en charge par des moteurs de webview comme Microsoft Edge WebView2, j’aurais l’impression que c’est immédiatement exploitable en développement.
Mais à l’inverse, il faudrait aussi que des outils comme OBS ou des plateformes comme YouTube le prennent en charge pour que cela ait un vrai sens
Donc… MoQ s’écarte un peu de la logique d’une grosse API web « boîte noire » comme WebRTC. Du point de vue du navigateur, l’élément clé est la prise en charge de l’API WebTransport.
Avec WebTransport et MoQT, on ouvre par exemple de nombreuses nouvelles possibilités autour de lecteurs vidéo comme WebCodecs. Si on accepte un peu plus de latence, on peut aussi lire via MSE tout en gardant la gestion du DRM
Et le travail pour permettre une publication directe depuis OBS avait déjà commencé avant mon arrivée chez Cloudflare ; cela dépend fortement de la manière dont on implémente les détails média au niveau de la couche « format de streaming ». Dans l’industrie, la spécification de cette couche évolue encore activement, et à l’heure actuelle, la spec dominante est WARP. À mesure que la norme WARP se stabilisera, cette fonctionnalité pourra sans doute être intégrée directement dans OBS et ailleurs. Aujourd’hui déjà, il est possible de publier de la vidéo via Norsk (https://norsk.video/) avec un format de secours basé sur fMP4
Pour YouTube, il y a des gens chez Google qui contribuent activement à MoQT, mais je ne saurais pas dire avec certitude quand ni comment cela pourrait être adopté dans le produit YouTube
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
En pratique, WebCodecs n’est pas strictement indispensable, on peut aussi faire le rendu avec MSE, mais c’est plus compliqué et la latence est plus élevée.
Je travaille sur un fallback WebSocket et sur un encodeur OPUS en WASM pour la prise en charge de Safari