Dato che siamo sempre all’avanguardia nelle nuove tecnologie, abbiamo fatto in modo che l’intero sito web e il pannello di amministrazione di Kinsta siano eseguiti su HTTP\/2 e che la nostra nuova infrastruttura supporti<\/a> HTTP\/2 per tutti i nostri clienti. Questa guida estensa spiega cos’\u00e8 HTTP\/2 a utenti finali, sviluppatori e aziende che perseguono l’innovazione. Dalle informazioni di base agli argomenti pi\u00f9 avanzati, qui c’\u00e8 tutto quello che dovete sapere su HTTP\/2.<\/p>\n L’HTTP<\/a> \u00e8 stato proposto in origine da Tim Berners-Lee<\/a>, il pioniere del World Wide Web che ha progettato il protocollo applicativo pensando alla semplicit\u00e0 per eseguire funzioni di comunicazione di dati ad alto livello tra web-server e client.<\/p>\n La prima versione documentata di HTTP fu rilasciata nel 1991 come HTTP0.9, che nel 1996 ha portato all’introduzione e al riconoscimento ufficiali di HTTP1.0. Ha fatto seguito HTTP1.1 nel 1997 e, da allora, il protocollo ha ricevuto piccoli miglioramenti periodici.<\/p>\n Nel febbraio del 2015, l’HTTP Working Group della Internet Engineering Task Force (IETF<\/a>) ha rivisto l’HTTP e sviluppato la seconda versione principale del protocollo dell’applicazione come HTTP\/2. Nel maggio del 2015, la specifica di implementazione HTTP\/2 \u00e8 stata ufficialmente standardizzata in risposta al protocollo SPDY di Google, compatibile con HTTP. Il confronto tra HTTP\/2 e SPDY continua in tutta la guida.<\/p>\n Il dibattito su HTTP\/2 e HTTP1 deve procedere con una breve premessa sul termine Protocollo usato frequentemente in questa guida. Un protocollo \u00e8 un insieme di regole che governano i meccanismi di comunicazione dei dati tra client (ad esempio i browser utilizzati dagli utenti di Internet per richiedere informazioni) e server (i computer che contengono le informazioni richieste).<\/p>\n I protocolli di solito consistono in tre parti principali: Header, Payload e Footer. L’header \u00e8 posizionato prima del payload e contiene informazioni come gli indirizzi di origine e di destinazione, nonch\u00e9 altri dati (come dimensioni e tipo) relativi al payload. Il payload \u00e8 l’informazione effettiva trasmessa usando il protocollo. Il footer segue il payload ed ha la funzione di campo di controllo per instradare le richieste client-server ai destinatari previsti, insieme all’intestazione, per garantire che i dati del payload vengano trasmessi senza errori.<\/p>\n Il sistema \u00e8 simile al servizio di posta. La lettera (Payload) viene inserita in una busta (Header) con l’indirizzo di destinazione scritto sopra e sigillata con colla e francobollo (Footer) prima di essere spedita. Solo che la trasmissione di informazioni digitali sotto forma di 0 e 1 non \u00e8 cos\u00ec semplice e richiede una nuova dimensione di innovazione in risposta ai crescenti progressi tecnologici che emergono con lo sviluppo esplosivo dell’uso di Internet.<\/p>\n In origine, il protocollo HTTP disponeva di comandi di base: GET, per recuperare informazioni dal server, e POST, per consegnare le informazioni richieste al client. Questo semplice e apparentemente noioso insieme di pochi comandi per ottenere dati (GET) e ricevere una risposta (POST) ha essenzialmente costituito la base per costruire anche altri protocolli di rete. Il protocollo \u00e8 un altro passo in avanti per migliorare l’esperienza utente e l’efficacia di Internet che richiede l’implementazione di HTTP\/2 per migliorare la presenza online.<\/p>\n Dalla sua nascita all’inizio degli anni ’90, HTTP ha visto solo alcune importanti revisioni. La versione pi\u00f9 recente, HTTP 1.1, ha servito il cyber mondo per oltre 15 anni. Nell’attuale epoca di aggiornamenti dinamici delle informazioni, formati media ad alto consumo di risorse ed eccessiva inclinazione verso le prestazioni, le pagine web hanno reso obsolete le vecchie tecnologie di protocollo. Queste tendenze richiedono modifiche significative ad HTTP\/2 per migliorare l’esperienza di Internet.<\/p>\n L’obiettivo primario della ricerca e sviluppo di una nuova versione di HTTP \u00e8 incentrato su tre qualit\u00e0 raramente associate a un singolo protocollo di rete senza che si avverta la necessit\u00e0 di tecnologie di rete aggiuntive: semplicit\u00e0, alte prestazioni e robustezza. Questi obiettivi vengono raggiunti introducendo funzionalit\u00e0 che riducono la latenza nell’elaborazione delle richieste dei browser con tecniche quali multiplexing, compressione, prioritizzazione delle richieste e push del server.<\/p>\n Meccanismi come il controllo del flusso, l’aggiornamento e la gestione degli errori funzionano come miglioramenti del protocollo HTTP per gli sviluppatori per garantire elevate prestazioni e resilienza delle applicazioni “web based”.<\/p>\n Il sistema collettivo consente ai server di rispondere in modo efficiente con pi\u00f9 contenuti di quelli originariamente richiesti dai client, eliminando l’intervento dell’utente per chiedere continuamente informazioni fino a quando il sito web non viene caricato completamente sul browser. Ad esempio, la funzionalit\u00e0 Server Push con HTTP\/2 consente ai server di rispondere con i contenuti completi di una pagina diversi rispetto alle informazioni gi\u00e0 disponibili nella cache del browser. Una efficiente compressione dei file header HTTP riduce al minimo l’overhead del protocollo e migliora le prestazioni ad ogni richiesta del browser e risposta del server.<\/p>\n Le modifiche ad HTTP\/2 sono progettate per mantenere l’interoperabilit\u00e0 e la compatibilit\u00e0 con HTTP1.1. Si prevede che i vantaggi di HTTP\/2 aumenteranno nel tempo sulla base di esperimenti nel mondo reale e la sua capacit\u00e0 di gestire i problemi relativi alle prestazioni nel confronto reale con HTTP1.1 influir\u00e0 notevolmente sulla sua evoluzione a lungo termine.<\/p>\n “….non stiamo sostituendo tutti di HTTP – i metodi, i codici di stato e la maggior parte delle intestazioni che utilizzate oggi saranno gli stessi. Invece, stiamo ridefinendo il modo in cui viene utilizzato “sul filo”, in modo che sia pi\u00f9 efficiente, e che sia pi\u00f9 gentile nei confronti di internet stesso….”. Mark Nottingham<\/a>, presidente dell’HTTP Working Group dell’IETF e membro del W3C TAG.\u00a0 Fonte<\/a><\/p><\/blockquote>\n \u00c8 importante notare che la nuova versione di HTTP \u00e8 un’estensione del suo predecessore e non si prevede che sostituir\u00e0 presto HTTP1.1. L’implementazione di HTTP\/2 non consentir\u00e0 il supporto automatico per tutti i tipi di crittografia disponibili con HTTP1.1, ma sicuramente aprir\u00e0 le porte a migliori alternative o ulteriori aggiornamenti di compatibilit\u00e0 della crittografia nel prossimo futuro. Tuttavia, confronti di funzionalit\u00e0 come HTTP\/2 rispetto a HTTP1 e SPDY rispetto a HTTP\/2 non possono far altro che presentare l’ultimo protocollo applicativo come vincitore in termini di prestazioni, sicurezza e affidabilit\u00e0.<\/p>\n HTTP1.1 era limitato all’elaborazione di una sola richiesta in sospeso per connessione TCP, costringendo i browser a utilizzare pi\u00f9 connessioni TCP per elaborare pi\u00f9 richieste contemporaneamente.<\/p>\n Tuttavia, l’utilizzo di un numero eccessivo di connessioni TCP in parallelo porta a una congestione di TCP che provoca un’ingiusta monopolizzazione delle risorse di rete. I browser che utilizzano connessioni multiple per elaborare richieste aggiuntive occupano una quantit\u00e0 maggiore delle risorse di rete disponibili, riducendo quindi le prestazioni della rete per altri utenti.<\/p>\n L’emissione di pi\u00f9 richieste dal browser provoca anche la duplicazione dei dati sui cavi di trasmissione dei dati, che a loro volta richiedono protocolli aggiuntivi per estrarre, in corrispondenza dei nodi finali, le informazioni desiderate prive di errori.<\/p>\n L’industria di Internet \u00e8 stata naturalmente costretta ad aggirare questi vincoli con pratiche come, tra le altre, la condivisione dei domini, la concatenazione, l’integrazione dei dati e lo sprite. L’uso inefficace delle connessioni TCP sottostanti con HTTP1.1 porta anche a una scarsa priorit\u00e0 delle risorse, causando un degrado esponenziale delle prestazioni man mano che le applicazioni web crescono in termini di complessit\u00e0, funzionalit\u00e0 e portata.<\/p>\n Il Web si \u00e8 evoluto ben oltre la capacit\u00e0 delle obsolete tecnologie di rete basate su HTTP. Le qualit\u00e0 fondamentali di HTTP1.1, sviluppate oltre un decennio fa, hanno scoperto diverse imbarazzanti lacune nelle prestazioni e nella sicurezza.<\/p>\n Cookie Hack, ad esempio, consente ai criminali informatici di riutilizzare una sessione di lavoro precedente per compromettere le password degli account, perch\u00e9 HTTP1.1 non fornisce funzionalit\u00e0 di endpoint-identity di sessione. Anche se simili problemi di sicurezza continueranno a perseguitare HTTP\/2, il nuovo protocollo applicativo \u00e8 progettato con capacit\u00e0 di sicurezza migliori, come l’implementazione migliorata delle nuove funzionalit\u00e0 TLS<\/a>.<\/p>\n La sequenza bidirezionale dei frame in formato testo inviati tramite il protocollo HTTP\/2 e scambiati tra il server e il client \u00e8 nota come “stream”. Precedenti iterazioni del protocollo HTTP erano in grado di trasmettere solo un flusso alla volta, con un certo ritardo tra ciascuna trasmissione del flusso.<\/p>\n La ricezione di grandi quantit\u00e0 di contenuti multimediali tramite flussi individuali inviati uno ad uno \u00e8 inefficiente oltre che dispendiosa in termini di risorse. Le modifiche introdotte con HTTP\/2 hanno contribuito a stabilire un nuovo livello di framing binario per risolvere questi problemi.<\/p>\n Questo livello consente a client e server di disintegrare il payload HTTP in una piccola sequenza interlacciata di frame, indipendente e gestibile. Questa informazione viene quindi riassemblata all’altra estremit\u00e0.<\/p>\n I formati di frame binari consentono lo scambio di sequenze bidirezionali indipendenti multiple, aperte contemporaneamente, senza latenza tra flussi successivi. Questo approccio presenta una serie di vantaggi di HTTP\/2 spiegati qui di seguito:<\/p>\n Con questa funzionalit\u00e0, i pacchetti dati provenienti da pi\u00f9 flussi vengono essenzialmente mixati e trasmessi su una singola connessione TCP. Questi pacchetti vengono quindi divisi all’estremit\u00e0 di ricezione e presentati come flussi di dati individuali. La trasmissione simultanea di pi\u00f9 richieste parallele utilizzando HTTP versione 1.1 o precedente richiedeva connessioni TCP multiple, che intrinsecamente creavano strozzature nelle prestazioni complessive del netowrk nonostante la trasmissione di pi\u00f9 flussi di dati a velocit\u00e0 pi\u00f9 elevate.<\/p>\n\n Questa funzionalit\u00e0 consente al server di inviare al client ulteriori informazioni memorizzabili nella cache che non sono richieste ma sono previste nelle richieste future. Ad esempio, se il client richiede la risorsa X e si comprende che la risorsa Y fa riferimento al file richiesto, il server pu\u00f2 scegliere di inviare Y insieme a X invece di attendere una appropriata richiesta del client.<\/p>\n Il client colloca la risorsa Y in arrivo nella sua cache per un futuro utilizzo. Questo meccanismo consente di salvare un round trip richiesta-risposta e riduce la latenza della rete. Server Push \u00e8 stato originariamente introdotto nel protocollo SPDY di Google. Gli identificatori di flusso contenenti pseudo intestazioni come :path consentono al server di avviare il Push per informazioni che devono essere memorizzabili nella cache. Il client deve consentire esplicitamente al server di eseguire il push delle risorse memorizzabili nella cache con HTTP\/2 o di terminare i flussi trasmessi con un identificatore di flusso specifico.<\/p>\n Altre modifiche HTTP\/2 come Server Push aggiornano o invalidano in modo proattivo la cache del client: si parla di “Cache Push”. Le conseguenze a lungo termine sono incentrate sulla capacit\u00e0 dei server di identificare possibili risorse che possano essere spinte ma che il client in realt\u00e0 non desidera.<\/p>\n L’implementazione di HTTP\/2 presenta prestazioni significative per le risorse push. Altri vantaggi di HTTP\/2 sono elencati di seguito:<\/p>\n Funzionalit\u00e0 Push simili sono gi\u00e0 disponibili con tecniche non ottimali come le risposte del server Inline to Push, mentre Server Push presenta una soluzione a livello di protocollo per evitare la complessit\u00e0 di hack di ottimizzazione secondari alle funzionalit\u00e0 di base dello stesso protocollo dell’applicazione.<\/p>\n HTTP\/2 multiplexa e d\u00e0 la priorit\u00e0 al flusso di dati push per garantire migliori prestazioni di trasmissione rispetto ad altri flussi di dati richiesta-risposta. Come misura di sicurezza integrata, il server deve essere autorizzato a inviare preventivamente le risorse.<\/p>\n L’ultima versione di HTTP si \u00e8 evoluta in modo significativo in termini di capacit\u00e0 e attributi come la trasformazione da un protocollo di testo a un protocollo binario. HTTP1.x elaborava i comandi di testo per completare i cicli richiesta-risposta. HTTP\/2 utilizzer\u00e0 i comandi binari (in 1s e 0s) per eseguire le stesse attivit\u00e0. Questo attributo riduce le complicazioni con l’inquadramento e semplifica l’implementazione di comandi che sono stati mixati in modo confuso a causa di comandi contenenti testo e spazi opzionali.<\/p>\n Sebbene probabilmente occorreranno maggiori sforzi per leggere i file binari rispetto ai comandi di testo, \u00e8 pi\u00f9 facile per la rete generare e analizzare i frame disponibili in binario. La semantica effettiva rimane invariata.<\/p>\n I browser che utilizzano l’implementazione di HTTP\/2 convertiranno gli stessi comandi di testo in binari prima di trasmetterli sulla rete. Il livello di framing binario non \u00e8 retrocompatibile con client e server HTTP1.x ed \u00e8 un fattore chiave per ottenere vantaggi significativi in \u200b\u200btermini di prestazioni rispetto a SPDY e HTTP1.x. L’utilizzo dei comandi binari per consentire alle aziende Internet e al business online di ottenere i principali vantaggi aziendali \u00e8 illustrato di seguito con i vantaggi di HTTP\/2:<\/p>\n L’implementazione di HTTP\/2 consente al client di fornire la preferenza per determinati flussi di dati. Sebbene il server non sia tenuto a seguire queste istruzioni provenienti dal client, il meccanismo consente al server di ottimizzare l’allocazione delle risorse di rete in base ai requisiti dell’utente finale.<\/p>\n La priorit\u00e0 dei flussi funziona con l’assegnazione di Dipendenze e Peso a ciascun flusso. Sebbene tutti gli stream siano intrinsecamente dipendenti l’uno dall’altro, agli stream dipendenti viene anche assegnato un peso compreso tra 1 e 256. I dettagli sui meccanismi di prioritizzazione dello stream sono ancora in discussione.<\/p>\n Nel mondo reale, tuttavia, il server raramente ha il controllo su risorse come connessioni CPU e database. La complessit\u00e0 dell’implementazione stessa impedisce ai server di soddisfare le richieste di priorit\u00e0 del flusso. Ricerca e sviluppo in questo settore sono particolarmente importanti per il successo a lungo termine di HTTP\/2, poich\u00e9 il protocollo \u00e8 in grado di elaborare pi\u00f9 flussi di dati con una singola connessione TCP.<\/p>\n Questa capacit\u00e0 pu\u00f2 portare all’arrivo simultaneo di richieste del server che differiscono effettivamente in termini di priorit\u00e0 dal punto di vista dell’utente finale. Il blocco delle richieste di elaborazione del flusso di dati su base casuale compromette l’efficienza e l’esperienza dell’utente finale promesse dalle modifiche apportate da HTTP\/2. Allo stesso tempo, un meccanismo di prioritizzazione dei flussi intelligente e ampiamente adottato presenta i vantaggi di HTTP\/2 come spiegato di seguito:<\/p>\n Per offrire un’esperienza utente di fascia alta sono necessari siti web ricchi di grafica e contenuti. Il protocollo di applicazione HTTP \u00e8 senza stato, il che significa che ogni richiesta del client deve includere tutte le informazioni necessarie al server per eseguire l’operazione desiderata. Questo meccanismo fa s\u00ec che i flussi di dati trasportino pi\u00f9 frame ripetitivi di informazioni in modo tale che il server stesso non debba archiviare informazioni provenienti dalle precedenti richieste del client.<\/p>\n Nel caso di siti che offrono contenuti ricchi di media, i client spingono pi\u00f9 frame di intestazione quasi identici che portano ad una maggiore latenza e ad un consumo inutile di risorse di rete limitate. Un mix prioritario di flussi di dati non pu\u00f2 raggiungere i desiderati standard prestazionali del parallelismo senza ottimizzare questo meccanismo.<\/p>\n L’implementazione di HTTP\/2 risolve questi problemi data la capacit\u00e0 di comprimere un gran numero di frame di intestazione ridondanti. Utilizza le specifiche HPACK come approccio semplice e sicuro alla compressione delle intestazioni. Sia il client che il server mantengono un elenco di intestazioni utilizzate nelle precedenti richieste client-server.<\/p>\n HPACK comprime il valore individuale di ciascun header prima che venga trasferito sul server, il quale quindi cerca le informazioni codificate nell’elenco dei valori dell’header trasferiti in precedenza per ricostruire le informazioni dell’header complete. La compressione dell’intestazione HPACK per l’implementazione di HTTP\/2 presenta enormi vantaggi in termini di prestazioni, inclusi alcuni dei seguenti:<\/p>\n La semantica delle applicazioni sottostanti a HTTP, compresi codici di stato HTTP, URI, metodologie e file di intestazione, rimane la stessa nell’ultima iterazione dell’HTTP\/2. Questo si basa su SPDY, l’alternativa di Google a HTTP1.x. Le differenze reali risiedono nei meccanismi utilizzati per elaborare le richieste client-server. Il seguente schema identifica alcune aree di similitudine e miglioramenti occorsi tra HTTP1.x, SPDY e HTTP\/2:<\/p>\nQuesta guida mette in evidenza i seguenti aspetti chiave di HTTP\/2:<\/h3>\n
\n
Che cos’\u00e8 l’HTTP\/2?<\/h2>\n
![\"Timeline](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/http-timeline.png\")
Che Cos’\u00c8 un Protocollo?<\/h3>\n
![\"Posta](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/posta-http2.png\")
Obiettivo della Creazione di HTTP\/2<\/h2>\n
![\"](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/esperienza-internet.png\" "\\"Internet")
![\"Crittografia](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2019\/10\/crittografia.png\")
Cosa C’Era di Sbagliato in HTTP1.1?<\/h2>\n
![\"Richieste](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/richieste-http.png\")
![\"Frazionamento](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/frazionamento-del-dominio.png\" "\\"HTTP\/2")
Aggiornamenti delle Funzionalit\u00e0 di HTTP\/2<\/h2>\n
Flussi Multiplex<\/h3>\n
![\"Flussi](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/flussi-http2.png\")
\n
Server Push HTTP\/2<\/h3>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/http2-push-1.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/http2-autorizzato.png\")
Protocolli Binari<\/h3>\n
![\"Protocolli](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/protocolli-binary-2.png\")
\n
Priorit\u00e0 dei Flussi<\/h3>\n
![\"Peso](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/peso-http2.png\")
\n
![\"Carico](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/carico-pagina-http2.png\")
Compressione dell’Header con Stato<\/h3>\n
![\"Compressione](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/compressione-http2-hpack-1.png\")
\n
Similitudini tra HTTP1.x e SPDY<\/h2>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/http2-https.png\")
![\"Crittografia](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/crittografia-http2.png\")
![\"Velocit\u00e0](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/velocita-internet.jpg\")
![\"Miglioramenti](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/miglioramenti-delle-prestazioni-http2.jpg\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/http2_mobile.png\")
![\"Calo](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/calo-prezzi-su-internet.png\")
![\"Mappa](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/mappa-larghezza-banda.png\")
![\"Prima](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/prima-cellulare.png\")
![\"Sicurezza](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/sicurezza-https2.png\")
![\"Vantaggi](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/vantaggi-https2-seo.png\")
![\"Confronto](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/confronto-http2.png\")
![\"Supporto](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/supporto-browser-http2.png\")
![\"Supporto](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2016\/04\/supporto-https2-nginx-apache.png\")
![\"Aggiungere](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2015\/04\/aggiungi-crittografia-certificato.png\" "\\"Aggiungere")