Table des matières de l'article :
Enfin, en 2022, il semble désormais établi qu'il est devenu plutôt facile de mettre en ligne un projet web qui peut fonctionner décemment et apporter satisfaction et profits.
Cependant, il faut prendre en compte que nous sommes toujours en concurrence féroce dans toutes les facettes qui peuvent contribuer à décréter le succès de notre projet web.
Malheureusement, il n'y a pas de luxe à pouvoir bien faire les choses, ou bien, il faut toujours essayer de faire les choses au mieux de manière optimale et maniaque pour pouvoir garantir des résultats et des avantages sur la concurrence.
Avoir un site lent ou non indexé devient juste un coût inutile qui ne vous donnera jamais satisfaction professionnelle et économique. C'est pourquoi vous devez toujours et uniquement vous entourer de professionnels estimés et compétents dans leur domaine et dans le cas de l'hébergement et de la performance Web, vous pouvez compter sur nous.
Parmi les nombreux aspects fondamentaux tels que le développement, le SEO, le Copy, l'un des aspects à ne pas négliger est en effet celui de la rapidité et de la réactivité du site aussi bien pour les moteurs de recherche comme Google que pour l'utilisateur. Nous avons beaucoup écrit à ce sujet, en concevant des services spécifiques pour les utilisateurs qui n'aiment pas faire de compromis sur les performances, sans avoir à dépenser des sommes considérables de l'ordre de milliers d'euros par mois.
En résumé, nous avons rendu les services d'hébergement haute performance populaires et accessibles en combinant recherche et développement. En analysant les sites web les plus populaires en Italie, nous avons constaté que la quasi-totalité d'entre eux n'utilisent pas TLS 1.3, et notamment le protocole 0-RTT. Dans notre cas, cela nous a permis de gagner plus de 150 ms sur le TTFB global, pour un coût total d'environ 500 ms, soit une amélioration de la vitesse d'environ 25 %.
Dans cet article, j'expliquerai les avantages de l'utilisation de TLS 1.3 et 0-RTT dans les serveurs web comme NGINX, le serveur web le plus populaire que nous avons longuement abordé dans cet article.
Transport Layer Security (TLS) est un protocole cryptographique utilisé pour sécuriser les communications entre les clients et les serveurs sur Internet ou d'autres réseaux. Assure la protection de la confidentialité et de l'intégrité des données échangées sur des réseaux non sécurisés tels qu'Internet. Il permet également aux applications client / serveur de s'authentifier mutuellement, permet aux utilisateurs de vérifier s'ils sont connectés au serveur prévu et fournit éventuellement une authentification mutuelle (le serveur prouve son identité au client). La dernière version de TLS au moment de la rédaction est la 1.3.
Le coût de la latence
Un élément important des performances Web est la latence de transmission. En termes simples, la latence de transmission est le temps nécessaire pour qu'un message passe d'une partie à une autre sur un réseau. Une latence plus faible signifie des pages Web plus rapides et des API plus réactives ; en matière de réactivité, chaque milliseconde compte.
Le diagramme ci-dessous provient d'un test récent de latence réseau réalisé par Cloudflare à l'aide du projet RIPE Atlas. Lors de cette expérience, des centaines de sondes réparties dans le monde entier ont envoyé un unique message « ping » à Cloudflare, et le temps de réponse a été mesuré. Ce temps constitue une bonne approximation du temps nécessaire aux données pour effectuer un aller-retour entre la sonde et le serveur, appelé latence aller-retour.
La latence se mesure généralement en millisecondes ou en millièmes de seconde. Un millième de seconde peut paraître infime, mais cela peut vite devenir significatif. On considère généralement que le seuil au-delà duquel l'être humain ne perçoit plus l'instantanéité est de 100 ms. Tout intervalle supérieur à 100 ms paraîtra rapide, mais ne sera pas instantané. Par exemple, le temps de réaction d'Usain Bolt au départ du 100 mètres est d'environ 155 ms , un bon point de repère pour appréhender la latence. Nous utilisons 155 ms, un intervalle de temps rapide mais perceptible par l'être humain, comme unité de temps.
La latence aller-retour fait une grande différence pour HTTPS. Lors de l'établissement d'une connexion sécurisée à un serveur, il existe une étape de configuration supplémentaire qui peut prendre jusqu'à trois messages pour effectuer l'aller-retour entre le client et le serveur avant même que la première demande puisse être envoyée. Pour un visiteur à 250 ms, cela peut entraîner un délai atroce d'une seconde (1000 ms) avant qu'un site ne commence à se charger. Pendant ce temps Usain Bolt a couru 10 mètres et vous attendez toujours une page web. TLS 1.3 et 0-RTT ne peuvent pas réduire la latence aller-retour d'une transmission, mais ils peuvent réduire le nombre d'allers-retours nécessaires pour établir une connexion HTTPS.
HTTPS aller-retour
Pour qu'un navigateur télécharge une page Web via HTTPS, il existe une configuration qui se déroule en arrière-plan. Voici les 4 étapes qui doivent se produire la première fois que votre navigateur tente d'accéder à un site.
Étape 1 : Recherche DNS
Votre navigateur doit convertir le nom d'hôte du site Web (par exemple, blog.cloudflare.com) en une adresse IP Internet (telle que 2400 : cb00 : 2048 : 1 :: 6813 : c166 ou 104.19.193.102) avant de pouvoir s'y connecter. Les résolveurs DNS gérés par votre FAI mettent généralement en cache l'adresse IP des domaines populaires, et la latence de votre FAI est assez faible ; par conséquent, cette étape prend souvent un temps négligeable.
Phase 2 : Prise de contact TCP (1 aller-retour)
L'étape suivante consiste à établir une connexion TCP au serveur. Cette phase consiste en ce que le client envoie un paquet SYN au serveur et le serveur répond avec un paquet ACK. Les détails importent moins que le fait que cela nécessite que les données soient envoyées du client au serveur et vice versa. Cela nécessite un aller-retour.
Étape 3 : Poignée de main TLS (2 allers-retours)
À ce stade, le client et le serveur échangent du matériel de clé cryptographique et établissent une connexion chiffrée. Pour TLS 1.2 et versions antérieures, deux allers-retours sont nécessaires.
Étape 4 : HTTP (1 retour)
Une fois la connexion TLS établie, votre navigateur peut envoyer une requête HTTP chiffrée en l'utilisant. Il peut s'agir d'une requête GET pour une URL spécifique telle que https://managedserver.it, par exemple. Le serveur répondra par une réponse HTTP contenant le code HTML de la page Web et le navigateur commencera à afficher la page.
En supposant que le DNS est instantané, il reste 4 allers-retours avant que le navigateur puisse commencer à afficher la page. Si vous visitez un site auquel vous vous êtes récemment connecté, la phase de prise de contact TLS peut être réduite de deux allers-retours à un avec la reprise de la session TLS.
Cela laisse les temps d'attente minimum suivants :
- Nouvelle connexion : 4 RTT + DNS
- Connexion reprise : 3 RTT + DNS
Comment TLS 1.3 et 0-RTT améliorent-ils les temps de connexion ?
L'un des plus grands avantages de TLS 1.3 par rapport aux versions précédentes est qu'il ne nécessite qu'un aller-retour pour établir la connexion, reprise ou non. Cela fournit une vitesse significative pour les nouvelles connexions, mais aucune pour les connexions reprises. Nos mesures montrent qu'environ 40 % des connexions HTTPS sont rétablies (via l'identifiant de session ou le ticket de session). Avec 0-RTT, un aller-retour peut être éliminé pour la plupart de ces 40 %.
Comment fonctionne TLS ?
Pour établir une connexion sécurisée entre deux parties - généralement un navigateur (client) et un serveur Web - une partie doit générer une clé privée (qu'elle seule connaît) et un certificat de clé publique qui contient les deux clés ainsi que des informations sur son identité.
TLS établit un échange de clés appelé Handshake (handshake) en plusieurs étapes rapides qui nécessitent cependant un transfert de données et évidemment une dépense de temps très courte (150/250 ms).
Il est donc évident qu'en pouvant gagner du temps dans la négociation des clés, il est possible d'améliorer la vitesse de navigation et ainsi d'obtenir de meilleures performances que l'on peut déjà apprécier même à l'œil nu.
Qu'est-ce que TLS 1.3 ?
TLS 1.3 est la dernière version du protocole Transport Layer Security (TLS). TLS 1.3 a été officiellement publié en août 2018 sous le nom de RFC 8446, remplaçant TLS 1.2, publié en 2008. La principale raison de la mise à jour était d'améliorer la sécurité et la confidentialité des communications Internet. Ces améliorations incluent :
Sécurité améliorée : TLS 1.3 utilise une nouvelle suite cryptographique basée sur l'échange de clés à courbe elliptique Diffie-Hellman (ECDHE) et l'accord de clé HMQV avec secret persistant (FS). Il utilise également le cryptage authentifié des données (AEAD), qui garantit la protection de la confidentialité et de l'intégrité, tout en permettant à toutes les parties d'une connexion d'être authentifiées.
Performances améliorées : l'utilisation de groupes Diffie-Hellman statiques et de groupes de courbes elliptiques (ECC) permet une prise de contact plus rapide que les versions précédentes de TLS. De plus, l'utilisation de données 0-RTT permet des réponses plus rapides des serveurs Web sans compromettre la sécurité ou la confidentialité, car un attaquant n'a pas assez de temps pour exploiter les vulnérabilités avant que les réponses ne soient envoyées aux clients.
Le transport de clé RSA est remarquable dans la liste des suppressions. Ce mode était principalement utilisé car il était plus rapide que Diffie‑Hellman, qui nécessitait un aller-retour supplémentaire pour établir la connexion avec Perfect Forward Secrecy (PFS). Avec TLS 1.3, l'aller-retour supplémentaire n'est plus nécessaire. Avec moins d'options de configuration, il y a moins d'informations à échanger et la poignée de main Diffie‑Hellman ne nécessite qu'un seul aller-retour (le schéma montre également un GETdemande après poignée de main).
0-RTT ou Reprise de la session (Zero Round Trip Time)
De plus, TLS 1.3 prend en charge la reprise de session , ce qui accélère l'établissement de la connexion en éliminant la surcharge liée à la répétition de la négociation TLS lorsqu'un client revient sur un site précédemment visité. On parle également de reprise 0-RTT (temps d'aller-retour nul) car aucun message de négociation n'est nécessaire entre le client et le serveur pour la session reprise. La reprise de session est mise en œuvre en créant un secret partagé lors de la session initiale et en le stockant dans un ticket de session. Lorsque le client revient sur le site, il présente le ticket de session avec sa requête, chiffrée à l'aide du secret partagé contenu dans le ticket.
En bref, Zero Round Trip Time Resumption ou 0-RTT optimise les performances pour les clients qui reprennent une connexion à votre site.
Techniquement parlant, dans la terminologie Internet et réseau, un redémarrage se produit lorsqu'un client réutilise des informations issues de l'établissement d'une connexion avec un serveur précédemment visité.
Vous êtes perdu ? Prenons un exemple (à titre d'illustration) : imaginez que vous vous rendez pour la première fois à un nouvel endroit et que le trajet dure 15 minutes (5 minutes de configuration du GPS + 10 minutes de trajet). La prochaine fois que vous y retournerez, vous gagnerez 5 minutes car vous connaîtrez déjà le chemin et n'aurez donc pas besoin de GPS. Le principe est similaire pour la reprise d'un trajet.
conclusion
TLS 1.3 est un grand pas en avant en matière de performances et de sécurité Web. En combinant TLS 1.3 avec 0-RTT, les améliorations de performances sont encore plus spectaculaires. Combinez cela avec HTTP / 2 et le Web crypté n'a jamais été aussi rapide, en particulier sur les réseaux mobiles. N'hésitez pas à nous consulter sans engagement pour connaître une fois pour toutes les problèmes de votre site internet que vous ne connaissez pas encore.
