performance - ¿Cuánta sobrecarga impone SSL?

sockets overhead

Question

Sé que no hay una única respuesta rápida, pero ¿existe una aproximación genérica de estimación de orden de magnitud para la sobrecarga de cifrado de SSL frente a la comunicación de socket no encriptada? Estoy hablando solo del procesamiento de comunicación y el tiempo de conexión, sin contar el procesamiento a nivel de aplicación.

Actualizar

Hay una pregunta sobre HTTPS versus HTTP , pero estoy interesado en buscar más abajo en la pila.

(Reemplacé la frase "orden de magnitud" para evitar confusiones, la usaba como una jerga informal en lugar de formal en el sentido de CompSci. Por supuesto, si lo hubiera querido decir formalmente, como un verdadero friki, habría estado pensando en binario en lugar de decimal! ;-)

Actualizar

Por solicitud en el comentario, supongamos que estamos hablando de mensajes de buen tamaño (rango de 1k-10k) sobre las conexiones persistentes. Así que la configuración de la conexión y la sobrecarga del paquete no son problemas importantes.

Answer 1

Orden de magnitud: cero.

En otras palabras, no verá su rendimiento reducido a la mitad, ni nada por el estilo, cuando agrega TLS. Las respuestas a la pregunta "duplicada" se centran en gran medida en el rendimiento de la aplicación y en cómo se compara con la sobrecarga de SSL. Esta pregunta excluye específicamente el procesamiento de aplicaciones, y busca comparar solo SSL no SSL. Si bien tiene sentido tener una visión global del rendimiento al optimizar, eso no es lo que esta pregunta está haciendo.

La sobrecarga principal de SSL es el apretón de manos. Ahí es donde sucede la costosa criptografía asimétrica. Después de la negociación, se usan cifras simétricas relativamente eficientes. Es por eso que puede ser muy útil habilitar sesiones SSL para su servicio HTTPS, donde se realizan muchas conexiones. Para una conexión duradera, este "efecto final" no es tan significativo, y las sesiones no son tan útiles.

Aquí hay una anécdota interesante. Cuando Google cambió a Gmail para usar HTTPS, no se requirieron recursos adicionales; sin hardware de red, sin nuevos hosts. Solo aumentó la carga de la CPU en aproximadamente un 1%.

Answer 2

Suponiendo que no cuente la configuración de la conexión (como indicó en su actualización), depende en gran medida del cifrado elegido. La sobrecarga de red (en términos de ancho de banda) será insignificante. La sobrecarga de la CPU estará dominada por la criptografía. En mi móvil Core i5, puedo encriptar alrededor de 250 MB por segundo con RC4 en un solo núcleo. (RC4 es lo que debe elegir para obtener el máximo rendimiento.) AES es más lento, proporcionando "solo" alrededor de 50 MB / s. Por lo tanto, si elige las cifras correctas, no podrá mantener ocupado un solo núcleo actual con la sobrecarga de cifrado, incluso si tiene una línea de 1 Gb totalmente utilizada. [ Editar : RC4 no se debe usar porque ya no es seguro. Sin embargo, el soporte de hardware de AES ahora está presente en muchas CPU, lo que hace que el cifrado AES sea realmente rápido en dichas plataformas.]

El establecimiento de la conexión, sin embargo, es diferente. Dependiendo de la implementación (por ejemplo, compatibilidad con el inicio en falso de TLS), agregará viajes de ida y vuelta, lo que puede ocasionar retrasos notorios. Además, la criptografía costosa se lleva a cabo en el primer establecimiento de conexión (la CPU mencionada anteriormente solo podía aceptar 14 conexiones por núcleo por segundo si usabas tontamente las claves de 4096 bits y 100 si usabas claves de 2048 bits). En conexiones posteriores, las sesiones anteriores a menudo se reutilizan, evitando la costosa criptografía.

Entonces, para resumir:

Transferencia en la conexión establecida:

• Retraso: casi ninguno
• CPU: insignificante
• Ancho de banda: insignificante

Primer establecimiento de conexión:

• Retraso: viajes de ida y vuelta adicionales
• Ancho de banda: varios kilobytes (certificados)
• CPU en el cliente: medio
• CPU en el servidor: alta

Establecimientos de conexión posteriores:

• Retardo: viaje de ida y vuelta adicional (no estoy seguro si uno o varios, pueden depender de la implementación)
• Ancho de banda: insignificante
• CPU: casi ninguno

Answer 3

Yo segundo @erickson: la multa de velocidad de transferencia de datos pura es insignificante. Las CPU modernas alcanzan un rendimiento de cifrado / AES de varios cientos de MBit / s. Por lo tanto, a menos que esté en un sistema con recursos limitados (teléfono móvil), TLS / SSL es lo suficientemente rápido como para transferir datos.

Pero tenga en cuenta que el cifrado hace que el almacenamiento en caché y el equilibrio de carga sean mucho más difíciles. Esto podría resultar en una gran penalización de rendimiento.

Pero la configuración de la conexión es realmente un stopper para muchas aplicaciones. En bajas anchuras de banda, altas pérdidas de paquetes, conexiones de alta latencia (dispositivos móviles en el campo), los recorridos de ida adicionales requeridos por TLS pueden convertir algo lento en algo inutilizable.

Por ejemplo, tuvimos que eliminar el requisito de encriptación para acceder a algunas de nuestras aplicaciones web internas; están inutilizadas si se usan desde China.