performance http https

performance - Rendimiento HTTP vs HTTPS



(21)

COMPARACIÓN DE RENDIMIENTO DE HTTP VS HTTPS

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

Para comprender las implicaciones del rendimiento involucrado, el diagrama a continuación 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 llevarse a cabo cuando se usa HTTPS en comparación con el uso de HTTP simple. Cuando realiza una solicitud utilizando HTTPS, debe producirse un protocolo de enlace para verificar la autenticidad de la solicitud. Este apretón de manos es un paso adicional en comparación con una solicitud HTTP y, lamentablemente, incurre en algunos gastos generales.

Con el fin de comprender las implicaciones del rendimiento y ver por mí mismo si el impacto del 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 utilizando HTTPS vs HTTP.

Como se puede ver en Aquí, el resultado de la prueba de video 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 del equipo, la velocidad de conexión, la carga del servidor y la distancia del servidor.

Su sitio puede ser diferente, y es importante probar su sitio a fondo y verificar el impacto en el rendimiento involucrado en el cambio a HTTPS.

¿PODEMOS MEJORAR EL RENDIMIENTO? Visite aquí para obtener información detallada

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

Actualización de Diciembre 2014

Puede probar fácilmente la diferencia entre el rendimiento 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 conexiones HTTP no seguras y conexiones HTTPS cifradas. Ambas páginas cargan 360 imágenes únicas, sin caché (2.04 MB en total) ".

Los resultados pueden sorprenderle.

Es importante tener un conocimiento actualizado sobre el rendimiento de HTTPS porque la Autoridad de Certificación Let''s Encrypt 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 ​​2015

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

Más información en Twitter: @letsencrypt

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

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

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

Gracias a Chris , autor de la prueba de prueba HTTP vs HTTPS , por sus comentarios a continuación.

Además de todo lo mencionado hasta ahora, tenga en cuenta que algunos (¿todos?) Navegadores web no almacenan el contenido almacenado 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, parecerá que 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 sobre HTTPS será superior al que habría tenido sobre HTTP.

Aquí hay un gran artículo (un poco viejo, pero aún así excelente) sobre la latencia del protocolo 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 de Internet lentas:

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

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

Otro impacto a considerar es que el contenido estático servido a través de HTTPS no será almacenado en caché por los servidores proxy, y esto puede reducir el rendimiento de varios usuarios que acceden al sitio a través del mismo proxy. Esto se puede mitigar 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 almacenarán el contenido estático HTTPS en caché a menos que se indique lo contrario (Menú Herramientas / Opciones de Internet / Avanzado / Seguridad / No guardar páginas cifradas a disco).

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

HTTPS requiere un saludo 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 un poco de sobrecarga. Sin embargo, una vez que se hace el apretón de manos, 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 muchos 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 saludo y luego un montón de solicitudes a través de la misma conexión. Esto hace una diferencia significativa para HTTPS. Probablemente debería hacer un perfil de su sitio (como han sugerido otros) para asegurarse, pero sospecho que la diferencia de rendimiento no se notará.

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

Hay una manera de medir esto. La herramienta de apache llamada jmeter medirá el rendimiento. Si configura una gran muestra 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.

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 la mente) y son bastante fáciles de usar.

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

Como han dicho otros, habrá algún nivel de sobrecarga debido al cifrado, pero depende en gran medida de:

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

En mi experiencia, los servidores que son pesados ​​en contenido dinámico tienden a verse menos afectados por HTTPS porque el tiempo empleado en cifrar (sobrecarga de SSL) es insignificante en comparación con el tiempo de generación de contenido.

Los servidores que son pesados ​​en el servicio de 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 realizó en una "intranet").

Edición: un punto que ha sido mencionado por varios otros es que el protocolo SSL es el mayor costo de HTTPS. Eso es correcto, por lo que la "duración típica de la sesión" y el "comportamiento de almacenamiento en caché de los clientes" son importantes.

Muchas sesiones muy cortas significan que el tiempo de apretón de manos abrumará cualquier otro factor de rendimiento. Las sesiones más largas significarán que se incurrirá en el costo de intercambio al inicio de la sesión, pero las solicitudes posteriores tendrán gastos generales relativamente bajos.

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 una memoria caché compartida (aunque algunos servidores proxy pueden explotar un comportamiento de tipo man-in-the-middle para lograr esto). Muchos navegadores almacenan en caché el contenido HTTPS para la sesión actual y, a menudo, en las sesiones. El impacto del no almacenamiento en caché o menos almacenamiento en caché significa que los clientes recuperarán el mismo contenido con más frecuencia. Esto resulta en más solicitudes y ancho de banda para dar servicio al mismo número de usuarios.

Hice un pequeño experimento y obtuve una diferencia de tiempo del 16% 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 del equipo, 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 Requiere más operaciones para completar (SSL handshaking y codificación / decodificación de datos).

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

La sobrecarga se debe a los acuerdos de SSL, que son largos y aumentan drásticamente el número de viajes de ida y vuelta necesarios para una sesión HTTPS a través de una HTTP.

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

La latencia se puede mitigar en cierta medida mediante:

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

Los navegadores pueden aceptar el protocolo HTTP / 1.1 con HTTP o HTTPS, pero 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 de 4 a 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 HTTP sobre HTTP / 1.1 se compara con HTTPS sobre HTTP / 1.1, entonces HTTP es un poco más rápido, en promedio, que HTTPS.

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

HTTPS sobre HTTP / 1.1:

  • Tiempo promedio de carga de la página de 0.47 segundos.
  • 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 la 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

No hay una sola respuesta para esto.

El cifrado siempre consumirá más CPU. Esto se puede descargar a 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 para el descifrador. Algunos tienen el costo opuesto.

Más caro que el criptográfico a granel es el costo de apretón de manos. Las nuevas conexiones consumirán mucho más CPU. Esto se puede reducir con la reanudación de la sesión, al costo de mantener los viejos secretos de la sesión hasta que caduquen. Esto significa que las solicitudes más pequeñas de un cliente que no vuelve por más son las más caras.

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

Para comprender realmente cómo HTTPS aumentará su latencia, debe comprender cómo se establecen las conexiones HTTPS. Aquí hay un bonito 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, usted 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 tarda 100 ms para que un paquete se mueva entre el cliente y el servidor, su primera solicitud de HTTPS tomará al menos 500 ms.

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

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

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

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

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

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

La respuesta principal actual no es completamente correcta.

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

Normalmente, en un entorno WAN, la latencia se convierte en el factor limitante y no en el aumento del 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 ida y vuelta).

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