HTTP sur UDP - faire bon usage du protocole QUIC

QUIC (Quick UDP Internet Connections) est un protocole au-dessus d'UDP qui prend en charge toutes les fonctionnalités de TCP, TLS et HTTP/2 et résout la plupart de leurs problèmes. On le qualifie souvent de protocole nouveau ou « expérimental », mais il a longtemps dépassé le stade expérimental : le développement est en cours depuis plus de 7 ans. Pendant ce temps, le protocole n'a pas réussi à devenir une norme, mais s'est quand même répandu. Par exemple, QUIC est utilisé par des géants tels que Google et Facebook pour accélérer le trafic et réduire les délais dans les réseaux mobiles, et l'IETF a déclaré que sa branche du protocole constituait la base de la norme HTTP/3 (même si HTTP/2 utilise seulement 44.8% des sites).

Concept

QUIC a été développé pour remplacer l'ancien TCP, initialement conçu pour les réseaux filaires à faibles pertes. TCP délivre les paquets dans l'ordre, donc si un paquet est perdu, toute la file d'attente est arrêtée (blocage en tête de ligne), ce qui affecte négativement la qualité et la stabilité de la connexion. Pour éviter des pertes massives, les réseaux cellulaires ont recours à de grands tampons, ce qui entraîne une redondance et une réponse faussement négative du protocole (ballonnement tampon). De plus, TCP passe beaucoup de temps à établir une connexion : les requêtes SYN/ACK et TLS vont séparément, nécessitant trois allers-retours au lieu d'un, comme le fait QUIC.

Puisque QUIC combine un remplacement de TCP et une implémentation de TLS 1.3, toutes les connexions sont toujours cryptées, et le décryptage d'un tel trafic n'est pas plus facile que s'il passait par HTTPS. De plus, QUIC est implémenté au niveau de l'application, car un remplacement complet de la pile TCP prendrait éternité.

Malgré la prise en charge du multiplexage dans HTTP/2, le problème du blocage en tête de ligne persistait en raison de la nécessité de livrer les paquets dans l'ordre. QUIC est implémenté au-dessus d'UDP, il n'y a donc en principe aucun blocage, et pour éviter que les paquets ne soient perdus à jamais, ils sont numérotés et peuvent contenir des parties de « voisins », assurant ainsi la redondance. De plus, QUIC divise la file d'attente monolithique en plusieurs threads pour différents types de requêtes au sein d'une seule connexion. Ainsi, si un paquet est perdu, des problèmes peuvent survenir uniquement pour une seule file d'attente (par exemple, pour le transfert d'un fichier spécifique) :

l'utilisation de

Initialement, QUIC a été développé au sein de Google et a été largement adapté à une utilisation au sein de l'entreprise. En 2013, il a été transféré à l'IETF pour normalisation (qui est toujours en cours), et désormais chacun peut participer à l'élaboration du protocole en proposant ce qui lui manque. Le groupe de travail de l'IETF organise des réunions annuelles au cours desquelles une nouvelle norme est approuvée et les innovations sont discutées. Cette implémentation de QUIC est considérée comme la principale et c'est sur cette base que le standard HTTP/3 est certifié.

Jusqu'à présent, il n'est pas question d'inclure HTTP/3 comme protocole principal, car il n'est pas encore terminé et n'est presque pas pris en charge :

Mais QUIC peut être implémenté comme un moyen de transport entre l'application et le serveur, ce qui a été réalisé avec succès chez Uber :

Commentaire d'Uber sur l'introduction de QUIC

Pour intégrer avec succès QUIC et améliorer les performances des applications dans des environnements de connectivité médiocre, nous avons remplacé l'ancienne pile (HTTP/2 sur TLS/TCP) par le protocole QUIC. Nous avons utilisé la bibliothèque réseau Cronet de Projets Chrome, qui contient la version originale de Google du protocole - gQUIC. Cette implémentation est également constamment améliorée pour suivre la dernière spécification de l'IETF.

Nous avons d'abord intégré Cronet dans nos applications Android pour ajouter la prise en charge de QUIC. L'intégration a été réalisée de manière à réduire autant que possible les coûts de migration. Au lieu de remplacer complètement l'ancienne pile réseau qui utilisait la bibliothèque OkHttp, nous avons intégré Cronet SOUS le framework API OkHttp. En procédant à l'intégration de cette façon, nous avons évité de modifier nos appels réseau (qui sont utilisés par Rénovation) au niveau de l'API.

Semblable à l'approche adoptée pour les appareils Android, nous avons implémenté Cronet dans les applications Uber sur iOS, interceptant le trafic HTTP du réseau. APIUtilisation Protocole NSURL. Cette abstraction, fournie par la Fondation iOS, gère les données URL spécifiques au protocole et garantit que nous pouvons intégrer Cronet dans nos applications iOS sans coûts de migration importants.

tiré de cette traduction Articles Uber

Sur le backend, ils ont détecté des connexions QUIC via Google Cloud lb, qui prend en charge le protocole à partir de mi-2018.

Il n'est pas surprenant que Google Cloud fonctionne très bien avec le protocole développé par Google, mais quelles sont les alternatives ?

Nginx

Il n'y a pas si longtemps, CloudFlare J'ai essayé de traverser nginx (qui ne supporte pas HTTP/3 par défaut) avec son outil Quiche. L'implémentation est disponible sous la forme d'un seul fichier .patch, accompagné d'un didacticiel d'installation :

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

Ici vous pouvez connecter vos modules si nécessaire

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

Il ne reste plus qu'à activer le support HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

Il n'est pas encore possible de se connecter via HTTP/3 dans les navigateurs classiques, mais vous pouvez utiliser Chrome Canary et lance-le avec le drapeau --enable-quic, allez sur votre serveur ou, par exemple, sur le site quic.rocks et regardez le type de connexion dans Developer Tools :

Au lieu de HTTP/3, il est écrit http2+quic/99, mais c'est essentiellement la même chose.

Autres technologies

• QUIC prend également en charge LiteSpeed (qui s'est connecté à Facebook via HTTP/3 en grande pompe) et progressif Caddie. Apache ne peut pas encore le faire, mais le travail est en cours en plein essor.
• Mise à jour du 21 janvier projet de norme pour WebRTC
• L'autre jour, Microsoft a ouvert code d'implémentation msquic, dans lequel toutes les fonctions de la norme IETF ne sont pas encore disponibles, mais il s'agit déjà d'une grande avancée.

Conclusion

L'intérêt pour QUIC est instable, mais croissant, et des travaux sont en cours pour le standardiser. De nouvelles implémentations du protocole apparaissent presque chaque mois et chaque année, de plus en plus de développeurs sont convaincus que QUIC est l'avenir. Il est même possible d'inclure le protocole dans les futures versions de la pile TCP, ce qui signifie que tôt ou tard, l'ensemble d'Internet passera à des connexions plus stables et plus rapides.

Vous pouvez déjà configurer l'interaction QUIC pour votre infrastructure ou même la donner aux navigateurs - ils prévoient tous d'ajouter la prise en charge du protocole, et les tristes statistiques avec Caniuse deviendront plus gaies.

Source: habr.com