Perché HTTP/2 è più lento del semplice HTTPS?

Question

Sto valutando quello che posso ottenere per il mio sito web da HTTP2 in termini di prestazioni e di ottenere risultato strano - il sito in Europa viene caricato da noi:

• con HTTP/2 - in 6-7 secondi
• con HTTPS semplici - a 5-6 secondi (circa 1 secondo più veloce)

ho catturare screenshot dal monitor di rete di Chrome e sembra che con HTTP/2 la maggior parte delle risorse vengono caricate in successione un altro piuttosto che in parallelo come nel caso del semplice SSL.

Per il test sto utilizzando la mia applicazione Web coperta da Apache 2.4.17 (Win32) come proxy (per applicare il supporto per i protocolli SSL & HTTP/2). Il browser client è Chrome 46.0.2490.86 su Windows 7.

Le richieste di rete catturate sono riportate di seguito. Breve sommario: 1. Pugno uno - è la pagina HTML 2. Gruppo successivo - 6 richieste - risorse dichiarate direttamente in HTML 3. Il resto - risorse aggiunte dinamicamente tramite script (tag "script" e "link/css" nel documento /capo).

Il lato sinistro dell'immagine è HTTP/2, lato destro - stesso personale tramite semplice SSL (http2_module è disattivato).

---

Aggiornamento: Ho testato "qualcosa d'altro" ciò che supporta HTTP/2 come proxy inverso. È nginx 1.9.7.1 Kitty da http://nginx-win.ecsds.eu - fork di originale nginx 'per windows'. HTTP/2 in originale nginx è disponibile solo in commercial version, quindi non ho potuto provarlo. E sembra che non ci siano altre implementazioni server di HTTP/2 + proxy inverso disponibile per Windows, o semplicemente non sono riuscito a trovarle (lista here e here).

Il risultato che ho ottenuto con Kitty è ancora più fuorviante: non esiste un "carico sequenziale" di risorse come in Apache, ma la velocità di trasferimento è due volte più lenta su HTTP/2 che su un semplice SSL. Il risultato finale è - HTTP/2 è significativamente più lento del semplice SSL. Di seguito sono tutti loro affiancati.

Di tutto questo posso solo presumere che le prestazioni dipendono fortemente dall'implementazione e l'implementazione attualmente disponibile si comporta in modo strano per ottenere conclusioni coerenti su HTTP/2.

Answer 1

Così, finalmente la mia decisione è - non c'è niente di sbagliato con HTTP/sé 2, c'è qualcosa di sbagliato con le implementazioni attualmente disponibili.

• Apache HTTPD 2.4.17/Win32 - ha qualche strano effetto 'carico sequenziale'
• nginx Kitty - fornisce velocità di trasferimento stranamente lento
• nginx ufficiale del freeware non ha HTTP2 modulo costruito nel

ma

• personalizzato nginx -built per le finestre da kevinworthington.com
• Apache HTTPD 2.4.17/linux

mostrano entrambe le prestazioni previste. Ecco lo screenshot per lo stesso test eseguito nella 'domanda', ma con proxy inverso Apache ospitato sul computer Linux di un altro ragazzo qui.

Answer 2

Date un'occhiata a questo, è una versione modificata di nginx sviluppato da Taobao.org, e utilizzato da AliExpress e un sacco di altri siti occupati. Supporta HTTP2 out of the box, e anche alcune altre funzionalità disponibili solo in nginx commerciale, come il controllo upstream.

http://tengine.taobao.org/

Answer 3

Ci sono in esecuzione più recente nginx con http/2

nginx version: nginx/1.9.10 
built with OpenSSL 1.0.2e 3 Dec 2015 
TLS SNI support enabled 

Abbiamo fatto la stessa osservazione. Stiamo registrando $ request_time e $ upstream_time. Mentre upstream_time è uguale indipendentemente dal protocollo, il REQUEST_TIME generale è diversa:

# grep ' 443 ' access.log|grep 'HTTP/1.1'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}' 
0.0116887 # HTTP/1.1 request_time in seconds 
0.00673473 # HTTP/1.1 upstream_time in seconds 

# grep ' 443 ' access.log|grep 'HTTP/2.0'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}' 
0.0363673 # HTTP/2.0 request_time in seconds 
0.00695812 # HTTP/2.0 upstream_time in seconds 

Così l'orario della richiesta complessiva per HTTP/1.1 è tre volte meglio! Forse c'è qualcosa che non funziona con logging request_time e http/2 a causa degli stream. Davvero non lo so, ma la promessa era che http/2 è più veloce di http/1.1 se entrambi sono in esecuzione su TLS.

Ma esaminerò ulteriormente questo.