Si cada mensaje TLS tiene que ser cifrado / descifrado por los dos hosts involucrados en la conexión segura, ¿esto consume mucho tiempo de CPU?
Si cada mensaje TLS tiene que ser cifrado / descifrado por los dos hosts involucrados en la conexión segura, ¿esto consume mucho tiempo de CPU?
Creo que el sitio web "TLS Fast Yet Yet" enlace puede responder a su pregunta. Aquí hay una cita de la parte superior de la página:
"En nuestras máquinas frontend de producción, SSL / TLS representa menos del 1% de la carga de la CPU, menos de 10 KB de memoria por conexión y menos del 2% de la sobrecarga de la red. Muchas personas creen que SSL / TLS requiere "Mucho tiempo de CPU y esperamos que los números anteriores ayuden a disipar eso". - Adam Langley, Google
Acabo de realizar algunas pruebas en una PC con CPU ARM de placa única: Como muchas preguntas de la web me tropecé, también aquí la respuesta es "depende". Probé con AB (Apache Benchmark) desde una PC en la misma red y solo HTTP1.1 (no tengo HTTP2 debido a la versión antigua de Linux / Apache)
Entonces ... si KeepAlive está deshabilitado, el rendimiento es realmente malo. La carga de CPU es alta.
Si AB usa KeepAlive y Apache usa KeepAlive 5 o 10, el rendimiento sigue siendo malo. Todavía alta carga de CPU.
Si KeepAlive es increíblemente alto 200 ... el rendimiento es aceptable.
Por lo tanto, si se usa la fragmentación del dominio, el rendimiento de HTTPS es malo. Si solo se usa un dominio con alto nivel de actividad, se acepta el rendimiento.
El primer apretón de manos para establecer la conexión hace la diferencia.
Y sí, el HTTPS es como tomar medicamentos si tienes frío, pero tener que viajar a la siguiente ciudad. Si tiene que ir por cada píldora a la siguiente ciudad y pedir direcciones a la próxima farmacia abierta, le duele más. Si tomas el paquete, es aceptable.
p.s. Supongo que la CPU ARM no tiene aceleración de hardware para el cifrado o no está habilitada. Es como la representación del software de la CPU de los juegos frente a los núcleos de GPU frente a la tarjeta gráfica dedicada.
No importa qué tan rápido sean sus sistemas: Tiempo == Dinero. Tiempo de CPU == CPU Money
El problema no es tanto "es rápido el cifrado bajo TLS o SSL", sino más bien "¿cuánto procesador tiene de sobra?".
El cifrado AES (utilizado en TLS) es computacionalmente intensivo y costoso. Como respuesta, aquí se señala "Las cuentas SSL / TLS para menos del 1% de la carga de la CPU". Si, por ejemplo, representara (siendo generoso) el 0,5% de la carga de la CPU y el sistema tuviera 199 conexiones TLS simultáneas en proceso, la 200a tendría que esperar porque el procesador tenía un límite máximo.
Pero 200 no es realmente un número realista de conexiones ... Digamos que se encuentra en los sitios web más importantes del mundo ... digamos en el 0,1% superior, con la NASA durante Navidad, el IRS alrededor del 15 de abril o simplemente un día promedio en el sitio web de CNN. Usted está hablando en algún lugar más allá de 70,000,000 conexiones HTTPS (visitas) por día. Así que vamos a hacer los cálculos ...
70,000,000 conexiones HTTPS (visitas) al día son 2,916,666 hits por hora 48,611 hits por minuto 810 hits por segundo ... un hit es una descarga de archivo ...
Entonces, si ese sistema está utilizando HTTPS en lugar de HTTP y le damos al cifrado el beneficio de la duda de que es solo un 0,5% de carga del procesador, entonces ...
Eso significa que usted debe manejar el mismo tráfico en el mismo factor de carga que necesitamos para aumentar la capacidad del sistema para manejar ... 0.5% * 810 es 4.05 hits por segundo o 0.5% * 48,611 es de 243 hits por minuto o 0.5% * 2,916,666 es 14,583 visitas por hora 0.5% * 70,000,000 son 350,000 visitas por día
El costo es de 350,000 visitas por día a la capacidad adicional necesaria para usar HTTPS.
Esto se traduce en términos arquitectónicos en la adición de CPUs de aceleración SSL / TLS adicionales para mantener la carga fuera de los servidores web reales. Y, por supuesto, cualquier arquitectura de hosting razonable debe tener redundancia, de modo que multiplique el costo de la caja del acelerador SSL / TLS por 2, luego agregue tanto los costos de soporte humano como los costos de actualización de la tecnología para mantener adecuadamente sus HTTPS
Ahora, considere si esto es todo para el acceso no autenticado ... nada que requiera cifrado para mantenerlo en privado ... (como noticias gratuitas o material de ventas y marketing), simplemente perdió su tiempo y dinero con HTTPS vs sin cifrar HTTP.
Lo que tiene más sentido es cifrar lo que debe ser seguro (inicios de sesión, conexiones a contenido restringido o privado) y dejar el resto que no necesita estar seguro, sin cifrar.
El uso arbitrario de HTTPS para datos públicos es como tomar un antibiótico cada vez que se resfríe ... WebMD Cold Guide
Lea otras preguntas en las etiquetas tls performance