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

HTTP Conciso: Arquitectura Web HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Connections
HTTP Succinctly: HTTP State and Security

Spanish (Español) translation by Jonathan Samines (you can also view the original English article)

En el primer capítulo hablamos sobre recursos, principalmente enfocados en las URLs y como interpretarlas. Sin embargo, los recursos son la pieza central de HTTP. Ahora que entendemos los mensajes HTTP, los métodos y las conexiones, podemos regresar a ver los recursos con una nueva luz. En éste capítulo hablaremos sobre la verdadera esencia de trabajar con recursos cuando diseñamos la arquitectura de aplicaciones y servicios web.

Reducción de Recursos

Aunque es fácil pensar en un recurso web como si fuera un archivo en el sistema de archivos de un servidor web, pensar de esa forma es una falta de respeto para las verdaderas capacidades de abstracción del recurso. Muchas páginas web requieren recursos físicos en un sistema de archivos- archivos Javascript, imágenes y hojas de estilo. Sin embargo, a consumidores y usuarios de la web no les importan mucho éstos recursos secundarios. En cambio, les importan los recursos con los que puedan interactuar, y más importante, recursos que puedan nombrar. Recursos como:

  • La receta para una ensalada de brócoli
  • Los resultados de búsqueda para "Pizza de Chicago"
  • El historial médico del paciente 123

Todos éstos recursos son los tipos de recursos sobre los que construimos aplicaciones, y el tema en común en la lista es como cada elemento es lo suficientemente significante para identificarlo y nombrarlo. Si podemos identificar un recurso, también podemos darle una URL al recurso, para que alguien localice el recurso. Una URL es algo muy útil de tener. Dada una URL puedes localizar un recurso, por supuesto, pero también puedes manejar la URL para alguien más incorporando la URL en un hiperenlace o enviándola en un correo electrónico.

Pero, hay cosas que no puedes hacer con una URL. Más bien, hay muchas cosas que una URL no puede hacer. Por ejemplo, una URL no puede restringir al cliente o al servidor a un tipo de tecnología especifica. Todos hablan HTTP. No importa si tu cliente es C++ y tu aplicación web está escrita en Ruby.

Una URL tampoco puede forzar al servidor a almacenar un recurso utilizando alguna tecnología en particular. El recurso podría ser un documento en el sistema de archivos, pero un framework web también podría responder la solicitud para el recurso y construir el recurso utilizando información almacenada en archivos, almacenada en bases de datos, obtenida de servicios web, o obtener el recurso de la hora del día.

Una URL no puede siquiera especificar la representación de un recurso específico, y un recurso puede tener múltiples representaciones. Como aprendimos anteriormente, un cliente puede solicitar una representación particular utilizando cabeceras en el mensaje de solicitud HTTP. Un cliente puede solicitar un lenguaje específico, o un tipo específico de contenido. Si has trabajando con una aplicación web que permita la negociación de contenidos, has visto la flexibilidad de los recursos en acción. JavaScript puede solicitar los datos del paciente 123 en formato JSON, C# puede solicitar el mismo recurso en formato XML, y un explorador puede solicitar los datos en formato HTML. Todos ellos trabajan con el mismo recurso, pero utilizando tres representaciones diferentes.

Hay una cosa más que una URL no puede hacer- no puede indicar lo que un usuario quiere hacer con un recurso. Una URL no indica si quiero obtener o editar un recurso. Es el trabajo del mensaje de solicitud HTTP describir su intención utilizando uno de los métodos HTTP estándar. Como hablamos en la parte 2 de ésta sesión, hay un número limitado de métodos HTTP estándar, incluyendo GET, POST, PUT y DELETE.

Cuando empiezas a pensar en los recursos y URLs como lo estamos haciendo en éste capítulo, empiezas a ver la web como parte de tu aplicación y una capa arquitectónica flexible sobre la que puedes construir. Para una mayor comprensión de esta línea de pensamiento, mira la tesis de Roy Fielding titulada "Estilos Arquitectónicos y el Diseño de Arquitecturas de Software basadas en Redes". Esta tesis es la investigación que introduce el estilo arquitectónico Transferencia de Estado Representacional (REST) y se adentra en gran detalle sobre los conceptos e ideas en ésta sección y la siguiente. El artículo se encuentra en: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.


El protocolo HTTP Visible

Hasta ahora nos hemos enfocado en lo que una URL no puede hacer, cuando deberíamos estar enfocados en lo que una URL puede hacer. O más bien, enfocarnos en lo que una URL y HTTP pueden hacer, porque trabajan bien juntos. En su tesis, Fielding describe los beneficios de adoptar HTTP. Estos beneficios incluyen la escalabilidad, simplicidad, confiabilidad y bajo acoplamiento. HTTP ofrece éstos beneficios en parte porque puedes pensar en una URL como un puntero, o una unidad de indirección, entre un cliente y la aplicación servidor. Otra vez, la URL en sí misma no indica una representación de recurso específica, implementación tecnologica, o la intención del cliente. En cambio, un cliente puede expresar la intención y representación deseadas en un mensaje HTTP.

Un mensaje HTTP es un simple mensaje de texto plano. La belleza del mensaje HTTP es como tanto la solicitud como la respuesta son completamente auto-descriptivas. Una solicitud incluye un método HTTP (lo que el cliente quier hacer), la ruta al recurso, y las cabeceras adicionales proporcionan información sobre la representación deseada. Una respuesta incluye un código de estado para indica el resultado de la transacción, pero también incluye cabeceras con instrucciones de cache, el tipo de contenido del recurso, el tamaño del recurso, y posiblemente otros metadatos valiosos.

Debido a que toda la información requerida por la transacción está contenida en los mensajes, y debido a que la información es visible y fácil de parsear, las aplicaciones HTTP pueden depender de varios servicios que proporcionan valor mientras el mensaje se mueve entre la aplicación cliente y la aplicación servidor.


Agregando Valor

Conforme un mensaje HTTP se mueve del espacio de memoria en un proceso en una máquina al espacio de memoria en un proceso en otra máquina, puede moverse a través de muchas piezas de software y hardware que inspeccionan y posiblemente modifican el mensaje. Un buen ejemplo es la aplicación servidor web en sí mismo. Un servidor web como Apache o IIS será uno de los primeros receptores de la solicitud HTTP entrante en la máquina servidor, y como servidor web, puede direccionar el mensaje a la aplicación apropiada

El servidor web puede utilizar la información en un mensaje, como la URL o la cabecera host, cuando decide a dónde enviar el mensaje. El servidor también puede llevar a cabo acciones adicionales con el mensaje como el registro del mensaje a un archivo local. Las aplicaciones en el servidor no necesitan preocuparse sobre el registro porque el servidor está configurado para registrar todos los mensajes.

Igualmente, cuando una aplicación crea un mensaje de respuesta HTTP, el servidor tiene la posibilidad de interactuar con el mensaje en su camino hacía afuera. Otra vez, esto podría ser una simple operación de registro, pero también podría ser una modificación directa al mensaje en sí mismo. Por ejemplo, un servidor puede saber si un cliente soporta la compresión gzip, porque el cliente puede indicarle éste hecho a través de la cabecera Accept-Encoding en la solicitud HTTP. La compresión permite a un servidor tomar un recurso de 100-KB y convertirlo en un recurso de 25-KB para una transmisión más rápida. Puedes configurar muchos servidores web para que automáticamente utilicen la compresión para ciertos tipos de contenido (típicamente tipos de texto), y ésto ocurre sin que la aplicación en sí misma se preocupe sobre la compresión. La compresión es un valor agregado proporcionado por el software del servidor web en sí mismo.

Las aplicaciones no tienen que preocuparse sobre registrar las transacciones HTTP o la compresión, y todo ésto es gracias a los mensajes HTTP auto-descriptivos que permiten a otras piezas de infraestructura procesar y transformar los mensajes. Este tipo de proceso también puede ocurrir mientras el mensaje se mueve a través de la red.


Proxies

Un servidor proxy es una computador que se sitúa entre el cliente y el servidor. Un proxy es transparente para los usuarios finales. Piensas que estás enviando mensajes de solicitud HTTP directamente a un servidor, pero los mensajes en realidad van a un proxy. El proxy acepta los mensajes de solicitud HTTP de un cliente y redirigen los mensajes al servidor deseado. El proxy entonces toma la respuesta del servidor y remite la respuesta al cliente. Antes de reenviar estos mensajes, el proxy puede inspeccionar los mensajes y potencialmente tomar algunas acciones adicionales.

Uno de los clientes para los que trabajo utiliza un servidor proxy para capturar todo el tráfico HTTP que deja la oficina. Ellos no quieren que sus empleados y socios gasten todo su tiempo en Twitter y Facebook, así que las solicitudes HTTP para éstos servidores nunca alcanzarán su destino y por tanto nadie está tuiteando o jugando Farmville dentro de la oficina. Este es un ejemplo de uno de los roles populares de los servidores proxy, el cual es funcionar como dispositivo de control de acceso.

Sin embargo, un servidor proxy puede ser mucho más sofisticado que solo bloquear mensajes a host específicos- un simple firewall podría llevar a cabo ésta tarea. Un servidor proxy también puede inspeccionar los mensajes para eliminar información confidencial, como las cabeceras Referer que apuntan a recursos internos de la red de la compañia. Un proxy de control de acceso también puede registrar los mensajes HTTP para auditar el registro de todo el tráfico. Muchos proxies de control de acceso requieren la autenticación del usuario, un tema que veremos en el siguiente artículo.

El proxy que estoy describiendo en el párrafo anterior es lo que llamamos un proxy de redirección. Los servidores de redirección están normalmente más cerca del cliente que del servidor, y normalmente requieren alguna configuración en el software cliente o el explorador web para funcionar.

Un proxy inverso es un servidor proxy que está más cerca al servidor que al cliente, y es completamente transparente para el cliente.

Figure 6: Forward and reverse proxies
Proxies inverso y de redirección

Ambos tipos de proxies puede proporcionar un amplio conjunto de servicios. Si regresamos al escenario de compresión gzip del que hablamos con anterioridad, un servidor proxy tiene la capacidad de comprimir el cuerpo de los mensajes de respuesta. Una empresa podría usar un servidor proxy inverso para sacar del servidor web toda la carga computacional de la compresión. Ahora, ni la aplicación ni el servidor web tienen que preocuparse sobre la compresión. En su lugar, la compresión es una característica que se apoya en un proxy. Esta es la belleza de HTTP.

Algunos otros servicios proxy populares incluyen lo siguiente.

Los proxies de balanceo de carga pueden tomar un mensaje y redirigirlo a uno de muchos servidores web en base a una ronda de todos contra todos, o sabiendo que servidor está actualmente procesando el menor número de solicitudes.

Los proxies de aceleración SSL pueden encriptar y desencriptar los mensajes HTTP, llevando la carga de la encriptación fuera del servidor web. Hablaremos más sobre SSL en el siguiente capítulo.

Los proxies pueden proporcionar capas adicionales de seguridad filtrando mensajes HTTP potencialmente peligrosos. Específicamente, los mensajes que lucen como si intetaran encontrar una vulnerabilidad cross-site scripting (XSS) o ejecutar un ataque de inyección SQL.

Los proxies de almacenamiento en caché pueden almacenar copias de recursos frecuentemente accedidos y responder a los mensajes solicitando éstos recursos directamente. Entraremos en más detalle sobre el almacenamiento en caché en la siguiente sección.

Finalmente, vale la pena apuntar que los proxies no tienen que ser un servidor físico. Fiddler, una herramienta mencionada en el capítulo anterior, es un depurador HTTP que te permite capturar e inspeccionar los mensajes HTTP. Fiddler funciona indicándole a Windows que redirija todo el tráfico saliente al puerto 8888 a la dirección IP 127.0.0.1. Esta dirección IP es la dirección de loopback, lo cual quiere decir que el tráfico simplemente va directamente a la máquina local dónde Fiddler está escuchando en el puerto 8888. Fiddler toma el mensaje de solicitud HTTP, lo registra, y lo redirige al destino, y también captura la respuesta antes de redirigir el mensaje de respuesta a la aplicación local. Puedes visualizar la configuración del proxy en Internet Explorer (IE) yendo a Herramientas, Opciones de Internet, haciendo click en el tab Conexiones y luego haciendo click en el botón Configuración LAN. Bajo el área de Servidor Proxy, haz click en el botón Avanzado para ver los detalles del servidor proxy.

Figure 7: Proxy settings in Internet Explorer
Configuración de Proxy en Internet Explorer

Los proxies son un perfecto ejemplo de como HTTP puede influenciar la arquitectura de una aplicación o servicio web. Hay muchos servicios en los que puedes apoyarte en la red sin impactar la aplicación. El único servicio que queremos examinar en más detalle es el almacenamiento en caché.


Almacenamiento en Caché

El almacenamiento en caché es una optimización hecha para mejorar el rendimiento y la escalabilidad. Cuando hay múltiples solicitudes para la misma representación del recurso, un servidor puede enviar los mismo bytes sobre la red una y otra vez para cada solicitud. O, un servidor proxy o un cliente puede cachear la representación localmente y reducir el tiempo y ancho de banda requerido para obtenerlo completamente. El almacenamiento en caché puede reducir la latencia, ayudar a prevenir cuellos de botella, y permite a las aplicaciones web sobrevivir cuando cada usuario quiere comprar a la vez el producto más nuevo o ver el último lanzamiento de prensa. El almacenamiento en caché es un excelente ejemplo de como los metadatos en las cabeceras del mensaje HTTP facilita capas y servicios adicionales.

Lo primero a saber es que hay dos tipos de caché.

Una caché pública es una caché compartida entre múltiples usuarios. Una caché pública generalmente reside en un servidor proxy. Una caché pública en un proxy de redirección generalmente cachea recursos que son populares en una comunidad de usuarios, como los usuarios de una empresa específica, o los usuarios de un proveedor de servicios de Internet. Una caché pública en un proxy invertido generalmente cachea los recursos que son populares a un sitio web específico, como las imágenes de productos populares de Amazon.com

Un caché privado es dedicado a un único usuario. Los exploradores web siempre mantienen un caché privado de recursos en tu disco (éstos son los "Archivos Temporales de Internet" en IE, o escribe about:cache en la barra de direcciones de Google Chrome para ver los archivos en el caché privado de Chrome). Todo lo que un explorador haya cacheado en el sistema de archivos puede aparecer casi instantáneamente en la pantalla.

Las reglas sobre lo que se cachea, cuando cachear, y cuando invalidar un elemento de caché (esto es, sacarlo de la memoria caché), son desafortunadamente complicados y sumidos por algunos comportamientos legados e implementaciones incompatibles. A pesar de eso, me esforzaré para apuntar algunas de las cosas que deberías de saber sobre el almacenamiento en caché.

En HTTP 1.1, un mensaje de respuesta con un código de estado 200 (OK) para una solicitud HTTP GET es almacenable en caché por defecto (lo cual quiere decir que los clientes y proxies tienen permitido cachear la respuesta). Una aplicación puede influenciar esta configuración por defecto, utilizando las cabeceras apropiadas en la respuesta HTTP. En HTTP 1.1, esta cabecera es Cache-Control, aunque también puedes ver la cabecera Expires en muchos mensajes. La cabecera Expires aún está rondando por ahí y es ampliamente soportada, a pesar de estar obsoleta en HTTP 1.1. Pragma es otro ejemplo de una cabecera utilizada para controlar el comportamiento del almacenamiento en caché, pero también está ahí solo por compatabilidad con versiones anteriores. En éste libro nos enfocaremos en Cache-Control.

Una respuesta HTTP puede tener un valor para Cache-Control de public, private o no-cache. Un valor de public quiere decir que los servidores proxy públicos pueden cachear la respuesta. Un valor de private quiere decir que solo el explorador puede almacenar en caché la respuesta. Un valor de no-cache quiere decir que nadie debería almacenar el caché la respuesta. También hay un valor no-store, que quiere decir que el mensaje podría contener información sensible y no debería ser almacenado, pero además debe ser eliminado de memoria lo más pronto posible.

¿Cómo utilizas ésta información? Para los recursos populares compartidos (como la imagen logotipo de la página principal), querrías utilizar una directa de control de caché public y permitirías a todos almacenar el caché la imagen, aún a los servidores proxy.

Para respuesta a usuarios específicos (como el HTML para la página principal que incluye el nombre del usuario), querrás usar una directiva de cache private.

Nota: En ASP.NET puedes controlar estas configuraciones mediante Response.Cache.

Un servidor también puede especificar un valor max-age en la cabecera Cache-Control. El valor max-age es el número de segundos que se almacena en caché la respuesta. Una vez los segundos expiran, la solicitud debe siempre regresar al servidor para obtener la respuesta actualizada. Veamos algunos ejemplos de respuesta.

Aquí está una respuesta parcial de Flickr.com para uno de los archivos CSS de Flickr.

Nota que Cache-Control permite a cachés públicos y privados almacenar en caché el archivo, y pueden mantenerlo rondando por más de 315 millones de segundos (10 años). También utilizan la cabecera Expires para dar una fecha de expiración específica. Si un cliente es compatible con HTTP 1.1 y entiende Cache-Control, debería utiliza el valor en max-age en lugar de Expires. Nota que esto no quiere decir que Flickr plenee utilizar el mismo archivo CSS por 10 años. Cuando Flickr cambie su diseño, probablemente solo usará una URL diferente para su archivo CSS actualizado.

La respuesta también incluye una cabecera Last-Modified para indicar cuando la representación fue cambiada por última vez (la cual puede solo ser el momento de la solicitud). La lógica para almacenamiento en caché utiliza éste valor como un validador, o un valor que el cliente puede utilizar para ver si la representación en caché es aún válida. Por ejemplo, si el agente decide que necesita revisar el recurso puede crear la siguiente solicitud.

La cabecera If-Modified-Since le indica al servidor que el cliente solo necesita completar la respuesta si el recurso ha cambiado. Si el recurso no ha cambiado, el servidor puede responder con un mensaje 304 Not Modified.

El servidor le indica al cliente: Adelante, utiliza los bytes que ya tienes en caché.

Otro validador que verás comúnmente es ETag.

El ETag es un identificador opaco, lo cual quiere decir que no tiene ningún significado heredado. Un ETag es frecuentemente creado utilizando un algoritmo de hash en contra del recurso. Si el recurso cambia alguna vez, el servidor calculará un nuevo ETag. Una entrada de caché puede ser validada comparando dos ETags. Si las ETags son iguales, nada ha cambiado. Si los ETags son diferentes, es momento de invalidar el caché.


¿Dónde estamos?

En éste capítulo hemos cubierto algo de teoría arquitectónica así como los beneficios prácticos de la arquitectura HTTP. La capacidad apoyarse en el almacenamiento en caché y otros servicios entre el servidor y cliente ha sido la fuerza conductora detrás del éxito de HTTP y de la web. La visibilidad de los mensajes HTTP auto-descriptivos y la indirección proporcionada por URLs lo hace posible. En el siguiente capítulo hablaremos sobre uno de los pocos temas que hemos eludido, temas como la autenticación y la encriptación.

¡Sé el primero en conocer las nuevas traducciones–sigue @tutsplus_es en Twitter!

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.