Comprendre les Proxy d’application Un Proxy d’application était un logiciel inséré au milieu d’un flux de données d’application (fonctionnant généralement entre les couches 4 et 7 du modèle OSI) comme une cale pour « réparer » une caractéristique de l’application qui la rendait peu performante sur une connexion WAN.
Ces « correctifs » ont tendance à se présenter sous deux formes :
- ceux qui ont contribué à la déduplication des données de l’application ; ou
- Ceux qui ont contribué à réduire la quantité totale de communication (« chattiness ») requise par deux points d’extrémité d’application sur une connexion WAN.
Les proxys d’application (utilisés par les fournisseurs traditionnels d’optimisation du réseau étendu comme Riverbed) sont une technologie ancienne et sont de moins en moins utilisés dans l’espace d’optimisation du réseau étendu aujourd’hui. 
Voici les cinq principales raisons de cette transition : 1) Les proxys d’application ont une forte propension à « casser » de nombreuses applications qu’ils sont censés aider. C’est de loin la principale raison pour laquelle la technologie d’optimisation des réseaux étendus s’est largement éloignée du modèle de « proxy de couche 7 ».
Un proxy d’application doit être écrit selon les spécifications exactes du protocole d’application.
Cela convient généralement aux protocoles stables de bas niveau tels que SSL, mais cela devient un problème pour les protocoles de plus haut niveau et plus propriétaires tels que MS-SQL ou Citrix ICA.
Ces protocoles changent fréquemment et les changements ne sont pas publiés.
Comme c’est souvent le cas dans le monde de l’administrateur de réseau, un serveur est mis à niveau quelque part et le premier indice qu’un protocole d’application a changé apparaît lorsque les plaintes des utilisateurs commencent à affluer parce que l’application ne fonctionne plus correctement.
Une fois que le proxy de l’application est identifié comme la cause de la panne, il doit être mis à jour pour être compatible avec la nouvelle version de l’application.
Et comme ces protocoles doivent souvent faire l’objet d’une rétro-ingénierie par le fournisseur du proxy, il peut s’écouler de nombreux mois, voire plus (selon qu’ils sont ou non considérés comme « largement utilisés »), avant que le « correctif » ne soit disponible.
L’administrateur de réseau n’a donc que deux possibilités :
1) Dire à l’administrateur du serveur que le réseau ne supporte pas la nouvelle version de l’application ; ou
2) Configurer les serveurs mandataires de l’application pour qu’ils ignorent (contournent) la nouvelle application, ce qui revient à rendre l’application sans aucune optimisation. 2) Un protocole particulier cesse lentement d’être utilisé. Un exemple de ce type de transition peut être observé aujourd’hui avec certains protocoles cryptés propriétaires, comme MAPI.
MAPI est le protocole de messagerie Exchange Server propriétaire de Microsoft, mais avec l’évolution des applications SaaS et basées sur le cloud, SSL devient rapidement le protocole d’entreprise de choix pour les utilisateurs SOHO et mobiles.
Étant donné que Microsoft prend également en charge le protocole SSL pour la transmission des messages électroniques Exchange, de nombreuses entreprises abandonnent le protocole MAPI au profit d’un protocole SSL non propriétaire.
Au fur et à mesure que les applications évoluent en s’éloignant des protocoles propriétaires, ces types de proxies deviennent obsolètes. 3) La technologie d’optimisation du réseau étendu a évolué au point qu’un proxy spécifique n’est plus nécessaire. NFS en est un bon exemple.
NFS v3, en tant que protocole de partage de fichiers, présentait certaines limites en termes de débit et de temps de réponse de l’utilisateur final en fonction des latences du réseau étendu.
Cela était principalement dû à la façon dont le protocole était conçu, qui limitait la quantité de données pouvant être transmises en même temps sans recevoir de réponses de l’application.
Dans le même temps, les technologies existantes d’optimisation des réseaux étendus se concentraient principalement sur la déduplication des données comme méthode pour réduire le total des données devant être envoyées dans les deux sens sur le réseau étendu, et donc pour éliminer la congestion afin d’améliorer le temps de réponse.
Mais ces anciennes technologies d’optimisation des réseaux étendus utilisaient une forme de déduplication au niveau des blocs qui ne fonctionnait pas très bien sur le trafic NFS, car pour faire correspondre un bloc de données, il faut savoir où commence la partie données d’une transmission.
L’emplacement de la partie données d’une transmission NFS peut varier.
La meilleure solution à l’époque pour « résoudre » le problème du réseau étendu NFS était d’écrire un proxy d’application, qui diminuerait artificiellement la quantité de communication requise par le protocole et déterminerait également l’emplacement de la portion de données de la transmission NFS afin que la déduplication au niveau du bloc puisse être efficace.
Les fournisseurs traditionnels de solutions d’optimisation des réseaux étendus ont toujours besoin d’une cale pour optimiser le trafic NFS, car ils utilisent toujours l’ancienne technologie de déduplication, mais les nouveaux fournisseurs peuvent optimiser le trafic NFS sans avoir besoin d’un proxy spécifique à l’application, et une optimisation minimale du proxy signifie qu’il y a moins de choses à casser dans votre réseau ! 4) Certaines applications ou certains protocoles qui ne fonctionnaient pas bien sur une connexion WAN il y a 10 ans ont évolué ou ont été repensés de manière à pouvoir fonctionner sur un WAN sans cale intermédiaire. Prenons à nouveau l’exemple de NFS.
Les versions ultérieures de NFS v4.x ont corrigé la plupart des limitations du protocole liées à la bavardage et au débit.
Les limites restantes sont résolues par l’optimisation générique de TCP, sans qu’il soit nécessaire d’utiliser une cale spécifique à l’application. 5) Une architecture technologique de type « Application Proxy » n’est pas un modèle durable du point de vue de l’entreprise et du développement. Tout d’abord, sa maintenance est très coûteuse.
De nouveaux mécanismes d’optimisation spécifiques doivent être développés pour le proxy d’application à chaque fois que de nouvelles versions d’applications ou leurs mises à jour sont publiées par les fournisseurs d’applications.
Prenez Citrix ICA par exemple – ils possèdent le protocole et sont en mesure d’apporter des modifications aux spécifications du protocole à tout moment, d’une version à l’autre, ou même dans le cadre d’une mise à jour du service pack.
Garder la trace de tous ces proxys d’application et continuer à prendre en charge des protocoles obsolètes n’est pas un modèle commercial très efficace.
Il limite également l’évolutivité future.
La nature même d’un proxy est d’agir au nom du serveur distant.
Pour ce faire, le proxy doit mettre fin à chaque session d’application et en assurer le suivi.
Cela entraîne des frais généraux très élevés en termes d’exigences matérielles, d’où la nécessité de disposer de boîtiers de plus en plus grands.
Heureusement, les problèmes autrefois résolus par les mandataires au niveau de l’application le sont aujourd’hui de manière plus efficace, ce qui rend obsolètes certains des avantages initiaux de l’ancienne technologie des mandataires.
Il existe encore quelques protocoles de couche d’application, comme les anciennes versions de CIFS ou de SMB, qui bénéficient d’un proxy spécifique pour l’optimisation sur le réseau étendu, mais cette liste ne cesse de s’allonger.
En réduisant la dépendance à l’égard des proxys spécifiques de la couche d’application, la technologie actuelle peut fournir une meilleure optimisation tout en améliorant la fiabilité et en supprimant les points de défaillance potentiels.
