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'allers-retours qu'un client doit effectuer pour établir une connexion.
Qu'est-ce qui le rend meilleur ?
Si 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 sert un objectif différent, avec des API de haut niveau comme HTTP au sommet (la couche d'application), jusqu'aux fils physiques et aux connexions qui se connectent aux routeurs :
Mais il y a’sa goulot d'étranglement dans ce modèle—et malgré le nouveau nom, la norme HTTP elle-même n'est pas’ 8217;t 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-over-TCP a atteint sa limite. Google et le reste de l'espace technologique ont travaillé sur un remplacement de TCP.
Publicité
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 été intégrées à 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 sur TCP. UDP est beaucoup plus rapide que TCP, mais est généralement moins fiable car il n'a pas la même vérification des erreurs et la même prévention des pertes que TCP. Il est couramment utilisé dans les applications qui n'exigent pas que les paquets soient dans le bon ordre, mais qui se soucient de la latence (comme les appels vidéo en direct).
QUIC est toujours fiable, mais il implémente sa vérification d'erreur et sa fiabilité en plus d'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 fait via TCP.
Le principal problème avec TCP que QUIC résout est le blocage en tête de ligne. Une fois la connexion é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 à pertes élevées.
QUIC résout ce problème et gère beaucoup mieux les connexions à forte perte. 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 faites, il y aura des améliorations de la latence à tous les niveaux.
Est-ce difficile à mettre en œuvre ?
Bien que QUIC soit une nouvelle norme, il repose 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
Publicité
HTTP-over-QUIC devrait être un remplacement instantané pour HTTP-over-TCP une fois qu'il est facilement disponible . Au moment de la rédaction, Chrome prend en charge QUIC, mais il est désactivé par défaut. Vous pouvez l'activer pour le test en allant sur :
chrome://flags
et en activant le “Protocole expérimental QUIC” drapeau. Firefox ajoutera le support plus tard cet automne, et avec le passage d'Edge à Chromium, ils prendront également le support bientôt.
Du côté du serveur, si vous utilisez CloudFlare comme CDN , vous pourrez déjà activer l'option dans votre tableau de bord, même si de nombreux clients ne l'utiliseront pas tant que les navigateurs mobiles ne l'auront pas activé par défaut. Fastly travaille activement sur le support. Cependant, si vous souhaitez l'activer sur votre serveur Web, vous devrez attendre un peu. La prise en charge précoce de QUIC devrait arriver pendant le cycle de développement de nginx 1.17, mais la prise en charge d'Apache n'est pas encore en vue.
Une fois que nginx et Apache sont mis à jour pour le prendre en charge, l'ajout de 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. Ce 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.