HTTP / 3 est la prochaine génération du protocole HTTP. Il est alimenté par QUIC, qui remplace TCP au niveau de la couche transport et réduit le nombre d'allers-retours qu'un client doit effectuer pour déterminer une connexion.
Qu'est-ce qui le rend meilleur?
Si vous ne pouvez pas dire par l'acronyme “Si vous ne pouvez pas dire par l'acronyme”, HTTP / 3 c'est beaucoup plus rapide.
HTTP n'est qu'une partie de 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 en haut (la couche applicative), jusqu'aux câbles 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 le coupable ici; a été conçu dans les années 70 et, En tant que tel, il 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.
Au 2012, Google a créé SPDY, un protocole basé sur TCP et résolvant de nombreux problèmes courants. SPDY lui-même est obsolète, mais certaines parties ont fait leur chemin dans HTTP / 2, qu'en ce moment utilise 40% du net.
QUIC est une nouvelle norme, très similaire à SPDY, mais il est construit sur UDP au lieu de TCP. UDP est beaucoup plus rapide que TCP, mais en général, il est 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 packages soient dans le exactement bon ordre, mais ils s'inquiètent de la latence (comme les appels vidéo en direct).
QUIC reste fiable, mais implémente sa vérification d'erreur et sa fiabilité en même temps qu'UDP, vous obtenez ainsi le meilleur des deux protocoles. La première fois qu'un utilisateur se connecte à un site compatible QUIC, le fera via TCP.
Le principal problème avec TCP que QUIC résout est le blocage des en-têtes. 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 conserve tous les paquets reçus après cela jusqu'à ce que le serveur retransmet le paquet perdu. HTTP / 2 résoudre ce problème d'une manière ou d'une autre, 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 à haute perte.
QUIC résout ce problème et gère beaucoup mieux les connexions à pertes élevées. Les premiers tests de Google ont montré des améliorations d'environ 15% dans des scénarios à latence élevée et jusqu'à 30% améliorations 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-il difficile à mettre en œuvre?
Bien que QUIC soit une nouvelle norme, est basé sur UDP, qui est déjà compatible presque partout. Ne nécessitera pas de nouvelles 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 être un remplacement direct pour HTTP-over-TCP une fois qu'il est disponible. Au moment d'écrire ce post, Chrome prend en charge QUIC, mais il est désactivé par défaut. Vous pouvez l'activer pour le test en allant sur:
chrome://drapeaux
Si vous ne pouvez pas dire par l'acronyme “Si vous ne pouvez pas dire par l'acronyme”. Firefox ajoutera le support plus tard cet automne, et avec Edge passant à Chromium, ils recevront également un soutien bientôt.
Côté serveur, si vous utilisez CloudFlare comme CDN, vous pouvez déjà activer l'option dans votre panneau, même si vous n'aurez pas beaucoup de clients qui l'utiliseront tant que les navigateurs mobiles ne l'auront pas activé par défaut. est rapidement travaillant activement à l'appui. Malgré cela, si vous souhaitez l'activer sur votre serveur web, va falloir attendre un peu; un support précoce pour QUIC devrait arriver tout au long du cycle de développement nginx 1.17, mais le support Apache n'est pas encore 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 aucune modification à apporter à votre application ou à votre code, puisque tout est géré au niveau de l'infrastructure. Pas encore ici, mais ça viendra très bientôt, et vous voudrez certainement l'activer une fois qu'il sera pris en charge par défaut.
