Diferencias entre HTTP y HTTPS
HTTP frente a HTTPS de un vistazo
El Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo que se usa cuando tu navegador web (cliente) solicita información a un servidor.
- la URL comienza con "http://"
- usa el puerto 80 para la comunicación
- no es seguro
- no hay cifrado implementado
- no se requieren certificados
El Protocolo Seguro de Transferencia de Hipertexto (HTTPS) es la combinación del Protocolo de Transferencia de Hipertexto (HTTP) y los protocolos Secure Sockets Layer (SSL) y Transport Layer Security (TLS).
- la URL comienza con "https://"
- usa el puerto 443 para la comunicación
- es una forma más segura de enviar datos de un cliente a un servidor y de vuelta
- la comunicación está cifrada
- se requieren certificados SSL de cifrado
Por qué el protocolo importa al hacer pruebas de carga
El esquema de tu URL de destino, http:// frente a https://, no es cosmético. Le indica al agente de pruebas de carga qué protocolo debe hablar y a qué puerto conectarse por defecto: el 80 para HTTP y el 443 para HTTPS. Probar http://example.com y https://example.com son dos solicitudes distintas, potencialmente gestionadas por dos configuraciones de servidor diferentes, así que asegúrate de que la URL que introduces coincide con la que realmente usan tus usuarios reales.
Sobrecarga del handshake TLS
HTTPS añade un handshake TLS antes de intercambiar cualquier dato de la aplicación: el cliente y el servidor negocian un cifrado, intercambian y validan certificados, y acuerdan claves de sesión. Esa negociación cuesta round trips y tiempo de CPU adicionales respecto al HTTP simple, especialmente en la primera conexión. Dos cosas reducen ese coste en la práctica:
- Reutilización de conexión (keep-alive): una vez establecida una conexión TLS, las solicitudes siguientes por la misma conexión se saltan el handshake, así que la mayor parte de la sobrecarga es un coste único por conexión, no por solicitud.
- Reanudación de sesión: el TLS moderno permite que un cliente reanude una sesión anterior sin un handshake completo, reduciendo aún más el coste en conexiones repetidas.
Con alta concurrencia, cuando muchos usuarios virtuales abren muchas conexiones nuevas a la vez, los handshakes TLS se vuelven intensivos en CPU en el lado del servidor. Si estás comparando el rendimiento de HTTP y HTTPS para el mismo endpoint, espera que HTTPS se vea ligeramente más lento en pruebas con muchas conexiones, y no confundas esa diferencia con una regresión a nivel de aplicación.
Validación de certificados
Como HTTPS requiere un certificado válido, un agente de pruebas de carga que se conecte a tu endpoint necesita poder validarlo. Un certificado caducado, autofirmado o emitido por una autoridad de certificación privada o interna puede provocar fallos de conexión que no tienen nada que ver con el rendimiento real de tu aplicación. Si ves errores de conexión solo en la variante HTTPS de un endpoint, revisa la cadena de certificados antes de asumir que es un problema de carga o de capacidad.
Redirecciones entre HTTP y HTTPS
Muchos sitios redirigen todo el tráfico HTTP a HTTPS con una respuesta 301 o 302. Si apuntas una prueba de carga a la URL HTTP esperando llegar directamente a tu aplicación, en realidad estás midiendo el salto de la redirección más la solicitud HTTPS posterior, lo que añade latencia que no existiría si probaras directamente el endpoint HTTPS. Para obtener cifras de referencia precisas, prueba la URL HTTPS final a la que llegan tus usuarios. Solo prueba la URL HTTP directamente si quieres medir específicamente el propio comportamiento de la redirección.
Para saber qué cuenta como una URL de destino válida, incluido el prefijo http o https, consulta https://loadfocus.com/docs/es-es/knowledge-base/using-valid-url-endpoints.