Saltar a contenido

Arquitectura Web Moderna

Diagramas del capítulo

D-003 - ¿Qué es Internet?

D-003 - ¿Qué es Internet?

D-004 - Cliente ↔ Servidor

D-004 - Cliente ↔ Servidor

D-005 - Viaje de una petición web

D-005 - Viaje de una petición web

D-006 - Infraestructura de Internet

D-006 - Infraestructura de Internet

D-009 - Carga de una página web

D-009 - Carga de una página web

De cero a una infraestructura profesional para Internet

Capítulo 1

¿Qué ocurre cuando escribes una dirección web?

Objetivos

¿Qué aprenderás?

Al terminar este capítulo serás capaz de:

  • Describir con precisión técnica qué sucede desde el momento en que escribes una URL hasta que la página aparece en pantalla.
  • Entender qué es Internet, cómo está construida físicamente y por qué funciona como funciona.
  • Comprender el sistema de nombres de dominio (DNS) y por qué existe.
  • Diferenciar entre IPv4 e IPv6 y entender el problema de agotamiento de direcciones.
  • Explicar el proceso de conexión TCP y por qué es necesario antes de enviar cualquier dato.
  • Entender qué es TLS/HTTPS y cómo protege tu información en tránsito.
  • Leer e interpretar una petición y respuesta HTTP.
  • Comprender qué hace el navegador con el HTML, CSS y JavaScript que recibe del servidor.
  • Reconocer los errores más comunes que ocurren durante este proceso y cómo diagnosticarlos.

Introducción

La analogía de la casa sin dirección

Imagina que quieres visitar a una persona llamada El Profe, pero solo conoces su nombre. No tienes su dirección, no tienes un mapa, ni sabes en qué ciudad vive. Lo único que tienes es su nombre.

¿Qué harías? Probablemente llamarías a alguien que tenga un directorio: la guía telefónica, un asistente, alguien que conozca a El Profe y pueda darte su dirección exacta. Una vez que tienes la dirección, ya puedes tomar el camino correcto, llegar a la casa, tocar la puerta, identificarte, y finalmente entrar.

Eso es exactamente lo que ocurre cuando escribes https://elprofe.org en tu navegador.

No hay magia. No hay atajos. Hay un proceso preciso, veloz, y absolutamente fascinante que ocurre en milisegundos. En este capítulo lo vamos a desmontar pieza por pieza.

Paso 1 — ¿Qué es Internet?

Antes de hablar de URLs, DNS o HTTPS, necesitamos entender la infraestructura sobre la que todo esto opera.

Una red de redes

Internet no es un servidor gigante en algún lugar. Internet es, literalmente, una red de redes: millones de redes privadas, corporativas, académicas y gubernamentales, interconectadas entre sí siguiendo un conjunto de protocolos comunes.

El nombre viene de Internetwork: una red entre redes.

Cada red que se conecta a Internet es autónoma. Tu proveedor de Internet (ISP), la red de tu universidad, la red interna de Google, la de un hospital en Alemania: todas son redes independientes que deciden voluntariamente hablar el mismo idioma para poder comunicarse.

ISP: el proveedor de acceso

Tu ISP (Internet Service Provider, como Telmex, Totalplay o Megacable en México) es la empresa que te da acceso a Internet. Cuando tu computadora quiere comunicarse con el mundo exterior, lo hace a través de la red de tu ISP.

Los ISP están interconectados entre sí. Los ISP pequeños se conectan a ISP medianos, que a su vez se conectan a grandes operadores de tránsito, y estos a los llamados ISP Tier 1: las empresas que poseen o controlan la infraestructura más grande de Internet y que no pagan a nadie para transportar su tráfico.

Routers: los carteros de Internet

Un router (enrutador) es un dispositivo especializado cuya única función es recibir paquetes de datos y decidir hacia dónde enviarlos para que lleguen a su destino.

Cuando envías información por Internet, esa información se divide en pequeños fragmentos llamados paquetes. Cada paquete puede tomar un camino diferente para llegar a destino. Los routers leen la dirección de destino de cada paquete y lo reenvían al siguiente router más cercano al destino, como una cadena de carteros que se pasan una carta entre sí.

El backbone de Internet

El backbone (columna vertebral) de Internet son las grandes rutas de fibra óptica que atraviesan continentes y océanos. Son cables físicos, tendidos en el fondo del mar y bajo tierra, que transportan enormes volúmenes de tráfico a velocidades cercanas a la de la luz.

La mayoría de la comunicación internacional ocurre a través de estos cables submarinos. Puedes verlos en el mapa interactivo de Submarine Cable Map. Es literalmente el sistema circulatorio de Internet.

Fibra óptica y centros de datos

La fibra óptica transmite información mediante pulsos de luz. Es mucho más rápida y resistente a interferencias que el cable de cobre tradicional. La luz viaja a ~200,000 km/s dentro de la fibra (aproximadamente 2/3 de la velocidad de la luz en el vacío), lo que permite latencias de milisegundos incluso entre continentes.

Los centros de datos (data centers) son los edificios donde viven los servidores. Google, Amazon, Microsoft y Meta tienen decenas de centros de datos repartidos por el mundo, cada uno con miles o millones de servidores. Cuando visitas una página web, estás hablando con uno de esos servidores.

Diagrama — La estructura de Internet

  [Tu dispositivo]
        |
   [Tu router Wi-Fi]
        |
   [Red del ISP]
        |
   [ISP Regional]
        |
   [ISP Tier 1 / Backbone]
        |
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
  ~  RED GLOBAL DE INTERNET ~
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
        |
   [ISP del servidor]
        |
   [Centro de datos]
        |
   [Servidor web]

Paso 2 — ¿Qué ocurre cuando escribimos https://elprofe.org?

Antes de que ocurra cualquier comunicación de red, el navegador necesita entender qué le estás pidiendo. Lo hace analizando la URL (Uniform Resource Locator).

Anatomía de una URL

https://elprofe.org/cursos/matematicas?nivel=basico#temario
  │        │           │                    │            │
  │        │           │                    │            └── Fragmento (hash)
  │        │           │                    └────────────── Parámetros de consulta
  │        │           └─────────────────────────────────── Ruta (path)
  │        └─────────────────────────────────────────────── Dominio
  └──────────────────────────────────────────────────────── Esquema (protocolo)

Esquema (protocolo): La parte https:// le dice al navegador qué protocolo usar para comunicarse. http es el protocolo original; https es su versión segura con cifrado. Existen otros esquemas: ftp://, mailto:, ws:// (WebSocket), etc.

Dominio: elprofe.org es el nombre humano-legible del servidor al que quieres conectarte. El navegador necesita traducir este nombre a una dirección IP para poder comunicarse. Esa traducción la hace el DNS (lo veremos en el siguiente paso).

Ruta (path): /cursos/matematicas indica qué recurso específico quieres dentro del servidor. Es como la ruta de un archivo dentro de un sistema de carpetas.

Parámetros de consulta: ?nivel=basico son pares clave-valor que el servidor puede usar para personalizar la respuesta. Muy comunes en búsquedas y filtros.

Fragmento (hash): #temario es procesado exclusivamente por el navegador, no se envía al servidor. Le dice al navegador que salte a un elemento con ese identificador dentro de la página.

Referencia técnica: La estructura de las URLs está definida en el RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax, publicado por el IETF.

Paso 3 — DNS: El directorio de Internet

¿Por qué existe el DNS?

Las computadoras se comunican usando direcciones IP (números como 104.21.32.67). Los humanos preferimos nombres como elprofe.org.

El DNS (Domain Name System) es el sistema que traduce un nombre de dominio a una dirección IP. Es, literalmente, el directorio telefónico de Internet.

Sin DNS, tendrías que memorizar direcciones IP para visitar cualquier sitio web.

Referencia técnica: El DNS fue diseñado por Paul Mockapetris y está especificado en el RFC 1034 y RFC 1035, publicados por el IETF en noviembre de 1987.

¿Cómo funciona la resolución DNS?

Hay varios actores involucrados en encontrar la IP de un dominio:

1. Caché local del sistema operativo Lo primero que hace tu computadora es revisar su propia memoria. Si ya visitaste elprofe.org recientemente, la IP puede estar guardada localmente. Esta caché tiene un tiempo de vida limitado llamado TTL (Time To Live), especificado en segundos por el propietario del dominio.

2. Resolver recursivo (del ISP o de Google/Cloudflare) Si no hay caché local, la consulta va a un resolver recursivo. Este servidor (generalmente operado por tu ISP, o por servicios públicos como 8.8.8.8 de Google o 1.1.1.1 de Cloudflare) es el encargado de hacer el trabajo pesado: preguntar a los servidores correctos hasta obtener la respuesta.

3. Servidores raíz (Root Servers) Si el resolver tampoco tiene la respuesta en caché, pregunta a uno de los 13 grupos de servidores raíz de DNS. Estos servidores no saben la IP de elprofe.org, pero saben quién es responsable del TLD .org.

4. Servidor TLD El servidor del TLD .org (operado por la Public Interest Registry) no sabe la IP de elprofe.org, pero sabe cuál es el servidor DNS autoritativo de ese dominio específico.

5. Servidor DNS autoritativo Este es el servidor que tiene la respuesta final. El propietario de elprofe.org configuró aquí los registros DNS, incluyendo el registro A (que apunta a una dirección IPv4) o AAAA (que apunta a IPv6).

Diagrama — Resolución DNS completa

  [Tu navegador]
       |
       | 1. ¿Cuál es la IP de elprofe.org?
       ↓
  [Resolver Recursivo del ISP / 8.8.8.8 / 1.1.1.1]
       |
       | ¿Tiene caché? → SÍ → Devuelve IP ──────────────────→ [Navegador]
       |                ↓ NO
       | 2. Pregunta al servidor raíz
       ↓
  [Servidor Raíz]  →  "No sé, pero .org lo maneja este servidor: [TLD .org]"
       |
       | 3. Pregunta al servidor TLD .org
       ↓
  [Servidor TLD .org]  →  "No sé la IP, pero el autoritativo es: ns1.elprofe.org"
       |
       | 4. Pregunta al servidor autoritativo
       ↓
  [Servidor DNS Autoritativo de elprofe.org]
       |
       | → "La IP es 104.21.32.67" (Registro A)
       ↓
  [Resolver Recursivo]  → Guarda en caché con el TTL del dominio
       |
       ↓
  [Tu navegador]  → Ya tiene la IP. Puede continuar.

Tipos de registros DNS más comunes

Tipo Función
A Mapea un dominio a una dirección IPv4
AAAA Mapea un dominio a una dirección IPv6
CNAME Alias de otro dominio (redirección de nombre)
MX Define los servidores de correo del dominio
TXT Texto libre; usado para verificaciones y SPF/DKIM
NS Define los servidores DNS autoritativos del dominio

Curiosidad: Todo este proceso de resolución DNS suele completarse en menos de 100 milisegundos. Cloudflare registra latencias promedio de resolución DNS de ~14 ms en su resolver 1.1.1.1.

Paso 4 — Direcciones IP: el sistema de coordenadas de Internet

IPv4

Una dirección IPv4 tiene 32 bits y se representa en cuatro grupos de números del 0 al 255, separados por puntos: 104.21.32.67.

El número total de combinaciones posibles es 2³² = 4,294,967,296 (poco más de 4 mil millones de direcciones). Cuando se diseñó este sistema en los años 80, parecía más que suficiente. No lo fue.

El agotamiento de IPv4: En enero de 2011, la IANA (Internet Assigned Numbers Authority) distribuyó los últimos bloques IPv4 disponibles a los registros regionales. Según la ICANN, el pool de direcciones IPv4 está efectivamente agotado. Las nuevas direcciones hoy se consiguen comprándolas en mercados secundarios o compartiendo bloques mediante NAT.

IPv6

IPv6 usa 128 bits y se representa en ocho grupos de cuatro dígitos hexadecimales: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

El número de combinaciones posibles es 2¹²⁸ = 340 sextillones de direcciones. Una cantidad tan astronómica que podría asignarse una dirección única a cada átomo de la superficie terrestre y todavía sobrarían.

La transición de IPv4 a IPv6 es gradual y lleva décadas. Hoy, la mayoría de las infraestructuras modernas soportan ambas (configuración dual-stack).

¿Por qué los dominios son necesarios?

Las IPs son difíciles de recordar para los humanos. Además, una IP puede cambiar: si un servidor se mueve a otro data center, su IP cambia, pero su dominio permanece igual. El DNS actúa como intermediario, desacoplando el nombre (estable) de la dirección (variable).

Paso 5 — Conexión TCP: el apretón de manos que garantiza la comunicación

Ya tenemos la IP del servidor. Ahora necesitamos establecer una conexión antes de enviar cualquier dato. Para eso usamos TCP (Transmission Control Protocol).

TCP es un protocolo orientado a la conexión: antes de transmitir datos, ambos lados deben acordar que están listos para comunicarse y sincronizar sus parámetros de comunicación.

El Three-Way Handshake (Apretón de tres vías)

Referencia técnica: El procedimiento de establecimiento de conexión TCP está definido en el RFC 793, publicado por el IETF en septiembre de 1981.

Diagrama — TCP Three-Way Handshake

  [Cliente / Navegador]              [Servidor]
         |                               |
         |──── SYN (SEQ=x) ────────────>|   1. "¿Puedo conectarme?"
         |                               |      (Synchronize: número de secuencia x)
         |                               |
         |<─── SYN-ACK (SEQ=y, ACK=x+1)|   2. "Sí. Aquí está mi número. ¿Me confirmas?"
         |                               |      (Acknowledge: confirma x, propone y)
         |                               |
         |──── ACK (ACK=y+1) ──────────>|   3. "Confirmado. Empecemos."
         |                               |
         |                               |
    [ CONEXIÓN ESTABLECIDA — Datos pueden fluir ]

Paso 1 — SYN: El cliente envía un paquete con el flag SYN activado y un número de secuencia inicial (ISN) aleatorio x. Esto significa: "Quiero iniciar una conexión contigo."

Paso 2 — SYN-ACK: El servidor responde con SYN y ACK simultáneamente. Confirma el número del cliente (x+1) y propone su propio número de secuencia y. Esto significa: "Recibí tu petición. Aquí está mi número de secuencia. Ahora tú confírmame."

Paso 3 — ACK: El cliente confirma el número del servidor (y+1). La conexión queda establecida en ambas direcciones.

¿Por qué tres pasos y no dos? Porque es necesario sincronizar números de secuencia en ambas direcciones para garantizar que los paquetes lleguen en orden y sin duplicados. Dos pasos no serían suficientes para confirmar que el servidor también escucha al cliente correctamente.

Buena práctica: En HTTP/2 y HTTP/3, se han implementado mecanismos para reducir el número de viajes de ida y vuelta (RTT) necesarios antes de enviar datos, mejorando significativamente la velocidad de carga.

Paso 6 — TLS: La capa de seguridad que protege tu información

Tenemos una conexión TCP. Pero si enviáramos datos ahora, cualquier dispositivo en la ruta (routers, ISPs, gobiernos) podría leerlos. Para evitarlo usamos TLS (Transport Layer Security).

HTTPS = HTTP + TLS. El candado verde que ves en tu navegador indica que la conexión está protegida con TLS.

Referencia técnica: La versión actual del protocolo es TLS 1.3, especificada en el RFC 8446, publicado por el IETF en agosto de 2018. Versiones anteriores como SSL 2.0, SSL 3.0, TLS 1.0 y TLS 1.1 están obsoletas y consideradas inseguras.

¿Qué hace TLS exactamente?

TLS proporciona tres garantías fundamentales:

  1. Confidencialidad: Los datos viajan cifrados. Solo el cliente y el servidor pueden leerlos.
  2. Integridad: Si alguien modifica los datos en tránsito, el destinatario lo detecta.
  3. Autenticación: El cliente puede verificar que realmente está hablando con el servidor correcto y no con un impostor.

Certificados TLS

Para que TLS funcione, el servidor presenta un certificado digital, emitido por una Autoridad de Certificación (CA) de confianza (como Let's Encrypt, DigiCert o Sectigo). El certificado contiene:

  • El nombre del dominio para el que fue emitido
  • La clave pública del servidor
  • La firma digital de la CA que lo validó
  • La fecha de expiración

Tu navegador tiene una lista de CAs de confianza preinstalada. Cuando el servidor presenta su certificado, el navegador verifica la firma, la fecha de expiración y que el dominio coincide. Si algo falla, aparece la advertencia de "conexión no segura".

El handshake TLS 1.3 (simplificado)

Diagrama — TLS 1.3 Handshake

  [Cliente]                                  [Servidor]
     |                                            |
     |──── ClientHello ─────────────────────────>|
     |     (versiones TLS soportadas,             |
     |      algoritmos de cifrado,                |
     |      clave pública efímera Diffie-Hellman) |
     |                                            |
     |<─── ServerHello + Certificado ────────────|
     |     (algoritmo elegido,                    |
     |      clave pública del servidor,           |
     |      certificado TLS firmado)              |
     |                                            |
     |     [El cliente verifica el certificado]   |
     |     [Ambos derivan la misma clave          |
     |      de sesión sin enviarla jamás]         |
     |                                            |
     |──── Finished (cifrado) ──────────────────>|
     |                                            |
     |<─── Finished (cifrado) ────────────────── |
     |                                            |
     [ TÚNEL CIFRADO ESTABLECIDO ]

La magia de TLS está en el intercambio de claves Diffie-Hellman: cliente y servidor pueden derivar la misma clave de cifrado sin que esa clave jamás viaje por la red. Incluso si alguien graba toda la conversación, no puede descifrarla sin haber participado en el handshake.

Curiosidad: Let's Encrypt, lanzada en 2014, democratizó el acceso a certificados TLS. Antes, un certificado costaba cientos de dólares al año. Hoy es gratuito y automático. Según sus estadísticas, Let's Encrypt ha emitido más de 3 mil millones de certificados.

Paso 7 — La Petición HTTP: el idioma entre cliente y servidor

Con la conexión TCP establecida y el túnel TLS activo, el navegador puede finalmente enviar una petición HTTP.

Referencia técnica: El protocolo HTTP está definido en el RFC 9110 — HTTP Semantics, publicado por el IETF en junio de 2022.

Estructura de una petición HTTP

GET /cursos/matematicas?nivel=basico HTTP/1.1
Host: elprofe.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/126.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-MX,es;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session_id=abc123xyz; preferencia=oscuro

Línea de petición: Contiene el método HTTP, la ruta y la versión del protocolo.

Métodos HTTP principales

Método Uso
GET Obtener un recurso (la acción más común al navegar)
POST Enviar datos al servidor (formularios, creación de recursos)
PUT Reemplazar un recurso completo
PATCH Modificar parcialmente un recurso
DELETE Eliminar un recurso
HEAD Como GET pero solo devuelve los headers, sin cuerpo
OPTIONS Pregunta qué métodos acepta el servidor para una ruta

Headers HTTP

Los headers (cabeceras) son metadatos que acompañan la petición. Informan al servidor sobre el cliente, el tipo de contenido que acepta, el idioma preferido, si acepta compresión, y más.

Host: Indica el dominio solicitado. Esencial porque un mismo servidor puede alojar decenas de dominios distintos (virtual hosting).

Accept-Encoding: gzip, deflate, br: Le dice al servidor que el cliente acepta respuestas comprimidas. El servidor puede enviar el HTML comprimido con Brotli (br) o gzip, reduciendo el tamaño del archivo hasta en un 80%.

Cookie: Fragmentos de texto que el servidor colocó anteriormente en el navegador para mantener estado (sesiones, preferencias, carritos de compra). Las cookies son la razón por la que puedes cerrar el navegador y seguir "logueado" cuando vuelves.

Paso 8 — El servidor web: quien procesa la petición

La petición HTTP llega al servidor. Pero, ¿qué la recibe?

Diagrama — Ruta de la petición al servidor

  [Internet]
      |
  [Firewall / Load Balancer]
      |
  [Servidor Web (Nginx / Apache / Cloudflare)]
      |
  [Aplicación backend (Node.js, Python, PHP...)]
      |
  [Base de datos (Firestore, PostgreSQL, MySQL...)]
      |
  [Respuesta construida]
      |
  [De vuelta al usuario]

Apache

Uno de los servidores web más antiguos y populares (1995). Maneja cada petición en su propio hilo o proceso. Excelente para sitios con contenido dinámico complejo (PHP). Configuración flexible vía .htaccess.

Nginx

Diseñado para manejar miles de conexiones concurrentes con bajo consumo de memoria. Usa una arquitectura orientada a eventos en lugar de hilos. Ideal como servidor de archivos estáticos, reverse proxy, y balanceador de carga. Muy popular en infraestructuras de alto tráfico.

Cloudflare

No es solo un servidor web; es una red de distribución de contenido (CDN) que también actúa como proxy inverso, firewall de aplicaciones web (WAF), y proveedor de DNS. Cuando un sitio usa Cloudflare, las peticiones van primero a uno de los más de 330 puntos de presencia (PoP) de Cloudflare alrededor del mundo, antes de llegar al servidor de origen.

Firebase Hosting

Servicio de Google que aloja archivos estáticos (HTML, CSS, JS) en CDN globales de Google. Ideal para Single Page Applications (SPAs) y sitios estáticos. Las peticiones a contenido dinámico se redirigen a Cloud Functions o Cloud Run.

GitHub Pages

Servicio gratuito de GitHub para alojar sitios estáticos directamente desde un repositorio Git. Usa la infraestructura de Fastly como CDN. Soporta Jekyll para generación de sitios estáticos. Limitado a contenido estático, sin backend.

AWS (Amazon Web Services)

La plataforma de nube más grande del mundo. Ofrece desde servidores virtuales (EC2) hasta funciones serverless (Lambda), balanceadores de carga (ELB), CDN (CloudFront), bases de datos administradas (RDS, DynamoDB), y decenas de servicios más. La mayoría de la Internet moderna corre parcialmente sobre AWS.

Paso 9 — La Respuesta: todo lo que el servidor envía de vuelta

El servidor procesa la petición y devuelve una respuesta HTTP:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Content-Length: 12453
Cache-Control: max-age=3600, public
ETag: "a3f92b1c"
Strict-Transport-Security: max-age=31536000; includeSubDomains

<!DOCTYPE html>
<html lang="es">
  <head>
    <title>El Profe — Matemáticas</title>
    ...

Códigos de estado HTTP

El número en la primera línea (200 OK) es el código de estado. Le dice al navegador si la petición fue exitosa y qué ocurrió.

Rango Categoría Ejemplos
1xx Informacional 100 Continue
2xx Éxito 200 OK, 201 Created, 204 No Content
3xx Redirección 301 Moved Permanently, 302 Found, 304 Not Modified
4xx Error cliente 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx Error servidor 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Recursos adicionales: CSS, JS, imágenes, fuentes

El HTML que llega al navegador contiene referencias a decenas de recursos adicionales: hojas de estilo CSS, archivos JavaScript, imágenes, fuentes web, videos. Cada uno de estos recursos genera una petición HTTP adicional, la cual puede ser servida desde el mismo servidor o desde un CDN.

CDN: la magia de la distribución global

Una CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que almacenan copias en caché de los recursos estáticos de tu sitio.

Diagrama — CDN vs. Servidor de origen

  Sin CDN:
  [Usuario en México] ─────────────────────────────── [Servidor en Frankfurt]
                              ~180ms de latencia

  Con CDN:
  [Usuario en México] ──── [Nodo CDN en Guadalajara] ─── [Servidor en Frankfurt]
                              ~8ms de latencia          (solo si el caché expiró)

Cuando un usuario en Guadalajara pide una imagen, la CDN puede servirla desde un nodo en la misma ciudad en milisegundos, en lugar de hacer el viaje hasta Frankfurt. Cloudflare, Fastly, y AWS CloudFront son ejemplos de CDNs ampliamente usadas.

Paso 10 — Renderizado: del código a la pantalla

El navegador recibió el HTML. Ahora comienza la fase más compleja: convertirlo en píxeles visibles.

Referencia técnica: El proceso de renderizado está documentado en detalle en MDN Web Docs — Populating the page: how browsers work y en el Critical Rendering Path.

1. Parsing HTML → DOM

El motor de parsing del navegador lee el HTML byte a byte y construye el DOM (Document Object Model): una representación en árbol de todos los elementos de la página.

Diagrama — Árbol DOM

  document
  └── html
      ├── head
      │   ├── title → "El Profe"
      │   └── link (CSS)
      └── body
          ├── header
          │   └── h1 → "Matemáticas"
          └── main
              ├── section.leccion
              └── footer

El DOM es la representación viva del documento. JavaScript puede modificarlo en tiempo real, y el navegador actualizará la pantalla para reflejar esos cambios.

2. Parsing CSS → CSSOM

De manera paralela, el navegador descarga y parsea las hojas de estilo CSS para construir el CSSOM (CSS Object Model): un árbol similar al DOM que contiene todos los estilos y cómo se aplican a cada elemento.

El CSS es render-blocking: el navegador no puede pintar nada hasta terminar de parsear todo el CSS. Por eso, las buenas prácticas dicen que el CSS debe estar en el <head> y ser lo más pequeño posible.

3. Render Tree

El navegador combina el DOM y el CSSOM para crear el Render Tree: solo contiene los elementos visibles y sus estilos computados. Los elementos con display: none no aparecen en el Render Tree.

4. Layout (Reflow)

Con el Render Tree listo, el navegador calcula la posición y dimensiones exactas de cada elemento en la pantalla, en píxeles. Este proceso se llama layout o reflow. Aquí se resuelven porcentajes, em, rem, flexbox, grid, etc.

5. Paint (Pintar)

El navegador convierte el layout en instrucciones de dibujo y rasteriza los píxeles en las capas de la pantalla. Cada elemento se pinta en su capa correspondiente.

6. Composite (Composición)

El motor de composición del navegador combina todas las capas pintadas en la imagen final que ves en pantalla. Las animaciones y transiciones optimizadas operan en esta fase para no relanzar layout ni paint.

JavaScript: el dinamismo que lo complica todo

El JavaScript es parser-blocking de forma predeterminada: cuando el parser encuentra una etiqueta <script>, detiene la construcción del DOM, ejecuta el JavaScript, y solo entonces continúa. Por eso los scripts deben colocarse al final del <body> o usar los atributos defer o async.

Diagrama — Flujo completo de renderizado

  HTML recibido
      |
      ├── Parser HTML ─────────────────────────────→ DOM
      |                                              |
      └── Descarga CSS → Parser CSS ──────────────→ CSSOM
                                                     |
                                              DOM + CSSOM
                                                     |
                                               Render Tree
                                                     |
                                                  Layout
                                                     |
                                                   Paint
                                                     |
                                                 Composite
                                                     |
                                             [Pantalla visible]

El flujo completo: de la tecla Enter a la página visible

Ahora que conocemos cada pieza, veamos el flujo completo de principio a fin:

1.  El usuario escribe https://elprofe.org y presiona Enter
2.  El navegador analiza la URL (esquema, dominio, ruta)
3.  Consulta la caché DNS local → no encontrado
4.  Consulta al resolver DNS del ISP / 1.1.1.1
5.  El resolver consulta a los Root Servers → respuesta: pregunta al TLD .org
6.  El resolver consulta al servidor TLD .org → respuesta: NS autoritativo
7.  El resolver consulta al servidor DNS autoritativo de elprofe.org
8.  Respuesta: IP = 104.21.32.67 (TTL = 300 segundos)
9.  El resolver devuelve la IP al navegador y la guarda en caché
10. El navegador inicia conexión TCP al puerto 443 de 104.21.32.67
    → SYN → SYN-ACK → ACK (Three-Way Handshake)
11. Se inicia el handshake TLS 1.3
    → ClientHello → ServerHello + Certificado → Finished
    → Túnel cifrado establecido
12. El navegador envía petición HTTP GET /
    GET / HTTP/1.1
    Host: elprofe.org
    Accept-Encoding: gzip, br
    ...
13. El servidor (Nginx / Cloudflare / Firebase) procesa la petición
14. El servidor devuelve respuesta HTTP 200 OK con el HTML
15. El navegador parsea el HTML y construye el DOM
16. Encuentra referencias a CSS → descarga y parsea → CSSOM
17. Encuentra referencias a JS → descarga, parsea y ejecuta
18. Encuentra imágenes, fuentes → descarga en paralelo (CDN)
19. Construye el Render Tree
20. Calcula el Layout
21. Pinta (Paint) y Compone (Composite)
22. La página aparece en pantalla. Total: ~200-500ms típicamente.

Errores comunes y cómo diagnosticarlos

Error Causa probable Qué verificar
ERR_NAME_NOT_RESOLVED DNS no puede resolver el dominio Registros DNS, servidor autoritativo
ERR_CONNECTION_REFUSED El servidor no acepta conexiones en ese puerto Firewall, puerto abierto, servidor activo
ERR_SSL_PROTOCOL_ERROR Problema con el certificado TLS Certificado expirado, dominio incorrecto
404 Not Found La ruta solicitada no existe en el servidor Ruta correcta, archivo presente, configuración
500 Internal Server Error Error en el código del servidor Logs del servidor, excepciones no manejadas
502 Bad Gateway El proxy no puede comunicarse con el servidor origen Servidor de aplicación caído, timeout
503 Service Unavailable El servidor está saturado o en mantenimiento Capacidad del servidor, reinicio del servicio
Página lenta DNS lento, sin CDN, imágenes sin optimizar, JS bloqueante DevTools → Network tab, Lighthouse

Conceptos importantes y buenas prácticas

  • Siempre usa HTTPS. HTTP sin cifrado expone los datos de tus usuarios. Let's Encrypt ofrece certificados gratuitos y automáticos.
  • Configura un TTL razonable en tu DNS. TTL muy bajo (ej. 60s) aumenta la carga en tus servidores DNS. TTL muy alto (ej. 86400s = 24h) ralentiza los cambios de IP.
  • Usa una CDN para recursos estáticos. Imágenes, CSS, JS y fuentes deben servirse desde servidores geográficamente cercanos al usuario.
  • Habilita compresión Brotli o gzip. Reduce el tamaño de transferencia hasta en un 80%.
  • Usa defer o async en tus scripts. Evita bloquear el parsing del DOM.
  • Optimiza el Critical Rendering Path. El CSS y HTML crítico debe llegar lo antes posible para que el navegador pinte la primera vista.
  • Monitorea tus códigos de estado. Un aumento en errores 5xx indica problemas en tu infraestructura.

Resumen del capítulo

Cuando escribes https://elprofe.org en tu navegador y presionas Enter, ocurre lo siguiente en una fracción de segundo:

  1. URL parsing: El navegador descompone la URL en sus partes (esquema, dominio, ruta, parámetros).
  2. Resolución DNS: Se traduce el nombre de dominio a una dirección IP mediante una cadena de consultas desde servidores raíz hasta el servidor autoritativo. La caché DNS agiliza futuras consultas.
  3. Direcciones IP: Las IPs (IPv4 o IPv6) son las coordenadas reales de los servidores en Internet. Los dominios existen para que los humanos no tengamos que memorizar números.
  4. TCP Handshake: Se establece una conexión confiable y ordenada en tres pasos (SYN → SYN-ACK → ACK), sincronizando números de secuencia en ambas direcciones.
  5. TLS Handshake: Se negocia un canal cifrado usando certificados digitales y criptografía de clave pública/privada. Garantiza confidencialidad, integridad y autenticación.
  6. Petición HTTP: El navegador envía una petición estructurada con método, headers, cookies y cuerpo opcional.
  7. Servidor web: Nginx, Apache, Cloudflare, Firebase, AWS u otro servidor procesa la petición y ejecuta la lógica de la aplicación.
  8. Respuesta HTTP: El servidor devuelve un código de estado, headers y el contenido solicitado (HTML, JSON, imagen, etc.), posiblemente comprimido y desde una CDN.
  9. Renderizado: El navegador parsea HTML (DOM), CSS (CSSOM), ejecuta JavaScript, calcula el layout, pinta y compone los píxeles finales.

Todo esto ocurre en el tiempo que tardas en parpadear.

Glosario

Término Definición
URL Uniform Resource Locator. Dirección completa de un recurso en Internet (protocolo + dominio + ruta + parámetros).
DNS Domain Name System. Sistema jerárquico que traduce nombres de dominio a direcciones IP.
IP Internet Protocol. Protocolo de direccionamiento de paquetes en redes. Las IPs son las "coordenadas" de los dispositivos.
IPv4 Versión 4 del protocolo IP. Usa 32 bits (~4.3 mil millones de direcciones posibles). Prácticamente agotado.
IPv6 Versión 6 del protocolo IP. Usa 128 bits (340 sextillones de direcciones). Sucesor de IPv4.
TCP Transmission Control Protocol. Protocolo orientado a la conexión que garantiza entrega ordenada y sin pérdida de paquetes.
TLS Transport Layer Security. Protocolo de cifrado que protege la comunicación entre cliente y servidor.
HTTPS HTTP sobre TLS. Versión segura del protocolo HTTP.
HTTP Hypertext Transfer Protocol. Protocolo de comunicación entre navegadores y servidores web.
ISP Internet Service Provider. Empresa que provee acceso a Internet.
CDN Content Delivery Network. Red de servidores distribuidos que sirven contenido desde ubicaciones cercanas al usuario.
Router Dispositivo que dirige paquetes de datos entre redes.
Backbone Infraestructura de alta capacidad (cables submarinos, fibra) que forma el núcleo de Internet.
DOM Document Object Model. Representación en árbol del HTML analizado por el navegador.
CSSOM CSS Object Model. Representación en árbol de los estilos CSS analizados por el navegador.
Render Tree Árbol combinado de DOM + CSSOM que contiene solo los elementos visibles con sus estilos.
TTL Time To Live. Tiempo en segundos que una respuesta DNS puede almacenarse en caché.
Certificado TLS Documento digital emitido por una CA que verifica la identidad de un servidor y contiene su clave pública.
CA Certificate Authority. Entidad de confianza que emite y valida certificados TLS.
Handshake Proceso de negociación inicial entre cliente y servidor para establecer parámetros de conexión.
Header HTTP Metadato que acompaña una petición o respuesta HTTP con información adicional sobre el contenido o el cliente.
Cookie Pequeño fragmento de texto que el servidor almacena en el navegador para mantener estado entre peticiones.
Gzip / Brotli Algoritmos de compresión usados para reducir el tamaño de los archivos en tránsito.
Registro A Tipo de registro DNS que mapea un dominio a una dirección IPv4.
Registro AAAA Tipo de registro DNS que mapea un dominio a una dirección IPv6.
ISN Initial Sequence Number. Número aleatorio con el que inicia una conexión TCP.
SYN / ACK Flags del protocolo TCP. SYN inicia sincronización; ACK confirma recepción.
Layout / Reflow Fase del renderizado donde el navegador calcula posición y tamaño exacto de cada elemento.
Paint Fase del renderizado donde los elementos se convierten en píxeles en pantalla.
Composite Fase donde las capas pintadas se combinan en la imagen final visible.
Resolver recursivo Servidor DNS que realiza consultas en nombre del cliente hasta obtener la respuesta final.
DNS autoritativo Servidor DNS que tiene la respuesta definitiva para un dominio específico.
Fibra óptica Medio de transmisión de datos mediante pulsos de luz. Base del backbone de Internet.
Puerto Número (0-65535) que identifica un servicio específico dentro de un servidor. HTTP usa 80, HTTPS usa 443.
Virtual hosting Técnica que permite alojar múltiples dominios en un mismo servidor usando el header Host.

Autoevaluación

Responde estas preguntas sin mirar el capítulo. Si puedes responderlas todas, dominaste el contenido.

  1. ¿Qué significa la sigla URL y cuáles son sus componentes principales?
  2. ¿Cuál es la diferencia entre el esquema http:// y https://?
  3. ¿Qué es el DNS y por qué fue creado?
  4. Explica la diferencia entre un resolver DNS recursivo y un servidor DNS autoritativo.
  5. ¿Qué es el TTL en el contexto del DNS? ¿Qué consecuencias tiene un TTL muy bajo o muy alto?
  6. ¿Cuántas direcciones IP posibles existen en IPv4? ¿Por qué se agotaron?
  7. ¿Cuántas direcciones IP posibles existen en IPv6?
  8. ¿Qué problema resuelve el TCP Three-Way Handshake? ¿Por qué son necesarios tres pasos y no dos?
  9. ¿Qué significa el flag SYN en TCP? ¿Y el flag ACK?
  10. ¿Qué tres garantías proporciona TLS?
  11. ¿Qué es un certificado TLS y quién lo emite?
  12. ¿Por qué el certificado TLS incluye una "clave pública"?
  13. ¿Cuál es la diferencia entre un código de estado HTTP 404 y un 500?
  14. ¿Qué hace el header Accept-Encoding en una petición HTTP?
  15. ¿Para qué sirven las cookies en HTTP?
  16. ¿Qué es el DOM y cómo se construye?
  17. ¿Por qué el CSS es considerado "render-blocking"?
  18. ¿Qué es una CDN y cuál es su principal ventaja?
  19. ¿Cuál es la diferencia entre Firebase Hosting y AWS EC2?
  20. Si un usuario reporta que tu sitio muestra ERR_SSL_PROTOCOL_ERROR, ¿qué es lo primero que verificarías?

Ejercicio práctico

"Radiografía de una petición"

Objetivo: Observar en tiempo real exactamente lo que ocurre cuando visitas un sitio web.

Herramienta: Chrome DevTools (F12 en cualquier navegador Chromium)

Pasos:

  1. Abre Chrome y presiona F12 para abrir DevTools.
  2. Ve a la pestaña Network.
  3. Activa la opción Preserve log y asegúrate de que Disable cache esté activado.
  4. Escribe https://elprofe.org en la barra de direcciones y presiona Enter.
  5. Observa cómo aparecen decenas de peticiones en tiempo real.

Analiza lo siguiente:

  • Busca la primera petición (el documento HTML). Haz clic en ella.
  • En la pestaña Headers, observa los request headers y response headers.
  • Encuentra el código de estado de la respuesta.
  • Ve a la pestaña Timing y observa las fases: DNS Lookup, Initial connection, SSL, TTFB (Time to First Byte), Content Download.
  • Vuelve a la lista de peticiones y filtra por tipo: JS, CSS, Img, Font.

Preguntas de reflexión:

  • ¿Cuántas peticiones HTTP se hicieron en total para cargar esa página?
  • ¿Cuántos milisegundos tardó la resolución DNS?
  • ¿Cuánto tiempo tomó el handshake TLS?
  • ¿Qué recurso fue el más pesado en bytes?
  • ¿Qué recursos vinieron de una CDN (observa los dominios en la columna "Name")?

Proyecto para el siguiente capítulo

"Tu primer servidor en la nube"

En el Capítulo 2 hablaremos de dominios, DNS y servidores. Para prepararte, realiza los siguientes pasos antes de la siguiente sesión:

Tarea 1 — Registra un dominio (o usa uno que ya tengas)

Si no tienes un dominio propio, registra uno en Namecheap o en el registrador que prefieras. Un dominio .com cuesta alrededor de $10-12 USD/año. También puedes usar un subdominio gratuito de servicios como Firebase.

Tarea 2 — Despliega un sitio en Firebase Hosting

  1. Instala Firebase CLI: npm install -g firebase-tools
  2. Crea un proyecto en Firebase Console
  3. Inicializa Hosting: firebase init hosting
  4. Crea un archivo public/index.html con un mensaje simple
  5. Despliega: firebase deploy

Tarea 3 — Explora la CDN de tu despliegue

Una vez desplegado, abre DevTools y observa desde dónde se sirven los archivos. ¿Puedes identificar qué servidores de Google están respondiendo?

Tarea 4 — Inspecciona los registros DNS de tu dominio

Desde la terminal, ejecuta: 

nslookup elprofe.org
dig elprofe.org A
dig elprofe.org NS

Observa los resultados. ¿Puedes identificar el servidor DNS autoritativo? ¿Cuál es el TTL configurado?

En el Capítulo 2 usarás exactamente esta infraestructura para entender cómo conectar un dominio personalizado a Firebase, Cloudflare y otros servicios.

Fin del Capítulo 1

Referencias técnicas utilizadas en este capítulo: