Una descripción general de HTTP

HTTP es un protocolo para obtener recursos como documentos HTML. Es la base de cualquier

intercambio de datos en la web y es un protocolo cliente-servidor, lo que significa que las
solicitudes las inicia el destinatario, generalmente el navegador web. Se reconstruye un documento
completo a partir de los diferentes subdocumentos obtenidos, por ejemplo, texto, descripción del
diseño, imágenes, videos, guiones y más.

Los clientes y los servidores se comunican intercambiando mensajes individuales (a diferencia de

un flujo de datos). Los mensajes enviados por el cliente, generalmente un navegador web, se
denominan solicitudes y los mensajes enviados por el servidor como respuesta se
denominan respuestas .
Diseñado a principios de la década de 1990, HTTP es un protocolo extensible que ha evolucionado
con el tiempo. Es un protocolo de capa de aplicación que se envía a través de TCP , o a través de
una conexión TCP encriptada con TLS , aunque teóricamente se podría usar cualquier protocolo de
transporte confiable. Debido a su extensibilidad, se utiliza no solo para obtener documentos de
hipertexto, sino también imágenes y videos o para publicar contenido en servidores, como con los
resultados de formularios HTML. HTTP también se puede usar para obtener partes de documentos
para actualizar páginas web a pedido.

Componentes de sistemas basados ​en HTTP

HTTP es un protocolo cliente-servidor: las solicitudes las envía una entidad, el agente de usuario (o
un proxy en su nombre). La mayoría de las veces, el agente de usuario es un navegador web, pero
puede ser cualquier cosa, por ejemplo, un robot que rastrea la web para completar y mantener un
índice de motor de búsqueda.

Cada solicitud individual se envía a un servidor, que la maneja y proporciona una respuesta
llamada respuesta . Entre el cliente y el servidor existen numerosas entidades, denominadas
colectivamente proxies , que realizan diferentes operaciones y actúan como pasarelas o cachés ,
por ejemplo.
En realidad, hay más computadoras entre un navegador y el servidor que maneja la solicitud: hay
enrutadores, módems y más. Gracias al diseño en capas de la Web, estas quedan ocultas en las
capas de red y transporte. HTTP está en la parte superior, en la capa de aplicación. Aunque son
importantes para diagnosticar problemas de red, las capas subyacentes son en su mayoría
irrelevantes para la descripción de HTTP.

Cliente: el agente de usuario

El agente de usuario es cualquier herramienta que actúa en nombre del usuario. Esta función la
realiza principalmente el navegador web, pero también pueden realizarla los programas que
utilizan los ingenieros y los desarrolladores web para depurar sus aplicaciones.

El navegador es siempre la entidad que inicia la solicitud. Nunca es el servidor (aunque se han

agregado algunos mecanismos a lo largo de los años para simular mensajes iniciados por el
servidor).

Para mostrar una página web, el navegador envía una solicitud original para obtener el documento
HTML que representa la página. Luego analiza este archivo y realiza solicitudes adicionales
correspondientes a secuencias de comandos de ejecución, información de diseño (CSS) para
mostrar y subrecursos contenidos en la página (generalmente imágenes y videos). El navegador
web luego combina estos recursos para presentar el documento completo, la página web. Los
scripts ejecutados por el navegador pueden obtener más recursos en fases posteriores y el
navegador actualiza la página web en consecuencia.

Una página Web es un documento de hipertexto. Esto significa que algunas partes del contenido
que se muestra son enlaces, que se pueden activar (generalmente con un clic del mouse) para
obtener una nueva página web, lo que permite al usuario dirigir su agente de usuario y navegar
por la web. El navegador traduce estas instrucciones en solicitudes HTTP y, además, interpreta las
respuestas HTTP para presentar al usuario una respuesta clara.

El servidor web

En el lado opuesto del canal de comunicación se encuentra el servidor, que sirve el documento

solicitado por el cliente. Un servidor aparece virtualmente como una única máquina; pero en
realidad puede ser una colección de servidores que comparten la carga (equilibrio de carga), o una
pieza compleja de software que interroga a otras computadoras (como caché, un servidor de base
de datos o servidores de comercio electrónico), generando total o parcialmente el documento bajo
demanda.
Un servidor no es necesariamente una sola máquina, pero se pueden alojar varias instancias de
software de servidor en la misma máquina. Con HTTP/1.1 y el  Host encabezado, incluso pueden
compartir la misma dirección IP.

apoderados

Entre el navegador web y el servidor, numerosas computadoras y máquinas transmiten los

mensajes HTTP. Debido a la estructura en capas de la pila web, la mayoría de estos operan en los
niveles de transporte, red o físico, se vuelven transparentes en la capa HTTP y pueden tener un
impacto significativo en el rendimiento. Aquellos que operan en las capas de aplicación
generalmente se denominan proxies . Estos pueden ser transparentes, reenviando las solicitudes
que reciben sin alterarlas de ninguna manera, o no transparentes, en cuyo caso cambiarán la
solicitud de alguna manera antes de pasarla al servidor. Los proxies pueden realizar numerosas
funciones:

almacenamiento en caché (el caché puede ser público o privado, como el caché del
navegador)
filtrado (como un análisis antivirus o controles parentales)
Equilibrio de carga (para permitir que varios servidores atiendan diferentes solicitudes)
autenticación (para controlar el acceso a diferentes recursos)
registro (permitiendo el almacenamiento de información histórica)

Aspectos básicos de HTTP

HTTP es simple

HTTP generalmente está diseñado para ser simple y legible por humanos, incluso con la
complejidad adicional introducida en HTTP/2 al encapsular mensajes HTTP en marcos. Los
humanos pueden leer y comprender los mensajes HTTP, lo que facilita las pruebas para los
desarrolladores y reduce la complejidad para los recién llegados.

HTTP es extensible

Introducidos en HTTP/1.0, los encabezados HTTP hacen que este protocolo sea fácil de ampliar y
experimentar. Incluso se puede introducir una nueva funcionalidad mediante un simple acuerdo
entre un cliente y un servidor sobre la semántica de un nuevo encabezado.

HTTP es sin estado, pero no sin sesión

HTTP no tiene estado: no existe un vínculo entre dos solicitudes que se realizan sucesivamente en
la misma conexión. Esto tiene la perspectiva inmediata de ser problemático para los usuarios que
intentan interactuar con ciertas páginas de manera coherente, por ejemplo, utilizando cestas de
compras de comercio electrónico. Pero mientras que el núcleo de HTTP en sí no tiene estado, las
cookies de HTTP permiten el uso de sesiones con estado. Usando la extensibilidad del encabezado,
las cookies HTTP se agregan al flujo de trabajo, lo que permite la creación de sesiones en cada
solicitud HTTP para compartir el mismo contexto o el mismo estado.
HTTP y conexiones

Una conexión se controla en la capa de transporte y, por lo tanto, fundamentalmente fuera del
alcance de HTTP. HTTP no requiere que el protocolo de transporte subyacente esté basado en
conexión; solo requiere que sea confiable , o que no pierda mensajes (como mínimo, que presente
un error en tales casos). Entre los dos protocolos de transporte más comunes en Internet, TCP es
confiable y UDP no lo es. Por lo tanto, HTTP se basa en el estándar TCP, que se basa en la conexión.

Antes de que un cliente y un servidor puedan intercambiar un par de solicitud/respuesta HTTP,

deben establecer una conexión TCP, un proceso que requiere varios viajes de ida y vuelta. El
comportamiento predeterminado de HTTP/1.0 es abrir una conexión TCP independiente para cada
par de solicitud/respuesta HTTP. Esto es menos eficiente que compartir una sola conexión TCP
cuando se envían varias solicitudes en una sucesión cercana.

Para mitigar este defecto, HTTP/1.1 introdujo canalización (que resultó difícil de implementar)

y conexiones persistentes : la conexión TCP subyacente se puede controlar parcialmente mediante
el  Connection encabezado. HTTP/2 fue un paso más allá al multiplexar mensajes a través de una
sola conexión, lo que ayudó a mantener la conexión cálida y más eficiente.

Se están realizando experimentos para diseñar un mejor protocolo de transporte más adecuado
para HTTP. Por ejemplo, Google está experimentando con QUIC , que se basa en UDP para
proporcionar un protocolo de transporte más confiable y eficiente.

Qué puede ser controlado por HTTP

Esta naturaleza extensible de HTTP, con el tiempo, ha permitido un mayor control y funcionalidad
de la Web. Los métodos de caché y autenticación fueron funciones manejadas al principio de la
historia de HTTP. La capacidad de relajar la restricción de origen , por el contrario, solo se agregó en
la década de 2010.

Aquí hay una lista de características comunes controlables con HTTP:

Almacenamiento en caché : HTTP puede controlar cómo se almacenan los documentos en

caché. El servidor puede instruir a los proxies y clientes sobre qué almacenar en caché y por
cuánto tiempo. El cliente puede indicar a los proxies de caché intermedios que ignoren el
documento almacenado.
Relajación de la restricción de origen : para evitar la intromisión y otras invasiones de la
privacidad, los navegadores web imponen una separación estricta entre los sitios web. Sólo las
páginas de un mismo origen pueden acceder a toda la información de una página
Web. Aunque tal restricción es una carga para el servidor, los encabezados HTTP pueden
relajar esta separación estricta en el lado del servidor, lo que permite que un documento se
convierta en un mosaico de información proveniente de diferentes dominios; incluso podría
haber razones relacionadas con la seguridad para hacerlo.
Autenticación : algunas páginas pueden estar protegidas para que solo usuarios específicos
puedan acceder a ellas. La autenticación básica puede ser proporcionada por HTTP, ya sea
 usando los  WWW-Authenticate encabezados y similares, o configurando una sesión específica
usando cookies HTTP .
Proxy y tunelización : los servidores o clientes a menudo se encuentran en intranets y ocultan
su verdadera dirección IP de otras computadoras. Las solicitudes HTTP luego pasan por
proxies para cruzar esta barrera de red. No todos los servidores proxy son servidores proxy
HTTP. El protocolo SOCKS, por ejemplo, opera a un nivel más bajo. Estos proxies pueden
manejar otros protocolos, como ftp.
Sesiones : el uso de cookies HTTP le permite vincular las solicitudes con el estado del
servidor. Esto crea sesiones, a pesar de que HTTP básico es un protocolo sin estado. Esto es
útil no solo para las cestas de la compra de comercio electrónico, sino también para cualquier
sitio que permita la configuración de la salida por parte del usuario.

flujo HTTP

Cuando un cliente quiere comunicarse con un servidor, ya sea el servidor final o un proxy
intermedio, realiza los siguientes pasos:

1. Abrir una conexión TCP: La conexión TCP se utiliza para enviar una solicitud, o varias, y recibir
una respuesta. El cliente puede abrir una nueva conexión, reutilizar una conexión existente o
abrir varias conexiones TCP a los servidores.
2. Envíe un mensaje HTTP: los mensajes HTTP (antes de HTTP/2) son legibles por humanos. Con
HTTP/2, estos mensajes simples se encapsulan en marcos, lo que los hace imposibles de leer
directamente, pero el principio sigue siendo el mismo. Por ejemplo:

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

3. Lea la respuesta enviada por el servidor, como:

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html>… (here come the 29769 bytes of the requested web page)

4. Cierre o reutilice la conexión para más solicitudes.

Si la canalización HTTP está activada, se pueden enviar varias solicitudes sin esperar a que se reciba
completamente la primera respuesta. La canalización de HTTP ha resultado difícil de implementar
en las redes existentes, donde las piezas antiguas de software coexisten con las versiones
modernas. La canalización HTTP se reemplazó en HTTP/2 con solicitudes de multiplexación más
sólidas dentro de un marco.

Mensajes HTTP

Los mensajes HTTP, tal como se definen en HTTP/1.1 y versiones anteriores, son legibles por
humanos. En HTTP/2, estos mensajes están incrustados en una estructura binaria, un marco , lo que
permite optimizaciones como la compresión de encabezados y la multiplexación. Incluso si solo se
envía una parte del mensaje HTTP original en esta versión de HTTP, la semántica de cada mensaje
no cambia y el cliente reconstituye (virtualmente) la solicitud HTTP/1.1 original. Por lo tanto, es útil
comprender los mensajes HTTP/2 en el formato HTTP/1.1.

Hay dos tipos de mensajes HTTP, solicitudes y respuestas, cada uno con su propio formato.

Peticiones

Un ejemplo de solicitud HTTP:

Las solicitudes constan de los siguientes elementos:

Un método HTTP , generalmente un verbo como  GET ,  POST o un sustantivo

como  OPTIONS o  HEAD que define la operación que el cliente desea realizar. Por lo general,
un cliente quiere obtener un recurso (usando  GET ) o publicar el valor de un formulario
HTML (usando  POST ), aunque en otros casos se pueden necesitar más operaciones.
La ruta del recurso a buscar; la URL del recurso desprovista de elementos que son obvios por
el contexto, por ejemplo, sin el protocolo (  http:// ), el dominio (aquí, ) o
el puerto developer.mozilla.org  TCP (aquí, ). 80
La versión del protocolo HTTP.
Encabezados opcionales que transmiten información adicional para los servidores.
 Un cuerpo, para algunos métodos como  POST , similar a los de las respuestas, que contiene el
recurso enviado.

Respuestas

Un ejemplo de respuesta:

Las respuestas constan de los siguientes elementos:

La versión del protocolo HTTP que siguen.

Un código de estado , que indica si la solicitud fue exitosa o no, y por qué.
Un mensaje de estado, una breve descripción no autorizada del código de estado.
Encabezados HTTP , como los de las solicitudes.
Opcionalmente, un cuerpo que contiene el recurso obtenido.

API basadas en HTTP

La API más utilizada basada en HTTP es la  XMLHttpRequest API, que se puede utilizar para
intercambiar datos entre un agente de usuario y un servidor. El moderno  Fetch API proporciona las
mismas funciones con un conjunto de funciones más potente y flexible.
Otra API, los eventos enviados por el servidor , es un servicio unidireccional que permite que un
servidor envíe eventos al cliente, utilizando HTTP como mecanismo de transporte. Usando
la  EventSource interfaz, el cliente abre una conexión y establece controladores de eventos. El
navegador del cliente convierte automáticamente los mensajes que llegan en el flujo HTTP
en  Event objetos apropiados. Luego, los entrega a los controladores de eventos que se han
registrado para los eventos  type si se conocen, o al  onmessage controlador de eventos si no se
estableció un controlador de eventos específico del tipo.

Conclusión

HTTP es un protocolo extensible que es fácil de usar. La estructura cliente-servidor, combinada con
la capacidad de agregar encabezados, permite que HTTP avance junto con las capacidades
extendidas de la Web.

Aunque HTTP/2 agrega algo de complejidad al incorporar mensajes HTTP en marcos para mejorar
el rendimiento, la estructura básica de los mensajes se ha mantenido igual desde HTTP/1.0. El flujo
de sesión sigue siendo simple, lo que permite investigarlo y depurarlo con un simple monitor de
mensajes HTTP .