Alors que le web s’éveille doucement à HTTP/2, un autre protocole de communication commence à faire du bruit : Quick UDP Internet Connections. QUIC est un projet développé par Google en parallèle de SPDY. Après l’abandon des recherches sur SPDY (grâce à la sortie de HTTP/2), QUIC va enfin prouver son utilité, en particulier avec les clients mobiles.
En Juillet 2012, SPDY demande à devenir un standard et devient alors la base de réflexion de HTTP/2. Cette même année, Jim Roskind propose QUIC, une alternative au protocole de communication existant. En 2013, les premières expérimentations sur Chromium commencent et dès 2015, QUIC est utilisé dans les communications entre Chrome et les produits Google (Gmail, Google, Youtube, etc). Google annonce alors abandonner SPDY. Cet abandon officiellement lié à la standardisation de HTTP/2 peut être aussi vu comme lié à de bons résultats de QUIC durant ce test. En Juin 2015, QUIC demande à être standardisé. Alors qu’est-ce que QUIC ?
SPDY est donc un protocole “over TCP”. Et le problème est justement TCP. Le couple TCP TLS évolue très lentement alors que le reste du web ne s’arrête plus. C’est la que QUIC joue un de ses avantages. Créé pour le web d’aujourd’hui, ce protocole est pensé pour évoluer.
La vitesse de transmission d’un message est inhérente à la vitesse de la lumière. C’est la physique qui nous arrête même si des recherches pour atteindre une vitesse supérieure à celle de la lumière existent. Alors comment réduire la latence ?
Le problème de TCP TLS vient justement du nombre de round trip time (RTT) qui sont nécessaires pour établir une connexion entre un client et un serveur. Il y a déjà l’échange standard de TCP (1 RTT). Ensuite, TLS redemande certaines confirmations (2 RTT). Et c’est ce nombre que QUIC tente de réduire, voire même d'annihiler avec une promesse de 0 RTT.
Lors de sa première connexion, le client envoie une requête initiale avec toutes les informations nécessaires. À ce paquet, le serveur renvoie un autre paquet (Certificats, etc) ainsi qu’un identifiant qui sera associé à ce client. À la première connexion, on est donc à 1 RTT.
Le côté sécurité, jusque là traité par TLS, est pris en charge par une alternative, QUIC Crypto. Mais cette solution n’est que provisoire, dans l’attente de la sortie de TLS 1.3, que QUIC intégrera.
QUIC est une modification d’UDP, qui est connu pour la perte de paquets. C’est là qu’entrent en scène deux outils de QUIC : Forward-Error-Correcting (FEC) et Packet Pacing.
FEC est un paquet supplémentaire qui contient l’information d’un autre paquet.
Il permet alors, si ce paquet est perdu, de le reconstruire à partir de ceux qui ont été reçus. On a alors une augmentation du nombre de paquets, mais FEC est actif selon plusieurs paramètres comme la stabilité de la connexion, la latence, le nombre de paquets, etc, et s’adapte alors à l’environnement dans lequel il doit fonctionner.
Le Packet Pacing organise les paquets pour les envoyer à intervalles réguliers. Les paquets importants sont aussi dupliqués pour diminuer le risque de perte.
SPDY possède des nouveautés intéressantes comme le multiplexing ou encore la compression des headers. QUIC reprend ces avantages. Le multiplexing de HTTP/2 résout le problème de head-of-line blocking existant dans HTTP/1.1. Malheureusement ces avancées ne résolvent pas le problème de head-of-line blocking causé par TCP. QUIC s’affranchit de ce problème.
Alors que nos habitudes évoluent et se dirigent de plus en plus vers des support mobiles, les protocoles de communication n’ont pas vraiment bougés. TCP n’est ni pensé ni adapté aux technologies mobiles. À chaque changement de réseau, les connexions sont totalement interrompues, et c’est extrêmement frustrant pour l’utilisateur.
Et c’est peut-être dans ce domaine que QUIC va réellement s’imposer. Même si le 0-RTT ne fonctionne pas à chaque fois à cause du changement d’IP régulier d’un support mobile, QUIC bat tout de même le couple TCP TLS. Mieux encore, il gère très bien le changement de réseau.
Lors d’un changement de réseau, par exemple le passage du Wifi à un réseau 3G, TCP perd la connexion. Dans le cas de QUIC, ce n’est pas votre connexion qui importe, mais votre identifiant (celui que le serveur vous a donné lors de votre première connexion). Au moment du changement de réseau, le client mobile envoie alors un message au serveur avec son identifiant et sa nouvelle connexion. QUIC sait alors où retransmettre les données demandées.
D’après Robbie Shade, le choix d’UDP était stratégique. QUIC aurait pu totalement s’abstraire de ce choix comme base, mais ce protocole est connu du réseau d’aujourd’hui, et cela fait de QUIC est une solution envisageable dès maintenant.
Même si 91 à 94% des terminaux clients acceptent les connexions UDP, l’ajout d’un firewall par exemple peut bloquer les connexions via UDP. Si ce problème survient, QUIC redonne la main à une connexion TCP.
Il y a des similitudes entre QUIC et SCTP. Encore une fois, d’après Robbie Shade, SCTP est une bonne solution mais malheureusement inutilisable. Elle n’est pas adaptée au web moderne.
Il possible de constater par soi-même le fonctionnement de QUIC.
Via Chrome, installez le plugin HTTP/2 and SPDY Indicator. Ensuite, il suffit d’aller dans les paramètres de Chrome (chrome://flags/#enable-quic) et d’activer QUIC. Ce plugin permet, entre autre, de constater qu’actuellement la première connexion à un service Google, comme Gmail, se fait via HTTP/2. La seconde connexion sera faite avec QUIC.
Chromium possède un “jeu de test” server/client qu’il est possible d’essayer.
Les DevSisters ont sorti leur propre standalone du projet (trouvant celui de Chromium bien trop complexe à utiliser), ainsi qu’une implémentation en Go.
Aujourd’hui, on peut dire que QUIC émerge : lors de la Google I/O, l’application DUO a été annoncée. Elle utilisera, entre autre, QUIC. Le début de QUIC sur mobile sera donc à tester prochainement !
Google semble donc vouloir changer la donne, “Make the web faster”.
Références: