Che cos'è HTTP/2?
HTTP/2 è una revisione importante del protocollo HTTP. È stato rilasciato nel maggio 2015 ed è stato progettato per migliorare le prestazioni del web consentendo ai browser di inviare richieste multiplexate ai server. I server, in cambio, possono inviare risposte multiplexate ai browser, comprimere le intestazioni e inviare contenuti al browser prima che vengano richiesti.
Queste nuove funzionalità consentono ai server e ai browser che comunicano tramite HTTP/2 di consumare meno risorse, di sperimentare una minore latenza e di ottenere una maggiore efficienza rispetto a quelli che comunicano tramite il protocollo HTTP/1.1 che lo ha preceduto.
Nonostante questo miglioramento, HTTP/2 non è un sostituto di HTTP/1.1. La Internet Engineering Task Force (IETF), l'organismo che si occupa di responsabile della creazione e della gestione del Standard HTTP, considera HTTP/2 un'alternativa e non una sostituzione per HTTP/1.1.
Che cos'è l'HTTP?
Per comprendere correttamente HTTP/2, dobbiamo comprendere HTTP. HTTP (abbreviazione di Hypertext Transfer Protocol) è il protocollo standard per il trasferimento dei dati sul web. È il linguaggio che i browser e i server utilizzano per comunicare tra loro.
Ad esempio, quando un utente vuole accedere a un sito web, inserisce l'URL nel proprio browser. Il browser invia quindi una richiesta HTTP al server, richiedendo i file contenenti il testo, le immagini e gli script della pagina web.
Ad esempio, il browser può inviare la richiesta riportata di seguito:
GET / HTTP/1.1 Host: yourdomain.com User-Agent: Chrome/Windows Accetta: text/html Lingua di accettazione: en-US
Il server elabora quindi la richiesta e restituisce la risposta in formato HTTP.
HTTP/1.1 200 OK
Contenuto: text/html; charset=UTF-8
Lunghezza del contenuto: 1256
Data: Mon, 01 Jan 2025 12:00:00 GMT
Server: Apache
Connessione: chiudere
La richiesta e la risposta di cui sopra sono state inviate nel formato HTTP/1.1. Tuttavia, HTTP/1.1 e HTTP/2 sono solo due dei molteplici protocolli HTTP disponibili. L'intero protocollo HTTP comprende:
- HTTP/0.9 (rilasciato nel 1991)
- HTTP/1.0 (rilasciato nel 1996)
- HTTP/1.1 (rilasciato nel 1997 e prima versione HTTP di rilievo)
- HTTP/2 (rilasciato nel 2015 ed è la seconda versione principale di HTTP)
- HTTP/3 (rilasciata nel 2022 è la terza versione HTTP principale)
Come HTTP/2 migliora HTTP/1.1
HTTP/2 presenta tre miglioramenti principali rispetto a HTTP/1.1. Essi sono:
- Multiplexing
- Compressione delle intestazioni
- Spinta del server
1 Multiplexing
Il multiplexing è il principale miglioramento di HTTP/2 rispetto a HTTP/1.1. Si riferisce alla capacità di HTTP/2 di inviare e ricevere più richieste e risposte contemporaneamente su un'unica connessione. Si riferisce alla capacità di HTTP/2 di inviare e ricevere più richieste e risposte contemporaneamente su una singola connessione.
HTTP/1.1 non disponeva di questa funzionalità e in genere gestiva le richieste in modo sequenziale. Ciò significa che il server deve restituire una risposta per una richiesta precedente prima che il browser possa procedere con la richiesta successiva sulla stessa connessione.
Questo a volte porta al problema del blocco della testa della linea (HOL blocking), che si verifica quando una richiesta o una risposta lenta ritarda le richieste successive. Questo causa una lentezza velocità di caricamento delle pagineche danneggia il esperienza dell'utente per i visitatori.
Si può pensare all'HTTP/1.1 come a una coda in cui la persona che sta davanti deve essere servita prima che possa essere servita la persona successiva. Se la persona davanti è bloccata al server per qualsiasi motivo, la coda viene ritardata e chi è in fondo non viene servito.
Gli sviluppatori che utilizzano HTTP/1.1 possono limitare questo problema aprendo più connessioni. Tuttavia, questo consuma ulteriori risorse e può portare al blocco della linea di testa se una delle richieste o delle risorse è lenta.
HTTP/2 risolve il problema dell'head-of-line (a livello HTTP) utilizzando il multiplexing. Ciò significa che il browser invia più richieste contemporaneamente, mentre il server restituisce le risposte non appena sono pronte, senza dover attendere il completamento di altre richieste e risposte.
2 Compressione delle intestazioni
Le richieste e le risposte HTTP includono tipicamente un'intestazione contenente importanti metadati sulla richiesta o sulla risposta. In HTTP/1.1, le intestazioni di queste richieste e risposte sono inviate come testo semplice, non compresso e leggibile dall'uomo.
Sebbene siano ottimi per la leggibilità, non sono ottimizzati per la velocità e possono rallentare la velocità di caricamento della pagina, soprattutto quando si è su una rete lenta o quando il browser e il server si scambiano più richieste e risposte..
HTTP/2 migliora questo aspetto comprimendo l'intestazione utilizzando il formato di compressione delle intestazioni HPACK. HPACK sostituisce le chiavi e i valori dell'intestazione comunemente utilizzati con brevi codici numerici, fornendo inoltre un sistema di codifica per chiavi e valori dell'intestazione unici.
Ad esempio, l'intestazione HTTP/1.1 qui sotto specifica:
- Il browser (
User-Agent: Mozilla/5.0) - The URL the browser wants to access (
Host: yourdomain.com) - The URL path the browser wants to access (
/index.html) - The language in which the browser expects the response (
Accept-Language: en-US)
GET /index.html HTTP/1.1 Host: yourdomain.com User-Agent: Mozilla/5.0 Accept: text/html Accept-Language: en-US Connection: keep-alive
Meanwhile, this is what the HTTP/1.1 request above will look like if it were created using the HTTP/2 protocol. As you can see, the HTTP/2 protocol is unreadable to humans. However, browsers and servers understand it.
00 00 5f 01 05 00 00 00 01 82 87 84 8f 40 0a 75 73 65 72 2d 61 67 65 6e 74 0d 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 40 06 61 63 63 65 70 74 09 74 65 78 74 2f 68 74 6d 6c 40 10 61 63 63 65 70 74 2d 6c 61 6e 67 75 61 67 65 05 65 6e 2d 55 53
3 Server Push
HTTP/2 allows the server to send resources to the browser before they are requested. For instance, when a browser requests a resource’s HTML file, the server sends the HTML file along with the CSS and JavaScript files.
This feature is called server push, and is very helpful because it saves the browser from sending multiple requests to access resources on the server. It also enables visitors to access content and resources quickly, ultimately enhancing the user experience.
However, server push can waste bandwidth, particularly when the user does not need the pushed resource or already has it cached on their device. Overall, the feature is largely unpopular and is rarely used, except in specific instances.
HTTP/2 Best Practices
HTTP/2 remains the most widely used HTTP protocol today. Many developers prefer it over the older HTTP/1.1 and even the newer HTTP/3. That said, it is a great idea to keep these best practices in mind when using it.
1 Only Use HTTP/2 over HTTPS Connections
Modern browsers only support HTTP/2 when used over a secure HTTPS connection. If the connection is not secure, the system will fall back to HTTP/1.1.
You can avoid this by including a Sicurezza del livello di trasporto (TLS) certificate, also known as a SSL (Secure Sockets Layer) certificate, on webpages and servers you configure to run over HTTP/2.
2 Use Server Push Sparingly
HTTP/2’s server push feature can improve performance by sending resources to the browser before it requests them. However, while it speeds up page load time, it can waste bandwidth, strain server resources, and delay the loading of other critical resources.
To avoid performance issues, ensure to use the server push feature sparingly. Many developers only use it to push high-priority resources like CSS and above the fold images. For other resources, they use the HTML preload value (rel="preload").
3 Avoid Unnecessary Redirects
Redirects create round-trip delays, which can cancel out the benefits of HTTP/2. You can reduce the chances of this happening by specifying your desired URLs using a canonical tag. This makes it more likely that search engines will recognize your canonical URLs and use them.
4 Avoid Domain Sharding
Domain sharding is the practice of splitting resources across multiple subdomains. This was useful in HTTP/1.1, where it allowed developers to bypass connection limits. However, it becomes counterproductive with HTTP/2.
HTTP/2 supports multiplexing, which enables multiple streams to share a single connection. As a result, domain sharding is unnecessary and can actually degrade performance by forcing the browser and server to establish multiple TLS connections. This increases latency and consumes additional resources.