HTTP (Hypertext Transfer Protocol) es un protocolo de request-response sin estado que usan clientes y servidores para intercambiar recursos como páginas HTML, respuestas de API en JSON, imágenes y archivos. Corre en la capa de aplicación (Capa 7) y típicamente usa TCP (HTTP/1.1, HTTP/2) o QUIC sobre UDP (HTTP/3) como transporte.
Resumen rápido — HTTP es el protocolo estándar de la web para solicitar y entregar recursos mediante un modelo de request-response sin estado, operando en la Capa 7 y dependiendo de TCP o QUIC para el transporte. Cada request contiene un método (GET, POST, PUT, PATCH, DELETE), una ruta, headers y un cuerpo opcional; cada respuesta contiene un código de estado, headers y un cuerpo opcional. HTTP ha evolucionado de HTTP/0.9 (1991, solo GET) a HTTP/3 (2019, sobre QUIC/UDP), mejorando en cada versión el desempeño, la seguridad y la latencia. Como HTTP en texto plano no está cifrado, la decisión de producción correcta es usar HTTPS para prácticamente todo el tráfico web y de API modernos.
Última actualización: 2026-08-08
En otras palabras, si no lo recuerdas o no lo has notado, aparece al principio de la dirección de un sitio web. HTTP es un protocolo de transferencia de capa de aplicación basado en texto y se considera la base de la comunicación de datos entre dispositivos conectados en red. Durante este proceso de request-response, HTTP usa estándares y reglas predefinidas para el intercambio de información. En general, HTTP es el protocolo que usan clientes y servidores para comunicarse.
Además, para que ocurra el intercambio de datos, HTTP depende de otros dos protocolos de red: TCP (Transmission Control Protocol) e IP (Internet Protocol). De ahí surge el modelo TCP/IP, que es parte del proceso de comunicación entre clientes y servidores, y también entre servidores y API móviles/web. HTTP es el protocolo más usado para aplicaciones web y API.
Nota que TCP/IP es un modelo, pero también una pila de protocolos en la que cae HTTP. En cuanto al modelo OSI, del que hablaremos más adelante, TCP es la capa 4 e IP es la capa 3.
Cuándo usar HTTP (y HTTPS)
- Cuando construyes sitios web y aplicaciones web accedidas por navegadores.
- Cuando expones o consumes API (REST/JSON, GraphQL sobre HTTP).
- Cuando necesitas métodos estándar (GET/POST/PUT/PATCH/DELETE) y códigos de estado para modelar operaciones.
- Cuando quieres caching, negociación de contenido, y compatibilidad con proxy/CDN.
- Cuando integras con infraestructura común de internet (load balancers, gateways, CDN, WAF).
En la práctica, usa HTTPS para prácticamente todo el tráfico público (HTTP cifrado con TLS).
Cuándo no usar HTTP
- Cuando necesitas mensajería bidireccional en tiempo real con overhead mínimo (considera WebSocket o streaming gRPC).
- Cuando la carga de trabajo es máquina a máquina de baja latencia con contratos estrictos y protocolos binarios (considera gRPC).
- Cuando la red es restringida y necesitas semántica pub/sub (considera MQTT).
- Cuando necesitas semántica de transferencia de archivos con características especializadas (considera SFTP/FTPS según los requisitos).
- Cuando usar HTTP forzaría un modelado poco natural (ej. telemetría de alta frecuencia sin agrupamiento por lotes).
Señales de que necesitas entender HTTP (síntomas)
- Los usuarios reportan que “el sitio está lento” pero la CPU del backend se ve bien.
- Ves muchos errores 4xx/5xx y no sabes si son problemas del lado del cliente o del servidor.
- Problemas de CORS: errores de navegador tipo “blocked by CORS policy”.
- El caching no funciona: los assets se descargan de nuevo; el cache hit ratio es bajo.
- Las sesiones se “rompen aleatoriamente” por un mal entendimiento de la ausencia de estado, las cookies o los headers.
- No puedes explicar por qué HTTP/2 ayuda pero el head-of-line blocking sigue ocurriendo en algunas redes.
Cómo funciona HTTP (modelo mental para tomar decisiones)
1) URL → dónde y cómo conectarse
Una URL le indica al cliente:
- Esquema:
http://ohttps://(reglas + expectativas de seguridad) - Host:
example.com(dónde conectarse) - Ruta:
/products/123(qué recurso) - Opcional: query
?page=2, fragmento#faq
2) El cliente abre una conexión
- HTTP/1.1 y HTTP/2 típicamente usan TCP.
- HTTP/3 usa QUIC, que corre sobre UDP.
3) El cliente envía un request HTTP
Un request contiene:
- Método (GET, POST, PUT, PATCH, DELETE, etc.)
- Ruta/URI
- Headers (metadatos como
Host,Accept,Authorization) - Un cuerpo opcional (común en POST/PUT/PATCH)
4) El servidor devuelve una respuesta HTTP
Una respuesta contiene:
- Código de estado (ej. 200, 301, 401, 404, 500)
- Headers (ej.
Content-Type,Cache-Control) - Un cuerpo opcional (HTML, JSON, bytes de imagen, etc.)
5) Las cachés e intermediarios pueden participar
Las CDN, proxies y navegadores pueden almacenar respuestas y reutilizarlas según las reglas de caching de HTTP.
Naturaleza sin estado
HTTP no tiene estado a nivel de aplicación: cada request se procesa de forma independiente, y el servidor no está obligado a recordar requests anteriores.
El estado usualmente se agrega vía cookies, tokens, o sesiones del lado del servidor referenciadas por identificadores.
Es decir, incluso si se hacen varios requests al mismo tiempo, uno no sabe que el otro existe, y el servidor no almacena ninguna información sobre el estado del cliente. En cuanto se hace una conexión TCP, toda la información intercambiada se pierde. Las ventajas de esto son una reducción en el uso de memoria del servidor y una reducción en los problemas derivados de una sesión expirada.
También es importante mencionar que HTTP no tiene estado si se ve desde un nivel alto de abstracción, pero también se basa en TCP (no UDP), y por lo tanto está basado en conexión y tiene estado desde el punto de vista de una capa inferior. Lo que esto significa es que, por estar basado en conexión, tiene estado en la entrega, lo que asegura que todos los paquetes se reciban y secuencien correctamente.
URL
Ya sabemos qué es una URL, y que es el primer paso en el proceso de intercambio de información. Pero, aunque es parte de nuestra vida diaria en línea, muchos no sabemos qué significa su estructura. Así que consideremos la siguiente URL:
En su forma básica, podemos dividir la URL en tres partes:
- El protocolo (http:// o https://) — le dice a tu navegador cómo comunicarse con el servidor de un sitio web para enviar y recuperar información. Cuando es HTTPS, es un HTTP seguro que tiene algunos estándares adicionales de seguridad y texto cifrado.
- El dominio (azion.com) — tiene el subdominio (blog.), el nombre por el cual se conoce al sitio web (azion), y el TLD (.com). TLD significa Top Level Domain (dominio de nivel superior), que es la categoría de los sitios web como .com (comercial), .org (organizaciones), y .net (redes).
- La ruta (/edge) — dirige al navegador a una página específica del sitio web.
Historia de HTTP
Empecemos con el término hipertexto, creado por Ted Nelson en 1965 y definido como “escritura no secuencial”. En otras palabras, es un tipo de texto que se ramifica, no es necesariamente lineal y contiene enlaces a otros textos. Este término, a su vez, se inspiró en las ideas de Vannevar Bush presentadas previamente en su artículo de 1945 As We May Think.
Después, en 1989, Tim Berners-Lee propuso el proyecto WorldWideWeb y, en 1991, él y su equipo crearon un protocolo que permitiría recuperar textos de otros documentos vía enlaces de hipertexto, el cual se convertiría en el formato HTTP original. Los hipertextos fueron los primeros archivos que usaron HTML (HyperText Mark-up Language), un formato textual para representar documentos en hipertexto. El HTML, igual que el hipertexto, es texto, pero puede servir como comandos, incluyendo llamar a otros assets como imágenes, videos, audios, etc. Su última versión es HTML5.
Como todo lo demás en el mundo de internet, el protocolo HTTP ha pasado por varias transformaciones y ha evolucionado mucho, como se puede ver a continuación.
- HTTP/0.9 — La primera versión se lanzó en 1991 y era muy simple. Se enfocaba en la transferencia de texto y solo tenía el método de request GET; no tenía headers HTTP, ni códigos de estado o error.
- HTTP/1.0 — Esta versión posterior es de 1996, y presentó, además de la transferencia simple de texto, la transmisión de datos más sofisticados, como metadatos de request/response y negociación de contenido.
- HTTP/1.1 — Esta versión de 1999 se considera un hito en la evolución de internet, ya que eliminó varios problemas de versiones anteriores e introdujo una serie de optimizaciones, como un mecanismo de caché adicional, transferencias con codificación fragmentada, pipelining de requests y cifrado de la transferencia. Aunque hay una versión más reciente, esta sigue siendo el estándar y la versión más usada en el mundo.
- HTTP/2 — Esta versión es de 2015 y está mejor preparada para el uso masivo y generalizado de internet actual. Aunque no hubo cambios en la semántica respecto a la versión anterior, algunos beneficios notables son un mejor desempeño en el transporte de información y datos, y una latencia significativamente menor.
- HTTP/3 — Lanzado en 2019, el protocolo HTTP/3 es todavía más rápido, confiable y seguro. Presenta una diferencia fundamental respecto a la versión anterior: un nuevo protocolo de transporte, QUIC. QUIC se basa en UDP (User Datagram Protocol), que es más rápido que TCP transmitiendo datos, ya que no pasa por el proceso de verificación de datos; esto, sin embargo, lo hace menos seguro. Aunque no es un transporte confiable, QUIC agrega una capa extra a UDP, brindando características como retransmisión de paquetes y control de congestión. Otra característica importante de HTTP/3 es que soporta HTML5, la versión más moderna de HTML, que agrega la capacidad de hacer programación nativa.
Versiones de HTTP (qué cambia, qué no)
| Versión | Transporte | Cambio clave | Impacto típico |
|---|---|---|---|
| HTTP/1.1 | TCP | Conexiones persistentes, mejores reglas de caching | Ampliamente compatible; puede sufrir de head-of-line blocking por conexión |
| HTTP/2 | TCP | Multiplexación, compresión de headers | Mejor carga de página bajo concurrencia; sigue teniendo head-of-line de TCP a nivel de transporte |
| HTTP/3 | QUIC sobre UDP | Rediseño de transporte + handshakes más rápidos | Mejor desempeño en redes con pérdida; reduce algunos problemas de latencia |
Entendiendo dónde se ubica HTTP en el rompecabezas de la comunicación
HTTP es una pieza pequeña en la pila de comunicación, pero ¿cómo se ubica en ella? Para entenderlo mejor, primero echemos un vistazo rápido al modelo OSI.
El modelo OSI (Open System Interconnection), creado por la Organización Internacional de Normalización en 1971, es un modelo de redes de computadoras que sirve como estándar, o reglas, para los protocolos de comunicación entre distintos sistemas en una red. Es decir, es como si fuera un lenguaje universal para las redes de computadoras. En este modelo, el sistema de comunicación se divide en siete capas abstractas, cada una con una funcionalidad específica.
El protocolo HTTP actúa precisamente en la capa 7, la capa de aplicación, donde ocurre la interacción entre usuarios y computadoras, por ejemplo, cuando los usuarios visitan un sitio web o revisan correos electrónicos. La capa de aplicación es responsable de los protocolos y la manipulación de datos de los que depende el software para presentar datos significativos al usuario. Además de HTTP, otros protocolos que operan en la capa de aplicación son: HTTPS, DNS, FTP, IMAP, MIME, POP, RTP, SMTP, TELNET, TFTP y TLS.
La comunicación HTTP
Cuando un cliente quiere comunicarse con un servidor, lo primero que pasa, después de que el usuario escribe la URL en la barra de direcciones del navegador o va a otra página, es abrir una conexión TCP/IP, y se envía el request HTTP al servidor. En ese request, hay un mensaje con una serie de datos que describen lo que el cliente solicitó. El servidor entonces envía la respuesta al cliente, que también contiene datos que se pueden leer. Finalmente, el proceso de request-response se termina. Ten en cuenta que todo esto usualmente toma microsegundos en ocurrir.
En el proceso de comunicación que describimos arriba, puede que hayas notado que hay dos agentes esenciales: el request y la respuesta.
Mensajes HTTP
¿Qué es un request?
El request es lo que el cliente necesita del servidor. En ese mensaje, hay datos específicos, que describen lo que se solicitó. Los componentes principales de un request se describen abajo.
- El método — indica la acción que el cliente quiere realizar, como:
- GET — para obtener recursos o recuperar datos del servidor; es el más común.
- POST — para enviar datos al servidor, como el envío de un formulario.
- HEAD — para obtener la línea de respuesta y los headers.
- PUT — para enviar archivos al servidor o hacer una actualización completa de un recurso.
- PATCH — para hacer una actualización parcial de un recurso.
- DELETE — para eliminar documentos dentro del servidor.
- OPTIONS — para consultar qué comandos están disponibles para un usuario dado.
- TRACE — para depurar requests, devolviendo un header de documento.
- La ruta — el URI (Uniform Resource Identifier) del recurso a buscar.
- La versión del protocolo HTTP.
- Los headers del request — que contienen información adicional para los servidores.
- El cuerpo del request — opcional y necesario para algunos métodos, como POST, y contiene el recurso solicitado.
¿Qué es una respuesta?
La respuesta que da el servidor contiene la información solicitada por el cliente o informa que hubo un error en relación con lo solicitado. Contiene los elementos listados abajo.
- El header de respuesta — contiene la versión del protocolo, el código de estado del request y el tipo de contenido incluido en el cuerpo.
- El código de estado — indica si el request se respondió exitosamente o no. La respuesta se da mediante códigos específicos, como:
- 200 — el request se respondió exitosamente.
- 301 — el request se movió permanentemente.
- 401 — el request no fue autorizado por el servidor.
- 404 — el request no fue encontrado por el servidor.
- 500 — error interno del servidor.
- El cuerpo de la respuesta — como en el request, es opcional y contiene datos sobre el recurso solicitado.
Otro aspecto interesante de la comunicación HTTP es el uso de caché, que mantiene copias de datos que se acceden con frecuencia. Básicamente, la caché acelera la búsqueda y entrega de datos usados frecuentemente y evita el uso de recursos en un servidor, mejorando el desempeño y la velocidad del proceso, pero eso es un tema para otro artículo.
La desventaja de HTTP
Ya viste que el protocolo HTTP es la base de cualquier intercambio de información en internet, pero, como todo en esta vida, tiene un problema: no es seguro. ¿Sabías que esta es exactamente la razón por la que es blanco de acciones maliciosas? Entre los cibercrímenes que pueden afectar al protocolo HTTP, podemos mencionar la interceptación de datos durante la transmisión de información y los ataques DDoS en la capa 7, también conocidos como ataques HTTP flood, que sobrecargan un servidor con requests HTTP. Cuando el servidor ya no puede responder al tráfico normal, los requests de los usuarios legítimos sufrirán una denegación de servicio.
Aunque todos los sitios y aplicaciones están sujetos a cibercrimen, la buena noticia es que hay algunas formas de protegerse contra estas amenazas, como: Web Application Firewall, DDoS Protection, y Network Layer Protection.
Soluciones de seguridad avanzadas
El Web Application Firewall (WAF) mejora la seguridad de las aplicaciones web al defenderlas contra una amplia gama de amenazas, desde vulnerabilidades del OWASP Top 10 hasta ataques de día cero sofisticados. Protege la capa de aplicación (capa 7), donde las aplicaciones interactúan con los servicios de red, actuando como una barrera protectora que aplica un conjunto de reglas para filtrar y monitorear el tráfico entre la aplicación e internet. En términos prácticos, el WAF se enfoca en proteger los protocolos HTTP/S analizando requests, detectando y bloqueando actividades maliciosas antes de que puedan impactar la infraestructura, todo sin comprometer el desempeño de la aplicación.
La solución de DDoS Protection ofrece múltiples capas de defensa contra ataques DDoS, incluyendo los que apuntan a la capa 7, donde opera el protocolo HTTP. Al aprovechar una red distribuida globalmente junto con centros de mitigación especializados, brinda la inteligencia y escalabilidad requeridas para neutralizar incluso los ataques más complejos y a gran escala.
Para una cobertura de seguridad todavía más amplia, Network Layer Protection establece un perímetro de seguridad programable en el edge de la red, controlando el tráfico entrante y saliente. Esta solución habilita la capacidad de bloquear amenazas, monitorear comportamiento sospechoso, y aplicar penalizaciones como limitaciones de acceso.
Adoptar estas estrategias de mitigación ayuda a las empresas a mantenerse resilientes frente a amenazas cibernéticas emergentes, incluyendo ataques cada vez más frecuentes y a gran escala, explotación dirigida de API, y metodologías de ataque en evolución.
La importancia de HTTP
HTTP es un protocolo simple, pero más que eso, es una característica notable que también es accesible, ya que fue diseñado para tener mensajes que puedan ser leídos y entendidos por cualquier usuario. Además, su naturaleza sin estado simplifica el desempeño del servidor y lo hace más rápido, ya que no hay necesidad de almacenar o limpiar datos para los siguientes requests. Si una transacción se interrumpe, ninguna parte del sistema necesita ser responsable de limpiar el estado actual del servidor. Otro aspecto fundamental es el hecho de que es extensible, lo que permite la inserción de nuevas funcionalidades y, en consecuencia, HTTP sigue las necesidades y la evolución de internet en su misión de transmitir los datos que prácticamente hacen funcionar al mundo.
Métricas y cómo medir el desempeño y la confiabilidad de HTTP
- Latencia (de extremo a extremo): tiempo desde que se envía el request hasta que se recibe la respuesta.
- Mídelo con RUM, pruebas sintéticas, o APM; separa DNS, conexión, TLS, TTFB, descarga.
- TTFB (Time To First Byte): la capacidad de respuesta del servidor + la red antes de la descarga del cuerpo.
- Un TTFB alto a menudo indica problemas de backend, distancia al origen, o encolamiento.
- Tasas de código de estado:
- Tasa de 5xx (errores de servidor), tasa de 4xx (cliente/auth/validación), tasa de 429 (rate limiting).
- Cache hit ratio: % de requests servidos desde caché en el navegador/CDN/edge.
- Un hit ratio bajo a menudo significa headers de caché incorrectos o URL demasiado únicas.
- Throughput (RPS) y error budget:
- Da seguimiento a la capacidad bajo carga; correlaciona picos de error con deployments.
- Métricas de conexión:
- Tiempo de handshake TLS, retransmisiones (especialmente en móvil), adopción de HTTP/2 vs HTTP/3.
- Tamaño de payload:
- HTML/JSON/imágenes grandes aumentan el tiempo de descarga; comprime donde sea apropiado.
Errores comunes (y cómo corregirlos)
- Error: usar HTTP (sin TLS) para cualquier cosa sensible.
- Corrección: usa HTTPS por defecto; redirige HTTP→HTTPS; habilita HSTS donde sea apropiado.
- Error: usar mal los métodos (ej. cambiar datos con GET).
- Corrección: usa GET para recuperación segura; usa POST/PUT/PATCH/DELETE para mutaciones.
- Error: headers de caché que previenen el caching o causan contenido obsoleto.
- Corrección: configura
Cache-Controlde forma intencional; usa assets versionados inmutables; valida con ETag. - Error: tratar los 4xx como “problemas del servidor”.
- Corrección: segmenta las métricas por clase de estado; investiga 401/403 de auth, 404 de enrutamiento, 429 de throttling.
- Error: asumir que “sin estado” significa “sin sesiones”.
- Corrección: agrega estado vía cookies/tokens; mantén el almacenamiento de sesión explícito y seguro.
- Error: ignorar a los intermediarios (CDN/proxies) y depurar solo en el origen.
- Corrección: registra/rastrea los IDs de request de extremo a extremo; verifica los headers en cada salto.
Seguridad: la principal desventaja de HTTP
HTTP en texto plano no está cifrado, así que el tráfico puede ser interceptado o modificado en tránsito. Regla de decisión: usa HTTPS para prácticamente todo el tráfico web y de API modernos y agrega protecciones a nivel de aplicación contra ataques comunes de Capa 7 (ej. abuso de bots, inyección, HTTP floods).
Las amenazas comunes a nivel HTTP incluyen:
- Credential stuffing y fuerza bruta en endpoints de login
- Ataques del OWASP Top 10 (inyección, XSS, etc.)
- DDoS de Capa 7 (HTTP floods) que abruman las aplicaciones con requests de apariencia legítima
Cómo aplica esto en la práctica
Si operas un sitio web o API en producción, las decisiones de HTTP típicamente incluyen:
- Elección de protocolo: habilita HTTP/2 y evalúa HTTP/3 para desempeño en redes móviles/inestables.
- Estrategia de caching: decide qué se puede cachear, por cuánto tiempo, y dónde (navegador vs. edge vs. origen).
- Autenticación: elige entre cookies vs. tokens bearer; aplica headers seguros y TLS.
- Protección: aplica reglas de WAF, rate limiting, y mitigación DDoS para endpoints de Capa 7.
- Observabilidad: recolecta logs/métricas/trazas ligados a IDs de request para depurar latencia y errores.
Preguntas frecuentes
¿HTTP es lo mismo que HTTPS? No. HTTPS es HTTP sobre TLS, que cifra la conexión y autentica al servidor.
¿Por qué se dice que HTTP no tiene estado? Entonces, ¿cómo funcionan los logins? HTTP no requiere que el servidor recuerde requests anteriores; los logins funcionan enviando cookies o tokens en cada request.
¿Qué versión de HTTP debería usar? Usa HTTP/2 por defecto para amplia compatibilidad; considera HTTP/3 cuando necesites mejor desempeño en redes con pérdida y tu stack lo soporte.
¿Qué significan 301, 401, 404 y 500? 301 = redirección permanente; 401 = no autorizado; 404 = no encontrado; 500 = error de servidor.
¿Cómo hago más rápido a HTTP? Reduce el TTFB, habilita el caching, comprime los payloads, usa HTTP/2 o HTTP/3, y acerca el contenido a los usuarios con infraestructura de edge/CDN.
¿Cuál es la diferencia entre un request y una respuesta HTTP? Un request lo envía el cliente al servidor e incluye un método, una ruta, headers y un cuerpo opcional. Una respuesta la devuelve el servidor al cliente e incluye un código de estado, headers y un cuerpo opcional.
¿Qué protocolo de transporte usa cada versión de HTTP? HTTP/1.1 y HTTP/2 usan TCP. HTTP/3 usa QUIC, que corre sobre UDP.
¿Por qué es importante la capa 7 del modelo OSI para HTTP? HTTP opera en la capa 7 (capa de aplicación) del modelo OSI, donde ocurre la interacción entre usuarios y aplicaciones. Otros protocolos de esta capa incluyen HTTPS, DNS, FTP y SMTP.
¿Qué es un ataque HTTP flood? Es un ataque DDoS de Capa 7 que sobrecarga un servidor con requests HTTP de apariencia legítima, agotando su capacidad de responder al tráfico real de usuarios.
¿Cómo protejo mi sitio de amenazas a nivel HTTP? Usa HTTPS en todo el tráfico, aplica un Web Application Firewall (WAF), implementa protección DDoS, y agrega protección a nivel de red para controlar el tráfico entrante y saliente en el edge.
Glosario (referencia rápida)
- URL: dirección de un recurso (esquema + host + ruta + query/fragmento opcional).
- URI: identificador de un recurso (más amplio que una URL).
- Método: acción (GET/POST/PUT/PATCH/DELETE).
- Headers: metadatos de request/response.
- Código de estado: señal de resultado (2xx éxito, 3xx redirección, 4xx error de cliente, 5xx error de servidor).
- Cache-Control / ETag: controles de caching de HTTP.
- Capa 7 de OSI: la capa de aplicación donde opera HTTP.
Resumen
HTTP es el protocolo estándar de la web para solicitar y entregar recursos mediante un modelo de request-response sin estado, operando en la Capa 7 y dependiendo de TCP o QUIC para el transporte. En producción, las decisiones clave son: usar HTTPS, elegir HTTP/2 o HTTP/3, diseñar el caching correctamente, medir la latencia/TTFB y las tasas de error, y proteger los endpoints con controles de seguridad de Capa 7.