Streaming vidéo dans le navigateur

Qui suis-je ?

Dev/Ops chez Criteo (département SRE)
Avant: Ingénieur Système chez Alwaysdata

Affichage de publicité en ligne
2500 employés, 500 ingénieurs
6 data centers dans le monde, 35 000 serveurs, ...
On a une équipe réseau et on recrute :)

Dans cette présentation :

Comment diffuser de la vidéo dans un navigateur ?

Le navigateur
Streaming de contenu avec HTTP
Streaming en temps réel avec WebRTC

Le navigateur

Dans cette partie :

Définition d'un navigateur
Afficher de la vidéo
Contraintes du système
Contraintes du réseau

Définition d'un navigateur

Parcourt le web: ensemble de documents multimédias, liés entre eux par des hyperliens
Une ressource est identifiée par une URL
Le navigateur télécharge et exécute des applications
Qui tournent sur une couche d'abstraction de la plateforme (OS)
Dans un environnement sécurisé

Afficher de la vidéo dans le navigateur

Avant, les plugins comme Flash (propriétaire)
Aujourd'hui: <video>
Dans les tuyaux: APIs en Javascript (Web Audio, HTMLMediaElement), EME (DRM)

Afficher de la vidéo dans le navigateur

            <video loop controls src="public/horseplay-2.webm"></video>
            <video controls>
              <source src="public/horseplay-2.webm">
              <source src="public/horseplay-2.mp4">
            </video>

Contraintes du système

Performances (CPU, GPU)
Codecs disponibles
Compatibilité hardware (acquisition, affichage)
Batterie
C'est la jungle !

Contraintes du réseau

Bande passante
Latence
Perte de paquets (fiabilité)
QoS, Firewalls, IPv4, NAT
C'est le Far-West !

Streaming de contenu avec HTTP

Dans cette partie :

TCP
HTTP/1.1
HTTP/2
TLS, QUIC, et le futur

TCP

Protocole de streams full-duplex
Contrôle de congestion (cwnd, rwnd)
Ordre des données garanti
Arrivée garantie
Head-of-Line blocking

HTTP/1.1 : une requête

		    GET /resource HTTP/1.1
		    Host: www.martiusweb.net
		    Connection: Keep-Alive

HTTP/1.1 : une réponse

		    HTTP/1.1 200 OK
		    Connection: Keep-Alive
		    Date: Tue, 27 Oct 2015 15:02:49 GMT
            Content-Type: text/html
            Content-Length: 22796

Avantages

Simple et facile à utiliser
Ports 80 et 443, toujours ouverts
Extensible et versatile :
- Cache et requêtes conditionnelles
- Range-Request
- Encoding: Chunked

Inconvénients

Mauvaises implémentations de HTTP partout
Limité par TCP (Head of Line, slow-start, handshake)
Synchronicité des messages (personne n'implémente le pipelining correctement)
Le chargement de la page retarde le chargement de la vidéo
Bloated: on envoie des tonnes de données inutiles
Utilisation inutile de gzip dans certains cas, etc

`Range-Request` : oui, tu peux !

		    HTTP/1.1 200 OK
		    Accept-Ranges: bytes
		    ...

`Range-Request` : requête

		    GET /video.webm HTTP/1.1
		    Range: bytes=0-4096
		    ...

`Range-Request` : réponse

		    HTTP/1.1 206 Partial Content
		    Content-Length: 4096
		    Content-Range: bytes 0-4096/381467554
		    ...

`Range-Request`

Téléchargement de fragments de fichiers
Multi-homing (téléchargement depuis plusieurs sources)
Permet des bidouillages pour faire de l'adaptive bitrate
... avant/avec MSE (API haut niveau qui permet de pousser des chunks dans un renderer <video>) ?

HTTP/2: Résoudre les problèmes

Multiplexage sur un seul stream TCP
Priorisation des flux (mais bon)
Built-in compression
Stateful: pas besoin de renvoyer des infos redondantes à chaque requête
Compatible HTTP/1.1, donc Range-Requests
Un peu un gros hack par les ports 80/443...

Pour la vidéo ?

Meilleure réactivité globale
Au niveau des chunks de vidéo :
Réduction de la latence (un seul socket TCP = pas de slow-start, etc)
Priorisation des chunks à afficher rapidement

TLS, QUIC, ?

TLS: chiffrage de bout en bout
coût élevé en CPU
obscur pour le coeur de réseau
QUIC: pour remplacer TCP?

Streaming en temps réel avec WebRTC

Dans cette partie :

Objectifs de WebRTC
MediaStream
Signaling
RTCPeerConnection: ICE, STUN, TURN, Nat traversal
RTCDataChannel: SCTP over UDP

Objectifs de WebRTC

Adresser le problème du temps réel (timeliness plutôt que reliability)
Fournir une API en Javascript permettant d'acquérir et manipuler du contenu multimédia
Fournir un ensemble de protocoles standards et inter-opérables

WebRTC, un gros framework

MediaStream

navigator.getUserMedia(constraints, onStream, onError);
        function onStream(stream) {
          var video = document.querySelector('video');
          video.src = window.URL.createObjectURL(stream);
        }

RTCPeerConnection

API Javascript
Canal de communication full-duplex avec un pair
Utilise les protocoles SRTP et SRTCP (over UDP)
Chiffré avec DTLS (Datagram TLS)
Le navigateur s'occupe de l'adaptive bitrate

RTCDataChannel

API Javascript
Canal de communication pour des données arbitraires
Orienté message
Garanties optionnelles :
- ordonné ou non
- délivraison garantie ou non

SCTP

RTCDataChannel utilise SCTP
Normalement au niveau de TCP ou UDP
Mais encapsulé dans le l'UDP pour traverser les NAT

Etablir une connexion: le problème des NAT

Distribue dans un réseau local du trafic depuis Internet
Les pairs ne connaissent pas leur IP publique
Les NAT ne savent pas comment router les paquets
Ils utilisent une table de correspondance privé/public

NAT

STUN

Session Traversal Utility for NAT
Indique à un client son IP publique
Force le NAT à maintenir la correspondace avec des heartbeats

STUN

TURN

Traversal Using Relay around NAT
Quand le NAT est défectueux, ou la topologie de réseau complexe
Ou le trafic UDP est bloqué
Passage par un relai public
Coûteux, car plus peer-to-peer

TURN

ICE

Interactive Connectivity Establishment
Négociation du mode de communication :
- Obtention de l'IP publique
- Tests de connectivité
- Paquets Heartbeat (Keep Alive)
- Public > STUN > TURN

Comment deux pairs se trouvent ? Le signaling

Le signaling ne fait pas partie de WebRTC
Canal utilisé pour mettre en relation les pairs
Négociation d'une offre rédigée en SDP

Signaling

Bibliographie

Les RFCs:
- HTTP/1.1 : ~~2616~~, 7230-7235, HTTP/2 : 7540
- WebRTC : 7478
- ICE : 5245, STUN : 5389, TURN : 5766, SDP : 4566, DTLS : 6347, SCTP : 4960, SRTP : 3711
- WebRTC API côté W3C : www.w3.org/TR/webrtc/

Bibliographie

High Performance Browser Networking
Ilya Grigorik, O'Reilly Media, 2013

C'est aussi le crédit images

Des questions ?

m.richard@criteo.com
martius@martiusweb.net
https://marti.us
Twitter, github, etc: Martiusweb
Lien vers cette présentation: https://marti.us/t/upmc-network-18/

Streaming vidéo dans le navigateur

Qui suis-je ?

Dans cette présentation :

Le navigateur

Dans cette partie :

Définition d'un navigateur

Afficher de la vidéo dans le navigateur

Afficher de la vidéo dans le navigateur

Contraintes du système

Contraintes du réseau

Streaming de contenu avec HTTP

Dans cette partie :

TCP

HTTP/1.1 : une requête

HTTP/1.1 : une réponse

Avantages

Inconvénients

Range-Request : oui, tu peux !

Range-Request : requête

Range-Request : réponse

Range-Request

HTTP/2: Résoudre les problèmes

Pour la vidéo ?

TLS, QUIC, ?

Streaming en temps réel avec WebRTC

Dans cette partie :

Objectifs de WebRTC

WebRTC, un gros framework

MediaStream

MediaStream

RTCPeerConnection

RTCDataChannel

SCTP

Etablir une connexion: le problème des NAT

NAT

STUN

STUN

TURN

TURN

ICE

Comment deux pairs se trouvent ? Le signaling

Signaling

Bibliographie

Bibliographie

Des questions ?

`Range-Request` : oui, tu peux !

`Range-Request` : requête

`Range-Request` : réponse

`Range-Request`