Comparación de velocidad HTTPS vs HTTP
ssl benchmarking (6)
¿Estás accediendo a tu sitio a través de un proxy? Si es así, es posible que vea un mejor rendimiento porque el proxy se está anulando o reduciendo a simplemente utilizando las solicitudes iniciales CONNECT.
Un proxy podría estar revisando y almacenando en caché el contenido cuando usa HTTP, lo que reduce el rendimiento.
Actualización 2013-04-25:
Esta es una pregunta popular que está recibiendo más atención de la que probablemente debería. Para detener la propagación de la información errónea, lea primero los siguientes párrafos y el artículo que lo acompaña primero:
La velocidad no debería ser un factor para decidir si usar HTTPS o HTTP. Si necesita HTTPS para cualquier parte de su sitio (inicios de sesión, registro, tarjetas de crédito, etc.), absolutamente necesita HTTPS para todo , todo el tiempo.
Por favor, lea SSL no se trata de cifrado por Troy Hunt por las razones.
Se considera que estoy ejecutando todo mi sitio web de comercio electrónico en https. Decidí ejecutar un punto de referencia crudo para medir el tiempo de descarga de una imagen de 156 KB a través de https vs http porque había leído que https está cargado con una sobrecarga adicional del proceso de cifrado.
Benchmark se realizó utilizando Firebug de Firefox simplemente transcribiendo los tiempos "Esperando" y "Recibiendo" (todos los demás tiempos son 0) a Excel desde el panel de Red al descargar la imagen desde un caché vacío.
Mis resultados fueron inesperados:
http: 11.233 seconds
Waiting Receiving Total
1.56 0.88 2.44
1.55 0.101 1.651
1.53 0.9 2.43
1.71 0.172 1.882
1.9 0.93 2.83
https: 9.936 seconds
Waiting Receiving Total
0.867 1.59 2.457
0.4 1.67 2.07
0.277 1.5 1.777
0.536 1.29 1.826
0.256 1.55 1.806
[Obvio] Observaciones del punto de referencia:
- La respuesta del servidor es más rápida, pero el tiempo de descarga es más lento para https que para http.
- https es más rápido en general en una cantidad significativa (~ 10%).
¿Alguien puede explicar por qué esto sucederá?
¿Crees que un documento (html, css, javascript) dará resultados diferentes?
¿Alguien tiene un mejor método de evaluación comparativa de descargas?
Aquí está la imagen de prueba:
[imagen de prueba eliminada]
Información Adicional:
- El sitio web está en una cuenta de alojamiento compartido a través de Godaddy.com.
- Si va a ser tan amable de ejecutar su propio benchmark, no agregue el subdominio "www" ... De todos modos, utilizo la raíz para contenido estático.
- Utiliza IIS7 en modo de canal integrado.
Editar: punto de referencia para 1 px GIF (35 bytes) a continuación:
http: 2.666 seconds
Waiting Receiving Total
0.122 0.31 0.432
0.184 0.34 0.524
0.122 0.36 0.482
0.122 0.34 0.462
0.126 0.64 0.766
https: 2.604 seconds
Waiting Receiving Total
0.25 0.34 0.59
0.118 0.34 0.458
0.12 0.34 0.46
0.182 0.31 0.492
0.134 0.47 0.604
Resultados: https es aún más rápido; aunque trivialmente en este caso.
Si alguien ve un defecto en mi punto de referencia, házmelo saber para que pueda publicar mejores resultados.
Por lo tanto, en el alojamiento compartido de Godaddy alrededor de las 6:00 p.m. en mi servidor específico, el contenido que se sirve en https es más rápido que en http.
Creo que el rendimiento más rápido que está viendo a través de HTTPS no es una casualidad.
Observe dos cosas sobre sus resultados:
- HTTP siempre es más rápido en el primer resultado "total", pero más lento en los totales posteriores.
- Los resultados HTTPS son más consistentes.
Los balanceadores de carga modernos normalmente permiten la compresión mientras SSL está en uso para ayudar al rendimiento. Si bien es cierto que el protocolo de enlace SSL inicial tiene una latencia sustancial, los mecanismos utilizados para mantener la sesión (el "saludo de bienvenida reanudado" y el cifrado simétrico en lugar del cifrado asimétrico) agregan solo una latencia insignificante. Como resultado, a menos que las sesiones sean cortas, obtendrá más beneficio de rendimiento de la compresión de lo que pierde por el mantenimiento de la sesión.
El conocimiento convencional de que el SSL tiene una latencia sustancial está desactualizado (a menos que las sesiones sean bastante cortas). Algunos ingenieros de Google escribieron un artículo explicando cómo algunas suposiciones previas sobre SSL ya no son ciertas.
Si observa sus tiempos, http tiene un tiempo de espera mayor y un tiempo de recepción menor. https por otro lado tiene un menor tiempo de espera y un mayor tiempo de recepción. Yo interpretaría esto como el puerto http en el servidor de alojamiento compartido está más ocupado, por lo tanto, una solicitud permanece más tiempo en la cola hasta que sea aceptada por el servidor. Una vez aceptado, las solicitudes se transfieren más rápido que https. En el puerto https hay menos tráfico en el servidor, por lo que la solicitud recibe un servicio más rápido, pero lleva más tiempo transferir.
Para cualquier comparación de https vs. http tendrá que tener en cuenta el mayor tiempo para saludar cada solicitud de https en comparación con http. Deberías ver cómo empeora cuando haces muchas pequeñas solicitudes.
También es posible que desee tener en cuenta que los documentos HTTPS casi nunca se almacenarán en caché en ningún lugar, excepto el navegador de los usuarios, por lo que puede encontrar que aunque hay poca diferencia para un usuario individual, un documento HTTP puede ser mucho más rápido para un gran número de personas que comparten cache. (Todavía es bastante común en algunos lugares que los ISP pongan a sus clientes a través de un caché de proxy compartido)
Si es algo que no le molesta a los usuarios compartir, por supuesto.
Toda la diferencia de velocidad se debe probablemente a que GoDaddy impone la compresión HTTP en sus servidores en un esfuerzo por conservar el ancho de banda, pero esto no ocurre siempre con la conexión de estilo HTTPS ya que es más nuevo y está mejor optimizado para comenzar.
https funciona de la siguiente manera: Primero se realiza un handshake de 4 vías (al menos si recuerdo correctamente que fue de 4 vías), aquí el cliente y el servidor acuerdan el algoritmo de cifrado simétrico utilizado más adelante e intercambian certificados (que contienen claves públicas).
Intercambian una sesión (clave para el sim sim más tarde) usando publickey crypto.
Ahora envían mensajes cifrados con la clave de sesión y algún algoritmo de cifrado (3des, aes, rc4, rc5, etc.). Como las encriptaciones simétricas no son tan costosas, las diferencias en el tiempo de descarga no son tan grandes.
El hecho de que tenga menos tiempo de espera es porque probablemente tenga menos tráfico en el puerto http o menos tráfico en el momento en que realizó la solicitud https en comparación con las solicitudes http.
Por lo tanto, para optimizar el rendimiento, debe usar la menor cantidad posible de conexiones https, ya que el protocolo de enlace es un procedimiento relativamente costoso.