Cómo funciona Internet: del navegador al servidor, explicado para developers

Escribes programacionwebs.com en la barra de direcciones, pulsas Enter y, unos cientos de milisegundos después, hay una página en pantalla. Ese hueco de tiempo esconde una cadena de protocolos que llevan funcionando, con ajustes, desde los años 80 y 90: uno traduce nombres a direcciones, otro abre una tubería fiable entre dos máquinas que no se conocen de nada, un tercero cifra esa tubería para que nadie por el camino pueda leerla, y un cuarto por fin pide y entrega el documento. Cada capa resuelve un problema que la anterior no resuelve, y entenderlas es lo que separa a quien sabe que “la web funciona con HTTP” de quien puede diagnosticar por qué una API tarda 400 ms de más o por qué un certificado mal configurado tira abajo un dominio entero.

El viaje completo, de un vistazo

Antes de entrar en cada pieza, conviene ver el orden real de los acontecimientos. No es “HTTP y ya”: son al menos cuatro protocolos distintos, cada uno con su propia negociación, antes de que exista una sola petición de contenido.

sequenceDiagram
participant N as Navegador
participant R as Resolver DNS
participant S as Servidor

N->>R: 1. ¿Qué IP tiene programacionwebs.com?
R-->>N: 2. Esta IP: 198.51.100.23
N->>S: 3. SYN (TCP)
S-->>N: 4. SYN-ACK
N->>S: 5. ACK — conexión TCP abierta
N->>S: 6. ClientHello (TLS)
S-->>N: 7. ServerHello + certificado
N->>S: 8. Finished — canal cifrado listo
N->>S: 9. GET / HTTP/1.1
S-->>N: 10. 200 OK + HTML

Cuatro fases: resolución de nombre (DNS), apertura de conexión (TCP), negociación de cifrado (TLS) y transferencia de contenido (HTTP). Solo entonces empieza el trabajo del navegador: parsear el HTML, construir el DOM y pintar píxeles, que es un tema tan denso que le dedicamos aparte el pipeline de renderizado del navegador y cómo funciona el DOM por dentro.

Paso 1: encontrar la dirección — DNS

Internet no enruta paquetes usando nombres de dominio, los enruta usando direcciones IP. El Domain Name System (DNS) es la capa de traducción: un sistema jerárquico y distribuido, definido originalmente en el RFC 1035, que convierte programacionwebs.com en algo como 198.51.100.23.

La resolución real casi nunca es una sola pregunta-respuesta. El sistema operativo primero consulta su propia caché; si no tiene la respuesta, delega en un resolver recursivo (a menudo el de tu ISP o uno público como 1.1.1.1 o 8.8.8.8), que hace el trabajo pesado en tu nombre:

1. Pregunta a un servidor raíz: “¿quién gestiona .com?”.
2. El servidor raíz no conoce la respuesta final, pero sabe delegar al servidor TLD de .com.
3. El servidor TLD tampoco tiene la IP exacta, pero sabe qué servidor autoritativo gestiona programacionwebs.com.
4. Ese servidor autoritativo sí responde con la IP real.

El resolver recursivo guarda esa respuesta en caché durante el tiempo que indique el TTL (time-to-live) del registro, para no repetir el proceso en cada visita. Es la razón por la que cambiar los DNS de un dominio no se propaga al instante: hasta que caduca el TTL en cada resolver del mundo que tenga la respuesta antigua en caché, seguirán sirviendo la IP vieja.

Paso 2: abrir la tubería — la conexión TCP

Con la IP ya en mano, el navegador necesita una vía fiable para enviar y recibir bytes. Esa vía es una conexión TCP (Transmission Control Protocol), y se abre con el conocido three-way handshake:

• El cliente envía un paquete SYN (synchronize) proponiendo un número de secuencia inicial.
• El servidor responde con SYN-ACK, aceptando y proponiendo el suyo propio.
• El cliente confirma con ACK.

Son tres mensajes, uno y medio de ida y vuelta (round trip), antes de que exista intercambio de datos de aplicación. TCP no solo abre la conexión: garantiza que los paquetes lleguen en orden, retransmite los que se pierden y regula la velocidad de envío mediante control de congestión (slow start): empieza enviando pocos segmentos, y va doblando la ventana de envío mientras recibe confirmaciones, hasta encontrar el límite de la red.

Esa fiabilidad tiene un coste estructural: si un paquete se pierde, TCP bloquea la entrega de todo lo que viene detrás hasta que llega la retransmisión, aunque ese contenido pertenezca a una petición completamente distinta multiplexada en la misma conexión. Es el problema de head-of-line blocking, y es la motivación principal detrás de QUIC y HTTP/3, que rediseñan esta capa por completo — lo tratamos con detalle en HTTP/3 y QUIC en 2026.

Paso 3: cifrar el canal — el handshake TLS

Una conexión TCP abierta es solo una tubería fiable, no una tubería privada. Para HTTPS, encima de TCP se negocia TLS (Transport Layer Security), y aquí es donde TLS 1.3 —estandarizado en el RFC 8446— supuso un salto real frente a TLS 1.2.

En TLS 1.2 el handshake completo necesitaba dos round trips. TLS 1.3 lo reduce a uno solo en el caso común: el cliente envía un ClientHello que ya incluye una propuesta de clave criptográfica (key share) “a ciegas”, apostando por el algoritmo que el servidor probablemente soporte. Si acierta, el servidor responde con ServerHello, su certificado, un CertificateVerify (una firma que demuestra que posee la clave privada correspondiente) y un mensaje Finished, y ambas partes ya pueden derivar las claves simétricas de sesión mediante HKDF. A partir del ServerHello, casi todo el resto del handshake —incluido el certificado— viaja ya cifrado, algo que TLS 1.2 no hacía.

Sumando TCP y TLS 1.3, una conexión nueva a un sitio HTTPS necesita de media entre dos y tres round trips completos antes de que salga la primera petición HTTP. En una red con 100 ms de latencia (un móvil en una red con RTT alto, o un servidor lejano geográficamente), eso son 200-300 ms “regalados” solo en negociación, antes de que el servidor haya visto una sola línea de tu petición.

Paso 4: la petición HTTP

Con el canal abierto y cifrado, el navegador por fin envía la petición HTTP: un método (GET, POST…), una ruta, un conjunto de cabeceras (idioma preferido, cookies, tipo de contenido aceptado) y, en su caso, un cuerpo. El servidor responde con un código de estado (200, 404, 301, 500…), sus propias cabeceras y, normalmente, el documento HTML.

El primer paquete de esa respuesta suele limitarse a unos 14 KB, el tamaño típico de la ventana de congestión inicial en TCP antes de que el servidor tenga confirmación de que el cliente está recibiendo bien. Es la razón práctica por la que el HTML crítico y el CSS que bloquea el primer pintado deberían caber, siempre que sea posible, en ese primer tramo: todo lo que no entra ahí espera a la siguiente vuelta de confirmaciones.

A partir de aquí, el navegador empieza a parsear el HTML según llega —no espera a tener el documento completo— y dispara peticiones adicionales para hojas de estilo, scripts, fuentes e imágenes en cuanto las encuentra, gracias a un mecanismo llamado preload scanner que examina el marcado por delante del punto que se está procesando. Qué hace el navegador con todo eso —construcción del DOM, del CSSOM, layout, pintado— es ya el terreno de el pipeline de renderizado.

Por qué esto importa en la práctica

No es trivia de certificación. Cada una de estas fases tiene una traducción directa a decisiones que tomas al construir una web:

• Cada dominio nuevo cuesta una resolución DNS completa y, si es HTTPS, su propio TCP+TLS. Servir imágenes, fuentes y analítica desde tres orígenes distintos multiplica ese coste. Consolidar en menos dominios (o usar HTTP/2 y HTTP/3, que multiplexan muchas peticiones sobre una sola conexión) reduce ese overhead.
• preconnect y dns-prefetch existen exactamente para adelantar el DNS y el handshake TCP/TLS de un origen que sabes que vas a necesitar pronto, antes de que el navegador descubra la necesidad por sí mismo leyendo el HTML.
• La latencia de red pesa más que el ancho de banda en la mayoría de webs modernas. Añadir otro round trip de negociación afecta más al tiempo hasta el primer byte que unos cuantos kilobytes extra de payload, sobre todo en móvil.
• Un certificado TLS mal configurado (caducado, con cadena incompleta, con el nombre equivocado) no es un detalle cosmético: rompe el handshake antes de que exista petición HTTP alguna, así que el error que ve el usuario ni siquiera llega a tu servidor de aplicación.

Errores frecuentes al razonar sobre esto

Un error habitual es pensar en HTTP como si fuera la única capa relevante y tratar DNS, TCP y TLS como “infraestructura invisible que ya funciona sola”. Funciona sola hasta que no: un TTL de DNS demasiado alto retrasa una migración de servidor durante horas; una configuración de TLS que fuerza renegociaciones completas en cada petición destruye el rendimiento; asumir que “HTTPS ya está resuelto porque tengo un candado verde” ignora que hay versiones de TLS, cifrados y configuraciones de certificado con implicaciones de seguridad y rendimiento muy distintas entre sí.

Otro error es subestimar cuánto cambia esta cadena entre la primera visita de un usuario y las siguientes. La primera vez, todo el proceso —DNS, TCP, TLS— ocurre desde cero. En visitas posteriores, con DNS cacheado, conexiones TCP reutilizadas (keep-alive) y sesiones TLS reanudadas, gran parte de ese coste desaparece. Diseñar pensando solo en la visita repetida (la que ves tú, desarrollando, con todo cacheado) es la trampa clásica que hace que una web “vuele” en local y se sienta lenta para un usuario nuevo en una red móvil al otro lado del mundo.

Entender esta cadena de principio a fin —DNS, TCP, TLS, HTTP— no es un ejercicio académico: es la diferencia entre “algo va lento” y saber exactamente en qué punto del recorrido se está perdiendo el tiempo.