Quanto overhead impone SSL?

So che non esiste una risposta semplice e rapida, ma esiste una generica stima approssimativa dell'ordine di grandezza per l'overhead di crittografia di SSL rispetto alla comunicazione socket non crittografata? Sto parlando solo dell'elaborazione delle comunicazioni e del tempo di trasmissione, senza contare l'elaborazione a livello di applicazione.

Aggiornare

C'è una domanda su HTTPS rispetto a HTTP , ma sono interessato a guardare più in basso nello stack.

(Ho sostituito la frase "ordine di grandezza" per evitare confusione; la stavo usando come gergo informale piuttosto che nel senso formale di CompSci. Naturalmente se lo avessi voluto dire formalmente, come un vero geek avrei pensato binario piuttosto che decimale! ;-)

Aggiornare

Per richiesta nel commento, supponiamo che stiamo parlando di messaggi di buone dimensioni (intervallo di 1k-10k) su connessioni persistenti. Pertanto, la configurazione della connessione e l'overhead dei pacchetti non rappresentano problemi significativi.

Ordine di grandezza: zero.

In altre parole, non vedrai il tuo throughput dimezzato o qualcosa di simile quando aggiungi TLS. Le risposte alla domanda "duplicata" si concentrano pesantemente sulle prestazioni dell'applicazione e su come ciò si confronta con l'overhead SSL. Questa domanda esclude specificamente l'elaborazione delle applicazioni e cerca di confrontare solo i non SSL con SSL. Mentre ha senso assumere una visione globale delle prestazioni durante l'ottimizzazione, non è questo che si pone questa domanda.

L'overhead principale di SSL è l'handshake. Ecco dove avviene la costosa crittografia asimmetrica. Dopo la negoziazione, vengono utilizzate cifre simmetriche relativamente efficienti. Ecco perché può essere molto utile abilitare le sessioni SSL per il tuo servizio HTTPS, dove vengono stabilite molte connessioni. Per una connessione di lunga durata, questo "effetto finale" non è così significativo e le sessioni non sono altrettanto utili.

Ecco un aneddoto interessante. Quando Google ha cambiato Gmail per utilizzare HTTPS, non sono state necessarie risorse aggiuntive; nessun hardware di rete, nessun nuovo host. Ha solo aumentato il carico della CPU di circa l'1%.

Secondo secondo @erickson: la pura penalità per la velocità di trasferimento dei dati è trascurabile. Le CPU moderne raggiungono un throughput crypto / AES di diverse centinaia di MBit / s. Pertanto, a meno che non si utilizzi un sistema con risorse limitate (telefono cellulare), TLS / SSL è abbastanza veloce per il trasferimento dei dati.

Tuttavia, tieni presente che la crittografia rende molto più difficile la memorizzazione nella cache e il bilanciamento del carico. Ciò potrebbe comportare un'enorme penalità per le prestazioni.

Ma la configurazione della connessione è davvero un punto fermo per molte applicazioni. Con larghezza di banda ridotta, elevata perdita di pacchetti, connessioni ad alta latenza (dispositivo mobile in campagna) i round trip aggiuntivi richiesti da TLS potrebbero rendere qualcosa di lento in qualcosa di inutilizzabile.

Ad esempio, abbiamo dovuto abbandonare il requisito di crittografia per l'accesso ad alcune delle nostre app Web interne, che erano quasi inutilizzabili se utilizzate dalla Cina.

Supponendo che non si contenga la configurazione della connessione (come indicato nell'aggiornamento), dipende fortemente dalla cifra scelta. L'overhead di rete (in termini di larghezza di banda) sarà trascurabile. Il sovraccarico della CPU sarà dominato dalla crittografia. Sul mio Core i5 mobile, posso crittografare circa 250 MB al secondo con RC4 su un singolo core. (RC4 è ciò che dovresti scegliere per le massime prestazioni.) AES è più lento, fornendo "solo" circa 50 MB / s. Quindi, se scegli le cifre corrette, non riuscirai a tenere occupato un singolo core corrente con l'overhead crittografico anche se hai una linea da 1 Gbit completamente utilizzata. [ Modifica : RC4 non deve essere utilizzato perché non è più sicuro. Tuttavia, il supporto hardware AES è ora presente in molte CPU, il che rende la crittografia AES molto veloce su tali piattaforme.]

L'istituzione della connessione, tuttavia, è diversa. A seconda dell'implementazione (ad es. Supporto per TLS false start), verranno aggiunti round trip, che possono causare notevoli ritardi. Inoltre, la costosa crittografia ha luogo al primo collegamento (la CPU sopra menzionata potrebbe accettare solo 14 connessioni per core al secondo se si utilizzano follemente chiavi a 4096 bit e 100 se si utilizzano chiavi a 2048 bit). Su connessioni successive, le sessioni precedenti vengono spesso riutilizzate, evitando la costosa crittografia.

Quindi, per riassumere:

Trasferimento su connessione stabilita:

• Ritardo: quasi nessuno
• CPU: trascurabile
• Larghezza di banda: trascurabile

Primo collegamento:

• Ritardo: viaggi di andata e ritorno aggiuntivi
• Larghezza di banda: diversi kilobyte (certificati)
• CPU sul client: media
• CPU sul server: alta

Stabilimenti di connessione successivi:

• Ritardo: andata e ritorno aggiuntiva (non sono sicuro se uno o più, potrebbero dipendere dall'implementazione)
• Larghezza di banda: trascurabile
• CPU: quasi nessuna