Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Tools & Tips

HTTP: el protocolo que todo desarrollador web debe saber - Parte 2

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Juan Pablo Diaz Cuartas (you can also view the original English article)

En mi artículo anterior, cubrimos algunos de los conceptos básicos de HTTP, como el esquema de URL, los códigos de estado y los encabezados de solicitud / respuesta. Con eso como nuestra base, veremos los aspectos más finos de HTTP, como el manejo de la conexión, la autenticación y el almacenamiento en caché de HTTP. Estos temas son bastante extensos, pero cubriremos los bits más importantes.


Conexiones HTTP

Se debe establecer una conexión entre el cliente y el servidor antes de que puedan comunicarse entre sí, y HTTP utiliza el protocolo de transporte TCP confiable para realizar esta conexión. De forma predeterminada, el tráfico web usa el puerto TCP 80. Una secuencia TCP se divide en paquetes IP y garantiza que esos paquetes siempre lleguen en el orden correcto sin falta. HTTP es un protocolo de capa de aplicación sobre TCP, que está sobre IP.

HTTPS es una versión segura de HTTP, insertando una capa adicional entre HTTP y TCP llamada TLS o SSL (Transport Layer Security o Secure Sockets Layer, respectivamente). HTTPS se comunica a través del puerto 443 de forma predeterminada, y veremos HTTPS más adelante en este artículo.

HTTP and HTTPS layers

Una conexión HTTP se identifica por <source-IP, source-port> y <destination-IP, destination-port>. En un cliente, una aplicación HTTP se identifica mediante una <IP, port> tupla . Establecer una conexión entre dos puntos finales es un proceso de varios pasos e implica lo siguiente:

Connection Delays
  • resolver la dirección IP del nombre de host a través de DNS
  • establecer una conexión con el servidor
  • enviar una solicitud
  • espera una respuesta
  • conexión cercana

El servidor es responsable de responder siempre con los encabezados y respuestas correctos.

En HTTP / 1.0, todas las conexiones se cerraron después de una sola transacción. Entonces, si un cliente desea solicitar tres imágenes separadas del mismo servidor, realiza tres conexiones separadas con el host remoto. Como puede ver en el diagrama anterior, esto puede introducir muchas demoras en la red, lo que resulta en una experiencia de usuario no óptima.

Para reducir los retrasos en el establecimiento de la conexión, HTTP / 1.1 introdujo conexiones persistentes, conexiones de larga duración que permanecen abiertas hasta que el cliente las cierra. Las conexiones persistentes son predeterminadas en HTTP / 1.1, y hacer una conexión de transacción única requiere que el cliente configure la conexión: cierre el encabezado de la solicitud. Esto le dice al servidor que cierre la conexión después de enviar la respuesta.

Además de las conexiones persistentes, los navegadores / clientes también emplean una técnica, llamada conexiones en paralelo, para minimizar los retrasos en la red. El concepto antiguo de conexiones paralelas implica crear un conjunto de conexiones (generalmente limitado a seis conexiones). Si hay seis activos que el cliente necesita descargar de un sitio web, el cliente realiza seis conexiones paralelas para descargar esos activos, lo que da como resultado un cambio más rápido. Esta es una gran mejora con respecto a las conexiones en serie, donde el cliente solo descarga un activo después de completar la descarga de un activo anterior.

Las conexiones en paralelo, en combinación con conexiones persistentes, son la respuesta actual para minimizar los retrasos en la red y crear una experiencia fluida en el cliente. Para un tratamiento en profundidad de las conexiones HTTP, consulte la sección Conexiones de la especificación HTTP.

Manejo de la conexión del lado del servidor

El servidor generalmente escucha las conexiones entrantes y las procesa cuando recibe una solicitud. Las operaciones involucran:

  • establecer un socket para comenzar a escuchar en el puerto 80 (o algún otro puerto)
  • recibir la solicitud y analizar el mensaje
  • procesando la respuesta
  • establecer encabezados de respuesta
  • enviando la respuesta al cliente
  • cerrar la conexión si se encontró un encabezado Connection: close request

Por supuesto, esta no es una lista exhaustiva de operaciones La mayoría de las aplicaciones / sitios web necesitan saber quién realiza una solicitud para crear respuestas más personalizadas. Este es el reino de la identificación y la autenticación.


Identificación y Autenticación

HTTP es un protocolo de capa de aplicación sobre TCP, que está sobre IP.

Es casi obligatorio saber quién se conecta a un servidor para rastrear el uso de una aplicación o sitio y los patrones generales de interacción de los usuarios. La premisa de la identificación es adaptar la respuesta para proporcionar una experiencia personalizada; naturalmente, el servidor debe saber quién es un usuario para proporcionar esa funcionalidad.

Hay algunas maneras diferentes en que un servidor puede recopilar esta información, y la mayoría de los sitios web usan un híbrido de estos enfoques:

  • Solicitar encabezadosFromRefererUser-Agent - vimos estos encabezados en la Parte 1.
  • Cliente-IP: la dirección IP del cliente
  • Fat Urls: almacenamiento del estado del usuario actual modificando la URL y redirigiendo a una URL diferente en cada clic; cada clic esencialmente acumula estado.
  • Cookies: el enfoque más popular y no intrusivo.

Las cookies permiten que el servidor adjunte información arbitraria para respuestas salientes a través del encabezado de respuesta Set-Cookie. Una cookie se establece con uno o más pares nombre = valor separados por punto y coma (;), como en Set-Cookie: session-id = 12345ABC; username = nettuts.

Un servidor también puede restringir las cookies a un dominio y ruta específicos, y puede hacer que sean persistentes con un valor de caducidad. Las cookies se envían automáticamente por el navegador para cada solicitud hecha a un servidor, y el navegador se asegura de que solo se envíen las cookies específicas del dominio y ruta en la solicitud. El encabezado de solicitud Cookie: nombre = valor [; name2 = value2] se usa para enviar estas cookies al servidor.

La mejor forma de identificar a un usuario es exigirle que se registre e inicie sesión, pero la implementación de esta función requiere un cierto esfuerzo del desarrollador, así como del usuario.

Las técnicas como OAuth simplifican este tipo de características, pero aún así requieren el consentimiento del usuario para funcionar correctamente. La autenticación juega un papel importante aquí, y es probablemente la única forma de identificar y verificar al usuario.

Autenticación

HTTP admite una forma de autenticación rudimentaria llamada Autenticación básica, así como la Autenticación implícita más segura.

En Basic Authentication, el servidor inicialmente niega la solicitud del cliente con un encabezado de respuesta WWW-Authenticate y un código de estado 401 no autorizado. Al ver este encabezado, el navegador muestra un cuadro de diálogo de inicio de sesión, solicitando un nombre de usuario y contraseña. Esta información se envía en un formato codificado en base 64 en el encabezado de solicitud de Autenticación. El servidor ahora puede validar la solicitud y permitir el acceso si las credenciales son válidas. Algunos servidores también pueden enviar un encabezado de información de autenticación que contiene detalles de autenticación adicionales.

Authentication Challenge/Response

Un corolario de la Autenticación Básica es la Autenticación Proxy. En lugar de un servidor web, el desafío de autenticación es solicitado por un proxy intermedio. El proxy envía un encabezado Proxy-Authenticate con un código de estado 407 no autorizado. A cambio, se supone que el cliente debe enviar las credenciales a través del encabezado de solicitud de Autorización de Proxy.

Digest Authentication es similar a Basic y usa la misma técnica de handshake con los encabezados WWW-Authenticate y Authorization, pero Digest usa una función hashing más segura para cifrar el nombre de usuario y la contraseña (comúnmente con funciones de resumen MD5 o KD). Aunque se supone que Autenticación implícita es más segura que Básica, los sitios web suelen utilizar la Autenticación básica debido a su simplicidad. Para mitigar los problemas de seguridad, Basic Auth se usa junto con SSL.

HTTP seguro

HTTPS AddressBar

El protocolo HTTPS proporciona una conexión segura en la web. La forma más fácil de saber si está usando HTTPS es verificar la barra de direcciones del navegador. El componente seguro de HTTPs implica insertar una capa de cifrado / descifrado entre HTTP y TCP. Esta es la Capa de sockets seguros (SSL) o la Seguridad de la capa de transporte (TLS) mejorada.

SSL usa una poderosa forma de encriptación usando RSA y criptografía de clave pública. Debido a que las transacciones seguras son tan importantes en la web, en todo momento ha estado en marcha un esfuerzo ubicuo basado en estándares de infraestructura de clave pública (PKI).

Los clientes / servidores existentes no tienen que cambiar la forma en que manejan los mensajes porque la mayor parte del trabajo duro ocurre en la capa SSL. Por lo tanto, puede desarrollar su aplicación web utilizando Basic Authentication y aprovechar automáticamente los beneficios de SSL al cambiar al protocolo https: //. Sin embargo, para que la aplicación web funcione a través de HTTPS, debe tener un certificado digital en funcionamiento implementado en el servidor.

Certificados

Del mismo modo que necesita tarjetas de identificación para mostrar su identidad, un servidor web necesita un certificado digital para identificarse. Los certificados (o "certs") son emitidos por una autoridad certificadora (CA) y avalan su identidad en la web. Los CA son los guardianes de la PKI. La forma más común de certificados es el estándar X.509 v3, que contiene información, como por ejemplo:

  • el emisor del certificado
  • el algoritmo utilizado para el certificado
  • el nombre del sujeto u organización para quien se creó este certificado
  • la información de clave pública para el sujeto
  • la firma de la autoridad de certificación, utilizando el algoritmo de firma especificado

Cuando un cliente realiza una solicitud a través de HTTPS, primero intenta ubicar un certificado en el servidor. Si se encuentra el cert, intenta verificarlo contra su lista conocida de CA. Si no es una de las CA enumeradas, podría mostrar un cuadro de diálogo para el usuario advirtiendo sobre el certificado del sitio web.

Una vez que se verifica el certificado, se completa el protocolo de enlace SSL y se activa la transmisión segura.


Caché de HTTP

En general, se acepta que hacer el mismo trabajo dos veces es un desperdicio. Este es el principio rector en torno al concepto de almacenamiento en caché HTTP, un pilar fundamental de la infraestructura de red HTTP. Debido a que la mayoría de las operaciones se realizan a través de una red, un caché ayuda a ahorrar tiempo, costos y ancho de banda, además de brindar una experiencia mejorada en la web.

Los cachés se utilizan en varios lugares de la infraestructura de red, desde el navegador hasta el servidor de origen. Dependiendo de dónde se encuentre, un caché se puede categorizar como:

  • Privado: dentro de un navegador, almacena en caché los nombres de usuario, las contraseñas, las URL, el historial de navegación y el contenido web. Por lo general, son pequeños y específicos para un usuario.
  • Público: implementado como proxies de caché entre el servidor y el cliente. Estos son mucho más grandes porque sirven a múltiples usuarios. Una práctica común es mantener múltiples proxys de caché entre el cliente y el servidor de origen. Esto ayuda a servir contenido al que se accede con frecuencia, al tiempo que permite un viaje al servidor para el contenido que se necesita con poca frecuencia.
Cache Topology

Procesamiento de caché

Independientemente de dónde se encuentre un caché, el proceso de mantenimiento de un caché es bastante similar:

  • Recibir mensaje de solicitud.
  • Analiza la URL y los encabezados.
  • Buscar una copia local; de lo contrario, busque y almacene localmente
  • Realice una comprobación de frescura para determinar la antigüedad del contenido en la memoria caché; realice una solicitud para actualizar el contenido solo si es necesario.
  • Crea la respuesta del cuerpo almacenado en caché y los encabezados actualizados.
  • Envía la respuesta de vuelta al cliente.
  • Opcionalmente, registre la transacción.

Por supuesto, el servidor es responsable de responder siempre con los encabezados y respuestas correctos. Si un documento no ha cambiado, el servidor debe responder con un 304 No modificado. Si la copia en caché ha caducado, debe generar una nueva respuesta con encabezados de respuesta actualizados y regresar con un 200 OK. Si el recurso se elimina, debe regresar con 404 Not Found. Estas respuestas ayudan a sintonizar la memoria caché y aseguran que el contenido obsoleto no se mantenga por mucho tiempo.

Encabezados de control de caché

Las conexiones en paralelo, en combinación con conexiones persistentes, son la respuesta actual para minimizar los retrasos en la red.

Ahora que tenemos una idea de cómo funciona un caché, es hora de mirar los encabezados de solicitud y respuesta que habilitan la infraestructura de caché. Mantener el contenido actualizado y actualizado es una de las principales responsabilidades del caché. Para mantener la copia en caché coherente con el servidor, HTTP proporciona algunos mecanismos simples, a saber, caducidad del documento y revalidación del servidor.

Expiración del documento

HTTP permite que un servidor de origen adjunte una fecha de caducidad a cada documento utilizando los encabezados de respuesta Cache-Control y Expira. Esto ayuda al cliente y a otros servidores de caché a saber cuánto tiempo un documento es válido y nuevo. La memoria caché puede servir la copia siempre que la fecha del documento esté dentro de la fecha de vencimiento. Una vez que un documento caduca, la caché debe verificar con el servidor una copia más nueva y actualizar su copia local en consecuencia.

Expira es un encabezado de respuesta HTTP / 1.0 anterior que especifica el valor como una fecha absoluta. Esto solo es útil si los relojes del servidor están sincronizados con el cliente, lo cual es una suposición terrible de realizar. Este encabezado es menos útil en comparación con el encabezado Cache-Control: max-age =<s> mas nuevo introducido en HTTP / 1.1. Aquí, la edad máxima es una edad relativa, especificada en segundos, desde el momento en que se creó la respuesta. Por lo tanto, si un documento caduca después de un día, el encabezado de caducidad debe ser Cache-Control: max-age = 86400.

Revalidación del servidor

Una vez que un documento en caché vence, la memoria caché debe revalidarse con el servidor para verificar si el documento ha cambiado. Esto se denomina revalidación del servidor y sirve como un mecanismo de consulta para la caducidad de un documento. El hecho de que una copia almacenada en caché haya expirado no significa que el servidor realmente tenga contenido más nuevo. La revalidación es solo un medio para garantizar que la memoria caché se mantenga fresca. Debido al tiempo de caducidad (como se especificó en una respuesta anterior del servidor), la memoria caché no tiene que verificar con el servidor para cada solicitud, lo que permite ahorrar ancho de banda, tiempo y reducir el tráfico de la red.

La combinación de la caducidad del documento y la revalidación del servidor es un mecanismo muy eficaz, y permite que los sistemas distribuidos mantengan copias con una fecha de vencimiento.

Si se sabe que el contenido cambia con frecuencia, el tiempo de caducidad se puede reducir, lo que permite que los sistemas se sincronicen con mayor frecuencia.

El paso de revalidación se puede realizar con dos tipos de encabezados de solicitud: If-Modified-Since y If-None-Match. El primero es para la validación basada en la fecha, mientras que el segundo usa Entity-Tags (ETags), un hash del contenido. Estos encabezados usan valores de fecha o ETag obtenidos de una respuesta anterior del servidor. En caso de If-Modified-Since, se utiliza el encabezado de respuesta Last-Modified; para If-None-Match, es el encabezado de respuesta ETag.

Controlando la Cachabilidad

El período de validez de un documento debe ser definido por el servidor que genera el documento. Si se trata de un sitio web de periódico, la página de inicio debe caducar después de un día (¡o incluso a veces cada hora!). HTTP proporciona los encabezados de respuesta Cache-Control y Expires para establecer la caducidad de los documentos. Como se mencionó anteriormente, Expires se basa en fechas absolutas y no es una solución confiable para controlar el caché.

El encabezado Cache-Control es mucho más útil y tiene algunos valores diferentes para restringir cómo los clientes deben almacenar en caché la respuesta:

  • Cache-Control: no-cache: el cliente puede almacenar el documento; sin embargo, debe revalidar con el servidor en cada solicitud. Hay un encabezado de compatibilidad HTTP / 1.0 llamado Pragma: no-cache, que funciona de la misma manera.
  • Cache-Control: no-store: esta es una directiva más fuerte para el cliente de no almacenar el documento en absoluto.
  • Cache-Control: must-revalidate: le dice al cliente que omita su cálculo de frescura y siempre revalide con el servidor. No está permitido publicar la respuesta en caché en caso de que el servidor no esté disponible.
  • Cache-Control: max-age: establece un tiempo de vencimiento relativo (en segundos) desde el momento en que se genera la respuesta.

Como comentario adicional, si el servidor no envía ningún encabezado de control de caché, el cliente puede usar su propio algoritmo de expiración heurística para determinar la frescura.

Restricción de la frescura del cliente

La cachabilidad no se limita al servidor. También se puede especificar desde el cliente. Esto le permite al cliente imponer restricciones sobre lo que está dispuesto a aceptar. Esto es posible a través del mismo encabezado de Cache-Control, aunque con algunos valores diferentes:

  • Cache-Control: min-fresh=<s>: el documento debe estar actualizado al menos durante <s> segundos.
  • Cache-Control: max-stale o Cache-Control: max-stale=<s>:el documento no puede ser servido desde la memoria cache si ha estado inactivo durante <s> segundos.
  • Cache-Control: max-age=<s>: la memoria cache no puede devolver un documento que haya sido almacenado en cache durante mas de <s> segundos.
  • Cache-Control: no-cache o Pragma: no-cache: el cliente no aceptará un recurso en caché a menos que haya sido revalidado.

HTTP Caching es en realidad un tema muy interesante, y hay algunos algoritmos muy sofisticados para administrar el contenido almacenado en caché. Para una descripción más detallada de este tema, consulte la sección Almacenamiento en caché de la especificación HTTP.


Resumen

Nuestro recorrido por HTTP comenzó con la base de esquemas de URL, códigos de estado y encabezados de solicitud / respuesta. Sobre la base de esos conceptos, miramos algunas de las áreas más finas de HTTP, como el manejo de la conexión, identificación y autenticación y almacenamiento en caché. Tengo la esperanza de que esta gira te haya dado una buena muestra de la amplitud de HTTP y suficientes consejos para seguir explorando este protocolo.

Referencias

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.