Leseprobe
Inhaltsverzeichnis
Eidesstattliche Erklärung
Abstract
Verzeichnis der Anhänge
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Motivation und Zielsetzung der Arbeit
1.2 Umfeld
1.3 Aufbau der Arbeit
2 Theoretische Grundlagen zur passiven RTT-Messung
2.1 Einführung in die aktiven und passiven RTT-Messmethoden
2.2 Erläuterung der SYN/ACK-Methode
2.3 Algorithmus der verteilten RTT-Messung
3 Konzeption der verteilten Messarchitektur
3.1 Architekturübersicht
3.2 Messsonde capture.c und die Bibliothek read.h
3.3 Datenbankverarbeitung
3.4 Sicherheit der Daten
3.5 Konkreter Ablauf der konzipierten verteilten Messarchitektur
4 Realisierung und Evaluierung der verteilten Architektur
4.1 Realisierung einer verteilten Umgebung
4.2 Evaluierung des realisierten Systems
5 Zusammenfassung und Ausblick
Literaturverzeichnis
Anhang
Verzeichnis der Anhänge
I capture.c-Quellcode Erläuterung
II getConnections()-Prozedur
III trigger_check_segments-Trigger
IV check_count_segments()-Funktion
V Realisierung einer möglichen Testumgebung
VI PostgreSQL-Datenbank „SondenDB“ konfigurieren
VII SSH-Forwarding und Authentifizieren mittels Public Key
VIII Anleitung zur Installation des realisierten Systems
Abstract
Die Round-Trip-Time (RTT) gibt die benötigte Zeit an, die eine Übertragung eines Datenpaketes vom Sender zum Empfänger zusammen mit dem Rücktransport der zugehörigen Antwort in Anspruch nimmt. Sie ist für die Internetqualität ein wichtiger Parameter und gewinnt immer mehr an Bedeutung. Die Telekom vermarktet dieses Leistungsmerkmal beispielsweise als Fast-Path-Option für DSL. Diese Arbeit beschreibt grundsätzlich das Konzept, die Realisierung und die Evaluation eines Systems, mit dem die Messung von RTT-Werten in Netzen ermöglicht wird. Dabei wird nicht nur der gesamte RTT-Wert einer Verbindung gemessen, sondern auch der Anteil der existierenden Verbindungsteilstrecken an diesem gesamten RTT-Wert, falls die Verbindung zwischen Sender und Empfänger über Zwischenstationen aufgebaut wird.
Abbildungsverzeichnis
Abbildung 1.1: Round-Trip-Time
Abbildung 1.2: Beispielszenario zur verteilten RTT-Messung
Abbildung 2.1: Die verschiedenen Methoden zur passiven RTT-Messung
Abbildung 2.2: Prinzip der SYN / ACK – Methode
Abbildung 2.3: Prinzip der verteilten RTT-Messung
Abbildung 3.1: Das Konzept der verteilten Messarchitektur
Abbildung 3.2: Unterscheidung zwischen Steuerungs- und Datensegment
Abbildung 3.3: Aufgabe der getConnections()-Prozedur
Abbildung 3.4: Datengesteuerter bzw. zeitgesteuerter Transport mit wiederholtem Verbindungsaufbau
Abbildung 3.5: Zeitgesteuerter Transport der Daten über eine permanente Verbindung
Abbildung 3.6: Prinzip des SSH-Tunnelings
Abbildung 3.7: Konkreter Ablauf der konzipierten Messarchitektur
Abbildung 4.3: Capture.c - Erfasste Frames - Schreiben in die Datenbank
Abbildung 4.4: Capture.c - Prozessorauslastung - Schreiben in die Datenbank
Abbildung 4.5: Capture.c - Erfasste Frames - Schreiben in die lokale Datei
Tabellenverzeichnis
Tabelle 3.1: Die von der Messsonde transportierten Headerfelder
Tabelle 3.2: Die Schlüsselwörter der Konfigurationsdatei
Tabelle 3.3: Die Schnittstelle zum NDW
Tabelle 4.1: Parameterbeschreibung des Lastgenerators D-ITG
Tabelle 4.2: Capture.c - Erfasste Frames - Schreiben in die Datenbank
Tabelle 4.3: Capture.c - Prozessorauslastung - Schreiben in die Datenbank
Tabelle 4.4: Capture.c - Erfasste Frames - Schreiben in die lokale Datei
Tabelle 4.5: Capture.c - Erkannte TCP-Verbindungen
Tabelle 4.6: Capture.c - Erkannte Verbindungen bei einer Nebenläufigkeit von 10 Clients
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
1.1 Motivation und Zielsetzung der Arbeit
Neben den Parametern Bandbreite und Verfügbarkeit für die Internetqualität ist die Antwortzeit, RTT (Round Trip Time) eine entscheidende Größe. Der RTT-Wert gibt die Zeit an, die benötigt wird, um ein Datenpaket von einer Quelle über ein Netz zum Empfänger zu senden und die Antwort des Empfängers wiederum zurück zum Sender zu transportieren.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.1:Round-Trip-Time
Die Gründe für die Messung von RTT-Werten sind vielfältig. Sie können z.B. dazu benutzt werden, sowohl die Dienstgüte eines Dienstes zu bestimmen als auch das Netzverhalten zu überwachen. Darüber hinaus ermöglichen sie die Überprüfung von Service Level Agreements. In dieser Arbeit geht es grundsätzlich darum, eine verteilte Messung zu realisieren, die es ermöglicht, RTT-Werte in großen Netzen zu erfassen. Dabei soll nicht nur der gesamte RTT-Wert der Verbindung gemessen werden. Auch die Verzögerungszeiten der einzelnen Teilstrecken sollen erfasst werden, wenn die Verbindung zwischen dem Client und Server über mehrere Zwischenstationen -die sogenannten Gateway Routern- aufgebaut wird. Die Idee dabei ist, die Ursache für die Verzögerung eines Paketes herauszufinden. Die Verzögerung eines Paketes kann verschiedene Ursachen haben. Sie kann beispielsweise durch das Netz der entsprechenden Provider verursacht werden. Ein anderes Szenario ergibt sich, falls die Verbindung über verschiedene Provider entlang aufgebaut wird. In diesem Fall kann ermittelt werden, welcher Provider die Kommunikation verzögert hat. Die Abbildung 1.3 auf der nächsten Seite stellt das beschriebene Szenario schematisch dar.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.2:Beispielszenario zur verteilten RTT-Messung
Durch den Einsatz von Messsonden an jedem Gateway-Router lässt sich der gesamte RTT-Wert einer Verbindung sowie der Anteil der existierenden Teilstreckenverzögerungen an diesem gesamten RTT-Wert ermitteln. Die Berechnung der Verzögerungszeiten der einzelnen Teilstrecken erfolgt jedoch nicht im Rahmen dieser Bachelorarbeit. Die Zielsetzung dieser Arbeit besteht darin, die zu dieser Berechnung notwendigen Daten bereitzustellen. Die Berechnung der Teilstrecken wurde von einer anderen Forschungsgruppe übernommen. Anschließend ist das realisierte System zu evaluieren. Evaluation heißt in diesem Kontext, wie sich das realisierte System bezüglich des Ressourcenbedarfs bei wachsendem Netzverkehr verhält. Durch Tests in der Laborumgebung soll also festgestellt werden, ob das realisierte System skaliert.
1.2 Umfeld
Diese Arbeit wird im Umfeld des Fachbereichs Informatik der Fachhochschule Bonn-Rhein-Sieg durchgeführt. Der Fachbereich Informatik ist in verschiedene Schwerpunkte aufgeteilt. Diese Arbeit findet im Schwerpunkt Tele-kommunikation statt und wird in den Laboren C015 und C050 durchgeführt. Diese Labore befassen sich mit den Lehrgebieten "Netzwerksysteme und Telekommunikation" sowie "Hochleistungsnetze und Mobilkommunikation". Sie werden unter anderem für Praxisprojekte, Abschlussarbeiten und Forschungs-projekte genutzt.
1.3 Aufbau der Arbeit
Die Arbeit gliedert sich hauptsächlich in drei Hauptteile. Der erste Teil beschreibt die theoretischen Grundlagen zur passiven RTT-Messung. Zunächst werden die Begriffe „aktives bzw. passives Messen“ eingeführt. Anschließend wird das zur RTT-Berechnung eingesetzte SYN/ACK-Verfahren sowie der Algorithmus der verteilten RTT-Berechnung erläutert. Das zweite Kapitel beschäftigt sich mit der Konzeption der verteilten Messarchitektur. In diesem Teil werden die einzelnen Bestandteile dieser Konzeption genauer beschrieben. Es wird dabei auch auf die Schwierigkeiten bzw. Probleme eingegangen, die sich bei der Implementierung ergaben. Als dritter Teil der Arbeit soll die beschriebene Konzeption konkret realisiert und anschließend bezüglich der Skalierbarkeit evaluiert werden.
2 Theoretische Grundlagen zur passiven RTT-Messung
2.1 Einführung in die aktiven und passiven RTT-Messmethoden
Die Methoden zur RTT-Bestimmung lassen sich in aktive und passive Messmethoden einteilen. Die aktiven Methoden generieren zusätzliche Testpakete, um daraus den RTT-Wert zu bestimmen. Ein bekannter Vertreter dieser Klasse ist das ping Kommando, das auf das Protokoll ICMP basiert. Es schickt ein Echo-Request-Paket an eine Zieladresse, die mit einem Echo-Reply-Paket antwortet. Aus der Differenz der Ankunftszeit des Echo-Reply-Paketes und der Zeit des versendeten Request-Paketes lässt sich die Laufzeit abschätzen. Doch das Problem hierbei besteht darin, dass das ICMP-Protokoll häufig aus Sicherheitsgründen deaktiviert ist. Außerdem führen die zusätzlichen Testpakete zu unerwünschter Zusatzlast des Netzes, die die Messungen verfälschen können.
Im Gegensatz dazu zeichnen die passiven Methoden den realen Verkehr auf und ermitteln daraus den RTT-Wert. Außerdem bieten sie den wichtigen Vorteil der flexiblen Platzierung des Monitors. Grundsätzlich lässt sich die Messung an einer beliebigen Stelle auf dem Weg zwischen den Endrechnern durchführen. Aus diesen Gründen werden häufiger passive Methoden entwickelt, die durch Analyse des Netzverkehrs an einem Beobachtungspunkt auf den RTT-Wert der gemessenen Verbindung schließen. Für die passive Messung von RTT-Werten bietet sich besonders das bekannte Protokoll TCP an, da eine Übertragung eines Datensegmentes vom Sender zum Empfänger den Rücktransport des zugehörigen Bestätigungssegmentes beansprucht. Die folgenden Kapiteln setzen das genaue Verständnis vom TCP-Protokoll voraus.
2.2 Erläuterung der SYN/ACK-Methode
Es existieren verschiedene Methoden, mit deren Hilfe RTT-Werte von TCP-Verbindungen berechnet werden können. Die Slow-Start-Methode beispiels-weise misst den RTT-Wert anhand des Slow-Start-Algorithmus, während kontinuierliche Messmethoden die Messung über den gesamten Zeitraum einer Verbindung vornehmen [Crngarov’07]. In dieser Arbeit wird zur passiven RTT-Messung die sogenannte SYN/ACK-Methode verwendet, die den RTT-Wert beim Aufbau einer TCP-Verbindung ermittelt. Diese Methode ist im Gegensatz zu anderen zwei Messmethoden leichter zu implementieren. Die Abbildung 2.1 stellt diese drei Messmethoden graphisch dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1:Die verschiedenen Methoden zur passiven RTT-Messung
Der Aufbau einer TCP-Verbindung besteht aus einer Abfolge von drei Segmenten (SYN-, SYN/ACK- und ACK-Segment) und wird daher als Three-Way-Handshake bezeichnet. Die Abbildung 2.2 stellt dar, wie die SYN/ACK-Methode den RTT-Wert mithilfe dieses Three-Way-Handshakes ermittelt:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2:Prinzip der SYN / ACK – Methode
Der Monitor schließt durch die Beobachtung von drei direkt aufeinander-folgenden TCP-Segmenten beim Verbindungsaufbau auf die RTT-Zeit. Dabei wird sowohl die Ankunftszeit des initialen SYN-Segments (active open) als auch die Zeit des auf das SYN/ACK-Segment (passive open) folgende ACK-Segments aufgezeichnet. Anschließend kann die RTT-Zeit durch Differenzbildung der aufgezeichneten Zeitwerte ermittelt werden. Vorraussetzungen für diese Messung ist, dass keines der drei Segmente verloren geht und die Segmente weder vom Client noch vom Server verzögert gesendet werden [Jiang’02, S. 77].
Die Schwierigkeit bei der Implementierung dieser Methode besteht darin, die Three-Way-Handshake-Segmente einer Verbindung aus dem Netzverkehr herauszufiltern. Die Erkennung der ersten beiden Segmente des Three-Way-Handshakes (active open und passive open) erfolgt wegen SYN bzw. SYN/ACK Flag problemlos. Das ACK-Segment ist jedoch anhand von Flags nicht identifizierbar, da es im Netzverkehr Segmente gibt, bei denen der ACK-Flag gesetzt ist, diese aber nicht zum Three-Way-Handshake gehören, z.B. die Bestätigungen von Datensegmenten. Auf diese Problematik und deren Lösung wird im Kapitel 3 näher eingegangen.
Anhand der SYN/ACK-Methode lässt sich zwar der RTT-Wert für die gesamte Verbindung ermitteln, sie reicht jedoch alleine nicht, Verzögerungszeiten der einzelnen Teilstrecken einer Verbindung zu berechnen. Deswegen bedarf es einer weiteren Überlegung, die diese Zielsetzung erfüllt. Sie wird im nächsten Kapitel beschrieben.
2.3 Algorithmus der verteilten RTT-Messung
Die Platzierung der Messsonden an jedem Gateway Router ermöglicht innerhalb einer Netzumgebung die Berechnung der Teilstrecken-RTTs einer Verbindung. Die Abbildung 3 stellt das Prinzip der verteilten Messung durch den Einsatz von Messsonden an zwei Gateway-Routern dar. Es wird im Folgenden davon ausgegangen, dass die erste Sonde Alpha und die zweite Sonde Beta heißt. Es entstehen insgesamt drei zu messenden Teilstrecken (auch Segmente genannt), nämlich die erste Teilstrecke zwischen Client und der Sonde Alpha, die zweite Teilstrecke zwischen den Sonden Alpha und Beta und schließlich die dritte Teilstrecke zwischen der Sonde Beta und Server.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3:Prinzip der verteilten RTT-Messung
Zur RTT-Berechnung der ersten Teilstrecke wird auf der Sonde Alpha sowohl die Ankunftszeit des SYN/ACK-Segments als auch die Ankunftszeit des ACK-Segments gemessen. Anschließend kann der RTT-Wert für diese Teilstrecke mittels einfacher Differenzbildung dieser beiden Zeitwerte ermittelt werden. Dieser Wert wird in der Abbildung als Δt_alpha2 bezeichnet. Im Gegensatz dazu werden zur RTT-Berechung der dritten Teilstrecke die Ankunftszeit des SYN- und SYN/ACK-Segments benötigt. Auch hier wird der RTT-Wert durch Differenzbildung der beiden Zeitwerte bestimmt. Er wird in der Abbildung durch Δt_beta1 repräsentiert.
Die Berechnung des RTT-Wertes der mittleren Teilstrecke kann auf zwei verschiede Weisen erfolgen. Hierfür kann einerseits die Differenz Δt_alpha1- Δt_beta1, andererseits die Differenz Δt_beta2-Δt_alpha2 benutzt werden. Im ersten Fall gehen in die Berechnung die Ankunftszeiten des SYN- und SYN/ACK-Segments ein, im zweiten Fall die Ankunftszeiten des SYN/ACK- und ACK-Segments. In dem vorliegenden Prototyp wurde die erste Berechnungs-vorschrift verwendet.
Die gesamte Strecke, also die Strecke zwischen Client und Server, kann wiederum durch die Addition von Δt_alpha1 und Δt_alpha2 bzw. Δt_beta1 und Δt_beta2 berechnet werden.
Es ist offensichtlich, dass für die RTT-Berechnung keine Zeitsynchronisation notwendig ist. Zur Ermittlung eines RTT-Wertes wird lediglich benötigt, wann ein Segment geschickt wurde und zu welchem Zeitpunkt die entsprechende Antwort wieder am Sender ankommt.
3 Konzeption der verteilten Messarchitektur
3.1 Architekturübersicht
Im Zuge des Projektes der passiven RTT-Messung wurde bereits eine Architektur konzipiert, die es ermöglicht, pro aufgebaute TCP-Verbindung einen RTT-Wert zu berechnen, der nur die gesamte Verzögerung dieser Verbindung präsentierte [Neth’07 a]. Das Konzept dieser Architektur wurde im Rahmen dieser Arbeit so weiterentwickelt, dass es durch eine verteilte Messung möglich ist, auch Messwerte für die einzelnen Teilstrecken einer TCP-Verbindung zu ermitteln. Wie es in der Abbildung 3.1 zu sehen ist, lässt sich das erweiterte Konzept zur verteilten Messarchitektur in drei Teile gliedern. Der erste Teil beschäftigt sich mit der Erfassung der Three-Way-Handshake-Segmente, die zur Berechnung der RTT-Werte notwendig sind. Für die Aufzeichnung dieser Segmente ist das capture-Programm zuständig, das im Folgenden auch als Messsonde bezeichnet wird. Für jede Netzkomponente, auf der diese Messsonde läuft, wurde ebenfalls eine eigene Datenbank angelegt. Sie ist in der Abbildung als SondenDB bezeichnet. Zeichnet die Messsonde ein solches Segment auf, sendet sie es zur Weiterverarbeitung an diese lokale SondenDB.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1:Das Konzept der verteilten Messarchitektur
Die Struktur der SondenDB ist einfach aufgebaut. Sie enthält eine einzige Tabelle, die tbl_segments heißt. Aufgezeichnete Daten der Messsonde werden in dieser Tabelle gespeichert. Außerdem ist mit dieser Tabelle ein Trigger verknüpft, der nach jeder Einfügeoperation in diese Tabelle die Triggerfunktion check_count_segments() aufruft. Diese Triggerfunktion hat die Aufgabe, bei jedem Aufruf den von ihm verwalteten Zähler um eins zu erhöhen und anschließend zu überprüfen, ob er den ausgewählten Wert 500 erreicht hat. Diese Zahl wurde aus den Messungen ermittelt und erwies sich als ein günstiger Wert. Wird also der Wert 500 erreicht, so ruft diese Funktion die Prozedur getConnections() auf.
Die Prozedur getConnections() bildet den zweiten Teil der konzipierten verteilten Architektur. Sie überführt nämlich die in der Tabelle tbl_segments gespeicherten Three-Way-Handshake-Segmente jeweils mit ihren Ankunftszeitstempeln in eine einzige Verbindung. Dazu sucht sie für jedes gefundene SYN-Segment das dazu passende SYN/ACK- und ACK-Segment aus. Nach der erfolgreichen Zuordnung und Überführung in eine Verbindung generiert diese Prozedur eine „INSERT“-Anweisung, die diesen Verbindungsdatensatz zum Network Data Warehouse (NDW) in die Tabelle sa_input transportiert. Das NDW ist die zentrale Datenbank, in der alle Daten aufgesammelt werden, die zur Berechnung der Verzögerungszeiten der Verbindungsteilstrecken notwendig sind. Das NDW wird von allen verfügbaren SondenDBs im realisierten System befüllt. In dieser Datenbank ist der Algorithmus zur verteilten RTT-Messung implementiert, der bereits im Kapitel 2.3 erläutert wurde.
Im dritten Teil der konzipierten verteilten Architektur geht es um den Transport der erkannten Verbindungsdatensätze. Dazu baut die SondenDB eine Verbindung zum NDW auf und transportiert sie über diese hergestellte Verbindung und baut sie anschließend wieder ab. Für den Aufbau der Verbindung, den Transport der Daten und den Abbau der Verbindung benutzt die SondenDB die PostgreSQL-Erweiterung Database Links (dblinks). Database Links sind modular aufgebaut. Sie stellen eine Mehrzahl von Funktionen zur Verfügung, die es ermöglichen, datenbankübergreifende SQL-Anweisungen auszuführen. Der Transport der Daten zwischen den verfügbaren SondenDBs und NDW erfolgt verschlüsselt über den erzeugten SSH-Tunnel. Jede SondenDB authentifiziert sich gegenüber dem NDW mittels Public Key Verfahren.
Wurden die erkannten Verbindungsdatensätze zum NDW transportiert, so erfolgt die Berechnung der einzelnen Verbindungsteilstrecken. Anschließend werden diese Ergebnisse in bestimmten Zeitintervallen graphisch visualisiert. In den folgenden Kapiteln werden die einzelnen Bestandteile der konzipierten verteilten Architektur genauer beschrieben.
3.2 Messsonde capture.c und die Bibliothek read.h
3.2.1 Zweck der Sonde
Aufgabe dieser Messsonde ist es, alle TCP-Segmente für den Verbindungs-aufbau aufzuzeichnen. Hierfür überwacht sie permanent den Netzverkehr auf einer angegebenen Schnittstelle und hinterlegt bestimmte Headerfelder der aufgezeichneten Pakete und Segmente jeweils mit ihren Ankunftszeitstempeln in der Datenbank SondenDB. Diese Headerfelder sind in der nachfolgenden Tabelle beschrieben:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.1:Die von der Messsonde transportierten Headerfelder
Bevor das capture-Programm genutzt werden kann, ist eine Installation der Datenbanksoftware sowie eine Vorkonfiguration notwendig. Als Datenbanksoftware kommt hier PostgreSQL zum Einsatz. Zur Anbindung an diese PostgreSQL-DB benutzt die Messsonde die libpq-Bibliothek. Für jedes aufgezeichnete Frame erzeugt sie ein SQL „INSERT“, das die entsprechenden Headerfelder in diese vorkonfigurierte Datenbank schreibt.
Die Three-Way-Handshake-Segmente haben spezielle Flags und beinhalten keine Nutzdaten. Um genau diese Segmente aufzuzeichnen, startet das capture-Programm mit einem im Quellcode festkompilierten Filterausdruck. Dieser Filterausdruck bewirkt, dass aus dem Netzverkehr nur die Segmente aufgezeichnet werden, bei denen das SYN- oder SYN/ACK- oder ACK-Flag gesetzt ist. Die Unterscheidung, ob so ein Segment Nutzdaten enthält oder nicht, ist mit einem Filterausdruck nicht realisierbar. Deswegen wird diese Überprüfung vom capture-Programm selbst vorgenommen. Sie lässt sich in drei Schritten zusammenfassen:
1 Größe des IP-Paket-Headers bestimmen
Die Headergröße eines IP-Paketes ist variabel. Um dessen Größe zu ermitteln, wird das Feld ihl benötigt. In diesem Feld wird die Header-Größe in 32-Bit-Blöcken angegeben. Steht hier also eine 5, so ist der Kopfdatenbereich 5 mal 32 Bit gleich 160 Bit oder 20 Byte lang, was auch die Minimalgröße für den IP-Kopfdatenbereich ist.
2 Größe des TCP-Segment-Headers bestimmen
Analog zum ersten Schritt lässt sich die Größe des TCP-Headers anhand des Feldes Data Offset berechnen. Auch dieses Feld enthält die Größe des TCP-Headers in 32-Bit-Blöcken.
3 Größe der Nutzdaten (IP-Payload) bestimmen
Im letzten Schritt wird die im Schritt 1 ermittelte Größe des IP-Paket-Headers mit der im Schritt 2 ermittelten Größe des TCP-Segment-Headers addiert. Anschließend wird das daraus resultierende Ergebnis vom IP-Feld Total Length abgezogen. Total Length gibt die Gesamtgröße des IP-Paketes einschließlich Nutzdaten an. Ergibt sich aus der Differenz 0, so beinhaltet das Segment keine Nutzdaten und dient somit zu Steuerungszwecken in TCP-Verbindungen. Anderenfalls (Differenz > 0) ist es ein Datensegment und wird nicht zur Datenbank transportiert.
Abbildung 3.2 stellt die programmiertechnische Umsetzung dieser Vorgehens-weise in 6 Schritten dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: Unterscheidung zwischen Steuerungs- und Datensegment
Wie es bereits in Kapitel 2.2 erwähnt wurde, lässt sich das letzte ACK-Segment anhand von seinem Flag aus dem Netzverkehr nicht eindeutig herauszufiltern. Deswegen werden die nicht benötigten ACK-Segmente ebenfalls in die vorkonfigurierte SondenDB gesendet. Die Behandlung dieser Segmente erfolgt in dieser Datenbank.
Die andere Schwierigkeit der Sonde ergab sich dadurch, dass der mithilfe der libpcap-Bibliothek gewonnene Zeitstempel (pc_time) im Unix Zeitformat vorliegt. Dieses Format gibt die seit dem 1. Januar 1970 00:00:00 GMT vergangenen Sekunden an [Neth 2007 a]. D.h. es soll eine Umwandlung in eine normale Zeitangabe stattfinden. Diese Umwandlung erfolgte mit der Funktion strftime. Sie formatiert eine Unix-Zeit in die angegebene Zeitzone um.
Das capture-Programm benötigt bei der Ausführung root-Rechte, da es auf die Netzwerkschnittstelle zugreifen muss.
3.2.2 Einlesen der Konfigurationen aus der Konfigurationsdatei
Das capture-Programm lässt das Anpassen der überwachten Ports sowie die Einstellungen zur Datenbank durch eine Konfigurationsdatei zu. Für das Einlesen der Konfigurationen aus der Konfigurationsdatei ist die Bibliothek read.h zuständig. Alle notwendigen Einstellungen erfolgen in dieser Konfigurationsdatei. So beschränkt sich der Programmaufruf auf:
./capture ConfigFile
Die Syntax eines Eintrages in die Konfigurationsdatei wird im Folgenden durch die erweiterte Backus-Naur Form (EBNF) beschrieben. Die Terminalsymbole sind durch unterstrichenen Fettdruck gekennzeichnet und sind wörtlich zu übernehmen. Die Nichtterminalsymbole sind in spitzen Klammern eingeschlossen und lassen sich weiter aufgliedern. Geschweifte Klammern stehen für eine beliebige Wiederholung des Inhalts, während runde Klammern lediglich der Gruppierung dienen [Vossen’04, S. 224].
Seien Σ und N zwei Alphabete (Terminalalphabet und Nichtterminalalphabet), S das Startsymbol und P die Produktion. Dann stellt die folgende Grammatik G mit
Abbildung in dieser Leseprobe nicht enthalten
N= { Eintrag, Schlüsselwort, Zuweisung, Freiraum, Buchstabe, Ziffer, Sonderzeichen, Zeichen, Kommentar, EinzeiligerKommentar, MehrzeiligerKommentar, AlleZeichen, AlleZeichenOhneCR }
Abbildung in dieser Leseprobe nicht enthalten
die Syntax eines Eintrages dar. Im Anhang dieser Arbeit ist die gleiche Syntax-beschreibung auch als Syntaxdiagramm zu finden.
Die erlaubten Schlüsselwörter und deren Bedeutungen sind unten aufgeführt:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.2:Die Schlüsselwörter der Konfigurationsdatei
Weiterhin sind bei der Konfiguration der Sonde über die Konfigurationsdatei folgende Punkte zu beachten, die mit EBNF nicht darstellbar sind:
- Die Einstellungen sind zeilenorientiert. D.h. pro Zeile ist nur eine Einstellung möglich. Werden innerhalb einer Zeile weitere Einstellungen angegeben, so werden diese ignoriert und read.h macht mit der nächsten Zeile weiter.
- Die maximale Zeichenanzahl pro Zeile beträgt 255. Wird diese maximale Zeichenanzahl überschritten, so wird das Programm mit entsprechender Fehlermeldung beendet.
- Duplikate von Schlüsselwörtern sind nicht erlaubt.
3.3 Datenbankverarbeitung
3.3.1 Die getConnections()-Prozedur zur Verbindungserkennung
Die getConnections()-Prozedur überführt die einzelnen Segmente des TCP-Verbindungaufbaus jeweils mit ihren erfassten Ankunftszeitstempeln in eine einzige Verbindung. Die Prozedur generiert anschließend eine INSERT-Anweisung, die diesen erkannten Verbindungsdatensatz zur Weiterverarbeitung in das NDW schickt. Somit wird aus den drei Zeilen in der Tabelle tbl_segments eine Zeile in der Tabelle sa_input im NDW. Die Abbildung 3.3 stellt die Aufgabe dieser Prozedur graphisch dar.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.3:Aufgabe der getConnections()-Prozedur
Zur Verbindungserkennung sucht die Prozedur für jedes SYN-Segment aus der Tabelle tbl_segments das passende SYN/ACK- und ACK-Segment aus. Die wesentliche Fragestellung hierfür ist, wie aus dem gesamten Datenbestand einzelne Verbindungen erkannt werden können. Anhand von Quell-/Ziel-IP kombiniert mit Quell-/Ziel-Port lassen sich grundsätzlich TCP-Verbindungen identifizieren. Da aber mehrere ACK-Segmente pro Verbindung gespeichert werden, müssen noch zur Ermittlung des ACK-Segments des Three-Way-Handshakes zusätzlich die Sequenz- und Bestätigungsnummer einbezogen werden. Darüber hinaus werden dieselben TWH-Segmente für den TCP-Verbindungsaufbau in einer verteilten Umgebung von jeder Messsonde aufgezeichnet. Deswegen muss für die Zuordnung dieser drei Segmente zu einer Verbindung auch die entsprechende Bezeichnung der Messsonde berücksichtigt werden, die diese Segmente aufgezeichnet hat. Dazu wurde die Variable probe_desc eingeführt, die die eindeutige Bezeichnung einer Sonde enthält.
Damit das entsprechende SYN/ACK-Segment zum SYN-Segment zugeordnet werden kann, müssen die folgenden Bedingungen erfüllt werden:
a) Die Quell-IP-Adresse des SYN/ACK-Segments entspricht der Ziel-IP-Adresse des SYN-Segments
b) Der Quell-Port des SYN/ACK-Segments entspricht dem Ziel-Port des SYN-Segments
c) Die Ziel-IP-Adresse des SYN/ACK-Segments entspricht der Quell-IP-Adresse des SYN-Segments
d) Der Ziel-Port des SYN/ACK-Segments entspricht dem Quell-Port des SYN-Segments
e) Der Datensatz entspricht einem SYN/ACK-Segment (fsyn = TRUE AND fack = FALSE)
f) Die Bestätigungsnummer des SYN/ACK-Segments entspricht der Sequenznummer des SYN-Segments +1
g) Das SYN/ACK-Segment wurde von derselben Sonde wie beim SYN-Segment aufgezeichnet
Die Bedingungen a) bis d) (Socketpaar) identifizieren die TCP-Verbindung. Durch die Bedingungen e) und f) wird das auf das SYN-Segment folgende SYN/ACK-Segment dieser Verbindung ermittelt. Die letzte Bedingung g) stellt sicher, dass das SYN/ACK-Segment von der gleichen Sonde aufgezeichnet wurde, die auch das SYN-Segment aufgezeichnet hat.
Analog dazu lässt sich das entsprechende ACK-Segment zum SYN/ACK-Segment wie folgt zuordnen:
a) Die Quell-IP-Adresse des ACK-Segments entspricht der Ziel-IP-Adresse des SYN/ACK-Segments
b) Der Quell-Port des ACK-Segments entspricht dem Ziel-Port des SYN/ACK-Segments
c) Die Ziel-IP-Adresse des ACK-Segments entspricht der Quell-IP-Adresse des SYN/ACK-Segments
d) Der Ziel-Port des ACK-Segments entspricht dem Quell-Port des SYN/ACK-Segments
e) Der Datensatz entspricht einem ACK-Segment (fsyn = FALSE AND fack = TRUE)
f) Die Sequenznummer des ACK-Segments entspricht der Bestätigungsnummer des SYN/ACK-Segments
g) Die Bestätigungsnummer des ACK-Segments entspricht der Sequenznummer des SYN/ACK-Segments + 1.
h) Das ACK-Segment wurde von derselben Sonde wie beim SYN/ACK-Segment aufgezeichnet
Auch hier identifizieren die Bedingungen a) bis d) die TCP-Verbindung. Die Bedingungen e) bis g) ordnen das passende ACK-Segment zum SYN/ACK-Segment zu. Anschließend stellt die Bedingung h) sicher, dass das ACK-Segment von derselben Sonde aufgezeichnet wurde, die auch das SYN/ACK-Segment aufgezeichnet hat.
Die getConnections()-Prozedur schreibt zum NDW pro TCP-Verbindung und pro Messsonde genau einen Verbindungsdatensatz. Wird z.B. eine TCP-Verbindung über 2 Messsonden aufgebaut, so transportiert sie genau 2 Verbindungsdatensätze. Für jeden erkannten Verbindungsdatensatz sendet diese Prozedur zum NDW folgende Informationen:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.3:Die Schnittstelle zum NDW
Durch die Sequenznummer des SYN- und SYN/ACK-Segments lassen sich die pro Messsonde und pro TCP-Verbindung transportierten Verbindungs-datensätze im NDW zueinander zuordnen.
Nach dem Transport eines erkannten Verbindungsdatensatzes zum NDW werden die Three-Way-Handshake-Segmente dieser Verbindung aus der Tabelle tbl_segments entfernt. Dieser Prozess wiederholt sich, bis alle SYN-Segmente in dieser Tabelle abgearbeitet wurden. Nach der Ausführung der Prozedur bleiben als Datenbestand 3 Arten von Segmenten übrig:
- Segmente noch nicht fertig aufgebauter Verbindungen
- Nicht benötigte ACK-Segmente (z.B. Datenbestätigungen)
- Fehlerhafte Segmente bzw. Segmente abgebrochener Verbindungen
Sowohl die nicht benötigten ACK-Segmente als auch die fehlerhaften Segmente bzw. Segmente abgebrochener Verbindungen können bedenkenlos gelöscht werden. Im Gegensatz dazu sind jedoch die noch nicht fertig aufgebauten Verbindungen für die RTT-Messung noch relevant. Deswegen muss sichergestellt werden, dass solche Segmente nicht irrtümlich gelöscht werden. Dies wird erreicht, indem nur die Segmente gelöscht werden, deren Zeitstempel mindestens den Timeout einer TCP-Verbindung überschritten haben. Der Timeout einer TCP-Verbindung wurde in der Prozedur als 2 Minuten gewählt.
3.3.2 Transport der Daten zum NDW
Für den Transport der erkannten Verbindungsdatensätze zum NDW bieten sich grundsätzlich zwei verschiedene Varianten an:
1) Datengesteuerter Transport der Daten mit wiederholtem Verbindungsaufbau
2) Zeitgesteuerter Transport der Daten
a. Mit wiederholtem Verbindungsaufbau
b. Über eine permanente Verbindung
Bei der Auswahl dieser Varianten lautet die Anforderung, die sich an den Transport dieser erkannten Verbindungsdatensätze stellt, sie zum NDW so schnell wie möglich zu transportieren. Denn nach der Berechnung der TeilstreckenRTTs aus diesen transportierten Verbindungsdatensätzen werden diese ermittelten Messwerte graphisch visualisiert. Für die Visualisierung ist es wichtig, dass sie möglichst den aktuellen Stand der Messungen wiedergibt. Damit die Visualisierung der Messungen möglichst auf aktuellem Stand bleiben kann, müssen die zu dieser Visualisierung benötigten Daten von SondenDB entsprechend möglichst schnell zum NDW transportiert werden.
Sowohl der datengesteuerte als auch der zeitgesteuerte Transport der Daten mit wiederholtem Verbindungsaufbau verursachen, dass eine Verbindung zum NDW vor jeder Datenübertragung aufgebaut und anschließend wieder abgebaut werden muss. Die Umsetzung dieser beiden Varianten erfolgt so, indem sie lediglich die getConnections()-Prozedur aufrufen. Der eigentliche Verbindungsaufbau zum NDW, der Transport der Daten und anschließend der Verbindungsabbau erfolgt in dieser aufgerufenen Prozedur selbst. Dazu benutzt sie die PostgreSQL-Erweiterung dblinks, die modulare Funktionen zu diesen Zwecken bereitstellt [PostgreSQL’08 a]. In der Prozedur kommen aus dieser Erweiterung drei Funktionen zum Einsatz:
dblink_connect(connname, connstr):Stellt eine Verbindung zu einer entfernten PostgreSQL-Datenbank her. Die hergestellte Verbindung bleibt so lange bestehen, bis sie explizit geschlossen oder die Datenbank-Sitzung beendet wird.
dblink_exec(connname, sql):Über diese Funktion lassen sich über die bereits hergestellte Verbindung SQL-Befehle an die entfernte Datenbank senden.
dblink_disconnect(connname):Baut eine hergestellte Verbindung wieder ab.
Der Ablauf der Varianten 1 und 2a ist in der Abbildung 3.4 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.4:Datengesteuerter bzw. zeitgesteuerter Transport mit wiederholtem Verbindungsaufbau
1) Der erste Schritt besteht darin, die getConnections()-Prozedur auf-zurufen. Der Aufruf dieser Prozedur erfolgt datengesteuert bzw. zeitgesteuert.
2) Daraufhin stellt die Prozedur eine Verbindung zum NDW her.
3) Es findet der Transport der erkannten Verbindungsdatensätze statt.
4) Anschließend wird die Verbindung wieder abgebaut.
Der datengesteuerte Transport tritt ein, wenn die Tabelle tbl_segments eine bestimmte Anzahl von Datensätzen beinhaltet. Die Anzahl wurde -wie es bereits erwähnt wurde- als 500 gewählt, d.h. wird die Tabelle mit 500 Datensätzen befüllt, so wird die Funktion getConnections() aufgerufen. Der Nachteil entsteht bei dieser Vorgehensweise, wenn die Anzahl der Datensätze eine längere Zeit kleiner als 500 bleibt. Diese Daten werden nicht transportiert, obwohl sie im NDW benötigt werden, damit die graphische Visualisierung dieser RTT-Messungen aktualisiert wird.
Bei der zweiten Variante wird die Prozedur getConnections() automatisch in zeitlichen Abständen unabhängig von der Anzahl der eingefügten Datensätze aufgerufen. Das Zeitintervall zwischen Aufrufen wurde als eine Minute gewählt. Als Nachteil ergibt sich hier, dass der Aufruf der Prozedur nach jeder vollendeten Minute auch dann stattfindet, wenn in der Tabelle tbl_segments gar keine Daten existieren. Auch der umgekehrte Fall ist als ein Nachteil zu sehen. Sammeln sich in dieser Tabelle sehr viele Daten an, weil der Netzverkehr auf einmal zunimmt, können sie eine Minute lang nicht abgearbeitet werden.
Durch die Kombination der beiden Varianten kann man versuchen, die geschilderten Nachteile zu vermeiden. Dazu wird ein konkreter Fall betrachtet. Enthält die Tabelle tbl_segments 400 Datensätze und fallen für eine Zeitlang keine Daten mehr an, tritt hier die zeitgesteuerte Überwachung ein. Der Nachteil der ereignisgesteuerten Überwachung wird dadurch eliminiert, indem die zeitgesteuerte Überwachung diese 400 Datensätze maximal nach einer Minute abarbeitet. Nimmt dagegen das Datenaufkommen in der Tabelle tbl_segments schnell zu, so tritt hier die ereignisgesteuerte Überwachung ein. Sie behebt den Nachteil der zeitgesteuerten Überwachung, weil er die Abarbeitung der Datensätze bereits nach dem 500. eingefügten Datensatz vornimmt und nicht auf die Vollendung einer Minute warten muss.
Doch es gibt ein Problem, das sowohl bei der datengesteuerten als auch der zeitgesteuerten Überwachung auftritt. Es wird angenommen, dass die Prozedur getConnections() ein zweites Mal aufgerufen wird, bevor sein erster Aufruf noch nicht zu Ende ausgeführt wurde. Es entstehen zwei Instanzen dieser Prozedur, die jeweils zur gleichen Zeit auf die Tabelle tbl_segments zugreifen. Diese zwei Instanzen werden unter PostgreSQL auch als Transaktionen bezeichnet. Der gleichzeitige Zugriff dieser beiden Transaktionen auf dieselbe Tabelle verursacht Datenredundanz und zwar aus folgendem Grund: Die PostgreSQL-Datenbank sorgt dafür, dass zwei schreibende Transaktionen niemals zur gleichen Zeit ausgeführt werden. Doch das gleichzeitige Lesen von Transaktionen wird nicht unterbunden. D.h. während die erste Instanz der getConnections()-Prozedur die Daten in der Tabelle tbl_segments abarbeitet, kann diese Tabelle gleichzeitig von der zweiten Instanz gelesen werden. Das Problem tritt genau dadurch auf. Die zweite Instanz erkennt durch eine Leseoperation (SELECT-Anweisung) den ersten Verbindungsdatensatz aus dieser Tabelle, transportiert ihn zum NDW und versucht anschließend die Three-Way-Handshake-Segmente dieser erkannten Verbindung aus der Tabelle zu entfernen. Doch das Löschen aus dieser Tabelle kann nicht erfolgen, weil diese Operation von PostgreSQL ebenfalls als ein Schreibzugriff gesehen wird. Folglich wird diese Löschoperation blockiert, bis die erste Instanz zu Ende ausgeführt und die Tabelle tbl_segments wieder freigegeben wird. Da die Segmente des erkannten Verbindungsdatensatzes von der zweiten Instanz nicht gelöscht werden konnten, werden diese von der ersten Instanz ebenfalls zu einer Verbindung zugeordnet. Dieser erkannte Verbindungsdatensatz wird somit ein zweites Mal zum NDW gesendet und es entstehen somit zwei redundante Datensätze.
Das Problem kann nur gelöst werden, indem sichergestellt wird, dass die Ausführungen der gleichzeitigen Prozeduraufrufe nacheinander stattfinden. D.h. wenn zu einem Zeitpunkt ein Prozeduraufruf ausgeführt wird, dann darf die Tabelle tbl_segments von anderen Transaktionen weder gelesen noch geschrieben werden. Somit werden die nebenläufigen Transaktionen blockiert, bis die zuerst aufgerufene Prozedur zu Ende ausgeführt wurde. Dieser Ansatz ist die strikteste Transaktionsisolation, die mit der SQL-Anweisung LOCK TABLE erreicht werden kann [Eisentraut’07 a]. Doch dadurch entsteht ein neues Problem. Da diese Tabelle komplett gesperrt wird, kann sie während der gesamten Ausführungszeit der getConnections()-Prozedur von der Messsonde nicht befüllt werden. D.h. durch diese Sperre werden die von dem capture-Programm erfassten Segmente in diese Tabelle nicht geschrieben und gehen verloren.
Aus theoretischer Sicht müssen die zwei Prozesse, nämlich das Auslesen aus der Tabelle tbl_segments zur Verbindungserkennung und das Schreiben in diese Tabelle durch die Messsonde voneinander getrennt werden. Die Kombination der ereignisgesteuerten und der zeitgesteuerten Überwachung ergibt sich als die beste Variante. Denn die beiden Varianten beheben gegenseitig ihre eigenen Nachteile und transportieren die Daten so schnell wie möglich zum NDW.
Der zeitgesteuerte Transport der Daten über eine permanente Verbindung verfolgt einen anderen Ansatz. Für die Realisierung dieser Variante wurde ein C-Programm geschrieben, das auch als Dämon genannt wird.[1]Er läuft die ganze Zeit im Hintergrund und hat die Aufgabe, eine Verbindung zum NDW aufzubauen und sie aufrecht zu erhalten. Dadurch wird der ständige Auf- und Abbau einer Verbindung aus den Varianten 1 und 2a vermieden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.5:Zeitgesteuerter Transport der Daten über eine permanente Verbindung
1. Der Dämon stellt mithilfe der libpq-API eine Verbindung zur SondenDB her.
2. Über diese hergestellte Verbindung ruft er auf dieser Datenbank die Funktion dblink_connect() mit entsprechenden Parametern auf.
3. Diese Funktion bewirkt, dass die SondenDB von sich aus eine Verbindung zum NDW herstellt (conn2).
4. Anschließend ruft der Dämon in zeitlichen Abständen (nach jeder vollendeten Minute) die Prozedur getConnections() auf
5. Zum Transport der Daten zum NDW benutzt die getConnections()-Prozedur die von der SondenDB im Schritt 3 hergestellte Verbindung conn2. Diese Verbindung bleibt solange bestehen, bis der Dämon sie wieder explizit abbaut oder der Dämon selbst beendet wird.
Als Nachteil hat sich hier jedoch erwiesen, dass der zeitgesteuerte Transport der Daten über eine permanente Verbindung sich mit der datengesteuerten Überwachung nicht kombinieren lässt und zwar aus folgendem Grund: Die Datenbank SondenDB, in der die datengesteuerte Überwachung läuft, stellt eine eigene Sitzung dar. Baut der Dämon eine Verbindung zur SondenDB auf, geschieht dies ebenfalls über eine separate Sitzung. Es entstehen zwei Sitzungen, die voneinander unabhängig sind, d.h. wenn der Dämon die permanente Verbindung zum NDW hergestellt hat, ist sie nur innerhalb der eigenen „lokalen“ Sitzung sichtbar, welche von der datengesteuerten Überwachung zum Datentransport nicht genutzt werden kann.
3.4 Sicherheit der Daten
3.4.1 Transport der Daten über einen SSH-Tunnel
Die Daten von der SondenDB zum NDW werden über das Internet unverschlüsselt übertragen. Um dieses Sicherheitsrisiko zu vermeiden, wurde für diese Kommunikation ein SSH-Tunnel erzeugt, der für eine sichere Verbindung sorgt. Ein SSH-Tunnel lässt sich mit ssh –L 2345:localhost:5432 probe@HostB einrichten, wobei probe den Benutzernamen angibt, mit dem SSH-Client sich gegenüber dem SSH-Dämon auf Host B mit entsprechendem Passwort authentifizieren kann [BSB 2004, S.159]. Die Abbildung 3.6 stellt das Prinzip des SSH-Tunnelings dar.
Abbildung in dieser Leseprobe nicht enthaltenAbbildung 3.6:Prinzip des SSH-Tunnelings
Die getConnections()-Prozedur in der SondenDB sendet die erkannten Verbindungsdatensätze an den lokalen Port 2345. Der lokale SSH-Client überwacht diesen Port, verschlüsselt die dort ankommenden Daten und sendet sie anschließend durch den Tunnel an den SSH-Dämon an Port 22. Der entfernte SSH-Dämon auf Host B entschlüsselt diese Daten und gibt sie an das NDW an Port 5432 weiter.
3.4.2 Authentifizieren mittels Public Key Verfahren
Das Public Key Verfahren erlaubt die Authentifizierung zwischen einem SSH-Client und SSH-Server mit einem kryptografischen Schlüssel anstelle eines Login-Passworts. Im Gegensatz zu einem Passwort ist ein kryptografischer Schlüssel sicherer, da er niemals über das Netzwerk übertragen wird. Er ist ein zusammengehörendes Schlüsselpaar, das aus dem öffentlichen und privaten Schlüssel besteht. Mit dem öffentlichen Schlüssel wird eine Nachricht verschlüsselt, während der dazu passende private Schlüssel sie wieder entschlüsseln kann [BSB 2004, S. 142].
Der Host, auf dem der SSH-Client installiert ist, generiert zunächst dieses Schlüsselpaar und übergibt den öffentlichen Schlüssel an den Server. Will der SSH-Client über den erzeugten Tunnel eine Verbindung zum SSH-Dämon aufbauen, so muss sein Host beweisen, dass er im Besitz des privaten Schlüssels ist, der zum öffentlichen Schlüssel dieses Servers passt. Zu diesem Zweck führt der SSH-Server mit dem SSH-Client komplexe Verhandlungen durch, die auf diesen beiden Schlüsseln basieren. Nach erfolgreicher Authentifizierung gewährt der SSH-Dämon dem SSH-Client den sicheren Zugriff ohne Passworteingabe. Da die Daten zwischen SondenDB und NDW ebenfalls über diesen Tunnel transportiert werden, erfolgt die Authentifizierung nach dem gleichen Schema.
Es ist anzumerken, dass diese Authentifizierung immer nur in einer Richtung gelingt. D.h. es wird sichergestellt, dass nur die berechtigten Clients in das NDW Daten transportieren können. Aber die Authentifizierung vom NDW wird hier nicht vorgenommen.
3.5 Konkreter Ablauf der konzipierten verteilten Messarchitektur
In diesem Kapitel wird der konkrete Ablauf der konzipierten, verteilten Mess-architektur anhand eines Beispieles beschrieben. Doch zuerst soll der Ablauf des gesamten Systems zur passiven RTT-Berechnung in 5 Schritten auf theoretische Weise zusammenfasst werden:
Schritte, die im Rahmen dieser Arbeit erfolgen:
1. capture.c: Erfassen der Three-Way-Handshake-Segmente (TWH-Segmente) aus dem Netzverkehr
a. Netzverkehr permanent auf einer angegeben Schnittstelle überwachen
b. Erste Filterung des Netzverkehrs vornehmen (Segmente ohne gesetztem SYN oder ACK Flag und mit Payload-Größe > 0 werden verworfen)
c. Segmente, die diesen ersten Filter überwunden haben, in die SondenDB weiterleiten
2. Datengesteuerter Aufruf der getConnections()-Prozedur in der SondenDB (nach 500 eingefügten Datensätzen)
3. getConnections()-Prozedur: Überführen der TWH-Segmente jeweils mit ihren erfassten Ankunftszeitstempeln in eine einzige Verbindung
a. Verbindungsaufbau zum NDW über den erzeugten SSH-Tunnel
b. Der verschlüsselte Transport eines erkannten Verbindungsdatensatzes zum NDW über die aufgebaute Verbindung
c. Löschen der TWH-Segmente dieser erkannten Verbindungsdatensatzes
d. Falls noch nicht alle SYN-Segmente abgearbeitet wurden, mit dem Schritt 3b fortfahren, ansonsten dem Schritt 3e folgen
e. Löschen aller Segmente, deren Ankunftszeitstempel den Timeout einer TCP-Verbindung überschritten haben. Der Timeout einer TCP Verbindung wurde auf 2 Minuten festgelegt (Zeitstempel eines Segments< (aktuelle Zeitstempel-2 Minuten) ? à ja: löschen, nein: nicht löschen).
f. Abbau der hergestellten Verbindung
[...]
[1]Der programmierte Dämon ist im CD OrdnerEntwicklung/Evaluationzu finden