Cómo funciona HTTP: el mensaje, las capas y las cuatro versiones

La carta que escribe tu navegador

Escribes una dirección y pulsas Enter. Lo primero que ocurre es que el DNS traduce ese nombre a una dirección IP: eso lo conté entero en cómo funciona el DNS. Ya sabemos dónde está el servidor.

Ahora hay que pedirle la página. Y de eso se encarga HTTP.

Lo que hace tu navegador en ese momento es escribir una carta. Literalmente: en HTTP/1.1 es texto plano, líneas separadas, que podrías leer tú con los ojos si te asomaras a mirar. En este artículo abrimos esa carta entera, la seguimos hasta el cable y vemos por qué el protocolo se ha reescrito cuatro veces en treinta años.

Qué es HTTP: un acuerdo, no un programa

HTTP son las siglas de HyperText Transfer Protocol, protocolo de transferencia de hipertexto. De las tres palabras, la que importa es la última.

Un protocolo no es un programa. No es un cable. No es algo que puedas instalar. Un protocolo es un acuerdo sobre dos cosas: qué formato tiene lo que nos mandamos y en qué orden nos lo mandamos. Nada más. Como el guion de una conversación telefónica muy estricta: tú preguntas, yo contesto, y ninguno habla cuando no le toca.

En HTTP, quien pregunta se llama cliente —normalmente tu navegador, pero también curl, una app de móvil o un servicio llamando a otro— y quien contesta se llama servidor. El cliente manda una petición, el servidor devuelve una respuesta.

Una petición, una respuesta. Y se acabó.

Ese intercambio viaja por defecto sobre el puerto 80 cuando es HTTP a secas y sobre el 443 cuando es HTTPS. Son solo convenciones, pero convenciones que están en todos los cortafuegos del mundo.

Sin memoria: por qué el servidor no se acuerda de ti

Aquí está el primer rasgo que sorprende a casi todo el mundo: HTTP no tiene memoria. Se dice que es un protocolo sin estado —stateless—, y significa que cada petición nace sin saber nada de la anterior.

Acabas de meter la contraseña, pides la página siguiente, y para el servidor vuelves a ser un desconocido.

Parece un defecto y es justo lo que permitió que la web creciera. Si el servidor no tiene que recordar a nadie, cualquier servidor puede atender cualquier petición: puedes poner mil máquinas detrás de un balanceador y da igual a cuál le toque la tuya. Ese es el motivo de fondo por el que un sitio se escala añadiendo máquinas en horizontal.

Pero algo tenía que recordarte. Y de ahí salen las cookies y los tokens: son la nota que tú mismo le vuelves a enseñar al servidor en cada petición. No es que el servidor se acuerde de ti; es que tú le refrescas la memoria cada vez.

Anatomía de una petición: las cuatro partes

Vamos a abrir la carta. Una petición HTTP tiene cuatro partes, siempre en este orden:

GET /articulos/como-funciona-http HTTP/1.1
Host: antoniocintora.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,*/*;q=0.8
Accept-Language: es-ES,es;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

1. La línea de petición, que es la primera.
2. Las cabeceras, una por línea.
3. Una línea en blanco.
4. El cuerpo, que en una petición como esta va vacío.

La primera línea lleva tres cosas, separadas por espacios:

La línea en blanco de la tercera parte no es decoración: es la marca que dice «aquí acaban las cabeceras». Es exactamente así como el servidor sabe dónde termina el sobre y empieza el contenido. Por eso las líneas de una petición HTTP/1.1 terminan en CRLF —retorno de carro y salto de línea— y lo que las separa del cuerpo es una línea CRLF vacía.

El cuerpo solo aparece cuando mandas algo. Un formulario, un JSON, un fichero:

POST /api/suscripcion HTTP/1.1
Host: antoniocintora.com
Content-Type: application/json
Content-Length: 40

{"email":"hola@ejemplo.com","lang":"es"}

Fíjate en Content-Length: sin esa cabecera —o sin Transfer-Encoding: chunked, que trocea el cuerpo cuando todavía no se sabe cuánto va a ocupar— el servidor no tendría forma de saber dónde acaba el cuerpo. El texto plano no se termina solo.

Los métodos: el verbo de la petición

El método es lo que quieres hacer. Con cuatro entiendes casi todo, pero merece la pena conocerlos con sus dos propiedades formales: si es seguro (no cambia nada en el servidor) y si es idempotente (repetirlo diez veces deja el mismo resultado que hacerlo una).

Esa columna de idempotencia no es teoría: es la razón por la que el navegador te avisa antes de recargar una página a la que llegaste por POST, y por la que un cliente puede reintentar sin miedo un PUT que se quedó sin respuesta pero no debería reintentar a ciegas un POST.

Las cabeceras: los metadatos de la carta

Una cabecera es un par de nombre y valor, una por línea, separados por dos puntos. Son los metadatos de la carta: quién eres, qué idioma prefieres, qué formatos aceptas, qué cookies llevas. Los nombres no distinguen mayúsculas de minúsculas —Host y host son la misma cabecera—, aunque en HTTP/2 y HTTP/3 se transmiten siempre en minúscula.

Estas son las que verás en casi cualquier intercambio:

Y un dato que sorprende: en una petición normal, la mayor parte del peso son cabeceras. El contenido útil es lo más pequeño. Una petición de una imagen puede llevar medio kilobyte de cabeceras —cookies incluidas— para pedir un fichero que ni siquiera hacía falta descargar. Guarda ese dato: es una de las dos cosas que HTTP/2 vino a arreglar.

La respuesta: qué te dice la primera cifra del código

La respuesta tiene la misma forma exacta que la petición —línea inicial, cabeceras, línea en blanco y cuerpo—, pero la primera línea cambia. En lugar del método lleva un código de estado: tres cifras que resumen qué ha pasado.

Una respuesta completa se lee igual de fácil:

HTTP/1.1 200 OK
Date: Sun, 20 Sep 2026 09:14:22 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 18422
Content-Encoding: gzip
Cache-Control: public, max-age=3600

<!doctype html><html lang="es">…

Y la primera cifra ya te lo cuenta casi todo:

Una redirección es la respuesta más corta que verás, y se entiende de un vistazo:

HTTP/1.1 301 Moved Permanently
Location: https://antoniocintora.com/articulos/como-funciona-http
Content-Length: 0

Dos matices que ahorran discusiones:

• 401 no es 403. 401 Unauthorized significa «no sé quién eres, identifícate»; 403 Forbidden significa «sé quién eres y aun así no puedes». Si tu API devuelve 401 a un usuario ya autenticado, lo que te está diciendo es que el token no vale.
• 304 Not Modified es una respuesta sin cuerpo. El servidor te dice que lo que tienes en caché sigue valiendo. Es de la familia 3xx pero no te manda a ningún sitio: te ahorra una descarga.

Y quédate con una cosa, porque dentro de un momento va a importar: todo esto que acabamos de leer es texto. Legible. En HTTP/1.1 podrías imprimir una petición y leerla en voz alta.

El malentendido: HTTP manda mensajes, no paquetes

Se dice mucho que HTTP «manda paquetes». No los manda. HTTP no sabe ni lo que es un paquete.

HTTP manda mensajes. Un mensaje es la carta completa que acabamos de escribir: línea de petición, cabeceras, línea en blanco y cuerpo. Esa es la unidad de HTTP, y no hay otra. Los paquetes son de la capa de abajo.

Y lo de «capa» no es una metáfora blanda: la red está montada literalmente por capas, y cada capa envuelve a la anterior sin leerla.

Esto es lo que le pasa de verdad a tu carta cuando pulsas Enter:

• HTTP le entrega el mensaje a TCP —Transmission Control Protocol—, cuyo trabajo es uno: que eso llegue entero y en orden. TCP lo trocea, porque no cabe de una pieza, y cada trozo se llama segmento y lleva su propia cabecera con un número de orden.
• Cada segmento se lo entrega a IP, el Internet Protocol, que es quien sabe encaminar. IP le pone otra cabecera con la dirección de origen y la de destino. Y ahí, solo ahí, es cuando eso ya se llama un paquete.
• Y cada paquete se mete todavía en una trama para cruzar el cable o el wifi. Otra cabecera más.

Sobres dentro de sobres: dónde nace un paquete

Son sobres dentro de sobres. Y cada capa solo lee el suyo:

[ TRAMA [ PAQUETE IP [ SEGMENTO TCP [ MENSAJE HTTP ] ] ] ]

Al router que mueve tu paquete por medio mundo no le importa si dentro va una petición HTTP, un correo o una partida de un videojuego. Lee la dirección de su sobre y lo empuja al siguiente salto. Por eso se puede cambiar una capa sin tocar las demás: es exactamente lo que va a hacer HTTP/3 más abajo.

¿Y por qué hay que trocear? Por el MTU, el tamaño máximo que admite un trozo de red. En Ethernet son unos 1.500 bytes. Así que una página normal, con su HTML, sus imágenes, sus fuentes y su JavaScript, no son unos pocos paquetes: son miles.

El viaje completo, desde que sueltas la tecla:

Ese último paso es la clave de todo lo que viene ahora: una página no es una petición, son decenas o cientos. Y encima está la promesa de TCP —que llega todo y que llega en orden—, que suena a que solo puede ser buena. Cuando lleguemos a HTTP/2 vas a ver que esa promesa es exactamente lo que lo rompió.

Por qué HTTP se ha reescrito cuatro veces

HTTP no se ha reescrito por capricho. Cada versión arregla el problema que dejó la anterior, y al arreglarlo crea uno nuevo. Es una cadena, y se entiende mucho mejor siguiéndola entera que memorizando fechas.

HTTP/0.9 (1991). Una sola línea: GET y la ruta. Sin cabeceras, sin códigos de estado, sin número de versión. Y solo sabía devolver HTML: no había forma de decir «esto es una imagen».

GET /index.html

Problema: no se puede extender.

HTTP/1.0 (1996). Llegan las cabeceras, los códigos de estado y una que lo cambia todo: Content-Type. Ahora el servidor puede decir qué te está mandando, y la web deja de ser solo documentos.

Problema nuevo: una conexión TCP por cada fichero. Y abrir una conexión cuesta un ida y vuelta entero. Una página con treinta imágenes eran treinta conexiones montadas y tiradas.

HTTP/1.1: keep-alive, Host y el bloqueo del primero de la fila

HTTP/1.1 (1997) es la versión que ha aguantado casi treinta años y la que todavía sirve una parte enorme del tráfico de internet. Trajo tres cosas.

La primera, keep-alive: mantener la conexión viva para pedir varias cosas por la misma. Deja de pagarse el peaje de montar una conexión por fichero.

La segunda, la cabecera Host. Parece menor y no lo es: permite servir muchos dominios desde una sola dirección IP, porque la petición dice a qué dominio va. Sin Host no existiría el alojamiento compartido ni la mayor parte del hosting tal y como lo conocemos. Es la única cabecera obligatoria de HTTP/1.1.

Y la tercera era una idea que sobre el papel lo resolvía todo: el pipelining. Mandar varias peticiones seguidas sin esperar cada respuesta.

El problema es que las respuestas tenían que volver en el mismo orden en que habías pedido. Si la primera era lenta, las demás esperaban detrás aunque ya estuvieran listas. Eso tiene nombre:

Head-of-line blocking: el bloqueo del primero de la fila. Un coche parado en un carril único deja atrás a todos los demás, por muy libre que esté la carretera.

Salió tan mal que los navegadores acabaron desactivándolo. Y el parche fue de fuerza bruta: abrir seis conexiones en paralelo contra cada servidor. Seis colas en vez de una. Ese parche aguantó dieciocho años, y es el origen de media docena de trucos de optimización que todavía se enseñan —juntar todos los CSS en un fichero, meter las imágenes pequeñas en un sprite, repartir los recursos entre varios subdominios— y que con HTTP/2 dejaron de tener sentido.

HTTP/2: binario, multiplexación y un bloqueo que cambia de capa

HTTP/2 (2015) cambia dos cosas de raíz.

La primera: deja de ser texto y pasa a ser binario. ¿Te acuerdas de que unas secciones más arriba era legible? Se acabó. Ya no puedes leer una petición HTTP/2 a ojo: necesitas una herramienta. Pierdes comodidad y ganas que la máquina la interprete sin ambigüedad ni trucos de espaciado.

La segunda, la importante: la multiplexación. Multiplexar es meter muchas conversaciones independientes por un mismo canal. HTTP/2 parte la conexión en flujos —streams— y cada petición va por el suyo, con su etiqueta. Van y vuelven entremezclados por una sola conexión.

Ya no hace falta abrir seis. Y ya no hay bloqueo del primero de la fila dentro de HTTP.

Además comprime las cabeceras con un algoritmo propio, HPACK, que es justo lo que hacía falta: recuerda que las cabeceras eran la mayor parte del peso y que en una página se repiten casi idénticas en cada una de sus cientos de peticiones.

Parece resuelto. Y aquí vuelve la promesa de TCP.

Porque debajo de esos flujos sigue habiendo una única conexión TCP. Y TCP prometió entregar todo, en orden. Así que cuando se pierde un paquete —y se pierden— TCP se planta: espera a que le retransmitan esa pieza antes de entregar nada de lo que venga detrás. Aunque lo de detrás ya haya llegado. Aunque sea de otro flujo que no tiene nada que ver.

El bloqueo del primero de la fila no desapareció: se mudó de capa. Antes bloqueaba HTTP; ahora bloquea TCP. Y desde HTTP no se puede arreglar, porque el problema está por debajo.

Por eso HTTP/2 rinde espectacularmente bien en una red buena y puede rendir peor que HTTP/1.1 con seis conexiones en una red con pérdidas: seis conexiones son seis colas independientes, y una sola conexión multiplexada es una cola que se congela entera.

HTTP/3 y QUIC: cambiarle el transporte a HTTP

HTTP/3 (2022). Como el problema ya no era de HTTP, la solución no fue tocar HTTP. Fue cambiarle el transporte.

HTTP/3 tira TCP y se monta sobre QUIC, que va sobre UDP. UDP no promete orden ni entrega: solo manda. Y sobre esa base tan simple, QUIC reconstruye lo que hacía falta —fiabilidad, orden y control de congestión— pero por flujo. Cada flujo lleva su propia cuenta de qué ha llegado y qué falta.

Si se pierde un paquete de una imagen, se para esa imagen. El resto sigue llegando.

De propina, QUIC lleva el cifrado dentro, integrado con TLS 1.3, no como una capa aparte encima. Eso permite montar la conexión y cifrarla en menos idas y vueltas: donde TCP más TLS necesitaban dos o tres viajes antes de la primera petición, QUIC lo hace en uno.

Y quédate con esto, porque es lo que casi nunca se dice: HTTP/3 no es «HTTP más rápido». Los mensajes son los mismos. Los métodos, los mismos. Los códigos de estado, los mismos. HTTP/3 es HTTP con otro transporte debajo.

Un detalle práctico: el navegador no adivina que un sitio habla HTTP/3. Se entera porque la respuesta trae una cabecera Alt-Svc anunciándolo —o porque el DNS publica un registro HTTPS—, y a partir de ahí lo intenta por QUIC. La primera visita casi siempre entra por HTTP/2.

HTTPS: dónde se mete TLS y qué no cambia

Todo lo que hemos visto viaja en claro. Esa carta legible, con tu ruta, tus cabeceras y tus cookies, la puede leer cualquiera que esté en el camino: tu operador, la wifi de la cafetería, cualquier equipo por el que pase.

HTTPS es esto mismo más una capa de cifrado. La S es de secure. Y la clave está en dónde se mete esa capa: ni por encima de HTTP ni por debajo de IP, sino justo entre HTTP y TCP.

HTTP      ← el mensaje, intacto
TLS       ← aquí entra el cifrado
TCP
IP
ENLACE

Esa capa se llama TLS, y no cambia el mensaje: coge la carta tal cual y la mete en un sobre cerrado. Por eso todo lo de este artículo sigue valiendo igual en HTTPS: los métodos, los códigos, las cabeceras y el cuerpo son exactamente los mismos.

Lo que sí cambia es lo que ve quien esté escuchando por el camino. Con HTTPS ya no ve la ruta, ni las cabeceras, ni las cookies, ni el contenido. Sigue viendo a qué dirección IP te conectas y, en la mayoría de los casos, a qué dominio, porque el nombre viaja en claro en la negociación inicial para que el servidor sepa qué certificado presentar.

Y una aclaración de nombres, que se lía siempre: SSL es el nombre viejo. Se quedó en la versión 3.0 y lo sustituyó TLS —Transport Layer Security—, que ya va por la 1.3. Llevamos más de veinte años usando TLS y llamándolo SSL; los certificados todavía se venden como «certificados SSL». No es un error tuyo: es inercia del sector.

Verlo tú mismo

Nada de esto es teoría abstracta. La carta se puede leer.

Lo más directo es pedirla a mano por el puerto 80, escribiendo el protocolo tú mismo. Esto manda exactamente los bytes de una petición HTTP/1.1 y te devuelve la respuesta en crudo:

printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80

Ahí está todo: la línea de petición, la cabecera Host obligatoria y la línea en blanco final. Si te saltas esa línea en blanco, el servidor se queda esperando más cabeceras y no contesta.

Con curl se ve lo mismo sin escribir el protocolo a mano. La opción -v imprime la petición con > y la respuesta con <:

curl -v https://antoniocintora.com/

Si solo te interesan las cabeceras de la respuesta, -I manda un HEAD:

curl -I https://antoniocintora.com/

Y este es el que responde a la pregunta del vídeo: imprime la versión que se ha negociado de verdad y el código de estado, sin descargar el cuerpo.

curl -s -o /dev/null -w '%{http_version} %{http_code}\n' https://antoniocintora.com/

Puedes forzar una versión concreta para comparar: --http1.1, --http2 o --http3. Ten en cuenta que --http3 solo funciona si tu curl está compilado con soporte de QUIC; compruébalo con curl --version y busca HTTP3 en la lista de funcionalidades.

En Windows, sin salir de PowerShell:

(Invoke-WebRequest -Uri https://antoniocintora.com/ -Method Head).Headers

Y sin tocar la terminal: abre las herramientas de desarrollo del navegador con F12, ve a la pestaña Red, recarga y añade la columna Protocolo —clic derecho sobre la fila de encabezados de la tabla—. Verás h2, h3 o http/1.1 en cada petición. Es el sitio donde más rápido se comprueba todo lo de este artículo: el método, el código de estado, las cabeceras y la versión, fila por fila.

Errores que verás en producción

Glosario

Preguntas frecuentes

Resumamos

HTTP es un acuerdo de formato y de orden, sin memoria, en el que el cliente manda un mensaje y el servidor devuelve otro. Ese mensaje tiene cuatro partes y, en HTTP/1.1, se puede leer con los ojos.

No viaja como un paquete: se lo entrega a TCP, que lo trocea en segmentos; IP los convierte en paquetes al ponerles origen y destino, y el enlace los mete en tramas. Sobres dentro de sobres, en los que cada capa lee el suyo y no mira los de dentro.

Y las versiones son una cadena: cada una arregla el atasco de la anterior, hasta que HTTP/3 tuvo que cambiar de transporte para arreglar uno que ya no era suyo.

Queda abierto lo que sostiene todo esto: cómo se ponen de acuerdo dos máquinas que no se conocen para elegir una clave secreta delante de todo el mundo, y quién decide en quién confía tu navegador. Eso es TLS, y va en el siguiente.

Recursos oficiales