QUIC, la fin de TCP pour 2019, enfin… plutôt 2021 ! Partie 1/3 : Pourquoi et Comment ?

 

Update 28 mai 2021 : Voilà c’est enfin fait ! l’IETF a sorti ses RFC après près de 2 ans de retard ! RFC 8999, 9000 (QUIC transport), 9001 et 9002. C’est historique : le RFC 793 pour TCP de septembre 1981 est détrôné !

Chez ISIS-Performance Phenisys, le protocole TCP est un allié et la matière de notre art quotidien. Nous l’étudions, l’analysons, l’optimisons et le domptons pour toujours plus de Performance. Seulement voilà, toutes les bonnes choses ont une fin… TCP va céder sa place à un adversaire trop puissant, trop indifférent, trop rapide, trop adaptable. Un adversaire en outre complètement insidieux et traitre, car il va exploiter ce vieux bêta d’UDP comme cheval de Troie. Cet adversaire s’appelle QUIC. Il arrive, vite, bientôt. La transition sera rapide, peut-être brutale et tous se rallieront à QUIC. Mais les experts d’ISIS-Performance de Phenisys seront là pour apporter les derniers soins palliatifs à cette transition, dés 2019 2021.

---

Down the rabbit hole ?

Est-ce que les experts d’ISIS-Performance de Phenisys auraient complètement craqué ? TCP règne en maitre du transport sur l’Internet depuis près de 30 ans et a hébergé tout HTTP et le web sur sa couche. C’est du béton !

Oui, et c’est exactement le problème que certains lui reprochent : c’est du béton ! Il est inaltérable et inamovible.

Mais pour vous en convaincre je me dois de développer un peu. En tant « qu’expert TCP », je vais même me risquer à vous faire quelques prédictions.

1. Pourquoi ? Parce que Google l’a décidé ! Hé oui, c’est presque aussi simple que cela aujourd’hui l’Internet.

2. Comment ? Avec QUIC, un protocole concocté par Google qui s’appuie sur UDP. QUIC promet de « vampiriser et softwariser » l’intelligence qu’il y avait en TCP. Explications.

3. Quand ? C’est ma petite prédiction 2019* : Avec une sortie en Juillet 2019, le sort de TCP devrait être réglé en 6 mois à 75%. Démonstration.

4. Et ensuite ? C’est une révolution et un nouveau défi, pour les entreprises et pour tous les praticiens des réseaux : monitoring, performance, sécurité… Tout est à revoir ! Il y a peut-être encore plus sérieux aussi…

Voilà pour la réponse courte.

* Edit 2021 : Evidemment faire une prédiction est un risque quasi garanti de se tromper. En 2021, l’IETF n’a toujours pas sorti ses RFC. Les documents de base de QUIC ont beau être finalisés (RFC 8999 à 9002, statut AUTH48 soit 48h à quelques semaines de leur sortie) depuis le 27/04/2021, toujours rien. De plus, la norme la plus importante, HTTP over QUIC, est passé en avis du groupe de travail HTTP, ce qui remet plusieurs mois encore de délai. Peut-être qu’en 2022, ma prédiction sera juste.

Chez ISIS-Performance Phenisys, nous aimons aller au fond des choses. Alors je vous propose une série de 3 articles pour fouiller un peu le sujet.

Partie 1/3 : Pourquoi et Comment ?

Partie 2/3 : Quand ?

Partie 3/3 : Et après ?

---

Pourquoi ?

TCP est un protocole puissant et ingénieux qui avait pour objectif de fiabiliser les échanges entre un client et un serveur tout en partageant équitablement la bande passante, ressource rare (au début) et partagée sur les réseaux IP par paquets (par opposition aux réseaux à liaisons ou circuits dédiés). Il remplit cet office admirablement et s’est imposé depuis 1981. Malgré l’énorme évolution des réseaux physiques et avec quelques menues améliorations, ses différents mécanismes n’ont pas été remis en cause fondamentalement.

Néanmoins, il comporte désormais quelques limitations à l’heure du temps de réponse en millisecondes en raison de ses mêmes brillants mécanismes qui sont assujettis à la latence du réseau : 3-way handshake (1,5 RTT) pour n’en retenir qu’un. Or TCP est intouchable sous peine que plus rien ne fonctionne, en raison de toutes les « middle boxes » comme les nomment les gens des applications, c’est à dire les routeurs, firewall, proxy, traffic shaper, WAN optimizers, etc. Bref, il s’est fossilisé.

Par ailleurs, SSL (TLS) est venu s’ajouter sur TCP pour sécuriser le Web qui a basculé de HTTP à HTTPS, notamment sous l’impulsion de Google et la généralisation de HTTP/2. Mais TLS nécessite encore un échange de certificats avec son Client HELLO/Server HELLO (+1,5 à +3 RTT) en plus de TCP pour envoyer la première donnée utile pour l’utilisateur. Cela finit par être sensible.

Comment ?

Ainsi, sous le louable mobile d’accélérer le Web, Google qui nous veut du bien (« Don’t do Evil »), a inventé QUIC (1), Quick UDP Internet Connection, un protocole pour remplacer TCP & TLS d’un seul coup avec l’objectif ultime du zéro RTT pour envoyer des données utiles pour l’utilisateur (0-RTT).

Positionnement protocolaire de QUIC par rapport à TCP/TLS/HTTP

Description des mécanismes d’établissement d’une connexion avec TCP, TCP+TLS et QUIC.
Source Google : https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html

Et tout cela, c’était il y a 6 ans déjà !

Quic flashback

Google a donc inventé QUIC en 2013, ainsi que le protocole de chiffrement associé pour sécuriser le Web (clin d’oeil à Sylvain Germe, ex-consultant ISIS-Performance qui a soulevé ce sujet chez nous dés 2014). Inventer une suite de protocoles propriétaires n’est pas vraiment un problème lorsque l’on maîtrise le côté client (Chrome) et serveur (google.com, gmail.com, youtube.com…).

Puis en 2016, Google a fait quelques tentatives « l’air de rien », de basculer ses services dont Youtube en QUIC pour les navigateurs compatibles…

Lorsqu’un problème majeur de sécurité a été découvert en décembre 2015, il n’a fallu que 2 mois pour le désactiver, corriger, redéployer, réactiver… en toute transparence. Encore mieux, en quelques jours de septembre 2016, avec l’activation sur Youtube mobile, ce sont plus de 30% de son trafic sortant qui sont « passés en QUIC ».

Soit 7% de tout l’Internet, une paille…

Expérimentation QUIC de Google : petit incident (bug) de sécurité détecté en décembre 2015 et ajout de l’application YouTube mobile en septembre 2016, notable.
Source : http://delivery.acm.org/10.1145/3100000/3098842/p183-Langley.pdf

Mais l’IETF n’a pas forcément apprécié la tentative ! En effet, l’Internet, particulièrement en matière de chiffrement, doit s’appuyer sur des standard, discutés, partagés, ouverts et interopérables. Google a donc fait machine arrière et pris son bâton de pèlerin pour entamer le chemin de la normalisation IETF. Ouf, on a eu chaud.

Notez le langage policé des communications officielles IETF : “Google designed its own version of QUIC and then deployed it both in its popular Chrome browser and most of its services, including Youtube and search. This allowed them to observe the protocol in action and tweak its design before submitting it to the IETF for consideration in 2016.”

Pour résumer techniquement le contenu de QUIC, voici ce qu’il contient dans les grandes lignes.

Objectifs clés de QUIC :

• Minimiser les délais d’établissement de connexion et de l’ensemble du transport pour les applications, à commencer par HTTP/2 (et viser l’établissement en 0-RTT). De précieuses centaines de millisecondes sont à gagner. Dans le e-commerce, Walmart indique que 100 ms gagnés sur son site représente 1% de chiffre d’affaire en plus. Par ailleurs en streaming vidéo, la mémoire tampon se chargera beaucoup plus vite.
• Apporter le multiplexage sans phénomène de « head-of-line blocking » (le retard d’un objet de départ, par une perte par exemple, bloque l’ensemble de tous les chargements). L’application a conscience des flux réseaux qui passent ou se bloquent et peut ainsi mieux gérer son contenu pour l’utilisateur.
• Ne nécessiter de changement que sur les extrémités du chemin pour le déploiement. C’est un changement majeur, car c’est alors l’application (coté client + serveur) qui maitrise le protocole et son évolution. L’infrastructure réseau n’a plus de prise sur son fonctionnement et il peut donc évoluer vite. Ce que TCP ne peut plus faire.
• Permettre des extensions pour le multi-chemin, par exemple pour passer du WiFi à la 4G sans coupure (alors que vous changez d’adresse IP, plus besoin de ré-établir de connexion !) et le Forward Error Correction (auto-correction d’erreurs de transmission)
• Apporter un transport systématiquement sécurisé, utilisant TLS 1.3 par défaut : la communication est impérativement chiffrée, mais le protocole de communication lui-même l’est aussi. Plus rien ne doit être lisible.

Vous pouvez approfondir le sujet avec les liens ci-dessous, mais ce sont les implications qui sont les plus intéressantes et l’objet de cet article.

• La conférence de Natasha Rooney à la conférence PerformanceNow() à Amsterdam à laquelle toute l’équipe technique d’ISIS-Performance était présente en novembre 2018 est un bon début. Elle m’a inspiré cet article. De quoi commencer doucement… chers confrères du réseau, passez à la suivante, Natasha s’adresse à des dev
  Néanmoins, la conférence est sympa, elle met en perspective les questions de protocoles par rapport aux applis web et à l’histoire depuis HTTP/1.0
  Natasha Rooney | Down the line: Evolving HTTP and making things QUIC |…
  https://vimeo.com/305436333 (meilleure qualité audio et vidéo)
• Cette vidéo de Robin Marx est carrément encore plus cool et encore plus claire que celle de Natasha Rooney. Si vous voulez vraiment tout comprendre très simplement (et que vous aimez les super-héros) alors il ne faut regarder que celle-ci ! Ce gars va aussi vous convaincre de l’intérêt de tout ce que je raconte dans la suite de cet article. D’autant que je ne l’ai découvert qu’en clôture de cet article (Merci à Olivier Leroy).

• Explications sur QUIC chez Cloudflare avec plus de détails :  The Cloudflare Blog – 26 Jul 18

• Un article de blog IETF sur l’actualité récente de QUIC :
  https://www.ietf.org/blog/whats-happening-quic/

Ainsi, ce qu’il faut retenir et comprendre, au delà de l’objectif d’accélérer le Web qui sera atteint à n’en pas douter, c’est que toute l’intelligence du protocole passe dans TLS, donc chiffré, et ne dépend plus que des extrémités ! C’est une révolution ! Le protocole se protège de la fossilisation induite par la rigidité de l’infrastructure réseau.

Dit autrement, le protocole est passé du monde de l’infra au monde du logiciel. Il va donc pouvoir évoluer avec l’agilité du logiciel !

C’est un changement énorme. Une nouvelle dimension.

Aujourd’hui, les fameux « slow-start », « congestion control », « window scaling », « 3-duplicate acks », « selective acks », etc. de TCP ne sont plus que des plug-ins dans QUIC.

Ce point particulier mérite à lui seul une explication en dernière partie de cette série d’articles.

Fort bien, mais où en est cette « révolution » ?

---

Je vous propose de tenter de prédire le calendrier de cette migration de manière argumentée dans une 2ème partie :

QUIC, la fin de TCP pour 2019 ! Partie 2/3 : Quand ?