HTTP/3, pour vous servir (plus vite)

HTTP/3, pour vous servir (plus vite)

"Tous les efforts d’un développeur web pour optimiser son code n’auront d’effet que sur une partie seulement des étapes nécessaires à la réception du contenu par l’internaute : l’envoi de la réponse HTTP. Avant cela, le serveur et le client ont déjà entamé tout un dialogue, qui peut être bien plus long que l’envoi du contenu lui-même !

Plutôt frustrant, non ? C’est là qu’intervient la nouvelle version du protocole http amorcée par Google."

 

HTTP , TCP et la politesse

Avec HTTP/1, pour qu’un serveur réponde à un client, il fallait qu’une connexion TCP soit initialisée. Pour cela, le client envoie un segment SYN au serveur. Qui lui répond par un segment SYN-ACK. Qui est suivi d’un ACK. Par la suite, il faut bien souvent sécuriser la connexion : c’est là qu’intervient TLS. 5 échanges de plus, deux pour dire "bonjour" ; deux pour dire "au revoir". Et un pour envoyer la clé cryptée. Ce qui se résume à ça :

Version avec TLS

    

Version sans TLS ( et alcoolisée)

 

HTTP/2 et l’envoi en masse

HTTP/2 s’appuie sur les mêmes protocoles. Mais à la différence de son prédécesseur, il est capable de supporter le multiplexage. Il permet, en une seule connexion TCP, de traiter plusieurs trames, qui remplaceront autant de requêtes. Autre avantage : en parallèle, un serveur push peut envoyer des ressources importantes directement au navigateur.

En somme, cela va plus vite avec HTTP2. Mais davantage de données transitent en même temps… Ce qui peut induire des temps de latence importants pour les internautes ne bénéficiant pas d’une connexion à très haut débit.

Le protocole TCP a aussi comme inconvénient d’être fortement lié au point d’accès. Si le point d’accès à internet change, le dialogue est interrompu et la connexion se réinitialise. Comme par exemple, lorsque vous vous promenez avec votre portable (relié au réseau 4G), que vous rentrez chez vous et que votre appareil se connecte automatiquement à votre Wifi.

 

HTTP/3 et l’éducation à la sécurité d’UDP

Pour contourner les obstacles induits par TCP, HTTP/3 s’appuie sur son petit frère diabolique : UDP. UDP se passe des formules de politesse, et ne fait pas attention aux paquets qu’il perd. L’important pour lui, c’est que le message arrive rapidement. Peu importe que les paquets soient dans le désordre, ou même… manquants. Il est utilisé pour, par exemple, les transmissions audio avec Skype : s’il manque des mots dans les phrases de votre mamie, c’est parfois seulement parce certains paquets ne sont pas arrivés à destination.

Mais alors, pourquoi le futur serait-il dans un protocole aussi tête en l’air que votre petit cousin ?

C’est que dans HTTP/3, un nouveau protocole, de niveau 4, s’appuie sur UDP : QUIC (Quick UDP Internet Connections). Il va jouer les grands frères et permettre de réintroduire les notions de gestion de l’ordre des paquets et de leur intégrité. Si les différents paquets sont arrivés dans le désordre ou si l’un d’eux s’est perdu, c’est donc cette surcouche qui va faire un rappel, ou une réorganisation.

Il garde également le principe du multiplexage introduit avec HTTP/2 : plusieurs segments peuvent toujours être envoyés dans la même connexion. Les différentes composants d’une page, s’ils ne sont pas interdépendants, peuvent aussi être rendus l’un après l’autre. Même en pleine campagne, vous pourrez au moins lire une partie d’une page, en attendant que le reste arrive.

Un envoi deux en un, avec message et données de sécurisation

Dans un contexte sécurisé, la première fois que le client se connecte à un serveur avec le protocole UDP + QUIC, le serveur va lui renvoyer les certificats et les clés nécessaires. Dans les échanges suivants, un token sera envoyé par le client en même temps que la requête. Le TLS a été gardé en tant que protocole de cryptage.

 
   

 

Si les paramètres de connexion ont changé en cours de route, un nouvel échange de token sera réalisé.

Une autre nouveauté est l’introduction d’une authentification des entêtes non cryptées par le serveur destinataire, à l’arrivée des paquets. En TCP, ces entêtes étaient envoyées en texte brut et étaient vulnérable à une attaque connue sous le nom de « l’homme du milieu ». Elle consiste à s’introduire dans les échanges entre le client et le destinataire.

Déjà des millions de testeurs !

En choisissant UDP, Google a évité de devoir faire introduire un nouveau protocole dans les systèmes. UDP est aussi connu des pare-feu, généralement ouverts à ces connections avec le port 443. Il n’y a donc rien à paramétrer de ce côté-là pour bénéficier du nouvel HTTP… et la firme s’est également ainsi assurée d’avoir à sa disposition des légions de testeur.

Chrome intègre en effet HTTP3 par défaut, pour les requêtes sur les serveurs Google, qui l’utilisent depuis… 2013. Vous utilisez donc peut être déjà HTTP3, sans le savoir. Si jamais vous souhaitez réellement savoir à quel moment vous déclenchez une requête HTTP2/QUIC, il existe même une extension Chrome pour cela : HTTP2 and SPDY indicator. Elle intègre un bouton avec un éclair qui se colore en bleu lorsque que le protocole est utilisé.

Pour ce qui est de l’intégration à votre propre site web, c’est une autre histoire :  pour le moment, seuls trois serveurs web supportent HTTP3. Caddy et H2O servers sont en open source mais encore en phase expérimentale. S’il vous prend l’envie d’investir, LiteSpeed, de licence propriétaire, met bien avant la nouveauté : selon leur site web, 97% des sites qui utilisent QUIC le font avec LiteSpeed.

À priori, vous êtes donc encore bien loin de pouvoir fournir votre blog avec HTTP/3… Mais cela ne saurait tarder. Le but de Google est bien sûr de faire de HTTP2/QUIC le nouveau standard du web.

 

Emmanuelle A.

Sources :

  • Conférence de Benoît Jacquemont, SymfonyLive 2019
  • Chronium Blog
  • 01Net
  • TechCrunch

 

 

 

 

 

Ajouter un commentaire