Le réseau dans les navigateurs web

# Le réseau dans les navigateurs web

Paul Adenot, Mozilla Corporation, 2014

---

# Agenda

- Mozilla
- Introduction
- HTTP
- HTTP2
- Streaming HTTP
- WebRTC

---

# Mozilla

- But non lucratif !
- [Manifeste](https://www.mozilla.org/fr/about/manifesto/)
- Firefox
- Firefox OS
- 1000 personnes tout compris dans le monde
- Des dizaines de milliers de bénévoles !
- Présence à l'IETF, au W3C
- Paul: `<audio>`, `<video>`, Web Audio API (implem + spec), WebRTC, etc.

---

# Introduction

- Navigateur: un des logiciels les plus utilisés sur un ordinateur
- Flash est mort (trou *gigantesque* de sécu)
- Ports: HTTP(80), HTTPS(443) principalement
- *Web*: Liens + HTTP(S) + HTML/CSS/JS + Web APIs
- Texte, images, vidéos, audio, jeux, etc.
- Une plateforme d'application sandboxée, capable de faire tourner des applications non fiables.

---

# HTTP

---

# HTTP: plein plein de RFC

- HTTP1.1: [RFC 2616](http://tools.ietf.org/html/rfc2616), mais récemment découpé: 
 - Protocol, routage: [7230](http://tools.ietf.org/html/rfc7230),
 - Sémantique, contenu: [7231](http://tools.ietf.org/html/rfc7231),
 - Requêtes conditionelles: [7232](http://tools.ietf.org/html/rfc7232),
 - Range-requests: [7233](http://tools.ietf.org/html/rfc7233),
 - Caching: [7234](http://tools.ietf.org/html/rfc7234),
 - Authentification: [7235](http://tools.ietf.org/html/rfc7235)
- Et puis:
 - [2817](http://tools.ietf.org/html/rfc2817): <strike>SSL</strike> *TLS*
 - [5785](http://tools.ietf.org/html/rfc5785): URI
 - [6585](http://tools.ietf.org/html/rfc6585): status codes

---

# HTTP en deux minutes

Dans une socket TCP sur le port 80, envoyez:

```
GET /
Host: paul.cx
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Thu, 03 Apr 2014 15:17:45 GMT
Cache-Control: max-age=0
```

Et vous receverez:

```
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 05 Nov 2014 21:17:21 GMT
Content-Type: text/html
Content-Length: 4740
Last-Modified: Thu, 03 Apr 2014 15:17:45 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "533d7b99-1284"
Accept-Ranges: bytes
```
 
```
<blablabla> <le> <document>
</blablabla> </le> </document>
```

---

# Les soucis

- HTTP est trop gros
- HTTP a trop d'options (pratiquement personne n'implémente tout)

- HTTP est mal utilisé:
    - Taille de transfers, nombre d'objets
    - Latence
    - Head of line blocking

???

HTTP1: 60 pages
HTTP1.1: 176 pages (trois ans plus tard)

Assez dur de dire comment implémenter tout HTTP parce que définir "tout" est dur

---

# Trop souvent, trop gros

- TCP slow-start (certains trichent)
- Nov. 2010: environ 702KB par page, 70 requêtes
- Oct. 2014: environ 2MB par page, 100.6 requêtes

---

# Limiter le nombre de requêtes?

- Concaténation
- Minification
- Image spriting
- Image inlining
- Sharding sur plusieurs domaines pour faire des requêtes en parallele/enlever
les cookies

---

# Latence

- Au cours des années
    - Bande passante: ↗
    - Latence: →
- Surtout sur mobile !
- Le pipelining HTTP est une blague
- Lenteur pour charger des pages (parce que beaucoup de round-trips)

---

# Head of line blocking

- Le souci de la file d'attente de la machine qui vent des tickets de métro avec
des touristes en heure de pointe: tous les clients rapides sont bloqués par un
client lent
- On ne peut pas changer de file une fois notre décision prise
- "Créer une nouvelle file d'attente" est couteux
- Le pipelining est désactivé par défaut dans Firefox et Chrome

---

# HTTP2

---

# HTTP2

Plusieurs buts:
- Être moins sensible à des latences hautes
- Rendre le pipelining _moins inutile_, fixer le head of line blocking
- Arrêter d'avoir besoin de faire des hacks pour limiter le nombre de requêtes
- Être rétrocompatible
- Être standard, fait à l'IETF avec les gens/entreprises
important·e·s
- Construit sur SPDY/3, fait par Google

???

Quand HTTPbis a commencé, Google avait déployé SPDY dans Chrome + ses sites, et
avait montré que ça marchait. Quelque sed plus tard, SPDY/3 -> http2-draft-00

---

# HTTP2: Concepts

- Même paradigme: le client envoie des requêtes, le serveur répond, sur TCP
- http:// et https:// ne changent pas (ça serait un désastre pour migrer)
- HTTP doit être _proxyfiable_ vers HTTP2, parce qu'il y a encore du vieux code partout
- Enlever ou réduire les parties optionelles du protocole
- Pas de versions mineurs (soit compatible, soit pas compatible)

---

# HTTP2: Autres concepts
- Principalement sur TLS (au moins dans les gros navigateurs)
- Binaire! (pour séparer le framing et le protocole, mais c'est pas trop grave
parce que de toute façon, c'est compressé)
- Multiplexage des requêtes (une seule connection TCP) et entrelaçage des resources (avec gestion des priorités)

???

Debugger des serveurs HTTP avec netcat, c'était bien, maintenant, on utilisera
des outils

---

# HTTP2: Autres trucs pas mal

- Compression moins vulnérable (à BREACH/CRIME): HPACK
- Compression de headers
- `RST_STREAM`: reset d'une connection
- Server push: le serveur envoie une resource qu'il n'a pas demandé au client
parce qu'il sait que le client en aura besoin bientôt
- Système de window propre au protocol
- ALTSVC (alternative service) pour faire du load-balancing

---

# HTTP2, en gros:

- Du positif: moins de round-trips, plus de choses en parallèle, pas de blocages
- Du moins positif, mais ça passe: plus compliqué à implémenter, nécessite plus d'outils pour debugger

---

# Streaming media sur HTTP

---

# Streaming media HTTP

- RTMP: flash, donc pas terrible
- RTSP: un peu supporté par Firefox OS, c'est tout
- Pour le reste, on se débrouille avec HTTP, 206 Partial-Content et une bonne
dose de JavaScript

---

# Le streaming HTTP en deux minutes

```html
<video loop controls src="https://paul.cx/public/horseplay-2.webm">
</video>

<video controls>
 <source src="https://paul.cx/public/horseplay-2.webm">
 <source src="https://paul.cx/public/horseplay-2.mp4">
</video>
```

---

# HTTP 206 Partial-Content

- Un moyen de ne télécharger qu'une partie d'une resource: utile pour _seeker_
- Très utile pour télécharger le header du fichier, puis l'index (à la fin, des
fois), puis commencer à faire le décodage
- Implémenté par virtuellement tous les serveurs Web de nos jours

---

# HTTP pour le live streaming

- Le serveur pousse juste des données dans une socket
- Le client est responsable de gérer les erreurs
- Facile à implémenter, basique, solide
- Un seul flux, pas de changement de qualité

---

# HLS - HTTP Live Streaming

- Un truc à la Apple
- iOS, Safari, Android Browser, Chrome for Android
- Pas standard du tout _du tout_
- On met quelque chose qui ressemble à une playlist m3u8 à la place de l'URL de
la vidéo, avec différentes qualités, et hop

```
#EXT-X-VERSION:3
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:10,
http://media.example.com/segment0.ts
#EXTINF:10.0,
http://media.example.com/segment1.ts
#EXTINF:9.5,
http://media.example.com/segment2.ts
#EXT-X-ENDLIST
```
---

# DASH - Dynamic Adaptative Streaming over HTTP

- MPD (Media presentation description) au début:
<div class=minicode>
```xml
<MPD xmlns="urn:mpeg:DASH:schema:MPD:2011" mediaPresentationDuration="PT0H3M1.63S" minBufferTime="PT1.5S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"
type="static">
 <Period duration="PT0H3M1.63S" start="PT0S">
 <AdaptationSet>
 <ContentComponent contentType="video" id="1" />
 <Representation bandwidth="4190760" codecs="avc1.640028" height="1080" id="1" mimeType="video/mp4" width="1920">
 <BaseURL>car-20120827-89.mp4</BaseURL>
 <SegmentBase indexRange="674-1149">
 <Initialization range="0-673" />
 </SegmentBase>
 </Representation>
 <Representation bandwidth="2073921" codecs="avc1.4d401f" height="720" id="2" mimeType="video/mp4" width="1280">
 <BaseURL>car-20120827-88.mp4</BaseURL>
 <SegmentBase indexRange="708-1183">
 <Initialization range="0-707" />
 </SegmentBase>
 </Representation>
 </AdaptationSet>
 </Period>
</MPD>
```

- Le contenu est coupé en petit morceaux
- Le client choisit lesquels prendre en fonction des conditions réseau
- Standardisé par MPEG
- _Oui mais non_

---

# MSE - Media Source Extension !

- [Specification W3C](https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html)
- Découple le réseau du décodage/rendu: bas niveau
- On télécharge les buffers qu'on veut (XHR) et on les ajoute dans une `<video>`
(Qui dispose d'une `MediaSource`)
- Implémentation de HLS & DASH possible
- Dans Chrome/IE11 et bientôt dans Firefox

---

# WebRTC

- Communication Audio/Video/Données Peer2Peer directement dans le navigateur
- Le _signaling_ est laissé à la charge de l'application
- Aussi besoin d'un serveur pour les NAT et firewalls un peu trop méchants
- Utilise des techniques classiques en VoIP

---

# WebRTC: architecture

---

# WebRTC: Protocols

- DTLS-SRTP: transport
- STUN: session traversal utilities for NAT
- TURN: traversal using relays around NAT
- ICE: interactive connectivity establishement

---

# WebRTC: DTLS-SRTP

- Utilisé pour faire transiter, en P2P, le flux video et audio, et les donnée
- Datagram Transport Layer Security - Secure Real Time Protocol
- Non fiable, basse latence, sécurisé
- RFC3711

---

# WebRTC: STUN

- Permet à un hôte de découvrir sa propre adresse IP publique lorsque qu'il est
derrière un NAT
- On envoie un message (souvent UDP) à un serveur publique en lui demandant notre IP publique
- Lorsqu'on a notre adresse publique, on  s'en sert comme _candidat_ pour une
connection P2P

---

# WebRTC: TURN

- Traversal using relays around NAT
- Quand les NAT sont trop méchants (NAT symétriques), TURN permet de contourner
- Marche quel que soit le NAT, mais des fois le firewall bloque explicitement

---

# WebRTC: ICE

- Interactive Connectivity Establishment
- Permet de _classer_ tous les candidats (hosts, p2p, relayé) par priorité, et
de les communiquer à l'autre hôte
- Critères: latence, taille de paquets, etc.
- Quand la communication est établie, ICE s'arrête: P2P complet

IPv6 permet aussi de régler tout ces soucis, chaque machine ayant s(on|es) adresse !

---

# Questions ?

---

# La fin

- Paul Adenot
- @<a href=https://twitter.com/padenot>padenot</a>
- <<a href=mailto:paul@paul.cx>paul@paul.cx</a>>
- <a href=http://daniel.haxx.se/http2/>http2 explained</a>

---