Ein WAN ist kein LAN

---

Verteilte Anwendungen werden normalerweise für den Einsatz in heterogenen Netzen entwickelt. Die miteinander kommunizierenden Systeme (Clients, Server, Legacy) stehen in voneinander logisch oder physikalisch isolierten Adressräumen, die über eine Netzwerkinfrastruktur miteinander verbunden sind. Häufig ist das Internet Bestandteil dieser Infrastruktur, die als wide area network (WAN) bezeichnet wird. Praktisch immer erfolgt die Entwicklung und der Test solcher Anwendungen in einem lokalen Netzwerk (LAN, locale area network), hier stehen die zu entwickelnden Anwendungskomponenten und die Anwendungsinfrastruktur in ein und demselben Adressraum. Aus Entwicklersicht ist der Charakter des Netzwerks unwichtig, ein im LAN entwickeltes Anwendungssystem lässt sich normalerweise problemlos auch in einem WAN deployen. Aus Betriebs- und Anwendersicht ist das nicht so, hier sind wesentliche Unterschiede zu berücksichtigen. Dieser Artikel beschreibt aus der Sicht des Architekten die Auswirkungen dieser Unterschiede auf die Anwendungsentwicklung.

Zunächst einmal sind die wesentlichen Unterschiede zwischen LAN und WAN festzuhalten:

• Verfügbarkeit: Die Infrastrukturkomponenten eines LAN sind inzwischen so zuverlässig, dass im LAN netzwerktechnisch Hochverfügbarkeit zugesichert werden kann. Im WAN ist das nicht so, denn hier läuft die Kommunikation über Infrastruktur, die zum Teil nicht in der direkten Verantwortung des Anwendungsbetriebs liegt.
• Latenz: In einem gut konfigurierten LAN liegen Latenzen normalerweise im µS Bereich und sind im Allgemeinen vernachlässigbar. Im WAN sind Latenzen im zweistelligen Millisekundenbereich völlig normal und im Nutzerablauf deutlich bemerkbar. Speziell wenn terrestrische Distanzen zu überwinden sind, können allerdings auch Latenzen im Sekundenbereich auftreten. Ist eine Satellitenverbindung Bestandteil der Kommunikationsstrecke sind solche Latenzen unvermeidbar.
• Bandbreite (throughput): Im LAN erreicht man selten die Grenzen der verfügbaren Bandbreiten, die inzwischen im Bereich von GBit/s liegen. In einer solchen Infrastruktur erscheint Bandbreite als unerschöpfliche Ressource. Hier ist der Bruch zum WAN besonders groß, denn im WAN teilen sich alle Teilnehmer die gleiche Infrastruktur. Bandbreite ist dann nicht nur begrenzt (meist im Bereich von einigen 100KBit/s), sondern schwankt auch mit der Tageszeit und kann zum Teil dramatisch klein sein. Hinzu kommt, dass Bandbreite im WAN ein betrieblicher Kostentreiber ist.
• typischer Aufbau: Im LAN, insbesondere in typischen Entwicklungsumgebungen, wird ein Client (zum Beispiel ein Webbrowser) direkt auf ein Anwendungsserver (zum Beispiel ein Webserver) zugreifen:

  Client -> Server
  

  In einem WAN sind die Verhältnisse potenziell komplizierter. Hier sind entlang der Kommunikationsstrecke diverse Infrastrukturkomponenten zu passieren. Selbst unter Vernachlässigung der Komponenten, die auf den OSI-Schichten 1-4 agieren (Switches, Router, Hubs) und die im allgemeinen aus Anwendungssicht vollkommen transparent ihren Dienst tun, bleiben noch Komponenten, die auf den OSI-Schichten 5-7 arbeiten (Firewalls, Gateways, Content-Switches, Proxies, Reverse Proxies). Hier gibt es tatsächlich Berührungspunkte zur Anwendungsentwicklung, denn diese Komponenten arbeiten auf Protokollebene:

  Client -> Proxy -> Firewall --- WAN --- Firewall -> Reverse Proxy -> Server
  

• Sicherheit: Ein LAN wird im allgemeinen in einem gesicherten, vor fremden Zugriffen gut abschirmbaren Bereich betrieben. Hier kann allein durch bauliche und organisatorische Maßnahmen ein hohes Sicherheitsniveau garantiert werden. In einem WAN läuft die Kommunikation zum Teil über fremde, nicht kontrollierbare Kanäle. Das geforderte Maß an Sicherheit muss hier durch die Anwendungsarchitektur realisiert werden.

Aus dieser Aufstellung ist ersichtlich, dass Architekten den späteren Einsatz der Anwendung im WAN berücksichtigen müssen. Das Überführen der Anwendung von der Entwicklungs- in die Produktivumgebung bedeutet eine Umzug vom LAN in ein WAN. Dieser konzeptionelle Sprung muss mittels geeigneter Integrationstests abgefedert und in möglichst kleine Schritte unterteilt werden (staging). In einem Projekt für verteilte Anwendungen müssen entsprechende Testumgebungen bereitgestellt werden, die Phase der Integrationstest ist entsprechend zu berücksichtigen.

Kommunikation mit TCP/UDP

---

Für viele Anwendungsprotokolle wird Netzwerkkommunikation auf der Basis des paketorientierten IP über die darüber liegenden Protokolle TCP (verbindungsorientiert) und UDP (datenorientiert) abgewickelt. Eine Netzwerkverbindung kostet einen belegten Socket, einen wartenden Thread und alle daran gebundenen Hilfsressourcen (Buffer, Semaphoren etc.). Der Aufbau einer TCP/UDP Connection kostet zusätzlich mindestens einen Roundtrip für das Handshake. Wird eine Verbindung SSL gesichert sind zudem noch ein weiterer Roundtrip und CPU-Ressourcen auf beiden Seiten der Verbindung nötig (slow-start Problem). Das Halten einer TCP/UDP Verbindung kostet Ressourcen, der Aufbau einer TCP/UDP Verbindung kostet Zeit und zusätzliche Ressourcen. Das gilt für alle in der Verbindung beteiligten Netzwerk-Infrastrukturkomponenten! Wie häufig eine Verbindung aufgebaut und wie lange sie gehalten wird ist offensichtlich eine wesentliche Designentscheidung. Connection-Management, also das planvolle Öffnen, Nutzen und wieder Freigeben von TCP/UDP Connections ist hier wesentliches Architekturziel. Es folgen Grundregeln:

• Connection-Pooling ist technisches Connection-Management und muss zur Anwendung kommen, wann immer das möglich ist. Die http keep-alive Option nicht beeinflussen, es sei denn man weiß sehr genau was man tut.
• SSL Verbindungen werden nur da wo nötig aufgebaut, Icons, CSS und Begrüßungsseiten müssen im Allgemeinen nicht über SSL Verbindungen zum Client gesendet werden.
• Langlaufende Anwendungsfälle sind unbedingt asynchron zu implementieren. Das unnötig lange Blockieren eines Netzwerksockets wegen lang laufender (synchron designeter) Anwendungsfälle ist nach meiner Erfahrung Hauptursache mangelhafter Skalierung des Gesamtsystems. Hier bringen Lasttests schnell und zuverlässig architektonische Mängel zum Vorschein.
• Der Architekt muss Protokolldetails der eingesetzten Technologien und Frameworks kennen, nur auf dieser Grundlage wird er korrekte Designentscheidungen fällen. Generell "chatty" Protokolle vermeiden (Protokolle mit vielen Roundtrips). Besonders File-Schnittstellen sind beim Einsatz im WAN kritisch zu würdigen: die zugrundeliegenden Protokolle sind oftmals "chatty".
• UDP ist designed für die ungeordnete Übertragung vieler kleiner Datenpakete und belegt grundsätzlich weniger Ressourcen für eine offene Verbindung. Protokolle die UDP nutzen, können deshalb im WAN im Vergleich zu Protokollen, die mit TCP das gleiche leisten, vorteilhaft sein. Hier gilt allerdings folgende Einschränkung: UDP ist zustandslos und deshalb von Firewalls schwer zu überwachen. Einige Firewall-Konfigurationen lassen deshalb keinen UDP Verkehr zu, andere erlauben ausgehende UDP Pakete und gestatten dann eingehende UDP Pakete der Zieladresse innerhalb einer kurzen Zeitspanne.

Latenz und Verbindungsabbrüche

---

Verbindungen im WAN sind prinzipiell fehleranfällig und die Latenz einer Verbindung kann prinzipiell nicht vorhergesagt werden. Anwendungen sind für dieses Szenario auszulegen und zu testen.

• Ausnahmen in der normalen Nutzerführung durch Timeouts oder Verbindungs-Abbrüche sind als ein möglicher, normaler Anwendungsfluss zu berücksichtigen. Für Entwicklungstests zieht man einfach ab und an mal den Netzwerkstecker oder besorgt sich einen TCP-Monitor, der langsame und abbrechende Verbindungen simuliert. Die Anwendung muss sich von solchen Abbrüchen erholen. Clients müssen im Rahmen der fachlichen Gegebenheiten ein sinnvolles "offline-Verhalten" zeigen.
• Anwendungsfälle möglichst asynchron designen und fachliche Transaktionen immer robust bezüglich Abbrüchen planen (Retry, Rollback der Transaktion etc. berücksichtigen), ein einfaches two-phase Commit reicht im allgemeinen nicht aus.

Bandbreiten

---

Bandbreiten sind in WAN begrenzt, können Kosten verursachen und werden zeitlich variieren.

• Die Wahl des Protokolls ist hier ein wichtiger Faktor, wie schon erwähnt ist für XML das Verhältnis von Nutzdaten zu Strukturdaten nicht optimal. EXI, Hessian und Burlap können hier die bessere Wahl sein, insbesondere wenn Schnittstellen designed werden, die nicht Bestandteil eines EAI Szenarios sind.
• Kompression der Nutzdaten kann bei schmalen Bandbreiten helfen, muss aber immer mit einer erhöhten CPU Last erkauft werden.
• Senden von Nutzdaten-Delta (statt der gesamten Nutzdaten) beseitigt Redundanzen und kann die gleiche Information sehr sparsam zum Ziel bringen.
• Clientseitiges Cachen, insbesondere das build in http-Caching sind möglichst ausgiebig zu nutzen.

Remote procedure calls

---

Aus Netzwerk-Perspektive sind RPC (remote procedure calls) immernoch eine teure Angelegenheit. RPC-Frameworks verschleiern den relativ hohen Aufwand, der bei Methodenaufrufen über Systemgrenzen hinweg entsteht, gerade dafür sind sie ja gemacht. In einem WAN kann dann der unreflektierte Einsatz von RPC zu substantiellen Problemen führen.

• Die einzelnen RPC eher selten und tendenziell mit großen Datenmengen planen. Das dafür etablierte Pattern wird als Transfer Object Pattern bezeichnet. Das Transfer Object Pattern hat Auswirkungen auf den Workflow der Anwendung und wird am besten schon bei der Anwendungsfallanalyse berücksichtigt.
• Umfangreiche fachliche Transaktionen mittels des Session Fascade Pattern als ein RPC designen.
• Langlaufende RPC vermeiden. Hier unbedingt auf asynchrone Dienste umsteigen.
• Wenn sinnvoll, Daten-Unterschiede und nicht die Nutzdaten selber per RPC verschicken.
• Bei der Wahl des Protokolls das Verhältnis von Protokoll- zu Nutzdaten berücksichtigen. XML basierte Protokolle schneiden hier eher schlecht ab, deren gewaltiger Overhead ist jedoch gerechtfertigt, wenn RPC zwischen heterogenen Anwendungssystemen erfolgen soll.
• Der Architekt muss die Details des RPC Protokolls kennen.

Rolle der Proxies und Reverse Proxies

---

Proxies arbeiten auf den OSI-Schichten 5-7. Sie optimieren Kommunikation, indem sie Kommunikationsprotokolle und zum Teil auch die Nutzdaten analysieren und "intelligent" reagieren. Daneben können sie für Querschnittsaufgaben eingesetzt werden, dazu zählen beispielsweise Caching von Daten, Contentfilter- und Loggingfunktionen. Proxy-taugliche Clients können in verteilten Umgebungen erheblich zur Entlastung der Netzwerkressourcen beitragen und sind gegebenenfalls für den Einsatz mit einem Proxy auszulegen. Ein Client ist proxytauglich, wenn er das Protokoll des verwendeten Proxy beherrscht. Populäre Standards sind HTTP-Proxy- und SOCKS-Protokolle.

Reverse Proxies arbeiten ebenfalls auf den OSI-Schichten 5-7. Sie nehmen Anfragen von Clients entgegen, analysieren Protokoll- und Nutzdaten und leiten die Anfrage an passende Server weiter. Aus Clientsicht ist ein Reverse Proxy damit ein einheitlicher Zugriffspunkt auf mehrere Server, die zumeist über URL-Bestandteile adressiert werden. Daneben kann ein Reverse Proxy für Querschnittsaufgaben eingesetzt werden, dazu zählen beispielsweise Loadbalancing, Caching von Daten, Terminierung der Verschlüsselung, Authentifizierung und Datentransformation. Eine Anwendung ist Reverse Proxy tauglich, wenn sie die URL-Bestandteile zur Adressierung der einzelnen Dienste protokollgerecht benutzt. Speziell für statisches und dynamisches HTML bedeutet dies konkret, dass die URLs des eigenen Dienstes grundsätzlich relativ (statt absolut) zu formulieren sind, eine Regel, die ohnehin als best practice anzusehen ist. Clientseitig dynamisch erstellte URLs (zum Beispiel mit der Hilfe AJAX-Frameworks) sind entsprechend kritisch und im Einzelfall zu würdigen.

Weiterführendes

---

Core J2EE Patterns
Das OSI-Modell