Kapitel   1

Inhaltsverzeichnis

1  InhaltsverzeichnisINHALTSVERZEICHNISINHALTSVERZEICHNIS  ii

2  Einleitung und Motivation  1

2.1  Einleitung  1

2.2  Motivation  1

3  Grundlagen  3

3.1  Allgemeines  3

3.1.1  Interpolation nach Lagrange  3

3.1.2  Three-Tier-Architektur  5

3.1.3  Two-Tier-Architektur  6

3.1.4  Demilitarisierte Zone  6

3.2  Protokolle  6

3.2.1  Internet Protocol  8

3.2.2  Transport Control Protocol  9

3.2.3  Hypertext Transport Protocol  9

3.2.4  Secure Socket Layer  11

3.3  Kommunikationstechniken  13

3.3.1  Parallel Virtual Maschine  13

3.3.2  Remote Method Invocation  13

ii

iii

3.3.3 Common Object Request Broker Architekture . . . . . . . . . 15 3.3.4 Simple Object Access Protocol . . . . . . . . . . . . . . . . . 16 3.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.2 Variablen-Handling . . . . . . . . . . . . . . . . . . . . . . . 17 3.5 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 3D-Computergra£k . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.2 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.3 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Anforderung 22

4.1 IST-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1 Renderbus . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2 RenderControl V.2 . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.1 Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4 Einsatzgebiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5 Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.1 GUI des Kunden . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.2 GUI des Administrator . . . . . . . . . . . . . . . . . . . . . 28 4.5.3 Verteilanwendung . . . . . . . . . . . . . . . . . . . . . . . 31 4.6 Hardwarespezi£kation . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.7 Betriebssystemspezi£kation . . . . . . . . . . . . . . . . . . . . . . 32

5 Konzeption und Entwurf 33

5.1 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1 Wahl des Datenbankbetriebsystems . . . . . . . . . . . . . . 34 5.1.2 De£nition der Datenbanktabellen . . . . . . . . . . . . . . . 34

iv

5.1.3 De£nition der Relationen . . . . . . . . . . . . . . . . . . . . 36 5.2 verschiedene Client / Server Kommunikationsansätze . . . . . . . . . 39 5.2.1 Parallel Virtual Maschine . . . . . . . . . . . . . . . . . . . . 39 5.2.2 Remote Methode Invocation . . . . . . . . . . . . . . . . . . 40 5.2.3 Common Object Request Broker Architekture . . . . . . . . . 41 5.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3 gra£sche Benutzerober¤äche . . . . . . . . . . . . . . . . . . . . . . 42 5.3.1 Programmierung . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2 Gestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.4 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 47 5.4.1 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4.2 Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4.3 Session-Management . . . . . . . . . . . . . . . . . . . . . . 49 5.4.4 Angriff eines authentisierten Benutzers . . . . . . . . . . . . 52 5.4.5 Angriffspunkt Datenbank . . . . . . . . . . . . . . . . . . . . 53 5.4.6 Sicherheitsrisiko FTP . . . . . . . . . . . . . . . . . . . . . . 54 5.4.7 Komplexitätsanalyse . . . . . . . . . . . . . . . . . . . . . . 55 5.5 Verteilalgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6 Abrechnungsmechanismen . . . . . . . . . . . . . . . . . . . . . . . 58

6 Implementierung 61

6.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 61 6.2 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.3 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3.1 Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3.2 Überprüfung der tatsächlichen Existenz von gerenderten Frames 65 6.3.3 Anbindung von Renderknoten über das WAN . . . . . . . . . 66 6.3.4 Parallelität der Auftragsvergabe . . . . . . . . . . . . . . . . 67

7 Fazit 69

v

A Glossar I

B Tabellenverzeichnis XIII

C Abbildungsverzeichnis XIV

D Literaturverzeichnis XV

Hinweise zur Benutzung dieses

Dokumentes

Bei der Erstellung dieses Dokumentes wurde darauf geachtet, dass auch Laien einen Sachverhalt nachvollziehen können. Fachbegriffe, welche allgemein in ihrer Abkürzung gebraucht werden, werden bei der ersten Verwendung ausgeschrieben. Im weiteren Verlauf nur noch als Abkürzung weiterverwendet. Aus Gründen der besseren Lesbarkeit kann es vorkommen, dass Abkürzungen doppelt beschrieben werden (beispielsweise.: HTTP-Protokoll). Fremdworte, Eigenbezeichnungen und Abkürzungen sind im Glossar zu £nden. Der dort angebrachte Hinweis ist zu beachten. Im Glossar erklärte Begriffe sind Kursiv vom übrigen Text abgehoben.

vi

Danksagung

Ich danke allen Menschen, die mich während der Erstellung meiner Diplomarbeit begleitet haben, meine Macken ertragen haben und immer wieder durch neue Ideen dazu beigetragen haben, die Arbeit ein Stück besser werden zu lassen. Würde ich an dieser Stelle alle Menschen aufzählen, so würden wohl einige Seiten beschrieben werden, darum beschränke ich mich auf die für mich Wichtigsten:

• Britta

• meiner lieben Familie

• meinen lieben Komilitonen, denn geteiltes Leid ist halbes Leid

• der Firma DIGITAL SYSTEMS, insbesondere Danny und Herrn Loos

vii

Kapitel 2

Einleitung und Motivation

2.1 Einleitung

Dem computeranimierten Film wird eine große Zukunft vorhergesagt. Die Zahl der Produktionen steigt von Jahr zu Jahr. Doch nicht jede Produktions£rma kann es sich leisten, selbst für genügend Rechenkapazität zu sorgen. Das ist die Stunde der Dienstleister. Die Firma DIGITAL SYSTEMS ist einer dieser Dienstleister. Sie bieten ihre Rechenkapazität gegen ein Entgeld an. Auf diese Weise kann es sich auch eine kleine Produktions£rma leisten, einen aufwändigen Film zu produzieren. Sie muss sich um die Unterhaltung der Computer, welche die Rechenkapazität zur Verfügung stellen, keine Gedanken machen. Sie wendet sich einfach an den Dienstleister und dieser übernimmt das Rendern, den rechenintensiven Teil der Produktion eines computeranimierten Filmes. Für den Dienstleister stellt sich jedoch das Problem, wie er seine Leistung möglichst transparent dem Kunden gegenüber abrechnen und wie er den eigenen Administrationsaufwand möglichst minimieren kann. Zudem muss der Dienstleister sicherstellen, dass seine Computer möglichst gleichmäßig ausgelastet sind und berücksichtigen, dass ein Auftrag so schnell wie möglich beendet werden soll. In der Diplomarbeit soll gezeigt werden, dass es möglich ist, eine Renderfarm mit geringstmöglichem Aufwand zu betreiben, indem der Kunde einen Großteil der Aufgaben selbst erledigen kann. Der Administrator soll nur im Notfall eingreifen müssen.

2.2 Motivation

Bereits während des Studiums habe ich mich mit dem Thema der Verteilung von Arbeitsintensiven Prozessen auf mehrere Computer beschäftigt. Um ein Semesterbeleg rechtzeitig abliefern zu können, entstand die Idee, die ungenutze Rechenpower eines

1

KAPITEL 2. EINLEITUNG UND MOTIVATION 2

ganzen Unix-Labors zu vereinen, anstatt auf nur einem Rechner des selben Labors die gesamte Arbeit ausführen zu lassen. Bei der Suche nach einem Thema für die Diplomarbeit kam der Zufall ins Spiel. Auf der CeBIT 2001 traf ich per Zufall auf die Firma DIGITAL SYSTEMS aus Leipzig. Sie gehört zu den wenigen Firmen, welche Rechenzeit gegen Bezahlung anbietet. Ich hatte die Gelegenheit die damals aktuelle Version der Software zum Verteilen von Renderprozessen zu begutachten. Auf den ersten Blick war mein Interesse geweckt diese Software zu vervollkommnen. Aber erst die Ideen der Firma machten den Service, der er heute ist. Die Zusammenarbeit hat sich als äußerst produktiv erwiesen und wird sich in Zukunft auch als weiterhin produktiv erweisen, da ich das Glück habe, direkt nach Beendigung des Studiums als fester Mitarbeiter eingestellt zu werden.

Kapitel 3

Grundlagen

Im folgenden werden Grundlagen zum besseren Verständnis der in der Diplomarbeit verwendeten Techniken geschaffen. Bei ausreichend großem Vorwissen ist es möglich, dieses Kapitel zu überspringen.

3.1 Allgemeines

3.1.1 Interpolation nach Lagrange

Im weiteren Verlauf der Diplomarbeit wird es nötig sein anhand von Meßwerten, einen Folgewert näherungsweise im Voraus zu bestimmen. Mittels eines Interpolationsverfahrens ist es nun möglich, auf Basis von nicht äquidistanten Stützwerten (Meßwerten) eine Polynomfunktion zu entwickeln. Durch diese aufgestellte Funktion können beliebige andere Messungen näherungsweise vorausbestimmt werden. Das hier vorgestellte Verfahren wurde vom italienisch-französischen Mathematiker Joseph Louis Lagrange (1736-1813) entwickelt und später auch nach ihm benannt.

Lagrange setzt das gesuchte Polynom p(x), hier mit beispielsweise drei Stützpunkten, folgendermaßen fest:

p(x) = y 0 L 0 (x) + y 1 L 1 (x) + y 2 L 2 (x)

mit den wie folgt de£nierten „Lagrangschen Grundpolynomen”:

KAPITEL 3. GRUNDLAGEN 4

Der Sinn dieser Festlegung wird offensichtlich, wenn man in diese Formeln die gegebenen Wertepaare einsetzt. Für die Stützpunkte x 0 beispielsweise erhält man:

Für das Interpolationspolynom p(x) an der Stelle x 0 gilt daher:

p(x 0 ) = y 0 L 0 (x 0 ) + y 1 L 1 (x 0 ) + y 2 L 2 (x 0 ) = y 0

Analog hierzu ergeben sich die Funktionswerte für x 1 und x 2 wie folgt:

Damit enthält das Polynom p(x) tatsächlich die Punkte P 0 , P 1 und P 2 . Allgemein, d.h. für (n + 1) Stützpunkte, lassen sich die Lagrangeschen Grundpolynome L k (k = 0, 1, . . . , n) auf folgende Weise bestimmen: Der Zähler stellt ein Produkt aus den Faktoren (x−x 0 ), (x−x 1 ), . . . , (x−x n ) mit Ausnahme des Faktors (x−x k ) dar, im Nenner lauten die Faktoren (x k −x 0 ), (x k −x 1 ), . . . , (x k −x n ) mit Ausnahme von (x k − x k ). Dadurch nimmt L k (x) an der Stelle x k den Wert 1 an; an allen anderen Stützstellen den Wert 0. Dieses Vorgehen lässt sich in folgende Formel fassen:

L k (x) =

Um das gesuchte Interpolationspolynom p(x) zu erhalten, wird die Summe aus den Produkten von y k und L k (x) gebildet: n

Hierbei wird deutlich, dass die Grundpolynome L k (x) vom Grad n sind, da sie im

KAPITEL 3. GRUNDLAGEN 5

Zähler die n Faktoren (x − x i ) (für i = 0, 1, . . . , k − 1, k + 1, n) enthalten. Es ist daher zu erwarten, dass die Interpolation mit (n + 1) Stützpunkten zu einem Polynom n-ten Grades führt, bei beispielsweise drei Punkten also zu einer Parabel. Dies kann aber nicht derartig verallgemeinert werden, da beispielsweise eine Interpolation mit den

fünf Punkten P 0 (−2/4), P 1 (−1/1), P 2 (0/0), P 3 (1/1), P 4 (2/4) zu p(x) = x ² führen würde und nicht zu einem Polynom vierten Grades. Daher sagt man, dass das Interpolationspolynom maximal n-ten Grades ist. Eine schnelle Aussage über den Grad von p(x), ohne das Polynom explizit auszurechnen, wird erst durch das Newtonsche Verfahren möglich.

Die allgemeine Formulierung des Lagrangeschen Interpolationsverfahrens zeigt, dass in jedem Fall, auch bei sehr vielen Stützpunkten, ein Polynom p(x) existiert, für das die Forderung p(x i ) = y i erfüllt ist. Sie zeigt aber auch, dass der Schreib- und Rechenauf-wand immer noch erheblich ist, da pro Stützpunkt ein Lagrangesches Grundpolynom anzugeben ist, das wiederum aus n Faktoren im Zähler und Nenner besteht. Außerdem ist eine völlig neue Rechnung erforderlich, wenn beispielsweise zu drei Punkten, durch die das Interpolationspolynom bereits bekannt ist, ein vierter hinzugefügt werden soll. Daher ist dieses Verfahren für praktische Anwendungen nicht immer geeignet. 1

3.1.2 Three-Tier-Architektur

Die Three-Tier-Architektur wird in der Literatur auch in der Kurzbezeichnung 3-Tier geführt. Das englische Wort „Tier” bezeichnet eine Schicht. Demnach geht es also um drei Schichten. Im einzelnen sind diese: Schicht 1 Datenschicht Schicht 2 Logikschicht Schicht 3 Präsentationsschicht

Die Datenschicht wird auch als Backend bezeichnet. Das Backend weiss, wie die zu verarbeitenden Daten physikalisch gespeichert sind. Die Schicht kennt also die Daten, kann mit ihnen aber nichts anfangen. Ein Beispiel wäre eine SQL-Datenbank. Die Logikschicht ist auch als Middletier bekannt. Wie beide Bezeichnungen es bereits andeuten, bedindet sich diese Schicht in der Mitte des Modells und in ihr läuft die eigentliche Programmintelligenz ab. So würde beispielsweise ein Programm zum Errechnen von Primzahlen in dieser Schicht die Berechnungen vornehmen. Die Präsentationsschicht, auch als Frontend bezeichnet, dient der Darstellung der in der 2. Schicht gewonnenen Informationen. Ein simples Beispiel hierfür ist ein Browser. Er stellt die ihm übermittelten Daten einfach nur dar.

¹ [DD75, S. 119]

KAPITEL 3. GRUNDLAGEN 6

Die Three-Tier-Architektur zeichnet sich sowohl durch ihre Skalierbarkeit als auch durch die erhöhte Wartbarkeit der einzelnen Komponenten aus. So ist es beispielsweise möglich, jede Schicht auf einem separaten Computer laufen zu lassen. Bei der Wartbarkeit wäre es beispielsweise denkbar, eine Datenbank durch eine andere zu ersetzen, ohne an der Anwendungslogik Änderungen vornehmen zu müssen.

3.1.3 Two-Tier-Architektur

Anders als die Three-Tier Architektur wird eine Anwendung in der Two-Tier-Architektur nur in zwei Schichten aufgeteilt. Sie arbeiten mit einem Server im Backend, auf dem die Datenbank gespeichert ist, und einer Benutzerschnittstelle, welche auf dem Client-Rechner liegt. Die Applikationslogik kann entweder auf dem Server oder auf dem Client-Rechner liegen.

3.1.4 Demilitarisierte Zone

In einer demilitarisierten Zone (DMZ) plazierte Rechner gehören zwar zum Local Area Network (LAN), können aber selber keine Verbindung zum LAN aufbauen. Allerdings sind Verbindungen vom Internet oder vom LAN zu einem Rechner in der DMZ erlaubt. Somit ist das übrige LAN bei einer eventuellen feindlichen Übernahme der in der DMZ plazierten Rechner nicht bedroht. Eine DMZ selber wird in der Regel durch ein Intrusion Detection System (IDS), quasi einem Einbruchsmelder für ein LAN, und einer Firewall geschützt.

3.2 Protokolle

Damit zwei oder mehr Partner miteinander kommunizieren können, benötigen sie Protokolle. Als Protokolle bezeichnet man die Menge aller Regeln, die nötig sind, um eine kontrollierte und eindeutige Kommunikation zwischen den Teilnehmern zu gewährleisten. Man stelle sich vor, dass sich drei Menschen aus verschiedenen Ländern der Erde treffen und Informationen austauschen wollen. Ohne Protokolle würden diese drei Menschen wild durcheinander sprechen. Keiner würde den anderen verstehen. Haben sich alle drei auf ein Protokoll, quasi auf eine Sprache, geeinigt, klappt die Verständigung untereinander gleich viel besser. Es ist geregelt, wer wann spricht und was passiert, wenn der eine den anderen nicht verstanden hat und so weiter. Man könnte sagen, dass es in der Computerlandschaft fast genauso viele Protokol- le gibt wie unter den Menschen Sprachen. Nachdem die ersten Netzwerkprotokolle

KAPITEL 3. GRUNDLAGEN 7

Tabelle 3.1: ISO/OSI-7-Schichten-Referenzmodell

entwickelt waren, hat man sich bemüht, die Kommunikation über Protokolle allgemeingültig darzustellen und zu de£nieren. Dazu gehört das weit verbreitete ISO/OSI-Referenzmodell. Alle in dem Modell beschriebenen Protokolle haben sehr unterschiedliche Ansprüche. Man hat sie daher, in Abhängigkeit von ihrem Abstraktionsgrad, in sieben Schichten unterteilt. Die Schichten im Einzelnen:

• Die Physikalische Schicht überträgt die Daten über das physikalische Medium, das die Computer miteinander verbindet, also zum Beispiel ein Kabel oder eine Funkstrecke. Hier werden im Wesentlichen Nullen und Einsen übertragen.

• Die Leitungsschicht überträgt sogenannte Datenframes. Sie stellt eine fehlerfreie Verbindung zwischen den Teilnehmern sicher.

• Die Netzwerkschicht übernimmt die Weiterleitung, das Routing, der zu Paketen zusammengefassten Daten an den Empfänger.

• Aufgabe der Transportschicht ist es, die Daten der Sitzungsschicht in kleinere Teile aufzuteilen und den Empfang der Pakete in der richtigen Reihenfolge sicherzustellen.

• Die Sitzungsschicht ist im Wesentlichen für das sogenannte Token Management und die Synchronisation bestimmter Abläufe zuständig.

• In der Darstellungsschicht werden, anders als in den darunter liegenden Schichten, strukturierte Daten, also Zahlen und Zeichen, übertragen .

• Die Anwendungsschicht stellt die Schnittstelle zum Benutzer dar und bietet Dienste, wie zum Beispiel die Übertragung von Dateien oder das Versenden von eMails, an.

Da im Allgemeinen nur die Protokolle der TCP/IP Familie benutzt werden, beschränkt sich der Autor bei den weiteren Betrachtungen auf diese Protokollfamilie. Häu£g £n-

KAPITEL 3. GRUNDLAGEN 8

Tabelle 3.2: vereinfachtes 4-Ebenen-Modell

det sich für diese Familie eine auf vier Schichten reduzierte Darstellung des ISO/OSI Referenzmodelles:

Die TCP/IP Protokollfamilie wird sowohl in lokalen Netzen als auch im Internet verwendet. Alle Eigenarten des Transportweges werden auf der zweiten bzw. dritten Ebene ausgeglichen. Die Anwendungsprotokolle merken prinzipiell keinen Unterschied zwischen lokalen und globalen Verbindungen.

3.2.1 Internet Protocol

Das Internet Protocol (IP) de£niert den Transport von Datagrammen, der kleinsten Einheit für die Übertragung von Daten, über das Internet. Der Transport von einem Rechner zum anderen geschieht über das sogenannte Routing. Kann ein Empfänger nicht im lokalen Teilnetz gefunden werden, so wird versucht, den Empfänger über einen oder über mehrere dazwischenliegende Router zu erreichen. Dabei spielt es keine Rolle, welcher Weg beschritten wird. Es zählt einzig und allein die Tatsache, dass das Ziel gefunden wird.

Um Daten über ein Netzwerk transportieren zu können, ist eine Adressierung dieser Daten notwendig. Der Absender muss angeben können, an wen er die Daten senden möchte und der Empfänger muss erkennen können, von wem die Daten stammen. Die Adressierung erfolgt in TCP/IP Netzen in der Netzwerkschicht mit Hilfe einer 32-Bit langen IP-Adresse. Die IP-Adresse besteht aus einer Netzwerk-ID und einer Host-ID. Die Host-ID gibt die Bezeichnung des Computers innerhalb seines eigenen Netzwerkes an und die Netzwerk-ID liefert die Bezeichnung des Netzwerkes. Alle innerhalb eines Verbundes von Netzwerken sichtbaren Adressen müssen eindeutig sein. Es darf also nicht zweimal dieselbe Host-ID innerhalb eines Netzes geben. Sind mehrere Netzwerke miteinander verbunden, wie es zum Beispiel beim Internet der Fall ist, so müssen auch die Netzwerk-ID’s innerhalb des Verbundes eindeutig sein. Auf den genauen Aufbau der IP-Adressen und deren Unterteilung in verschiedene Klassen möchte der Autor nicht weiter eingehen.

Die Benutzung von IP-Adressen durch den Computer mag für diesen einfach sein. Jedoch ist die Art und Weise der Adressierung über Zahlen für den Menschen alles

KAPITEL 3. GRUNDLAGEN 9

andere als leicht. Daher wurde eine Zuordnung von IP-Adressen zu leichter merkbaren Namen unter der Bezeichnung Domain Name System (DNS) eingeführt. Das IP bietet selber keine eigene Fehlerkorrektur. Für den Ausgleich von Fehlern sind andere Schichten, wie zum Beispiel die Transportschicht, zuständig.

3.2.2 Transport Control Protocol

Das Transport Control Protocol (TCP) ist ein verbindungsorientiertes Protokoll, das auf der Basis von IP eine fehlerfreie Punkt-zu-Punkt-Verbindung realisiert. Das heißt, dass ein eintreffendes Datenpaket jeweils auf Vollständigkeit kontrolliert und der Empfang beim Sender bestätigt wird. Kommt ein Datenpaket fehlerhaft oder gar nicht an, so wird der Sender veranlasst, das entsprechende Paket noch einmal zu senden und zwar solange, bis das Paket vollständig eingetroffen ist. Ein weiteres Protokoll oberhalb von IP ist das User Datagram Protocol (UDP). Anders als TCP ist UDP ein verbindungsloses Protokoll. Die Anwendung selber muss für den fehlerfreien und folgerichtigen Empfang der Datenpakete aufkommen. Per UDP versandte Datenpakete werden also nach dem Send-And-Forget-Prinzip versandt.

Vergleichend kann man feststellen, dass TCP also denkbar ungeeignet für Dienste ist, bei denen es nicht auf Vollständigkeit, dafür aber auf Kontinuität, ankommt, wie z.B. Video-Streaming. Ein einzelnes fehlendes Datenpaket fällt bei der Darstellung von Videoströmen nicht ins Gewicht. Genau diese Eigenschaften kann UDP abdecken. Geht es jedoch um die Übertragung von Dateien, so ist eine absolut zuverlässige Übertragung unerlässlich. Würde ein Datenpaket nicht ankommen und auch kein Ersatz ange-fordert werden, so wäre die Datei auf der Empfängerseite nicht mehr zu gebrauchen. Ein fehlendes oder fehlerhaftes Bit reicht dafür schon aus. Hier liegen die Stärken von TCP.

3.2.3 Hypertext Transport Protocol

Das Hypertext Transport Protocol (HTTP) ist die gemeinsame Sprache von WWW-Servern und -Clients, über die sie Dokumente austauschen und sich sonstige Nachrichten zuschicken. Über dieses Protokoll sollen Daten beliebigen Typs, zum Beispiel Text, Gra£k, Gra£ksequenzen oder Musik transportiert werden. Bei der Konzeption des HTTP-Protokolls galt es, zwei Ansätze miteinander zu verknüpfen. Zum einen sollte das Ausliefern von Dokumenten per HTTP für die Servermaschine nur eine minimale Belastung darstellen. Dies erreicht das Protokoll durch seine Zustandslosigkeit. Das bedeutet: Nach dem Übermitteln einer Datei an den WWW- Client geht der Server wieder in seinen Grundzustand zurück. Es gibt keine langandau-

KAPITEL 3. GRUNDLAGEN 10

ernden „HTTP-Sitzungen”, bei denen sich der Benutzer auf einem WWW-Server einloggt, durch das dort be£ndliche Informationsangebot surft und den Server anschließend wieder verlässt. Vielmehr wird für jedes einzelne zu übertragende Dokument eine separate Verbindung aufgebaut und nach der Datenübertragung wieder geschlossen. Nach dem Senden einer HTML-Datei, einer Inline-Gra£k oder einer sonstigen Datei geht der Server wieder in seinen Grundzustand zurück. Jede nachfolgende Anfrage an den WWW-Server hat keinen Bezug zur vorhergehenden Anfrage. Diese Zustandslosigkeit des Protokolls hat jedoch zur Folge, dass beispielsweise bei einem HTML-Dokument mit mehreren Inline-Bildern für jedes Bild eine neue Verbindung aufgebaut werden muss. Da der Verbindungsaufbau durchaus im Sekundenbereich liegen kann, widerspricht dies dem zweiten Ansatz der Konzeption des HTTP Protokollsder Geschwindigkeit. Um Geschwindigkeit dennoch garantieren zu können, soll es möglich sein, TCP-Verbindungen wiederverwenden zu können. Dabei gibt der Server eine bestehende TCP-Verbindung zum Client nicht sofort nach jeder Transaktion auf, sondern wickelt mögliche weitere Anforderungen desselben Clients über diese Verbindung ab. Das setzt natürlich voraus, dass der Client diese Funktion unterstützt. Durch diese Maßnahme sparen sich die Kommunikationspartner den Aufbau von neuen TCP-Verbindungen für jedes einzelne Dokument. 2

Die Kommunikation per HTTP lässt sich in vier grundlegende Abschnitte unterteilen: Verbindungsaufbau: Im ersten Schritt baut der Client zum Server eine

Request: Nach erfolgreichem Verbindungsaufbau sendet der

Response:

Verbindungsabbau: Nach Request und Response können sowohl der

Gerade aktuelle Version des HTTP Protokolls ist Version 1.1 ³ .

² vgl. [TRH96]

³ siehe auch [RJJ ⁺ 97]

KAPITEL 3. GRUNDLAGEN 11

3.2.4 Secure Socket Layer

Mit TCP/IP war der Wunsch nach sicheren Verbindungen im Sinne von Datensicherheit nicht zu verwirklichen. Jedoch ohne TCP/IP gibt es kein Internet. Die Firma Netscape löste das Problem auf folgende elegante Weise: Die Entwickler erweiterten TCP/IP um zwei weitere Schichten

• Secure Socket Layer Record Protocol

• Secure Socket Layer Handshake Protocol.

Sie liegen funktional zwischen dem Aufgabenbereich von TCP/IP und den Anwendungen. Diese beiden Schichten liegen bildlich betrachtet unmittelbar aufeinander und werden darum von einigen Autoren auch als eine einzige Schicht angesprochen. Beide sind für angrenzende Schichten transparent: Weder die Anwendung (beispielsweise ein Browser), noch die unter dem Secure Socket Layer (SSL) Protokoll liegende Transportschicht bemerken das Wirken des SLL-Protokolls. Das heißt, SSL erfordert weder massive Änderungen vorhandener Anwendungen noch neue Transportprotokolle. Während einer sicheren Verbindung kommunizieren die beteiligten Rechner ausschließlich über den Mechanismus, der von SSL bereit gestellt wird. Steht die sichere Verbindung nicht zur Verfügung, schaltet sich das SSL-Protokoll gleichsam aus. Der Verbindungsaufbau läuft in vier Schritten ab ⁴ :

⁴ vgl. [APP96]

KAPITEL 3. GRUNDLAGEN 12

1. In der sogenannten „HELLO-Phase” baut der Client eine Verbindung zum Server auf und teilt ihm mit, welche Kryptographie-Algorithmen er unterstützt. 2. Der Server wählt daraus ein Public-Key-, ein Privat-Key- und ein Hash-Verfahren aus und teilt sie dem Client mit. Gleichzeitig sendet der Server ein Zerti£kat, das unter anderem den öffentlichen Schlüssel des Servers enthält. (Mit Hilfe des Zerti£kats kann der Client überprüfen, ob die Antwort tatsächlich vom gewünschten Server stammt).

3. Der Client generiert einen Sitzungsschlüssel (Session key) für einen Datenaustausch per Private-Key-Verfahren. Aus Geschwindigkeitsgründen werden standardmäßig symmetrische Verfahren verwendet. Der dazu notwendige Schlüsselaustausch wird durch Verschlüsselung mit den in den Zerti£katen enthaltenen öffentlichen Schlüsseln geschützt. Diesen chiffrierten Schlüssel schickt der Client an den Server.

4. In der abschließenden Authenti£zierungsphase authenti£ziert der Client den Server, indem er ihm eine Reihe von mit dem Sitzungsschlüssel chiffrierten zufälligen Testnachrichten schickt, die der Server nur dann korrekt dechiffrieren und bestätigen kann, wenn es sich um den „echten” Server handelt. In einem optionalen Schritt kann der Server auf vergleichbare Weise den Client authenti£zieren. Die Client-Authenti£kation funktioniert nur dann, wenn der Client über ein of£ziell registriertes Zerti£kat verfügt.

Der Ablauf einer mittels SSL geschützten Verbindung soll am Beispiel des Secure HTTP (HTTPS) beschrieben werden. Durch die Initialisierung einer Verbindung über das HTTPS Protokoll (beispielsweise https://www.ud.com) wird der Browser veranlasst vom angesprochenen Server ein Zerti£kat und einen öffentlichen Schlüssel ab-zufordern. Dieser Schlüssel wird zusammen mit einer Prüfsumme und einer ID an den Browser zurückgemeldet. Diese Informationen werden von einigen wenigen Zerti£zierungs£rmen errechnet. Die bekannteste Firma ist VeriSign ⁵ . Der Browser prüft anhand der übermittelten Daten, ob er wirklich mit dem Server verbunden ist, der in der URL angegeben ist. In der folgenden Phase verständigen sich die beiden Rechner auf einen symmetrischen Schlüssel (Session Key). Da diese Absprache in asymmetrischer Verschlüsselung vollzogen wird, ist die Sicherheit gegeben. Der Browser schickt dem Server vor dem Beginn des eigentlichen Datenaustausches einige Testnachrichten, die der Server nur beantworten kann, wenn es wirklich der Server ist, der er zu sein vorgibt.

⁵ http://www.verisign.com