Vers QUIC: ce qui sous-tend HTTP / 3

Une nouvelle étape importante dans l'histoire d'Internet commence sous nos yeux: nous pouvons supposer que HTTP / 3 a déjà été annoncé. Fin octobre, Mark Nottingham de l'IETF a suggéré de déjà décider d'un nom pour le nouveau protocole sur lequel l'IETF s'est construit depuis 2015. Ainsi, au lieu de noms de type QUIC, un fort HTTP / 3 est apparu. Les publications occidentales ont déjà écrit à ce sujet et plus d'une fois . L'histoire de QUIC a commencé dans les entrailles de Good Corporation en 2012, car seuls les serveurs de Google prenaient en charge les connexions HTTP sur QUIC, mais le temps passe et Facebook a déjà commencé à mettre en œuvre cette technologie (le 7 novembre, Facebook et LiteSpeed ​​ont fait la première interaction via HTTP / 3 ); Actuellement, la part des sites prenant en charge QUIC est de 1,2%. Enfin, le groupe de travail WebRTC se tourne également vers QUIC (plus voir l' API QUIC ), donc dans un avenir prévisible, la vidéo / audio en temps réel passera par QUIC au lieu de RTP / RTCP. Par conséquent, nous avons décidé qu'il serait formidable de révéler les détails de l'IETF QUIC: spécialement pour Habr, nous avons préparé une traduction du longread dotting i. Profitez-en!

QUIC (Quick UDP Internet Connections) est un nouveau protocole de couche de transport par défaut chiffré qui comporte de nombreuses améliorations HTTP: à la fois pour accélérer le trafic et augmenter la sécurité. QUIC a également un objectif à long terme: remplacer éventuellement TCP et TLS. Dans cet article, nous examinerons à la fois les puces QUIC clés et les raisons pour lesquelles le Web en bénéficiera, ainsi que les problèmes de prise en charge de ce tout nouveau protocole.

En fait, il existe deux protocoles du même nom: Google QUIC (gQUIC), le protocole original développé par les ingénieurs de Google il y a plusieurs années, qui, après une série d'expériences, a été adopté par l'Internet Engineering Task Force (IETF) pour la normalisation.

IETF QUIC (ci-après simplement QUIC) présente déjà des différences si fortes avec gQUIC qu'il peut être considéré comme un protocole distinct. Du format de package à la prise de contact et au mappage HTTP, QUIC a amélioré l'architecture gQUIC d'origine en collaborant avec de nombreuses organisations et développeurs qui ont un objectif commun: rendre Internet plus rapide et plus sécurisé.

Alors, quelles améliorations offre QUIC?

Sécurité intégrée (et performances)

L'une des différences les plus notables entre QUIC et TCP vénérable est l'objectif déclaré à l'origine d'être un protocole de transport sécurisé par défaut . QUIC y parvient en utilisant l'authentification et le chiffrement, qui se produisent généralement à un niveau supérieur (par exemple, dans TLS), et non dans le protocole de transport lui-même.

La prise de contact QUIC originale combine la communication à trois voies habituelle sur TCP avec la prise de contact TLS 1.3, qui fournit l'authentification des participants, ainsi que la coordination des paramètres cryptographiques. Pour ceux qui connaissent TLS: QUIC remplace le niveau d'enregistrement TLS par son propre format de trame, mais utilise en même temps des poignées de main TLS.

Cela permet non seulement à la connexion d'être toujours cryptée et authentifiée, mais aussi plus rapidement pour établir la connexion initiale: une poignée de main QUIC ordinaire effectue l'échange entre le client et le serveur en une seule passe, tandis que TCP + TLS 1.3 effectue deux passes.


Cependant, QUIC va plus loin et crypte également les métadonnées de connexion qui peuvent être facilement compromises par un tiers. Par exemple, les attaquants peuvent utiliser des numéros de paquets pour diriger les utilisateurs sur plusieurs chemins réseau lorsque la migration de connexion est utilisée (voir ci-dessous). QUIC chiffre les numéros de paquets, de sorte qu'ils ne peuvent être corrigés par personne d'autre que les vrais participants à la connexion.

Le chiffrement peut également être efficace contre la «stagnation» - un phénomène qui ne permet pas d'utiliser la flexibilité du protocole en raison d'hypothèses incorrectes dans les implémentations (ossification - c'est pourquoi TLS 1.3 a été présenté pendant longtemps . Nous ne l'avons publié qu'après quelques modifications qui empêcher les blocs indésirables pour les nouvelles révisions TLS).

Blocage du début de la file d'attente (blocage en tête de ligne)

L'une des principales améliorations apportées par HTTP / 2 est la possibilité de combiner différentes requêtes HTTP dans une seule connexion TCP. Cela permet aux applications HTTP / 2 de traiter les demandes en parallèle et de mieux utiliser le canal réseau.

Bien sûr, ce fut un pas en avant significatif. Parce que les applications antérieures devaient initier de nombreuses connexions TCP + TLS si elles voulaient traiter plusieurs requêtes HTTP en même temps (par exemple, lorsque le navigateur doit recevoir à la fois CSS et JavaScript pour afficher la page). La création de nouvelles connexions nécessite plusieurs prises de contact, ainsi que l'initialisation de la fenêtre de surcharge: cela signifie ralentir le rendu de la page. Les requêtes HTTP combinées évitent cela.



Cependant, il y a un inconvénient: puisque plusieurs requêtes / réponses sont transmises sur la même connexion TCP, elles dépendent toutes également de la perte de paquets, même si les données perdues ne concernent qu'une seule des requêtes. Cela s'appelle "bloquer le début de la file d'attente".

QUIC va plus loin et fournit un support de première classe pour combiner les demandes, par exemple, différentes demandes HTTP peuvent être considérées comme des demandes QUIC de transport différentes, mais en même temps, elles utiliseront toutes la même connexion QUIC - c'est-à-dire que des poignées de main supplémentaires ne sont pas nécessaires, il y en a une état d'encombrement, les demandes QUIC sont délivrées indépendamment - par conséquent, dans la plupart des cas, la perte de paquets affecte une seule demande.

Ainsi, il est possible de réduire considérablement le temps, par exemple, pour le rendu complet d'une page Web (CSS, JavaScript, images et autres ressources), en particulier dans le cas d'un réseau surchargé avec une perte de paquets élevée.

Si simple, hein?

Pour tenir sa promesse, le protocole QUIC doit surmonter certaines des hypothèses que de nombreuses applications réseau tiennent pour acquises. Cela peut compliquer la mise en œuvre et la mise en œuvre de QUIC.

QUIC est conçu pour être livré sur des datagrammes UDP afin de faciliter le développement et d'éviter les problèmes avec les périphériques réseau qui abandonnent les paquets de protocoles inconnus (car la plupart des périphériques prennent en charge UDP). Il permet également à QUIC de vivre dans l'espace utilisateur. Ainsi, par exemple, les navigateurs pourront implémenter de nouvelles fonctionnalités de protocole et les transmettre aux utilisateurs finaux, sans attendre les mises à jour du système d'exploitation.

Cependant, le bon objectif de réduire les problèmes de réseau rend plus difficile la protection des paquets et leur acheminement correct.

Un NAT pour se réunir tous ensemble et s'unir avec une seule volonté noire

En règle générale, les routeurs NAT fonctionnent avec des connexions TCP en utilisant un tuple de 4 valeurs (IP source et port plus IP et port de destination), ainsi que la surveillance des paquets TCP SYN, ACK et FIN transmis sur le réseau; les routeurs peuvent déterminer quand une nouvelle connexion est établie et quand elle s'est terminée. Par conséquent, une gestion précise des liaisons NAT (communications entre IP et ports internes et externes) est possible.

Dans le cas de QUIC, ce n'est pas encore possible, car les routeurs NAT modernes ne connaissent pas encore QUIC, donc ils rétrogradent généralement vers un traitement UDP par défaut et moins précis, ce qui signifie des délais d'expiration arbitraires (parfois courts) , ce qui peut affecter les connexions à long terme.

Lorsqu'une nouvelle liaison se produit (par exemple, en raison d'un délai d'attente), le périphérique en dehors du périmètre NAT commence à recevoir des paquets d'une autre source, ce qui rend impossible de maintenir la connexion en utilisant uniquement un tuple de 4 valeurs.


Et ce n'est pas seulement NAT! Une fonctionnalité QUIC est appelée migration de connexion et permet aux appareils de transférer des connexions vers d'autres adresses / chemins IP à leur discrétion. Par exemple, un client mobile pourra transférer une connexion QUIC d'un réseau mobile vers un réseau WiFi déjà connu (l'utilisateur a entré un café préféré, etc.).

QUIC essaie de résoudre ce problème avec le concept d'ID de connexion: une information de longueur arbitraire, transmise en paquets QUIC et permettant d'identifier la connexion. Les appareils d'extrémité peuvent utiliser cet ID pour suivre leurs connexions sans se réconcilier avec le tuple. En pratique, il devrait y avoir de nombreux ID pointant vers la même connexion, par exemple, pour éviter de connecter des chemins différents lorsque la connexion est migrée, car l'ensemble du processus est contrôlé uniquement par les périphériques finaux et non par les boîtiers de médiation.

Cependant, il peut y avoir un problème pour les opérateurs de télécommunications qui utilisent anycast et le routage ECMP, où une adresse IP peut potentiellement identifier des centaines ou des milliers de serveurs. Étant donné que les routeurs frontaliers de ces réseaux ne savent pas encore comment traiter le trafic QUIC, il peut arriver que des paquets UDP provenant de la même connexion QUIC, mais avec des tuples différents, soient envoyés à différents serveurs, ce qui signifie une déconnexion.



Pour éviter cela, les opérateurs peuvent avoir besoin d'implémenter un équilibreur de niveau plus intelligent. Cela peut être réalisé par programme sans affecter les routeurs frontaliers eux-mêmes (par exemple, voir le projet Katran de Facebook).

Qpack

Une autre fonctionnalité utile de HTTP / 2 était la compression d'en-tête (HPACK) , qui permet aux terminaux de réduire la taille des données envoyées en supprimant les demandes et réponses inutiles.

En particulier, entre autres techniques, HPACK utilise des tables dynamiques avec des en-têtes qui ont déjà été envoyés / reçus à partir de demandes / réponses HTTP précédentes, ce qui permet aux appareils de se référer dans de nouvelles demandes / réponses aux en-têtes rencontrés précédemment (au lieu de les renvoyer) .

Les tables HPACK doivent être synchronisées entre l'encodeur (la partie qui envoie la demande / la réponse) et le décodeur (le côté récepteur), sinon le décodeur ne peut tout simplement pas décoder ce qu'il reçoit.

Dans le cas de HTTP / 2 sur TCP, cette synchronisation est transparente car la couche de transport (TCP) délivre les requêtes / réponses dans le même ordre dans lequel elles ont été envoyées. Autrement dit, vous pouvez envoyer des instructions au décodeur pour mettre à jour les tables dans une simple demande / réponse. Mais avec QUIC, les choses sont beaucoup plus compliquées.

QUIC peut livrer plusieurs requêtes / réponses HTTP dans différentes directions en même temps, ce qui signifie que QUIC garantit l'ordre de livraison dans une direction, alors qu'il n'y a pas de telle garantie dans le cas de plusieurs directions.

Par exemple, si un client envoie une demande HTTP A dans le flux QUIC A, ainsi qu'une demande B dans le flux B, alors en raison de la permutation de paquets ou de pertes de réseau, le serveur recevra la demande B avant la demande A. Et si la demande B a été codée comme a été indiqué dans l'en-tête de la demande A, le serveur ne pourra tout simplement pas décoder la demande B, car il n'a pas encore vu la demande A.

Le protocole gQUIC a résolu ce problème en rendant simplement tous les en-têtes (mais pas les corps) des requêtes / réponses HTTP séquentielles dans un seul flux gQUIC. Cela garantit que tous les en-têtes sont dans le bon ordre, quoi qu'il arrive. Il s'agit d'un schéma très simple, avec son aide, les solutions existantes peuvent continuer à utiliser du code affiné sous HTTP / 2; d'autre part, cela augmente la probabilité de bloquer le début de la file d'attente, ce que QUIC est conçu pour réduire. Par conséquent, le groupe de travail IETF QUIC a développé un nouveau mappage entre HTTP et QUIC (HTTP / QUIC), ainsi qu'un nouveau principe de compression d'en-tête, QPACK.

Dans la version finale des spécifications HTTP / QUIC et QPACK, chaque échange de demande / réponse HTTP utilise son propre flux QUIC bidirectionnel, donc le blocage du début de la file d'attente ne se produit pas. De plus, afin de prendre en charge QPACK, chaque participant crée deux flux QUIC unidirectionnels supplémentaires, l'un pour envoyer les mises à jour de table, l'autre pour confirmer leur réception. Ainsi, le codeur QPACK ne peut utiliser le lien vers la table dynamique qu'après que le décodeur a confirmé sa réception.

Réflexion réfringente

Un problème commun avec les protocoles basés sur UDP est leur sensibilité aux attaques par réflexion, lorsque l'attaquant force un serveur à envoyer une énorme quantité de données à la victime. L'attaquant usurpe son adresse IP afin que le serveur pense que la demande de données provient de l'adresse de la victime.


Ce type d'attaque peut être très efficace lorsque la réponse du serveur est incomparablement plus grande que la demande. Dans ce cas, ils parlent de «gain».

TCP n'est généralement pas utilisé pour de telles attaques, car les paquets de la poignée de main d'origine (SYN, SYN + ACK, ...) ont la même longueur, donc ils n'ont pas de potentiel "d'amplification".

En revanche, la prise de contact QUIC est très asymétrique: comme dans TLS, le serveur QUIC envoie d'abord sa chaîne de certificats, qui peut être assez grande, malgré le fait que le client ne doit envoyer que quelques octets (le message du client ClientHello TLS est intégré au package QUIC ) Pour cette raison, l'emballage d'origine QUIC doit être augmenté jusqu'à une certaine longueur minimale, même si le contenu de l'emballage est beaucoup plus petit. Quoi qu'il en soit, cette mesure n'est toujours pas très efficace, car une réponse de serveur typique contient plusieurs paquets et peut donc être plus qu'un package client élargi.

Le protocole QUIC définit également un mécanisme de vérification de source explicite: le serveur, au lieu de donner une réponse importante, envoie uniquement un paquet de nouvelle tentative avec un jeton unique, que le client envoie ensuite au serveur dans un nouveau paquet. Ainsi, le serveur a plus confiance que le client n'a pas d'adresse IP de remplacement et vous pouvez mettre fin à la prise de contact. Moins de la décision - le temps de la poignée de main augmente, au lieu d'une passe, deux sont déjà nécessaires.

Une autre solution consiste à réduire la réponse du serveur à une taille où l'attaque par réflexion devient moins efficace - par exemple, en utilisant des certificats ECDSA (généralement ils sont beaucoup plus petits que RSA). Nous avons également expérimenté un mécanisme de compression de certificat TLS utilisant des algorithmes de compression standard tels que zlib et brotli; il s'agit d'une fonctionnalité qui est apparue pour la première fois dans gQUIC mais qui n'est actuellement pas prise en charge dans TLS.

Performances UDP

L'un des problèmes constants de QUIC est le matériel et les logiciels existants qui ne peuvent pas fonctionner avec QUIC. Nous avons déjà examiné comment QUIC essaie de gérer les boîtiers de médiation réseau comme les routeurs, mais un autre domaine potentiellement problématique est la performance d'envoi / réception de données entre les périphériques QUIC via UDP. Depuis de nombreuses années, des efforts ont été faits pour optimiser autant que possible les implémentations TCP, y compris les capacités de déchargement intégrées dans les logiciels (par exemple, les systèmes d'exploitation) et dans le matériel (interfaces réseau), mais rien de tout cela ne concerne UDP.

Cependant, ce n'est qu'une question de temps avant que les implémentations QUIC dépassent ces améliorations et avantages. Jetez un œil aux efforts récents pour implémenter le déchargement UDP sur Linux , qui permettrait aux applications de combiner et de transmettre plusieurs segments UDP entre l'espace utilisateur et la pile réseau de l'espace noyau au prix d'environ un segment; un autre exemple est la prise en charge de la zérocopie pour les sockets sous Linux , grâce à laquelle les applications pourraient éviter le coût de la copie de la mémoire de l'espace utilisateur vers l'espace noyau.

Conclusion

Comme HTTP / 2 et TLS 1.3, le protocole QUIC devrait apporter une tonne de nouvelles fonctionnalités qui amélioreront les performances et la sécurité des sites Web et des autres participants à l'infrastructure Internet. Le groupe de travail de l'IETF a l'intention de déployer la première version des spécifications QUIC d'ici la fin de l'année, il est donc temps de réfléchir à la façon dont nous pouvons tirer le meilleur parti des avantages de QUIC.