La optimización de TCP
Aunque TCP es omnipresente hoy en día, el protocolo ha sufrido muchos cambios para ayudar a superar las limitaciones que existían en versiones anteriores. Un dispositivo de aceleración puede ayudar a optimizar TCP mediante la implementación de características que pueden no estar presentes ya sea en un cliente o una aplicación TCP de servidor.
Un dispositivo de aceleración también puede disminuir el número de conexiones TCP de servidor necesarias para dar servicio a las solicitudes del cliente. Además, puede ayudar a acelerar el tráfico HTTP al aumentar el número de conexiones TCP simultáneas del lado del cliente que un navegador puede abrir mientras que descarga una página web.
Optimizaciones generales de TCP
Debido a que funciona como un proxy, un dispositivo de aceleración puede ser capaz de implementar características que faltan en un cliente o servidor y que puede ayudar a la velocidad de entrega de aplicaciones. El dispositivo de aceleración puede ser capaz de aprovechar las optimizaciones de forma nativa con el apoyo de los sistemas operativos de servidor o cliente en particular y es probable que sea capaz de implementar las optimizaciones que no dependen del sistema operativo. El beneficio de la alta velocidad, en conexiones WAN de alta latencia puede realizar escalado de ventanas TCP para mejorar el rendimiento. Para superar la pérdida de paquetes, el dispositivo de aceleración puede implementar reconocimientos selectivos TCP (SACK) y algoritmos de control de congestión avanzados para prevenir de la reducción de rendimiento.
Estos son sólo dos ejemplos. Algunos dispositivos de aceleración pueden implementar cientos de mejoras en TCP con el fin de ayudar a que funcione mejor.
La disminución de las conexiones TCP en el lado servidor
La reducción del proceso de conexión del lado del servidor puede mejorar drásticamente el rendimiento y reducir el número de servidores necesarios para albergar una aplicación. El establecimiento de la conexión TCP y el desmontaje requiere una sobrecarga significativa, sobre todo para los servidores. Si el número de conexiones abiertas aumentan en el servidor, el mantenimiento de las conexiones abiertas al mismo tiempo que la apertura de nuevas conexiones pueden degradar gravemente el rendimiento del servidor y por lo tanto, el tiempo de respuesta del usuario.
A pesar de que varias transacciones (por ejemplo, la transferencia de archivos) pueden ocurrir dentro de una única conexión TCP, una conexión es generalmente entre un cliente y un servidor. Normalmente, una conexión se cierra o bien cuando un servidor alcanza un límite de transacción definido o cuando un cliente ha transferido todos los archivos necesarios desde ese servidor. Debido a que un dispositivo de aceleración funciona como un proxy, puede agregar, o “agrupar,” conexiones del lado del servidor TCP mediante la combinación de muchas transacciones separadas, potencialmente de muchos usuarios, a través de un menor número de conexiones TCP. El dispositivo de aceleración abre nuevas conexiones del lado del servidor sólo cuando sea necesario, y en su lugar reutiliza conexiones existentes para las peticiones de otros usuarios siempre que sea posible.
El aumento de las conexiones TCP en el lado cliente
Por defecto, la mayoría de los navegadores web limitan el número máximo de conexiones HTTP / HTTPS simultáneas que el navegador puede abrir a una URL. Por ejemplo, Microsoft Internet Explorer v7 limita el número máximo de conexiones simultáneas a dos por dominio. En las versiones anteriores de Firefox el navegador limitaba a ocho conexiones por dominio. Teniendo en cuenta que una página web puede contener decenas de objetos, esta limitación puede crear enormes y lentos tiempos de carga de páginas.
Por ejemplo, supongamos que un usuario que ejecuta Internet Explorer v7 solicita una página de un servidor web que devuelve una respuesta que contiene una lista de los 30 objetos que componen la página web. Asumimos que a todos los objetos se accede a través del dominio, www.example.com. El navegador abre dos conexiones a www.example.com, solicita un objeto por conexión (el límite impuesto por TCP), y luego se vuelven a utilizar las dos conexiones hasta que todos los archivos han sido descargados o la conexión alcanza límite de transacción del servidor. Si la conexión sufre una alta latencia, el tiempo de ida y vuelta es alto y la velocidad de descarga se puede reducir en gran medida.
Si el servidor termina la conexión después de alcanzar un límite de transacción predefinido, el navegador abre otra conexión a esa URL. Este proceso continúa hasta que la página se descarga por completo. La utilización de esta manera aumenta innecesariamente el tiempo de carga de la página.
Algunos dispositivos de aceleración pueden “engañar” a un navegador mediante la modificación de las direcciones URL en una respuesta HTTP. Las URLs modificadas primero se deben definir en DNS para apuntar a la misma dirección IP. Al examinar la respuesta del servidor, los nombres modificados que aparecen en el navegador paracen ser distintos servidores, por lo que el navegador web abren conexiones paralelas a estas URLs alteradas en lugar de descargar los objetos de una URL.
5.02 - Describir el propósito de los "keeps-alive" de HTTP, del almacenamiento en caché, de la compresión y la canalización
Protocolo HTTP y optimizaciones de aplicaciones web
Las optimizaciones del protocolo HTTP mantienen altos niveles de rendimiento de usuario mediante la regulación óptima de cada sesión HTTP. Por ejemplo, algunas aplicaciones web no son capaces de devolver un código de estado HTTP 304 (no modificado) en respuesta a una petición del cliente en lugar de devolver todo el objeto. Debido a que un dispositivo de aceleración hace de proxy y cachés de contenido para las conexiones, puede ser capaz de tener en cuenta cuando no hay cambio en un objeto solicitado y devolver la respuesta 304 en su lugar. Esto permite al navegador a cargar el contenido de su propia caché, incluso en condiciones en que la aplicación web está codificada para volver a enviar el objeto.
Algunos dispositivos de aceleración, además, pueden examinar y cambiar las respuestas del servidor para proporcionar un rendimiento mejor del navegador y del servidor. Por ejemplo, algunas aplicaciones off-the-shelf y aplicaciones personalizadas añaden un encabezado no-cache para algunos objetos, que hace que un navegador que no haga caché de un objeto, en lugar de descargar el objeto desde el servidor Web de origen cada vez. El propósito de la cabecera no-cache es asegurar que un navegador siempre descarga de datos dinámicos (cambiantes).
Sin embargo, las aplicaciones en algunos casos marcan los datos estáticos como un logotipo de la empresa como no aplicables a la caché. Algunos dispositivos de aceleración pueden volver a escribir la respuesta del servidor para marcar el objeto como cacheable y suministrar una fecha de caducidad más realista. Esta característica puede ayudar a remediar problemas con off-the-shelf o aplicaciones desarrolladas a medida que el código no puede ser fácilmente modificado.
El almacenamiento en caché
El almacenamiento en caché consiste en el almacenamiento de datos cerca de los usuarios y la reutilización de los datos durante las solicitudes posteriores. El almacenamiento en caché toma generalmente una de tres formas. El primero es el enfoque clásico adoptado por los navegadores web y aplicaciones web. En este caso, el código de la aplicación web que se ejecuta en el servidor da instrucciones a un navegador para almacenar en caché un objeto marcado como estático durante un periodo de tiempo específico. Durante ese período de tiempo, el navegador lee el objeto de la memoria caché en la construcción de una página web hasta que el contenido expire. Luego, el cliente vuelve a cargar el contenido. El almacenamiento en caché evita que el navegador tenga que perder tiempo y ancho de banda mediante el acceso a los datos siempre desde un sitio central. Esta es la forma más común de almacenamiento en caché en uso hoy en día.
La segunda forma consiste en el despliegue de un dispositivo de aceleración en un centro de datos para descargar las solicitudes de contenido de la aplicación web de los servidores web. Este método funciona de forma asimétrica, con la aceleración de almacenamiento en caché de objetos de dispositivo de servidores web y su entrega directamente a los usuarios. Algunos dispositivos son de aceleración caché de contenido estático solamente, mientras que otros, además, puede procesar las respuestas HTTP, incluyendo objetos referenciados en una respuesta, y enviar los objetos incluidos como un solo objeto a un navegador. Esto no sólo descarga el procesamiento del servidor web, sino también descarga el procesamiento del navegador web también. Un beneficio adicional de este enfoque es que, como el dispositivo de aceleración está típicamente en el centro de datos y conectado a las conexiones de mayor velocidad, el dispositivo de aceleración puede ensamblar los objetos de instrucciones en la respuesta HTTP y entregarlos usando menos objetos y con menor número de transacciones .
Operando de esta manera, el almacenamiento en caché puede reducir drásticamente TCP del servidor y el procesamiento de aplicaciones, mejorar la página Web tiempo de carga, y por lo tanto reducir la necesidad de ampliar regularmente el número de servidores web necesarias para dar servicio a una aplicación.
La tercera forma de almacenamiento en caché implica el uso de dispositivos de aceleración simétrica para almacenar en caché y servir contenido a los usuarios en el sitio remoto. El dispositivo de aceleración remoto sirve contenido localmente siempre que sea posible, lo que reduce tanto el tiempo de respuesta como la utilización de la red. Esta forma de almacenamiento en caché se puede implementar no sólo para HTTP, sino también para otros protocolos.
El almacenamiento en caché tiene sus limitaciones. En primer lugar, si el dispositivo de aceleración del lado del cliente sirve contenido, independientemente de si se está en contacto con su par remoto, el dispositivo de cliente debe implementar el control de acceso para evitar el acceso no autorizado a un objeto. En segundo lugar, el dispositivo del lado del cliente puede servir versiones anteriores, rancios de contenidos que cambian después de la conexión entre los dispositivos se rompa. Si bien esto normalmente no es un problema con el contenido de la web estática, puede tener un impacto significativo en los archivos que cambian regularmente. Cuando se abordan ambas cuestiones, el almacenamiento en caché remoto puede mejorar en gran medida el rendimiento de aplicaciones, especialmente para aplicaciones web y archivos estáticos utilizados con otras aplicaciones.
Compresión
La compresión es una de las más antiguas técnicas de aceleración, después de haber estado presente durante décadas. GZIP, el algoritmo de compresión más común, se lleva a cabo en prácticamente todos los navegadores y servidores web. Los algoritmos de compresión como GZIP son buenos para encontrar pequeños, la repetición de patrones y reduciendo los caracteres necesarios para enviarlos.
Además de los servidores web y navegadores, los dispositivos de aceleración aplican compresión. Esto se hace por dos razones: en primer lugar para descargar sobrecarga de compresión de los servidores web y segundo, para permitir que el dispositivo de aceleración realice otras optimizaciones que mejoran el rendimiento para una flujo de HTTP / HTTPS.
La compresión puede ser computacionalmente cara, especialmente para los algoritmos que proporcionan altos niveles de compresión. Estos algoritmos son de uso limitado con la comunicación de alta velocidad, donde los retrasos deben reducirse al mínimo para mantener tiempos rápidos de respuesta del usuario. Por lo tanto, los algoritmos de compresión son más eficaces en comunicaciones de baja velocidad donde hay disponible más tiempo para llevar a cabo el proceso de compresión sin degradar rendimiento para el usuario y, por tanto, los tiempos de respuesta. Afortunadamente, el hardware de compresión de asistencia ya está disponible en algunos dispositivos de aceleración que pueden lograr tasas de compresión superiores a 1 Gbps.
Pipelining (Tuberias de HTTP)
Todo el mundo quiere sitios web y aplicaciones que carguen más rápido, y no hay escasez de gente por ahí en busca de maneras de hacer precisamente eso. Pero no todo lo que brilla es oro y no todas las técnicas de aceleración realmente no hacen todo lo que pueden para acelerar la entrega de aplicaciones y sitios web. Peor aún, algunos crean riesgos de que los servidores puedan ser atacados.
Una breve historia
Cuando HTTP estaba todavía en evolución, a alguien se le ocurrió el concepto de conexiones persistentes. HTTP 1.0 requería una conexión TCP para cada objeto en una página. Eso estaba bien, hasta que comenzaron las páginas que contenían diez, veinte, y más objetos. Así que alguien añade una cabecera HTTP, mantenimiento de conexiones, que básicamente dijo que el servidor no cerrarara la conexión TCP hasta que uno, el navegador lo cerraba o que se acabó el tiempo. Esto a la larga se convirtió en el comportamiento por defecto cuando HTTP 1.1 y se convirtió en un estándar.
Te dije que era una breve historia.
Esta capacidad se conoce como una conexión persistente, porque la conexión persiste a través de múltiples peticiones. Esto no es lo mismo que la canalización, aunque las dos están estrechamente relacionados. Pipelining lleva el concepto de conexiones persistentes y luego ignora la solicitud tradicional - responde a relación inherente en HTTP y lo tira por la ventana.
La línea general de pensamiento es la siguiente:
“Whoa. ¿Y si solo envío todas las peticiones de una página en el servidor y luego espero para que todos puedan volvera la vez en lugar de hacerlo uno en uno? Podríamos hacer las cosas aún más rápido!”
HTTP pipelining
En términos técnicos, el navegador inicia la canalización HTTP mediante la apertura de una conexión con el servidor y luego envía múltiples peticiones al servidor sin esperar una respuesta. Una vez que las todas solicitudes se envían entonces el navegador empieza a recibir las respuestas. La razón por la que esto se considera una técnica de aceleración es que al empujar todas las peticiones en el servidor a la vez esencialmente evitamos el RTT (Round Trip Time) en la conexión a la espera de una respuesta por cada petición se envíe.
¿Por qué simplemente no importa más (y quizás nunca lo hizo)
Por desgracia, la canalización fue concebida e implementada antes de las conexiones de banda ancha que ahora se utilizan ampliamente como un método de acceso a Internet. En aquel entonces, el RTT era lo suficientemente importante como para tener un impacto negativo en la aplicación y el rendimiento del sitio web y la experiencia de usuario en general se ha mejorado por el uso de la canalización. Hoy, sin embargo, la mayoría de la gente tiene una velocidad cómoda en la que acceden a Internet y el impacto en el rendimiento de RTT en aplicaciones web, a pesar del creciente número de objetos por página, es relativamente bajo.
No hay discusión sobre que una cierta reducción en el tiempo de carga es mejor que nada.
El problema es que la canalización no se trata en realidad de forma diferente en el servidor de viejas conexiones regulares persistentes. De hecho, la especificación HTTP 1.1 requiere que un “servidor debe enviar sus respuestas a esas peticiones en el mismo orden en que se recibieron las solicitudes.” En otras palabras, las solicitudes son de retorno en serie, a pesar de que algunos servidores web pueden realmente procesar esas peticiones en paralelo. Debido a que el servidor deberá devolver respuestas a las solicitudes, el servidor tiene que hacer algo de procesamiento adicional para asegurar el cumplimiento de esta parte de la especificación HTTP 1.1. Tiene que hacer colas de las respuestas y hacer ciertas que respuestas se devuelvan correctamente, lo que anula esencialmente el rendimiento obtenidos al reducir el número de idas y vueltas utilizando la canalización.
En función del orden en que se envían las solicitudes, si una solicitud que requiere un tratamiento especialmente largo - por ejemplo una consulta de base de datos - fue enviada relativamente temprano en la tubería, en realidad esto podría provocar una degradación de rendimiento, ya que todas las otras respuestas tienen que esperar hasta que los otros pueden ser enviados de vuelta.
Los intermediarios de aplicación tales como proxies, controladores de entrega de aplicaciones, y balanceadores de carga generales no solo pueden y apoyan la canalización, sino que, también, se adherirán a la especificación del protocolo y devolverán respuestas en el orden adecuado de acuerdo a como se recibieron las solicitudes. Esta limitación en el lado del servidor en realidad inhibe potencialmente un impulso significativo en el rendimiento, ya que sabemos que el procesamiento de las solicitudes dinámicas lleva más tiempo que la tramitación de una solicitud de contenido estático.
Si se elimina esta limitación es posible que el servidor pudiera ser más eficiente y el usuario podría experimentar mejoras no triviales en el rendimiento. O bien, si los intermediarios son lo suficientemente inteligentes como para reorganizar las solicitudes de tal manera que su ejecución se optimiza y además mantenemos los beneficios de rendimiento obtenidos por la canalización. Pero eso requeriría una comprensión de la aplicación que va mucho más allá de lo que incluso los controladores de entrega de aplicaciones más inteligentes de hoy en día son capaces de proporcionar.
El revestimiento de plata
En este punto, puede ser bastante decepcionante saber que la canalización HTTP hoy no da lugar a tan significativa ganancia de rendimiento como podría parecer en un principio (excepto a través de enlaces de latencia alta como satélites o de acceso telefónico, que están disminuyendo rápidamente en el uso ). Pero eso puede ser una buena cosa.
Como los malhechores han vuelto más inteligentes y más inteligente sobre la explotación de los protocolos y no sólo código de la aplicación, que han aprendido a aprovechar el protocolo para engañar a los servidores en la creencia de que sus peticiones son legítimas, a pesar de que el resultado deseado es generalmente malicioso. En el caso de la canalización (pipelining), sería simple explotar la capacidad en el servidor en cuestión de crear un ataque DoS de capa 7. Debido a que la canalización asume que las solicitudes serán enviadas una tras otra y que el cliente no está a la espera de la respuesta hasta el final, tendría un momento difícil distinguir entre alguien que intenta consumir recursos y una solicitud legítima.
Tengamos en cuenta que el servidor no tiene conocimiento de una “página”. Entiende peticiones individuales. No tiene forma de saber que una “página” se compone de sólo 50 objetos, y por lo tanto en un cliente pipelining las solicitudes máximas permitidas por defecto - 100 para Apache - no puede ser vista como fuera de lo normal. Varios clientes abriendos conexiones y canalizando cientos o miles de peticiones por segundo sin importar si reciben alguna de las respuestas podrían consumir de forma rápida recursos del servidor o del ancho de banda disponible y causar una denegación de servicio a los usuarios legítimos.
Así que, aunque tal vez el hecho de que la canalización no sea realmente tan útil, para la mayoría de la gente es una buena cosa, ya que los administradores de servidores pueden desactivar la función sin demasiada preocupación y por lo tanto reducir el riesgo de la característica para ser aprovechada como un método de ataque contra ellos.
Como Pipelining se especifica e implementa hoy es más que un riesgo para la seguridad una mejora de rendimiento. Hay, sin embargo, retoques en la especificación que se podrían hacer en el futuro que hagan que sea más útil.
No hay comentarios:
Publicar un comentario