Apuntes redes

No vayas a access.log, donde habitan los monstruos.

Una Introducción: ¿Qué es HTTP?

HTTP (Hypertext Transfer Protocol) es el protocolo que sirve como base para la comunicación en la web. Permite que un cliente (como un navegador) solicite recursos a un servidor, y que este responda con los datos solicitados: páginas HTML, imágenes, archivos, etc.
Se basa en un modelo de solicitud-respuesta, donde el cliente inicia el contacto y el servidor devuelve una respuesta estructurada.

Una característica esencial del protocolo HTTP es que es sin estado, es decir, cada solicitud se procesa de forma independiente, sin recordar solicitudes previas. Aunque tecnologías como las cookies o las sesiones permiten simular cierta continuidad, el protocolo en sí no mantiene ningún historial.

¿Cómo funciona HTTP?

HTTP opera bajo una arquitectura cliente-servidor y las interacciones se producen a través de mensajes estructurados:

Solicitud del cliente

Una solicitud HTTP incluye:

  • Un método (como GET, POST, etc.) que indica la acción a realizar.
  • Una URL para identificar el recurso solicitado.
  • Encabezados que aportan información adicional (tipo de contenido aceptado, idioma preferido, etc.).
  • Un cuerpo, que en algunas solicitudes contiene datos (por ejemplo, los de un formulario).

Respuesta del servidor

La respuesta HTTP contiene:

  • Un código de estado (como 200 OK, 404 Not Found, etc.) que indica el resultado de la solicitud.
  • Encabezados con metadatos (tipo de contenido, fecha, longitud, etc.).
  • Un cuerpo que incluye el contenido solicitado (como una página HTML, un JSON, una imagen…).

Características clave de HTTP

  • Basado en texto: Tanto solicitudes como respuestas pueden leerse directamente (usando caracteres ascii), lo que facilita su comprensión y depuración (esto dejará de ser cierto con HTTP/3).
  • Extensible: El protocolo permite añadir encabezados personalizados según necesidades.
  • Versátil y evolutivo: HTTP/2 y HTTP/3 mejoran el rendimiento con nuevas técnicas, como la multiplexación y el uso de UDP.
  • Sin conexión (en versiones anteriores): HTTP/1.0 cerraba la conexión tras cada solicitud, aunque HTTP/1.1 permite conexiones persistentes.

Seguridad: de HTTP a HTTPS

HTTP transmite datos en texto plano, lo que expone la información a posibles interceptaciones. Por eso, la mayoría de sitios modernos usan HTTPS, una versión de HTTP cifrada mediante TLS/SSL. Con HTTPS se garantiza:

  • Confidencialidad: Los datos no pueden ser leídos por terceros.
  • Integridad: El mensaje no se modifica durante la transmisión.
  • Autenticidad: El servidor es quien dice ser, gracias a certificados digitales.

Una reflexión sobre la filosofía de diseño: la Ley de Postel

Jon Postel, uno de los pioneros de la arquitectura de Internet, formuló una regla que influyó profundamente en el diseño de muchos protocolos de red, incluido HTTP:

“Sé conservador en lo que envías, y liberal en lo que aceptas.”

Este principio, conocido como la Ley de Postel, favorecía la tolerancia del sistema ante pequeñas imperfecciones. Si los sistemas fueran extremadamente rígidos al recibir, cualquier error menor podría romper la comunicación. En sus inicios, HTTP aplicaba esta filosofía: los servidores y navegadores eran indulgentes con espacios extra, formatos ligeramente incorrectos, encabezados desconocidos…

Por qué sigue siendo vigente?

  1. Interoperabilidad: En un mundo con una vasta diversidad de implementaciones de software (navegadores, servidores, APIs, dispositivos, etc.), el principio de Postel es clave para que todo funcione bien junto. Si cada sistema fuera estrictamente inflexible, cualquier pequeña desviación de un estándar (ya sea por un error o una interpretación diferente) rompería la comunicación. Al ser liberal en la recepción, un sistema puede dejar pasar pequeñas imperfecciones de otros, lo que le hace ser más resiliente ante errores humanos o de software.

  2. Evolución y Flexibilidad: Los protocolos y las especificaciones evolucionan. Ser liberal en la recepción facilita la introducción de nuevas características o variaciones sin romper la compatibilidad con implementaciones más antiguas o ligeramente diferentes.

  3. Experiencia de Usuario: Piensa en un navegador web. Si fuera estrictamente conservador al recibir, muchas páginas web (especialmente las antiguas o las que tienen pequeños errores de código) no se cargarían correctamente. Gracias a que es liberal, puede interpretar y mostrar la mayoría de las páginas, incluso con fallos menores.

Pero el contexto cambia…

Internet, y HTTP con él, ha evolucionado, desde un cuasi-experimento destinado al intercambio de archivos de texto en un entorno académico, al actual maremagnum que es hoy Internet. Con el crecimiento de la web y el aumento de amenazas como XSS, clickjacking o exfiltración de datos, esa permisividad de los inicios se puede convertir en vulnerabilidad. En el diseño de nuevos protocolos se propone validar estrictamente lo que se recibe y no confiar automáticamente en la entrada. Así nacieron las cabeceras de seguridad, que imponen reglas claras para proteger aplicaciones y usuarios:

  • Content-Security-Policy: restringe de dónde se pueden cargar scripts y recursos.
  • Strict-Transport-Security: obliga al navegador a usar HTTPS sin excepción.
  • X-Frame-Options: impide que el sitio sea incrustado en un <iframe> malicioso.
  • X-Content-Type-Options: evita que el navegador adivine el tipo de archivo.
  • Parámetros en Set-Cookie: evitan fugas o accesos indebidos a las cookies.

Este giro marca un equilibrio necesario: seguir siendo interoperables y flexibles donde no haya riesgo, pero ser rigurosos en entornos sensibles.

Conclusión

Aquí un desglose rápido:

  • HTTP/1.0 y la naturaleza "sin conexión" (non-persistent connections): En esta versión, cada vez que un navegador necesitaba un recurso (una imagen, un archivo HTML, un CSS), abría una nueva conexión TCP al servidor, descargaba el recurso y luego cerraba la conexión. Esto generaba mucha sobrecarga porque establecer y cerrar conexiones es costoso en tiempo y recursos.

  • HTTP/1.1 y las conexiones persistentes (persistent connections o Keep-Alive): Esta fue una de las mejoras más significativas. HTTP/1.1 introdujo la capacidad de mantener una conexión TCP abierta después de una solicitud-respuesta. Esto significa que múltiples solicitudes y respuestas pueden ser enviadas sobre la misma conexión, reduciendo drásticamente la latencia y la carga del servidor, especialmente al cargar una página web con muchos recursos pequeños.

  • HTTP/2 y HTTP/3 (Multiplexing y Conexiones aún más eficientes): HTTP/2 llevó esto un paso más allá con la multiplexación. Esto permite que múltiples solicitudes y respuestas se envíen simultáneamente sobre una única conexión, resolviendo el "Head-of-Line Blocking" que todavía podía ocurrir en HTTP/1.1. HTTP/3, por su parte, cambia el protocolo de transporte subyacente de TCP a UDP (con QUIC), mejorando aún más la eficiencia de las conexiones y la resistencia a los cambios de red.

En resumen, HTTP sigue siendo el pilar de la web moderna. A pesar de su simplicidad inicial, ha evolucionado hacia un protocolo más rápido, seguro y matizado. Al comprender cómo se estructura, cómo se interpreta y cómo se asegura, no solo se aprende a trabajar con él, sino a entender mejor el funcionamiento profundo de Internet.

TOP