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.

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.

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.
Retour en haut de page