Le web classique peut être résumé à une grosse archive, mise à jour plus ou moins rapidement.
Comment faire pour réduire cette latence au maximum et diffuser des données au fur et à mesure, en flux ?
Pour du texte, c'est facile, ce sont les outils de discussions, mais pour du son ou de l'image, ça devient de suite un poil plus complexe. Hors Internet, ça existe depuis un siècle, ça s'appelle la radio et la télévision.
Pendant longtemps, la diffusion multimédia a été squattée par des plugins (coucou RealPlayer , puis coucou Flash ) qui ont heureusement été éradiqués par les smartphones.
Petit tour d'horizon des solutions existantes, libres, ou utilisables simplement avec des outils libres. En commençant par ce qui passe dans de le HTTP.
Décrire un flux
La fondation MPEG a défini depuis longtemps des formats de stream, utilisés historiquement pour la télévision câblée, dès que la télé est passée de l'analogique au numérique.
Le concept est simple, un flux est décrit par une suite de paquets, les paquets ont un entête, puis du contenu. Quand on se branche dans un flux en cours, on attend de lire un début d'entête, on vérifie que l'entête décrit un paquet souhaité, et l'on peut commencer à remplir un buffer, qui sera lu et décompressé par un lecteur pour finalement arriver sur un écran, et/ou une enceinte.
MPEG est un regroupement de sociétés fans de licences et de procès.
Dans le monde du libre, on a Ogg et Matroška qui serviront de base à WebM implémenté par Google.
Attention à ne pas confondre le format de conteneur (mkv, mov, mp4, ogg, webm…) et les codecs, pour CODeur/DECodeur, (h264, vorbis, vp9…), dans cet article nous ne vous parlerons que d'emballage, pas de contenu.
HTTP Pour tout faire
Pour peu que l'on prenne la peine de mettre les informations nécessaires au début du flux, il est possible de commencer à lire un média, avant d'avoir fini de le télécharger. C'est le progressive download .
Il est donc possible de lire un flux, si pour chaque client, on commence par mettre les quelques paquets décrivant le flux, puis enchaîner par les paquets que l'on reçoit depuis la source, les mêmes pour tout le monde.
HTTP/1.0
La spécification 1.0, d'avant le déluge, est brutale : pas d'annonce de la taille du contenu, et coupure de la socket TCP quand c'est fini.
Il est donc possible de streamer du contenu, en se contentant de tout pousser dans la socket.
C'est le choix qu'a fait Icecast , leader cacochyme de la web radio.
Globalement, les proxys HTTP (nginx, haproxy…) galèrent à gérer le foutoir d'HTTP/1.0 et risquent de bufferiser les réponses, et de tout péter, pour rendre service. Du coup, le mainteneur Debian recommande de ne pas mettre de proxy devant son Icecast, pour que ça tombe en marche. De toute façon, Icecast a la flemme de loguer l'IP indiquée dans le header HTTP, et collera l'IP du proxy dans ses logs. Il est tout à fait possible de mettre un proxy devant Icecast, mais ce serait tellement plus simple si ce dernier prenait la peine de suivre les normes et usages du moment.
HTTP/1.1
Cette version, tout à fait civilisée, impose d'annoncer la taille de la réponse (ce qui ne nous arrange pas), ou d'utiliser du chunked transfer . Avec les chunks, on spécifie une taille, puis on envoie un chunk de la taille annoncée, et on recommence, jusqu'à annoncer une taille de zéro pour clore.
HTTP/2.0
Hérité de SPDY, cette version met du binaire de partout, et surtout se base sur du multiplexing pour tout faire passer sur une seule connexion TCP, avec des notions de priorités. Techniquement, on est très proche du fonctionnement historique des flux télévisuels, c'est donc la fête pour les flux multimédias.
Pour les devs, un peu moins. Golang, poussé par le même Google qui a poussé SPDY et HTTP/2, permet de streamer une réponse en HTTP/1.1 et HTTP/2 sans sueurs. Pour les autres langages, c'est un peu moins la fête.
Pour l'instant, les APIs Javascript n'exposent rien de spécifique à HTTP/2, mais l'utilisent dans ses couches basses, tout comme les balises <video> et <audio> .
Assembler un flux
L'avantage des flux de paquets, c'est qu'on peut les tripoter sans toucher au contenu. On peut tout à fait recevoir le flux d'une émission, le couper pour mettre le flux d'un jingle, pour enchaîner sur le flux d'une chanson. Ce sera sec, sans transition, mais très peu coûteux en ressources.
Transcoder (passer de mp3 à vorbis par exemple) est imaginable, parce que bien sûr, chaque client va avoir ses goûts personnels, ou la trouille des licences (Linux) ou de l'absence de licence (Apple), et ne pourra donc pas forcément gérer les mêmes formats que ses camarades. Pour le son, la consommation en CPU est mesurée, par contre, pour de la vidéo, certains matos seront aidés par des instructions spécifiques, ou des coprocesseurs (comme sur les ARMs), qui pourront tout simplement ne pas être capables de gérer un codec ambitieux, comme vp9 .
La rolls pour préparer un flux à streamer est l'inévitable liquidsoap , de quoi vous occuper quelque temps.
Mise à l'échelle
Pour du son, on parle de 64 ou 128k par utilisateur, je vous laisse faire une règle de trois avec les offres de bande passante de votre hébergeur, mais pour des audiences raisonnables, ça passe tranquille.
Le broadcast radio reste la meilleure réponse pour gérer plein d'auditeurs. Techniquement, ce n’est rien du tout de brancher un émetteur FM au cul d'un flux de son. Ça se bricole à partir d'un Raspberry Pi ou avec un kit électronique. Vous retrouverez la folle ambiance des radios libres des années 80, et vous aurez une visite des gendarmes par ce que c'est règlementé, l'usage des ondes radios. Par contre, c'est la réponse ultime pour arroser plein de gens pas trop loin.
Si on veut toucher plein de gens, dispersés, il va falloir passer par un CDN.
Attention, pour ne pas perturber les lecteurs, le flux servi en HTTP commence par un "début de flux", pour chaque client. Cette adaptation à chaque client ne sera absolument pas gérée par un proxy cache ou même un CDN. Il faut soit un proxy spécifique (Icecast peut être le proxy d'un autre Icecast), soit avoir un protocole sans effort pour un CDN.
HTTP Live Streaming
Créé par Apple, le HLS ressemble à un gros hack. Le client va télécharger une playlist, qui contient les URLs ordonnées de plein de petits fichiers, et quand on a fini la playlist, et bien on la recharge, puis on recommence.
La playlist, au format Winamp, est annotée pour que l'on puisse choisir un débit, et comme l'échantillonnage des paquets est fixe, on peut changer de résolution, sans bouger dans la timeline.
C'est tellement simple qu'on peut le gérer en JS avec HLS.js .
La norme prévoit du chiffrement, et de fait, ce protocole est utilisé dans des offres de VOD.
Les petits bouts de fichiers sont servis en HTTP bien classique, avec etag et last-modified , et il n'y a pas la notion de trame de début. Ça fonctionne avec n'importe quel CDN, qui se chargera de trouver un relai cache près de chez vous.
C'est le protocole sollicité par youtube-dl pour aspirer du contenu, et je suppose qu'il est utilisé par divers matos embarqués, la norme étant bien prévisible, et ne nécessite ni plugin, ni code spécifique, ni interpréteur de Javascript.
La norme le lie au format MPEG-4 en H264. Rien n'empêche de suivre le même protocole avec des formats libres, mais comme ce n'est pas normalisé, ce sera spécifique.
Au-delà du dôme du TCP
Avec ce type d'outils, on va avoir des choses prévisibles, plutôt classiques à héberger, mais avec des latences entre 1 et 10 secondes.
Pour une radio classique, ça passe, pour interagir avec des utilisateurs (voix, chat textuel, téléphone), ou pour du commentaire sportif, ça va être mou, il va falloir envisager des technologies plus exotiques.