Analyse und Visualisierung des Einflusses ausgewählter Applikationen auf die Netzbelastung mit Hilfe des Netzmanagementsystems "HP OpenView Node Manager"

I Inhaltsverzeichnis

II Bibliographische Angaben

III Aufgabenstellung

IV Abkürzungsverzeichnis

V Abbildungsverzeichnis

VI Tabellenverzeichnis

Vorwort

1 Grundlagen
1.1 Netzwerke
1.1.1 Protokolle und Standards für Netzwerke
1.2 Netzwerkmanagement
1.2.1 Protokolle und Standards für das Netzwerkmanagement
1.2.1.1 OSI-Management-Framework
1.2.1.2 SNMP
1.2.1.2.1 RMON
1.3 Internet und World Wide Web
1.3.1 Internet
1.3.2 World Wide Web
1.3.2.1 HTTP
1.3.2.2 Cache und Proxy-Cache
1.3.2.3 Java und JavaScript
1.3.2.4 Browser
1.3.2.4.1 NCSA Mosaic (v2.6)
1.3.2.4.2 Netscape Navigator (v3.0)
1.3.2.4.3 Sun HotJava Browser (v1.0 pre-Beta1)

2 Programme zur Meßdatenerfassung
2.1 HP OpenView Network Node Manager
2.2 HP NetMetrix/UX
2.3 Frontier NETscout Manager

3 Erfassung und Auswertung der Meßdaten
3.1 Lasterzeugung
3.2 Testfeld 1: URZ (HP OpenView, Frontier NETscout)
3.3 Testfeld 2: IRB (HP OpenView, HP NetMetrix/UX)
3.3.1 Auswertung der Meßergebnisse
3.3.1.1 Laden eines HTML-Dokumentes als lokale Datei
3.3.1.2 Laden eines HTML-Dokumentes von einem lokalen Web-Server
3.3.1.3 Laden eines HTML-Dokumentes von einem entfernten Web-Server
3.3.1.4 Unterschiede zwischen den WWW-Browsern
3.3.2 Vergleich HP OpenView mit SunNet Manager

4 Probleme

5 Ausblick

VII Literaturverzeichnis

VIII Selbständigkeitserklärung

IX Thesen

Anhang A : Ausgewählte Portnummern

Anhang B : HP OpenView Network Node Manager 4.01

Anhang C : HP NetMetrix/UX 4.60

Anhang D : Frontier NETscout Manager 3.3.0

Anhang E : Meßergebnisse (komplett)

II Bibliographische Angaben

Weber, Titus:

Diplomarbeit:

„Analyse und Visualisierung des Einflusses ausgewählter Applikationen auf die Netzbelastung mit Hilfe des Netzmanagementsystems ‘HP OpenView Node Manager’“

Dezember 1996, 195 Seiten, 134 Abbildungen, 10 Tabellen,

Otto-von-Guericke-Universität Magdeburg, Fakultät für Informatik,

Institut für Theoretische Informatik, Rechnerverbund und Betriebssysteme.

Inhalt

In den letzten Jahren ist das Interesse am Internet und am World Wide Web auf der ganzen Welt stark angestiegen. Damit verbunden ist auch ein rapides Anwachsen der Anzahl der Rechner in den Netzwerken. Um diese Netzwerke in Betrieb zu halten, werden immer größere Anforderungen an das Netzwerkmanagement gestellt. In dieser Diplomarbeit wird eines der am meisten eingesetzten Netzwerkmanagementsysteme, der HP OpenView Network Node Manager, in Hinsicht auf seine Funktionalität im Rahmen des Konfigurationsmanagements, des Fehlermanagements und des Leistungsmanagements getestet. Untersucht wird mit Hilfe dieser Anwendung der Einfluß des World Wide Web auf die Belastung des Netzwerkes der Universität Magdeburg. Zusätzlich werden die Netzwerkanalysetools HP NetMetrix und Frontier NETscout Manager betrachtet.

Contents

The interest on the Internet and the World Wide Web, as well, has been growing enormously in the past years. In conjunction with that, the amount of hosts grew in the networks. In order to keep these networks running, more requirements concerning network management need to be satisfied. This thesis is done in order to test the functionality of one of the most used network management systems, the HP OpenView Network Node Manager, within the setting of configuration management, fault management and performance management. The subject matter in this thesis will focus on the influence of the World Wide Web to the load of the network of the University of Magdeburg. The network analysis tools, HP NetMetrix and Frontier NETscout Manager are considered in addition.

III Aufgabenstellung

„Analyse und Visualisierung des Einflusses ausgewählter Applikationen auf die Netzbelastung mit Hilfe des Netzmanagementsystems

‘HP OpenView Node Manager’“

- Welchen Einfluß hat speziell das World Wide Web auf die Belastung des Netzes?
- Die Durchführung der Messungen sollte sowohl im Universitätsnetz als auch im Institutsnetz (IRB) der Fakultät für Informatik (FIN) erfolgen.
- Eine Zuhilfenahme geeigneter Tools ist möglich, wenn der HP OpenView Network Node Manager für die Lösung der Aufgabe als nicht ausreichend erscheint.
- Alle für die Messungen verwendeten Programme sind ausführlich zu dokumentieren.
- Es sollte, wenn möglich, ein Vergleich verschiedener Browser für das World Wide Web vorgenommen werden.
- Weiterhin soll eine vergleichende Bewertung der zwei Netzwerkmanagementsysteme HP OpenView Network Node Manager und SunNet Manager erfolgen.
- Die Auswertung der erhaltenen Meßergebnisse ist mit Zusatzprogrammen vorzunehmen, wenn die verwendete Anwendung für das Netzwerkmanagement keine Möglichkeit der grafischen Ausgabe der Meßdaten beinhaltet. Wenn notwendig, sind eigene Programme bzw. Schnittstellen für eine grafische Auswertung zu entwickeln.

IV Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

V Abbildungsverzeichnis

Abbildung 1: ISO/OSI-Referenzmodell

Abbildung 2: DoD-Schichtenmodell

Abbildung 3: TCP/IP-Protokollstack

Abbildung 4: IP-Datagramm

Abbildung 5: TCP-Segment

Abbildung 6: UDP-Datagramm

Abbildung 7: Manager - Agent

Abbildung 8: SNMP-Managementmodell

Abbildung 9: SNMP Communities

Abbildung 10: Struktur der MIB-II

Abbildung 11: RMON-MIB

Abbildung 12: RMON und OSI

Abbildung 13: Anzahl der Internet Hosts (1989 - 1996)

Abbildung 14: Telnet und HTTP

Abbildung 15: Fehlermeldung in NCSA Mosaic v2.4

Abbildung 16: Architektur von HP OpenView

Abbildung 17: NetMetrix Extended RMON Module

Abbildung 18: NetMetrix Power Agent

Abbildung 19: Architektur von Frontier NETscout

Abbildung 20: Lasterzeugung mit dem Tool „spray“

Abbildung 21: Testumgebung FDDI-Ring der Universität Magdeburg mit Position der NETscout Probe

Abbildung 22: Conversation Report (12. - 15. Juli) - Domain WWW

Abbildung 23: Segment Traffic Statistics Report (12. - 15. Juli) - Domain WWW

Abbildung 24: Segment Details Report (12. - 15. Juli) - Domain WWW (Auslastung)

Abbildung 25: Host Report (05. August) - Domain ALL

Abbildung 26: Segment Details Report (05. August) - Domain ALL (Paketgrößen)

Abbildung 27: Segment Details Report (05. August) - Domain ALL (Auslastung)

Abbildung 28: Conversation Report (05. August) - Domain DNS

Abbildung 29: Segment Details Report (05. August) - Domain MAIL (Paketgrößen)

Abbildung 30: Conversation Report (05. August) - Domain WWW

Abbildung 31: Segment Details Report (05. August) - Domain WWW (Paketgrößen)

Abbildung 32: Netzplan IRB (FIN) mit Position der HP LANprobe III Plus, Überblick

Abbildung 33: HP OpenView und die ATM-Anbindung der Universität

Abbildung 34: Testumgebung 1 - IRB (FIN), vereinfachte Darstellung

Abbildung 35: Testumgebung 2 - IRB (FIN), vereinfachte Darstellung

Abbildung 36: Verzeichnisstruktur auf „freyja“ für ERM

Abbildung 37: Die Datei "agent.db"

Abbildung 38: Traceroute zum Web-Server des Sunpools (eva)

Abbildung 39: Traceroute zum Web-Server der Universität Hohenheim

Abbildung 40: Aufbau eines TCP/IP-Paketes im Protocol Analyzer

Abbildung 41: Nutzdaten eines TCP/IP-Paketes im Protocol Analyzer

Abbildung 42: Laden eines Java-Applets im Protocol Analyzer

Abbildung 43: Aufbau eines SNMP-Paketes im Protocol Analyzer

Abbildung 44: HTTP-Aktivität beim Laden einer lokalen HTML-Datei

Abbildung 45: Paketverkehr beim Laden einer lokalen HTML-Datei

Abbildung 46: Paketanzahl beim Laden einer lokalen HTML-Datei

Abbildung 47: Laden einer Web-Seite mit Sun HotJava (lokaler Web-Server)

Abbildung 48: Laden einer Web-Seite mit NCSA Mosaic (lokaler Web-Server)

Abbildung 49: Laden einer Web-Seite mit Netscape Navigator (lokaler Web-Server)

Abbildung 50: Auslastung und Paketgrößen beim Laden einer Web-Seite mit Netscape Navigator (lokaler Web-Server)

Abbildung 51: Laden einer Web-Seite mit Sun HotJava (entfernter Web-Server)

Abbildung 52: Laden einer Web-Seite mit NCSA Mosaic (entfernter Web-Server)

Abbildung 53: Laden einer Web-Seite mit Netscape Navigator (entfernter Web-Server)

Abbildung 54: HTTP-Verbindungen beim Laden einer Web-Seite mit Zugriffszähler (entfernter Web-Server)

Abbildung 55: Pakettypen und Paketanzahl beim Laden einer Web-Seite mit Netscape Navigator (entfernter Web-Server)

Abbildung 56: Fehlermeldung Internetwork Reporter

Anhang:

Abbildung A 1: HP OpenView Network Node Manager - Systeminformation

Abbildung A 2: Root Submap

Abbildung A 3: Toolbar

Abbildung A 4: Available Maps

Abbildung A 5: Submaps in Map

Abbildung A 6: Internet Submap

Abbildung A 7: Internet Submap mit Panner (Lupe)

Abbildung A 8: Network Submap - FDDI-Ring (Backbone) Universität Magdeburg

Abbildung A 9: Network Submap - IRB-25

Abbildung A 10: Segment Submap - IRB-25

Abbildung A 11: Node Submap - Knoten freyja (IRB-25)

Abbildung A 12: System Information für Knoten freyja

Abbildung A 13: Quick Navigator

Abbildung A 14: Add Object

Abbildung A 15: Add Connection

Abbildung A 16: Locate Object by Selection Name

Abbildung A 17: Operational Status Colors

Abbildung A 18: Administrative Status Colors

Abbildung A 19: Event Categories

Abbildung A 20: Configuration Events Browser

Abbildung A 21: Event Configuration

Abbildung A 22: Load/Unload MIBs

Abbildung A 23: SNMP Data Collection & Thresholds

Abbildung A 24: MIB Application Builder

Abbildung A 25: MIB Application Builder/Modify MIB Application

Abbildung A 26: Menü

Abbildung A 27: MIB Browser

Abbildung A 28: Network Polling Configuration

Abbildung A 29: Interface Traffic für Knoten freyja

Abbildung A 30: Routing Table für Knoten freyja

Abbildung A 31: ARP-Cache für Knoten freyja

Abbildung A 32: Network Connectivity - Poll Node für Knoten freyja

Abbildung A 33: SNMP Operations für Knoten freyja während „snmpwalk“

Abbildung A 34: SNMP Errors für Knoten freyja bei falschem Community Name

Abbildung A 35: HP NetMetrix Agent Toolbox

Abbildung A 36: Agent Database Editor

Abbildung A 37: ERM Configurator

Abbildung A 38: Load Monitor

Abbildung A 39: Protocol à Conversation für Knoten freyja

Abbildung A 40: Conversations zwischen Knoten freyja und File-Server herkules

Abbildung A 41: Packet Size für Knoten freyja

Abbildung A 42: Monthly Historical Ethernet Statistic für HP LANprobe III Plus

Abbildung A 43: Traffic between Nodes (A: lanprobe, B: anubis)

Abbildung A 44: Protocol Distribution für LANprobe

Abbildung A 45: RMON Status für HP LANprobe III Plus

Abbildung A 46: Protocol Analyzer - Protocol Decode

Abbildung A 47: Protocol Selection

Abbildung A 48: Protocol Analyzer - Traffic Trend

Abbildung A 49: Internetwork Monitor

Abbildung A 50: NFS Monitor

Abbildung A 51: Internetwork Reporter - New Report

Abbildung A 52: Internetwork Reporter - Report Status

Abbildung A 53: Internetwork Reporter - Health Profile

Abbildung A 54: Internetwork Reporter - Network at a Glance (daily)

Abbildung A 55: Internetwork Reporter - Protocol Distribution over Time

Abbildung A 56: Frontier NETscout Probe - Systeminformation

Abbildung A 57: NETscout Manager

Abbildung A 58: Filter Editor

Abbildung A 59: Filter Editor (View Filter)

Abbildung A 60: Domain Editor

Abbildung A 61: Domain Manager

Abbildung A 62: Segment Zoom

Abbildung A 63: Traffic Monitor

Abbildung A 64: Protocol Monitor

Abbildung A 65: Data Capture

Abbildung A 66: Protocol Decode

Abbildung A 67: 7-Layer Protocol Decode

Abbildung A 68: Resource Manager

Abbildung A 69: Watchdog

Abbildung A 70: FDDI Ring Station List

Abbildung A 71: Report Generator

Abbildung A 72: Expert Visualizer (Traffic Monitor - Utilization)

Abbildung A 73: Traffic Monitor (Topology)

Abbildung A 74: Traffic Monitor (Topology - Ring Order)

Abbildung A 75: Traffic Monitor (Hosts - Util out)

Abbildung A 76: Internet Monitor (Host - Util out)

Abbildung A 77: Application Monitor (Segment - Util out)

Abbildung A 78: Application Monitor (Hosts - Util out)

VI Tabellenverzeichnis

Tabelle 1: Übertragungsraten in Netzwerken

Tabelle 2: Maximum Transfer Units

Tabelle 3: RMON, RMON2 und Enterprise RMON

Tabelle 4: NSFnet Auslastung (1993 - 1995)

Tabelle 5: Anforderungen an RAM und Swap Space für den NNM

Tabelle 6: Zeit für das Discovery in Abhängigkeit von der Anzahl der Knoten

Tabelle 7: NETscout Reports

Tabelle 8: Auswahl von Rechneradressen der Universität Magdeburg (WWW)

Tabelle 9: Aufteilung der Paketgrößen in der RMON-MIB

Tabelle 10: Auslastung des Universitätsnetzes (05. August) - Übersicht

Vorwort

Netzwerkmanagement - dieser Begriff ist in den letzten Jahren immer mehr zu einem Schlagwort in der Informationsverarbeitung und sogar zu einem neuen Berufsbild für Informatiker geworden. Mit dem rapiden Anstieg der Anzahl von Rechnern in Netzwerken sowohl auf Unternehmensebene (Intranet) wie auch im weltumspannenden „Netz der Netze“, dem Internet, ist auch die Notwendigkeit einer Überwachung dieser Netze, z.B. im Hinblick auf Fehler, Leistung und Sicherheit, immer mehr in den Vordergrund gerückt. Gerade das Internet verzeichnete in den vergangenen Monaten einen so raschen Zuwachs, daß die Ausmaße dieses Netzwerkes schon kaum mehr zu überschauen sind.

Besonders eine Anwendung sorgte in den letzten Jahren für ein gewaltiges Anwachsen des Datenverkehrs im Internet - das World Wide Web (WWW) mit seinem zugrunde liegenden Protokoll, dem Hyper Text Transfer Protocol (HTTP). Der große Zuspruch, den diese grafische Oberfläche für das Internet weltweit findet, und die Auswirkungen, im vorliegenden Falle auf die Belastung des Netzwerkes der Otto-von-Guericke-Universität Magdeburg bzw. auf das Netz der Fakultät für Informatik (FIN) waren die entscheidenden Punkte für die Wahl dieses Diplomthemas. Eingegangen werden soll bei den Betrachtungen und Messungen nach Möglichkeit auch auf neue Entwicklungen im World Wide Web, wie die Programmiersprache Java von Sun Microsystems, und auf einen Vergleich verschiedener Web-Browser.

Die Analyse und Visualisierung soll dabei mit dem Netzwerkmanagementsystem „OpenView Network Node Manager“ von Hewlett Packard und, wenn erforderlich, mit entsprechenden Zusatztools erfolgen.

Begründet mit der Aktualität sämtlicher Aktivitäten in und um das Internet bzw. World Wide Web wurde dieses Diplomthema in ähnlicher Formulierung noch einmal vergeben. Dies vor allem auch deshalb, da eine vergleichende Betrachtung der am Institut für Theoretische Informatik, Rechnerverbund und Betriebssysteme (IRB) der Fakultät für Informatik (FIN) vorhandenen Netzwerkmanagementsysteme vorgenommen werden sollte. Deshalb sollte die vorliegende Diplomarbeit in Zusammenhang mit der Arbeit des Herrn Jörg Prange gesehen werden, der dieses Thema mit Hilfe des SunNet Managers in der Version 2.2.2 bearbeitet hat. Auf Grundlage dessen wurden einige Messungen im IRB auch gemeinsam vorgenommen, um die Leistungsfähigkeit dieser Anwendungen beurteilen zu können.

In der vorliegenden Arbeit werde ich zu Beginn etwas näher auf die Grundlagen von Netzwerken, des Netzwerkmanagements und des Internet bzw. World Wide Web eingehen. Dies beinhaltet u.a. eine Beschreibung der zugehörigen Protokolle sowie einiger Managementstandards. Daran anschließend wird ausführlich auf die Lösung der Aufgabenstellung und die Auswertung der erhaltenen Meßergebnisse eingegangen. Dabei erfolgt auch eine kurze Beschreibung der von mir verwendeten Programme für das Netzwerkmanagement. Abschließend soll dann noch ein Ausblick auf weiterführende Aufgaben zum selben Themenbereich gegeben werden.

Im Anhang befindet sich neben der Auflistung der für die Messungen verwendeten Portnummern (Anhang A) auch eine ausführlichere Beschreibung der für diese Diplomarbeit verwendeten Softwareprodukte. Dies sind das Netzwerkmanagementsystem HP OpenView Network Node Manager (Anhang B) sowie die Netzwerkmonitore HP NetMetrix/UX (Anhang C) und der Frontier NETscout Manager (Anhang D). Damit die Inhalte der Screenshots dieser Programme gut zu erkennen sind, wurden sie statt im dazugehörigen Text auf Extraseiten angeordnet. Am Ende der Arbeit sind sämtliche Meßergebnisse noch einmal zusammengefaßt dargestellt, da diese nicht alle ausführlich in den nachfolgenden Kapiteln angesprochen werden können (Anhang E).

An dieser Stelle möchte ich Herrn Dr. rer. nat. Achim Winkler, Herrn Dr. rer. nat. Fritz Zbrog und Herrn Jens Elkner von der Fakultät für Informatik, Institut für Theoretische Informatik, Rechnerverbund und Betriebssysteme für Ihre Unterstützung, sowohl bei der Bereitstellung von Literatur, Hard- und Software als auch bei der Lösung von Netzwerkproblemen, danken. Ebenso gilt mein Dank Herrn Mors, Herrn Hedermann und Herrn Engelmann vom Universitätsrechenzentrum (URZ) der Universität Magdeburg, die mir die Arbeit mit dem Netzwerkmonitor Frontier NETscout Manager ermöglichten. Weiterhin danke ich Herrn Reiner Nebelin von der Universität Hohenheim, der mir das Ablegen der Web-Seiten für meine Messungen auf dem dortigen Web-Server in seinem Verzeichnis ermöglichte.

1 Grundlagen

1.1 Netzwerke

Der Zusammenschluß mehrerer Rechner zu Rechnerverbünden oder Netzwerken ergab sich aus der Notwendigkeit der Weitergabe und Weiterverarbeitung der mittels eines Rechners erstellten Daten. Vor allem in größeren Unternehmen sind die eingesetzten Computer oft sehr weit voneinander entfernt, teilweise sogar über Länder- und Kontinentgrenzen hinweg. Um eine gemeinsame Nutzung der vorhandenen Ressourcen, wie z.B. Programme, Daten und auch der Rechenleistung, zu gewährleisten, ist eine Vernetzung der Rechner unbedingt notwendig. Daher soll an dieser Stelle kurz auf die geschichtliche Entwicklung von Netzwerken und speziell auf die Entstehung des Internet eingegangen werden.

Das Ur-Netzwerk stellt dabei das ARPANET dar, welches 1969 im Auftrag des amerikanischen Verteidigungsministeriums (Department of Defense - DoD) entwickelt wurde. Gleichzeitig damit entstand in den Bell Laboratories von AT&T auch die Ur-Version des heutigen Betriebssystems UNIX. Der Öffentlichkeit wurde das ARPANET allerdings erst im Jahre 1972 vorgestellt. Das anfangs eingesetzte Network Control Protocol (NCP) ist dann 1983 dem noch heute im Einsatz befindlichen Transmission Control Protocol/Internet Protocol (TCP/IP) gewichen. IP ist dabei das Vermittlungsprotokoll und TCP das Transportprotokoll (siehe Kapitel 1.1.1: Protokolle und Standards für Netzwerke).

Unabhängig von diesem ARPANET entwickelte sich unter Leitung der National Science Foundation (NSF) ein Netz mit primär wissenschaftlichem Hintergrund, das Computer Science Network (CSnet), welches Schulen, Universitäten und Verwaltungen preiswert zur Verfügung stehen sollte. Der Grund für diese Entwicklung lag darin begründet, daß der Eigentümer des ARPANET das DoD war und somit nicht alle Universitäten und Informatikabteilungen in den USA Zugang zu diesem Netz hatten. Ein weiteres, parallel entstandenes Netzwerk war das National Science Foundation Network (NSFnet), welches hauptsächlich als Verbindung zwischen Forschungs- und Wissenschaftseinrichtungen konzipiert war. Aus diesen Netzwerken entstand dann 1982 mittels eines TCP/IP-Gateways das heutige Internet. Nach Abspaltung eines Teiles des ARPANET zum militärisch orientierten MILNET (1983) wurde das ARPANET im Jahre 1990 aufgelöst. ([LIEN96], S.14ff)

1.1.1 Protokolle und Standards für Netzwerke

An dieser Stelle soll lediglich ein kurzer Einblick in einige Netzwerkstandards, Zugriffsverfahren und Topologien erfolgen. Für weitergehende Informationen hierzu verweise ich auf [BORO96], [LIEN96] sowie auf [TANE92]. Etwas ausführlicher wird dann auf die Schichtenmodelle, einzelne Protokolle und den Aufbau ausgesuchter Pakete eingegangen, da dies im Hinblick auf die nachfolgenden Kapitel dieser Arbeit von Wichtigkeit ist. Bei den Protokollen beziehe ich mich auf die Request for Comments (RFC), in denen Spezifikationen und Probleme des Internet festgehalten werden. Die meisten dieser RFCs sind gleichzeitig Standards des Internet.

Das Institute of Electrical and Electronics Engineers (IEEE) hat für lokale Netzwerke die Norm IEEE 802 hervorgebracht, in der einige der nachfolgend beschriebenen Verfahren enthalten sind. Dazu gehören die Netzwerkstandards Ethernet und Token Ring.

Das Ethernet ist ein Standard für Lokale Netzwerke (Local Area Network - LAN), der auf einer Bus-Topologie basiert. Bei dieser Topologie sind alle Endgeräte an einem einzigen Kabel angeschlossen. Dieses Kabel (Bus) ist an seinen beiden Enden mit Abschlußelementen, sogenannten Terminatoren, ausgestattet. Über Repeater, die der Signalverstärkung dienen, können mehrere Bussegmente miteinander verbunden werden. Als Zugriffsverfahren wird hier Carrier Sense Multiple Access with Collision Detection (CSMA/CD, IEEE 802.3) eingesetzt. Jede sendewillige Station hört vor dem Senden den Kanal ab und sendet nur, wenn der Kanal frei ist (Carrier Sense). Dabei können mehrere Stationen konkurrierend auf das gleiche Übertragungsmedium zugreifen (Multiple Access). Collision Detection bedeutet, daß jede Station für eine frühzeitige Kollisionserkennung auch während des Sendens den Kanal abhört.

Im Token Ring (IEEE 802.5) sind die Stationen in einer Ringstruktur angeordnet und der Zugriff auf das Medium wird über ein auf dem Ring kreisendes Token geregelt. Das Token ist eine eindeutige Bitfolge die angibt, ob der Übertragungskanal frei oder belegt ist. Dieser Zustand wird dann durch ein freies bzw. belegtes Token angezeigt. Erhält eine sendewillige Station ein freies Token, wandelt sie dieses in ein belegtes Token um und beginnt direkt nach dem Token mit dem Versenden seiner Daten. Diese werden solange auf dem Ring weitergereicht, bis sie die Empfangsstation erreicht haben. Dort werden sie kopiert, aber nicht vom Ring genommen. Die Daten werden weitergeleitet bis sie wieder an der Sendestation angekommen sind. Diese nimmt die Daten vom Ring und setzt das Token auf frei. Hierfür gibt es jedoch noch verschiedene andere Verfahren. ([BORO96], S.44ff)

Bereits zu den Hochgeschwindigkeitsnetzen zählen das Fiber Distributed Data Interface Network (FDDI) und Netzwerke auf Basis des Asynchronous Transfer Mode (ATM).

Bei FDDI wird ein gegenläufiger Doppelring, bestehend aus Primär- und Sekundärring verwendet. Als Übertragungsmedium wird ein Glasfaserkabel und als Zugriffsverfahren ebenfalls ein Token benutzt. FDDI wird hauptsächlich für Backbone-Konzepte eingesetzt, also dort, wo mehrere Subnetze bei kurzen Übertragungszeiten gekoppelt werden müssen. Ein Beispiel hierfür ist das FDDI-Backbone des Netzwerkes der Otto-von-Guericke-Universität Magdeburg.

ATM nutzt für den Datentransport sogenannte ATM-Zellen, die stets die gleiche Länge von 53 Bytes besitzen. Aus diesen Zellen werden Bit-Datenströme zusammengesetzt, die sich als virtuelle Kanäle auch zu virtuellen Pfaden zusammenfassen lassen. In einem ATM-Switch, der aus mehreren Ein- und Ausgängen besteht, wird dann eine Verbindung eines Eingangs mit seinem diagonal angeordneten Ausgang hergestellt. Mehrere ATM-Switches bilden dann ein großes ATM-Netzwerk. Außer den soeben genannten gibt es noch weitere Verfahren, wie z.B. Fast Ethernet, Synchronous Optical Network (SONET - mit Übertragungsraten im Bereich von Gigabit/s !), das Integrated Services Digital Network (ISDN) oder Distributed Queue Dual Bus (DQDB), auf die ich aber hier nicht eingehen möchte.

Deutliche Unterschiede bestehen bei den maximalen Übertragungsraten, die mit den beschriebenen Verfahren erreicht werden können (siehe Tabelle 1). ([HEIB96], S.27)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Übertragungsraten in Netzwerken

Das Versenden von Paketen in Netzwerken kann als Multicast, Broadcast oder Unicast erfolgen. Bei einem Multicast werden die Daten an eine Gruppe von Stationen gesendet, bei einem Broadcast an alle Stationen im Netzwerk. Die am häufigsten verwendete Methode ist der Unicast, d.h. das Paket wird nur an eine einzige Zielstation weitergeleitet.

Da eine Kommunikation zwischen zwei Partnern nur dann möglich ist, wenn beide die gleichen Regeln für diese Kommunikation beherrschen, wurde Ende der 70er Jahre von der International Standardization Organization (ISO) ein Gremium mit der Erstellung eines Modells für offene Systeme beauftragt. Das Ergebnis war das „Reference Model for Open Systems Interconnection“ (ISO/OSI-Referenzmodell), auch als 7-Schichtenmodell (siehe Abbildung 1) bezeichnet. ([BORO96], S.23)

Abbildung in dieser Leseprobe nicht enthalten Abbildung 1: ISO/OSI-Referenzmodell

Für jede dieser sieben Schichten werden Protokoll-Layer mit spezifischen Aufgaben und Funktionen für eine systemübergreifende Kommunikation definiert:

Bitübertragungsschicht:

Ungesicherte Übertragung eines Bitstroms über das physikalische Medium.

Datensicherungsschicht:

Sicherung des Bitstroms und Rahmenbildung.

Netzwerkschicht:

Verbindungsherstellung zwischen Endteilnehmern mittels derer Adressen .

Transportschicht:

Zuverlässige Datenübertragung zwischen den Endteilnehmern.

Sitzungsschicht:

Bereitstellung von Synchronisationsmitteln zwischen Anwendungsprozessen.

Darstellungsschicht:

Herstellung einer einheitlichen Sichtweise auf die Daten.

Anwendungsschicht:

Zugang zu OSI-Diensten der Anwendungen bereitstellen.

Die Kommunikation zwischen zwei Rechnern A und B beginnt in der Anwendungsschicht des Rechners A bis hinunter zur physikalischen Schicht des Rechners A. Erst hier erfolgt die eigentliche Übertragung der Daten auf dem physikalischen Medium. Am Ziel, dem Rechner B, werden die Daten in die unterste Schicht, die physikalische Schicht, übernommen. Bei der Weitergabe bis in die Anwendungsschicht entfernt jede Schicht ihre Steuerinformationen wieder. Am Ende dieser Kommunikation entsprechen die Daten im Rechner B den Ursprungsdaten im Rechner A.

Während der Kommunikation erhält also eine Schicht n die Informationen von der vorhergehenden Schicht n-1, fügt eigene Steuerinformationen hinzu und gibt diese dann wieder an die nachfolgende Schicht n+1 weiter. Verläuft die Kommunikation in der umgekehrten Richtung, so erhält Schicht n die Informationen von der Schicht n+1 und gibt diese an die Schicht n-1 weiter. Der Aufruf eines Dienstes einer untergeordneten bzw. übergeordneten Schicht erfolgt über einen definierten Zugangspunkt, den Service Access Point (SAP). Der von den Schichten zu erbringende Dienst wird durch die Ausführung eines Protokolls realisiert. Im Rahmen dieses Protokolls werden die Informationen in Protokolldateneinheiten (Protocol Data Units - PDU) ausgetauscht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: DoD-Schichtenmodell

Eine andere Architektur ist die des DoD, die lediglich aus vier Schichten besteht (siehe Abbildung 2). ([GLAS94], S.85)

Vergleicht man dieses Modell mit dem ISO/OSI-Referenzmodell, so stellt man fest, daß die Schichten 1 und 2 zu der Schicht Netzzugang zusammengefaßt wurden. Dies geschah, da diese zwei Schichten nicht unabhängig voneinander sind, denn eine Auswahl eines bestimmten Übertragungsmediums wirkt sich auch auf Schicht 2 aus. Die Vermittlungsschicht (oder Internetschicht) ermöglicht eine gezielte Zustellung von Datagrammen. Die Kommunikation mit dem Benutzer erfolgt über Protokolle auf der Anwendungsschicht, z.B. FTP, Telnet oder SMTP. Auf dieser Philosophie basiert TCP/IP. Das Internet Protocol (IP) ist dabei das Vermittlungsprotokoll und somit in der Vermittlungsschicht angeordnet. Das Transmission Control Protocol (TCP) dient als Transportprotokoll und befindet sich in der Ende-zu-Ende-Schicht. Es liegt somit auch in den Schichten 3 (Netzwerkschicht) und 4 (Transportschicht) des ISO/OSI-Referenzmodells.

Unter TCP/IP werden jedoch nicht nur die zwei Protokolle TCP und IP, sondern eine ganze Gruppe von Protokollen zusammengefaßt. Dazu zählen u.a. das User Datagram Protocol (UDP), das Simple Mail Transfer Protocol (SMTP), Telnet und das File Transfer Protocol (FTP). Auch das Simple Network Management Protocol (SNMP, siehe Kapitel 1.2.1.2: SNMP) gehört zu der Protokollfamilie TCP/IP. Die Einordnung der Protokolle in den TCP/IP-Protokollstack und in das ISO/OSI-Referenzmodell zeigt Abbildung 3. ([LIEN96], S.68)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: TCP/IP-Protokollstack

Bevor das TCP/IP näher beschrieben wird, ist eine Unterscheidung der Protokolle in verbindungslose Protokolle und in verbindungsorientierte Protokolle wichtig.

Verbindungsorientiert bedeutet hierbei, daß ein kontrollierter Ablauf der Kommunikation erfolgt. Die Kommunikation beginnt mit dem Verbindungsaufbau und endet mit dem Verbindungsabbau. Dazwischen findet die eigentliche Kommunikation oder Datenübertragung statt. Für jede übermittelte Information muß eine Bestätigung vom jeweiligen Kommunikationspartner erfolgen. Das TCP ist ein verbindungsorientiertes Protokoll.

Bei verbindungslosen Protokollen ist dagegen keine Sicherheit vorhanden, es existiert lediglich ein einfacher Datagramm-Verkehr zwischen den Kommunikationspartnern. Datagramm-Dienst (engl.: datagram service) bedeutet, daß das Netzwerk versucht, jedes Paket als isolierte Einheit zu seinem Ziel zu transportieren. Da keine Sicherheitsmechanismen vorhanden sind, ist diese Art der Kommunikation schneller, aber Datagramme können hierbei verloren gehen oder in der falschen Reihenfolge am Ziel ankommen. Es erfolgt kein expliziter Verbindungsaufbau bzw. Verbindungsabbau. Daher wird diese Variante vor allem für die Übertragung von Statusinformationen im Netzwerk verwendet, z.B. für das Netzwerkmanagement. Das bereits erwähnte Managementprotokoll SNMP nutzt für den Austausch von Managementinformationen zwischen den zu überwachenden Netzstationen und dem Managementsystem das verbindungslose Protokoll UDP. Doch dazu weiter unten.

Auch das IP [RFC791] ist ein verbindungsloses Protokoll. Es ermöglicht die gezielte Zustellung von Daten in der Form von Datagrammen. Das IP-Datagramm hat eine Gesamtlänge von bis zu 65.535 Bytes und enthält mehrere Felder, die u.a. folgende Einträge enthalten: die IP-Versionsnummer, die Länge des Headers (Internet Header Length - IHL), Qualität des angeforderten Dienstes (Type of Service), die Gesamtlänge des Datagramms, Flags für die Steuerung der Fragmentierung (don’t fragment, more fragments), das Time-To-Live Feld (TTL), das übergeordnete Protokoll der Transportschicht (dem die IP-Schicht das Datagramm übergeben soll) und die Quell- sowie Zieladresse (siehe Abbildung 4). Auf die Größen in Bytes der einzelnen Felder gehe ich hier nicht ein. ([LIEN96], S.68)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: IP-Datagramm

Der Aufbau dieser Datagramme wird in einem späteren Kapitel noch einmal gezeigt, wenn das Dekodieren von Protokollen besprochen wird und man sich somit den Inhalt jedes einzelnen dieser Felder genauer betrachten kann (siehe Kapitel 3: Erfassung und Auswertung der Meßdaten). Ein Fragmentieren der IP-Datagramme ist zuweilen unumgänglich, da bei Einsatz des IP in verschiedenen Netzwerk-Topologien auf deren maximale Übertragungseinheiten (Maximum Transfer Unit - MTU) Rücksicht genommen werden muß (siehe Tabelle 2). ([LIEN96], S.74)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Maximum Transfer Units

Nach der Übertragung werden diese Fragment-Datagramme mittels Auswertung der diversen im Datagramm enthaltenen Flags wieder zu dem Original-Datagramm zusammengesetzt. Dieser Vorgang nennt sich Reassemblieren.

IP-Adressen sind weltweit eindeutig und bestehen derzeit aus 32 Bit. Eine Unterteilung erfolgt in Gruppen mit der Bezeichnung Class A bis Class E. ([JANS93], S.45)

Vergeben werden diese Adressen von dem Network Information Center (NIC) in den USA, wobei kontinentale (European NIC - ENIC) und nationale (Deutsches NIC - DeNIC) Zuständigkeitsbereiche davon existieren. Die Adressen werden üblicherweise in der Dezimalschreibweise mit Punktnotation als Abtrennung angegeben und nicht in der reinen Binärdarstellung. So lauten die IP-Adressen der Rechner des Netzwerkes am Instituts für Theoretische Informatik, Rechnerverbund und Betriebssysteme (IRB) der Fakultät für Informatik (FIN) an der Otto-von-Guericke-Universität Magdeburg wie folgt:

141.44.25.xxx.

Die Untergliederung erfolgt in eine Class-Netz-ID, eine Netz-ID, eine Subnetz-ID und eine Host-ID. Der Wert „xxx“ steht dabei für einen beliebigen Hostrechner (Host-ID); so wäre 141.44.25.199 die IP-Adresse der HP LANprobe III Plus im IRB-Netz. Die IP-Adresse ist eine Class-B-Adresse. Da der IP-Adreßbereich, bedingt durch das rasche Wachstum des Internet, inzwischen bei weitem nicht mehr ausreicht, ist eine Erweiterung des Adreßbereiches auf 128-Bit-Adressen angedacht und soll in der nächsten IP-Version (IP Next Generation - IPng) verwirklicht werden (siehe Kapitel 5: Ausblick).

Im Gegensatz zu IP ist TCP [RFC793] ein verbindungsorientiertes Protokoll. Dies bedeutet, daß hier ein kontrollierter Aufbau und Abbau der Verbindungen erfolgt. Die Daten werden nicht blockweise, sondern als Datenstrom (Oktetts) übertragen. Dabei nutzt TCP für die Übertragung das Internet Protocol (IP). Da dieses durch den Datagramm-Verkehr keinerlei Sicherheiten für die versendeten Datenpakete geben kann, muß dies nun durch TCP gewährleistet werden. So sorgt TCP für die Erkennung von verlorengegangenen Paketen und bringt vertauschte Pakete wieder in die richtige Reihenfolge. Den Aufbau eines TCP-Segmentes zeigt Abbildung 5. ([LIEN96], S.89)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: TCP-Segment

Eine sichere Datenübertragung wird durch Sequenznummern (Numerierung der Datenoktetts eines Datenstromes), Prüfsummen und zeitüberwachte Quittungen gewährleistet. Ist die Zeit einer Quittung abgelaufen, wird das Segment (Block) erneut gesendet. Die Adressierung erfolgt bei TCP mittels 16 Bit langer Portnummern für den Sender und den Empfänger. Diese Portnummern (siehe Anhang A) repräsentieren einen eindeutigen Zugangspunkt zum Datenaustausch mit den übergeordneten Anwendunsprotokollen (z.B. FTP oder Telnet).

Auch das User Datagram Protocol (UDP, [RFC768]) benutzt diese Ports zur Kommunikation.

Da UDP ein verbindungsloses Protokoll ist, können mit diesem Protokoll ohne großen Aufwand Daten zwischen Kommunikationspartnern ausgetauscht werden. Es gewährleistet ebenso wie das Internet Protocol keine korrekte Datenübertragung und es erfolgt keine Quittierung der übertragenen Daten. Ein erneutes Senden von verlorengegangenen Datagrammen findet nicht statt. Da alle diese Funktionalitäten fehlen, ist die Übertragung von Daten mit dem User Datagram Protocol von einer hohen Geschwindigkeit geprägt und wird daher oft zur Übermittlung von Bootload-Funktionen und Statusmeldungen benutzt. Weiterhin findet es im Netzwerkmanagement und im World Wide Web Anwendung. Im World Wide Web erfolgt über UDP das Versenden von Informationen, die u.a. für den Cache bzw. Proxy-Cache (siehe Kapitel 1.3.2.2: Cache und Proxy-Cache) von Wichtigkeit sind, wie z.B. der Änderungsstatus bestimmter Seiten („If-Modified-Since“ (Header Last Modified)). Den Aufbau eines UDP-Datagramms zeigt Abbildung 6. ([LIEN96], S.96)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: UDP-Datagramm

Bei den Portnummern ist zu beachten, daß TCP und UDP unterschiedliche Adreßräume benutzen. Die Portnummer TCP-80 ist also nicht identisch mit der Portnummer UDP-80. Die Portnummern sind außerdem in ihrem Gültigkeitsbereich auf einen Rechner (Host) beschränkt. Wird ein UDP-Datagramm an einen bestimmten Port gesendet, so muß an diesem Port ein Prozeß auf eingehende Datagramme warten. Ist dies nicht der Fall, so kommt das nächste Protokoll zum Einsatz, das Internet Control Message Protocol (ICMP, [RFC792]). Dieses schickt an den Absender des UDP-Datagramms eine Fehlermeldung. In diesem Falle wäre es „port unreachable“. Das ICMP ist ein Hilfsprotokoll (verbindungslos, nutzt IP), welches zur Übermittlung von Fehler- und Informationsmeldungen zwischen Netzwerkkomponenten (Rechner, Router) benutzt wird. Um Endlosschleifen zu vermeiden, wird auf Fehler im eigenen Protokoll nicht reagiert.

Damit möchte ich die kurze Beschreibung ausgewählter Protokolle abschließen. Auf das Protokoll für das World Wide Web, das Hyper Text Transfer Protocol (HTTP) gehe ich in einem gesonderten Kapitel ein (siehe Kapitel 1.3.2.1: HTTP). Für weitere Informationen zu den aufgeführten und anderen Protokollen verweise ich auf die angegebenen Literaturhinweise.

1.2 Netzwerkmanagement

Diesem Kapitel möchte ich zwei Zitate voranstellen, welche die Problemstellung ziemlich genau beschreiben. Das erste ist von Marshall T. Rose ([ROSE91], S. 71):

„Die Auswirkung von Netzmanagement auf die zu verwaltenden Netzelemente muß gering bleiben und sich am kleinsten gemeinsamen Nenner orientieren.“

(Marshall T. Rose)

Das zweite ist von Jeffrey D. Case („Dr. SNMP“), einem der Väter des im nächsten Kapitel zur Sprache kommenden Simple Network Management Protocols (SNMP), der das Ganze etwas direkter anspricht ([JANS93], S.106):

„I want my dog hunting raccoon, not skinning them!“

(Jeffrey D. Case)

Diese Aussagen sollten bei den nachfolgenden Betrachtungen im Vordergrund stehen. Mit dem Netzwerkmanagement sollen also nicht die eigentlichen Aufgaben der einzelnen Komponenten des Netzwerkes vernachlässigt werden. Die Vorgänge des Netzwerkmanagements müssen transparent im Hintergrund ablaufen, ohne einen zu großen Einfluß auf die Belastung des Netzes und seiner Komponenten auszuüben.

Was versteht man nun aber unter Netzwerkmanagement?

Die Aufgabe des Netzwerkmanagements ist das Überwachen der Elemente des Netzwerkes, um frühzeitig Fehler oder Engpässe zu erkennen und geeignete Maßnahmen zu deren Beseitigung einleiten zu können. Aber auch die Sammlung von Daten zu den Konfigurationen der Netzbestandteile und eine Zugriffsregelung auf das Netz werden dazu gerechnet. Man könnte auch kurz sagen, das Ziel des Netzwerkmanagements ist das Gewähren einer konstant hohen Dienstgüte (Quality of Service). Daher gliedert sich Netzwerkmanagement in die folgenden fünf Teilbereiche:

- Konfigurationsmanagement,
- Fehlermanagement,
- Leistungsmanagement,
- Sicherheitsmanagement,
- Abrechnungsmanagement.

Dabei befaßt sich das Konfigurationsmanagement (Configuration Management) mit der Überwachung der vorhandenen Netzelemente und ihrer Konfigurationen, wobei auch die Vergabe von Adressen und die Routing-Kontrolle dazu gehören. Das Fehlermanagement (Fault Management) hat drei Hauptaufgaben: das Erkennen, das Diagnostizieren und das Beheben von abnormen Zuständen im Netzwerk. Für die Erkennung von Fehlerzuständen werden in bestimmten Zeitintervallen Tests durchgeführt, das sogenannte Polling. Aber auch das Versenden von Fehlermeldungen vom überwachten Objekt zu der Managementstation mit Hilfe von Traps ist möglich. Die quantitative Analyse und Bewertung von Informationen über die Leistung des Netzes ist Aufgabe des Leistungsmanagements (Performance Management). Die Daten können kurzzeitig oder über einen längeren Zeitraum (historische Statistiken) ermittelt werden (Polling, Trapping). Die vorliegende Diplomarbeit befaßt sich in einigen Teilen mit diesem Leistungsmanagement. Grundlage des Sicherheitsmanagements (Security Management) ist die Sicherheit von Diensten und Protokollmechanismen in den Schichten des ISO/OSI-Referenzmodells. Es geht hier also um Zugriffsberechtigungen und Verfahren zur Abwendung eines nicht autorisierten Datenempfangs. Aber auch Strategien gegen eine Verfälschung von Daten während ihrer Übertragung fallen in diesen Bereich. Die benutzerbezogene Bestimmung der Nutzung von Ressourcen des Netzwerkes und eventuell personenabhängig zu setzende Limits sind die Aufgaben des Abrechnungsmanagements (Accounting Management).

Eine weitere Unterscheidung des Netzwerkmanagements wird in

- In-Band Management und
- Out-of-Band Management

vorgenommen. Diese Einteilung basiert auf der Art und Weise der Abwicklung des Managements. Wird dieses über die Netzwerk-Topologie (d.h. das gleiche Netz) abgewickelt, bezeichnet man dies als In-Band Management. Geschieht es dagegen über spezielle Leitungen, z.B. Remote Verbindungen, so ist dies ein Out-of-Band Management. Bei dem letzteren Verfahren kann z.B. parallel ein Managementnetz eingerichtet werden, über das ausschließlich Informationen für das Netzwerkmanagement übertragen werden (welches allerdings auch wieder gemanagt werden müßte ...). Das Out-of-Band Management ist für den Ernstfall ein unentbehrliches Hilfsmittel. Fällt der Primärpfad, das Ethernet, aus, so kann ein Einloggen in das Netzwerk über den SLIP-Port erfolgen (Serial Line Internet Protocol - SLIP). Bei den noch zur Sprache kommenden Netzwerkmanagementsystemen ist ein Einsatz sowohl In-Band als auch Out-of-Band möglich.

Während einer Managementoperation werden verschiedene Daten zwischen der Managementanwendung (Manager System) und einem Agenten ausgetauscht (siehe Abbildung 7).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Manager - Agent

Diese sogenannten Managementinformationen, auch Protokolldateneinheiten (Protocol Data Units - PDU) genannt, besitzen eine vorgeschriebene Struktur und ihr Austausch erfolgt nach festgelegten Regeln. Diese Vereinbarungen werden in einem Managementprotokoll getroffen. Von der Managementanwendung aus kann der Netzwerkverwalter (Administrator) sich mit Hilfe der Agenten einen Überblick über den Zustand einzelner Geräte im Netzwerk verschaffen. Der Agent ist meist Teil einer Netzkomponente, stellt die Informationen für den Manager bereit und hat Zugriff auf die Netzressourcen. Dies sind hierbei z.B. die Endsysteme, Router und Bridges. Da nun aber nicht alle Eigenschaften dieser Ressourcen für das Netzwerkmanagement von Wichtigkeit sind, ist eine Teilsicht auf diese Netzressourcen notwendig, die als Managed Object bezeichnet wird. Ein Managed Object besitzt folgende Eigenschaften:

- Attribute,
- Operationen,
- Meldungen.

Die Attribute sind die Parameter des Objektes, wie z.B. sein eindeutiger Name. Operationen sind die auf diesem Objekt zugelassenen Kommandos. Dazu gehören u.a. Operationen zum Verändern (SET) und zum Auslesen (GET) von Attributwerten. Die Operationen laufen in zwei Phasen ab, der Anforderung (Request) und der Antwort (Response). Meldungen werden beim Eintreten von Ereignissen generiert und über den Agenten an das Manager System gesendet.

Man unterscheidet zwischen Alarmmeldungen und Änderungsmeldungen. Beim Eintreffen einer Alarmmeldung hat das Manager System bzw. der Netzwerkadministrator sofort zu reagieren. Sämtliche Managed Objects und deren Attribute sind in der Management Information Base (MIB, [RFC1156]) zusammengefaßt. Die MIB wird im Kapitel 1.2.1.2 (SNMP) ausführlicher beschrieben. Die Darstellung der Objektklassen in der MIB erfolgt in einer standardisierten Sprache, der Abstract Syntax Notation One (ASN.1), die ich hier nicht näher betrachten möchte.

1.2.1 Protokolle und Standards für das Netzwerkmanagement

Basierend auf diesen grundlegenden Modellen wurden mehrere Managementstandards entwickelt. Dazu zählen das OSI-Management-Framework und das Simple Network Management Protocol (SNMP). Auf das von der Open Software Foundation (OSF) erarbeitete Distributed Management Environment (DME) wird hier nicht eingegangen.

1.2.1.1 OSI-Management-Framework

Die ISO befaßte sich seit 1985 mit der Entwicklung eines Network-Management-Konzeptes. 1989 wurde dann das OSI Management Framework (ISO 7498-4) der Öffentlichkeit vorgestellt, das sich in mehrere Normungsdokumente gliedert.

Diese beschreiben im wesentlichen ein Managementmodell, ein funktionales Modell sowie Dienste und Protokolle. Das Managementmodell (Manager, Agent, Managed Objects) wurde im vorhergehenden Kapitel bereits erläutert. Das funktionale Modell bezieht sich auf die Aufgaben des Netzwerkmanagements. Bleiben die Dienste und Protokolle zur Kommunikation zwischen Manager System und Agent. Die Dienstfunktionen zur Übermittlung der Managementinformationen sind in den Common Management Information Services (CMIS - ISO 9595) festgehalten. Der Transport der Informationen erfolgt mit Hilfe des Common Management Information Protocol (CMIP - ISO 9596). Das CMIS ist eine Anwendung der Schicht 7 des ISO/OSI-Referenzmodells und nutzt zur Kommunikation die Remote Operations Service Elements (ROSE - ISO 9072), die ein einfaches Verfahren für Anfragen und Antworten definieren. Die Management Information Base (MIB) baut bei diesem Standard auf der Structure of Management Information (SMI - [RFC1155]) auf, welche die Struktur der auszutauschenden Managementinformationen festlegt.

Als Übergangslösung bis zur vollständigen Implementierung der OSI-Management-Norm sollte das CMIS/CMIP over TCP/IP (CMOT) dienen. Dies konnte sich aber nie durchsetzen. Anders sieht es dagegen mit dem CMIP over Logical Link Control (CMOL) aus. Dieses wird von den Firmen IBM und 3Com unterstützt und soll im Vergleich zu SNMP kleinere und somit platzsparende Agenten besitzen und eine geringere Netzbelastung verursachen.

([JANS93], S.92ff), ([HEIT95], S.19)

1.2.1.2 SNMP

Es gibt kaum ein Netzwerkmanagementsystem, welches nicht dieses Protokoll unterstützt. Das Simple Network Management Protokoll (SNMP) ist sozusagen der Standard, wenn es um Netzwerkmanagement geht.

Die Entwicklung von SNMP begann 1987, als eine Gruppe von Netzwerkspezialisten beschloß, das Management der Komponenten des Internet effektiver zu gestalten. Drei Projekte wurden somit gleich parallel gestartet. Die erste Entwicklung führte zu dem Simple Gateway Monitoring Protocol (SGMP - [RFC1028]), ein einfaches Managementprotokoll für das Management von Verbindungsknoten zwischen den Gateways des Internet. Das zweite Projekt war das High Level Entity Management System (HEMS), das jedoch nie in der Entwicklung abgeschlossen wurde. Der dritte und letzte Ansatz versuchte die OSI-Management-Konzepte auf TCP/IP-basierte Netzwerke zu übertragen. Statt dem OSI-Transport sollte hier TCP als Transportdienst eingesetzt werden. Daher bekam es auch den Namen CMOT (CMIS/CMIP Over TCP/IP). Nach heftigen Diskussionen um Vor- und Nachteile wurde beschlossen, SGMP und CMOT parallel weiter zu entwickeln und somit ein gemeinsames Framework zu schaffen. Die ersten Spezifikationen dazu erschienen 1988 und ein Jahr später wurde SNMP bereits zum faktischen Standard für die Verwaltung TCP/IP-basierter Netze. Das geplante gemeinsame Framework wurde nie erreicht, die Entwicklung von CMOT endete praktisch im Oktober 1990. Im Mai 1990 kam es zur Normung der SMI ([RFC1155]), der MIB-I ([RFC1156]) und des SNMP ([RFC1157]). Im März 1991 erschien dann bereits eine Weiterentwicklung der MIB-I, die MIB-II ([RFC1213]). Eine Erweiterung von SNMP im LAN-Bereich erfolgte mit der Normung der Remote Network Monitoring MIB ([RFC1271]), die im nächsten Kapitel beschrieben werden soll. Dies zur Geschichte dieses Standards.

Das SNMP-Managementmodell besteht ähnlich wie das OSI-Management-Framework aus Manager Systemen (Network Management Station - NMS) und den zu verwaltenden Elementen, die hier als Managed Nodes bezeichnet werden. Dies sind die Netzkomponenten und sie enthalten die Agenten, welche die Managementfunktionen ausführen. Über das Managementprotokoll werden die Managementinformationen zwischen den Network Management Stations und den Managed Nodes bezüglich der Managed Objects ausgetauscht. Dabei erfolgt eine Einteilung in sogenannte SNMP Entities, bestehend aus der SNMP Application Entity (Funktionen für die Kommunikation zwischen Managementsystem und Agent) und der SNMP Protocol Entity (dienen der Abwicklung des SNMP-Protokolls). Ein großer Vorteil von SNMP ist, daß auch alte Geräte, die keinen SNMP-Agenten besitzen, über sogenannte Proxy- Agenten in das Management mit einbezogen werden können. Diese Stellvertreter dienen, vereinfacht gesagt, als Übersetzer zwischen den Protokollen. Das bei SNMP angewandte Managementmodell zeigt die Abbildung 8. ([JANS93], S.108)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: SNMP-Managementmodell

Die Managementoperationen zwischen dem NMS und einem Agenten beschränken sich im wesentlichen (mit Ausnahme der Traps) auf die zwei Operationen SET und GET, also das Schreiben und Lesen von Variablenwerten. Der Vorteil dessen liegt auf der Hand: Für einen Agenten brauchen nur diese zwei Funktionen implementiert werden. Traps sind spontane Ereignismeldungen (Event Notifications), die von einem Agenten an die Managementstation gesandt werden und dieser das Eintreten eines bestimmten Zustandes mitteilen. Eine andere Variante für das Melden des Zustandes eines Netzwerkelementes ist das Polling. Dabei erfolgt ein zyklisches Abfragen der Variablen des Netzwerkelementes. Das Zeitintervall kann dabei in den Managementsystemen meist beliebig eingestellt werden. Das SNMP-Polling, wie es auch genannt wird, verursacht natürlich, je nach Intervallwert, einen mehr oder weniger starken Netzverkehr. Demgegenüber steht, daß sich mit einer niedrigeren Pollingrate auch bessere Analysen erreichen lassen, da mehr Meßwerte erzeugt werden. Bei der Einstellung dieses Intervalls sollte man sich also stets überlegen, was und wie genau etwas gemessen werden soll. Auf diese Einstellungen wird bei der Beschreibung der Managementsysteme und Netzwerkmonitore noch einmal eingegangen. Die Beziehung zwischen der Managementstation und den Agenten wird als Administrative Relationships bezeichnet. Die Application Entities (NMS und Agenten) werden zu Gruppen, den SNMP Communities (SNMP-Gemeinschaften) zusammengefaßt. Jede dieser Gruppen erhält einen eindeutigen Namen, den Community Name. Eine Kommunikation zwischen Application Entities ist nur dann möglich, wenn diese der gleichen Community angehören (siehe Abbildung 9). ([JANS93], S.114)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: SNMP Communities

Als Standard Community Names sind bei den meisten Managementsystemen „public“ (nur lesen, engl.: read-only) und „private“ vorgegeben. SNMP greift beim Transport von Protokollnachrichten lediglich auf den Datagramm-Dienst UDP zurück. Dieses User Datagram Protocol wurde weiter oben schon ausführlich untersucht. Der Community Name muß in jeder Nachricht enthalten sein, da bei einem Datagramm-Dienst kein Bezug zwischen aufeinanderfolgenden Nachrichten besteht. Eine Nachricht mit einem korrekten Community Name wird authentische SNMP-Nachricht (engl.: authentic SNMP message) genannt. Eine große Sicherheitslücke ist die unverschlüsselte Übertragung der Community Names innerhalb des SNMP-Datenpaketes. Mit einem Tool zum Dekodieren von Protokollen (engl.: protocol decoding), wie Frontier NETscout Manager oder HP NetMetrix ist es kein Problem, den Community Name einer SNMP-Abfrage herauszubekommen.

Durch die Verwendung des verbindungslosen Protokolls UDP wird die Erzeugung von Netzverkehr durch die Übertragung von Managementinformationen erheblich vermindert. Nachteilig ist, daß es zum Verlust von SET-Kommandos oder Traps kommen kann. Bei diesen Betrachtungen sollte man aber die einleitenden Zitate zum Netzwerkmanagement beachten.

Die Managed Objects sind bei SNMP ebenso wie beim OSI-Management-Framework in einer Management Information Base (MIB) enthalten. Neben der Standard-MIB, die für die Verwendung im Internet verbindlich ist, gibt es noch zusätzliche private MIBs. Alle Objekte gehören zu einem bestimmten Zweig innerhalb der hierarchischen Struktur der MIB. Auf Grund dieser Struktur wird auch von einem MIB-Baum (engl.: MIB-Tree) gesprochen. Die erste Version der Standard-MIB ([RFC1156]) enthielt lediglich 14 Objekte. In der MIB-II ([RFC1213]) sind es bereits 172 Objekte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Struktur der MIB-II

In der Abbildung 10 sind nur die für das Netzwerkmanagement relevanten Zweige der MIB-II aufgezeigt. Firmenspezifische Einträge bzw. MIB-Erweiterungen, z.B. von HP oder Cisco, befinden sich unterhalb des Zweiges private. Eine MIB enthält also die formalen Beschreibungen von Objektklassen. Diese Objektbeschreibungen sind in der Structure and Identification of Management Information (SMI) festgelegt und erfolgen in der Abstract Syntax Notation One (ASN.1). Jedes Objekt besitzt dabei fünf Felder (Objekt, Syntax, Definition, Access, Status). Zusätzlich existiert ein genauer Zugriffspfad, um auf das Objekt mittels der MIB zugreifen zu können. Die Angabe des Pfades innerhalb der MIB erfolgt immer von der Wurzel (engl.: root) aus zum Objekt, indem man in dem MIB-Tree „absteigt“. So wird der Object Identifier (Beschreibung des Objektes) für den Zugriff auf Informationen über das Protokoll UDP wie folgt angegeben (vgl. Abbildung 10):

.1.3.6.1.2.1.7

oder auch:

.iso.org.dod.internet.mgmt.mib-2.udp.

Das SNMP-Protokoll basiert auf folgenden fünf Befehlen: Get-Request, GetNext-Request, Get-Response, Set-Request und Trap. Mittels der Get-Befehle kann eine gezielte Abfrage von MIB-Variablen durch das Managementsystem erfolgen. Auf der Kommandozeile ist dies ebenfalls mit den Befehlen „snmpwalk“, „snmpnext“, „snmpget“ und „snmpset“ möglich. Die Set-Befehle dienen dem Setzen von Variablenwerten und mit Trap werden Ausnahmesituationen (coldStart, warmStart, ...) gemeldet. Um eine unabhängige Verarbeitung von Kommandos (Get, Set) und den Traps zu ermöglichen, werden unterschiedliche Portnummern verwendet. Während die Traps den Port 162 verwenden, erfolgt das Versenden der restlichen SNMP-Befehle über den Port mit der Nummer 161.

Dies soll zur Erläuterung von SNMP im Hinblick auf die nachfolgenden Kapitel ausreichen.

Inzwischen gibt es eine verbesserte Version 2 von SNMP (SNMPv2). In dieser sind u.a. die Sicherheitslücken, wie das unverschlüsselte Übertragen des Community Names, beseitigt. Doch gibt es durch die Beschränkungen beim Export von Verschlüsselungsalgorithmen aus den USA Schwierigkeiten bei der Einführung dieser Version in Europa. Außerdem ist hierbei eine Kommunikation zwischen Network Management Stations möglich. Dies geschieht über ein Manager-zu-Manager-Protokoll. ([JANS93], S.192ff)

Eine Erweiterung der klassischen SNMP-Funktionalität erfolgte durch die Remote Network Monitoring MIB (RMON).

1.2.1.2.1 RMON

Die Remote Network Monitoring MIB (RMON- [RFC1271]) wurde im November 1991 veröffentlicht und erweitert das Management von LANs. RMON erlaubt das Monitoring eines Netzwerkes mit Hilfe eines Zusatzgerätes, der Probe. Eine Probe (LAN-Monitor, LAN-Analysator, engl.: probe) ist ein Gerät, welches in das Netzsegment eingehangen wird und ständig Statistikdaten über das Netzwerk und die darüber übertragenen Datenpakete sammelt. Diese Daten können zur Auswertung ständig oder nach Ablauf von Schwellwerten (engl.: thresholds) an das Managementsystem übertragen werden. Dem RMON-Standard ist eine eigene MIB zugeordnet, die RMON-MIB mit dem Eintrag {mib-2 16}. Die RMON-MIB (siehe Abbildung 11) gliedert sich in den Ethernet-Standard ([RFC1271]) und spezielle Erweiterungen für Token Ring ([RFC1513]). ([IJNM96]. S.18)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: RMON-MIB

Auf die Erweiterungen für Token Ring gehe ich nicht weiter ein, dafür aber auf die anderen neun Gruppen. Die Statistics Group liefert, wie der Name schon sagt, Statistikdaten über das Netzsegment, wie Anzahl und Größe der übertragenen Pakete und Oktetts (Bytes), Anzahl der Multicasts, Broadcasts und Kollisionen. In der History Group werden Daten für historische Analysen der obigen Werte gesammelt. So lassen sich Trendanalysen für einen bestimmten Zeitraum erstellen. Die Beobachtung von Variablen der RMON-MIB und ihr Vergleich mit Schwellwerten wird über die Alarm Group realisiert. Die Host Group dient der Sammlung von statistischen Informationen (gesendete und empfangene Pakete) aller an dem LAN-Segment angeschlossenen Hostrechner. Für die Erstellung von Reports, z.B. einer Top10 der Rechner mit der höchsten Auslastung, werden Daten in der HostTopN Group gesammelt und nach den jeweiligen Kriterien sortiert. Die Matrix Group ist für die Messung des Datenaufkommens zwischen zwei Netzgeräten, angegeben durch ihre MAC-Adressen, zuständig. Dazu erfolgt eine ständige Aktualisierung der Paketzähler. Mit Hilfe der Filter Group können über Filterausdrücke bestimmte Pakete aus dem Netzverkehr für eine genauere Untersuchung ausgewählt werden. Die Auswertung der gefilterten Pakete geschieht in der Capture Group (auch Packet Capture Group). In der Event Group sind die möglicherweise eintretenden Ereignisse bestimmten Aktionen zugeordnet, die der Agent dann auszuführen hat. Alle der in dieser Arbeit gewonnenen Meßergebnisse basieren auf der Verwendung der RMON-MIB bzw. ihrer Weiterentwicklungen. So ist neben dem Monitoring von Ethernet und Token Ring inzwischen auch eine Analyse von FDDI-Ringen möglich. Dazu werden spezielle Probes angeboten, so z.B. die NETscout FDDI/CDDI Probe von der Firma Frontier. Bei meinen Messungen im Universitätsrechenzentrum der Otto-von-Guericke-Universität Magdeburg stand mir so ein Gerät mit der dazugehörigen Software NETscout Manager zur Verfügung (siehe auch Kapitel 2.3: Frontier NETscout Manager). Um diese zusätzlichen Topologien in die Messung per RMON einzugliedern, wurden spezifische RMON-MIBs dafür entwickelt.

Standard-RMON erlaubt nur das Monitoring des Netzsegmentes auf der Physikalischen Schicht (MAC-Layer) des ISO/OSI-Referenzmodells. RMON-Probes können also nicht „sehen“, was nach einer Router-Verbindung im Netz geschieht. Mit dem noch nicht standardisierten RMON2 ist dagegen eine Sicht auf alle sieben Schichten möglich. RMON2 erlaubt somit auch das Monitoring der Anwendungsschicht (Schicht 7), womit eine Diagnose von Programmen wie Microsoft Mail oder Sybase möglich wird. Frontier Software hat RMON2 noch um die Möglichkeit der Überwachung einer Client/Server-Umgebung und der Unterstützung von WAN, FDDI, Fast Ethernet und ATM erweitert und bezeichnet dies als Enterprise RMON (oder RMON+). Eine Eingliederung von RMON, RMON2 und Enterprise RMON in das ISO/OSI-Referenzmodell zeigt die Abbildung 12. Die steigende Funktionalität bei der Analyse von Leistungswerten des Netzes durch Einsatz dieser drei Arten wird abschließend noch einmal in der Tabelle 3 auf der nächsten Seite zusammengefaßt. ([FRON95])

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: RMON und OSI

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: RMON, RMON2 und Enterprise RMON

1.3 Internet und World Wide Web

In den folgenden Abschnitten möchte ich eine kurze Einführung in das Internet und das World Wide Web vornehmen. Dabei wird der Schwerpunkt auf das World Wide Web gelegt, da das Internet, seine Geschichte und die grundlegenden Protokolle in den vorhergehenden Kapiteln bereits beschrieben worden sind. Außerdem basieren die vorgenommenen Messungen auf dem World Wide Web und den Navigationsprogrammen für das World Wide Web, die im weiteren als Browser, WWW-Browser oder Web-Browser bezeichnet werden. Drei ausgewählte Browser sollen dabei einer näheren Betrachtung in Hinsicht auf ihre Funktionalität unterzogen werden. Zum Schluß dieses Kapitels soll eine knappe Einführung in die Auswirkungen von Cache bzw. Proxy Cache auf das World Wide Web und eine kurze Beschreibung der Programmiersprachen Java und JavaScript erfolgen.

1.3.1 Internet

Das Internet ist ein weltweiter Verbund von Rechnern, der Dienste wie das Übertragen von Dateien (File Transfer Protocol - FTP), elektronische Post (e-Mail) oder das World Wide Web (WWW) zur Verfügung stellt. Da Einzelheiten zum Internet bereits erläutert wurden, sollen hier nur einige sehr interessante Statistiken zu der Größe und Entwicklung dieses Netzes angeführt werden.

In den letzten Jahren ist eine fast dramatische Zunahme der Anzahl von Rechnern im Internet zu verzeichnen gewesen. Dies vor allem auch deshalb, da ein Zugang zum Internet in zunehmendem Maße auch für Privatpersonen und kleinere Firmen möglich geworden ist. Das belegen aktuelle Zahlen über die Anzahl der Rechner im Internet, die vom DeNIC im World Wide Web der Öffentlichkeit zur Verfügung gestellt werden. Die Quelle dieser Meßergebnisse ist allerdings das RIPE in Amsterdam (RIPE - Réseaux IP Européens).

Zu erwähnen ist zuvor noch, das eine Einteilung des Internet in als Domains und Subdomains bezeichnete Bereiche erfolgt. Einer Domain bzw. Subdomain sind Gruppen von Rechnern zugeordnet, die durch ihre Adressen auseinandergehalten werden können. So gehören Rechner in Deutschland der Top-Level-Domain DE an. Eine Subdomain kann jetzt die Firma oder Institution sein, z.B. uni-magdeburg. Die Subdomain läßt sich noch weiter unterteilen. So ergibt sich für die Fakultät für Informatik (FIN, engl.: computer science (cs)) der Otto-von-Guericke-Universität Magdeburg folgende Adresse:

cs.uni-magdeburg.de.

Mit Stand vom 01. November 1996 gab es in Deutschland insgesamt 652.563 Rechner, die in der Domain DE registriert waren. Dies entspricht einer Steigerung von 1,3 % im Vergleich zum Vormonat. Deutschland hat damit in Europa die meisten Rechner im Internet, gefolgt von Großbritannien (Domain UK: 599.098) und Finnland (Domain FI: 309.191). Insgesamt wurden in Europa zum gleichen Zeitpunkt 3.358.686 Rechner ermittelt (+ 2,1 %). Die Gesamtzahl der Rechner im Internet beträgt derzeit ca. 13 Millionen.

Die Entwicklung der Anzahl der Rechner (Hosts) im Internet seit dem Jahre 1989 zeigt die Abbildung 13. (Quelle: Network Wizard (Daten), General Magic, Inc.(Grafik))

Sehr gut zu erkennen ist darin auch, daß seit der Einführung des World Wide Web Mitte des Jahres 1993 bzw. seit der Durchsetzung des WWW im Jahre 1994 eine rapide Zunahme der Rechner zu verzeichnen war.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Anzahl der Internet Hosts (1989 - 1996)

Interessant ist auch eine Statistik von NSFnet über den Anteil von bestimmten Diensten des Internet an der Auslastung des Backbones des NSFnet, das ja einer der Vorgänger des Internet war. Leider wurde das Backbone des NSFnet im März 1995 eingestellt, und somit enden die Aufzeichnungen auch in diesem Monat. Aber die Tendenz, die sich in den folgenden Jahren fortsetzte, ist bereits aus diesen Daten ablesbar (siehe Tabelle 4). (Quelle: NSFnet, MIT)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: NSFnet Auslastung (1993 - 1995)

In dieser Tabelle ist deutlich der Anstieg der Belastung des Internet seit der Entstehung des World Wide Web erkennbar.

1.3.2 World Wide Web

Das World Wide Web (WWW) ist derzeit der wohl am meisten genutzte Dienst im Internet. Es ist, kurz gesagt, ein Dienst zum Abfragen und Abholen von Informationen von einem entfernten Rechner. Man kann es somit in das Prinzip der Client/Server (Wechselbeziehung zwischen Dienstanforderung und Dienstbereitstellung) einordnen. Die Daten werden von Servern bereitgehalten und bei Anforderung durch die Clients diesen übermittelt. Der Client-Rechner sorgt dann für die Darstellung dieser Daten auf dem Bildschirm. Die Daten können dabei verschiedenster Art sein, von einfachen Texten über komplette Bücher bis hin zu Bildern, Videos und seit einiger Zeit ist auch das Telefonieren über das Netz möglich. Daß hiermit die Belastung der Datenleitungen des Internet drastisch angestiegen ist, dürfte offensichtlich sein.

Die Entwicklung des WWW begann 1989 am CERN (Europäische Organisation für Kernforschung) in der Schweiz und sollte den Physikern auf der ganzen Welt die Kommunikation mittels Hypertext ermöglichen. Mit Hilfe von Hypertext werden einzelne Dokumente über Verweise (engl.: link) miteinander verbunden. Aber auch Verweise innerhalb eines Dokumentes und zwischen weltweit verteilten Dokumenten sind möglich. Ein Verweis kann dabei sowohl ein Text als auch eine Grafik sein. Hyper Text Markup Language (HTML) heißt die Sprache des World Wide Web. HTML ist einfacher ASCII-Text mit Formatierungsanweisungen. Die Beschreibung dieser plattformunabhängigen Seitenbeschreibungssprache soll allerdings nicht Bestandteil dieser Diplomarbeit sein. Die Darstellung der in HTML geschriebenen Hypertext-Dokumente auf dem Bildschirm erfolgt mit sogenannten Browsern. Der erste grafisch orientierte Browser mit dem Namen Mosaic wurde 1993 vom National Center for Supercomputing Applications (NCSA) an der Universität von Illinois vorgestellt. Mit dieser grafischen Benutzeroberfläche begann das World Wide Web immer mehr an Beliebtheit zu gewinnen. Inzwischen bieten mehrere Softwarefirmen grafische Web-Browser an, u.a. Netscape, Sun und Microsoft. Als Protokoll wird im World Wide Web das Hyper Text Transfer Protokoll (HTTP) eingesetzt.

1.3.2.1 HTTP

Das Hyper Text Transfer Protocol (HTTP) ist ein Protokoll, welches im World Wide Web zur Übertragung der verteilten Hypertext-Dokumente verwendet wird. Es nutzt das TCP als Transport-Protokoll. Soll ein Dokument von einem entfernten Server (Dienstanbieter) angefordert werden, so wird eine Verbindung zu diesem aufgebaut und die Anforderung (Request) versendet. Der Server verarbeitet diese Anforderung, sendet das angeforderte Dokument an den Client (Dienstanforderer) zurück und schließt die Verbindung wieder. Die Anforderung eines Dokumentes erfolgt recht einfach mittels eines GET-Befehles. Die Lage des Dokumentes wird dabei über den Uniform Resource Identifier (URI) beschrieben. Für URIs werden auch andere Namen verwendet: Uniform Resource Locator (URL) und Uniform Resource Name (URN). In der Protokollbeschreibung von HTTP ([HTTP95]) wird die Bezeichnung URI verwendet. Eine URI beinhaltet das Protokoll, welches genutzt werden soll (HTTP, FTP, ...), die IP-Adresse des Servers und den Dateinamen. So könnte meine Homepage (Startseite) vom Web-Server des Sunpools (eva.cs.uni-magdeburg.de) der FIN wie folgt angefordert werden:

GET http://www.cs.uni-magdeburg.de/~tweber/index.html HTTP/1.0

Wenn im URI kein anderer Port für den Zugriff des TCP-Protokolls angegeben ist, so wird standardmäßig der Port 80 (HTTP-TCP) verwendet. Im weiteren werde ich statt URI die gebräuchlichere Bezeichnung URL verwenden. Die Anforderung eines Dokumentes aus dem WWW kann in sehr einfacher Weise mit Hilfe von Telnet nachvollzogen werden (siehe Abbildung 14).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Telnet und HTTP

Dabei wird zuerst eine Telnet-Sitzung zum Web-Server (hier wieder der Web-Server des SunPools, eva.cs.uni-magdeburg.de, IP-Adresse: 141.44.21.5) mit Port 80 aufgebaut. Danach wird die Seite mit dem Befehl GET /~tweber/index.html zur Anzeige auf den Bildschirm geholt.

1.3.2.2 Cache und Proxy-Cache

Eine deutliche Verringerung der Wartezeiten auf die Dokumente des World Wide Web kann das Einschalten eines Cachespeichers bewirken. Ein Cache dient dem zwischenzeitlichen Speichern von Dokumenten (Web-Seiten) und deren Elementen (Bilder, ...). Bei einem erneuten Zugriff auf diese Web-Seite entfällt der Verbindungsaufbau zum entfernten Server, es werden Zeit und Kosten gespart. Für das Caching werden unterschiedliche Varianten angeboten. Die meisten Web-Browser bieten sowohl einen Platten-Cache als auch ein Zwischenspeichern im Hauptspeicher des Rechners an. Jeder dieser Speicher kann manuell in seiner Größe konfiguriert werden. Im Gegensatz zu diesen Cachespeichern, die nur auf den jeweiligen Rechner begrenzt sind, gibt es einen netzwerkweiten Cache, den sogenannten Proxy-Cache. Hier werden sämtliche Dateien, die das Ergebnis der Anfragen von Clients innerhalb des Netzwerkes an entfernte Server sind, als lokale Kopien abgelegt. Das Prinzip ist das Gleiche, der Server muß für eine erneute Anforderung nicht mehr kontaktiert werden. Dieser Cache ist jedoch effizienter, da alle lokalen Rechner auf diesen Zugriff haben. Selbst Daten von Netzwerken, die im Moment wegen eines Fehlers nicht erreichbar sind, könnten somit abgerufen werden, wenn sie sich bereits im Cache befinden. Ein großes Problem ist das Alter der Dateien. In Einzelfällen kann es vorkommen, daß der Cache eine veraltete Version eines Dokumentes an den Client sendet. Doch um dies auszuschließen, wurden einige Strategien entwickelt. Eine wäre das Ausnutzen der Features von HTTP. Dieses Protokoll bietet die Möglichkeit an, mit den Antworten des Servers Informationen über die Änderung eines Dokumentes mitzuliefern. Dies wird mit Hilfe eines Last-Modified-Headers und eines Header-Expires realisiert. Die erste Variante gibt das Datum der letzten Änderung an und die zweite Variante eine Zeit, zu der die Version dieses Dokumentes ausläuft. Die Kommunikation zwischen Proxy-Cache und Server erfolgt dabei über das Protokoll UDP, was sich über ein Dekodieren der Protokolle auch ermitteln läßt. Die Nutzung eines hierarchischen Cache-Verbundes ist die neueste Möglichkeit. Bekannt ist sie unter dem Namen Harvest-Cache oder Squid. Hier werden zusätzlich zu dem lokalen Proxy-Cache noch Nachbarn (engl.: neighbor) definiert, bei denen zusätzlich eine Nachfrage nach den Daten erfolgt. Die Otto-von-Guericke-Universität Magdeburg ist an einen Harvest-Cache angeschlossen. Eine genaue Beschreibung dieses Caches befindet sich in [iX0896], S.124ff.

Für die nachfolgenden Messungen im Netz der Fakultät für Informatik (FIN) zum Vergleich verschiedener Web-Browser mit HP OpenView und HP NetMetrix/UX wurden alle möglichen Cachespeicher (Platten-Cache, Speicher-Cache, Proxy-Cache) ausgeschaltet, um eine Verfälschung der Meßergebnisse zu vermeiden. Eingeflossen ist der Cache allerdings in die Messungen im Universitätsnetz mit Frontier NETscout. Aus den Ergebnissen ist der Austausch von Informationen bzw. Dateien zwischen den Cache-Nachbarn (Cache in Magdeburg und Cache in Jena) gut zu erkennen (siehe Kapitel 3.2: Testfeld 1: URZ (HP OpenView, Frontier NETscout)).

1.3.2.3 Java und JavaScript

Java ist eine von Sun Microsystems entwickelte Programmiersprache zum Erstellen interaktiver und verteilter Anwendungen, die der Sprache C++ sehr ähnlich ist. Die Programme sind plattformunabhängig, d.h. sie laufen auf jedem Rechner. Die Umwandlung von Java-Code in eine Anwendung verläuft in einem Zweiphasen-Prozeß. Das Programm wird in der ersten Stufe in Bytecode umgewandelt. Nach Verteilung an den Anwender und zum Beispiel Einbinden als Java-Applet in ein Dokument für das WWW wird dieser Bytecode auf dieser Maschine (Rechner) von einem Interpreter in die Instruktionen für diesen speziellen Rechner umgewandelt. Bei Aufruf einer Web-Seite mit Java erfolgt zuerst eine Übertragung des kompletten als Bytecode vorliegenden Applets auf den lokalen Rechner. Erst dort wird die Java-Anwendung dann mittels des Java-Interpreters in den spezifischen Code transformiert. Mit Hilfe des Internet Explorers von Microsoft kann dieses Verfahren sehr leicht überprüft werden. Nach Laden einer Web-Seite mit Java-Applets befinden sich diese Dateien (*.class) im Cache-Verzeichnis (wenn nicht anders angegeben heißt dieses „Temporäre Internet Dateien“). Zu erwähnen wäre hier noch, daß nicht alle Online-Dienste, die einen Zugang zum World Wide Web anbieten, die Sprache Java unterstützen. So ist mit America Online (AOL) z.Zt. das Einbinden von Java-Applets noch nicht möglich, da dieses System noch auf dem alten DOS bzw. auf der Dateinamenskonvention 8.3 (Dateiname.Erweiterung) basiert. Java verlangt aber für seine Klassen die lange Dateiendung „class“.

JavaScript ist eine von Netscape und Sun entwickelte plattformübergreifende, auf Objekten basierende Programmiersprache. Sie ist an Java angelehnt, besitzt aber nicht so viele Möglichkeiten. JavaScript ist mehr eine Erweiterung der Hyper Text Markup Language (HTML) und hauptsächlich für die Erstellung von Formularen, kleinen Animationen oder zur Steuerung von Fensterinhalten bei der Verwendung von Frames innerhalb von HTML-Dokumenten einsetzbar. Der JavaScript-Code kann direkt in das HTML-Dokument eingebunden sein oder als externe Datei nachgeladen werden.

[...]