HTTP/2 - HTTP/2

HTTP/2
Standard internazionale RFC  7540
Sviluppato da IETF
Introdotto 14 maggio 2015 ; 6 anni fa ( 2015-05-14 )
Sito web https://http2.github.io/

HTTP/2 (originariamente denominato HTTP/2.0 ) è una revisione importante del protocollo di rete HTTP utilizzato dal World Wide Web . È stato derivato dal precedente protocollo SPDY sperimentale , originariamente sviluppato da Google . HTTP/2 è stato sviluppato dall'HTTP Working Group (chiamato anche httpbis, dove " bis " significa "due volte") dell'Internet Engineering Task Force (IETF). HTTP/2 è la prima nuova versione di HTTP da HTTP/1.1, che è stata standardizzata in RFC  2068 nel 1997. Il gruppo di lavoro ha presentato HTTP/2 all'Internet Engineering Steering Group (IESG) perché lo considerasse uno standard proposto nel dicembre 2014, e IESG ne hanno approvato la pubblicazione come Proposed Standard il 17 febbraio 2015 (ed è stato aggiornato a febbraio 2020 in relazione a TLS 1.3 ). La specifica HTTP/2 è stata pubblicata come RFC  7540 il 14 maggio 2015.

Lo sforzo di standardizzazione è stato supportato dai browser Chrome , Opera , Firefox , Internet Explorer 11 , Safari , Amazon Silk e Edge . La maggior parte dei principali browser ha aggiunto il supporto HTTP/2 entro la fine del 2015. Circa il 97% dei browser Web utilizzati ne ha la capacità. A partire da ottobre 2021, il 47% (dopo aver superato di poco il 50%) dei primi 10 milioni di siti Web supportava HTTP/2.

Il suo successore proposto è HTTP/3 , una revisione importante che si basa sui concetti stabiliti da HTTP/2.

Obiettivi

La carta del gruppo di lavoro menziona diversi obiettivi e questioni di interesse:

Differenze da HTTP/1.1

Le modifiche proposte non richiedono alcuna modifica al funzionamento delle applicazioni Web esistenti, ma le nuove applicazioni possono sfruttare le nuove funzionalità per una maggiore velocità. HTTP/2 lascia invariata tutta la semantica di alto livello di HTTP/1.1, come metodi , codici di stato , campi di intestazione e URI . La novità è il modo in cui i dati vengono inquadrati e trasportati tra il client e il server.

I siti Web efficienti riducono al minimo il numero di richieste necessarie per il rendering di un'intera pagina minimizzando (riducendo la quantità di codice e impacchettando parti di codice più piccole in pacchetti, senza ridurne la capacità di funzionamento) risorse come immagini e script. Tuttavia, la minificazione non è necessariamente conveniente né efficiente e potrebbe comunque richiedere connessioni HTTP separate per ottenere la pagina e le risorse minimizzate. HTTP/2 consente al server di "spingere" il contenuto, ovvero di rispondere con dati per più query rispetto a quelle richieste dal client. Ciò consente al server di fornire i dati necessari a un browser Web per eseguire il rendering di una pagina Web, senza attendere che il browser esamini la prima risposta e senza il sovraccarico di un ciclo di richiesta aggiuntivo.

Ulteriori miglioramenti delle prestazioni nella prima bozza di HTTP/2 (che era una copia di SPDY) provengono dal multiplexing di richieste e risposte per evitare alcuni dei problemi di blocco head-of-line in HTTP 1 (anche quando viene utilizzato il pipelining HTTP ), compressione dell'intestazione e priorità delle richieste. Tuttavia, poiché HTTP/2 viene eseguito su una singola connessione TCP, è ancora possibile che si verifichi il blocco dell'head-of-line se i pacchetti TCP vengono persi o ritardati nella trasmissione. HTTP/2 non supporta più il meccanismo di codifica del trasferimento a blocchi di HTTP/1.1 , poiché fornisce i propri meccanismi più efficienti per lo streaming dei dati.

Storia

Genesi in e successive differenze da SPDY

SPDY (pronunciato come "speedy") era un precedente protocollo di sostituzione HTTP sviluppato da un progetto di ricerca guidato da Google . Incentrato principalmente sulla riduzione della latenza, SPDY utilizza la stessa pipe TCP ma protocolli diversi per ottenere questa riduzione. Le modifiche di base apportate a HTTP/1.1 per creare SPDY includevano: "true request pipelining senza restrizioni FIFO, meccanismo di framing dei messaggi per semplificare lo sviluppo di client e server, compressione obbligatoria (incluse le intestazioni), pianificazione delle priorità e persino comunicazione bidirezionale".

Il gruppo di lavoro HTTP considerato il protocollo SPDY di Google, Microsoft s' HTTP Speed + Mobility proposta (basata SPDY), e Network-friendly aggiornamento HTTP. Nel luglio 2012, Facebook ha fornito un feedback su ciascuna delle proposte e ha raccomandato che HTTP/2 si basi su SPDY. La bozza iniziale di HTTP/2 è stata pubblicata nel novembre 2012 e si basava su una copia diretta di SPDY.

La più grande differenza tra HTTP/1.1 e SPDY era che a ogni azione dell'utente in SPDY viene assegnato un "ID flusso", il che significa che c'è un singolo canale TCP che connette l'utente al server. SPDY suddivide le richieste in controllo o dati, utilizzando un "protocollo binario semplice da analizzare con due tipi di frame". SPDY ha mostrato un evidente miglioramento rispetto a HTTP, con una nuova velocità di caricamento della pagina che va dall'11% al 47%.

Lo sviluppo di HTTP/2 ha utilizzato SPDY come punto di partenza. Tra le molte differenze dettagliate tra i protocolli, la più notevole è che HTTP/2 utilizza un algoritmo di compressione dell'intestazione basato su codice Huffman fisso , invece della compressione dinamica basata sul flusso di SPDY. Ciò aiuta a ridurre il potenziale di attacchi Oracle di compressione sul protocollo, come l' attacco CRIME .

Il 9 febbraio 2015, Google ha annunciato l'intenzione di rimuovere il supporto per SPDY in Chrome a favore del supporto per HTTP/2. Ciò ha avuto effetto, a partire da Chrome 51.

Pietre miliari dello sviluppo

Data Pietra miliare
20 dicembre 2007 Prima bozza Internet di revisione HTTP/1.1
23 gennaio 2008 Prime proprietà di sicurezza HTTP Bozza Internet
Inizio 2012 Invito a presentare proposte per HTTP 2.0
14 ottobre – 25 novembre 2012 Ultima chiamata del gruppo di lavoro per la revisione di HTTP/1.1
28 novembre 2012 Prima bozza WG di HTTP 2.0, basata su draft-mbelshe-httpbis-spdy-00
Trattenuto/Eliminato Gruppo di lavoro Ultima chiamata per le proprietà di sicurezza HTTP
settembre 2013 Invia la revisione HTTP/1.1 a IESG per essere presa in considerazione come standard proposto
12 febbraio 2014 Revisione HTTP/1.1 approvata da IESG da pubblicare come standard proposto
6 giugno 2014 Pubblica revisione HTTP/1.1 come RFC  7230 , 7231 , 7232 , 7233 , 7234 , 7235
1 agosto 2014 – 1 settembre 2014 Gruppo di lavoro Ultima chiamata per HTTP/2
16 dicembre 2014 Invia HTTP/2 a IESG per essere preso in considerazione come standard proposto
31 dicembre 2014 – 14 gennaio 2015 Ultima chiamata IETF per HTTP/2
22 gennaio 2015 Telechat IESG per rivedere HTTP/2 come standard proposto
17 febbraio 2015 HTTP/2 approvato da IESG per la pubblicazione come standard proposto
14 maggio 2015 Pubblica HTTP/2 come RFC  7540
Febbraio 2020 RFC  8740 : HTTP/2 con TLS 1.3

Crittografia

HTTP/2 è definito sia per HTTP URI (cioè senza crittografia TLS , una configurazione che è abbreviata in h2c ) sia per HTTPS URI (su TLS usando l' estensione ALPN dove è richiesto TLS 1.2 o successivo, una configurazione che è abbreviata in h2 ).

Sebbene lo standard stesso non richieda l'utilizzo della crittografia, tutte le principali implementazioni client (Firefox, Chrome, Safari, Opera, IE, Edge) hanno dichiarato che supporteranno solo HTTP/2 su TLS, il che rende la crittografia di fatto obbligatoria.

critiche

Il processo di sviluppo di HTTP/2 e il protocollo stesso sono stati oggetto di critiche.

Lo sviluppatore di FreeBSD e Varnish, Poul-Henning Kamp, afferma che lo standard è stato preparato con un programma irrealisticamente breve, escludendo qualsiasi base per il nuovo HTTP/2 diversa dal protocollo SPDY e risultando in altre opportunità mancate di miglioramento. Kamp critica il protocollo stesso per essere incoerente e avere una complessità inutile e schiacciante. Afferma inoltre che il protocollo viola il principio di stratificazione del protocollo , ad esempio duplicando il controllo di flusso che appartiene al livello di trasporto (TCP). La maggior parte delle preoccupazioni, tuttavia, riguardava problemi di crittografia.

Crittografia

Costo computazionale della crittografia obbligatoria e disponibilità del certificato

Inizialmente, alcuni membri del gruppo di lavoro hanno cercato di introdurre un requisito di crittografia nel protocollo. Questo ha affrontato le critiche.

I critici hanno affermato che la crittografia ha costi di elaborazione non trascurabili e che molte applicazioni HTTP in realtà non hanno bisogno di crittografia e i loro provider non desiderano spendere risorse aggiuntive su di essa. I sostenitori della crittografia hanno affermato che questo sovraccarico di crittografia è praticamente trascurabile. Poul-Henning Kamp ha criticato l'IETF per aver standardizzato frettolosamente il prototipo SPDY di Google come HTTP/2 a causa di considerazioni politiche. La critica all'agenda della crittografia obbligatoria all'interno del quadro dei certificati esistente non è nuova, né è unica per i membri della comunità open source - un dipendente Cisco ha dichiarato nel 2013 che l'attuale modello di certificato non è compatibile con piccoli dispositivi come router, perché il presente modello richiede non solo l'iscrizione annuale e lo sgravio delle tasse non banali per ogni certificato, ma deve essere continuamente ripetuto su base annuale. Il gruppo di lavoro alla fine non ha raggiunto il consenso sulla crittografia obbligatoria, sebbene la maggior parte delle implementazioni client lo richieda, il che rende la crittografia un requisito de facto .

Mancanza di crittografia opportunistica

Il protocollo HTTP/2 è stato anche criticato per non supportare la crittografia opportunistica , una misura contro il monitoraggio passivo simile al meccanismo STARTTLS che è stato a lungo disponibile in altri protocolli Internet come SMTP . I critici hanno affermato che la proposta HTTP/2 va in violazione della stessa RFC  7258 di IETF "Pervasive Monitoring Is an Attack", che ha anche lo stato di Best Current Practice 188. RFC7258/BCP188 impone che il monitoraggio passivo sia considerato un attacco, e i protocolli progettati da IETF dovrebbero adottare misure per proteggersi dal monitoraggio passivo (ad esempio, attraverso l'uso della crittografia opportunistica). Sono state fornite una serie di specifiche per la crittografia opportunistica di HTTP/2, di cui draft-nottingham-http2-encryption è stata adottata come elemento di lavoro ufficiale del gruppo di lavoro, portando alla pubblicazione di RFC  8164 nel maggio 2017.

Blocco dell'head-of-line TCP

Sebbene la progettazione di HTTP/2 risolva efficacemente il problema del blocco head-of-line a livello di transazione HTTP consentendo più transazioni HTTP simultanee, tutte queste transazioni vengono multiplexate su una singola connessione TCP, il che significa che qualsiasi head-of-line a livello di pacchetto il blocco della linea del flusso TCP blocca simultaneamente tutte le transazioni a cui si accede tramite quella connessione. Questo blocco head-of-line in HTTP/2 è ora ampiamente considerato come un difetto di progettazione e gran parte dello sforzo dietro QUIC e HTTP/3 è stato dedicato a ridurre i problemi di blocco head-of-line.

Supporto lato server

Software server

  • Apache 2.4.12 supporta HTTP/2 tramite il modulo mod_h2, anche se le patch appropriate devono essere applicate al codice sorgente del server affinché supporti quel modulo. A partire da Apache 2.4.17 tutte le patch sono incluse nell'albero dei sorgenti principale di Apache, sebbene il modulo stesso sia stato rinominato mod_http2. Le vecchie versioni di SPDY erano supportate tramite il modulo mod_spdy, tuttavia lo sviluppo del modulo mod_spdy è stato interrotto.
  • Apache Tomcat supporta HTTP/2 con la versione 8.5 e successive con una modifica alla configurazione.
  • Apache Traffic Server supporta HTTP/2.
  • Caddy supporta HTTP/2.
  • Charles Proxy supporta HTTP/2 dalla versione Charles 4.
  • Citrix NetScaler 11.x supporta HTTP/2.
  • Sucuri supporta HTTP/2.
  • F5 BIG-IP Local Traffic Manager 11.6 supporta HTTP/2.
  • Barracuda Networks WAF (Web Application Firewall) supporta HTTP/2.
  • h2o è stato costruito da zero per il supporto HTTP/2.
  • HAProxy 1.8 supporta HTTP/2.
  • Jetty 9.3 supporta HTTP/2.
  • lighttpd 1.4.56 supporta HTTP/2.
  • LiteSpeed ​​Web Server 5.0 supporta HTTP/2.
  • Microsoft IIS supporta HTTP/2 in Windows 10, Windows Server 2016 e Windows Server 2019 .
  • Netty 4.1 supporta HTTP/2.
  • nginx 1.9.5 supporta HTTP/2, rilasciato il 22 settembre 2015, utilizzando il modulo ngx_http_v2_module e HTTP/2 Server Push dalla versione 1.13.9 del 20 febbraio 2018.
  • Node.js Supporto stabile da 8.13.0. (5.0 supporta HTTP/2 con un modulo e il nodo 8.4 ha introdotto il supporto integrato sperimentale per HTTP/2.)
  • Il server Web Kestrel per ASP.NET Core supporta HTTP/2 a partire da .NET Core 2.2.0-anteprima 1.
  • OpenLiteSpeed ​​1.3.11 e 1.4.8 supporta HTTP/2.
  • Il proxy supporta HTTP/2.
  • Pulse Secure Virtual Traffic Manager 10.2 supporta HTTP/2.
  • Radware Alteon NG supporta HTTP/2.
  • ShimmerCat supporta HTTP/2.
  • Vert.x 3.3 supporta HTTP/2.
  • Warp ( server web Haskell , usato di default in Yesod ) supporta HTTP/2.
  • Wildfly 9 supporta HTTP/2.
  • Il proxy di Envoy supporta HTTP/2.

Reti di distribuzione di contenuti

  • Akamai è stata la prima grande rete CDN a supportare HTTP/2 e HTTP/2 Server Push .
  • Microsoft Azure supporta HTTP/2.
  • PageCDN supporta HTTP/2 out of the box e fornisce un'interfaccia utente per configurare il server HTTP/2 Push in dashboard CDN.
  • CDN77 supporta HTTP/2 utilizzando nginx (20 agosto 2015) .
  • Cloudflare supporta HTTP/2 utilizzando nginx con SPDY come fallback per i browser senza supporto, pur mantenendo tutti i servizi di sicurezza e prestazioni. Cloudflare è stato il primo grande CDN a supportare HTTP/2 Server Push .
  • AWS CloudFront supporta HTTP/2 dal 7 settembre 2016.
  • Supporta rapidamente HTTP/2 incluso Server Push.
  • Imperva Incapsula CDN supporta HTTP/2. L'implementazione include anche il supporto per le funzionalità di mitigazione WAF e DDoS.
  • KeyCDN supporta HTTP/2 utilizzando nginx (6 ottobre 2015). HTTP/2 Test è una pagina di prova per verificare se il tuo server supporta HTTP/2.
  • Voxility supporta HTTP/2 utilizzando nginx da luglio 2016. L'implementazione supporta i servizi di mitigazione Cloud DDoS.
  • StackPath supporta HTTP/2.

implementazioni

Guarda anche

Riferimenti

link esterno