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 vous ne pouvez pas dire à partir de l’acronyme «QUIC», HTTP / 3 est beaucoup plus rapide.
HTTP n’est qu’une partie de la 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 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 de transport) est ici le coupable; 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 repose sur TCP et corrige de nombreux problèmes courants. SPDY lui-même est obsolète, mais certaines de ses parties ont été introduites 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 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 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 des 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 ce n’est pas parfait et peut en fait être plus lent que HTTP / 1 avec des connexions à perte élevée.
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 construit 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 être un remplacement de 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 le test en accédant à:
chrome://flags
et activer le drapeau «Protocole QUIC expérimental». Firefox ajoutera une prise en charge plus tard cet automne, et avec le passage d’Edge à Chromium, ils en bénéficieront bientôt également.
Du côté du serveur, si vous utilisez CloudFlare comme CDN, vous pourrez activer l’option déjà dans votre tableau de bord, même si vous n’aurez pas beaucoup de clients qui l’utilisent réellement jusqu’à ce que les navigateurs mobiles l’utilisent par défaut. Est rapidement travaille activement sur le support. Cependant, si vous souhaitez l’activer sur votre serveur Web, vous devrez attendre un peu – le support rapide de QUIC devrait arriver pendant la Cycle de développement nginx 1.17, mais la prise en charge d’Apache est encore nulle part en vue.
Une fois que nginx et Apache sont mis à jour pour le prendre en charge, l’ajout de QUIC à votre page Web ou à votre 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.