Entendendo os proxies de aplicativos Um proxy de aplicativo era um software inserido no meio do fluxo de dados de um aplicativo (geralmente operando entre as camadas 4 e 7 do modelo OSI) como um calço para “corrigir” uma característica do aplicativo que fazia com que ele tivesse um desempenho ruim em uma conexão WAN.
Essas “correções” costumavam vir em duas variedades:

  • Aqueles que ajudaram a permitir a deduplicação dos dados do aplicativo; ou
  • Aqueles que ajudaram a reduzir a quantidade total de comunicação (“chattiness”) exigida por dois endpoints de aplicativos em uma conexão WAN.

Os proxies de aplicativos (usados pelos fornecedores tradicionais de otimização de WAN, como a Riverbed) são uma tecnologia antiga e estão se tornando menos usados no espaço de otimização de WAN atualmente. 5razões E aqui estão os cinco principais motivos para essa transição: 1) Os proxies de aplicativos têm uma alta propensão a “quebrar” muitos dos aplicativos que eles pretendem ajudar. Esse é, de longe, o maior motivo pelo qual a tecnologia de otimização de WAN se afastou amplamente do modelo “Layer-7 Proxy”.
Um proxy de aplicativo precisa ser escrito de acordo com a especificação exata do protocolo do aplicativo.
Em geral, isso é bom para protocolos estáveis e de nível inferior, como o SSL, mas se torna um problema para protocolos de nível superior e mais proprietários, como o MS-SQL ou o Citrix ICA.
Esses protocolos mudam com frequência e as alterações não são publicadas.
Como acontece com frequência no mundo dos administradores de rede, um servidor em algum lugar é atualizado e a primeira pista de que um protocolo de aplicativo foi alterado surge quando as reclamações dos usuários começam a chegar sobre o fato de o aplicativo não estar mais funcionando corretamente.
Quando o proxy do aplicativo é identificado como a causa da falha, ele precisa ser atualizado para ser compatível com a nova versão do aplicativo.
E como esses protocolos geralmente precisam passar por engenharia reversa pelo provedor de proxy, a “correção” para essa falha pode demorar muitos meses ou mais (dependendo de ser considerada “amplamente usada”) até estar disponível.
Isso deixa o administrador de rede com apenas duas opções:
1) Informar ao administrador do servidor que a rede não é compatível com a nova versão do aplicativo; ou
2) Configurar os proxies de aplicativos para ignorar (by-pass) o novo aplicativo, essencialmente tornando o aplicativo sem nenhuma otimização. 2) Um determinado protocolo deixa de ser usado aos poucos. Um exemplo desse tipo de transição pode ser visto atualmente com alguns protocolos criptografados proprietários, como o MAPI.
O MAPI é o protocolo de e-mail proprietário do Exchange Server da Microsoft, mas com a evolução de mais aplicativos baseados em nuvem e SaaS, o SSL está se tornando rapidamente o protocolo corporativo preferido dos usuários SOHO e móveis.
E como a Microsoft também oferece suporte ao SSL para o fornecimento de e-mail do Exchange, muitas empresas estão migrando do MAPI para o SSL não proprietário.
À medida que os aplicativos evoluem PARA ALÉM dos protocolos proprietários, esses tipos de proxies se tornam obsoletos. 3) A tecnologia de otimização de WAN evoluiu a ponto de não ser mais necessário um proxy específico. O NFS é um bom exemplo.
O NFS v3, como um protocolo de compartilhamento de arquivos, tinha certas limitações de rendimento e tempo de resposta do usuário final relacionadas às latências da WAN.
Isso se deveu principalmente à forma como o protocolo foi projetado, limitando a quantidade de dados que poderiam ser transmitidos de uma só vez sem receber respostas do aplicativo.
Ao mesmo tempo, as tecnologias de otimização de WAN existentes se concentravam principalmente na deduplicação de dados como um método para reduzir o total de dados que precisavam ser enviados para frente e para trás pela WAN e, assim, eliminar o congestionamento para melhorar o tempo de resposta.
Mas essas tecnologias mais antigas de otimização de WAN usavam uma forma de deduplicação em nível de bloco que não funcionava muito bem no tráfego NFS, pois, para corresponder a um bloco de dados, é preciso saber onde começa a parte de dados de uma transmissão.
O local da parte de dados em uma transmissão do protocolo NFS pode variar.
A melhor solução na época para “consertar” o problema de WAN do NFS era escrever um proxy de aplicativo, que diminuiria artificialmente a quantidade de comunicação exigida pelo protocolo e também descobriria onde estava a parte de dados da transmissão do NFS para que a deduplicação em nível de bloco pudesse ser eficaz.
Os fornecedores tradicionais de otimização de WAN ainda exigem um shim para a otimização do NFS, porque ainda estão usando a tecnologia de deduplicação mais antiga, mas os fornecedores mais novos podem otimizar o tráfego NFS sem a necessidade de um proxy específico do aplicativo, e a otimização mínima do proxy significa menos coisas para quebrar na sua rede! 4) Alguns aplicativos ou protocolos que não funcionavam bem em uma conexão WAN há 10 anos evoluíram ou foram reprojetados para que possam funcionar em uma WAN sem um calço intermediário. Novamente, vamos dar uma olhada no NFS.
Hoje, as versões posteriores do NFS v4.x corrigiram a maioria das limitações do protocolo relacionadas à conversação e à taxa de transferência.
Os limites restantes são resolvidos pela otimização genérica do TCP, sem a necessidade de um shim específico para o aplicativo. 5) Uma arquitetura de tecnologia “Application Proxy” não é um modelo sustentável do ponto de vista comercial e de desenvolvimento. Primeiro, sua manutenção é muito cara.
Novos mecanismos específicos de otimização devem ser desenvolvidos para o proxy de aplicativo sempre que novas versões de aplicativos ou suas atualizações forem lançadas pelos fornecedores de aplicativos.
Veja o Citrix ICA, por exemplo: eles são proprietários do protocolo e podem fazer alterações nas especificações do protocolo a qualquer momento, de versão em versão ou até mesmo em uma atualização de service pack.
Manter o controle de todos esses proxies de aplicativos e continuar a oferecer suporte a protocolos obsoletos não é um modelo de negócios muito eficiente.
Isso também limita a escalabilidade futura.
A própria natureza de um proxy é agir em nome do servidor remoto.
Para fazer isso, o proxy deve encerrar e rastrear cada sessão do aplicativo.
Isso cria uma sobrecarga muito alta em termos de requisitos de hardware, resultando na necessidade de caixas cada vez maiores.
Felizmente, os problemas antes resolvidos pelos proxies em nível de aplicativo agora são resolvidos de maneira mais eficiente, tornando obsoletos alguns dos benefícios originais da antiga tecnologia de proxy.
Ainda existem alguns protocolos de camada de aplicativo, como versões mais antigas de CIFS ou SMB, que se beneficiam de um proxy específico para otimização na WAN, mas essa lista está diminuindo constantemente.
Ao reduzir a dependência de proxies específicos da camada de aplicativos, a tecnologia atual pode proporcionar melhor otimização e, ao mesmo tempo, aumentar a confiabilidade e remover possíveis pontos de falha.