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

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-RTTNGINX

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.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

AVIS DE NON-RESPONSABILITÉ, Mentions légales et droits d'auteur. Red Hat, Inc. détient les droits sur Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale de la AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la Fondation FreeBSD ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt ; Oracle Corporation détient les droits sur Oracle®, MySQL®, MyRocks®, VirtualBox® et ZFS® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; PostgreSQL® est une marque déposée de PostgreSQL Global Development Group ; SQLite® est une marque déposée de Hipp, Wyrick & Company, Inc. ; KeyDB® est une marque déposée d'EQ Alpha Technology Ltd. ; Typesense® est une marque déposée de Typesense Inc. ; REDIS® est une marque déposée de Redis Labs Ltd ; F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB ; HAProxy® est une marque déposée de HAProxy Technologies LLC ; Traefik® est une marque déposée de Traefik Labs ; Envoy® est une marque déposée de CNCF ; Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited ; Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal® ; Shopify® est une marque déposée de Shopify Inc. ; BigCommerce® est une marque déposée de BigCommerce Pty. Ltd.; TYPO3® est une marque déposée de la TYPO3 Association; Ghost® est une marque déposée de la Ghost Foundation; Amazon Web Services, Inc. détient les droits sur AWS® et Amazon SES® ; Google LLC détient les droits sur Google Cloud™, Chrome™ et Google Kubernetes Engine™ ; Alibaba Cloud® est une marque déposée d'Alibaba Group Holding Limited ; DigitalOcean® est une marque déposée de DigitalOcean, LLC ; Linode® est une marque déposée de Linode, LLC ; Vultr® est une marque déposée de The Constant Company, LLC ; Akamai® est une marque déposée d'Akamai Technologies, Inc. ; Fastly® est une marque déposée de Fastly, Inc. ; Let's Encrypt® est une marque déposée d'Internet Security Research Group ; Microsoft Corporation détient les droits sur Microsoft®, Azure®, Windows®, Office® et Internet Explorer® ; Mozilla Foundation détient les droits sur Firefox® ; Apache® est une marque déposée de The Apache Software Foundation ; Apache Tomcat® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée de PHP Group ; Docker® est une marque déposée de Docker, Inc. Kubernetes® est une marque déposée de The Linux Foundation ; OpenShift® est une marque déposée de Red Hat, Inc. ; Podman® est une marque déposée de Red Hat, Inc. ; Proxmox® est une marque déposée de Proxmox Server Solutions GmbH ; VMware® est une marque déposée de Broadcom Inc. ; CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV ; Grafana® est une marque déposée de Grafana Labs ; Prometheus® est une marque déposée de The Linux Foundation ; Zabbix® est une marque déposée de Zabbix LLC ; Datadog® est une marque déposée de Datadog, Inc. ; Ceph® est une marque déposée de Red Hat, Inc. ; MinIO® est une marque déposée de MinIO, Inc. ; Mailgun® est une marque déposée de Mailgun Technologies, Inc. ; SendGrid® est une marque déposée de Twilio Inc. Postmark® est une marque déposée d'ActiveCampaign, LLC ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Hetzner® est une marque déposée de Hetzner Online GmbH ; OVHcloud® est une marque déposée d'OVH Groupe SAS ; Terraform® est une marque déposée de HashiCorp, Inc. ; Ansible® est une marque déposée de Red Hat, Inc. ; cURL® est une marque déposée de Daniel Stenberg ; Facebook®, Inc. détient les droits sur Facebook®, Messenger® et Instagram®. Ce site n'est pas affilié, sponsorisé ou autrement associé à l'une des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées sont la propriété de leurs titulaires respectifs. MANAGED SERVER® est une marque déposée européenne de MANAGED SERVER SRL, dont le siège social est situé Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italie et le siège opérationnel Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Vous êtes-vous déjà demandé si votre hébergement était nul ?

Découvrez dès maintenant si votre hébergeur vous pénalise avec un site web lent digne des années 1990 ! Résultats immédiats.

Fermer le CTA
Retour en haut de page