Comprensión de los proxies de aplicación Un proxy de aplicación era una pieza de software que se insertaba en medio del flujo de datos de una aplicación (que generalmente operaba entre las capas 4 -7 del modelo OSI) como una cuña para «arreglar» una característica de la aplicación que hacía que funcionara mal en una conexión WAN.
Estas «correcciones» solían ser de dos tipos:

  • Los que ayudaron a permitir la deduplicación de los datos de la aplicación; o
  • Los que ayudaron a reducir la cantidad total de comunicación («chattiness») requerida por dos puntos finales de aplicación a través de una conexión WAN.

Los proxies de aplicaciones (utilizados por proveedores tradicionales de optimización de WAN como Riverbed) son una tecnología antigua y cada vez se utilizan con menos frecuencia en el espacio de la optimización de WAN en la actualidad. 5razonesporqué Y he aquí las 5 razones principales de esta transición: 1) Los proxies de aplicaciones tienen una alta propensión a «romper» muchas de las aplicaciones a las que pretenden ayudar. Ésta es, con diferencia, la mayor razón por la que la tecnología de optimización de la WAN se ha alejado en gran medida del modelo de «proxy de capa 7».
Un proxy de aplicación debe escribirse según la especificación exacta del protocolo de aplicación.
Esto suele estar bien para protocolos estables y de bajo nivel como SSL, pero se convierte en un problema para protocolos de más alto nivel y más propietarios como MS-SQL, o Citrix ICA.
Estos protocolos cambian con frecuencia y los cambios no se publican.
Como ocurre tan a menudo en el mundo del administrador de red, un servidor en algún lugar se actualiza, y la primera pista de que un protocolo de aplicación ha cambiado llega cuando empiezan a llover las quejas de los usuarios sobre que la aplicación ya no funciona correctamente.
Una vez identificado el proxy de la aplicación como la causa de la avería, es necesario actualizarlo para que sea compatible con la nueva versión de la aplicación.
Y como estos protocolos a menudo tienen que ser sometidos a ingeniería inversa por el proveedor del proxy, la «solución» para esta rotura puede tardar muchos meses o más (dependiendo de si se considera «ampliamente utilizada») antes de que esté disponible.
Esto deja al administrador de la red con sólo dos opciones:
1) Decir al administrador del servidor que la red no es compatible con la nueva versión de la aplicación; o
2) Configurar los proxies de la aplicación para que ignoren (by-pass) la nueva aplicación, dejando esencialmente la aplicación sin ninguna optimización. 2) Un protocolo concreto deja de utilizarse poco a poco. Un ejemplo de este tipo de transición puede verse hoy en día con algunos protocolos cifrados propietarios, como MAPI.
MAPI es el protocolo de correo electrónico propietario de Microsoft Exchange Server, pero con la evolución de más aplicaciones basadas en la nube y SaaS, SSL se está convirtiendo rápidamente en el protocolo corporativo de elección para SOHO y usuarios móviles.
Y puesto que Microsoft también admite SSL para su entrega de correo electrónico Exchange, muchas empresas se están alejando de MAPI hacia SSL no propietario.
A medida que las aplicaciones evolucionan alejándose de los protocolos propietarios, este tipo de proxies se vuelven obsoletos. 3) La tecnología de optimización de la WAN ha evolucionado hasta el punto de que ya no es necesario un proxy específico. NFS es un buen ejemplo.
NFS v3, como protocolo de compartición de archivos, tenía ciertas limitaciones en el rendimiento y el tiempo de respuesta del usuario final relacionadas con las latencias de la WAN.
Esto se debía principalmente a la forma en que estaba diseñado el protocolo, que limitaba la cantidad de datos que podían transmitirse a la vez sin recibir respuestas de la aplicación.
Al mismo tiempo, las tecnologías de optimización de la WAN existentes se centraban principalmente en la deduplicación de datos como método para reducir el total de datos que debían enviarse de un lado a otro de la WAN y, de este modo, eliminar la congestión para mejorar el tiempo de respuesta.
Pero estas antiguas tecnologías de optimización de la WAN utilizaban una forma de deduplicación a nivel de bloque que no funcionaba muy bien en el tráfico NFS, porque para hacer coincidir un bloque de datos, ayuda saber dónde empieza la porción de datos de una transmisión.
La ubicación de la porción de datos dentro de una transmisión del protocolo NFS puede variar.
La mejor solución en aquel momento para «arreglar» el problema de la WAN NFS era escribir un proxy de aplicación, que disminuyera artificialmente la cantidad de comunicación requerida por el protocolo y además averiguara dónde estaba la porción de datos de la transmisión NFS para que la deduplicación a nivel de bloque pudiera ser efectiva.
Los proveedores tradicionales de optimización WAN siguen necesitando un calce para la optimización NFS, porque siguen utilizando la tecnología de deduplicación más antigua, pero los proveedores más recientes pueden optimizar el tráfico NFS sin necesidad de un proxy específico de la aplicación, ¡y una optimización mínima del proxy significa menos cosas que romper en su red! 4) Algunas aplicaciones o protocolos que no funcionaban bien a través de una conexión WAN hace 10 años han evolucionado o se han rediseñado para que puedan funcionar a través de una WAN sin un calce intermedio. De nuevo, fijémonos en NFS.
Avancemos rápido hasta hoy: las últimas versiones de NFS v4.x solucionaron la mayoría de las limitaciones del protocolo relacionadas con el chateo y el rendimiento.
Los límites restantes se resuelven mediante la optimización genérica de TCP, sin necesidad de un calce específico para la aplicación. 5) Una arquitectura tecnológica «Application Proxy» no es un modelo sostenible desde una perspectiva empresarial y de desarrollo. En primer lugar, su mantenimiento es muy costoso.
Hay que desarrollar nuevos mecanismos de optimización específicos para el proxy de la aplicación cada vez que los proveedores de la aplicación lanzan nuevas versiones de las aplicaciones o sus actualizaciones.
Tomemos como ejemplo Citrix ICA: ellos son los propietarios del protocolo y pueden realizar cambios en la especificación del protocolo en cualquier momento; de una versión a otra, o incluso dentro de una actualización de un paquete de servicios.
Hacer un seguimiento de todos estos proxies de aplicaciones y seguir dando soporte a protocolos obsoletos no es un modelo de negocio muy eficiente.
También limita la escalabilidad futura.
La propia naturaleza de un proxy es actuar en nombre del servidor remoto.
Para ello, el proxy debe terminar y hacer un seguimiento de cada sesión de aplicación.
Esto crea una sobrecarga muy elevada en términos de requisitos de hardware, lo que se traduce en la necesidad de cajas cada vez más grandes.
Afortunadamente, los problemas que antes resolvían los proxies a nivel de aplicación se solucionan ahora de maneras más eficientes, dejando obsoletas algunas de las ventajas originales de la antigua tecnología proxy.
Todavía existen algunos protocolos de capa de aplicación, como las versiones antiguas de CIFS o SMB, que se benefician de contar con un proxy específico para su optimización a través de la WAN, pero esa lista se reduce constantemente.
Al reducir la dependencia de proxies específicos de la capa de aplicación, la tecnología actual puede proporcionar una mejor optimización al tiempo que mejora la fiabilidad y elimina posibles puntos de fallo.