Rendimiento HTTP vs HTTPS
https://stackoverflow.com/questions/149274
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Existen 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 documento técnico que lo respalde?
Solución
Hay una respuesta muy simple a esto: Haga un perfil del rendimiento de su servidor web para ver cuál es la penalización de rendimiento para su situación particular. Hay varias herramientas disponibles 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 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á algún nivel de sobrecarga debido al cifrado, pero depende en gran medida de:
- Hardware
- Software de servidor
- Relación entre contenido dinámico y estático
- Distancia del cliente al servidor
- Duración típica de la sesión
- Etc (mi favorito personal)
- Comportamiento de almacenamiento en 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).
Editar: 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 " duración de sesión típica " y " comportamiento de almacenamiento en caché de los clientes " son importantes.
Muchas sesiones muy cortas significan que el tiempo de intercambio de ideas abrumará cualquier otro factor de rendimiento. Las sesiones más largas significarán que se incurrirá en el costo del 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 da como resultado más solicitudes y ancho de banda para atender a la misma cantidad de usuarios.
Otros consejos
HTTPS requiere un saludo inicial que puede ser muy lento. La cantidad real de datos transferidos como parte del protocolo de enlace no es enorme (normalmente 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 transfieres 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 single handshake 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á.
Para entender 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 " piernas " (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 etapas (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.
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 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 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 página, por ejemplo, al cargar datos que no se requieren en la página (tal vez en un elemento HTML oculto) y luego mostrarlos usando el script del cliente.
Actualización de diciembre de 2014
Puede probar fácilmente la diferencia entre el rendimiento HTTP y HTTPS en su propio navegador utilizando la Prueba HTTP vs HTTPS por 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 no almacenadas en caché (2.04 MB en total) ".
Los resultados pueden sorprenderte.
Es importante tener un conocimiento actualizado sobre el rendimiento de HTTPS porque Let's Encrypt se iniciará la Autoridad de Certificación emitir certificados SSL abiertos, automatizados y gratuitos 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 - Llegando a septiembre de 2015:
- Cifrar el calendario de lanzamiento (16 de junio de 2015)
- Let's Encrypt Root and Intermediate Certificates (4 de junio de 2015)
- Borrador del Acuerdo de Suscriptor de Let's Encrypt (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:
- ¿TLS es rápido todavía?
- Red de navegadores 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 solo para HTTPS)
- Vamos a cifrar (Grupo de investigación de seguridad de Internet)
- HTTPS Everywhere (Electronic Frontier Foundation)
Para resumir, permítame citar Ilya Grigorik : " TLS tiene exactamente un problema de rendimiento: no es utilizado ampliamente Todo lo demás se puede optimizar. & Quot;
Gracias a Chris - autor de Prueba HTTP / HTTPS - para sus comentarios a continuación.
La respuesta principal actual no es completamente correcta.
Como otros lo 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 .
Además de todo lo mencionado hasta ahora, tenga en cuenta que algunos (¿todos?) los 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, las páginas con mucho contenido estático se cargarán más lentamente después de que se reinicie el navegador, y desde la perspectiva de su servidor, el volumen de solicitudes de contenido estático a través de HTTPS será más alto que el 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 cifrador que para el descifrador. Algunos tienen el costo opuesto.
Más caro que el criptográfico a granel es el costo del 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 pequeñas de un cliente que no regresan por más son las más caras.
Para el tráfico de Internet cruzado, es posible que no note este costo en su tasa 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.
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 normal ...
En algunos casos, el impacto en el rendimiento de los protocolos de SSL se verá afectado 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 de almacenamiento en caché de la sesión.
Otro impacto que se debe tener en cuenta es que el contenido estático servido a través de HTTPS no se almacenará en la memoria 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 al disco).
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_bjpg
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 la red en 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).
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:
Como estoy investigando el mismo problema para mi proyecto, encontré estas diapositivas. Más viejo pero interesante:
http://www.cs.nyu.edu/ artículo / investigación / comparación / comparación_slides / sld001.htm
Parece que hay un caso de borde desagradable aquí: Ajax sobre wifi congestionado.
Ajax generalmente significa que KeepAlive ha caducado después de 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, ¡el rendimiento de HTTPS es realmente muy malo!
COMPARACIÓN DE RENDIMIENTO DE HTTP VS HTTPS
Siempre he asociado HTTPS con tiempos de carga de página 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 de rendimiento involucradas, 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 utiliza 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.
Para comprender las implicaciones del rendimiento y ver 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.
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 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 sus resultados.
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.
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.
Es casi seguro que esto suceda, dado que SSL requiere un paso adicional de cifrado que simplemente no es requerido por HTTP que no sea 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 que 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 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:
- 0.47 segundos de tiempo promedio de carga de la página
- 0.05 segundos más lentos 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
- tiempo de carga promedio de 0.10 segundos
- 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
