Quanto sovraccarico impone SSL?

Question

So che non esiste un'unica risposta definitiva, ma esiste una risposta generica stima dell'ordine di grandezza approssimazione per il sovraccarico di crittografia di SSL rispetto alla comunicazione socket non crittografata?Sto parlando solo dell'elaborazione delle comunicazioni e del tempo di cablaggio, senza contare l'elaborazione a livello di applicazione.

Aggiornamento

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

(Ho sostituito la frase "ordine di grandezza" per evitare confusione;Lo stavo usando come gergo informale piuttosto che nel senso formale di CompSci.Naturalmente se io avevo lo intendevo formalmente, da vero geek avrei pensato in binario anziché in decimale!;-)

Aggiornamento

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 il sovraccarico dei pacchetti non sono problemi significativi.

Answer 1

ordine di grandezza:. A zero

In altre parole, non sarà possibile visualizzare la velocità effettiva tagliato a metà, o qualcosa di simile, quando si aggiunge TLS. Le risposte alla "duplicato" questione concentrarsi pesantemente sulle prestazioni delle applicazioni, e come che confronta a testa SSL . Questa domanda esclude specificamente l'elaborazione delle applicazioni, e cerca di confrontare non SSL a Solo SSL. Mentre ha senso avere una visione globale delle prestazioni quando l'ottimizzazione, non è questo che a questa domanda sta chiedendo.

Il sovraccarico principale della SSL è la stretta di mano. È lì che il costoso crittografia asimmetrica accade. Dopo la negoziazione, sono utilizzati relativamente efficienti algoritmi simmetrici. Ecco perché può essere molto utile per abilitare le sessioni SSL per il servizio HTTPS, dove sono fatte molte connessioni. Per una connessione a lunga durata, questo "end-effetto" non è così significativo, e le sessioni non sono così utili.

---

Ecco un aneddoto interessante. Quando Google acceso a Gmail utilizzare HTTPS, erano tenuti senza risorse aggiuntive; nessun hardware di rete, non nuovi padroni di casa. E 'aumentato solo carico della CPU di circa l'1%.

Answer 2

I secondi @erickson: La pena di velocità di trasferimento dati pura è trascurabile. CPU moderne raggiungono un cripto / AES il throughput di diverse centinaia di Mbit / s. Quindi, a meno che non siete su sistema vincolato risorse (telefono cellulare) TLS / SSL è abbastanza veloce per l'imbracatura dati in giro.

Ma tenere a mente che la crittografia rende caching e bilanciamento del carico molto più difficile. Ciò potrebbe comportare un enorme calo delle prestazioni.

Ma impostazione della connessione è davvero un tappo di spettacolo per molte applicazioni. Sulla larghezza di banda ridotta, elevata perdita di pacchetti, connessioni ad alta latenza (dispositivo mobile in campagna) i roundtrip aggiuntivi previsti dalle TLS possa rendere qualcosa lento in qualcosa inutilizzabile.

Per esempio abbiamo dovuto cadere il requisito di crittografia per l'accesso ad alcune delle nostre applicazioni web interne -. Essi dove accanto al inutilizzabile se usato dalla Cina

Answer 3

Supponendo che non si contenga l'impostazione della connessione (come indicato nell'aggiornamento), dipende fortemente dalla cifra scelta.Il sovraccarico della 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 e fornisce "solo" circa 50 MB/s.Quindi, se scegli le cifre corrette, non riuscirai a mantenere un singolo core attuale occupato con il sovraccarico crittografico anche se disponi di una linea da 1 Gbit completamente utilizzata.[Modificare:RC4 non dovrebbe essere utilizzato perché non è più sicuro.Tuttavia, il supporto hardware AES è ora presente in molte CPU, il che rende la crittografia AES davvero veloce su tali piattaforme.]

La creazione della connessione, tuttavia, è diversa.A seconda dell'implementazione (ad es.supporto per la falsa partenza TLS), aggiungerà viaggi di andata e ritorno, che possono causare ritardi notevoli.Inoltre, la crittografia costosa avviene alla prima connessione (la CPU sopra menzionata può accettare solo 14 connessioni per core al secondo se si utilizzano stupidamente chiavi a 4096 bit e 100 se si utilizzano chiavi a 2048 bit).Nelle connessioni successive, le sessioni precedenti vengono spesso riutilizzate, evitando le costose criptovalute.

Quindi, riassumendo:

Trasferimento su connessione stabilita:

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

Prima realizzazione della connessione:

• Ritardo:ulteriori viaggi di andata e ritorno
• Larghezza di banda:diversi kilobyte (certificati)
• CPU sul client:medio
• CPU sul server:alto

Successive realizzazioni di collegamento:

• Ritardo:andata e ritorno aggiuntivo (non sono sicuro se uno o più, potrebbe dipendere dall'implementazione)
• Larghezza di banda:trascurabile
• PROCESSORE:quasi nessuno