Rendimiento HTTP vs HTTPS

¿Hay 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 navegadores / servidores web de la generación actual? Si es así, ¿hay documentos técnicos que lo respalden?

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 (me vienen a la mente JMeter y Visual Studio) y son bastante fáciles de usar.

Nadie puede darle 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á cierto nivel de sobrecarga debido al cifrado, pero depende en gran medida de:

  • Hardware
  • Software de servidor
  • Relación de contenido dynamic frente a estático
  • Distancia del cliente al servidor
  • Longitud de sesión típica
  • Etc (mi favorito personal)
  • Comportamiento de almacenamiento en caché de los clientes

En mi experiencia, los servidores que tienen mucho contenido dynamic tienden a verse menos afectados por HTTPS porque el tiempo dedicado al cifrado (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 memoria caché tienen una sobrecarga mucho mayor (en un caso, el rendimiento se obtuvo en una “intranet”).

Editar: Un punto que ha sido mencionado por muchos otros es que el protocolo de enlace 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 caché de los clientes” son importantes.

Muchas sesiones muy cortas significan que el tiempo de toma de contacto superará cualquier otro factor de rendimiento. Las sesiones más largas significarán que se incurrirá en el costo del apretón de manos 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 man-in-the-middle para lograr esto). Muchos navegadores almacenan en caché contenido HTTPS para la sesión actual y muchas veces en todas las sesiones. El impacto de no 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 handshake no es enorme (por debajo de 5 kB típicamente), pero para solicitudes muy pequeñas, esto puede ser bastante costoso. Sin embargo, una vez que se realiza el protocolo de enlace, se utiliza una forma muy rápida de encriptación simétrica, por lo que la sobrecarga es mínima. En pocas palabras: realizar muchas solicitudes breves a través de HTTPS será bastante más lento que HTTP, pero si transfiere una gran cantidad de datos en una única solicitud, la diferencia será insignificante.

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

Para comprender realmente cómo HTTPS boostá su latencia, debe comprender cómo se establecen las conexiones HTTPS. Aquí hay un buen diagtwig . La clave es que en lugar de que el cliente obtenga los datos después de 2 “patas” (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 patas (2 viajes de ida y vuelta) . Entonces, si toma 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 puede mitigarse reutilizando la conexión HTTPS (qué navegadores deberían hacer), pero explica parte de esa pérdida inicial al cargar un sitio web HTTPS.

La sobrecarga NO se debe a la encriptación. En una CPU moderna, el cifrado requerido por SSL es trivial.

La sobrecarga se debe a los apretones de manos de SSL, que son largos y aumentan drásticamente el número de viajes de ida y vuelta requeridos para una sesión de HTTPS sobre uno HTTP.

Mida (utilizando una herramienta como Firebug) los tiempos de carga de la página mientras el servidor se encuentra al final de un enlace simulado de alta latencia. 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:

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

Actualización de diciembre de 2014

Puede probar fácilmente la diferencia entre el rendimiento HTTP y HTTPS en su propio navegador utilizando el sitio web de prueba HTTP contra 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 que no están 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 en Let’s Encrypt – Al llegar septiembre de 2015:

  • Vamos a cifrar el calendario de lanzamiento (16 de junio de 2015)
  • Vamos a cifrar los certificados raíz y intermedios (4 de junio de 2015)
  • Borrador Let’s Encrypt Subscriber Agreement (21 de mayo de 2015)

Más información en Twitter: @letsencrypt

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

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

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

  • ¿Por qué HTTPS para todo? (El estándar HTTPS-Only)
  • Let’s Encrypt (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 actual no es del todo correcta.

Como otros han señalado aquí, https requiere el apretón de manos y, por lo tanto, realiza más viajes de ida y vuelta 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 EE. UU. Puede ser de alrededor de 200 ms (tiempo de viaje de ida y vuelta).

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

Además de todo lo mencionado hasta ahora, tenga en cuenta que algunos (¿todos?) Navegadores web no almacenan el 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 abundante contenido estático parecerán cargarse más despacio 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 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 encriptador que para el descifrador. Algunos tienen el costo opuesto.

Más caro que el cripto granel 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 viejos secretos de sesión hasta que expiren. Esto significa que las pequeñas solicitudes de un cliente que no vuelve 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, ya que el ancho de banda disponible es demasiado bajo. Pero seguramente 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 algunos casos, el impacto en el rendimiento de los apretones de manos SSL se mitigará por el hecho de que la sesión SSL se puede almacenar en caché en ambos extremos (computadora de escritorio y servidor). En máquinas con Windows, por ejemplo, la sesión SSL se puede almacenar en caché hasta por 10 horas. Vea 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 de la sesión.

Otro impacto a tener en cuenta es que el contenido estático servido sobre HTTPS no será almacenado en memoria caché por los servidores proxy, y esto puede reducir el rendimiento entre múltiples 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 en caché el contenido estático HTTPS a menos que se indique lo contrario (Menú Herramientas / Opciones de Internet / Avanzado / Seguridad / No guardar páginas encriptadas en el 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

enter image description here

Por supuesto, estas cifras 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 desde el navegador al servidor) pero muestra la idea general: HTTPS es lento y luego HTTP, ya que solicita más operaciones para completar (apretón de manos SSL y datos de encoding / desencoding).

Aquí hay un gran artículo (un poco viejo, pero aún genial) sobre latencia de handshake de 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

Como estoy investigando el mismo problema para mi proyecto, encontré estas diapositivas. Más viejo pero interesante:

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

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

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

COMPARACIÓN DEL RENDIMIENTO HTTP VS HTTPS

Siempre he asociado HTTPS con tiempos de carga de página más lentos en comparación con el viejo HTTP 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 de rendimiento involucradas, el siguiente diagtwig le brinda una idea básica de lo que sucede bajo el capó cuando realiza una solicitud de un recurso usando HTTPS.

enter image description here

Como puede ver en el diagtwig anterior, hay algunos pasos adicionales que deben tener lugar cuando se usa HTTPS en comparación con el uso de HTTP simple. Cuando realiza una solicitud usando HTTPS, debe darse un apretón de manos para verificar la autenticidad de la solicitud. Este apretón de manos es un paso adicional cuando se compara con una solicitud HTTP y desafortunadamente incurre en algunos gastos generales.

Para entender las implicaciones de rendimiento y ver por mí mismo si el impacto en el rendimiento sería o no significativo, utilicé este sitio como una 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 en Here is Test video, el resultado 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 desde el servidor.

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

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

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

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

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. Me interesarían tus resultados.

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

Una diferencia de rendimiento más importante es que una sesión HTTPS se abre con ketp mientras el usuario está conectado. Una ‘sesión’ HTTP solo dura para una única solicitud de artículo.

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

Esto es casi seguro que va a ser cierto dado que SSL requiere un paso adicional de encriptación que simplemente no es requerido por el HTTP que no es SLL.

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 HTTP / 2.0, en promedio, 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 a los diferentes protocolos que generalmente usa. Sin embargo, si HTTP sobre HTTP / 1.1 se compara con HTTPS a través de 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 promedio de tiempo de carga de la 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 a través de HTTP / 1.1

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