En mi último blog, hablé de por qué los proxies de aplicaciones se utilizan cada vez con menos frecuencia en el espacio de la optimización WAN hoy en día.
Recapitulando, la razón NÚMERO UNO por la que la tecnología se ha alejado en gran medida del modelo de «proxy de capa 7» es por la alta propensión a «romper» muchas de las aplicaciones a las que pretenden ayudar. El enfoque Aryaka

App_Proxy

Entonces, ¿cómo puede Aryaka optimizar el tráfico sin docenas de proxies de Capa 7 específicos para aplicaciones como «los otros tipos»?
Muy sencillo.
Solucionando la raíz del problema de la aplicación, en lugar de intentar enmascarar el síntoma.
Por ejemplo, fíjese en la tecnología de deduplicación de datos.
Si bien es cierto que las antiguas versiones «basadas en bloques» de los motores de deduplicación necesitaban saber dónde empezaba la porción de datos de un paquete IP y debían ser capaces de hacer coincidir un bloque de datos contiguos para obtener resultados de deduplicación razonables, los motores de deduplicación «a nivel de byte» más recientes, como la tecnología que Aryaka utiliza en nuestra pila de software de optimización WAN, son capaces de deduplicar datos en cualquier parte del paquete IP, haciendo innecesaria la necesidad de disponer de proxies específicos para aplicaciones como NFS y SRDF.
De todos modos, las aplicaciones ligeras y transaccionales como MS-RDP o Citrix ICA no se benefician de la deduplicación.
En estos casos, la cantidad de datos en los paquetes IP es muy pequeña y ya está comprimida.
Los problemas de rendimiento que experimentan los usuarios finales de estas aplicaciones suelen deberse a problemas relacionados con la red, como latencias de red altas o variables, o pérdida de paquetes.
En realidad, sólo existen tres soluciones técnicas principales para mejorar los problemas de rendimiento de los usuarios finales cuando utilizan este tipo de protocolos a través de la WAN:

  1. Estabilizar la latencia de extremo a extremo. En la mayoría de las redes de proveedores de WAN pueden producirse latencias variables y picos de latencia debido a cambios de enrutamiento, puntos de congestión provisionales, sobresuscripción de ancho de banda, equipos defectuosos, etc.Dado que Aryaka es propietaria de la red, hemos incorporado capacidad y redundancia para garantizar que siempre haya un núcleo de red estable.
    Con un enrutamiento de tráfico predefinido y múltiples rutas redundantes, Aryaka puede proporcionar a una aplicación una condición de red estable, consistente y predecible que mejora la eficiencia de los búferes de envío y recepción de la aplicación y da como resultado una experiencia interactiva del usuario final mucho más fluida.
  2. Reduzca la pérdida de paquetes. Combinada con tasas de latencia variables, la pérdida de paquetes es la mayor culpable de causar problemas de rendimiento a los usuarios de aplicaciones transaccionales.
    Los paquetes perdidos provocan retardos y retrasos en cosas como los movimientos del ratón o la escritura en pantalla, así como problemas con la calidad de la voz o de la imagen con programas colaborativos como MS-Lync.
    Aunque existen diferentes tecnologías que intentan mitigar los problemas de pérdida de paquetes en los enlaces con pérdidas, ninguna es tan eficaz para mejorar el rendimiento de las aplicaciones como disponer de una conexión limpia y con pocas pérdidas.Ser propietario del núcleo de la red permite a Aryaka eliminar las causas principales de la pérdida de paquetes, que suele deberse a la congestión de la red o a equipos defectuosos.
    Aryaka nunca sobreabastece su ancho de banda, por lo que nunca hay congestión en el núcleo.
    De hecho, Aryaka mantiene una cantidad de ancho de banda significativamente superior a la que garantiza a sus clientes.
    Esto permite un rápido aprovisionamiento de ancho de banda adicional a los clientes cuando lo necesitan, y permite a los clientes «reventar» sobre sus tarifas aprovisionadas.
    Si se produjera una pérdida de paquetes en un segmento de la WAN debido a un equipo defectuoso, el tráfico se transfiere inmediatamente y sin problemas a un enlace WAN redundante para evitar que afecte al tráfico de los clientes.
  3. Elimine la responsabilidad del control de la congestión del punto final de la aplicación y póngala en la red, que es donde debe estar. El protocolo de transporte subyacente para muchas aplicaciones es TCP, y TCP pide al usuario final que intente «averiguar» cuál es la disponibilidad de la red intermediaria para enviar datos y, a continuación, ajustar su velocidad de transmisión para adaptarse a la red.
    Aunque este enfoque funcionaba bien hace 15 ó 20 años, cuando las redes de área extensa solían tener un ancho de banda muy bajo y a menudo estaban congestionadas, hoy en día, esto en realidad provoca que la aplicación se convierta en el cuello de botella.Mientras que la mayoría de los dispositivos de optimización WAN proporcionan alguna medida de control de congestión TCP para sus soluciones punto a punto basadas en dispositivos, Aryaka sólo tiene que proporcionar esta característica particular en el borde, desde la ubicación del cliente hasta el primer punto de presencia de Aryaka.
    En todas las regiones geográficas, Aryaka controla todo el tránsito de datos a través de nuestra red central, por lo que tenemos la capacidad de utilizar algoritmos de protocolo más nuevos y eficientes, diseñados para ser más eficaces en los enlaces WAN más grandes y largos que se utilizan hoy en día.

Los proveedores tradicionales de optimización de la WAN carecen de la pieza de red Las tecnologías de optimización de la WAN no tienen control sobre las condiciones de la red intermedia y están atascadas intentando superar o enmascarar los problemas que se producen en los enlaces de tránsito de la WAN.
Por ejemplo, no pueden hacer nada por las condiciones de pérdida de paquetes o latencias variables de la red que causan problemas a las aplicaciones WAN más ligeras de hoy en día, como Citrix, MS-RDP, VoIP, etc.
Esto deja atascada a la tecnología tradicional de optimización de la WAN, que intenta «mitigar» los problemas de pérdida y latencia intermedias que se producen a través de la WAN, en lugar de ser capaz de resolverlos realmente. Hacer «más con menos Proxies de aplicación Todavía existen unos pocos protocolos de capa de aplicación, como versiones antiguas de CIFS o SMB, que se benefician de tener un proxy específico para la optimización a través de la WAN, y por supuesto Aryaka soporta estos casos de esquina hoy en día.
Pero esa lista se acorta constantemente.
Lo cierto es que la mayoría de los protocolos se comportan mejor en la WAN a medida que evolucionan.
Al reducir la dependencia de proxies específicos de la capa de aplicación, la tecnología de Aryaka puede proporcionar una mejor optimización al tiempo que mejora la fiabilidad y elimina posibles puntos de fallo.
Nuestra tecnología de deduplicación y compresión a nivel de byte admite todo el tráfico no cifrado, independientemente del formato de datos específico de la aplicación.
Y nuestra arquitectura de red privada optimizada y multisegmento proporciona un mejor rendimiento a las empresas distribuidas por todo el mundo, con un 0% de los quebraderos de cabeza asociados a las frecuentes actualizaciones, parches y correcciones.