Redes, internet y la web: IP, DNS, HTTP y el modelo cliente-servidor

Redes y paquetes

Casi ningún software moderno funciona solo. Una app de reparto de comida en tu teléfono se comunica con los servidores de la empresa, que se comunican con las tabletas de los restaurantes, un proveedor de pagos, un servicio de mapas y un servicio de notificaciones. Esta sección explica cómo funciona esa comunicación, de abajo arriba.

Una red es un conjunto de computadoras conectadas para poder intercambiar datos, por cable, wifi, señal de telefonía móvil o enlace de fibra óptica. Internet es una red de redes: millones de redes con propietarios distintos (banda ancha doméstica, operadores de telefonía móvil, universidades, proveedores de nube) que han acordado transportar el tráfico de las demás usando reglas comunes llamadas protocolos.

Los datos no viajan como un flujo continuo. Se cortan en paquetes: trozos de normalmente hasta unos 1500 bytes, cada uno etiquetado con su origen y su destino, como un paquete postal con la dirección del remitente y la del destinatario. Unos dispositivos llamados routers pasan los paquetes de una red a otra, y cada uno elige un buen siguiente salto, igual que los centros de clasificación hacen avanzar los paquetes postales hacia su destino. Distintos paquetes del mismo mensaje pueden tomar rutas diferentes, llegar desordenados u ocasionalmente perderse, y la computadora que los recibe los vuelve a montar. Dividir los datos en paquetes permite que millones de conversaciones compartan los mismos cables de forma equitativa, y que el tráfico rodee un enlace roto.

Direcciones: direcciones IP y puertos

Para que un paquete llegue, el destino necesita una dirección. Cada dispositivo de internet se alcanza mediante una dirección IP (IP significa Internet Protocol, protocolo de internet). La versión antigua, IPv4, escribe las direcciones como cuatro números del 0 al 255, por ejemplo 192.0.2.10; admite unos 4.3 mil millones de direcciones, que no bastan para cada teléfono, computadora portátil y sensor del mundo. La versión más reciente, IPv6, usa direcciones mucho más largas escritas en hexadecimal (base 16, con los dígitos del 0 al 9 y las letras de la a a la f), por ejemplo 2001:db8::1, y tiene espacio para una cantidad prácticamente ilimitada de dispositivos. Ambas se usan en paralelo. (Las direcciones de ejemplo de esta sección proceden de rangos reservados para documentación, así que no pertenecen a ninguna máquina real).

Una dirección IP lleva un paquete a la computadora correcta, pero una computadora ejecuta muchos programas a la vez. Un número de puerto, del 0 al 65 535, indica qué programa debe recibirlo. Si la dirección IP es la dirección postal de un edificio de oficinas, el puerto es el número de la oficina. Los servicios conocidos tienen puertos estándar: 443 para HTTPS, 80 para HTTP simple, 53 para DNS, 5432 para la base de datos PostgreSQL. Un programa servidor escucha en un puerto, a la espera de conexiones; cuando tu navegador contacta con un sitio web, se conecta al puerto 443 de la dirección IP del sitio.

TCP y UDP: dos formas de entregar

Por encima de IP hay dos protocolos de transporte principales, que deciden cuánto cuidado se pone en la entrega. TCP (Transmission Control Protocol) da a dos programas un flujo de bytes fiable y ordenado. Antes de enviar ningún dato, las dos partes establecen una conexión con un handshake de tres pasos. Cada paquete va numerado; el receptor confirma lo que ha llegado; lo que falta se vuelve a enviar; y todo se entrega al programa en el orden correcto. TCP también reduce la velocidad cuando la red está congestionada. Es como un servicio de correo certificado con seguimiento: fiable, pero con cierta sobrecarga.

UDP (User Datagram Protocol) simplemente envía paquetes sueltos, llamados datagramas, sin handshake, sin confirmaciones, sin reenvíos y sin orden. Es como enviar postales: barato y rápido, pero puede que algunas no lleguen. Eso es justo lo adecuado cuando un paquete que llega tarde no sirve de nada. En una videollamada, un fragmento de sonido que llega medio segundo tarde es peor que uno que nunca llega, así que las llamadas, las transmisiones en directo y los juegos en línea usan UDP y toleran pequeños huecos. Las consultas DNS, que son preguntas y respuestas diminutas, también usan tradicionalmente UDP.

DNS: la libreta de direcciones de internet

Las personas recuerdan nombres como shop.example; las redes enrutan por direcciones IP. El sistema de nombres de dominio (DNS, Domain Name System) traduce lo uno en lo otro. Es un directorio mundial y distribuido: ninguna computadora contiene todos los nombres. En su lugar, la responsabilidad se reparte según los puntos del nombre, leídos de derecha a izquierda. Los servidores raíz saben quién es responsable de cada dominio de nivel superior, como .com o .uk; esos servidores de dominio de nivel superior saben qué servidores de nombres autoritativos son responsables de cada dominio registrado bajo ellos; y los servidores autoritativos contienen los registros reales, como la dirección IP de www.shop.example. La zona raíz la atienden 13 identidades de servidor con nombre, gestionadas por 12 organizaciones independientes mediante bastante más de mil instancias de servidor repartidas por todo el mundo.

Tu dispositivo no suele recorrer esta cadena por sí mismo. Pregunta a un resolvedor recursivo, gestionado normalmente por tu proveedor de internet o por un servicio público, que hace el trabajo pesado y recuerda (guarda en caché) las respuestas durante un periodo fijado por el propietario del dominio, llamado TTL (time to live, tiempo de vida). Como las respuestas se guardan en caché en muchos niveles, la mayoría de las consultas se responden en unos pocos milisegundos sin llegar siquiera a la raíz. Esa misma caché explica por qué un cambio en un registro DNS puede tardar minutos u horas en verse en todas partes.

HTTP: solicitudes y respuestas

Una vez que un programa puede llegar a otro, los dos necesitan un lenguaje común para decir lo que quieren. En la web, ese lenguaje es HTTP (Hypertext Transfer Protocol). Sigue un patrón sencillo: el cliente envía una solicitud; el servidor devuelve una respuesta. Cada solicitud indica un método (qué hacer), una ruta (sobre qué), algunas cabeceras (información adicional en forma de pares nombre-valor) y, a veces, un cuerpo (los datos que se envían). Cada respuesta lleva un código de estado, cabeceras y normalmente un cuerpo: una página web, una imagen o datos en un formato como JSON (un formato de texto sencillo para datos estructurados, que se explica en la sección sobre las API).

Los métodos más comunes son GET (obtener algo, sin cambiarlo), POST (enviar algo nuevo, como hacer un pedido), PUT (sustituir algo en una dirección conocida, como actualizar una dirección de entrega) y DELETE (eliminar algo). GET, PUT y DELETE se definen como idempotentes: enviar dos veces la misma solicitud tiene el mismo efecto que enviarla una vez, lo que hace seguro reintentarlas tras un fallo de red. POST no lo es, y por eso un reintento descuidado puede hacer un pedido dos veces. Las cabeceras llevan cosas como el tipo de contenido (Content-Type: application/json), el idioma que prefiere el usuario, las cookies (pequeños datos que un sitio pide al navegador que guarde y devuelva con las solicitudes posteriores) y las credenciales, e instrucciones de caché.

HTTP es sin estado: cada solicitud se entiende por sí sola, y el servidor no tiene por qué recordar las anteriores. Las sesiones con usuario identificado se construyen por encima, normalmente porque el cliente envía una cookie o un token con cada solicitud. La ausencia de estado es una de las razones por las que la web escala tan bien, porque cualquiera de muchos servidores idénticos puede atender cualquier solicitud.

POST /api/orders HTTP/1.1
Host: shop.example
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"product_id": 42, "quantity": 2}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9917

{"order_id": 9917, "status": "received", "total_pence": 3000}

La división entre 4xx y 5xx importa en la práctica. Un 4xx dice "no te limites a reintentar; corrige la solicitud". Un 5xx dice "el problema está de nuestro lado"; reintentar más tarde puede funcionar, y hay que avisar al equipo de operaciones cuando aumenta la tasa de 5xx.

HTTPS y TLS: privacidad e identidad

El HTTP simple envía todo como texto legible, así que cualquiera que esté en el camino, como alguien conectado al mismo wifi de una cafetería, podría leerlo o alterarlo. HTTPS es HTTP enviado a través de un canal protegido creado por TLS (Transport Layer Security; la versión actual, TLS 1.3, se publicó como RFC 8446 en 2018). TLS aporta tres cosas: confidencialidad (quien escucha a escondidas solo ve datos codificados), integridad (se detectan las manipulaciones) y autenticación (de verdad estás hablando con shop.example, no con un impostor).

La autenticación se basa en certificados. El certificado de un sitio es un documento digital que dice, en esencia, "esta clave pública pertenece a shop.example", firmado por una autoridad de certificación (CA) en la que tu navegador o tu teléfono ya confían. Funciona como un pasaporte: lo emite una autoridad en la que ambas partes confían, se comprueba frente a su titular y solo es válido hasta su fecha de caducidad. Durante el handshake de TLS, el servidor presenta su certificado, el cliente comprueba la firma, el nombre y las fechas, y las dos partes acuerdan claves secretas nuevas para cifrar el resto de la conversación. Si falla alguna comprobación, el navegador muestra una advertencia.

TLS protege los datos en tránsito entre dos puntos. No protege los datos una vez almacenados, ni demuestra que el sitio sea honrado, solo que es quien dice ser. Hoy HTTPS es la norma para todo el tráfico web, no solo para los pagos, y los certificados a menudo se emiten gratis y se renuevan automáticamente.

El modelo cliente-servidor

La mayoría de los sistemas de este curso siguen el modelo cliente-servidor. Un cliente (un navegador, una app móvil, otro programa) inicia la conversación enviando una solicitud. Un servidor espera solicitudes y las responde. El servidor guarda lo que debe ser compartido y fiable: el catálogo de productos, los pedidos de todos, las reglas sobre precios y reembolsos. El cliente se ocupa de la pantalla del usuario y de lo que este introduce.

En un restaurante, los comensales son los clientes y la cocina es el servidor: los comensales inician los pedidos; la cocina tiene los ingredientes y el oficio, y atiende a muchos comensales a la vez. Una consecuencia es que el servidor nunca debe confiar ciegamente en el cliente. El usuario puede modificar una app de su teléfono, así que los precios, los permisos y los niveles de stock deben comprobarse en el servidor, por mucho cuidado que ponga también la app al comprobarlos.

A menudo un servidor también es cliente: el servidor web de la tienda es cliente de su base de datos y del proveedor de pagos. Los sistemas reales son cadenas y redes de relaciones de este tipo, como muestra el diagrama de secuencia de más abajo.

Latencia y ancho de banda

Dos números describen lo rápida que se siente una red, y a menudo se confunden. El ancho de banda es cuántos datos puede transportar una conexión por segundo, por ejemplo 100 megabits por segundo: el ancho de la tubería. La latencia es cuánto tarda un dato en ir de un extremo al otro, y suele medirse como tiempo de ida y vuelta (RTT, round-trip time) en milisegundos: la longitud de la tubería. Ayuda una analogía con una autopista: añadir carriles (ancho de banda) deja pasar más vehículos por hora, pero no acorta el trayecto de ningún vehículo concreto (latencia).

La latencia tiene un mínimo fijado por la física. La luz en la fibra óptica viaja a unos 200 000 km por segundo, alrededor de dos tercios de su velocidad en el vacío. Londres y Sídney están a unos 17 000 km de distancia en línea recta sobre la superficie del globo, así que incluso una fibra perfecta a lo largo de esa línea necesitaría unos 85 ms de ida y 170 ms de ida y vuelta. Los cables reales no siguen el camino más corto y los routers añaden retraso, de modo que los viajes de ida y vuelta medidos rondan normalmente los 250 ms. Ninguna mejora puede eliminar eso. Si cargar una página desde Sídney requiere diez viajes de ida y vuelta secuenciales a un servidor en Londres, el usuario espera dos segundos y medio, por muy rápida que sea su banda ancha.

Qué ocurre cuando escribes una dirección web

Todas estas piezas se combinan cada vez que visitas un sitio web. Esta es la secuencia cuando escribes https://shop.example/products/42 y pulsas Intro, simplificada pero exacta.

Por qué esto importa para la arquitectura

En cuanto un sistema se reparte entre más de una computadora, cada interacción entre sus partes se convierte en una llamada de red, con latencia, posibilidad de fallo y necesidad de seguridad. Una llamada a una función dentro de un programa tarda nanosegundos y nunca se pierde; una llamada a través de una red tarda milisegundos, a veces mucho más, y a veces nunca vuelve. Muchos de los problemas más difíciles de la arquitectura se derivan de esa diferencia, y por eso el Capítulo 6 empieza con las falacias de la computación distribuida, como la creencia de que la latencia es cero.

Los protocolos de esta sección también reaparecen como bloques de construcción: HTTP sustenta las API web de la siguiente parte de este capítulo y los estilos de comunicación del Capítulo 6, mientras que TLS y los certificados vuelven en comunicación segura y zero trust. Situar los servidores cerca de los usuarios forma parte de la arquitectura multirregión y en el borde.