🥇HTTP sur UDP — utilisons le protocole QUIC à bon escient

QUIC (Quick UDP Internet Connections) est un protocole basé sur UDP qui prend en charge toutes les fonctionnalités de TCP, TLS et HTTP/2, tout en résolvant la plupart de leurs problèmes. Il est souvent qualifié de nouveau protocole ou de « protocole expérimental », mais il a depuis longtemps dépassé la phase d'expérimentation : son développement dure depuis plus de 7 ans. Au cours de cette période, le protocole n'est pas devenu un standard, mais il a tout de même gagné en popularité. Par exemple, QUIC est utilisé pour accélérer le trafic et réduire la latence dans les réseaux mobiles par des géants comme Google et Facebook, et l'IETF a déclaré son fork comme base pour le standard HTTP/3 (alors que HTTP/2 utilise seulement 44,8% des sites).

Concept

QUIC a été développé pour remplacer le TCP obsolète, qui était initialement conçu pour des réseaux filaires avec un faible pourcentage de perte. TCP livre les paquets dans un ordre déterminé, donc lorsqu'un paquet est perdu, toute la file d'attente se bloque (head-of-line blocking), ce qui impacte négativement la qualité et la stabilité de la connexion. Pour éviter des pertes massives, les réseaux mobiles utilisent de grands tampons, ce qui entraîne des surcharges et une réaction faussement négative du protocole (bufferbloat). De plus, TCP consacre beaucoup de temps à l'établissement de la connexion : les demandes SYN/ACK et TLS sont traitées séparément, nécessitant trois allers-retours au lieu d'un seul, comme le fait QUIC.

Puisque QUIC combine un remplacement du TCP et la mise en œuvre de TLS 1.3, toutes les connexions sont toujours chiffrées, et il n'est pas plus facile de déchiffrer ce trafic que s'il circulait via HTTPS. En outre, QUIC est mis en œuvre au niveau applicatif, car une substitution complète de la pile TCP prendrait une éternité..

Bien qu'il prenne en charge le multiplexage dans HTTP/2, le problème de head-of-line blocking subsiste à cause de la nécessité de livrer les paquets dans l'ordre. QUIC est mis en œuvre au-dessus de l'UDP, ce qui le rend exempt de blocages, et pour éviter que les paquets ne soient irrémédiablement perdus, ils sont numérotés et peuvent contenir des parties de « voisins », assurant ainsi une redondance. De plus, QUIC divise la file d'attente monolithique en plusieurs flux pour différents types de requêtes au sein d'une seule connexion. Ainsi, en cas de perte d'un paquet, les problèmes ne peuvent survenir que dans une seule file d'attente (par exemple, lors de la transmission d'un fichier spécifique) :

Utilisation

QUIC a été initialement développé à l'intérieur de Google et était en grande partie conçu pour un usage interne. En 2013, il a été transféré à l'IETF pour normalisation (ce qui est toujours en cours), et maintenant tout le monde peut participer au développement du protocole en proposant ce qui lui manque. Le groupe de travail de l'IETF organise chaque année des réunions au cours desquelles un nouveau standard est approuvé et où des innovations sont discutées. Cette implémentation de QUIC est considérée comme la principale et c'est sur cette base que la norme HTTP/3 est certifiée.

Actuellement, 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 mis en œuvre comme un transport entre l'application et le serveur, ce qui a été réalisé avec succès chez Uber :

Commentaire d'Uber sur l'implémentation de QUIC
Pour intégrer QUIC avec succès et améliorer les performances de l'application dans des conditions de mauvaise connexion, 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 Chromium Projects, qui contient la version originale de Google du protocole – gQUIC. Cette implémentation est également constamment améliorée pour suivre les dernières spécifications de l'IETF.
Nous avons d'abord intégré Cronet dans nos applications Android pour ajouter le support de QUIC. L'intégration a été effectuée de manière à minimiser au maximum 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 cadre de l'API OkHttp. En procédant ainsi, nous avons évité des modifications dans nos appels réseau (qui utilisent Retrofit) au niveau de l'API.
Tout comme pour les appareils Android, nous avons intégré Cronet dans les applications Uber sous iOS, en interceptant le trafic HTTP des API, en utilisant NSURLProtocol. Cette abstraction, fournie par iOS Foundation, 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 significatifs.

extrait de cette traduction article d'Uber

Sur le backend, ils capturent les connexions QUIC via Google Cloud lb, qui prend en charge le protocole depuis le milieu de 2018.

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

Nginx

Récemment, CloudFlare a essayé de croiser nginx (qui par défaut ne supporte pas HTTP/3) avec son outil Quiche. L’implémentation est disponible sous la forme d’un unique fichier .patch, accompagné d’un tutoriel 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 propres 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 de HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Activer QUIC et HTTP/3.
        listen 443 quic reuseport;

        # Activer HTTP/2 (optionnel).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Activer toutes les versions TLS (TLSv1.3 est nécessaire pour QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Le buffering de requêtes est actuellement non supporté pour HTTP/3.
        proxy_request_buffering off;

        # Ajouter l'en-tête Alt-Svc pour négocier HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

Dans les navigateurs classiques, il n'est pas encore possible de se connecter via HTTP/3, mais vous pouvez le prendre Chrome Canary et le lancer avec le drapeau --enable-quic, accéder à votre serveur ou, par exemple, au site quic.rocks et vérifier le type de connexion dans les Outils de développement :

Au lieu de HTTP/3, cela affiche http2+quic/99, mais c'est en réalité la même chose.

D'autres technologies

QUIC est également supporté par LiteSpeed qui se connectaient avec grand fracas à Facebook via HTTP/3 et le progressif Caddy. Apache ne supporte pas encore, mais le travail avance à grands pas.
Le 21 janvier, un brouillon de norme pour WebRTC a été mis à jour Récemment, Microsoft a ouvert
le code de son implémentation msquic , où toutes les fonctionnalités du standard IETF ne sont pas encore disponibles, mais c'est déjà un grand pas en avant.L’intérêt pour QUIC est instable mais en croissance, le travail sur sa normalisation se poursuit. De nouvelles implémentations du protocole apparaissent presque chaque mois, et chaque année, de plus en plus de développeurs réalisent que l'avenir appartient à QUIC. Il est même envisagé d'intégrer le protocole dans les prochaines versions de la pile TCP, ce qui signifie qu'un jour ou l'autre, tout Internet se déplacera vers des connexions plus stables et rapides.

Conclusion

Déjà maintenant, vous pouvez configurer l'interaction QUIC pour votre infrastructure ou même le fournir aux navigateurs — tous prévoient d’ajouter le support du protocole, et les tristes statistiques de caniuse deviendront plus joyeuses.