Ottimizzare la durata della connessione (TCP + TLS), sotto-parte del Time to First Byte

Ottimizzare la durata della connessione (TCP + TLS), sotto-parte del Time to First Byte

Il Time to First Byte (TTFB) può essere suddiviso nelle seguenti sotto-parti:

• Waiting + Redirect (o durata di attesa)
  
• Worker + Cache (o durata della cache)
• DNS (o durata DNS)
• Connection  (o durata della connessione)
• Request (o durata della richiesta)

Vuoi ottimizzare il Time to First Byte? Questo articolo fornisce un'analisi approfondita della parte relativa alla durata DNS del Time to First Byte. Se vuoi comprendere o risolvere problemi del time to first byte e non sai cosa significa la durata di attesa, consulta cos'è il time to first byte e identificare e risolvere i problemi del time to first byte prima di procedere con questo articolo

La parte relativa alla durata della connessione del time to first byte consiste nel tempo impiegato dal browser per connettersi al server web. Dopo questa connessione, il browser e il server aggiungono solitamente un livello di crittografia (TLS). Il processo di negoziazione di queste 2 connessioni richiede un po' di tempo, che viene aggiunto al Time to First Byte.

Processo di connessione nel dettaglio

Il Transmission Control Protocol (TCP) è responsabile dell'instaurazione di una connessione affidabile tra il client (browser) e il server. Questo processo prevede un three-way handshake:

• SYN (Synchronize) Packet: Il client invia un pacchetto SYN al server per avviare la connessione e richiedere la sincronizzazione.
• SYN-ACK (Synchronize-Acknowledge) Packet: Il server risponde con un pacchetto SYN-ACK, confermando la ricezione del pacchetto SYN e accettando di stabilire una connessione.
• ACK (Acknowledge) Packet: Il client invia un pacchetto ACK al server, confermando la ricezione del pacchetto SYN-ACK. A questo punto, la connessione TCP è stabilita, consentendo il trasferimento affidabile dei dati tra client e server.

TCP garantisce che i dati vengano inviati e ricevuti nell'ordine corretto, rinviando eventuali pacchetti persi e gestendo il controllo di flusso per adattarsi alla capacità della rete.

Una volta stabilita la connessione TCP, il protocollo Transport Layer Security (TLS) viene utilizzato per proteggere la connessione. L'handshake TLS prevede diversi passaggi per autenticare il server e stabilire un canale di comunicazione sicuro:

• ClientHello: Il client invia un messaggio "ClientHello" al server, indicando le versioni TLS supportate, le cipher suite e un numero casuale (Client Random).
• ServerHello: Il server risponde con un messaggio "ServerHello", selezionando la versione TLS e la cipher suite dalla lista del client, e fornendo il proprio certificato digitale e un numero casuale (Server Random).
• Certificate and Key Exchange: Il server invia il proprio certificato digitale al client per l'autenticazione. Il client verifica il certificato rispetto alle autorità di certificazione fidate.
• Premaster Secret: Il client genera un premaster secret, lo crittografa con la chiave pubblica del server (dal certificato) e lo invia al server.
• Session Key Generation: Sia il client che il server utilizzano il premaster secret, insieme al Client Random e al Server Random, per generare una chiave di sessione condivisa per la crittografia simmetrica.
• Finished Messages: Il client e il server scambiano messaggi crittografati con la chiave di sessione per confermare che l'handshake è stato completato con successo e che entrambe le parti dispongono della chiave di sessione corretta.

Una volta completato l'handshake TLS, il client e il server hanno stabilito una connessione sicura e crittografata. Questo garantisce che qualsiasi dato scambiato sia protetto da intercettazioni e manomissioni da parte di terzi.

HTTP/3 velocizza le connessioni TLS integrandosi con il protocollo QUIC, che riduce il numero di round trip necessari per stabilire una connessione sicura combinando i processi di handshake in uno solo, e supporta la ripresa 0-RTT per riconnessioni più rapide. Inoltre, l'uso di UDP da parte di QUIC elimina il blocco head-of-line e migliora il controllo della congestione, portando a una trasmissione dei dati più efficiente e a caricamenti delle pagine più veloci.

• HTTP/3 - porta il protocollo QUIC su UDP invece di TCP, consentendo un trasferimento dei dati più veloce ed efficiente
  
• TLS 1.3 Aggiunge maggiore sicurezza e riduce i round trip dell'handshake ed è necessario per la ripresa della connessione 0-RTT. 
• 0-RTT Connection Resumption - Funzionalità di TLS 1.3 che consente ai client di ritorno di inviare dati crittografati immediatamente alla riconnessione riutilizzando le informazioni scambiate  in precedenza.
  
• TCP Fast Open. Consente l'invio di dati nel pacchetto SYN iniziale, riducendo il tempo di round trip per l'handshake TCP.
• TLS false start - Consente l'invio anticipato di dati prima che l'handshake TSL sia completato.
  
• OCSP Stapling -  Velocizza la validazione dei certificati eliminando la necessità per il client di contattare direttamente l'autorità di certificazione

Time to Fist Byte TIP: una CDN non solo offre tempi di round trip più brevi. Utilizzare una CDN spesso migliorerà immediatamente i tempi di connessione TCP e TLS perché i provider CDN premium avranno già configurato correttamente queste impostazioni per te!

Come individuare i problemi di TTFB causati da un tempo di connessione lento

Per individuare l'impatto che gli utenti reali subiscono a causa del redirect, dovrai utilizzare uno strumento RUM come CoreDash. Il monitoraggio degli utenti reali ti permetterà di tracciare i Core Web Vitals con maggiore dettaglio e senza il ritardo di 28 giorni di Google.

In CoreDash è sufficiente 'cliccare su Time to Fist Byte breakdown' per visualizzare la parte relativa alla connessione del Time to First Byte.