Escribes una dirección, pulsas Enter y en menos de un segundo aparece una página entera. Parece magia. No lo es: es una secuencia de pasos con nombre, cada uno con su responsable. Entenderla no es trivia de informática: es lo que te permite arreglar una web que no carga, porque el fallo siempre está en uno de estos pasos, no en “internet en general”.
Lo iremos contando con nuestro hilo conductor, el Overwatch Team Builder: imagina que abres
teambuilder.apppara ver el ranking de héroes. ¿Qué ocurre entre Enter y la página?
Dos papeles: cliente y servidor#
En la web siempre hay dos lados. Tu navegador es el cliente: el que pide. Al otro lado hay un servidor: el que responde.
Y aquí va la primera desmitificación: un servidor no es una nube ni una caja mágica. Es otro ordenador, encendido en algún sitio, ejecutando un programa que está a la escucha, esperando peticiones para contestarlas. Cuando más adelante despliegues tu Team Builder, ese servidor podrías ser perfectamente tú, en un ordenador tuyo.
Cliente y servidor hablan un idioma común para entenderse: HTTP. Todo lo que viene ahora son las reglas de esa conversación.
Del nombre al número: DNS#
teambuilder.app es un nombre pensado para que lo recuerden personas. Pero la red no sabe
encontrar un nombre: necesita un número, una dirección IP como 192.0.2.10.
El DNS (Domain Name System) es la guía telefónica que traduce ese nombre a su IP.
Antes de pedir nada, tu navegador pregunta a un servidor DNS: “¿qué IP tiene
teambuilder.app?”, y recibe el número. Solo entonces sabe a qué ordenador llamar.
Como preguntar cada vez sería lento, el navegador y tu sistema guardan en caché las respuestas DNS un rato. Por eso un dominio recién cambiado a veces “tarda en propagarse”: estás viendo una traducción vieja todavía guardada.
La petición: lo que el navegador envía#
Con la IP en la mano, el navegador abre una conexión y manda una petición (request). Una request, en el fondo, es texto con tres partes:
GET /heroes HTTP/1.1
Host: teambuilder.app
Accept-Language: es
Cookie: sesion=ab12...- El método:
GETpara pedir,POSTpara enviar datos (un login, un formulario). Abrir una URL en el navegador es siempre unGET. - La ruta: qué recurso quieres (
/heroes). - Las cabeceras (headers): metadatos de la petición. Qué idioma aceptas, qué navegador eres, tu cookie de sesión para que el servidor sepa quién eres.
La respuesta: lo que el servidor devuelve#
El servidor procesa la petición y manda una respuesta (response), con la misma forma: una etiqueta, unas cabeceras y un cuerpo.
HTTP/1.1 200 OK
Content-Type: text/html
<!doctype html><html>...La etiqueta es el código de estado, el dato que más vas a mirar en tu vida. Se agrupan en familias, y con conocer estas cinco vas sobrado para el día a día:
- 2xx — fue bien.
200 OKes el normal. - 3xx — redirección. “Lo que pides está en otro sitio, ve allí.”
- 4xx — la liaste tú (el cliente).
404no existe esa ruta,401/403no tienes permiso. - 5xx — la lió el servidor.
500algo reventó al otro lado, no es culpa tuya.
Cuando una web “no funciona”, abrir DevTools y leer estos códigos te dice en un vistazo de qué lado está el problema.
¿Y qué llega exactamente? Texto#
El cuerpo (body) de esa primera respuesta suele ser un documento HTML: texto plano, nada más. El navegador lee ese texto, descubre que necesita más cosas (las hojas de estilo, el JavaScript, las imágenes, los datos de los héroes) y lanza una nueva petición por cada una, cada una con su propio request/response. Abrir una sola página dispara, de hecho, decenas de peticiones.
Convertir ese texto en lo que de verdad ves —cajas, colores, la carta de cada héroe— es otro trabajo entero: el del próximo capítulo, El navegador por dentro.
Una nota honesta para que no te pille por sorpresa: en apps modernas con React, esa primera respuesta puede ser un HTML casi vacío, y es el JavaScript el que después pide los datos y rellena la página. Lo verás de primera mano en el Nivel 6. El esquema petición/respuesta es el mismo; solo cambia quién pide qué y cuándo.
Júntalo todo: una petición real, anotada#
Esto no es un diagrama inventado: es lo que de verdad viaja por la red al pedir la página de héroes. Primero, lo que sale de tu navegador (la request):
GET /heroes HTTP/1.1 ← método (GET = "dame esto") y la ruta que pides
Host: teambuilder.app ← a qué servidor; el DNS ya tradujo el nombre a su IP
Accept-Language: es ← una cabecera: prefiero la versión en españolY esto es lo que vuelve del servidor (la response):
HTTP/1.1 200 OK ← código de estado: todo fue bien
Content-Type: text/html ← lo que viene es un documento HTML
← (línea en blanco: aquí acaban las cabeceras)
<!doctype html><html>... ← el cuerpo: el HTML de la página, como textoPara leer cualquier petición en tu vida profesional basta con mirar la primera línea de cada
bloque: el método y la ruta al pedir, el código de estado al responder. Si esa ruta no existiera
(/heroez), el código de respuesta sería 404 en lugar de 200.
Aún no has escrito nada de esto a mano, y está bien: en el capítulo DevTools verás estas peticiones ocurriendo en vivo en la pestaña Red, y en el Nivel 2 las lanzarás tú con JavaScript. Por ahora, basta con reconocer las piezas.
Comprueba lo que sabes#
Pregunta 1 de 5