ADC

Protocole HTTP3 sur QUIC

HTTP/2 sur TCP est la norme préférée pour l’envoi de plusieurs flux de requêtes HTTP sur une seule connexion. Toutefois, dans le mécanisme de transport TCP, l’accès aux sites Web et aux applications Web présente certaines limitations et problèmes de latence. Lorsque vous multiplexez plusieurs demandes sur la même connexion, elles sont soumises à la fiabilité de la même connexion. Si le paquet d’une demande est perdu, toutes les autres demandes multiplexées sont retardées jusqu’à ce que le paquet perdu soit détecté et retransmis. Cela entraîne des retards de blocage de la tête de ligne et des problèmes de latence.

Pour les retards de connexion et de transport, HTTP/3 utilise QUIC au lieu du protocole TCP. Le QUIC est un protocole émergent qui utilise UDP au lieu de TCP comme transport de base. Dans HTTP overQuic, vous pouvez multiplexer plusieurs requêtes indépendantes sans dépendre d’une seule connexion TCP. QUIC met en œuvre une connexion fiable sur laquelle vous pouvez diffuser plusieurs requêtes HTTP en streaming. QUIC intègre également TLS en tant que composant intégré et non en tant que couche supplémentaire, comme dans HTTP/1.1 ou HTTP/2.

Avantage de l’utilisation du protocole HTTP/3

Voici quelques-uns des avantages importants de l’utilisation du protocole QUIC pour le transport de données HTTP/3 :

• Multiplexage de flux • Contrôle du débit au niveau du flux et de la connexion • Établissement de connexions à faible latence • Migration des connexions et résilience à la reliaison NAT • En-tête et charge utile authentifiés et chiffrés

Pile de transport dans les protocoles HTTP

L’illustration ci-dessous montre la pile de transport dans les protocoles HTTP/1.1, HTTP/2 et HTTP/3.

Pile de transport dans les protocoles HTTP

Comment fonctionne la gestion des connexions QUIC et HTTP/3 dans NetScaler

L’illustration suivante montre comment les connexions QUIC et HTTP/3 sont gérées dans une appliance NetScaler et comment les composants interagissent les uns avec les autres.

Fonctionnement de la gestion des connexions QUIC et HTTP/3

Étape 1 : Requête HTTP/3 côté client via le protocole QUIC vers l’appliance NetScaler. Étape 2 : Requête transmise par NetScaler AS HTTP/1.1 ou HTTP/2 en fonction du support du serveur principal. Étape 3 : Réponse via HTTP/2 ou HTTP/1.1 du serveur principal à NetScaler. Étape 4 : ADC transmet la réponse en tant que réponse HTTP/3 au client.

Fonctionnement du protocole HTTP/3

Dans HTTP/3, lorsqu’un client sait qu’un serveur HTTP/3 existe sur un point de terminaison donné, il ouvre une connexion QUIC. Le protocole QUIC permet le multiplexage et le contrôle du flux. Dans chaque flux, l’unité de base de la communication HTTP/3 est une trame. Chaque type de cadre a un objectif différent. Par exemple, les blocs HEADERS et DATA constituent la base des requêtes et des réponses HTTP.

Le multiplexage des requêtes est effectué à l’aide de l’abstraction de flux QUIC. Chaque paire demande-réponse consomme un flux QUIC unique. Les flux sont indépendants les uns des autres, de sorte qu’un flux bloqué ou subit une perte de paquets n’empêche pas la progression sur d’autres flux. Server Push est un mode d’interaction introduit dans HTTP/2 qui permet à un serveur de transmettre un échange demande-réponse à un client en prévision de la demande indiquée par le client. Cela permet d’opposer l’utilisation du réseau à un gain potentiel de latence. Plusieurs trames HTTP/3 sont utilisées pour gérer le push du serveur, telles que PUSH_PROMISE, MAX_PUSH_ID et CANCEL_PUSH. Comme dans HTTP/2, les champs de demande et de réponse sont compressés pour transmission. Parce que HPACK repose sur la transmission dans l’ordre de sections de champs compressés (garantie non fournie par QUIC), HTTP/3 remplace HPACK par QPACK. QPACK utilise des flux unidirectionnels distincts pour modifier et suivre l’état de la table des champs, tandis que les sections de champs codées font référence à l’état de la table sans la modifier.

Fonctionnement du protocole HTTP/3

Protocole HTTP3 sur QUIC