Se ogni messaggio TLS deve essere crittografato / decrittografato da entrambi gli host coinvolti nella connessione sicura, questo sta consumando molto tempo della CPU?
Se ogni messaggio TLS deve essere crittografato / decrittografato da entrambi gli host coinvolti nella connessione sicura, questo sta consumando molto tempo della CPU?
Credo che il sito web "È TLS Fast Yet" link possa rispondere alla tua domanda. Ecco una citazione dalla parte superiore della pagina:
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." -- Adam Langley, Google
Ho appena eseguito alcuni test su PC CPU ARM a scheda singola: Come molte domande web sono incappato, anche qui la risposta è "dipende". Ho provato con AB (Apache Benchmark) da PC sulla stessa rete e solo HTTP1.1 (non ho HTTP2 a causa della vecchia versione di Linux / Apache)
Quindi ... se KeepAlive è disabilitato, le prestazioni sono davvero pessime. Il carico della CPU è alto.
Se AB utilizza KeepAlive e Apache utilizza KeepAlive 5 o 10, le prestazioni sono ancora negative. Ancora elevato carico della CPU.
Se KeepAlive è pazzo alto 200 ... le prestazioni sono accettabili.
Quindi, se viene utilizzato il sharding di dominio, le prestazioni HTTPS sono negative. Se solo un dominio viene utilizzato con keepalive elevato, le prestazioni sono accettabili.
La prima stretta di mano per stabilire la connessione fa la differenza.
E sì HTTPS è come prendere medicine se hai freddo, ma devi andare nella prossima città. Se devi andare per ogni pillola alla prossima città e chiedere indicazioni per la prossima farmacia aperta, ti fa più male. Se prendi il pacchetto, è accettabile.
P.S. Immagino che la CPU ARM non abbia accelerazione hardware per la crittografia o non sia abilitata. È come il rendering del software CPU dei giochi rispetto ai core GPU rispetto alla scheda grafica dedicata.
Indipendentemente dalla velocità dei tuoi sistemi: Tempo == Denaro. Tempo CPU == CPU Money
Il problema non è tanto "è la crittografia sotto TLS o SSL veloce", ma piuttosto "quanto processore devi risparmiare?".
La crittografia AES (utilizzata in TLS) è computazionalmente intensiva e costosa. Come una risposta sottolinea qui "SSL / TLS rappresenta meno dell'1% del carico della CPU". Se, ad esempio, rappresentava (essendo generoso) lo 0,5% del carico della CPU e il sistema aveva elaborato 199 connessioni TLS simultanee, il 200 ° avrebbe dovuto attendere perché il processore era al massimo.
Ma 200 non è davvero un numero realistico di connessioni ... Diciamo che sei nei migliori siti web del mondo ... diciamo nella top 0.1%, lassù con la NASA durante Xmas, l'IRS intorno al 15 aprile o solo un giorno medio sul sito web della CNN. Stai parlando da qualche parte ben oltre 70.000.000 di connessioni HTTPS (hit) al giorno. Quindi lascia fare i calcoli ...
70.000.000 di connessioni HTTPS (hit) al giorno 2.916.666 colpi all'ora 48.611 colpi al minuto 810 colpi al secondo .. un colpo è un download di file ...
Quindi se quel sistema sta usando HTTPS invece di HTTP e diamo alla crittografia il beneficio del dubbio che si tratta solo del carico del processore dello 0.5% allora ...
Ciò significa che devi gestire lo stesso traffico con lo stesso fattore di carico di cui abbiamo bisogno per aumentare la capacità del sistema di gestire ... 0,5% * 810 è 4,05 colpi al secondo o 0,5% * 48,611 è 243 colpi al minuto o 0,5% * 2.916.666 sono 14.583 colpi all'ora 0,5% * 70.000.000 è 350.000 visite al giorno
Il costo è di 350.000 accessi al giorno la capacità aggiuntiva necessaria per utilizzare HTTPS.
Ciò si traduce in termini architettonici nell'aggiunta di CPU acceleratore SSL / TLS aggiuntive per mantenere il carico sui server Web attuali. E, naturalmente, qualsiasi architettura di hosting ragionevole deve avere ridondanza in modo da moltiplicare i tempi di costo 2 per l'acceleratore SSL / TLS, quindi aumentare i costi di supporto umano ei costi di aggiornamento tecnico per mantenere adeguatamente il tuo HTTPS
Consideriamo ora se questo è tutto per l'accesso non autenticato ... niente che richiedesse la crittografia per mantenerlo privato ... (come notizie gratuite o materiale di vendita e marketing), hai appena perso tempo e denaro con HTTPS vs non crittografato HTTP.
Ciò che ha più senso è crittografare ciò che deve essere sicuro (accessi, connessioni a contenuto limitato o privato) e lasciare il resto che non deve essere protetto, non crittografato.
Utilizzare arbitrariamente HTTPS per dati pubblici è come prendere un antibiotico ogni volta che si ottiene un raffreddore ... WebMD Cold Guide
Leggi altre domande sui tag performance tls