Protocolos de red: de TCP/IP a HTTP/3

TCP/IP es el conjunto de protocolos sobre el que funciona Internet. Se suele explicar en cuatro capas: enlace (cómo viajan los bits por el cable, el wifi o la fibra), internet (cómo llega un paquete de una máquina a otra saltando de router en router), transporte (cómo se entregan los datos al programa correcto) y aplicación (HTTP, DNS, el correo… lo que de verdad quieres hacer).

La capa de internet es IP: envía paquetes sueltos a una dirección, como 203.0.113.7 en IPv4 o 2001:db8::7 en IPv6, sin ninguna garantía. Un paquete puede perderse, duplicarse o llegar desordenado. La capa de transporte añade el puerto, el número que indica a qué programa va dirigido (443 para HTTPS, 53 para DNS), y, si usa TCP, la fiabilidad.

Quizá oigas hablar también del modelo OSI, de siete capas. Es un modelo teórico más detallado, pero su numeración se usa mucho: «capa 7» es la de aplicación y «capa 4», la de transporte.

TCP abre una conexión antes de enviar nada, con un saludo de tres pasos (SYN, SYN-ACK, ACK) que cuesta un viaje de ida y vuelta. Después numera los datos, confirma lo que recibe y reenvía lo que se pierde, así que la aplicación los recibe completos y en orden. Además regula el ritmo para no saturar la red (el control de congestión).

UDP no abre conexión ni confirma nada: envía cada paquete, llamado datagrama, y se olvida. Es más ligero y no hace esperar a nadie, pero si algo se pierde, se pierde. Lo usan DNS, las videollamadas, los juegos en línea y, como verás enseguida, HTTP/3.

La garantía de orden de TCP tiene un precio: si se pierde un paquete, todo lo que llegó detrás espera en un búfer hasta que llega el reenvío, aunque ya esté completo. Es el bloqueo de cabeza de línea (head-of-line blocking), la clave para entender HTTP/2 y HTTP/3.

TLS (Transport Layer Security) se coloca encima de TCP y ofrece tres garantías: confidencialidad (nadie en el camino puede leer los datos), integridad (nadie puede modificarlos sin que se note) y autenticación (el servidor demuestra quién es con un certificado firmado por una autoridad de certificación en la que confía tu navegador).

Antes de enviar datos, cliente y servidor hacen un handshake (saludo): acuerdan los algoritmos, el servidor presenta su certificado y ambos calculan unas claves que solo ellos conocen. En TLS 1.3, la versión actual, ese saludo cuesta un solo viaje de ida y vuelta.

SSL es el nombre de su predecesor, de los años 90. Todas sus versiones son inseguras, igual que TLS 1.0 y 1.1, y los navegadores ya no las aceptan. Aun así, mucha gente sigue diciendo «certificado SSL» cuando habla de TLS.

HTTPS no es un protocolo distinto: son los mismos mensajes HTTP, cifrados con TLS. Usa el esquema https:// y, por defecto, el puerto 443 en lugar del 80. El candado de la barra de direcciones indica que la conexión está cifrada y que el certificado corresponde a ese dominio; no dice nada de si la web es de fiar.

Hoy es obligatorio en la práctica: los navegadores marcan como «No seguro» las páginas HTTP, solo usan HTTP/2 y HTTP/3 sobre conexiones cifradas, y muchas APIs (Service Workers, geolocalización, el portapapeles) solo funcionan en un contexto seguro, es decir, en HTTPS o en localhost.

HTTP/1.1 envía los mensajes como texto legible, como los que viste en la lección de HTTP. Trajo las conexiones persistentes (keep-alive), que reutilizan una misma conexión TCP para varias peticiones, y la cabecera Host, que permite alojar muchos dominios en un mismo servidor.

Su gran limitación: en cada conexión, una petición tiene que esperar a que termine la respuesta anterior. Para no hacer tanta cola, los navegadores abren varias conexiones en paralelo con el mismo dominio, normalmente hasta seis, y los desarrolladores inventaron trucos como juntar todos los iconos en una sola imagen (sprites) o repartir los recursos entre varios subdominios.

HTTP/2 mantiene la misma semántica, pero cambia el formato: divide cada mensaje en frames binarios etiquetados con un número de flujo (stream). Así, por una única conexión TCP viajan a la vez, intercaladas, todas las peticiones y respuestas de la página: es la multiplexación. Además comprime las cabeceras con HPACK, para no reenviar una y otra vez las mismas cookies.

Su punto débil está debajo: TCP no sabe que hay varios flujos, solo ve una fila de bytes. Si se pierde un paquete, retiene todo lo que llegó detrás, sea del flujo que sea. En una red con pérdidas, como un móvil con mala cobertura, una sola pérdida frena toda la página.

HTTP/3 resuelve lo que HTTP/2 no podía resolver por ir sobre TCP. Usa QUIC, un protocolo de transporte que funciona sobre UDP e implementa por su cuenta lo que hacía TCP: confirmaciones, reenvíos y control de congestión. La diferencia es que QUIC sí conoce los flujos: si se pierde un paquete, solo espera el flujo al que pertenecía.

QUIC lleva TLS 1.3 integrado, así que la conexión y el cifrado se negocian a la vez, en un solo viaje de ida y vuelta (o en ninguno, si reanudas una conexión reciente). Y como identifica la conexión con un ID propio, no por la IP, puede sobrevivir a un cambio de red, como pasar del wifi a los datos móviles.

El navegador no sabe de antemano si un servidor habla HTTP/3: lo normal es que conecte primero por HTTP/2 y que el servidor le anuncie, con la cabecera Alt-Svc o con un registro DNS, que puede usar HTTP/3 en las siguientes peticiones.

Un tipo MIME, o tipo de medio, tiene la forma tipo/subtipo: text/html, text/css, text/javascript, image/webp, application/json, font/woff2. Puede llevar parámetros, como text/html; charset=utf-8. El nombre viene del correo electrónico (Multipurpose Internet Mail Extensions), donde nació para adjuntar archivos, y la IANA mantiene el registro oficial.

En HTTP viaja en dos cabeceras: Content-Type dice qué se está enviando y Accept dice qué formatos prefiere recibir el cliente. El navegador se fía del tipo MIME, no de la extensión: un archivo datos.json servido como text/html se tratará como HTML.

Un URI (Uniform Resource Identifier) es cualquier cadena que identifica un recurso con una sintaxis común: un esquema, dos puntos y lo que ese esquema necesite. Es el término general.

Una URL (Uniform Resource Locator) es un URI que además dice dónde está el recurso y cómo llegar a él, como https://tienda.ejemplo/libros/7; sus partes ya las desmontaste en «Anatomía de una URL». Un URN (Uniform Resource Name) lo identifica por su nombre, de forma permanente y sin decir dónde encontrarlo: urn:isbn:0451450523 nombra un libro, no una tienda que lo venda.

En el día a día la diferencia importa poco: el estándar URL del WHATWG, el que siguen los navegadores, llama URL a todo, incluidos mailto: o data:. Los URN aparecen en sitios concretos, como los ISBN, los UUID (urn:uuid:…) o algunos parámetros de OAuth.