Shutterstock / Robert Avgustin
HTTP/3 représente la nouvelle évolution du protocole HTTP. Il s’appuie sur QUIC, qui remplace TCP au niveau de la couche transport et réduit de manière significative le nombre d’échanges nécessaires pour établir une connexion.
Pourquoi est-ce une amélioration ?
Comme le suggère son nom, QUIC permet à HTTP/3 d’être beaucoup plus rapide.
Le protocole HTTP n’est qu’un élément du modèle OSI, qui constitue la base d’Internet tel que nous le connaissons. Chaque couche de ce modèle remplit une fonction spécifique, allant des API de haut niveau comme HTTP (situées au sommet, dans la couche application) jusqu’aux câbles physiques et aux connexions qui relient les routeurs :
Cependant, ce modèle présente un goulot d’étranglement, et malgré son nouveau nom, la norme HTTP elle-même n’est pas en cause.
Le véritable responsable est TCP (la couche transport). Conçu dans les années 70, il n’était pas prévu pour gérer efficacement la communication en temps réel. HTTP sur TCP a atteint ses limites. C’est pourquoi Google et d’autres acteurs du secteur technologique ont travaillé sur un remplacement de TCP.
En 2012, Google a introduit SPDY, un protocole basé sur TCP qui corrigeait bon nombre de problèmes existants. SPDY est maintenant obsolète, mais certains de ses principes ont été intégrés à HTTP/2, qui est actuellement utilisé par environ 40 % des sites web.
QUIC est une nouvelle norme, semblable à SPDY, mais construite sur UDP plutôt que sur TCP. UDP est beaucoup plus rapide que TCP, mais il est généralement considéré comme moins fiable, car il ne dispose pas des mêmes mécanismes de vérification des erreurs et de prévention des pertes que TCP. Il est souvent utilisé dans les applications qui ne nécessitent pas que les paquets arrivent dans un ordre précis, mais qui sont sensibles à la latence (comme les appels vidéo en direct).
QUIC assure une certaine fiabilité, mais en implémentant ses propres mécanismes de vérification des erreurs et de fiabilité au-dessus d’UDP, ce qui lui permet de tirer le meilleur parti des deux protocoles. La première fois qu’un utilisateur se connecte à un site compatible QUIC, la connexion se fait par TCP.
Le principal problème de TCP que QUIC corrige est le blocage de tête de ligne. Lorsqu’une connexion est établie entre un serveur et un client, le serveur envoie des paquets de données au client. Si la connexion est instable et qu’un paquet est perdu, le client met en attente tous les paquets reçus ultérieurement jusqu’à ce que le serveur renvoie le paquet perdu. HTTP/2 atténue partiellement ce problème en autorisant plusieurs transferts sur la même connexion TCP, mais ce n’est pas parfait, et peut même s’avérer plus lent que HTTP/1 dans des conditions de pertes de paquets élevées.
QUIC résout ce problème et gère beaucoup mieux les connexions avec des pertes élevées. Les premiers tests de Google ont montré des améliorations de l’ordre de 15 % dans les scénarios de forte latence et jusqu’à 30 % d’amélioration de la mise en mémoire tampon vidéo sur les connexions mobiles. Grâce à la réduction du nombre d’échanges nécessaires, QUIC apporte des améliorations de la latence à tous les niveaux.
Est-ce compliqué à mettre en place ?
Bien que QUIC soit une nouvelle norme, il est basé sur UDP, qui est déjà pris en charge presque partout. Il ne nécessite donc pas de mises à jour du noyau, ce qui peut être problématique pour les serveurs. QUIC devrait fonctionner immédiatement sur tout système prenant en charge UDP.
HTTP-over-QUIC devrait à terme remplacer HTTP-over-TCP une fois qu’il sera largement disponible. À l’heure où j’écris ces lignes, Chrome prend en charge QUIC, mais cette option est désactivée par défaut. Vous pouvez l’activer pour le tester en vous rendant sur :
chrome://flags
et en activant l’option « Protocole QUIC expérimental ». Firefox ajoutera la prise en charge plus tard cet automne, et avec le passage d’Edge à Chromium, ils en bénéficieront également rapidement.
Côté serveur, si vous utilisez CloudFlare comme CDN, vous pouvez déjà activer cette option dans votre tableau de bord, même si vous n’aurez pas beaucoup de clients qui l’utilisent réellement tant que les navigateurs mobiles ne l’auront pas activé par défaut. Fastly travaille activement sur sa prise en charge. Toutefois, si vous souhaitez l’activer sur votre propre serveur web, il faudra patienter un peu : la prise en charge de QUIC devrait arriver pendant le cycle de développement nginx 1.17, mais la prise en charge d’Apache n’est pas encore d’actualité.
Une fois que nginx et Apache seront mis à jour pour le prendre en charge, l’ajout de QUIC à votre site web ou à votre application web sera aussi simple que de mettre à jour votre serveur web et d’activer l’option. Vous n’aurez pas besoin de modifier votre application ou votre code, car tout est géré au niveau de l’infrastructure. Ce n’est pas encore une réalité, mais cela ne saurait tarder, et il sera conseillé de l’activer dès qu’il sera pris en charge par défaut.