HTTP son las siglas de Hypertext Transfer Protocol (protocolo de transferencia de hipertexto). Se trata de un protocolo de solicitud-respuesta en la capa de aplicación web. HTTP tiene una arquitectura cliente-servidor que permite la transferencia fiable de recursos entre un servidor de aplicaciones web y un agente de usuario (UA), como un navegador web. Los UA incluyen rastreadores web, aplicaciones móviles y otro software que se utiliza para acceder a recursos web.
HTTP se diseñó para facilitar la comunicación entre dispositivos y aplicaciones web. Define cómo se formatean y transmiten las solicitudes de contenido y cómo se construyen las respuestas. HTTP transmite contenidos como texto, imágenes, audio y vídeo mediante un conjunto de protocolos denominado Protocolo de Control de Transmisión/Protocolo Internet (TCP/IP).
A medida que HTTP ha ido evolucionando, cada versión ha ido añadiendo nuevas funciones y cada una realiza algunos procesos, como la gestión de conexiones, de forma diferente.
Tim Berners-Lee, considerado el fundador de la Web, escribió la primera versión de HTTP. Las especificaciones de HTTP, Hypertext Markup Language (HTML) y Uniform Resource Identifier (URI) se redactaron entre 1989 y 1990. El primer servidor web empezó a funcionar en 1991.
Un protocolo de Internet es un conjunto de reglas que definen cómo se comunican los dispositivos de una red de Internet. Este conjunto de normas se basa en estándares comunes que se crean mediante peticiones de comentarios (RFC). Las RFC son la compilación de las normas que se utilizan en la comunicación de red en Internet. Las RFC son gestionadas por el Grupo de Trabajo de Ingeniería de Internet (IETF), principal órgano normativo del funcionamiento de Internet. Algunos ejemplos de protocolos de red comunes son HTTP, TCP, IP, FTP y Secure Shell (SSH).
Los protocolos de red pueden desglosarse aún más. El modelo de Interconexión de Sistemas Abiertos (OSI) es un marco conceptual que describe las funciones de un sistema informático. Consta de siete capas: física, enlace de datos, red, transporte, sesión, presentación y aplicación. Los datos de cada capa son gestionados por protocolos diferentes. HTTP es un protocolo de capa 7 (aplicación), que no debe confundirse con la capa de red del modelo OSI.
Los datos en Internet se gestionan y transmiten mediante una pila de protocolos de red que se denominan colectivamente TCP/IP. Cada capa de la pila puede asignarse a capas del modelo OSI y cada una tiene una función diferente. HTTP forma parte de la capa de aplicación y permite que distintas aplicaciones se comuniquen entre sí. Utiliza TCP para establecer sesiones entre un cliente y un servidor. TCP forma parte de la capa de transporte de la pila. Divide los mensajes en paquetes de datos en su origen, que luego se reensamblan en su destino. IP en el acrónimo TCP/IP es el protocolo que dirige paquetes de datos a un ordenador específico a través de una dirección IP. IP forma parte de la capa de red de la pila.
En teoría, HTTP podría utilizar un protocolo de capa de transporte alternativo a TCP, como UDP, pero HTTP casi siempre utiliza TCP, que está basado en conexiones y es más fiable que UDP. Es el preferido por las aplicaciones en las que los datos deben ser fiables, relevantes y completos, por ejemplo una noticia. UDP es un protocolo sin conexión y no puede retransmitir paquetes de datos perdidos. Sin embargo, UDP es más rápido que TCP y se utiliza a menudo en aplicaciones como videoconferencias y streaming, donde los pequeños contratiempos en la transferencia apenas se notan. Sin embargo, la versión preliminar más reciente de HTTP, HTTP/3, aborda algunos de los problemas de TCP y UDP, combinando características de dos protocolos: HTTP/2 y QUIC sobre UDP. HTTP/3 también se denomina HTTP-sobre-QUIC.
QUIC es un protocolo de red que funciona como alternativa a una combinación de TCP, Transport Layer Security (TLS) y HTTP/2. Está implementado sobre UDP. QUIC transporta el tráfico HTTP/3 sobre UDP de forma más rápida y eficaz que las versiones HTTP más antiguas que utilizan TCP. QUIC reduce la latencia de la conexión, mejora el control de la congestión, permite la multiplexación sin bloqueo de cabecera, posibilita la corrección de errores y permite la migración de conexiones. QUIC está totalmente encriptado con TLS 1.3 por defecto. UDP es un protocolo sin conexión, por lo que una de las principales funciones de QUIC es garantizar la fiabilidad de la conexión permitiendo, por ejemplo, la retransmisión de paquetes.
La primera versión de HTTP sólo incluía el método de solicitud GET y carecía de cabeceras, metadatos como el tipo de contenido o códigos de estado. Como HTTP/09 no utilizaba cabeceras, sólo se podían devolver al cliente páginas HTML (hipertexto). Tras recibir una respuesta del servidor, el cliente cerraba inmediatamente la conexión. HTTP/09 es, en su mayor parte, obsoleto, pero algunos servidores web populares como nginx todavía lo soportan.
HTTP/1.0 admitía los métodos GET y POST y añadía información sobre versiones y códigos de estado. Se introdujeron las cabeceras, que permitían especificar un tipo de contenido para poder transmitir archivos distintos de HTML. Tras recibir una respuesta del servidor, el cliente cerraba inmediatamente la conexión. La introducción de las cabeceras en HTTP/1.0 hizo que HTTP fuera muy extensible.
Cuando se solicita una página web, ésta debe renderizarse en varias partes, por ejemplo contenido de texto y otros contenidos como imágenes o vídeos. Los archivos de imagen, vídeo y audio tienen sus propias URL, y cada archivo debe solicitarse por separado. En HTTP/1, esto significaba que había que hacer múltiples solicitudes individuales al servidor e iniciar múltiples conexiones. HTTP/1.1 introdujo las conexiones persistentes y el pipelining. Una conexión persistente no se cierra por defecto después de realizar una solicitud. Pipelining significa que un cliente puede hacer peticiones sucesivas en una transacción sin esperar respuesta del servidor. Las conexiones persistentes y el pipelining permiten enviar sucesivamente hipertexto y otros archivos, como imágenes, desde el servidor al cliente a través de una única conexión con latencia reducida. HTTP/1.1 también permitía métodos adicionales, como DELETE, PUT y TRACE. Esta versión introdujo el almacenamiento en caché, las cookies de cliente, las transferencias codificadas y la negociación de contenidos. La negociación de contenidos permitía al servidor y al cliente seleccionar el contenido más adecuado para el intercambio en términos de idioma, codificación o tipo de contenido. HTTP/1.1 también hizo que la estandarización de HTTP fuera más coherente y actualmente es la versión HTTP más utilizada.
Basado en SPDY, HTTP/2 es un protocolo de comunicaciones obsoleto desarrollado por Google para reducir la latencia de carga de las páginas web y mejorar la seguridad. Se diseñó para mejorar el rendimiento de la web y reducir costes, ya que HTTP/1.1 era caro en términos de uso de recursos de CPU. HTTP/2 introdujo la multiplexación avanzada, que es la capacidad de transmitir eficazmente datos de múltiples recursos en una sola sesión utilizando tramas HTTP y flujos HTTP. Esta función se introdujo para solucionar los problemas de bloqueo de cabecera HTTP de HTTP/1.1 y permitir la comunicación paralela a través de una única conexión TCP. El bloqueo de cabecera HTTP se refiere al escenario en el que las sucesivas solicitudes en un flujo pueden bloquearse si hay un problema con la solicitud actual en la cola o si aún no se ha completado.
Mientras que las solicitudes y respuestas HTTP/1.1 están en formato de texto, las tramas HTTP/2 utilizan formato binario.
Las tramas binarias HTTP/2 descomponen una solicitud de mensaje en unidades lógicas separadas, como tramas de encabezado y tramas de datos, cada una de las cuales está codificada en binario y comparte un ID de flujo HTTP común. Un flujo HTTP/2 es una solicitud única, bidireccional y lógica que comprende múltiples tramas. En HTTP/2, se pueden enviar varios flujos (multiplexados) a través de una única conexión TCP a un servidor que, a continuación, mapea las tramas por su ID de flujo y las vuelve a ensamblar en mensajes de solicitud HTTP/2 completos de acuerdo con una prioridad de mensaje predeterminada. La multiplexación permite realizar varias solicitudes a través de una conexión y el servidor también puede enviar varias respuestas al cliente de la misma manera. Esta función evita el bloqueo de cabeceras en la capa de aplicación y mejora el rendimiento.
HTTP/2 también ha mejorado la gestión de errores y el control de flujo, así como la función "push" del servidor. Server push significa que el servidor puede enviar al cliente datos no solicitados explícitamente, por ejemplo recursos que el servidor intuye que puede necesitar el cliente. El servidor notificará primero al cliente lo que pretende enviar y éste podrá rechazarlo.
Según W3Techs HTTP/2 es utilizado por alrededor del 46% de los sitios web. No es compatible con las versiones anteriores de HTTP.
La tercera versión de HTTP, HTTP/3, está diseñada para mejorar el rendimiento de HTTP/2 y aborda algunos problemas de HTTP/2. HTTP/3 utiliza UDP en la capa de transporte en lugar de TCP. El bloqueo de cabecera de línea en la capa TCP en HTTP/2 se resuelve mediante el uso de UDP. El bloqueo de cabecera de línea TCP se refiere al escenario en el que, si se pierde un paquete, se bloquea un mensaje hasta que se pueda recuperar el paquete. HTTP/3 permite conexiones más rápidas, ya que no depende de las direcciones IP. Utiliza identificadores de conexión para que las descargas sean coherentes incluso cuando se produce un cambio en la red. A diferencia de TCP, UDP no requiere que se confirme una transferencia de datos antes de transmitir la siguiente solicitud. Las conexiones también son más rápidas porque hay que enviar menos paquetes de datos por flujos paralelos. Para establecer una conexión, TCP utiliza un handshake de tres vías. UDP crea una conexión en una ida y vuelta. Dado que TLS 1.3 está integrado en HTTP/3, sólo admite conexiones cifradas (HTTPS).
Las alertas personalizadas y la visualización de datos le permiten identificar y prevenir rápidamente los problemas de salud y rendimiento de la red.
Las cabeceras hacen que HTTP sea extensible, ya que el cliente y el servidor pueden acordar añadir nuevos nombres de campo e información que se adapten a sus necesidades.
Aunque puede hacerlo, un servidor HTTP no está obligado a almacenar información entre una solicitud y otra. Esta característica hizo que las primeras versiones de HTTP fueran apátridas. Las solicitudes en las versiones anteriores a HTTP/2 se realizaban de forma independiente, sin conocimiento de lo ocurrido en solicitudes anteriores. HTTP se diseñó como un modelo sin estado principalmente para la escalabilidad; las solicitudes HTTP pueden dirigirse a cualquier servidor porque el servidor no necesita mantener un estado concreto para un cliente. Esto facilita la ampliación del número de servidores en función de la carga de trabajo prevista, ya que mantener una conexión persistente consumiría muchos recursos. Cuando es necesario interactuar con un sitio web de forma progresiva, por ejemplo al comprar en línea, el HTTP puede utilizar cookies, sesiones del lado del servidor, reescritura de URL o variables ocultas para permitir sesiones con estado Estas soluciones alternativas se denominan funciones con estado. Otra ventaja de la ausencia de estado es que, en la mayoría de los casos, se minimiza la cantidad de datos que hay que transferir.
Toda la pila TCP/IP no es apátrida. TCP en la capa de transporte es apátrida, manteniendo el estado de una sesión HTTP y asegurando que los paquetes de datos perdidos puedan ser retransmitidos.
HTTP se considera generalmente sin conexión porque, después de que el cliente haya establecido una conexión con un servidor, enviado una solicitud y recibido una respuesta, la conexión se interrumpe inmediatamente. HTTP también se considera sin conexión porque las conexiones de red se controlan en la capa de transporte, no en la capa de aplicación. HTTP utiliza TCP, que se basa en la conexión, en la capa de transporte.
Siempre que tanto el cliente como el servidor sepan cómo manejar un contenido de datos específico especificado por el tipo MIME en una cabecera, se puede enviar cualquier tipo de datos a través de HTTP. MIME son las siglas de Multipurpose Internet Mail Extensions.
HTTP se utiliza en la web siempre que sea necesario transferir datos entre un cliente y un servidor, por ejemplo API, servicios web y solicitudes de navegador.
HTTP suele ser utilizado por usuarios que no tienen información confidencial por la que deban preocuparse, que no desean adquirir un certificado SSL o que no quieren la complejidad de mantener un sitio seguro.
Las primeras versiones de HTTP carecían de estado, pero no de sesión. Normalmente, una sesión HTTP tiene tres pasos, con algunas variaciones en cómo se manejan los pasos en las diferentes versiones.
En primer lugar, el cliente establece una conexión con el servidor. En la mayoría de las versiones de HTTP, se trata de una conexión TCP, pero HTTP/3 utiliza UDP en la capa de transporte.
En segundo lugar, el cliente envía un mensaje de solicitud para ver una página web, por ejemplo. Un método de solicitud en el mensaje especifica la acción que debe realizar el servidor. Por ejemplo, para ver una página web, el cliente utilizará el método GET .
En tercer lugar, el servidor procesa la solicitud y devuelve un mensaje de respuesta al cliente, por ejemplo, el contenido de la página web solicitada si la solicitud se ha realizado correctamente, y un código de estado.
En las versiones de HTTP anteriores a HTTP/1.1, la conexión se cerraba por defecto tras la finalización de una solicitud. Si el cliente quería que la conexión se mantuviera abierta, tenía que especificarlo activando la cabecera de conexión Keep-Alive. HTTP/1.1 y las versiones HTTP posteriores permiten al cliente enviar mensajes de solicitud adicionales y la conexión se mantiene viva por defecto. Por lo tanto, si un cliente recibe un código de error, es posible que desee reintentar la solicitud. Si el cliente desea que se cierre la conexión, debe especificarlo con la cabecera Close Connection.
Entre el cliente y el servidor hay otros muchos servidores llamados proxies, que son intermediarios que realizan funciones adicionales como cifrar contenidos, cachear y comprimir datos, equilibrar la carga, registrar y proporcionar conexiones compartidas para usuarios concurrentes.
Los mensajes HTTP se intercambian en un formato similar a MIME. MIME es un estándar para el correo por Internet que permite ampliar el formato de las solicitudes de mensajes para que admitan datos que no sean texto plano ASCII. Las cabeceras tipo MIME en HTTP tienen una función similar; por ejemplo, permiten a un cliente seleccionar la aplicación adecuada para abrir archivos que no sean de texto, como vídeo, imágenes, ejecutables, audio, etc.
Las solicitudes HTTP y las respuestas HTTP utilizan el mismo formato de mensaje. Los mensajes constan de una línea de inicio (una línea de solicitud en el caso de un mensaje de solicitud o una línea de estado en el caso de un mensaje de respuesta), uno o más campos de cabecera opcionales, una línea vacía que indica que no hay más campos de cabecera y un cuerpo de mensaje opcional.
La línea de inicio incluye la versión del protocolo y alguna información sobre el tipo de solicitud, en el caso de un mensaje de solicitud, o el éxito o fracaso de la solicitud, en el caso de un mensaje de respuesta.
Las cabeceras HTTP permiten incluir información adicional sobre la solicitud o la respuesta, como el método de solicitud en el caso de los mensajes de solicitud y la longitud del contenido devuelto en el caso de los mensajes de respuesta.
El cuerpo opcional del mensaje en una petición puede incluir la información que necesita ser cargada o borrada de un servidor. El cuerpo opcional de un mensaje de respuesta puede incluir el contenido solicitado por el cliente.
El uso de cabeceras es lo que hace que HTTP sea flexible y extensible como cliente, y un servidor puede crear nuevas cabeceras relevantes para una transacción siempre que ambos estén de acuerdo en el formato.
Algunas cabeceras HTTP son específicas de los mensajes de solicitud o respuesta, por ejemplo la cabecera Accept-Language es específica de los mensajes de solicitud. Sin embargo, algunas cabeceras pueden aparecer tanto en peticiones como en respuestas. Por ejemplo, la cabecera Content-Type, clasificada como cabecera de representación, puede incluirse en mensajes de solicitud o de respuesta. En el primer caso, especifica qué tipo de contenido desea el cliente. En el segundo, especifica qué tipo de contenido devuelve el servidor.
Las cabeceras de solicitud pueden incluir información adicional sobre el cliente y el recurso. Por ejemplo, el Identificador Uniforme de Recursos (URI) es el recurso sobre el que el método necesita actuar para obtener información de un sitio web específico, por ejemplo. Las cabeceras de solicitud HTTP también pueden especificar información sobre qué datos deben almacenarse en caché, información general sobre la conexión, detalles de autenticación, fecha y hora, información sobre la codificación de la transferencia, en qué formato puede utilizarse la información para transferir el contenido, etc.
Las cabeceras de solicitudAccept -como Accept-language y Accept-encoding- y algunas cabeceras de representación complementarias -como Content-Language y Content-Encoding- permiten la función de negociación de contenidos de HTTP. Las cabeceras Accept especifican las preferencias del cliente y las cabeceras de representación complementaria en la respuesta especifican lo que el servidor realmente devolvió.
Las cabeceras de respuesta pueden incluir información adicional sobre el servidor y el recurso. También pueden especificar cualquier cookie, la longitud del contenido devuelto, el tipo de contenido, cuándo se modificó el contenido por última vez, etc.
Existen cabeceras especiales para numerosas funciones HTTP como autenticación, tipos de conexión, almacenamiento de cookies, descarga de archivos, gestión de proxy, seguridad, codificación de transferencias, etc.
HTTP es un modelo de solicitud-respuesta para la comunicación en red. Su contrapartida es el modelo de publicación-suscripción, en el que un servidor (también llamado broker) recibe y distribuye datos, mientras que el cliente publica datos en el servidor para actualizarlos o se suscribe a él para recibir información. En el modelo de publicación-suscripción, los datos se intercambian automáticamente, pero sólo cuando cambian o si la información es nueva. MQTT es un ejemplo de protocolo de transporte que utiliza el modelo publicar-suscribir.
Web Real-Time Communication (WebRTC) se utiliza para realizar conexiones peer-to-peer (P2P), que permiten compartir fácilmente datos de aplicaciones y archivos multimedia como audio y vídeo. Facebook Messenger es un ejemplo de aplicación que utiliza WebRTC.
QUIC utiliza TCP pero está compilado sobre UDP. QUIC se diseñó para reducir la latencia en las transferencias de datos por Internet y resolver algunos problemas de HTTP/2. Google Chrome es un ejemplo de aplicación que utiliza QUIC.
El Sistema Interplanetario de Archivos (IPFS) es una alternativa reciente a HTTP que tiene una arquitectura P2P distribuida y permite elegir entre conexiones TCP, QUIC o WebRTC. Con su arquitectura distribuida, fue diseñado para resolver los problemas de fallo del servidor que son comunes a los modelos de protocolo de comunicación de red centralizados como HTTP.
Sensor HTTP Página web completa
Monitoreo HTTP en la nube
Contenido HTTP del sensor
El Protocolo Seguro de Transferencia de Hipertexto (HTTPS) es básicamente HTTP con cifrado; "envuelve" los mensajes HTTP en un formato cifrado. HTTPS utiliza Transport Layer Security (TLS) para cifrar las solicitudes y respuestas HTTP.
HTTP y HTTPS utilizan puertos diferentes. Habitualmente, HTTP utiliza el puerto 80 y HTTPS el 443 aunque, en teoría, se puede utilizar cualquier puerto excepto los que están reservados para servicios específicos.
La principal ventaja de utilizar HTTPS es la mejora de la seguridad. Para sitios web que no transfieran información confidencial, HTTP podría ser una opción aceptable y menos compleja de configurar y mantener. Además, en 2014, Google anunció que utilizaría HTTPS como señal de clasificación ligera para animar a las empresas a cambiar de HTTP a HTTPS.
Hay algunas desventajas sutiles y, en la práctica, menores en el uso de HTTPS en lugar de HTTP. En primer lugar, puede haber una sobrecarga adicional en la transferencia de datos, ya que primero hay que hacer un intercambio de datos. En segundo lugar, el proceso de generación de claves de cifrado puede impedir que el servidor realice otras tareas. En tercer lugar, algunos contenidos no se pueden cachear localmente porque los datos están encriptados.
Por defecto, HTTP/3 sólo está disponible con HTTPS.
Las notificaciones en tiempo real significan una solución de problemas más rápida para que pueda actuar antes de que se produzcan problemas más graves.
TCP es más fiable pero más lento que UDP. Sin embargo, cuando UDP se combina con QUIC, el resultado es una transmisión de paquetes rápida y fiable mediante HTTP/3. HTTP/3 aún está en pañales. A principios de 2021, había sido habilitado por aplicaciones populares como Google, WhatsApp, YouTube y Facebook, pero no por aplicaciones igualmente populares como Uber o Twitter.
HTTP/3 es todavía un borrador RFC, pero es compatible, según Wikipedia, con casi el 75 por ciento de los navegadores web y, según W3Techs, con el 21 por ciento de los 10 millones de sitios web para los que W3Techs proporciona datos de uso.
La comercialización de Internet ha dado lugar a una mayor necesidad de análisis y monitoreo de la red en tiempo real para proporcionar a las organizaciones el máximo tiempo de actividad. El monitoreo y análisis de paquetes - llamado packet sniffing - es la clave para analizar qué paquetes se pierden, cuándo y por qué, con el fin de mantener un rendimiento alto y consistente.
La herramienta de monitoreo de paquetes de PTRG monitorea y analiza cada paquete en su red para identificar el ancho de banda utilizado, los acaparadores de ancho de banda y las potenciales brechas de seguridad. El rastreador de paquetes monitorea todo el tráfico HTTP, HTTPS, UDP y TCP, así como otro tráfico de correo, transferencia de archivos, control remoto e infraestructura.
La herramienta de sensores web de PTRG le permite monitorear servidores web que utilizan HTTP para asegurarse de que las páginas web estén siempre accesibles.
