Cómo funciona Internet

Navegador → DNS → TCP → HTTP → Servidor → Base de datos → Respuesta → Renderizado

A alto nivel, una solicitud web no es una sola acción, sino una cadena de sistemas que trabajan juntos. Cada paso existe para resolver un problema específico: encontrar el destino, establecer la comunicación, definir la solicitud, procesar la lógica, recuperar datos y devolver resultados.

DNS responde “¿Dónde está ubicado este servicio?” TCP responde “¿Cómo nos comunicamos de forma confiable?” HTTP responde “¿Qué se está solicitando exactamente?” El servidor y la base de datos responden “¿Qué debe calcular y devolver el sistema?”

Estas capas operan de forma independiente, pero cooperan en secuencia. Ningún componente entiende el sistema completo: cada uno cumple su función y pasa el control al siguiente.

Lo que para un usuario parece instantáneo en realidad es una canalización estructurada de abstracciones que se ejecuta en milisegundos.

Cuando un usuario escribe una URL, el navegador hace más que solo “abrir una página”. Primero analiza la entrada para identificar el protocolo (como HTTPS), el nombre de dominio y la ruta solicitada.

Las computadoras no pueden enrutar tráfico usando nombres de dominio como example.com. Las redes funcionan con direcciones IP, que son identificadores numéricos.

El navegador revisa su caché local para ver si ya conoce la dirección IP de ese dominio. Si no, inicia un proceso de búsqueda DNS para resolver el nombre en una dirección IP enrutable.

Solo después de este paso de traducción el sistema puede avanzar para establecer una conexión.

DNS está diseñado como un directorio distribuido para Internet. En lugar de depender de una sola base de datos central, la responsabilidad se divide entre varias capas de servidores para admitir una escala global.

Cuando un dominio no se conoce localmente, un resolvedor recursivo inicia el proceso de búsqueda. Primero contacta a un servidor raíz, que indica el servidor de Dominio de Nivel Superior (TLD) correcto, como .com o .org. Luego, el servidor TLD dirige al resolvedor al servidor de nombres autoritativo para ese dominio específico.

El servidor autoritativo proporciona la dirección IP final. Esa dirección se devuelve al cliente, lo que permite que el navegador continúe y establezca una conexión de red con el destino correcto.

Este diseño por capas mantiene DNS organizado, escalable y capaz de admitir miles de millones de búsquedas cada día.

TCP no comienza a enviar datos de la aplicación de inmediato. Primero establece una conexión usando un proceso de tres pasos: SYN → SYN-ACK → ACK.

El cliente comienza enviando un mensaje SYN (synchronize) para solicitar una conexión. El servidor responde con SYN-ACK, reconociendo la solicitud y compartiendo su propio número de secuencia inicial. Luego, el cliente envía un ACK para confirmar la recepción. En este punto, ambas partes acuerdan los números de secuencia iniciales y saben que la otra parte está lista.

Este intercambio establece la base para una entrega confiable. TCP rastrea los números de secuencia, detecta paquetes perdidos, retransmite los datos faltantes y ajusta la velocidad de envío según las condiciones de la red.

Solo después de este paso de coordinación comienza a fluir realmente los datos de la aplicación.

TCP garantiza la entrega confiable de bytes, pero no define qué significan esos bytes. HTTP se sitúa por encima de TCP y aporta estructura y semántica a la comunicación. Define cómo un cliente pide algo y cómo responde un servidor.

Una solicitud HTTP incluye un método (como GET o POST), encabezados que describen metadatos y, opcionalmente, un cuerpo que contiene datos. El servidor responde con un código de estado, encabezados y el contenido solicitado. Como ambas partes siguen las mismas reglas, pueden interpretar los mensajes de forma consistente.

HTTP es esencial porque Internet es un sistema compartido. Sin un protocolo común que defina la estructura y la intención de los mensajes, los navegadores y los servidores no se entenderían entre sí. HTTP crea ese lenguaje compartido para la web.

Define qué se solicita y qué se devuelve, no cómo viajan físicamente los datos a través de la red.

Cuando los datos llegan a una máquina, no “se ejecutan” automáticamente. El sistema operativo recibe los datos de red y los dirige al proceso correcto usando sockets. Así es como la solicitud llega al programa del servidor.

Luego, el sistema operativo administra los recursos necesarios. Programa el tiempo de CPU para que el servidor pueda ejecutarse, asigna memoria para el procesamiento y controla el acceso a archivos o bases de datos. Sin el sistema operativo coordinando estos recursos, no se podrían manejar varias solicitudes de forma segura o eficiente.

Una vez que la solicitud está dentro del proceso del servidor, la lógica de la aplicación toma el control. Interpreta el mensaje HTTP, realiza los cálculos necesarios o las consultas a la base de datos, y construye una respuesta.

El sistema operativo permite la ejecución. La aplicación del servidor define el comportamiento.

Las aplicaciones generan datos constantemente: cuentas de usuario, publicaciones, transacciones, registros y configuraciones. Si estos datos vivieran solo en memoria, desaparecerían cada vez que el programa se reiniciara. Las bases de datos resuelven esto proporcionando almacenamiento duradero en disco o en sistemas distribuidos.

Pero el almacenamiento por sí solo no es suficiente. Los datos deben estar estructurados y poder consultarse. Las bases de datos organizan la información en tablas o colecciones y proporcionan lenguajes de consulta que permiten a las aplicaciones recuperar registros específicos sin tener que recorrer todo manualmente.

Para mejorar el rendimiento, las bases de datos usan índices, estructuras de datos especializadas que funcionan como un mapa de búsqueda. En lugar de comprobar cada fila, el motor puede ir directamente a las entradas relevantes.

Las bases de datos son fundamentales porque las aplicaciones modernas requieren estado persistente. Sin ellas, cada solicitud funcionaría de forma aislada, sin memoria de la actividad anterior.

Cuando un usuario solicita el mismo recurso varias veces, volver a calcularlo desde cero es ineficiente. La caché resuelve esto almacenando una copia de la respuesta para que las solicitudes futuras puedan servirse de inmediato sin volver a consultar la base de datos ni la lógica de la aplicación.

Las cachés existen en varias capas: dentro del navegador, en el servidor y en el borde de la red. Una Content Delivery Network (CDN) amplía esta idea a nivel global distribuyendo el contenido entre centros de datos geográficamente dispersos. En lugar de contactar siempre al servidor de origen, los usuarios se enrutan a la ubicación de edge más cercana.

Reducir la distancia física disminuye la latencia de red, y reducir el cálculo repetido disminuye la carga del servidor. Juntas, estas optimizaciones mejoran drásticamente el tiempo de respuesta a escala.

Sin embargo, los datos en caché pueden quedar desactualizados, por lo que los sistemas deben equilibrar la velocidad con la frescura de los datos.

Como el ciclo de vida de una solicitud en Internet abarca DNS, transporte, servidores y bases de datos, pueden surgir problemas en cualquier etapa. Si DNS no puede resolver un dominio, la conexión nunca comienza. Si la red pierde paquetes o la conexión TCP se rompe, la comunicación se interrumpe.

Incluso después de que una solicitud llega al servidor, todavía pueden ocurrir fallos. El proceso del servidor podría bloquearse, quedarse sin memoria o no poder conectarse a la base de datos. Una base de datos lenta o que no responde puede retrasar toda la respuesta.

Los sistemas distribuidos rara vez fallan todos a la vez. En cambio, fallan de forma parcial: una región, una instancia o una dependencia a la vez. Diseñar sistemas resilientes requiere añadir redundancia, comprobaciones de estado, reintentos y mecanismos de respaldo en varias capas.

Entender dónde pueden ocurrir fallos es esencial para comprender cómo se comportan los sistemas del mundo real.