18 mai 2022

Les avantages de l'utilisation de TLS 1.3 et 0-RTT sur des serveurs Web tels que NGINX

Voyons comment améliorer la vitesse et les performances de notre serveur web NGINX grâce à TLS 1.3 et 0-RTT

Bannière TLS 1.3 et HTTPS
Print Friendly, PDF & Email

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 bref, nous avons rendu populaires et accessibles les services d'hébergement performants, alliant recherche et développement. En regardant autour de nous et en pesant les sites les plus célèbres du panorama italien, nous avons pu vérifier que presque tous les sites Web n'adoptent pas TLS 1.3 et surtout le 0-RTT qui, dans notre cas, permettait, par exemple, de récupérer plus de 150 ms de TTFB total, sur une dépense totale d'environ 500 ms, améliorant la vitesse d'environ 25 %.

Dans cet article, j'expliquerai les avantages de l'utilisation de TLS 1.3 et 0-RTT dans des serveurs Web tels que NGINX, le serveur Web le plus populaire dont nous avons tant discuté sur 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 suivant est dérivé d'un récent test de latence du réseau Cloudflare utilisant le projet RIPE Atlas. Dans l'expérience, des centaines de sondes du monde entier ont envoyé un seul message "Ping" à Cloudflare et a mesuré le temps qu'il a fallu pour obtenir une réponse en réponse. Ce temps est une bonne approximation du temps qu'il faut aux données pour faire l'aller-retour de la sonde au serveur et retour, le soi-disant latence aller-retour.

La latence est généralement mesurée en millisecondes ou en millièmes de seconde. Un millième de seconde peut ne pas sembler long, mais ils peuvent s'additionner rapidement. EST généralement accepté que le seuil au-delà duquel l'humain ne perçoit plus quelque chose comme instantané est de 100 ms. Tout ce qui dépasse 100 ms semblera rapide, mais pas immédiat. Par exemple, le temps de réaction d'Usain Bolt hors des blocs de départ dans le sprint de XNUMX m est d'environ 155 ms, un bon point de référence pour réfléchir à la latence. Nous utilisons 155 ms, comme une durée rapide mais perceptible par l'homme, comme unité de mesure du 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).

Prise de contact TLS

0-RTT ou Reprise de la session (Zero Round Trip Time)

De plus, TLS 1.3 prend en charge le reprise de la séance, qui accélère la création de la connexion en éliminant la surcharge liée à la répétition de la poignée de main TLS lorsqu'un client revient sur un site précédemment visité. Cela s'appelle aussi 0 ‑ RTT reset (zéro temps aller-retour), car aucun message d'établissement de liaison ne doit aller et venir entre le client et le serveur pour la reprise de la session. La reprise de session est mise en œuvre en créant un secret partagé pendant la session d'origine et en le stockant dans un billet de séance. Lorsque le client revient, il présente le ticket de session avec sa demande, qui est chiffrée avec le secret partagé trouvé dans le ticket.

0-RTT NGINX

En bref, Zero Round Trip Time Resumption ou 0-RTT optimise les performances pour les clients qui reprennent une connexion à votre site.

Techniquement, dans la terminologie d'Internet et des réseaux, on se produit récupération lorsqu'un client réutilise des informations connues de la poignée de main d'un serveur précédemment visité.

Confus? Pensez-y de cette façon (à titre d'exemple uniquement): disons que vous vous rendez pour la première fois dans un nouvel endroit et qu'il vous faut 15 minutes pour vous y rendre (5 minutes de configuration de la navigation + 10 minutes de trajet). Désormais, lorsque vous reviendrez au même endroit, vous gagnerez 5 minutes car vous connaissez déjà le chemin et vous n'aurez donc pas besoin de navigation. L'idée de la récupération est similaire.

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.

 

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Écrivez-nous

Discutez directement avec notre support technique.

0256569681

Appelez-nous immédiatement pendant les heures de bureau de 9h30 à 19h30

Recevoir de l'aide

Ouvrez un ticket directement dans l'espace support.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

Communiqué de presse : Notre entreprise est 100 % italienne depuis juin En savoir plus
+ +

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
haut