QUIC, TLS 1.3, DNS sur HTTPS, puis partout

Habr, bonjour! Il s'agit d'une transcription du rapport d' Artyom ximaera Gavrichenkov, qu'il a lu à BackendConf 2018 dans le cadre du festival RIT ++.

- Bonjour!

Le titre du rapport contient une longue liste de protocoles, nous allons le parcourir progressivement, mais commençons par ce qui n'est pas dans le titre.

Cette rubrique (sous la coupe) de l'un des blogs, sur Internet, vous pouvez voir beaucoup de ces rubriques. Dans ce post, il est écrit que HTTP / 2 n'est pas un avenir lointain, c'est notre présent; Il s'agit d'un protocole moderne développé par Google et des centaines de professionnels de nombreuses entreprises avancées, publié par l'IETF sous forme de RFC en 2015, c'est-à-dire il y a déjà 3 ans.

Les normes IETF sont acceptées par l'industrie, comme les documents en béton armé comme une pierre tombale, en fait.



Il est prévu qu'ils déterminent le développement d'Internet et prennent en compte tous les scénarios d'utilisation possibles. Autrement dit, si nous avions une ancienne version du protocole, puis qu'une nouvelle est apparue, elle conserve définitivement la compatibilité avec tous les cas d'utilisateurs précédents et résout en outre un tas de problèmes, optimise le travail, etc.

HTTP / 2 devait être adapté pour le Web avancé, prêt à l'emploi dans les services et applications modernes, en fait, être un remplacement direct pour les anciennes versions du protocole HTTP. Il était censé augmenter les performances du site, tout en réduisant la charge du backend.



Même les référenceurs ont dit qu'ils avaient besoin de HTTP / 2.



Et cela semblait très facile à supporter. En particulier, Neil Craig de la BBC a écrit sur son blog qu'il suffisait de "simplement l'activer" sur le serveur. Vous pouvez toujours trouver de nombreuses présentations où il est dit que HTTP / 2 est inclus comme suit: si vous avez Nginx, vous pouvez corriger la configuration en un seul endroit; s'il n'y a pas de HTTPS, vous devez en plus mettre un certificat; mais, en principe, il s'agit d'un jeton dans le fichier de configuration.

Et, bien sûr, après avoir enregistré ce jeton, vous commencez immédiatement à recevoir des bonus de productivité accrue, de nouvelles fonctionnalités disponibles, d'opportunités - en général, tout devient merveilleux.


<sup>Liens depuis la diapositive:
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2.www.cloudflare.com/website-optimization/http2</sup>

L'histoire ultérieure est basée sur des événements réels. La société dispose d'un service en ligne qui traite environ 500 à 1 000 requêtes HTTP par seconde. Ce service est sous protection DDoS de Cloudflare.

Il existe de nombreux tests de référence qui confirment que le passage à HTTP / 2 réduit la charge sur le serveur, car lors du passage à HTTP / 2, le navigateur établit non pas 7 connexions, mais une selon le plan. Il était prévu que lors du passage à HTTP / 2, la mémoire utilisée deviendrait inférieure et le processeur serait moins chargé.

De plus, le blog Cloudflare et le site Web Cloudflare suggèrent d'activer HTTP / 2 en un seul clic. Question: pourquoi ne pas faire ça?



Le 1er février 2018, la société inclut HTTP / 2 avec ce bouton dans Cloudflare, et sur Nginx local l'inclut également. Les données mensuelles sont collectées. Le 1er mars, les ressources consommées sont mesurées, puis les sysops regardent le nombre de demandes dans les journaux qui arrivent via HTTP / 2 au serveur derrière Cloudflare. La diapositive suivante sera le pourcentage de demandes qui sont arrivées au serveur via HTTP / 2. Levez la main, qui sait quel sera ce pourcentage?

[Du public: «1-2%!»]



- Zéro. Pour quelle raison?



Cloudflare, ainsi que d'autres services de protection contre les attaques, MSSP et services cloud, fonctionnent en mode proxy inverse . Si dans une situation normale, le navigateur se connecte directement à votre Nginx, c'est-à-dire que la connexion passe directement du navigateur à votre serveur HTTP, vous pouvez utiliser le protocole pris en charge par le navigateur.

S'il y a un cloud entre le navigateur et votre serveur, la connexion TCP entrante est interrompue dans le cloud, TLS y est également interrompu et la requête HTTP va d'abord dans le cloud, puis le cloud traite réellement cette requête.

Le cloud possède son propre serveur HTTP, dans la plupart des cas le même Nginx, dans de rares cas, il s'agit d'un serveur "auto-écrit". Ce serveur analyse la demande, la traite d'une manière ou d'une autre, consulte les caches et, finalement, forme une nouvelle demande et l'envoie déjà à votre serveur en utilisant le protocole qu'il prend en charge.

Tous les clouds existants qui prétendent prendre en charge HTTP / 2 prennent en charge HTTP / 2 sur le côté du navigateur. Mais ne le soutenez pas sur le côté regardant vers vous.



Pourquoi?

Une réponse simple et pas tout à fait correcte: "Parce que dans la plupart des cas, Nginx est déployé et Nginx ne peut pas passer par HTTP / 2 en amont." Bon, eh bien, cette réponse est correcte , mais pas complète .



La réponse complète nous est donnée par les ingénieurs Cloudflare. Le fait est que l'objectif de la spécification HTTP / 2, écrite et publiée en 2015, était d'augmenter les performances du navigateur sur des cas d'utilisation spécifiques, par exemple pour Google.

Google utilise ses propres technologies, n'utilise pas de proxy inverse devant ses serveurs de production, donc personne n'a pensé au proxy inverse, et c'est pourquoi HTTP / 2 du cloud vers l'amont n'est pas utilisé. Là, en fait, il y a peu de profit, car en mode proxy inverse, de ce qui est décrit dans le protocole HTTP / 2, par exemple, Server Push n'est pas pris en charge, car il n'est pas clair comment cela devrait fonctionner si nous avons un pipeline.

Le fait que HTTP / 2 enregistre les connexions est cool, mais le proxy inverse seul les enregistre car il n'ouvre pas une connexion par utilisateur. Il ne sert à rien de prendre en charge HTTP / 2 ici, et les frais généraux et les problèmes associés à cela sont importants.



Ce qui est important: le reverse proxy est une technologie qui a commencé à être utilisée activement il y a environ 13 ans. Autrement dit, c'est la technologie du milieu des années 2000: je suis allé à l'école alors qu'il était déjà utilisé. Il n'est pas mentionné dans la norme publiée en 2015, il n'est pas pris en charge et les travaux pour le prendre en charge ne sont actuellement pas menés au sein du groupe de travail httpbis de l'IETF.

Ceci est un exemple des problèmes qui surviennent lorsque les gens commencent à implémenter HTTP / 2. En fait, lorsque vous parlez à des personnes qui se sont déployées et qui ont déjà une certaine expérience avec celui-ci, vous entendez constamment les mêmes mots.



Ils ont été mieux formulés par Maxim Matyukhin de Badoo dans un article sur Habré, où il a expliqué le fonctionnement de HTTP / 2 Server Push. Il a écrit qu'il était très surpris de la différence d'interaction de cette fonctionnalité particulière avec les navigateurs, car il pensait qu'il s'agissait d'une fonctionnalité entièrement développée, prête à être utilisée en production . J'ai déjà entendu cette phrase à propos de HTTP / 2 à plusieurs reprises: nous pensions que c'était un protocole de remplacement sans rendez-vous - c'est-à-dire que vous l'activez et que tout va bien - pourquoi tout est si compliqué dans la pratique, d'où viennent tous ces problèmes et les défauts?

Voyons cela.



Historiquement, dans les temps anciens, l'architecture d'Internet ressemblait à ceci. Il n'y avait pas de rectangle vert à un moment donné, mais ensuite il est apparu.

Les protocoles suivants ont été utilisés: comme nous parlons d'Internet et non du réseau local, au niveau inférieur, nous commençons avec IPv4. Au-dessus, le protocole TCP ou UDP a été utilisé, mais dans 90% des cas (puisque 80 à 90% du trafic sur Internet est le Web), TCP était le suivant, puis SSL (qui a ensuite été remplacé par TLS), et au-dessus était l'hypertexte HTTP . Peu à peu, la situation s'est développée selon laquelle, selon le plan, d'ici 2020, l'architecture d'Internet aurait dû changer radicalement.



IPv6 est avec nous depuis très longtemps. TLS a récemment été mis à jour, nous discuterons toujours de la façon dont cela s'est produit. Et le protocole HTTP / 2 a également été mis à jour.

Le merveilleux écrivain domestique de science-fiction Vadim Panov dans le cycle des Enclaves avait une phrase si merveilleuse : «Vous attendiez l'avenir. Voulez-vous un avenir? C'est venu. Tu ne voulais pas de lui? C'est venu de toute façon. » La seule chose qui est restée pratiquement intacte - il y a quelques années - est le protocole TCP.

Les gens qui sont engagés dans la conception d'Internet, ne pouvaient pas passer par une injustice aussi flagrante et ont décidé de jeter le protocole TCP aussi.

D'accord, c'est bien sûr une blague. Le problème n'est pas seulement que le protocole est trop ancien. Il y a des failles dans TCP. Il était particulièrement inquiétant pour beaucoup que le protocole HTTP / 2 soit déjà écrit, la norme 2015 était déjà en cours d'implémentation, mais il ne fonctionnait pas toujours spécifiquement avec TCP, et ce serait bien de mettre un autre transport en dessous, plus adapté à ce qui était autrefois appelé SPDY lors de ces conversations, puis pour HTTP / 2.



Le protocole a décidé d'appeler QUIC. QUIC est un protocole en cours de développement pour le transport. Il est basé sur UDP, c'est-à-dire qu'il s'agit d'un protocole de datagramme . Le premier projet de norme a été publié en juillet 2016, et le projet de version actuelle ...

[Le président vérifie le courrier au téléphone]

"... oui, toujours le 12."

Pour le moment, QUIC n'est pas encore un standard - il est activement écrit. Si je ne me trompe pas - je n'ai pas écrit sur la diapositive parce que j'avais peur de faire une erreur - mais à l'IETF 101 à Londres, il a été dit qu'en novembre 2018, il était prévu de le publier en tant que document final. C'est la norme QUIC elle-même, car il y a huit autres documents dans le groupe de travail des documents.



Autrement dit, il n'y a pas encore de norme, mais le battage médiatique actif est déjà en cours. Je n'ai énuméré que les conférences où je suis allé depuis six mois, où il y a eu au moins une présentation sur QUIC. À propos de «comment c'est cool», «comment nous devons y basculer», «que faire pour les opérateurs», «arrêtez de filtrer UDP - QUIC fonctionnera maintenant». Tout ce battage médiatique dure depuis un certain temps - j'ai déjà vu de nombreux articles qui exhortaient l'industrie du jeu à passer à QUIC au lieu de l'UDP habituel.


<sup>Liens depuis la diapositive:
1. conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop</sup>

En novembre 2017, le lien suivant est apparu sur la liste de diffusion du groupe de travail QUIC: celui du haut pour le livre blanc et celui du bas pour ceux qui ont du mal à lire le livre blanc - il s'agit d'un lien vers le blog de l'APNIC avec un résumé.

Les chercheurs ont décidé de comparer les performances de TCP et de QUIC sous sa forme actuelle. À titre de comparaison, afin de ne pas savoir qui est à blâmer et où Windows peut être à blâmer, du côté client, ils ont pris Chrome sous Ubuntu, et ont également pris 2 appareils mobiles: un Nexus et un Samsung (ndlr: Nexus 6 et MotoG) avec les versions Android 4 et 6, et ils ont également lancé Chrome.

Côté serveur, ils ont installé Apache pour voir comment fonctionne le serveur TCP et pour surveiller QUIC, ils ont arraché une partie du code open source qui se trouve dans le projet Chromium. Les résultats de référence ont montré que, dans toutes les conditions de serre, QUIC surpasse vraiment TCP, il y a certaines pierres angulaires qu'il perd.



Par exemple, l'implémentation QUIC de Google fonctionne bien pire que TCP si la réorganisation des paquets se produit sur le réseau, c'est-à-dire que les paquets arrivent dans le mauvais ordre dans lequel ils ont été envoyés par le serveur. En 2017-2018, à l'ère des réseaux mobiles et sans fil, il n'y a généralement aucune garantie que le forfait volera en principe, sans oublier dans quel ordre. QUIC fonctionne très bien sur un réseau câblé, mais qui utilise un réseau câblé maintenant?



En général, les développeurs de ce code dans Google, apparemment, n'aiment vraiment pas les téléphones portables.

QUIC est un protocole qui est implémenté au-dessus d'UDP dans l'espace utilisateur. Et sur les appareils mobiles ainsi que dans l'espace utilisateur. Selon les résultats des mesures, dans une situation normale, c'est-à-dire lorsque vous travaillez via un réseau sans fil, la mise en œuvre du protocole QUIC passe 58% du temps dans Android à l'état «Application Limited». Quelle est cette condition? C'est l'état où nous avons envoyé des données et attendons une confirmation. À titre de comparaison, sur les ordinateurs de bureau, il y avait un chiffre d'environ 7%.

Seulement 2 cas d'utilisation: le premier est un réseau sans fil, le second est un appareil mobile; et QUIC fonctionne soit en TCP, soit bien pire. Naturellement, cela s'est avéré être dans le groupe de travail de l'IETF consacré à QUIC et, naturellement, Google a réagi à cela. La réponse de Google a été la suivante:


^{mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE}

Eh bien, nous avons ri, mais en fait, c'est absolument logique.

Pourquoi? Parce que la conception de QUIC - bien que nous parlions déjà de mise en œuvre en production, mais - en fait, l'expérience la plus folle.

Voici, disons, un modèle ISO / OSI à sept niveaux. Qui se souvient d'elle ici? Rappelez-vous les niveaux: physique, canal, réseau, transport, certains non-sens, certains non-sens et appliqués, non?

Oui, il a été développé il y a très longtemps, et en quelque sorte nous avons vécu avec ce modèle de niveau. QUIC est une expérience pour éliminer le système de niveau réseau lui-même. Il combine cryptage, transport et livraison fiable de données. Tout cela n'est pas dans la structure des niveaux, mais dans la moissonneuse-batteuse, où chaque composant a accès à l'API des autres composants.



Citant l'un des concepteurs du protocole QUIC Christian Guitem: «L'un des principaux avantages de QUIC d'un point de vue architectural est le manque de structure de niveau.» Nous avons la reconnaissance, le contrôle de flux, le cryptage et toute la cryptographie - tout cela est complètement dans un transport, et nos innovations de transport impliquent l'accès de tout cela directement à l'API réseau, donc nous ne voulons pas d'une architecture à plusieurs niveaux dans QUIC.



La conversation au sein du groupe de travail à ce sujet a commencé en raison du fait qu'au début du mois de mars, un autre concepteur de protocole QUIC, à savoir Eric Rescorla, a décidé de proposer pour discussion une variante dans laquelle tout le cryptage est supprimé de QUIC, en général. Il ne reste qu'une fonction de transport qui s'exécute au-dessus de DTLS. DTLS, à son tour, est TLS sur UDP, au total, il s'avère: QUIC sur TLS sur UDP.

D'où vient une telle offre? Soit dit en passant, Rescorla a écrit un document volumineux, mais pas du tout pour devenir une norme - c'était un sujet de discussion car dans le processus de conception de l'architecture QUIC, dans le processus de test d'interopérabilité et de mise en œuvre, de nombreux problèmes se sont posés. Principalement lié au "flux 0".

Qu'est-ce que le flux 0 dans QUIC? C'est la même idée que dans HTTP / 2: nous avons une connexion, à l'intérieur nous avons plusieurs flux multiplexés. Par conception QUIC, je me souviens, le cryptage est fourni par le même protocole. Cela a été fait comme suit: un flux "magique" numéro 0 est ouvert, qui est chargé d'établir une connexion, de se serrer la main et de chiffrer, après quoi ce flux 0 est chiffré et tous les autres sont également chiffrés. Avec cela, beaucoup de problèmes sont survenus, ils sont répertoriés sur la liste de diffusion, il y a 10 articles, je ne m'arrêterai pas à chacun. Je ne citerai qu'un seul que j'aime vraiment.


^{www.ietf.org/mail-archive/web/quic/current/msg03498.html}

Le problème avec le thread 0, dont l'un, est que si nous perdons des paquets, nous devons les renvoyer. Et en même temps, par exemple, côté serveur, la connexion peut déjà être marquée comme chiffrée, et le paquet perdu remonte à l'époque où il n'était pas chiffré. Dans ce cas, lors du transfert, l'implémentation peut chiffrer de manière aléatoire les paquets.

Encore une fois:



Chiffrement aléatoire des paquets.

C'est assez difficile à commenter, en plus de dire comment tout cela est réellement conçu. Le développement QUIC utilise en fait l'approche ersatz-agile. Autrement dit, ce n'est pas que quelqu'un a écrit une norme en béton armé qui peut être officiellement publiée après quelques itérations. Non.



Le travail est le suivant:
1. Le projet de norme commence, par exemple, le numéro 5;
2. Sur les listes de diffusion, ainsi que lors des réunions de l'IETF - trois pièces par an - des discussions ont lieu, puis la mise en œuvre est effectuée lors de hackathons, des tests d'interopérabilité, des commentaires sont collectés;
3. Google implémente certaines des modifications de Chrome, dans sa propre infrastructure, analyse les conséquences, puis le compteur est incrémenté et la norme 6 apparaît.

Maintenant, je vous le rappelle, version 12.
Remarque Ed.: Au 10 juillet 2018, c'est déjà le 13.

Qu'est-ce qui est important ici?

Tout d'abord, nous venons de voir les inconvénients, mais il y a des avantages. En fait, vous pouvez participer à ce processus. Les commentaires sont recueillis auprès de toutes les parties impliquées: si vous êtes impliqué dans le jeu, si vous pensez que vous dans l'industrie du jeu pouvez simplement changer et changer UDP, définir QUIC à la place, et tout fonctionnera - non, ce ne sera pas le cas. Mais au moment où vous pouvez l'influencer, vous pouvez en quelque sorte travailler avec.



Et c'est, en fait, une histoire commune. Des commentaires de votre part sont attendus, tout le monde veut les voir.

Google est en train de développer un protocole, en y insérant quelques idées - à ses propres fins. Les entreprises qui font autre chose (s'il ne s'agit pas d'applications Web, de jeux ou mobiles typiques, le référencement est le même), elles ne peuvent pas par défaut s'attendre à ce que le protocole tienne compte de leurs intérêts: non seulement parce qu'il n'intéresse personne, mais parce que personne ne connaît ces intérêts.

Ceci, soit dit en passant, est une confession. Bien sûr, la question est pour moi pourquoi nous, en tant que Qrator Labs , en particulier, n'avons pas participé au développement du protocole HTTP / 2 et n'avons parlé à personne du proxy inverse. Mais les mêmes Cloudflare et Nginx n'y ont pas non plus participé.

Bien que l'industrie ne soit pas impliquée dans cela, Google, Facebook, d'autres entreprises et universitaires se développent. Pour vous faire savoir, dans le parti proche de l'IETF, le mot «académicien» n'est, disons, pas louable. Cela ressemble aux épithètes «schizophrène» et «hypocondriaque». Les gens viennent souvent sans objectifs pratiques, sans comprendre les tâches réelles, mais s’y inscrivent, car il est plus facile d’obtenir une thèse de doctorat.

Bien sûr, il faut y participer et il n'y a pas d'autres options.



Revenons à QUIC: donc, le protocole est implémenté dans l'espace utilisateur, sur les appareils mobiles il y a ... Bla bla. "Implémenté dans l'espace utilisateur." Parlons-en.

Comment avons-nous généralement organisé le transport avant d'en arriver à QUIC? Comment ça marche maintenant en production? Il existe un protocole TCP si nous parlons du Web.



En TCP, il existe une triple poignée de main : SYN, SYN / ACK, ACK. Il est nécessaire pour un certain nombre de choses: pour empêcher le serveur d'être utilisé pour attaquer les autres, pour filtrer avec succès certaines attaques sur le protocole TCP, telles que SYN flood . Ce n'est qu'après le passage de 3 segments de la triple poignée de main que nous commençons à envoyer des données.



En même temps, il y a 4 actions, dont 3 se produisent dans le noyau, elles se produisent assez efficacement, et les données pénètrent déjà dans l'espace utilisateur lorsque la connexion est établie.



Dans la situation avec QUIC, tout ce bonheur est dans l'espace utilisateur. , «SYN, SYN/ACK», , , , user space. 20 / TCP SYN- , user space, c context switch'. - .

? QUIC – user space'? , , - .



, , Google . , , . user space, ( , , ) .

, , Google – . - , Google ( ). - , Google, , .


^{www.ietf.org/mail-archive/web/quic/current/msg03736.html}

QUIC, , user space. : « QUIC . , ». QUIC , , .



– . . , QUIC , , , , , , . – .

Linux, , QUIC , UDP, , … TCP, .


^{vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf}

. , UDP- Linux , TCP-, , . 2 ( , ):

1. UDP-;
2. «large segment offload». TCP , CPU, UDP , . , , , , , TCP , , , UDP, QUIC.


^{www.ietf.org/mail-archive/web/quic/current/msg03720.html}

Google, , , . Linux, , Windows, , , . , , Google QUIC, ( ) UDP- TCP-. Linux , .



.

QUIC. . , – , : HTTP/2 HTTP/1.1, QUIC TCP, DNS, IPv6 IPv4… , , production – , , benchmarking.

, , « // » – ! – , , .

, , , , -, , , .



, IPv6. , IPv6, , - , agile-. . , , , 10-20% IPv6. , .

IPv6 . , «Happy Eyeballs»? , , IPv6, , . , , , IPv6, , IPv6 , – , – IPv6, .

«Happy Eyeballs» ( , IETF): 0,3 IPv6-, , IPv4.

, , , , ! . , - - iPad, IPv6 IPv4 , 0,3 : 1 – 1 .

- IETF 99 : « Happy Eyeballs syslog' , , – - ». syslog – , , . , .

– , IPv6 – /64 , , , . - , .

, , - IPv6 . , . IPv4. , — . , , , , .

, , .


^{blog.apnic.net/2018/02/26/peak-dnssec}

– DNSSEC. , , , , .

IPv6, , , , , . , DNSSEC .

- ( APNIC Labs), , DNSSEC. : , , – 2016 .

DNSSEC , , - , , .


^{datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01}

DNS . IETF dnsop 3 , 15 , , « » : RFC.

DNS, , . TCP ( , ). TLS , HTTPS , QUIC .

, , . 2017 . OpenDNS IETF «DNS Camel» , « DNS». : (aka DNS), ?

, . , , -. , . , , production – , . , – .



? IETF – «RFC» – - . : SSL TLS.

, SSL 2, 0.9 1.0 production, , Netscape . SSL 2.0, . SSL 3.0 .

TLS 1.0 3 ; 1.1 – 7 ; 1.2 2 , ; , – 27- , – 10 .

, , TLS 1.3 use case', , , . , , , US Bank. , , , , , .

, - – – // , , , , .



, , .

: , – «- ». , , .

: , , , .

, : . , Google, , , , .

, , - - , , , , , , , .

Je vous remercie!