Cuánto sobrecarga funciona SSL imponer?

Question

Sé que no hay una única duro-y-respuesta rápida, pero ¿hay un genérico orden de magnitud de la estimación de aproximación para la sobrecarga de cifrado de SSL versus sin cifrar socket de comunicación?Estoy hablando sólo acerca de las comunicaciones y de procesamiento de alambre de tiempo, sin contar el nivel de la aplicación de procesamiento.

Actualización

Hay una pregunta acerca de HTTPS versus HTTP, pero estoy interesado en mirar abajo en la pila.

(He sustituido la frase "orden de magnitud" para evitar la confusión;Yo lo estaba usando como informal jerga más que en el formal CompSci sentido.Por supuesto, si me había significaba formalmente, como un verdadero geek, yo habría sido el pensamiento binario en lugar de decimal!;-)

Actualización

Por solicitud de comentario, supongamos que estamos hablando de buen tamaño de los mensajes (rango de 1k-10k) a través de conexiones persistentes.Para el conjunto de conexión y paquete de sobrecarga no son cuestiones importantes.

Answer 1

orden de magnitud:. Cero

En otras palabras, usted no verá su rendimiento reduce a la mitad, o algo parecido, cuando se agrega TLS. Las respuestas a la "duplicar" cuestión se centran en gran medida de rendimiento de las aplicaciones, y cómo se compara con sobrecarga de SSL . Esta pregunta excluye específicamente el procesamiento de aplicaciones, y pretende comparar no SSL a SSL solamente. Si bien tiene sentido tener una visión global del rendimiento cuando se optimiza, eso no es lo que esta pregunta está pidiendo.

La sobrecarga principal de SSL es el apretón de manos. Ahí es donde ocurre la cara criptografía asimétrica. Después de la negociación, se utilizan sistemas de cifrado simétrico relativamente eficientes. Es por eso que puede ser muy útil para permitir que las sesiones SSL para su servicio HTTPS, donde se hacen muchas conexiones. Para una conexión de larga vida, este "efecto final" no es tan significativa, y las sesiones no son tan útiles.

---

Esto es una anécdota interesante. Cuando Google cambió a Gmail utilice HTTPS, no se necesitan recursos adicionales; sin necesidad de hardware de red, no hay nuevos huéspedes. Es sólo aumentó carga de la CPU en aproximadamente un 1%.

Answer 2

I segundo @erickson: La penalización de velocidad de transferencia de datos pura es insignificante. CPU modernas alcanzan un cripto / AES rendimiento de varios cientos de Mbit / s. Así que a menos que esté en el sistema de recursos limitados (teléfono móvil) TLS / SSL es lo suficientemente rápido para arrojando datos alrededor.

Pero hay que tener en cuenta que la encriptación hace que el almacenamiento en caché y balanceo de carga mucho más difícil. Esto podría dar lugar a una enorme pérdida de rendimiento.

Pero configuración de la conexión es realmente un tapón de la demostración para muchas aplicaciones. Del ancho de banda baja, alta pérdida de paquetes, conexiones de alta latencia (dispositivo móvil en el campo) las idas y vueltas adicionales requeridos por TLS podría hacer algo lenta en algo inservible.

Por ejemplo, tuvimos que dejar caer el requisito de cifrado para el acceso a algunas de nuestras aplicaciones web internas -. Ellos donde junto a inutilizable si se utiliza de china

Answer 3

Suponiendo que usted no cuente conexión de la configuración (como se indicó en su actualización), que depende fuertemente en el sistema de cifrado elegido.La sobrecarga de la red (en términos de ancho de banda) van a ser insignificantes.La sobrecarga de la CPU estará dominada por la criptografía.En mi móvil Core i5, me puede cifrar en torno a 250 MB por segundo con RC4 en un solo núcleo. (RC4 es lo que usted debe elegir para obtener el máximo rendimiento.) AES es más lento, proporcionando "sólo" alrededor de 50 MB/s.Por lo tanto, si usted elige correcto sistemas de cifrado, que no logran mantener un único núcleo actual ocupado con el crypto sobrecarga incluso si usted tiene un plenamente de 1 Gbit línea.[Editar:RC4 no debe ser utilizado, ya que no es seguro.Sin embargo, hardware AES de apoyo está presente en muchas Cpu, lo que hace que el cifrado AES muy rápido en este tipo de plataformas.]

El establecimiento de la conexión, sin embargo, es diferente.Dependiendo de la aplicación (por ejemplo,soporte para TLS salida en falso), se añade viajes de ida y vuelta, lo que puede causar notable retraso.Además, caro crypto se lleva a cabo en el primer establecimiento de la conexión (mencionado más arriba de la CPU podría aceptar sólo 14 conexiones por núcleo por segundo si tontamente utilizado 4096 bits y claves de 100 si el uso de claves de 2048 bits).En las conexiones posteriores, anteriores períodos de sesiones, a menudo son reutilizados, evitando el costoso crypto.

Así que, para resumir:

Transferencia en conexión establecida:

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

Primer establecimiento de la conexión:

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

Conexión posterior establecimientos:

• Retraso:de ida y vuelta adicional (no se si una o varias, pueden ser de aplicación-dependiente)
• Ancho de banda:insignificante
• CPU:casi ninguno