HTTP / 3 arrive QUIC, voici ce que vous devez savoir

HTTP / 3 est la prochaine génération du protocole HTTP. Il est alimenté par QUIC, qui remplace TCP au niveau de la couche de transport et réduit le nombre d’aller-retours qu'un client doit effectuer pour établir une connexion.

Qu'est-ce qui le rend meilleur?

Si vous ne pouvez pas distinguer l'acronyme «QUIC», HTTP / 3 est beaucoup plus rapide.

HTTP n'est qu'une partie du modèle OSI, qui alimente Internet tel que nous le connaissons. Chaque couche du modèle a un objectif différent, avec des API de haut niveau comme HTTP situées tout en haut (la couche d'application), jusqu'aux fils physiques et aux connexions qui se connectent aux routeurs:

Mais il y a un goulot d'étranglement dans ce modèle – et malgré le nouveau nom, la norme HTTP elle-même n'est pas le problème.

TCP (la couche transport) est le coupable ici; il a été conçu dans les années 70 et, en tant que tel, n’a pas été conçu pour gérer très bien la communication en temps réel. HTTP-sur-TCP a atteint sa limite. Google et le reste de l'espace technologique ont travaillé sur un remplacement de TCP.

En 2012, Google a créé SPDY, un protocole qui s'appuie sur TCP et résout de nombreux problèmes courants. SPDY lui-même est obsolète, mais certaines parties ont fait leur chemin dans HTTP / 2, qui est actuellement utilisé par 40% du Web.

QUIC est un nouveau standard, un peu comme SPDY, mais il est construit sur UDP plutôt que TCP. UDP est beaucoup plus rapide que TCP, mais il est généralement moins fiable car il n’a pas le même contrôle d’erreurs et la même prévention des pertes que TCP. Il est couramment utilisé dans les applications qui ne nécessitent pas que les paquets soient dans le exact bon ordre, mais attention à la latence (comme les appels vidéo en direct).

QUIC est toujours fiable, mais il implémente sa vérification d'erreurs et sa fiabilité en plus de UDP, de sorte qu'il tire le meilleur parti des deux protocoles. La première fois qu'un utilisateur se connecte à un site compatible QUIC, il le fera via TCP.

Le principal problème avec TCP que QUIC corrige est le blocage de tête de ligne. Une fois qu'une connexion est établie entre le serveur et le client, le serveur envoie des paquets de données au client. Si la connexion est mauvaise et qu'un paquet est perdu, le client retient tous les paquets reçus par la suite jusqu'à ce que le serveur retransmet le paquet perdu. HTTP / 2 résout quelque peu ce problème, en autorisant plusieurs transferts sur la même connexion TCP, mais il n'est pas parfait et peut en fait être plus lent que HTTP / 1 avec des connexions à forte perte.

QUIC résout ce problème et traite beaucoup mieux les connexions à perte élevée. Les premiers tests de Google ont montré des améliorations d'environ 15% dans les scénarios à latence élevée et jusqu'à 30% d'amélioration de la mise en mémoire tampon vidéo sur les connexions mobiles. Parce que QUIC réduit le nombre de poignées de main qui doivent être effectuées, il y aura des améliorations de la latence à tous les niveaux.

Est-ce difficile à mettre en œuvre?

Bien que QUIC soit un nouveau standard, il est basé sur UDP, qui est déjà pris en charge presque partout. Il ne nécessitera aucune nouvelle mise à 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 remplacer le protocole HTTP-over-TCP une fois qu'il est facilement disponible. Au moment de la rédaction de cet article, Chrome prend en charge QUIC, mais il est désactivé par défaut. Vous pouvez l'activer pour les tests en allant sur:

chrome://flags

et activer le drapeau «Protocole QUIC expérimental». Firefox ajoutera la prise en charge plus tard cet automne, et avec le passage d'Edge à Chromium, ils prendront également bientôt en charge la prise en charge.

Côté serveur, si vous utilisez CloudFlare comme CDN, vous pourrez activer l'option déjà dans votre tableau de bord, bien que vous n'ayez pas beaucoup de clients qui l'utilisent jusqu'à ce que les navigateurs mobiles l'utilisent par défaut. Fastly travaille activement sur le support. Si vous souhaitez l'activer sur votre serveur Web, vous devrez attendre un peu: la prise en charge anticipée de QUIC devrait arriver pendant le cycle de développement de nginx 1.17, mais la prise en charge d'Apache n'est encore nulle part en vue.

Une fois que nginx et Apache sont mis à jour pour le prendre en charge, ajouter QUIC à votre page Web ou application Web sera aussi simple que de mettre à jour votre serveur Web et d'activer l'option. Vous n'aurez pas à apporter de modifications à votre application ou à votre code, car tout est géré au niveau de l'infrastructure. Il n’est pas encore là, mais il arrive très bientôt, et vous voudrez certainement l’activer une fois qu’il sera pris en charge par défaut.