Anwendungsproxys verstehen Ein Anwendungsproxy war ein Stück Software, das in der Mitte eines Anwendungsdatenstroms (in der Regel zwischen den Schichten 4 – 7 des OSI-Modells) als Zwischenstück eingefügt wurde, um eine Eigenschaft der Anwendung zu „reparieren“, die dazu führte, dass sie über eine WAN-Verbindung schlecht funktionierte.
Diese „Korrekturen“ gab es in der Regel in zwei Varianten:

  • Diejenigen, die dazu beigetragen haben, eine Datendeduplizierung der Anwendungsdaten zu ermöglichen; oder
  • Diejenigen, die dazu beigetragen haben, den Gesamtumfang der Kommunikation („Chattiness“) zu reduzieren, den zwei Anwendungsendpunkte über eine WAN-Verbindung benötigen.

Anwendungsproxys (die von traditionellen WAN-Optimierungsanbietern wie Riverbed verwendet werden) sind eine veraltete Technologie, die heute im Bereich der WAN-Optimierung immer seltener eingesetzt wird. 5Gründe warum Und hier sind die 5 wichtigsten Gründe für diesen Übergang: 1) Anwendungsproxys neigen dazu, viele der Anwendungen, denen sie helfen sollen, zu „stören“. Dies ist bei weitem der wichtigste Grund dafür, dass sich die WAN-Optimierungstechnologie weitgehend vom Modell des „Layer-7-Proxys“ entfernt hat. Ein Anwendungsproxy muss genau nach den Vorgaben des Anwendungsprotokolls geschrieben werden. Bei stabilen Protokollen auf niedrigerer Ebene wie SSL ist das in der Regel in Ordnung, aber bei proprietären Protokollen auf höherer Ebene wie MS-SQL oder Citrix ICA wird es zum Problem. Diese Protokolle ändern sich häufig und die Änderungen werden nicht veröffentlicht. Wie so oft in der Welt des Netzwerkadministrators wird irgendwo ein Server aufgerüstet, und der erste Hinweis darauf, dass sich ein Anwendungsprotokoll geändert hat, kommt, wenn die Beschwerden der Benutzer darüber, dass die Anwendung nicht mehr richtig funktioniert, eintrudeln. Sobald der Anwendungs-Proxy als Ursache für die Störung identifiziert wurde, muss der Proxy aktualisiert werden, damit er mit der neuen Anwendungsversion kompatibel ist. Und da diese Protokolle oft vom Proxy-Anbieter zurückentwickelt werden müssen, kann es viele Monate oder länger dauern (je nachdem, ob das Protokoll als „weit verbreitet“ gilt), bis die Lösung für diese Probleme verfügbar ist. Damit bleiben dem Netzwerkadministrator nur zwei Möglichkeiten: 1) Sagen Sie dem Server-Administrator, dass das Netzwerk die neue Anwendungsversion nicht unterstützt; oder 2) Legen Sie die Anwendungsproxys so fest, dass sie die neue Anwendung ignorieren (umgehen), wodurch die Anwendung im Wesentlichen ohne jegliche Optimierung wiedergegeben wird. 2) Ein bestimmtes Protokoll wird einfach langsam nicht mehr verwendet. Ein Beispiel für diese Art des Übergangs ist heute bei einigen proprietären verschlüsselten Protokollen wie MAPI zu beobachten.
MAPI ist das proprietäre Exchange Server-E-Mail-Protokoll von Microsoft, aber mit der Entwicklung von mehr Cloud-basierten und SaaS-Anwendungen wird SSL schnell zum bevorzugten Protokoll für SOHO- und mobile Benutzer.
Und da Microsoft auch SSL für seine Exchange E-Mail-Zustellung unterstützt, gehen viele Unternehmen weg von MAPI und hin zu nicht-proprietärem SSL.
Da sich Anwendungen weg von proprietären Protokollen entwickeln, werden diese Arten von Proxys obsolet. 3) Die WAN-Optimierungstechnologie hat sich so weit entwickelt, dass ein spezieller Proxy nicht mehr erforderlich ist. NFS ist ein gutes Beispiel.
NFS v3 hatte als Protokoll für die Dateifreigabe gewisse Einschränkungen in Bezug auf den Durchsatz und die Reaktionszeit des Endbenutzers im Zusammenhang mit den WAN-Latenzen.
Dies lag in erster Linie an der Art und Weise, wie das Protokoll konzipiert war. Es begrenzte die Datenmenge, die gleichzeitig übertragen werden konnte, ohne dass eine Anwendung darauf antwortete.
Gleichzeitig konzentrierten sich die bestehenden WAN-Optimierungstechnologien in erster Linie auf die Datendeduplizierung als Methode zur Verringerung der Gesamtdatenmenge, die über das WAN hin- und hergeschickt werden muss, und damit zur Beseitigung von Staus, um die Antwortzeiten zu verbessern.
Diese älteren WAN-Optimierungstechnologien verwendeten jedoch eine Form der Deduplizierung auf Blockebene, die beim NFS-Verkehr nicht sehr gut funktionierte, denn um einen Datenblock zuordnen zu können, muss man wissen, wo der Datenteil einer Übertragung beginnt.
Der Ort des Datenteils innerhalb einer NFS-Protokollübertragung kann variieren.
Die beste Lösung, um das NFS-WAN-Problem zu „beheben“, bestand damals darin, einen Anwendungsproxy zu schreiben, der den Kommunikationsaufwand des Protokolls künstlich verringert und außerdem herausfindet, wo sich der Datenanteil der NFS-Übertragung befindet, damit die Deduplizierung auf Blockebene effektiv sein kann.
Traditionelle Anbieter von WAN-Optimierung benötigen immer noch ein Shim für die NFS-Optimierung, weil sie noch die ältere Deduplizierungstechnologie verwenden, aber neuere Anbieter können den NFS-Verkehr auch ohne einen anwendungsspezifischen Proxy optimieren, und minimale Proxy-Optimierung bedeutet, dass weniger Dinge in Ihrem Netzwerk kaputt gehen! 4) Einige Anwendungen oder Protokolle, die vor 10 Jahren nicht gut über eine WAN-Verbindung funktionierten, haben sich weiterentwickelt oder wurden so umgestaltet, dass sie über ein WAN ohne Zwischenschaltung einer Zwischenschicht funktionieren. Schauen wir uns noch einmal NFS an.
Spulen Sie bis heute vor – die späteren Versionen von NFS v4.x haben die meisten Einschränkungen des Protokolls in Bezug auf Gesprächigkeit und Durchsatz behoben.
Die verbleibenden Einschränkungen werden durch eine allgemeine TCP-Optimierung behoben, ohne dass ein anwendungsspezifisches Shim erforderlich ist. 5) Eine „Application Proxy“-Technologiearchitektur ist aus Geschäfts- und Entwicklungssicht kein nachhaltiges Modell. Erstens ist er sehr teuer in der Wartung.
Jedes Mal, wenn neue Versionen von Anwendungen oder deren Updates von den Anwendungsanbietern veröffentlicht werden, müssen neue spezifische Optimierungsmechanismen für den Anwendungsproxy entwickelt werden.
Nehmen Sie zum Beispiel Citrix ICA – sie sind Eigentümer des Protokolls und können jederzeit Änderungen an der Protokollspezifikation vornehmen, von Version zu Version oder sogar innerhalb eines Service Pack-Updates.
All diese Anwendungsproxys im Auge zu behalten und veraltete Protokolle weiterhin zu unterstützen, ist kein sehr effizientes Geschäftsmodell.
Außerdem schränkt es die zukünftige Skalierbarkeit ein.
Die eigentliche Aufgabe eines Proxys ist es, im Namen des entfernten Servers zu handeln.
Zu diesem Zweck muss der Proxy jede Anwendungssitzung beenden und verfolgen.
Dies führt zu einem sehr hohen Overhead in Bezug auf die Hardware-Anforderungen, was dazu führt, dass immer größere Boxen benötigt werden.
Glücklicherweise werden die Probleme, die einst durch Proxys auf Anwendungsebene gelöst wurden, heute auf effizientere Weise gelöst, wodurch einige der ursprünglichen Vorteile der alten Proxy-Technologie obsolet geworden sind.
Es gibt immer noch einige Protokolle der Anwendungsebene, wie ältere Versionen von CIFS oder SMB, die von einem speziellen Proxy zur Optimierung über das WAN profitieren, aber diese Liste wird immer kürzer.
Durch die Verringerung der Abhängigkeit von spezifischen Proxys für die Anwendungsschicht kann die heutige Technologie eine bessere Optimierung bieten und gleichzeitig die Zuverlässigkeit verbessern und potenzielle Fehlerquellen beseitigen.