TCP handshake vs TLS handshake: qué sucede antes de abrir una web HTTPS
Publicado el 2026-10-26 por frfrand
Secuencia SYN y TLS, y diagnóstico de conexiones lentas
Abrís una web con HTTPS y parece que la conexión es instantánea. Detrás hay pasos distintos: DNS, establecimiento de conexión y negociación de cifrado. Entenderlos ayuda cuando el navegador tarda antes de recibir el primer byte.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace TCP handshake y TLS handshake
En TCP clásico se intercambian SYN, SYN-ACK y ACK para establecer un flujo fiable. Después, en HTTPS sobre TCP, TLS negocia parámetros criptográficos y verifica la identidad del servidor mediante certificados. HTTP/3 utiliza QUIC sobre UDP, por lo que no sigue exactamente la misma secuencia.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo concreto
# Comprobar DNS
dig api.ejemplo.com A +short
# Ver tiempos de una petición
curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' https://api.ejemplo.com/health
# Inspeccionar la cadena TLS
openssl s_client -connect api.ejemplo.com:443 -servername api.ejemplo.com </dev/nullLos nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Medí cuánto consume resolver el dominio.
- Medí el establecimiento de la conexión TCP con una petición real.
- Revisá negociación y validación TLS sin desactivar comprobaciones de certificados.
- Compará tiempo hasta primer byte y duración completa de la respuesta.
- Repetí la prueba desde más de una red antes de atribuir latencia al servidor.
Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
Una API alojada en Europa tiene usuarios de América. La consulta SQL tarda 15 ms, pero crear cada conexión nueva añade latencia de red. Reutilización de conexiones y región del servidor pueden importar más que optimizar otro índice.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
No confundas time_connect con tiempo total de la página. Tampoco afirmes que toda web usa TCP: HTTP/3 suele funcionar sobre QUIC/UDP y cambia las fases observables.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guardá una copia verificable o migración reversible y comprobá que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
En ArduMaker podés elegir la arquitectura de dominio, HTTPS y procesos de un VPS. Medir la latencia de cada fase ayuda a decidir si conviene acercar infraestructura a usuarios o revisar el backend.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder sólo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabés restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si podés responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando sólo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.