A menudo se menciona que los beneficios derivados de algunos controladores de entrega de aplicaciones son debidos a la naturaleza de ser un proxy completo. Y en la misma categoría que podríamos mencionar inversa, medio y servidores proxy de reenvío, lo que hace que la tecnología suene más como una descripción de las posiciones en un equipo deportivo que una solución de entrega de aplicaciones. Entonces, ¿qué significan realmente estos términos? Aquí está la verdad sobre los diferentes tipos de servidores proxy en una guía concisa.
Proxies
Proxies (a menudo llamados intermediarios en el mundo SOA) son soluciones de hardware o software que se sitúan entre el cliente y el servidor y hacen algo a las peticiones y las respuestas a veces. El uso más a menudo oído hablar del término proxy es en conjunción con la fabricación de navegación anónima. Esto se debe a proxies que se asientan entre su navegador y su destino deseado y el proxy de la conexión; es decir que hable con el proxy, mientras que las conversaciones de proxy para el servidor web y ni usted ni el servidor web saben el uno del otro.
Los proxies no son todos iguales. Algunos son la mitad de los proxies, algunos son proxies de pleno derecho; algunos son Proxies de reenvío y algunos son inversos.
Proxies de reenvío
Los Proxies de reenvío son probablemente los más conocidos de todos los proxies, principalmente porque la mayoría de la gente ha tratado con ellos, ya sea directa o indirectamente. Proxies de reenvío son aquellos que se colocan entre dos redes, por lo general una red interna privada y la Internet pública. Los grandes proveedores de servicios también se han empleado tradicionalmente hacia Proxies de reenvío como un puente entre su red aislada de suscriptores y la Internet pública, tales como CompuServe y AOL en los días pasados. Estos se refieren a menudo como “mega-proxies” porque lograron tan altos volúmenes de tráfico.
Los Proxies de reenvío son generalmente proxies HTTP (web) que proporcionan una serie de servicios que se centran principalmente en los servicios de filtrado y almacenamiento en caché de contenido web. Estos Proxies de reenvío a menudo incluyen la autenticación y la autorización como parte de su producto para proporcionar un mayor control sobre el acceso al contenido público. Si alguna vez se ha conseguido una página web que dice “Su solicitud ha sido negada por bla, bla. Si usted piensa que esto es un error por favor, póngase en contacto con el servicio de asistencia / su administrador”, entonces usted probablemente ha utilizado un proxy de reenvío.
Proxies inversos
Un proxy inverso es menos conocido, en general, porque no usamos el término más que para describir los productos utilizados como tales. Los balanceadores de carga (controladores de entrega de aplicaciones) y caches son buenos ejemplos de los proxies inversos. Los proxies inversos se instalan delante de los servidores Web y de aplicaciones y tramitan las solicitudes de aplicaciones y contenidos que vienen de la Internet pública a la red interna, privada. Esta es la principal razón para el nombre del proxy “inverso” para diferenciarlo de un proxy que maneja las solicitudes salientes.
Los proxies inversos también se centran generalmente en HTTP pero en los últimos años se han ampliado para incluir una serie de otros protocolos comúnmente utilizados en la web, tales como la transmisión de audio (RTSP), la transferencia de archivos (FTP), y en general cualquier protocolo de aplicación capaz de ser entregado a través de UDP o TCP.
Proxies Medios
Proxy medio es una descripción de la manera en que un proxy, inverso o de reenvío, maneja las conexiones. Hay dos usos del término proxy medio: una describe de una configuración de despliegue que afecta a la forma en que las conexiones se manejan y, otra que describe simplemente la diferencia entre una primera y subsiguientes conexiones.
La definición está asociada con una configuración de servidor de retorno directo (DSR). Las solicitudes se aproximan por el dispositivo, pero las respuestas no devuelven a través del dispositivo, sino que más bien se envían directamente al cliente. Para algunos tipos de datos, en particular los protocolos de transmisión, esta configuración da como resultado un rendimiento mejorado. Esta configuración se conoce como un proxy medio, porque sólo la mitad de la conexión (entrante) pasa a través del proxy mientras que el otro medio, la respuesta, no lo es.
El segundo uso de la expresión “proxy medio” describe una solución en la que el proxy realiza lo que se conoce como retraso de unión con el fin de proporcionar funcionalidad adicional. Esto permite que el proxy examine la solicitud antes de determinar dónde enviarlo. Una vez que el proxy determina dónde encaminar la solicitud, la conexión entre el cliente y el servidor se “cosen” juntas. Esto se conoce como un proxy medio porque el protocolo de enlace TCP inicial y las primeras solicitudes se aproximan por la solución, pero posteriormente son remitidos sin intercepción.
La mitad de los proxies puede ver en las solicitudes de entrada con el fin de determinar que la conexión se debe enviar e incluso pueden utilizar técnicas para llevar a cabo la inspección de capa 7, pero rara vez son capaces de examinar las respuestas. Casi todas los proxies medios entran en la categoría de los proxies inversos.
Proxies completos
Proxy completo es también una descripción de la manera en que un proxy, inverso o de reenvío, maneja las conexiones. Un proxy completo mantiene dos conexiones independientes - uno entre él mismo y el cliente y, uno entre él mismo y el servidor de destino. Un proxy completo entiende completamente los protocolos, y es en sí mismo un punto final y un originador de los protocolos. Los proxies completos son nombrados así porque manejan todas la conexiones, ya sea conexiones entrantes o salientes.
Debido a que el proxy completo es un punto final protocolo real, debe dar pleno cumplimiento de los protocolos como un cliente y un servidor (un diseño basado en paquetes no lo hace). Esto también significa que el proxy completo puede tener su propio comportamiento de la conexión TCP, tales como tampón, retransmisiones, y las opciones de TCP. Con un proxy completo, cada conexión es única; cada uno puede tener su propio comportamiento TCP. Esto significa que un cliente que se conecta al dispositivo de proxy completo tendría probablemente diferente comportamiento de una conexión que el proxy completo podría utilizar para la comunicación con los servidores. Los proxies completos pueden mirar las peticiones de respuesta entrantes y salientes y las puede manipular si la solución permite.
Muchos servidores proxy inversos y de reenvío utilizan un modelo de proxy completo en la actualidad. No hay ninguna garantía de que una solución dada es un proxy completo, por lo que siempre debe preguntar a su proveedor de soluciones, si es importante para usted, que la solución sea un proxy completo.
2,04 - Describir a / arquitectura basada en paquetes de reenvío de paquetes Reenvío de paquetes
Reenvío de paquetes
El reenvío de paquetes es la retransmisión de los paquetes de un segmento de red a otro por los nodos en una red informática. Es un patrón de desvío de unidifusión, típico de muchas tecnologías de red, incluyendo la inmensa mayoría del tráfico de Internet un patrón de multidifusión de reenvío, típicos de PIM, un patrón de reenvío de difusión, típico de puenteado Ethernet.
La capa de red de la Capa OSI es responsable del envío de paquetes. El reenvío simple modelo- unicasting-implica un paquete que se retransmite desde un enlace a lo largo de una cadena que conduce desde la fuente del paquete a su destino. Sin embargo, se utilizan habitualmente otras estrategias de reenvío. El broadcasting requiere que se duplique un paquete para ser y las copias son enviadas a múltiples vínculos con el objetivo de entregar una copia a cada dispositivo de la red. En la práctica, los paquetes de difusión (broadcast) no se reenvían todas partes en una red, sólo a los dispositivos dentro de un dominio de difusión. Menos común que la radiodifusión, pero quizás de mayor utilidad e importancia teórica, es multidifusión (multicast), donde un paquete se duplica de forma selectiva y copias entregado a cada uno de un conjunto de receptores.
Las tecnologías de red tienden a apoyar de forma natural en algunos modelos de reenvío. Por ejemplo, la fibra óptica y cables de cobre se ejecutan directamente desde una máquina a otra para formar un medio de comunicación de unidifusión naturales - los datos transmitidos en un extremo son recibidos por una sola máquina en el otro extremo. Sin embargo, como se ilustra en los diagramas, los nodos pueden reenviar paquetes para crear distribuciones de multidifusión o difusión de medios de comunicación naturalmente unidifusión. Del mismo modo, tradicional Ethernet (10BASE5 y 10BASE2, pero no el más moderno 10BASE-T) son medios de difusión naturales - todos los nodos están conectados a un solo cable de longitud y un paquete transmitido por un dispositivo es visto por cualquier otro dispositivo conectado al cable . Los nodos Ethernet implementan unicast e ignoran paquetes no dirigidos directamente a ellos. Una red inalámbrica es, naturalmente, de multidifusión - todos los dispositivos dentro de un radio de recepción de un transmisor pueden recibir sus paquetes. Los nodos inalámbricos ignoran los paquetes dirigidos a otros dispositivos, pero requieren de reenvío para llegar a los nodos fuera de su radio de recepción.
En los nodos donde múltiples enlaces salientes están disponibles, la elección de las cuales, todas o ninguna para la transmisión de un paquete dado requiere un proceso de toma de decisiones que, aunque es simple en concepto, a veces es asombrosamente complejo. Dado que una decisión de reenvío se debe hacer para cada paquete manejado por un nodo, el tiempo total requerido para esto puede convertirse en un factor limitante importante en el rendimiento global de la red. Gran parte del esfuerzo de diseño de los routers de alta velocidad y los switches se ha centrado en la toma de decisiones rápidas de reenvío para un gran número de paquetes.
La decisión de reenvío se hace generalmente usando uno de dos procesos: enrutamiento, que utiliza la información codificada en la dirección de un dispositivo para deducir su ubicación en la red, o puente, que no hace suposiciones sobre dónde se encuentran las direcciones y depende en gran medida de la difusión para localizar desconocida direcciones. La pesada sobrecarga de difusión ha llevado a la dominancia de enrutamiento en redes grandes, en particular Internet; el puente es relegado en gran medida a las pequeñas redes en las que la sobrecarga de la difusión es tolerable.
Una red puede utilizar uno de dos métodos diferentes para reenviar paquetes: store-and-forward o cut through.
Diseño basado en paquetes
Un dispositivo de red con un diseño de "packet-based"( paquete por paquete) se encuentra en el medio de una corriente de comunicaciones, pero no es un punto final para aquellas comunicaciones basada en paquetes; simplemente pasa los paquetes a través de él. A menudo, un dispositivo que opera sobre una base de paquete a paquete tiene algún conocimiento de los protocolos que fluyen a través de él, pero está lejos de ser un verdadero punto final del protocolo. La velocidad de estos dispositivos se basa principalmente en no tener que entender toda la pila de protocolos, y así reducir la cantidad de trabajo necesario para manejar el tráfico. Por ejemplo, con el protocolo TCP / IP, este tipo de dispositivo podría comprender solamente los protocolos lo suficientemente bien como para volver a escribir las direcciones IP y puertos TCP; sólo la mitad de toda la pila.
A medida que las redes se volvieron más complejas y la necesidad de la inteligencia aumentaron, diseños basados en paquetes más avanzados comenzaron a emerger (incluyendo los productos BIG-IP de F5). Estos dispositivos sabían TCP / IP lo suficientemente bien como para entender tanto la configuración de la conexión TCP y desmontaje, modificar las cabeceras TCP / IP, e incluso insertar datos en flujos TCP. Debido a que estos sistemas podrían insertar datos en flujos TCP y modificar el contenido de la corriente, también tenían que volver a escribir la secuencia de TCP (SEC) y los valores de acuse de recibo (ACK) para los paquetes que van de ida y vuelta desde el cliente y el servidor. Los productos BIG-IP de F5 entienden TCP / IP y HTTP lo suficientemente bien como para identificar las peticiones HTTP individuales y pueden enviar diferentes peticiones a diferentes servidores, la reutilización de las conexiones del dispositivo BIG-IP que ya tenía abiertas.
Mientras todo esto es posible con un muy sofisticado arquitectura paquete por paquete (los dispositivos BIG-IP son algunos de los más sofisticados de tales diseños hasta la fecha), se requiere un complejo motor de seguimiento del estado de entender el protocolo TCP / IP y HTTP protocolos lo suficientemente bien como para volver a escribir el contenido de encabezado, insertar datos, y mantener sus propias conexiones a los clientes y servidores.
A pesar de esta creciente complejidad, diseños basados en paquetes son mucho menos complejos y más rápidos que los diseños tradicionales basado en proxy, ya que tienen la ventaja de que sólo requiere un pequeño porcentaje de la lógica requerida para un proxy completo.
2.04 - Dada una lista de situaciones, determinar qué es apropiado para una arquitectura de proxy completo
Arquitectura completa de proxy - ¿Qué quieren decir?
La razón de que haya una distinción entre “proxy” y “full-proxy” se deriva de la manipulación de las conexiones a medida que fluyen a través del dispositivo. Todos los proxies se istalan entre dos entidades - en tiempos de Internet casi siempre “cliente” y “servidor” - y median entre las conexiones. Si bien todos los "full-proxies" son proxies, lo contrario no es así.. No todos los proxies son full-proxies y es esta distinción la que hay que hacer cuando se toman decisiones que afectarán a la arquitectura del centro de datos.
Un proxy completo (full-proxy) mantiene dos tablas de sesión separadas - uno en el lado del cliente, otra en el lado del servidor. Los clientes a menudo experimentan una mayor latencia debido a las conexiones de ancho de banda más bajos, mientras que los servidores son generalmente de baja latencia porque están conectados a través de una LAN de alta velocidad. Las optimizaciones y técnicas de aceleración utilizados en el lado del cliente son muy diferentes a los del lado LAN debido a los problemas que dan origen a los desafíos de rendimiento y disponibilidad son muy diferentes.
Un full proxy, con manejo a ambos lados de la conexión, puede hacer frente a estos desafíos. Un proxy, que puede ser un proxy completo, pero no suele, simplemente utiliza una metodología "buffer-and-stitch" para llevar a cabo la gestión de conexiones, no puede hacerlo de manera óptima. Un proxy típico amortigua una conexión, a menudo a través del proceso TCP apretón de manos y potencialmente en los primeros paquetes de datos de la aplicación, pero entonces “cose” una conexión a un servidor determinado en el back-end utilizando ya sea capa 4 o la capa 7 de datos, tal vez ambos. La conexión es un único flujo de extremo a extremo y debe elegir qué características de la conexión a centrarse en - cliente o servidor - porque no puede optimizar simultáneamente para ambos.
La segunda ventaja de un proxy completo es su capacidad para realizar más tareas sobre los datos que se intercambian a través de la conexión, ya que está fluyendo a través del componente. Debido a que se debe tomar una acción específica para “machear” la conexión y su flujo a través del proxy completo, el componente puede inspeccionar, manipular y alterar de otro modo los datos antes de enviarlos en su camino en el lado del servidor. Esto es lo que permite la terminación de SSL, la aplicación de políticas de seguridad, y servicios relacionados con el rendimiento que se aplicará sobre una base por cliente o por aplicación.
Esta capacidad se traduce en el uso más amplio en la arquitectura del centro de datos al permitir la aplicación de un nivel de distribución de aplicaciones en las que el riesgo operativo puede abordarse mediante la aplicación de diversas políticas. En efecto, creamos una arquitectura completa de proxy centro de datos en la que el nivel de entrega de aplicaciones en su conjunto sirve como el “proxy completo” que media entre los clientes y las aplicaciones.
La arquitectura de pleno centro de datos de proxy
Una arquitectura de full proxy de centro de datos instala un “espacio de aire” digital entre el cliente y las aplicaciones al servir como la agregación (y por el contrario desagregación) de puntos para servicios. Debido a que toda la comunicación se canaliza a través de aplicaciones y servicios virtualizados en el nivel de entrega de aplicaciones, sirve como un punto estratégico de control en el que se pueden hacer cumplir las políticas de entrega para el riesgo operacional (rendimiento, disponibilidad, seguridad).
Una arquitectura de full proxy de centro de datos tiene además la ventaja de aislar a los usuarios finales de la volatilidad inherente en entornos altamente virtualizados y dinámicos como la nube. Permite a soluciones como las que se utilizan para superar las limitaciones con la tecnología de virtualización, tales como las que se encuentran con las limitaciones arquitectónicas en las implementaciones de VMware View. Las tecnologías de gestión de acceso tradicionales, por ejemplo, están estrechamente vinculadas a nombres de host y direcciones IP. En un entorno informático altamente virtualizado o nube, esta limitación puede significar un desastre para la velocidad o la capacidad de funcionar, o ambos. Mediante la implementación de la gestión de acceso en el nivel de entrega de aplicaciones - en un dispositivo completo de proxy - la volatilidad se gestiona a través de la virtualización de los recursos, lo que permite al controlador de entrega de aplicaciones que preocuparse de detalles como la dirección y VLAN segmentos IP, liberando a la solución de gestión de acceso a la preocupación en sí con la determinación de si este usuario en este dispositivo desde esa ubicación se permite acceder a un recurso dado.
Básicamente, nos estamos tomando el concepto de un proxy completo y ampliado hacia el exterior de la arquitectura. La inserción de un “nivel de entrega de aplicaciones” permite una arquitectura ágil, flexible más a favor de los cambios rápidos con los que las organizaciones de IT de hoy en día tienen que lidiar.
Tal nivel también proporciona un medio eficaz para combatir los ataques modernos. Debido a su capacidad de aislar las aplicaciones, servicios y recursos de infraestructura, incluso, un nivel de entrega de aplicaciones, mejora la capacidad de una organización de resistir la embestida de un ataque DDoS. La magnitud de la diferencia entre la capacidad de conexión de un controlador de entrega de aplicaciones y la mayoría de las infraestructuras (y todos los servidores) da toda la arquitectura de una elasticidad mayor en la cara de las conexiones abrumadoras. Esto asegura una mejor disponibilidad y, cuando se combina con la infraestructura virtual que puede escalar bajo demanda cuando sea necesario, también puede mantener los niveles de rendimiento requeridos por las preocupaciones empresariales.
Una arquitectura full proxy de centro de datos es un activo de gran valor para las organizaciones de IT frente a los retos de la volatilidad, tanto dentro como fuera del centro de datos.
2,04 - Dada una lista de las situaciones, determinar que es apropiado para una arquitectura basada en paquetes
¿Qué es un diseño basado en paquetes?
Un dispositivo de red con un diseño de "packet-based"( paquete por paquete) se encuentra en el medio de una corriente de comunicaciones, pero no es un punto final para aquellas comunicaciones basada en paquetes; simplemente pasa los paquetes a través de él. A menudo, un dispositivo que opera sobre una base de paquete a paquete tiene algún conocimiento de los protocolos que fluyen a través de él, pero está lejos de ser un verdadero punto final del protocolo. La velocidad de estos dispositivos se basa principalmente en no tener que entender toda la pila de protocolos, y así reducir la cantidad de trabajo necesario para manejar el tráfico. Por ejemplo, con el protocolo TCP / IP, este tipo de dispositivo podría comprender solamente los protocolos lo suficientemente bien como para volver a escribir las direcciones IP y puertos TCP; sólo la mitad de toda la pila.
A medida que las redes se volvieron más complejas y la necesidad de la inteligencia aumentaron, diseños basados en paquetes más avanzados comenzaron a emerger (incluyendo los productos BIG-IP de F5). Estos dispositivos sabían TCP / IP lo suficientemente bien como para entender tanto la configuración de la conexión TCP y desmontaje, modificar las cabeceras TCP / IP, e incluso insertar datos en flujos TCP. Debido a que estos sistemas podrían insertar datos en flujos TCP y modificar el contenido de la corriente, también tenían que volver a escribir la secuencia de TCP (SEC) y los valores de acuse de recibo (ACK) para los paquetes que van de ida y vuelta desde el cliente y el servidor. Los productos BIG-IP de F5 entienden TCP / IP y HTTP lo suficientemente bien como para identificar las peticiones HTTP individuales y pueden enviar diferentes peticiones a diferentes servidores, la reutilización de las conexiones del dispositivo BIG-IP que ya tenía abiertas.
Mientras todo esto es posible con un muy sofisticado arquitectura paquete por paquete (los dispositivos BIG-IP son algunos de los más sofisticados de tales diseños hasta la fecha), se requiere un complejo motor de seguimiento del estado de entender el protocolo TCP / IP y HTTP protocolos lo suficientemente bien como para volver a escribir el contenido de encabezado, insertar datos, y mantener sus propias conexiones a los clientes y servidores.
¿Qué es un diseño basado en proxy (Proxy completo)?
Un diseño completo proxy es lo contrario de un diseño de paquete por paquete. En lugar de tener un mínimo conocimiento de las comunicaciones que fluyen a través del dispositivo, un proxy completo entiende completamente los protocolos, y es en sí misma un punto final y un originador de los protocolos. La conexión entre un cliente y el proxy completo es totalmente independiente de la conexión entre el pleno proxy y el servidor; mientras que en un diseño de paquete por paquete, no hay esencialmente un canal de comunicación directa entre el cliente y el servidor (aunque el dispositivo en el medio puede manipular los paquetes que van hacia atrás y adelante).
Debido a que el proxy completo es un punto final protocolo real, debe dar pleno cumplimiento de los protocolos como un cliente y un servidor (un diseño basado en paquetes no lo hace). Esto también significa que el proxy completo puede tener su propio comportamiento de la conexión TCP, tales como tampón, retransmisiones, y las opciones de TCP. Con un proxy completo, cada conexión es única; cada uno puede tener su propio comportamiento TCP. Esto significa que un cliente que se conecta al dispositivo completo de proxy tendría probablemente diferente comportamiento de conexión que el proxy completo podría utilizar para la comunicación con los servidores de back-end.
Por lo tanto, un proxy completo permite la optimización de cada conexión de forma única, independientemente de la fuente original y el destino final. Además, un proxy completo entiende y procesa cada protocolo como un cliente real o servidor haría, el uso de capas. El uso de HTTP como un ejemplo, primero el protocolo IP se procesa, a continuación, TCP, a continuación, HTTP; y cada capa tiene ningún conocimiento de las capas inferiores.
La redefinición de la Solución
Es de conocimiento común que las soluciones basadas en proxy, o al menos la inteligencia ofrecida por ellos, eran la solución definitiva. Sin embargo, el rendimiento muy superior de diseños de paquete a paquete más que compensado por su inteligencia limitada. Durante un tiempo, este fue un compromiso aceptable para la mayoría de las redes empresariales. A medida que la necesidad de una mayor inteligencia crece, las soluciones basadas en paquetes están experimentando rápidamente las mismas restricciones de rendimiento que las soluciones basadas en proxy siempre han sufrido. Y la complejidad del desarrollo de soluciones basadas en paquetes que se está acercando rápidamente de diseños basados en proxy también. A pesar de los aumentos dramáticos en hardware y software potencia, diseños de paquete a paquete no son capaces de mantenerse al día con la necesidad de inteligencia y el rendimiento. Ya no es aceptable tener que elegir entre ellos. Mientras que las soluciones "packet-based" tuvieron su vez, el tiempo se ha ido. Ahora es evidente que acortando la inteligencia en lugar del rendimiento no proporcionó una solución viable. La verdadera solución es la construcción de una solución basada en proxy con el rendimiento de la solución basada en paquetes.
No hay comentarios:
Publicar un comentario