Prestazioni HTTP vs HTTPS

Ci sono grandi differenze nelle prestazioni tra http e https? Mi sembra di ricordare che HTTPS può essere un quinto più veloce di HTTP. È valido con i webserver / browser di generazione attuale? Se sì, ci sono dei white paper per supportarlo?

C’è una risposta molto semplice a questa: profilare le prestazioni del tuo server web per vedere quale sia la penalità delle prestazioni per la tua situazione specifica. Ci sono diversi strumenti là fuori per confrontare le prestazioni di un server HTTP vs HTTPS (JMeter e Visual Studio vengono in mente) e sono abbastanza facili da usare.

Nessuno può darti una risposta significativa senza alcune informazioni sulla natura del tuo sito web, hardware, software e configurazione di rete.

Come altri hanno già detto, ci sarà un certo livello di overhead dovuto alla crittografia, ma dipende molto da:

  • Hardware
  • Software del server
  • Rapporto tra contenuto dinamico e contenuto statico
  • Distanza dal client al server
  • Durata tipica della sessione
  • Etc (il mio preferito)
  • Comportamento di memorizzazione nella cache dei client

Nella mia esperienza, i server che pesano sui contenuti dinamici tendono ad essere meno influenzati da HTTPS perché il tempo impiegato per la crittografia (overhead SSL) è insignificante rispetto al tempo di generazione del contenuto.

I server che sono pesanti nel servire un insieme abbastanza piccolo di pagine statiche che possono facilmente essere memorizzati nella cache soffrono di un sovraccarico molto più elevato (in un caso, il throughput è stato annullato su una “intranet”).

Modifica: un punto sollevato da molti altri è che l’handshake SSL è il costo principale di HTTPS. È corretto, motivo per cui “la tipica lunghezza della sessione” e “il comportamento di memorizzazione nella cache dei client” sono importanti.

Molte sessioni molto brevi significano che il tempo di handshake sopraffà qualsiasi altro fattore di performance. Per sessioni più lunghe, il costo di handshaking sarà sostenuto all’inizio della sessione, ma le richieste successive avranno un sovraccarico relativamente basso.

La memorizzazione nella cache del client può essere eseguita in diversi passaggi, ovunque da un server proxy su larga scala fino alla cache del browser individuale. Generalmente il contenuto HTTPS non verrà memorizzato nella cache in una cache condivisa (sebbene alcuni server proxy possano sfruttare un comportamento di tipo man-in-the-middle per ottenere ciò). Molti browser memorizzano nella cache il contenuto HTTPS per la sessione corrente e spesso le volte tra una sessione e l’altra. L’impatto della non memorizzazione nella cache o meno nella memorizzazione nella cache significa che i client recupereranno lo stesso contenuto più frequentemente. Ciò si traduce in più richieste e larghezza di banda per servire lo stesso numero di utenti.

HTTPS richiede una stretta di mano iniziale che può essere molto lenta. La quantità effettiva di dati trasferiti come parte dell’handshake non è enorme (in genere meno di 5 kB), ma per richieste molto piccole, questo può essere un bel po ‘di overhead. Tuttavia, una volta che l’handshake è terminato, viene utilizzata una forma molto veloce di crittografia simmetrica, quindi l’overhead è minimo. In conclusione: fare molte richieste brevi su HTTPS sarà un po ‘più lento di HTTP, ma se trasferisci molti dati in una singola richiesta, la differenza sarà insignificante.

Tuttavia, keepalive è il comportamento predefinito in HTTP / 1.1, quindi eseguirai un singolo handshake e quindi molte richieste sulla stessa connessione. Questo fa una differenza significativa per HTTPS. Probabilmente dovresti profilare il tuo sito (come altri hanno suggerito) per essere sicuro, ma sospetto che la differenza di prestazioni non sarà evidente.

Per capire veramente come HTTPS aumenterà la latenza, devi capire come vengono stabilite le connessioni HTTPS. Ecco un bel diagramma . La chiave è che invece del client che ottiene i dati dopo 2 “gambe” (un viaggio di andata e ritorno, si invia una richiesta, il server invia una risposta), il client non otterrà dati fino ad almeno 4 gambe (2 round trip) . Pertanto, se occorrono 100 ms per spostare un pacchetto tra il client e il server, la prima richiesta HTTPS richiederà almeno 500 ms.

Ovviamente, questo può essere attenuato riutilizzando la connessione HTTPS (che i browser dovrebbero fare), ma spiega parte di quello stallo iniziale durante il caricamento di un sito Web HTTPS.

L’overhead NON è dovuto alla crittografia. Su una CPU moderna, la crittografia richiesta da SSL è banale.

Il sovraccarico è dovuto agli handshake SSL, che sono lunghi e aumentano drasticamente il numero di round-trip richiesti per una sessione HTTPS su una HTTP.

Misurare (usando uno strumento come Firebug) i tempi di caricamento della pagina mentre il server si trova alla fine di un collegamento simulato ad alta latenza. Esistono strumenti per simulare un collegamento ad alta latenza – per Linux c’è “netem”. Confronta HTTP con HTTPS nella stessa configurazione.

La latenza può essere mitigata in una certa misura da:

  • Garantire che il server stia utilizzando i keepalives HTTP: ciò consente al client di riutilizzare le sessioni SSL, evitando così la necessità di un altro handshake
  • Ridurre il numero di richieste al minimo ansible – combinando le risorse laddove ansible (ad esempio .js include file, CSS) e incoraggiando il caching lato client
  • Riduci il numero di caricamenti della pagina, ad esempio caricando i dati non necessari nella pagina (magari in un elemento HTML nascosto) e quindi mostrandoli tramite script client.

Aggiornamento dicembre 2014

Puoi facilmente testare la differenza tra le prestazioni HTTP e HTTPS nel tuo browser utilizzando il sito web di test HTTP vs HTTPS di AnthumChris : “Questa pagina misura il tempo di caricamento su HTTP non crittografate e connessioni HTTPS crittografate. Entrambe le pagine caricano 360 immagini uniche e non memorizzate nella cache (2,04 MB totali). ”

I risultati potrebbero sorprenderti.

È importante avere una conoscenza aggiornata delle prestazioni HTTPS poiché l’autorità di certificazione Let’s Encrypt inizierà a rilasciare certificati SSL gratuiti, automatizzati e aperti nell’estate 2015, grazie a Mozilla, Akamai, Cisco, Electronic Frontier Foundation e IdenTrust.

Aggiornamento di giugno 2015

Aggiornamenti su Let’s Encrypt – Arrivando a settembre 2015:

  • Let’s Encrypt Launch Schedule (16 giugno 2015)
  • Let’s Encrypt Root and Intermediate Certificates (4 giugno 2015)
  • Bozza Let’s Encrypt Subscriber Agreement (21 maggio 2015)

Maggiori informazioni su Twitter: @letsencrypt

Per maggiori informazioni sulle prestazioni HTTPS e SSL / TLS, consultare:

  • TLS è ancora veloce?
  • Networking dei browser ad alte prestazioni, Capitolo 4: Transport Layer Security
  • SSL overclocking
  • Anatomia e prestazioni dell’elaborazione SSL

Per maggiori informazioni sull’importanza dell’utilizzo di HTTPS, vedere:

  • Perché HTTPS per tutto? (Lo standard solo HTTPS)
  • Let’s Encrypt (Internet Research Group)
  • HTTPS Everywhere (Electronic Frontier Foundation)

Per riassumere, lasciatemi citare Ilya Grigorik : “TLS ha esattamente un problema di prestazioni: non è usato abbastanza ampiamente, tutto il resto può essere ottimizzato”.

Grazie a Chris – autore del benchmark Test HTTP contro HTTPS – per i suoi commenti qui sotto.

La risposta superiore corrente non è completamente corretta.

Come altri hanno sottolineato, https richiede l’handshaking e quindi esegue più roundtrip su TCP / IP.

In un ambiente WAN, in genere, la latenza diventa il fattore limitante e non il maggiore utilizzo della CPU sul server.

Tieni presente che la latenza dall’Europa agli Stati Uniti può essere di circa 200 ms (tempo di percorrenza).

Puoi facilmente misurare questo (per il caso singolo utente) con HTTP Watch .

Oltre a tutto quanto menzionato finora, tieni presente che alcuni (tutti?) Browser Web non memorizzano il contenuto memorizzato nella cache ottenuto tramite HTTPS sul disco rigido locale per motivi di sicurezza. Ciò significa che dalle pagine di prospettiva dell’utente con un sacco di contenuto statico sembrerà caricarsi più lentamente dopo il riavvio del browser, e dal punto di vista del tuo server il volume di richieste di contenuto statico su HTTPS sarà superiore a quello che sarebbe stato su HTTP.

Non c’è una sola risposta per questo.

La crittografia consumerà sempre più CPU. Questo può essere scaricato su hardware dedicato in molti casi e il costo varia in base all’algoritmo selezionato. Per esempio, 3des è più costoso di AES. Alcuni algoritmi sono più costosi per il crittografo rispetto al decryptor. Alcuni hanno il costo opposto.

Più costoso della cripta di massa è il costo della stretta di mano. Le nuove connessioni consumeranno molta più CPU. Questo può essere ridotto con la ripresa della sessione, al costo di mantenere i vecchi segreti delle sessioni in giro fino alla loro scadenza. Ciò significa che le piccole richieste di un cliente che non ritorna più sono le più costose.

Per il traffico cross-line, potresti non notare questo costo nella tua velocità dati, perché la larghezza di banda disponibile è troppo bassa. Ma lo noterete sicuramente nell’uso della CPU su un server occupato.

Posso dire (come utente dialup) che la stessa pagina su SSL è parecchie volte più lenta rispetto a un normale HTTP …

In un certo numero di casi l’impatto sulle prestazioni degli handshake SSL sarà mitigato dal fatto che la sessione SSL può essere memorizzata nella cache su entrambi i lati (desktop e server). Su macchine Windows, ad esempio, la sessione SSL può essere memorizzata nella cache per un massimo di 10 ore. Vedi http://support.microsoft.com/kb/247658/EN-US . Alcuni acceleratori SSL disporranno anche di parametri che consentono di ottimizzare il tempo in cui la sessione viene memorizzata nella cache.

Un altro impatto da considerare è che il contenuto statico pubblicato su HTTPS non verrà memorizzato nella cache dai proxy e ciò potrebbe ridurre le prestazioni tra più utenti che accedono al sito tramite lo stesso proxy. Ciò può essere attenuato dal fatto che il contenuto statico verrà memorizzato nella cache anche sui desktop, nelle versioni di Internet Explorer 6 e 7 contenuto statico HTTPS memorizzabile nella cache a meno che non venga richiesto diversamente (Menu Strumenti / Opzioni Internet / Avanzate / Sicurezza / Non salvare le pagine crittografate su disco).

Ho fatto un piccolo esperimento e ho ottenuto il 16% di differenza di tempo per la stessa immagine da flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

inserisci la descrizione dell'immagine qui

Ovviamente questi numeri dipendono da molti fattori, come prestazioni del computer, velocità di connessione, carico del server, QoS sul percorso (il particolare percorso di rete preso dal browser al server) ma mostra l’idea generale: HTTPS è più lento allora HTTP, dal momento che Richiede più operazioni da completare (dati di handshaking SSL e codifica / decodifica).

Ecco un ottimo articolo (un po ‘vecchio, ma comunque eccezionale) sulla latenza SSL handshake. Mi ha aiutato a identificare SSL come la causa principale della lentezza per i clienti che utilizzavano la mia app attraverso connessioni Internet lente:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Poiché sto studiando lo stesso problema per il mio progetto, ho trovato queste diapositive. Più vecchio ma interessante:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

TLS è ancora veloce? Sì.

Ci sono molti progetti là fuori che mirano a sfocare le linee e rendere HTTPS altrettanto veloce. Come SPDY e mod-spdy .

CONFRONTO DI PERFORMANCE HTTP VS HTTPS

Ho sempre associato HTTPS con tempi di caricamento delle pagine più lenti rispetto al semplice vecchio HTTP. Come sviluppatore web, le prestazioni della pagina web sono importanti per me e tutto ciò che rallenta le prestazioni delle mie pagine web è un no-no.

Al fine di comprendere le implicazioni in termini di prestazioni, lo schema seguente ti fornisce un’idea di base su cosa succede quando si effettua una richiesta per una risorsa utilizzando HTTPS.

inserisci la descrizione dell'immagine qui

Come puoi vedere dal diagramma sopra, ci sono alcuni passaggi aggiuntivi che devono essere effettuati quando si utilizza HTTPS rispetto all’utilizzo di HTTP semplice. Quando si effettua una richiesta utilizzando HTTPS, è necessario che si verifichi una stretta di mano per verificare l’autenticità della richiesta. Questa stretta di mano è un passo in più rispetto ad una richiesta HTTP e purtroppo comporta un sovraccarico.

Per comprendere le implicazioni in termini di prestazioni e verificare personalmente se l’impatto sulle prestazioni sarebbe significativo, ho utilizzato questo sito come piattaforma di test. Mi sono diretto a webpagetest.org e ho usato lo strumento di comparazione visuale per confrontare questo caricamento del sito usando HTTPS vs HTTP.

Come puoi vedere da Qui è il Test del video Il risultato usando HTTPS ha avuto un impatto sui tempi di caricamento della mia pagina, tuttavia la differenza è trascurabile e ho notato solo una differenza di 300 millisecondi. È importante notare che questi tempi dipendono da molti fattori, come le prestazioni del computer, la velocità di connessione, il carico del server e la distanza dal server.

Il tuo sito potrebbe essere diverso ed è importante testare accuratamente il tuo sito e verificare l’impatto sulle prestazioni coinvolto nel passaggio a HTTPS.

POSSIAMO MIGLIORARE LE PRESTAZIONI? visita qui per ottenere informazioni dettagliate

Sembra che ci sia un brutto caso qui: Ajax su wifi congestionato.

Ajax di solito significa che il KeepAlive è scaduto dopo circa 20 secondi. Tuttavia, il wifi significa che la connessione ajax (idealmente veloce) deve effettuare più round trip. Peggio ancora, il wifi spesso perde i pacchetti e ci sono ritrasmissioni TCP. In questo caso, HTTPS si comporta davvero male!

C’è un modo per misurare questo. Lo strumento di apache chiamato jmeter misurerà il throughput. Se si imposta un ampio campionamento del proprio servizio con jmeter, in un ambiente controllato, con e senza SSL, è necessario ottenere un confronto accurato del costo relativo. Sarei interessato ai tuoi risultati

HTTPS ha un overhead di crittografia / decrittografia, quindi sarà sempre leggermente più lento. La terminazione SSL richiede molta CPU. Se si dispone di dispositivi per scaricare SSL, la differenza di latenza potrebbe essere a malapena evidente a seconda del carico in cui si trovano i server.

Una differenza di prestazioni più importante è che una sessione HTTPS è ketp aperta mentre l’utente è connesso. Una “sessione” HTTP dura solo per una singola richiesta di elemento.

Si sta eseguendo un sito con un numero elevato di utenti simultanei, si prevede di acquistare molta memoria.

Questo è quasi certamente vero dato che SSL richiede un ulteriore passaggio di crittografia che semplicemente non è richiesto da HTTP non-SLL.

I browser possono accettare il protocollo HTTP / 1.1 con HTTP o HTTPS, tuttavia i browser possono gestire solo il protocollo HTTP / 2.0 con HTTPS. Le differenze di protocollo da HTTP / 1.1 a HTTP / 2.0 rendono HTTP / 2.0, in media, 4-5 volte più veloce di HTTP / 1.1. Inoltre, dei siti che implementano HTTPS, la maggior parte lo fa tramite il protocollo HTTP / 2.0. Pertanto, HTTPS è quasi sempre più veloce di HTTP semplicemente a causa del diverso protocollo che generalmente utilizza. Tuttavia, se HTTP su HTTP / 1.1 viene confrontato con HTTPS su HTTP / 1.1, allora HTTP è leggermente più veloce, in media, di HTTPS.

Ecco alcuni confronti che ho eseguito utilizzando Chrome (versione 64):

HTTPS su HTTP / 1.1:

  • Tempo di caricamento medio della pagina di 0,47 secondi
  • 0,05 secondi più lento di HTTP su HTTP / 1.1
  • 0,37 secondi più lento di HTTPS su HTTP / 2.0

HTTP su HTTP / 1.1

  • Tempo di caricamento medio della pagina di 0,42 secondi
  • 0,05 secondi più veloce di HTTPS su HTTP / 1.1
  • 0,32 secondi più lento di HTTPS su HTTP / 2.0

HTTPS su HTTP / 2.0

  • Tempo di caricamento medio di 0,10 secondi
  • 0,32 secondi più veloce di HTTP su HTTP / 1.1
  • 0,37 secondi più veloce di HTTPS su HTTPS / 1.1