HTTP, HTTPS y TLS: Parte 14 — Qué ocurre cuando abres un sitio: todo el recorrido de la petición

Estás escribiendo example.ru y pulsas Enter. Medio segundo después aparece la página en la pantalla. En ese tiempo el navegador alcanza a averiguar la dirección IP del servidor, establecer una conexión segura, enviar la petición, esperar a que el servidor prepare la respuesta, descargar decenas de archivos y dibujar la página. Este artículo recorre todo el camino paso a paso: qué ocurre en cada uno, cuánto tiempo ocupa y dónde buscar el problema si la página se abre lentamente o no se abre en absoluto. Los detalles de cada paso están en las partes anteriores del ciclo; los enlaces a ellas se dan en el texto.

Para estimar tiempos tomaremos la latencia al servidor (RTT, tiempo de ida y vuelta del paquete) de 50 ms — un valor típico para un servidor en la ciudad vecina.

1. Resolución de la dirección y elección del esquema

El navegador decide qué se ha introducido: una dirección o una consulta de búsqueda. example.ru parece un dominio, y el navegador completa la dirección. Luego — elección entre HTTP y HTTPS:

• el dominio está en la lista HSTS preload o el sitio ya envió el encabezado Strict-Transport-Security — inmediatamente https://;
• de lo contrario, los navegadores modernos igualmente prueban HTTPS primero (HTTPS-First en Firefox, HTTPS-Upgrades en Chrome) y hacen fallback a HTTP solo si HTTPS no funciona.

Detalles — en el artículo «Pase a HTTPS: redirecciones, HSTS, HTTPS-First y el encabezado Upgrade».

Si el sitio se abrió recientemente, el navegador puede tomar la página o partes de ella de su caché y no ir a la red en absoluto — eso lo determinan los encabezados Cache-Control de la respuesta anterior («Encabezados HTTP»).

2. DNS: el nombre se convierte en dirección

El navegador necesita la dirección IP de example.ru. La busca por una cadena hasta encontrarla:

1. su propia caché del navegador;
2. caché del sistema operativo y el archivo hosts;
3. el resolvedor DNS: normalmente el router o el servidor del proveedor, o uno público (1.1.1.1, 77.88.8.8), o un servidor DoH si en el navegador está habilitado DNS cifrado;
4. si el resolvedor no tiene la respuesta en caché, consulta la cadena de servidores: raíz → servidores de la zona .ru → servidores autoritativos del dominio example.ru.

El navegador solicita de inmediato tres tipos de registros: A (IPv4), AAAA (IPv6) y HTTPS. El registro HTTPS puede indicar que el sitio soporta HTTP/3 y proporcionar la clave para ECH («Qué es ECH»).

Tiempo: desde la caché — 0 ms, en el resolvedor del proveedor — 5–30 ms, con recorrido completo de la cadena — hasta 100–200 ms.

Qué puede ir mal: el dominio no está delegado o los registros son incorrectos (NXDOMAIN, «No se puede encontrar la dirección IP del servidor»); está en caché un registro antiguo tras una mudanza; el proveedor manipula las respuestas.

3. TCP: establecimiento de la conexión

Obtenidas las direcciones, el navegador abre una conexión TCP al puerto 443. Aparece el triple apretón de manos: cliente envía SYN, servidor responde SYN-ACK, cliente — ACK. Esto es un ciclo completo (1 RTT).

Si el sitio tiene tanto IPv4 como IPv6, el navegador prueba ambos casi simultáneamente, con una pequeña ventaja para IPv6, y usa el que responda primero (algoritmo Happy Eyeballs). Por ello un IPv6 roto usualmente no provoca un error sino una pequeña demora.

Tiempo: 1 RTT — 50 ms.

Qué puede ir mal: puerto bloqueado por firewall (la conexión queda colgada hasta el timeout) o en el puerto no hay servicio escuchando (inmediatamente «Connection refused»).

Para HTTP/3 los pasos 3 y 4 se combinan: el navegador envía paquetes QUIC por UDP, y el transporte con cifrado se establece en un solo ciclo («HTTP/1.1, HTTP/2 y HTTP/3»).

4. TLS: canal seguro

Sobre TCP va el apretón de manos TLS 1.3 («Qué es HTTPS y cómo funciona el apretón de manos TLS»):

1. ClientHello — versiones, cifrados, clave para el intercambio, nombre del sitio (SNI), lista de protocolos (ALPN: h2, http/1.1);
2. ServerHello con la clave del servidor; a partir de ahí todo cifrado: certificado, firma, Finished;
3. el navegador verifica el certificado: cadena hasta una raíz de confianza, validez, coincidencia del nombre;
4. Finished del cliente — y de inmediato la petición HTTP.

Por ALPN las partes han acordado la versión de HTTP — normalmente HTTP/2.

Tiempo: 1 RTT para TLS 1.3 (2 RTT para TLS 1.2); con reanudación de sesión — menos.

Qué puede ir mal: certificado caducado, nombre que no coincide, cadena incompleta, no hay una versión TLS común («Depuración de TLS»).

5. Petición HTTP

Por el canal ya listo el navegador envía la petición («Qué es HTTP»):

:method: GET
:path: /
:authority: example.ru
:scheme: https
accept: text/html,...
accept-encoding: gzip, br, zstd
accept-language: ru-RU,ru;q=0.9
cookie: session=...
user-agent: Mozilla/5.0 ...

La petición sale en un único frame HTTP/2 con los encabezados comprimidos.

6. En el lado del servidor

La petición rara vez llega directamente a la aplicación. Camino típico:

1. CDN o protección contra DDoS (si existe) — recibe TLS, revisa la petición: si no es bot, si no hay ya la respuesta en caché. Si hay respuesta en caché, la devuelve inmediatamente y la petición no llega a tu servidor. Aquí también se evalúa la huella del cliente («Qué son JA3 y JA4»);
2. Balanceador o proxy inverso (Nginx, HAProxy) — selecciona el servidor de aplicación según Host y ruta, añade X-Forwarded-For y X-Forwarded-Proto;
3. Aplicación — PHP-FPM, Node.js, Python, Go: comprueba la sesión por cookie, consulta la base de datos, cachés, APIs externas, construye el HTML;
4. la respuesta vuelve por el mismo camino; el proxy la comprime, añade encabezados de seguridad, el CDN puede guardarla en caché.

Tiempo: desde unos pocos milisegundos para estático o respuesta desde caché hasta cientos de milisegundos y segundos para páginas pesadas. Es precisamente aquí donde suele ir la mayor parte del tiempo. En curl esto es la diferencia time_starttransfer − time_appconnect, en el navegador — «Waiting for server response» en la pestaña Timing.

Qué puede ir mal: la aplicación falló (502), no dio tiempo a responder (504), devolvió un error (500), la petición fue bloqueada por la protección (403, captcha).

7. Respuesta

:status: 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: no-cache
strict-transport-security: max-age=31536000
set-cookie: ...

El navegador descomprime el cuerpo, recuerda HSTS y las cookies, guarda la respuesta en caché según las reglas Cache-Control. Si la respuesta es una redirección (301, 302), toda la cadena se reinicia para la nueva dirección; al cambiar de dominio — con DNS.

Resultado de la primera petición con RTT 50 ms: DNS 20 ms + TCP 50 ms + TLS 50 ms + petición y respuesta 50 ms + trabajo del servidor. Incluso en un servidor rápido el primer byte de HTML llega a los 170–200 ms. Cada redirección extra añade al menos otro ciclo.

8. Descarga de recursos

El navegador empieza a parsear el HTML sin esperar al final de la descarga y encuentra enlaces a estilos, scripts, fuentes, imágenes. Los solicita:

• desde el mismo dominio — por la conexión ya abierta HTTP/2, en hilos paralelos, sin nuevos apretones de manos;
• desde otros dominios (CDN de estático, fuentes, contadores, widgets) — para cada uno otra vez DNS, TCP y TLS. Por eso cada dominio externo en la página cuesta 100–150 ms en la primera visita. Se puede acelerar con una pista <link rel="preconnect" href="https://cdn.example.ru">.

No todos los recursos son iguales:

• CSS bloquea el render — el navegador no mostrará la página hasta cargar los estilos en <head>;
• scripts sin async o defer bloquean el parseo del HTML — el navegador se detiene, descarga y ejecuta el script;
• imágenes y fuentes se cargan en paralelo y no bloquean el parseo, pero la fuente puede retrasar la visualización del texto.

El servidor puede acelerar esta etapa: la respuesta 103 Early Hints o el encabezado Link: <...>; rel=preload indican recursos importantes antes de que el HTML esté listo.

9. Renderizado

Desde el HTML el navegador construye el árbol DOM, desde el CSS el árbol de estilos, los combina, calcula la posición de los elementos en pantalla (layout) y los pinta (paint). JavaScript puede cambiar el DOM y entonces parte del trabajo se repite.

Para el usuario son importantes tres momentos que miden las métricas Core Web Vitals:

• LCP (Largest Contentful Paint) — cuándo se muestra el elemento principal de la página; bueno — hasta 2,5 s;
• INP (Interaction to Next Paint) — qué tan rápido reacciona la página a las interacciones; bueno — hasta 200 ms;
• CLS (Cumulative Layout Shift) — cuánto saltan los elementos durante la carga; bueno — hasta 0,1.

10. Qué queda después

La conexión con el servidor no se cierra de inmediato — las siguientes navegaciones por el sitio usarán la misma sin nuevos apretones de manos. El navegador recuerda:

• respuestas DNS (durante el TTL);
• ticket de sesión TLS — la reanudación será más corta;
• HSTS — próximas visitas irán directamente por HTTPS;
• encabezado Alt-Svc — la próxima visita puede ir por HTTP/3;
• recursos cacheados — en una visita posterior no es necesario volver a cargarlos.

Por eso la segunda visita al sitio casi siempre es mucho más rápida que la primera, y hay que comprobar la velocidad en ambos modos — con caché vacío (DevTools → Disable cache o ventana de incógnito) y con caché poblado.

Análisis en un sitio real

Los mismos pasos con el ejemplo de este sitio, bigmike.help: medición del 24 de septiembre de 2026, el sitio con CDN CloudFront. Repite los comandos para tu sitio — los números serán distintos, pero el orden de magnitud parecido.

DNS: recorrido completo sin caché. dig +trace recorre la cadena por sí mismo, empezando por los servidores raíz:

dig +trace +nodnssec bigmike.help A | grep '^;; Received'

;; Received 823 bytes from 192.0.2.53#53 in 5 ms                  ← lista de servidores raíz desde el resolvedor del proveedor
;; Received 285 bytes from 192.58.128.30#53(j.root-servers.net) in 15 ms     ← raíz: "pregunta a los servidores .help"
;; Received 180 bytes from 194.169.218.158#53(a.nic.help) in 44 ms           ← zona .help: "pregunta a awsdns"
;; Received 244 bytes from 205.251.196.103#53(ns-1127.awsdns-12.org) in 46 ms ← servidor autoritativo: direcciones

Sin caché — alrededor de 110 ms para cuatro consultas. Desde la caché del resolvedor la misma respuesta llegó en 3 ms. La respuesta contiene cuatro direcciones IPv4 y direcciones IPv6 de CloudFront.

Todos los pasos de una petición:

curl -s -o /dev/null -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://bigmike.help/ru/

Encabezados de la respuesta:

curl -sI https://bigmike.help/ru/

HTTP/2 200
via: 1.1 Caddy, 1.1 ….cloudfront.net (CloudFront)
x-cache: Hit from cloudfront
age: 8359
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000
etag: "6ab48ab0-e02e"

De ellos se lee todo el camino: via — la petición pasó por Caddy en el servidor y por CloudFront; x-cache: Hit y age: 8359 — la respuesta fue tomada de la caché del CDN, donde llevaba 2 horas 19 minutos, la petición no llegó al servidor; alt-svc — el sitio es accesible por HTTP/3 y el navegador lo probará en la próxima visita; strict-transport-security — el navegador recordará que aquí solo por HTTPS.

Fallo de caché. La misma página justo después de actualizarse en el servidor — primer byte a los 570 ms en lugar de 60–90 ms: el CDN tuvo que ir al servidor por la respuesta. La petición repetida — de nuevo Hit y cerca de 60 ms. La diferencia casi de diez veces — esa es la ventaja del CDN.

Reutilización de la conexión. Dos URLs en una sola llamada curl van por la misma conexión:

curl -s -o /dev/null -o /dev/null -w '%{url_effective}: tcp %{time_connect} tls %{time_appconnect} nuevos conectos %{num_connects}\n' \
  https://bigmike.help/ru/ https://bigmike.help/ru/posts/

https://bigmike.help/ru/: tcp 0.020 tls 0.043 nuevos conectos 1
https://bigmike.help/ru/posts/: tcp 0.000 tls 0.000 nuevos conectos 0

Para la segunda página no hicieron falta DNS, TCP ni TLS.

Compresión. El mismo HTML con compresión gzip — 15 KB en lugar de 57 KB:

curl -s --compressed -o /dev/null -w '%{size_download}\n' https://bigmike.help/ru/   # 15362

Redirección desde HTTP:

curl -sI http://bigmike.help/ | grep -iE '^(HTTP|location)'
# HTTP/1.1 301 Moved Permanently
# Location: https://bigmike.help/

La primera visita por http:// cuesta un ciclo extra por la redirección; tras recibir HSTS el navegador irá directamente a https://.

Cómo ver todo esto por ti mismo

curl muestra las etapas de una petición («Depuración HTTP con curl»):

curl -s -o /dev/null https://example.ru/ -w \
 'dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n'

DevTools del navegador — pestaña Network, columna Waterfall y pestaña Timing en la petición: las mismas etapas para cada recurso de la página, incluido el tiempo en cola («Interceptar HTTPS para depuración»).

Lighthouse (en DevTools) y PageSpeed Insights — métricas Core Web Vitals y recomendaciones concretas sobre recursos que bloquean el render.

Dónde buscar el problema según el síntoma