¿Existen diferencias importantes en el rendimiento entre http y https? Me parece recordar haber leído que HTTPS puede ser un quinto más rápido que HTTP. ¿Es esto válido con los servidores web / navegadores de la generación actual? Si es así, ¿hay algún documento técnico que lo respalde?

Hay una respuesta muy simple a esto: Perfile el rendimiento de su servidor web para ver cuál es la penalización de rendimiento para su situación particular. Existen varias herramientas para comparar el rendimiento de un servidor HTTP vs HTTPS (JMeter y Visual Studio vienen a mi mente) y son bastante fáciles de usar.

Nadie puede darle una respuesta significativa sin alguna información sobre la naturaleza de su sitio web, hardware, software y configuración de red.

Como han dicho otros, habrá un cierto nivel de sobrecarga debido al cifrado, pero depende en gran medida de:

• Hardware
• Software de servidor
• Relación de contenido dinámico vs estático
• Distancia del cliente al servidor
• Duración de la sesión típica
• Etc (mi favorito personal)
• Comportamiento de caché de clientes

En mi experiencia, los servidores que tienen mucho contenido dinámico tienden a verse menos afectados por HTTPS porque el tiempo dedicado al cifrado (sobrecarga SSL) es insignificante en comparación con el tiempo de generación de contenido.

Los servidores que tienen un gran volumen de servicio en un conjunto bastante pequeño de páginas estáticas que pueden almacenarse fácilmente en la memoria caché sufren una sobrecarga mucho mayor (en un caso, el rendimiento se obtuvo en una "intranet").

Editar: Un punto que han mencionado varios otros es que el protocolo de enlace SSL es el mayor costo de HTTPS. Eso es correcto, por lo que es importante la "duración de sesión típica" y el "comportamiento de almacenamiento en caché de los clientes".

Muchas sesiones muy cortas significan que el tiempo de apretón de manos abrumará cualquier otro factor de rendimiento. Sesiones más largas significarán que se incurrirá en el costo del reconocimiento al comienzo de la sesión, pero las solicitudes posteriores tendrán una sobrecarga relativamente baja.

El almacenamiento en caché del cliente se puede realizar en varios pasos, desde un servidor proxy a gran escala hasta el caché del navegador individual. En general, el contenido HTTPS no se almacenará en caché en un caché compartido (aunque algunos servidores proxy pueden explotar un comportamiento de tipo intermediario para lograr esto). Muchos navegadores almacenan en caché el contenido HTTPS para la sesión actual y, a menudo, en varias sesiones. El impacto del no almacenamiento en caché o menos almacenamiento en caché significa que los clientes recuperarán el mismo contenido con mayor frecuencia. Esto da como resultado más solicitudes y ancho de banda para atender a la misma cantidad de usuarios.

HTTPS requiere un apretón de manos inicial que puede ser muy lento. La cantidad real de datos transferidos como parte del apretón de manos no es enorme (por lo general, menos de 5 kB), pero para solicitudes muy pequeñas, esto puede ser una sobrecarga. Sin embargo, una vez que se realiza el protocolo de enlace, se utiliza una forma muy rápida de cifrado simétrico, por lo que la sobrecarga es mínima. En pocas palabras: realizar muchas solicitudes cortas a través de HTTPS será un poco más lento que HTTP, pero si transfiere una gran cantidad de datos en una sola solicitud, la diferencia será insignificante.

Sin embargo, keepalive es el comportamiento predeterminado en HTTP / 1.1, por lo que hará un solo apretón de manos y luego muchas solicitudes a través de la misma conexión. Esto hace una diferencia significativa para HTTPS. Probablemente debería perfilar su sitio (como lo han sugerido otros) para asegurarse, pero sospecho que la diferencia de rendimiento no será notable.

Para comprender realmente cómo HTTPS aumentará su latencia, debe comprender cómo se establecen las conexiones HTTPS. Aquí hay un buen diagrama . La clave es que, en lugar de que el cliente obtenga los datos después de 2 "tramos" (un viaje de ida y vuelta, envía una solicitud, el servidor envía una respuesta), el cliente no obtendrá datos hasta al menos 4 tramos (2 viajes de ida y vuelta) . Entonces, si se necesitan 100 ms para que un paquete se mueva entre el cliente y el servidor, su primera solicitud HTTPS tomará al menos 500 ms.

Por supuesto, esto puede mitigarse reutilizando la conexión HTTPS (lo que deberían hacer los navegadores), pero explica parte de ese bloqueo inicial al cargar un sitio web HTTPS.

La sobrecarga NO se debe al cifrado. En una CPU moderna, el cifrado requerido por SSL es trivial.

La sobrecarga se debe a los apretones de manos SSL, que son largos y aumentan drásticamente la cantidad de viajes de ida y vuelta necesarios para una sesión HTTPS sobre una HTTP.

Mida (usando una herramienta como Firebug) los tiempos de carga de la página mientras el servidor está al final de un enlace simulado de alta latencia. Existen herramientas para simular un enlace de alta latencia: para Linux hay "netem". Compare HTTP con HTTPS en la misma configuración.

La latencia puede mitigarse hasta cierto punto mediante:

• Asegurarse de que su servidor está utilizando HTTP keepalives: esto permite al cliente reutilizar sesiones SSL, lo que evita la necesidad de otro apretón de manos
• Reducir la cantidad de solicitudes a la menor cantidad posible, combinando recursos donde sea posible (por ejemplo .js incluyen archivos, CSS) y fomentando el almacenamiento en caché del lado del cliente
• Reduzca la cantidad de cargas de la página, por ejemplo, cargando datos no necesarios en la página (tal vez en un elemento HTML oculto) y luego mostrándolos usando el script del cliente.

Actualización de diciembre de 2014

Puede probar fácilmente la diferencia entre el rendimiento de HTTP y HTTPS en su propio navegador utilizando el sitio web de prueba HTTP vs HTTPS de AnthumChris : “Esta página mide su tiempo de carga sobre HTTP no seguro y conexiones HTTPS cifradas. Ambas páginas cargan 360 imágenes únicas, no almacenadas en caché (2,04 MB en total) ".

Los resultados pueden sorprenderle.

Es importante tener un conocimiento actualizado sobre el rendimiento de HTTPS porque Let's Encrypt Certificate Authority comenzará a emitir certificados SSL gratuitos, automatizados y abiertos en el verano de 2015, gracias a Mozilla, Akamai, Cisco, Electronic Frontier Foundation e IdenTrust.

Actualización de junio de 2015

Actualizaciones sobre Let's Encrypt - Llegando a septiembre de 2015:

• Cifre el calendario de lanzamiento (16 de junio de 2015)
• Cifremos los certificados raíz e intermedios (4 de junio de 2015)
• Proyecto de acuerdo de suscripción de Let's Encrypt (21 de mayo de 2015)

Más información en Twitter: @letsencrypt

Para obtener más información sobre HTTPS y el rendimiento SSL / TLS, consulte:

• ¿TLS es rápido todavía?
• Redes de navegador de alto rendimiento, Capítulo 4: Seguridad de la capa de transporte
• SSL de overclocking
• Anatomía y rendimiento del procesamiento SSL

Para obtener más información sobre la importancia de usar HTTPS, consulte:

• ¿Por qué HTTPS para todo? (El estándar solo HTTPS)
• Encriptemos (Grupo de Investigación de Seguridad de Internet)
• HTTPS en todas partes (Electronic Frontier Foundation)

Para resumir, permítanme citar a Ilya Grigorik : "TLS tiene exactamente un problema de rendimiento: no se usa lo suficiente. Todo lo demás se puede optimizar".

Gracias a Chris , autor del benchmark HTTP vs HTTPS Test , por sus comentarios a continuación.

La respuesta principal actual no es completamente correcta.

Como otros han señalado aquí, https requiere un protocolo de enlace y, por lo tanto, requiere más viajes de ida y vuelta TCP / IP.

Por lo general, en un entorno WAN, la latencia se convierte en el factor limitante y no en el mayor uso de la CPU en el servidor.

Solo tenga en cuenta que la latencia de Europa a los EE. UU. Puede ser de alrededor de 200 ms (tiempo de viaje).

Puede medir esto fácilmente (para el caso de un solo usuario) con HTTPWatch .

Además de todo lo mencionado hasta ahora, tenga en cuenta que algunos (¿todos?) Navegadores web no almacenan contenido en caché obtenido a través de HTTPS en el disco duro local por razones de seguridad. Esto significa que, desde la perspectiva del usuario, las páginas con mucho contenido estático se cargarán más lentamente después de reiniciar el navegador, y desde la perspectiva de su servidor, el volumen de solicitudes de contenido estático a través de HTTPS será mayor de lo que hubiera sido a través de HTTP.

No hay una sola respuesta para esto.

El cifrado siempre consumirá más CPU. Esto puede descargarse en hardware dedicado en muchos casos, y el costo variará según el algoritmo seleccionado. 3des es más caro que AES, por ejemplo. Algunos algoritmos son más caros para el cifrador que el descifrador. Algunos tienen el costo opuesto.

Más caro que la criptografía masiva es el costo del apretón de manos. Las nuevas conexiones consumirán mucha más CPU. Esto se puede reducir con la reanudación de la sesión, a costa de mantener los viejos secretos de la sesión hasta que caduquen. Esto significa que las solicitudes pequeñas de un cliente que no regresa por más son las más caras.

Para el tráfico cruzado de Internet, es posible que no note este costo en su velocidad de datos, porque el ancho de banda disponible es demasiado bajo. Pero sin duda lo notará en el uso de la CPU en un servidor ocupado.

Puedo decirle (como usuario de acceso telefónico) que la misma página a través de SSL es varias veces más lenta que a través de HTTP normal ...

En varios casos, el impacto en el rendimiento de los protocolos de enlace SSL se verá mitigado por el hecho de que la sesión SSL se puede almacenar en caché en ambos extremos (escritorio y servidor). En máquinas con Windows, por ejemplo, la sesión SSL se puede almacenar en caché por hasta 10 horas. Consulte http://support.microsoft.com/kb/247658/EN-US . Algunos aceleradores SSL también tendrán parámetros que le permitirán ajustar el tiempo de almacenamiento en caché de la sesión.

Otro impacto a tener en cuenta es que el contenido estático que se sirve a través de HTTPS no será almacenado en caché por servidores proxy, y esto puede reducir el rendimiento en varios usuarios que acceden al sitio a través del mismo proxy. Esto puede mitigarse por el hecho de que el contenido estático también se almacenará en caché en los escritorios, las versiones 6 y 7 de Internet Explorer pueden almacenar en caché contenido estático HTTPS a menos que se indique lo contrario (Menú Herramientas / Opciones de Internet / Avanzado / Seguridad / No guardar páginas cifradas al disco).

Hice un pequeño experimento y obtuve un 16% de diferencia de tiempo para la misma imagen de flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

Por supuesto, estos números dependen de muchos factores, como el rendimiento de la computadora, la velocidad de conexión, la carga del servidor, la QoS en la ruta (la ruta de red particular tomada del navegador al servidor), pero muestra la idea general: HTTPS es más lento que HTTP, ya que solicita más operaciones para completar (protocolo de enlace SSL y codificación / decodificación de datos).

Aquí hay un gran artículo (un poco antiguo, pero aún excelente) sobre la latencia de protocolo de enlace SSL. Me ayudó a identificar SSL como la principal causa de lentitud para los clientes que usaban mi aplicación a través de conexiones lentas a Internet:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Como estoy investigando el mismo problema para mi proyecto, encontré estas diapositivas. Mayor pero interesante:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Parece que hay un caso extremo desagradable aquí: Ajax sobre wifi congestionado.

Ajax generalmente significa que KeepAlive ha excedido el tiempo de espera después de unos 20 segundos. Sin embargo, el wifi significa que la conexión ajax (idealmente rápida) tiene que hacer múltiples viajes de ida y vuelta. Peor aún, el wifi a menudo pierde paquetes y hay retransmisiones TCP. ¡En este caso, HTTPS funciona realmente muy mal!

¿TLS es rápido todavía? Si.

• Ver: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Leer: https://istlsfastyet.com/

Hay muchos proyectos por ahí que tienen como objetivo difuminar las líneas y hacer HTTPS igual de rápido. Como SPDY y mod-spdy .

COMPARACIÓN DE RENDIMIENTO HTTP VS HTTPS

Siempre he asociado HTTPS con tiempos de carga de página más lentos en comparación con HTTP antiguo simple. Como desarrollador web, el rendimiento de la página web es importante para mí y cualquier cosa que disminuya el rendimiento de mis páginas web es un no-no.

Para comprender las implicaciones de rendimiento involucradas, el siguiente diagrama le brinda una idea básica de lo que sucede debajo del capó cuando realiza una solicitud de un recurso utilizando HTTPS.

Como puede ver en el diagrama anterior, hay algunos pasos adicionales que deben realizarse cuando se usa HTTPS en comparación con HTTP simple. Cuando realiza una solicitud utilizando HTTPS, debe darse un apretón de manos para verificar la autenticidad de la solicitud. Este apretón de manos es un paso adicional en comparación con una solicitud HTTP y desafortunadamente incurre en una sobrecarga.

Para comprender las implicaciones de rendimiento y ver por mí mismo si el impacto en el rendimiento sería significativo o no, utilicé este sitio como plataforma de prueba. Me dirigí a webpagetest.org y usé la herramienta de comparación visual para comparar la carga de este sitio usando HTTPS vs HTTP.

Como puede ver aquí, el resultado del video de prueba usando HTTPS tuvo un impacto en los tiempos de carga de mi página, sin embargo, la diferencia es insignificante y solo noté una diferencia de 300 milisegundos. Es importante tener en cuenta que estos tiempos dependen de muchos factores, como el rendimiento de la computadora, la velocidad de conexión, la carga del servidor y la distancia del servidor.

Su sitio puede ser diferente, y es importante probarlo a fondo y verificar el impacto en el rendimiento que implica cambiar a HTTPS.

Hay una manera de medir esto. La herramienta de apache llamada jmeter medirá el rendimiento. Si configura una muestra grande de su servicio con jmeter, en un entorno controlado, con y sin SSL, debe obtener una comparación precisa del costo relativo. Estaría interesado en sus resultados.

HTTPS tiene sobrecarga de cifrado / descifrado, por lo que siempre será un poco más lento. La terminación de SSL requiere mucha CPU. Si tiene dispositivos para descargar SSL, la diferencia en las latencias puede ser apenas perceptible dependiendo de la carga de sus servidores.

Una diferencia de rendimiento más importante es que una sesión HTTPS está abierta mientras el usuario está conectado. Una 'sesión' HTTP dura solo para una solicitud de un solo elemento.

Si está ejecutando un sitio con una gran cantidad de usuarios concurrentes, espere comprar mucha memoria.

Es casi seguro que esto será cierto dado que SSL requiere un paso adicional de cifrado que simplemente no es requerido por HTTP no SLL.

El HTTPS de hecho afecta la velocidad de la página ...

Las citas anteriores revelan la tontería de muchas personas sobre la seguridad y la velocidad del sitio. El protocolo de enlace del servidor HTTPS / SSL crea un bloqueo inicial al realizar conexiones a Internet. Hay un retraso lento antes de que algo comience a mostrarse en la pantalla del navegador de su visitante. Este retraso se mide en información de tiempo hasta el primer byte.

La sobrecarga del protocolo de enlace HTTPS aparece en la información de Tiempo hasta el primer byte (TTFB). El TTFB común varía de menos de 100 milisegundos (mejor caso) a más de 1,5 segundos (peor caso). Pero, por supuesto, con HTTPS es 500 milisegundos peor.

Las conexiones inalámbricas 3G de ida y vuelta pueden ser de 500 milisegundos o más. Los viajes adicionales retrasan el doble a 1 segundo o más. Este es un gran impacto negativo en el rendimiento móvil. Muy malas noticias.

Mi consejo, si no está intercambiando datos confidenciales, entonces no necesita SSL en absoluto, pero si le gusta un sitio web de comercio electrónico, entonces puede habilitar HTTPS en ciertas páginas donde se intercambian datos confidenciales como Iniciar sesión y finalizar la compra.

Fuente: Pagepipe

Los navegadores pueden aceptar el protocolo HTTP / 1.1 con HTTP o HTTPS, sin embargo, los navegadores solo pueden manejar el protocolo HTTP / 2.0 con HTTPS. Las diferencias de protocolo de HTTP / 1.1 a HTTP / 2.0 hacen que HTTP / 2.0, en promedio, sea 4-5 veces más rápido que HTTP / 1.1. Además, de los sitios que implementan HTTPS, la mayoría lo hace a través del protocolo HTTP / 2.0. Por lo tanto, HTTPS casi siempre será más rápido que HTTP simplemente debido al protocolo diferente que generalmente usa. Sin embargo, si se compara HTTP sobre HTTP / 1.1 con HTTPS sobre HTTP / 1.1, entonces HTTP es ligeramente más rápido, en promedio, que HTTPS.

Aquí hay algunas comparaciones que ejecuté usando Chrome (Ver. 64):

HTTPS sobre HTTP / 1.1:

• 0.47 segundos de tiempo promedio de carga de página
• 0.05 segundos más lento que HTTP sobre HTTP / 1.1
• 0.37 segundos más lento que HTTPS sobre HTTP / 2.0

HTTP sobre HTTP / 1.1

• 0.42 segundos de tiempo promedio de carga de página
• 0.05 segundos más rápido que HTTPS sobre HTTP / 1.1
• 0.32 segundos más lento que HTTPS sobre HTTP / 2.0

HTTPS sobre HTTP / 2.0

• 0.10 segundos de tiempo de carga promedio
• 0.32 segundos más rápido que HTTP sobre HTTP / 1.1
• 0.37 segundos más rápido que HTTPS sobre HTTPS / 1.1