Ci sono differenze sostanziali nelle prestazioni tra http e https? Mi sembra di ricordare che HTTPS può essere un quinto più veloce di HTTP. Questo è valido con i web server / browser di generazione attuale? In tal caso, ci sono dei white paper a supporto?

C'è una risposta molto semplice a questa: profila le prestazioni del tuo server web per vedere qual è la penalità delle prestazioni per la tua situazione particolare. Esistono diversi strumenti per confrontare le prestazioni di un server HTTP vs HTTPS (vengono in mente JMeter e Visual Studio) 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 fortemente da:

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

In base alla mia esperienza, i server con un elevato contenuto dinamico hanno un impatto minore su HTTPS poiché il tempo impiegato per la crittografia (overhead SSL) è insignificante rispetto al tempo di generazione del contenuto.

I server che si occupano pesantemente di servire un insieme piuttosto piccolo di pagine statiche che possono essere facilmente memorizzate nella memoria cache soffrono di un sovraccarico molto più elevato (in un caso, il throughput è stato gestito su una "intranet").

Modifica: un punto che è stato sollevato da molti altri è che l'handshaking SSL è il costo principale di HTTPS. È corretto, motivo per cui "durata tipica della sessione" e "comportamento di memorizzazione nella cache dei client" sono importanti.

Molte sessioni molto brevi significano che il tempo di handshaking supererà qualsiasi altro fattore di prestazione. Sessioni più lunghe comporteranno il costo dell'handshaking 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, da qualsiasi 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 raggiungere questo obiettivo). Molti browser memorizzano nella cache il contenuto HTTPS per la sessione corrente e spesso volte attraverso le sessioni. L'impatto della non memorizzazione nella cache o della 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 po 'eccessivo. Tuttavia, una volta effettuata l'handshake, viene utilizzata una forma molto veloce di crittografia simmetrica, quindi il sovraccarico è minimo. In conclusione: fare molte brevi richieste 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 una singola stretta di mano 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 davvero come HTTPS aumenterà la tua 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 "leghe" (un round trip, si invia una richiesta, il server invia una risposta), il client non riceverà i dati fino ad almeno 4 leghe (2 round trip) . Quindi, se ci vogliono 100 ms perché un pacchetto si sposti tra il client e il server, la tua prima richiesta HTTPS richiederà almeno 500 ms.

Naturalmente, questo può essere mitigato riutilizzando la connessione HTTPS (cosa che i browser dovrebbero fare), ma spiega una parte di quella fase iniziale quando si carica 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 rispetto a una HTTP.

Misura (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 esiste "netem". Confronta HTTP con HTTPS sulla stessa configurazione.

La latenza può essere in qualche modo mitigata da:

• Garantire che il server utilizzi keepalive HTTP: ciò consente al client di riutilizzare le sessioni SSL, evitando la necessità di un'altra stretta di mano
• Ridurre il numero di richieste al minor numero possibile - combinando le risorse ove possibile (ad es. File con estensione js, CSS) e incoraggiando la memorizzazione nella cache sul lato client
• Ridurre il numero di caricamenti di pagine, ad es. Caricando i dati non richiesti nella pagina (forse in un elemento HTML nascosto) e mostrandoli utilizzando lo script client.

Aggiornamento di dicembre 2014

Puoi facilmente testare la differenza tra le prestazioni HTTP e HTTPS nel tuo browser usando il sito Web Test HTTP vs HTTPS di AnthumChris : “Questa pagina misura il suo tempo di caricamento su connessioni HTTP non sicure e HTTPS crittografate. Entrambe le pagine caricano 360 immagini uniche, non memorizzate nella cache (2,04 MB in totale). "

I risultati potrebbero sorprenderti.

È importante avere una conoscenza aggiornata delle prestazioni HTTPS perché 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 - In arrivo a settembre 2015:

• Let's Encrypt Launch Schedule (16 giu 2015)
• Let's Encrypt Root and Intermediate Certificates (4 giu 2015)
• Progetto di crittografia dell'accordo di abbonamento (21 maggio 2015)

Maggiori informazioni su Twitter: @letsencrypt

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

• TLS è ancora veloce?
• Networking di browser ad alte prestazioni, Capitolo 4: Transport Layer Security
• Overclocking SSL
• Anatomia e prestazioni dell'elaborazione SSL

Per maggiori informazioni sull'importanza dell'utilizzo di HTTPS consultare:

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

Per riassumere, lasciatemi citare Ilya Grigorik : "TLS ha esattamente un problema di prestazioni: non viene utilizzato abbastanza ampiamente. Tutto il resto può essere ottimizzato".

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

L'attuale risposta principale non è completamente corretta.

Come altri hanno sottolineato qui, https richiede l'handshaking e quindi fa più roundtrip TCP / IP.

In un ambiente WAN in genere la latenza diventa il fattore limitante e non l'aumento dell'utilizzo della CPU sul server.

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

Puoi misurarlo facilmente (per il singolo caso utente) con HTTPWatch .

Oltre a tutto ciò che è stato menzionato finora, tieni presente che alcuni (tutti?) Browser web non memorizzano i contenuti memorizzati nella cache ottenuti 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 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. 3des è più costoso di AES, per esempio. Alcuni algoritmi sono più costosi per il codificatore rispetto al decodificatore. Alcuni hanno il costo opposto.

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

Per il traffico Internet incrociato potresti non notare questo costo nella tua velocità di trasmissione dei dati, poiché la larghezza di banda disponibile è troppo bassa. Ma lo noterai sicuramente nell'uso della CPU su un server occupato.

Posso dirti (come utente dialup) che la stessa pagina su SSL è più volte più lenta rispetto al normale HTTP ...

In numerosi casi, l'impatto sulle prestazioni degli handshake SSL sarà mitigato dal fatto che la sessione SSL può essere memorizzata nella cache su entrambe le estremità (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 dispongono inoltre di parametri che consentono di ottimizzare il tempo di memorizzazione nella cache della sessione.

Un altro impatto da considerare è che il contenuto statico offerto tramite 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 mitigato dal fatto che il contenuto statico verrà memorizzato nella cache anche sui desktop, il contenuto statico HTTPS memorizzabile nella cache di Internet Explorer versioni 6 e 7 se non diversamente indicato (Menu Strumenti / Opzioni Internet / Avanzate / Sicurezza / Non salvare 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

Naturalmente questi numeri dipendono da molti fattori, come le prestazioni del computer, la velocità di connessione, il carico del server, il QoS sul percorso (il particolare percorso di rete preso dal browser al server) ma mostra l'idea generale: HTTPS è più lento di HTTP, poiché richiede più operazioni da completare (sincronizzazione dell'handshaking e codifica / decodifica dei dati).

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

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

Dato che 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

Sembra esserci un brutto caso qui: Ajax su wifi congestionato.

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

TLS è ancora veloce? Sì.

• Guarda: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Leggi: https://istlsfastyet.com/

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

CONFRONTO DELLE PRESTAZIONI HTTP VS HTTPS

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

Per comprendere le implicazioni relative alle prestazioni, il diagramma seguente fornisce un'idea di base di ciò che accade sotto copertura quando si effettua una richiesta per una risorsa utilizzando HTTPS.

Come puoi vedere dal diagramma sopra, ci sono alcuni passaggi aggiuntivi che devono essere eseguiti quando si utilizza HTTPS rispetto all'uso 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 passaggio in più rispetto a una richiesta HTTP e purtroppo comporta un certo sovraccarico.

Al fine di comprendere le implicazioni delle prestazioni e vedere di persona se l'impatto sulle prestazioni sarebbe significativo, ho utilizzato questo sito come piattaforma di test. Mi sono diretto su webpagetest.org e ho usato lo strumento di confronto visivo per confrontare il caricamento di questo sito usando HTTPS vs HTTP.

Come puoi vedere da Ecco il video di prova 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 testarlo accuratamente e verificare l'impatto delle prestazioni coinvolto nel passaggio a HTTPS.

C'è un modo per misurare questo. Lo strumento di Apache chiamato jmeter misurerà la velocità effettiva. Se imposti un ampio campionamento del tuo servizio con jmeter, in un ambiente controllato, con e senza SSL, dovresti 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 nelle latenze potrebbe essere appena percettibile a seconda del carico su cui si trovano i server.

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

Se stai gestendo un sito con un gran numero di utenti simultanei, ti aspetti di acquistare molta memoria.

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

L'HTTPS influisce infatti sulla velocità della pagina ...

Le citazioni sopra rivelano la follia di molte persone sulla sicurezza e la velocità del sito. L'handshaking del server HTTPS / SSL crea una fase iniziale di connessione a Internet. C'è un ritardo lento prima che qualcosa inizi a essere visualizzato sullo schermo del browser del tuo visitatore. Questo ritardo viene misurato nelle informazioni Time-to-First-Byte.

L'overhead dell'handshake HTTPS appare nelle informazioni Time-to-First-Byte (TTFB). Il TTFB comune varia da meno di 100 millisecondi (nel migliore dei casi) a oltre 1,5 secondi (nel peggiore dei casi). Ma, naturalmente, con HTTPS è peggio di 500 millisecondi.

Le connessioni 3G wireless di andata e ritorno possono essere di almeno 500 millisecondi. I viaggi extra raddoppiano i ritardi a 1 secondo o più. Questo ha un grande impatto negativo sulle prestazioni mobili. Pessime notizie.

Il mio consiglio, se non si scambiano dati sensibili, allora non è necessario SSL, ma se ti piace un sito Web di e-commerce, puoi semplicemente abilitare HTTPS su alcune pagine in cui vengono scambiati dati sensibili come Login e checkout.

Fonte: Pagepipe

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 sarà 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, HTTP è leggermente più veloce, in media, di HTTPS.

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

HTTPS su HTTP / 1.1:

• Tempo medio di caricamento della pagina 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 medio di caricamento della pagina 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 medio di caricamento 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