I vantaggi dell'utilizzo di TLS 1.3 e di 0-RTT nei server Web come NGINX - 🏆 Managed Server

BLOG

18 Maggio 2022

I vantaggi dell’utilizzo di TLS 1.3 e di 0-RTT nei server Web come NGINX

Vediamo come migliorare la velocità e le prestazioni del nostro server web NGINX grazie a TLS 1.3 e 0-RTT

TLS 1.3 Banner e HTTPS

Finalmente nel 2022 sembra ormai assodato che è diventato piuttosto facile portare online un progetto web che possa girare decentemente e portare soddisfazioni e profitti.

Tuttavia, bisogna tener conto che siamo sempre in un’agguerrita competizione in tutte le sfaccettature che possano aiutare a decretare il successo del nostro progetto web.

Non esiste purtroppo il lusso di poter fare le cose benino, o bene, bisogna cercare sempre di fare le cose al meglio in maniera ottimale e maniacale per potersi garantire dei risultati e dei vantaggi sulla concorrenza.

Avere un sito lento o non indicizzato diventa solo un costo inutile che non vi darà mai soddisfazioni professionali ed economiche. Ecco perche dovresti circondarti sempre e solo di stimati e competenti professionisti nel loro campo e nel caso di hosting e web performance affidarti a noi.

Tra i tanti aspetti fondamentali come lo sviluppo, la SEO, il Copy, uno degli aspetti da non trascurare infatti è proprio quello della velocità e della reattività del sito web sia per i motori di ricerca come Google che per l’utente. Abbiamo scritto parecchio in merito, ideando servizi specifici per quegli utenti che non amano raggiungere compromessi sulle performance, senza per questo dover spendere delle cifre considerevoli nell’ordine di migliaia di euro al mese.

Abbiamo insomma reso popolare e accessibili servizi di hosting ad alte performance, coniugando la ricerca e lo sviluppo. Guardandoci intorno e pesando i siti più famosi nel panorama italiano abbiamo potuto verificare che la quasi totalità dei siti web non adottano TLS 1.3 e soprattutto lo 0-RTT che ha permesso nel nostro caso, ad esempio, di recuperare oltre 150 ms di TTFB complessivo, su una spesa complessiva di circa 500ms, migliorandone la velocità di circa il 25%.

In questo articolo spiegherò i vantaggi dell’uso di TLS 1.3 e 0-RTT nei server Web come NGINX, il server web più popolare di cui abbiamo tanto discusso a questo articolo.

TLS (Transport Layer Security) è un protocollo crittografico utilizzato per proteggere le comunicazioni tra client e server su Internet o altre reti. Fornisce protezione della privacy e dell’integrità dei dati scambiati su reti non sicure come Internet. Inoltre, consente alle applicazioni client/server di autenticarsi reciprocamente, permette agli utenti di verificare se sono connessi al server previsto e fornisce facoltativamente un’autenticazione reciproca (il server dimostra la propria identità al client). L’ultima versione di TLS nel momento in cui scriviamo è la 1.3.

Il costo della latenza

Un grande componente delle prestazioni web è la latenza di trasmissione. In poche parole, la latenza di trasmissione è la quantità di tempo necessaria a un messaggio per passare da una parte all’altra su una rete. Una latenza inferiore significa pagine Web più rapide e API più reattive; quando si tratta di reattività, ogni millisecondo conta.

Il diagramma seguente deriva da un recente test di latenza della rete di Cloudflare utilizzando il progetto RIPE Atlas. Nell’esperimento, centinaia di sonde da tutto il mondo hanno inviato un singolo messaggio “ping” a Cloudflare e hanno misurato il tempo impiegato per ottenere una risposta in risposta. Questa volta è una buona approssimazione del tempo impiegato dai dati per effettuare il viaggio di andata e ritorno dal probe al server e ritorno, la cosiddetta latenza di andata e ritorno.

La latenza viene solitamente misurata in millisecondi o millesimi di secondo. Un millesimo di secondo potrebbe non sembrare molto tempo, ma possono sommarsi rapidamente. È generalmente accettato che la soglia oltre la quale gli esseri umani non percepiscono più qualcosa come istantaneo sia 100 ms. Qualsiasi cosa al di sopra di 100 ms sembrerà veloce, ma non immediata. Ad esempio, il tempo di reazione di Usain Bolt fuori dai blocchi di partenza nello sprint di cento metri è di circa 155 ms, un buon punto di riferimento per pensare alla latenza. Usiamo 155 ms, come una quantità di tempo percepibile veloce ma umana, come unità di misura del tempo.

La latenza di andata e ritorno fa una grande differenza per HTTPS. Quando si effettua una connessione sicura a un server, c’è un’ulteriore fase di configurazione che può richiedere fino a tre messaggi per effettuare il viaggio di andata e ritorno tra il client e il server prima ancora che la prima richiesta possa essere inviata. Per un visitatore a 250 ms di distanza, ciò può comportare un atroce ritardo di un secondo (1000 ms) prima dell’inizio del caricamento di un sito. Durante questo periodo Usain Bolt ha corso 10 metri e stai ancora aspettando una pagina web. TLS 1.3 e 0-RTT non possono ridurre la latenza di andata e ritorno di una trasmissione, ma possono ridurre il numero di viaggi di andata e ritorno necessari per configurare una connessione HTTPS.

HTTPS round trip

Affinché un browser scarichi una pagina Web su HTTPS, c’è una configurazione che va dietro le quinte. Ecco le 4 fasi che devono verificarsi la prima volta che il tuo browser tenta di accedere a un sito.

Fase 1: ricerca DNS

Il tuo browser deve convertire il nome host del sito Web (ad esempio blog.cloudflare.com) in un indirizzo IP Internet (come 2400:cb00:2048:1::6813:c166 o 104.19.193.102) prima che possa connettersi ad esso. I resolver DNS gestiti dal tuo ISP di solito memorizzano nella cache l’indirizzo IP per i domini popolari e la latenza del tuo ISP è piuttosto bassa; quindi, questo passaggio richiede spesso una quantità di tempo trascurabile.

Fase 2: TCP Handshake (1 andata e ritorno)

Il passaggio successivo consiste nello stabilire una connessione TCP al server. Questa fase consiste nel client che invia un pacchetto SYN al server e il server risponde con un pacchetto ACK. I dettagli non contano tanto quanto il fatto che ciò richiede che i dati vengano inviati dal client al server e viceversa. Questo richiede un viaggio di andata e ritorno.

Fase 3: stretta di mano TLS (2 viaggi di andata e ritorno)

In questa fase, il client e il server si scambiano il materiale della chiave crittografica e stabiliscono una connessione crittografata. Per TLS 1.2 e precedenti, sono necessari due viaggi di andata e ritorno .

Fase 4: HTTP (1 andata e ritorno)

Una volta stabilita la connessione TLS, il tuo browser può inviare una richiesta HTTP crittografata utilizzandola. Può essere una richiesta GET per un URL specifico come https://managedserver.it , ad esempio. Il server risponderà con una risposta HTTP contenente l’HTML della pagina Web e il browser inizierà a visualizzare la pagina.

Supponendo che il DNS sia istantaneo, rimangono 4 round trip prima che il browser possa iniziare a mostrare la pagina. Se stai visitando un sito a cui ti sei connesso di recente, la fase di handshake TLS può essere ridotta da due round trip a uno con ripresa della sessione TLS .

Ciò lascia i seguenti tempi di attesa minimi:

  • Nuova connessione: 4 RTT + DNS
  • Connessione ripresa: 3 RTT + DNS

In che modo TLS 1.3 e 0-RTT migliorano i tempi di connessione?

Uno dei maggiori vantaggi di TLS 1.3 rispetto alle versioni precedenti è che richiede solo un viaggio di andata e ritorno per impostare la connessione, ripresa o meno. Ciò fornisce una velocità significativa per le nuove connessioni, ma nessuna per le connessioni riprese. Le nostre misurazioni mostrano che circa il 40% delle connessioni HTTPS sono riprese (tramite ID di sessione o ticket di sessione). Con 0-RTT, un viaggio di andata e ritorno può essere eliminato per la maggior parte di quel 40%.

Come funziona TLS?

Per stabilire una connessione sicura tra due parti – in genere un browser (client) e un server web – una parte deve generare una chiave privata (che conosce solo lei) e un certificato a chiave pubblica che contiene entrambe le chiavi insieme alle informazioni sulla sua identità.

TLS instaura uno scambio di chiavi chiamato Handshake (stretta di mano) utilizzando diversi e veloci passaggi che comunque impiegano un trasferimento di dati e ovviamente un dispendio di tempo seppur molto breve (150 / 250 ms).

E’ dunque ovvio che potendo risparmiare del tempo nella negoziazione delle chiavi è possibile migliorare la velocità di navigazione e ottenere dunque delle performance migliori già apprezzabili persino ad occhio nudo.

Che cos’è TLS 1.3?

TLS 1.3 è l’ultima versione del protocollo Transport Layer Security (TLS). TLS 1.3 è stato pubblicato ufficialmente nell’agosto 2018 come RFC 8446, sostituendo TLS 1.2, pubblicato nel 2008. Il motivo principale dell’aggiornamento è stato quello di migliorare la sicurezza e la privacy delle comunicazioni su Internet. Questi miglioramenti includono:

Maggiore sicurezza: TLS 1.3 utilizza una nuova suite crittografica basata sullo scambio di chiavi a curva ellittica Diffie-Hellman (ECDHE) e sull’accordo di chiave HMQV con forward secrecy (FS). Inoltre, utilizza la crittografia autenticata con dati aggiuntivi (AEAD), che garantisce la protezione della riservatezza e dell’integrità, consentendo al contempo l’autenticazione di tutte le parti di una connessione.

Migliori prestazioni: L’uso di gruppi Diffie-Hellman statici e di gruppi a curva ellittica (ECC) consente di ottenere handshake più rapidi rispetto alle versioni precedenti di TLS. Inoltre, l’uso di dati 0-RTT consente risposte più rapide da parte dei server web senza compromettere la sicurezza o la privacy, poiché un aggressore non ha tempo sufficiente per sfruttare le vulnerabilità prima che le risposte vengano inviate ai client.

Notevole nell’elenco delle rimozioni è il trasporto della chiave RSA. Questa modalità è stata utilizzata principalmente perché era più veloce di Diffie‑Hellman, che richiedeva un ulteriore viaggio di andata e ritorno per stabilire la connessione con Perfect Forward Secrecy (PFS). Con TLS 1.3 il viaggio di andata e ritorno aggiuntivo non è più necessario. Con meno opzioni di configurazione, ci sono meno informazioni da scambiare e l’handshake Diffie‑Hellman richiede solo un viaggio di andata e ritorno per essere completato (il diagramma mostra anche una GETrichiesta dopo l’handshake).

TLS HandShake

0-RTT o Ripresa della sessione (Zero Round Trip Time)

Inoltre, TLS 1.3 supporta la ripresa della sessione, che rende più veloce la creazione della connessione eliminando il sovraccarico dovuto alla ripetizione dell’ handshake TLS quando un client torna a un sito visitato in precedenza. Questo è anche chiamato ripristino 0‑RTT (tempo di andata e ritorno zero), perché nessun messaggio di handshake deve andare avanti e indietro tra client e server per la sessione ripresa. La ripresa della sessione viene implementata creando un segreto condiviso durante la sessione originale e archiviandolo in un ticket di sessione. Quando il client ritorna, presenta il ticket di sessione insieme alla sua richiesta, che è crittografata con il segreto condiviso che si trova nel ticket.

0-RTT NGINX

In breve, Zero Round Trip Time Resumption o 0-RTT ottimizza le prestazioni per i client che stanno riprendendo una connessione al tuo sito.

Tecnicamente, nella terminologia di Internet e di rete, si verifica una ripresa quando un client riutilizza le informazioni note dall’ handshake di un server visitato in precedenza.

Confuso? Pensate in questo modo (solo per scopo di esempio): diciamo che stai andando per la prima volta in un posto nuovo, e ci vogliono 15 minuti per arrivarci (5 minuti di configurazione della navigazione + 10 minuti di viaggio). Ora, quando vai di nuovo nello stesso posto, risparmierai 5 minuti perché conosci già la strada e quindi non avrai bisogno di navigazione. L’idea della ripresa è simile.

Conclusione

TLS 1.3 è un grande passo avanti per le prestazioni e la sicurezza web. Combinando TLS 1.3 con 0-RTT, i miglioramenti delle prestazioni sono ancora più drammatici. Combina questo con HTTP/2 e il Web crittografato non è mai stato più veloce, specialmente sulle reti mobili. Consultaci pure senza impegno per conoscere una volta per tutte le problematiche del tuo sito internet che ancora non conosci.

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Facebook, Inc. detiene i diritti su Facebook®; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Questo sito non è affiliato, sponsorizzato, o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello Europeo da MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italia.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto