Kommunikationsprotokolle und schlanke Clients

3 Kommunikationsprotokolle und schlanke Clients 70 Netzwerkanbindung und Protokolle 79 Remote Desktop Protocol (RDP) 91 Die verschiedenen Arten von Clients 96 Terminaldiensteclients 112 Netzwerkplanung Eine Umgebung, die auf den Konzepten des Server-based Computing basiert, besteht nicht nur aus Terminalservern. Ebenso wichtig sind das zugehörige Netzwerk, die Kommunikationsprotokolle und die genutzten Clients. Das folgende Kapitel betrachtet daher diese Aspekte ein wenig genauer. b Werfen Sie einen Blick auf Anbindung von Terminalservern an existierende Netzwerke mit ihren verschiedenen Protokollen und Diensten. b Lernen Sie das Protokoll RDP zur Kommunikation zwischen Terminalservern und zugehörigen Clients kennen. b Betrachten Sie die Definitionen der verschiedenen Clienttypen, wie Windows-based Terminals, PCs im LAN oder Network Computer. b Erfahren Sie viele Details über die RDP-Clients, die mit dem Terminalserver ausgeliefert werden. Hierzu gehören Informationen zur Installation, Konfiguration und Benutzung sowie zu den Verbindungsoptionen der Clients zu einer Terminalserversitzung. b Planen Sie mithilfe einer strukturierten Einführung den Einsatz von Terminalservern und Terminaldiensteclients in verschiedenen Netzwerkumgebungen. Der Betrieb eines Terminalservers kann ohne Netzwerk nicht sinnvoll funktionieren. Jeder Terminalserverclient benötigt schließlich ein Netzwerk für den Zugriff auf das Mehrbenutzersystem. Auch für die Anbindung von weiteren Serverdiensten an die Terminalserverumgebung ist ein Netzwerk unerlässlich. Aus diesem Grund spielen Planung, Dimensionierung und Konfiguration der Netzwerkkomponenten wesentliche Rollen für das korrekte Funktionieren eines Terminalservers unter Windows Server 2003. Bevor ich in diesem Kapitel das Microsoft Remote Desktop Protocol (RDP) beschreibe, möchte ich zunächst eine kurze Einführung in die Grundlagen der gängigen Netzwerkmechanismen bei Windows-Servern geben. Erfahrene Netzwerkadministratoren können diesen ersten Teil über Netzwerkanbindung und Protokolle sicherlich überspringen und direkt zum Abschnitt mit den RDP-Funktionalitäten blättern. 69

Netzwerkanbindung und Protokolle Um das Thema Netzwerke besser zu strukturieren zu können, entwickelte die International Standardization Organization (ISO) 1977 ein so genanntes Referenzmodell für Open Systems Interconnection, das OSI-Referenzmodell. Das OSI-Modell gliedert sich in sieben wohl definierte Schichten, wobei die transportorientierten Funktionen in vier und die datenverarbeitungsorientierten Funktionen in drei darüber liegende Schichten unterteilt sind. Oftmals werden die datenverarbeitenden Schichten zur Vereinfachung auch zusammengefasst und dann Anwendungsschicht genannt. Die grundlegende Idee hinter einem Schichtenmodell ist, dass jede beteiligte Schicht einer darüber liegenden Schicht bestimmte Dienste anbietet. Damit schirmt sie die höheren Schichten von Details ab, wie die betreffenden Dienste realisiert sind. Zwischen einem Paar übereinander liegender Schichten liegt eine Schnittstelle, die jeweils definierte Operationen erlaubt und Dienste anbietet. Auch moderne Protokolle werden noch immer in Bezug zu diesen bewährten Modellen betrachtet auch wenn sie nicht in fünf oder sieben Schichten implementiert wurden. Dies erlaubt jedoch einen Vergleich und eine Abgrenzung zu anderen Protokollen. In diesem Buch unterscheide ich die verwendeten Protokolle in zwei grundsätzlich Kategorien, die sich vom OSI-Modell ableiten. Beide Kategorien spielen für den Betrieb eines Terminalserver eine wesentliche Rolle: b Transportprotokolle Konventionen zur Behandlung und Wandlung von Datenströmen, sodass sie über ein physisches Netzwerkkabel, eine Glasfaser oder ein Funknetz zwischen Computern ausgetauscht werden können. Dies entspricht den transportorientierten Funktionen des OSI- Modells. Beispiele für solche Transportprotokolle sind TCP/IP, IPX/SPX oder NetBEUI. b Kommunikationsprotokolle Kodierung von Funktionsaufrufen für bestimmte Aufgaben, die auf einem entfernten Computer ausgeführt werden sollen. Dies entspricht einem Teil der Funktionen, wie sie der oben vorgestellten Anwendungsschicht des OSI-Modells zugeschrieben werden können. Hierzu gehören die Methoden zur Interprozesskommunikation sowie die Terminalserverprotokolle Microsoft RDP und Citrix ICA. Auch das X11-Protokoll, das zumeist unter unix-betriebssystemen für den entfernten Zugriff auf Anwendungen genutzt werden kann, fällt unter diese Kategorie. Terminalserver in einem Netzwerk unterstützen potenziell mehrere Transport- und Kommunikationsprotokolle parallel. Daher ist es wichtig zu wissen, welche Protokolle mit den zugehörigen Kommunikationsmechanismen existieren und für welchen Zweck sie eingesetzt werden. Bei Bedarf können jederzeit fehlende Protokolle nachinstalliert oder überflüssige Protokolle deinstalliert werden, um Anpassungen an eine sich ändernde Netzwerkumgebung durchführen zu können. Die oben aufgeführten Kommunikationsprotokolle für den Terminalserver werden in diesem Buch jeweils ausführlich eingeführt und beschrieben. Daher sollen im Folgenden nur die Transportprotokolle und die Möglichkeiten zur Interprozesskommunikation kurz beleuchtet werden. Transportprotokolle Ein Transportprotokoll bezieht sich die unteren vier Schichten des OSI-Modells, d.h. auf die transportorientierten Funktionen. Dazu gehören insbesondere die Suche nach dem richtigen Weg zum Zielcomputer, die Anpassung eines Datenpaketformats beim Übergang in ein anderes Netzwerk sowie die Bereitstellung einer Ende-zu-Ende-Verbindung zwischen zwei oder mehreren Kommunikationspartnern. 70 Kapitel 3

TCP/IP Das Transportprotokoll TCP/IP hat sich seit über zehn Jahren als Standard etabliert und ist daher auch von zentraler Bedeutung für Windows Server 2003 im Allgemeinen und einen Terminalserver im Speziellen. Es ist zumeist die Basis für die Verbindung zu Terminalserverclients über die verschiedenen möglichen Kommunikationsprotokolle. TCP/IP besteht aus einem Satz an beteiligten Unterprotokollen, die in einem Schichtenmodell angeordnet sind. Die Kommunikation kann dabei verbindungsorientiert (TCP) oder verbindungslos (UDP) sein. Abbildung 3.1: Konfiguration der TCP/IP-Adresse Die Konfiguration des TCP/IP-Protokolls erfolgt auf Windows Server 2003 in der Systemsteuerung. Dort steht das Symbol Netzwerkverbindungen zur Verfügung, über das Sie als Administrator die Eigenschaften der LAN-Verbindung und damit auch des TCP/IP-Protokolls einstellen können. NWLink und IPX/SPX Ab Windows NT 3.5x wurde das NWLink-Protokoll eingeführt, ein NetWare-kompatibles Protokoll. Es ist entspricht Novells IPX/SPX und kann in einem Netzwerk genauso wie TCP/IP den Transport der Daten übernehmen. Zusatzprodukte zu Windows Server 2003 erlauben die Verwendung von IPX/SPX als Alternative zu TCP/IP für die Kommunikation zwischen den Terminaldiensten und den speziell angepassten Clients. Die Installation des NWLink-Protokolls auf Windows Server 2003 geschieht über die Eigenschaften einer LAN-Verbindung. Über die Schaltfläche Installieren... gelangt man in den Auswahldialog für eine neue Netzwerkkomponente. Dort ist es möglich das neue Protokoll NWLink IPX/SPX/Net- BIOS-kompatibles Transportprotokoll auszuwählen. Kommunikationsprotokolle und schlanke Clients 71

In der 64-Bit-Version von Windows Server 2003 wird das NWLink-Protokoll nicht mehr unterstützt. Dies ist für das Microsoft Remote Desktop Protocol zur Anbindung von Terminalservern unproblematisch, da es das NWLink-Protokoll als Transportmedium nicht nutzen kann. NetBEUI Das ehemals von Microsoft und IBM in ihren Netzwerkbetriebssystemen eingesetzte Standardprotokoll war NetBEUI (NetBIOS Enhanced User Interface). Es wurde in der Vergangenheit von Windows 2000, Windows NT, Windows 98 und auch von OS/2 unterstützt, erlaubte jedoch kein Routing im Netzwerk. Andererseits war es sehr einfach zu installieren und zu verwalten. Vor dem Durchbruch von TCP/IP stellte NetBEUI das Protokoll dar, das insbesondere in kleineren Netzwerken bevorzugt eingesetzt wurde. Mit Windows Server 2003 wurde die Unterstützung von NetBEUI eingestellt, es ist auf dem System nicht mehr vorhanden. HINWEIS: Ausgangspunkt für die Entwicklung von NetBEUI war die NetBIOS-Schnittstelle. (Network Basic Input/Output System). NetBIOS-Anwendungen sind jedoch nicht auf das NetBEUI- Protokoll angewiesen, sondern können auch über TCP/IP oder IPX/SPX betrieben werden. Interprozesskommunikation In einer verteilten Umgebung müssen die Daten zwischen verschiedenen Server- und Client-Komponenten bidirektional ausgetauscht werden. Hierfür existieren unter Windows Server 2003 neun Möglichkeiten: Named Pipes, Mailslots, Windows Sockets, Remote Procedure Calls, NetBIOS, NetDDE, Server Message Blocks, DCOM (COM+) und SOAP. Auch wenn einige dieser Möglichkeiten schon recht betagt sind, spielen sie oftmals sogar für die Terminaldienste von Windows Server 2003 noch eine wichtige Rolle. Der Grund liegt in den manchmal historischen Windowsanwendungen, die auch noch auf einem modernen Terminalserver bereitgestellt werden müssen. Insbesondere in großen Unternehmen, die möglicherweise viele selbst entwickelte, unternehmenskritische Anwendungen über einen langen Zeitraum unterstützen müssen, ist die Funktionsfähigkeit möglichst vieler gängigen Methoden zur Interprozesskommunikation essenziell. Aus diesem Grund werden im Folgenden die wichtigsten Methoden beschrieben (außer Named Pipes, Mailslots und NetDDE): Windows Sockets Die Windows Socket-Schnittstelle erlaubt die Kommunikation zwischen verteilten Anwendungen über Protokolle mit unterschiedlichen Adressierungssystemen. Momentan werden TCP/IP sowie NWLink (IPX/SPX) von den Windows Sockets unterstützt. Ursprünglich wurden sie von den Berkeley Sockets abgeleitet, einer Standardschnittstelle zur Entwicklung von Client/Server-Anwendungen unter unix und vielen anderer Plattformen. WICHTIG: Die Kommunikation eines Terminalservers mit seinen Clients erfolgt über Windows Sockets und nicht über den Server-Dienst. Remote Procedure Calls Das Konzept der Remote Procedure Calls (RPCs) wurde ursprünglich von Sun Microsystems entwickelt, um Prozesse so auf einem entfernten Rechner aufzurufen, als würden sie lokal ausgeführt. Die Entwickler sollten sich nicht um Details für die Netzwerkkommunikation kümmern müssen, so wie dies z.b. bei den Windows Sockets notwendig ist. RPCs setzen daher verschiedene Basismethoden wie Windows Sockets ein und kapseln die eigentliche Kommunikation in einem einfacheren Schema. 72 Kapitel 3

Auf Windows Server 2003 spielen Remote Procedure Calls und ihre lokale Variante Local Procedure Calls eine sehr wichtige Rolle. Sie laufen jedoch zumeist versteckt im Hintergrund ab und bieten zumeist nur indirekte Einflussmöglichkeiten für einen Administrator. Höhere Dienste zur Interprozesskommunikation nutzen jedoch die RPCs sehr oft. NetBIOS Die NetBIOS-Schnittstelle wird schon seit Anfang der Achtzigerjahre zur Entwicklung von verteilten Anwendungen verwendet. Die Kommunikation von NetBIOS-Anwendungen kann über verschiedene Protokolle erfolgen: b NetBIOS over TCP/IP NetBT Kommunikation auf der Basis des TCP/IP-Protokolls. b NWLink NetBIOS NWNBLink Kommunikation auf der Basis des IPX/SPX-Protokolls. Die NetBIOS-Schnittstelle besteht aus weniger als 20 einfachen Befehlen, die für den Datenaustausch sorgen. Insbesondere werden über NetBIOS die Anfrage- und Antwortfunktionalitäten zwischen Client- und Serverkomponenten realisiert. Dies gilt auch noch für Windows Server 2003. Aus diesem Grund ist die nahtlose Unterstützung von NetBIOS-Funktionalitäten auf einem Terminalserver insbesondere für ältere Anwendungen wichtig, da diese zumeist nicht aktuellen entsprechend Internet-Standards entwickelt wurden. Ressourcen werden für die NetBIOS-Schnittstelle mit Hilfe ihrer UNC-Namen (Universal Naming Convention) identifiziert, die das Format\\Computer\Freigabe haben. Auf freigegebene Ressourcen wie Dateien, Ordner und Drucker erfolgt nun der Zugriff über diese Namen. WICHTIG: Der NetBIOS-Name (auch bekannt als»microsoft-rechnername«) muss nicht zwingend identisch mit einem eventuell auf demselben Computer vorhandenen TCP/IP-Namen (auch bekannt als»tcp/ip-hostnamen«oder»dns-namen«) sein. Es ist jedoch definitiv nicht empfehlenswert, unterschiedliche Konventionen für die beiden Namensdienste zu verwenden. Dies führt in der Regel zur Verwirrung von Benutzern und Administratoren. Seit Windows 2000 wurde der Unterschied zwischen den beiden Namensräumen jedoch fast vollständig aufgehoben. CIFS und SMB Das Common Internet File System dient dem Fernzugriff von PCs unter einem Windows-Betriebssystem auf das Dateisystem eines anderen Computers. Der zugrunde liegende Mechanismus ist seit den frühen Achtzigerjahren besser unter dem Namen Server Message Blocks (SMB) bekannt. Die Funktionalitäten der SMBs umfassen insbesondere Sitzungssteuerung, Dateizugriffe, Druckerkontrolle und Nachrichtenmeldungen. Hierbei werden Gruppen von Aufrufen an die NetBIOS-Schnittstelle zu Blöcken zusammengefasst und an einen Zielcomputer geschickt. Erst die Ratifizierung der SMBs als offener X/Open-Standard unter dem Namen CIFS eröffnete diesem Konzept die Akzeptanz auf einer breiteren Basis. Seit 1996 fördert Microsoft die Verbreitung von CIFS aktiv durch offizielle Spezifikationen und Veröffentlichungen. Das CIFS stellt seine Daten Benutzern zur Verfügung, nicht Computern, wie dies bei anderen Dateisystemen der Fall ist. Die Authentifizierung des Benutzers wird dabei auf dem Server durchgeführt und nicht auf dem Client. Hierbei können auch spezielle netzwerkweite Authentifizierungs-Server eingesetzt werden (z.b. Domänencontroller). HINWEIS: Auf einem Terminalserver werden die SMB-Funktionalitäten oftmals zur Anbindung der Basisverzeichnisse für Benutzer und zur Ausgabe von Dokumenten auf Netzwerkdruckern genutzt. Kommunikationsprotokolle und schlanke Clients 73

DCOM und COM+ Die Basisidee einer verteilten Umgebung ist die Entwicklung von Anwendungen und Diensten nach dem Komponentenprinzip. Dies resultiert in einem Aufbrechen von monolithisch angelegten Anwendungen. Wird dieses Prinzip konsequent verfolgt, führt es zu einer Aufteilung in kleine, eigenständige, wiederverwendbare und in sich abgeschlossene Einheiten. Vor der Einführung der.net-strategie wurde eine solche Vorgehensweise durch die Verwendung des Component Object Models (COM) ermöglicht. Mit seiner Hilfe war es möglich, binäre Software-Komponenten zu erstellen und die Kommunikation zwischen mehreren dieser Komponenten zu vereinheitlichen. Ein Entwickler konnte eine Anwendung dann durch Wiederverwendung bestimmter Komponenten nach dem Baukastenprinzip zusammenstellen. Eine»Middleware«wie COM schirmt den Entwickler von Details der Kommunikationsmechanismen ab, ermöglicht die Nutzung vertrauter Techniken und bietet ein einheitliches Application Programming Interface (API). Die Middleware bildet daher eine Abstraktionsschicht zwischen der Anwendung sowie dem Betriebssystem und erlaubt die Kommunikation der Module einer verteilten Anwendung. Die COM-Komponenten werden bei ihrer Installation jedoch direkt im Betriebssystem verankert. Auf diese Weise stehen sie zwar jeder Applikation mit definierten Schnittstellen zur Verfügung und können frei verwendet werden. Problematisch ist hierbei jedoch, dass eine Anwendung unter Umständen nicht mehr funktioniert oder nur stark eingeschränkte Funktionalität besitzt, wenn die benötigten COM-Komponenten nicht (mehr) auf dem System installiert sind. COM ist heute noch weit verbreitet, es dient bereits seit Jahren als Basis für das historische Object Linking and Embedding (OLE) und für die ActiveX-Technologie. Erweitert wurde es noch durch Distributed COM (DCOM), den zugehörigen Standard für die Kommunikation über Computergrenzen Die gesamte Strategie für verteilte Anwendungen basierte vor der Einführung des.net-frameworks auf dem DCOM-Modell und seinem Nachfolger COM+. Heute werden diese Funktionalitäten unter dem Begriff Microsoft Component Services zusammengefasst. Die zugehörigen Konzepte finden sich daher auch in der einen oder anderen Ausprägung in einer Vielzahl von etablierten Softwareprodukten. Auf einem Terminalserver stellt das DCOM-Modell erhöhte Ansprüche an die zugrunde liegende Systemarchitektur. Verschiedene Benutzer kommunizieren mit ihren Anwendungen ggf. über DCOM. Die sichere Zuordnung aller Kommunikationskanäle zu ihren jeweiligen Benutzersitzungen wird jedoch auf Windows Server 2003 jederzeit gewährleistet. SOAP Das Simple Object Access Protocol (SOAP) ist ein XML-basiertes Protokoll, um in einer dezentralisierten und verteilten Umgebung Informationen auszutauschen. Es besteht im Wesentlichen aus zwei Kernkomponenten: Einem Umschlag zur Unterstützung von Erweiterungen und Modularitätsanforderungen sowie einem Kodierungsmechanismus zur Verwaltung von Daten innerhalb des Umschlags. Es erfordert nicht die synchrone Ausführung oder eine direkte Interaktion auf der Basis von Anfrage/ Antwort-Mechanismen. Vielmehr können verschiedene Protokolle eingesetzt werden, die zumeist einer Kommunikation zwischen verteilten Softwarekomponenten dienen. SOAP ist eines der Basiselemente der.net-strategie und spielt damit auch eine dominante Rolle für Windows Server 2003. 74 Kapitel 3

Namensvergabe und Namensauflösung Wie erhalten Computer ihren eindeutigen Namen? Wie finden sie sich im Netzwerk? Wie ermittelt ein Benutzer in einem Netzwerk die für ihn benötigten Ressourcen? Wie kommuniziert ein Terminalserver mit anderen Computern eines Netzwerks? Diese Probleme werden durch verschiedene Konzepte gelöst, die alle auf der Vergabe von logischen Namen für die einzelnen Computer und Ressourcen basieren. Im Laufe der Entwicklung von TCP/IP haben sich zwei Techniken entwickelt, wie die Auflösung von logischen TCP/IP-Namen zu IP-Adressen durchgeführt wird. b Hosts-Datei Diese Datei, die auf jedem Computer vorhanden sein muss, enthält eine einfache zeilenweise Auflistung in der Form Computername IP-Adresse. Da bei einer Änderung (z.b. ein neuer Rechner wird installiert) diese Tabelle für jeden Computer aktualisiert werden muss, ist diese Form der Namensauflösung zeit- und arbeitsintensiv sowie fehlerträchtig. b DNS (Domain Name Service) Auf einem zentralen Namensserver wird eine Datenbank von TCP/IP-Namen und zugehörigen IP-Adressen vorgehalten. Clients oder auch entsprechend konfigurierte Server fragen bei diesem Namensserver nach der IP-Adresse eines bestimmten TCP/IP- Namens, die daraufhin geliefert wird. HINWEIS: Auch für NetBIOS-Namen werden entsprechende Mechanismen zur Namensauflösung bereitgestellt: die LAN Manager Hosts-Datei Lmhosts oder der Windows Internet Name Service WINS. In der heutigen Zeit sind die zugehörigen Methoden jedoch nicht mehr gebräuchlich. Domain Name Service Programme und Benutzer referenzieren Computer und andere Ressourcen äußerst selten über binäre Netzwerkadressen. Stattdessen finden logische ASCII-Zeichenketten viel öfter Verwendung, wie z.b.»www.microsoft.com«. Dennoch versteht ein Computer im Netzwerk ausschließlich Adressen wie»192.44.2.1«. Daher werden Mechanismen zur Konvertierung der einen Konvention in die andere benötigt. Dies gilt ganz besonders bei der Anbindung von Clients an ihre Terminalserver. Ganz zu Anfang des Internet-Vorgängers DARPANET genügte dafür eine einfache ASCII-Datei, die alle Rechnernamen und IP-Adressen auflistete. Nachdem jedoch viele Tausende Computer im Internet miteinander verbunden waren, erwies sich dieses Vorgehen als nicht weiter tragfähig. Insbesondere die wachsende Größe der Datei und die Namenskonflikte bei der Einbindung neuer Rechner erforderte die Entwicklung eines neuen Konzepts, woraus das»domain Name Systems«(DNS) entstand. Die Essenz von DNS ist die Einführung eines hierarchischen, domänebasierten Namensschemas und eines verteilten Datenbanksystems für die Implementierung dieses Namensschemas. Es wird primär für die Abbildung (Mapping) von Rechnernamen auf IP-Adressen verwendet. DNS kann jedoch bei entsprechender Konfiguration auch die Abbildung in umgekehrter Richtung vornehmen, wobei eine vorgegebene IP-Adresse ihrem logischen Namen zugeordnet wird (Reverse Lookup). Ein weltweit registrierter Rechnername nennt sich vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN). Kommunikationsprotokolle und schlanke Clients 75

Abbildung 3.2: Namensauflösung über DNS Eine Domäne kennzeichnet in diesem Zusammenhang eine logische Struktur von Rechnern. Innerhalb einer Domäne kann es dabei Subdomänen geben, die für eine Strukturierung umfangreicher Netzwerke eingesetzt werden. Beim Betrieb einer eigenen Domäne ist ihr Besitzer auch für deren Verwaltung über einen»domain Name Server«verantwortlich. Bei sehr umfangreichen Netzwerken findet eine weitere Unterteilung in Zonen statt. Eine Zone definiert dabei, welche Internetnamen physisch in einer bestimmten Zonendatei verwaltet werden. Ein DNS-Server kann eine oder mehrere Zonen verwalten. Hierbei enthält eine Zone nicht zwingend alle Subdomänen einer Domäne. Eine größere Domäne kann daher in mehrere Zonen aufgeteilt werden, die getrennt verwaltet werden. Alle Änderungen an einer Zone werden an einem zugeordneten DNS- Server vorgenommen. Die meisten Netzwerkkonzepte einschließlich der Active Directory Services unter Windows Server 2003 basieren auf DNS. Eine Erweiterung dient der Möglichkeit, die neue Zuordnung von IP-Adressen zu logischen Computernamen automatisch zur Laufzeit durchzuführen und zu registrieren. Dieses»Dynamic DNS«wird vor allem in Kombination mit DHCP eingesetzt. WICHTIG: Die zufrieden stellende Funktion eines Terminalservers und seiner Clients ist in der Regel hochgradig abhängig von einer adäquaten DNS-Infrastruktur. Hierbei ist oftmals nicht unbedingt die Plattform des DNS-Servers ausschlaggebend, sondern seine korrekte Konfiguration. 76 Kapitel 3

DHCP Da IP-Adressen eindeutig sein müssen, können sie von einem Administrator nicht völlig frei vergeben werden. Die Verwaltung der Adressvergabe für Terminalserver-Clients in einem Unternehmensnetzwerk kann daher recht personal- und zeitaufwändig sein. Aus diesem Grund wird in Umgebungen mit einem Terminalserver oftmals das Dynamic Host Configuration Protocol (DHCP) eingesetzt. Es ist ein einfaches Verfahren, um Computer in TCP/IP-Netzwerken dynamisch von einem entfernten Ort aus zu konfigurieren. Hierbei bietet DHCP bei jeder Anmeldung zum einen die Zuordnung von fest vorgegebenen IP-Adressen und zum anderen die Vergabe von IP-Adressen aus einem Pool. Für das erfolgreiche Senden und Empfangen von TCP/IP-Datenpaketen zwischen zwei Computern ist die Angabe von drei Werten von zentraler Bedeutung: b IP-Adresse Eindeutige Identifikation des Geräts im Netzwerk, z.b. 192.168.1.2. b Subnetzmaske Bitmuster, das zur Unterscheidung von Netzwerk-ID und Host-ID innerhalb der IP-Adresse dient, z.b. 255.255.255.0. b Standard-Gateway Router, an den ein Datenpaket geschickt wird, wenn der Zielrechner nicht im gleichen Subnetz wie der Quellrechner liegt. Der Router leitet das Datenpaket über Routing- Tabellen zu seinem Ziel weiter. Wie kann nun ein Client, der diese Werte nicht besitzt, über das Netzwerk konfiguriert werden? Der Client schickt einen Rundruf (Broadcast) über das Netzwerk, der wie alle TCP/IP-Pakete die MAC- Adresse seiner Netzwerkkarte beinhaltet. Dieser Broadcast wird von einem oder mehreren DHCP- Servern aufgefangen. Einer oder mehrere der Server schicken dem anfragenden Client eine Mitteilung, dass sie grundsätzlich IP-Konfigurationsdaten zur Verfügung stellen können. Der Client sendet daraufhin einen Broadcast mit der Anfrage nach den gewünschten Konfigurationsdaten auf das Netzwerk. Diese Anfrage enthält dabei die Adresse des Servers, der zuerst geantwortet hat. Hierdurch werden andere Server davon abgehalten, auch Konfigurationsdaten zu schicken. Der Client erhält die Daten vom gewählten Server, bestätigt ihre Ankunft und konfiguriert sich zur Laufzeit. Die Datenmenge, die bei diesen Aktionen ausgetauscht wird, liegt im Bereich von unter 2 KB. In der Regel dauert die Kommunikation weniger als eine Sekunde. Die DHCP-Konfigurationswerte werden einem Client normalerweise nicht für immer zugewiesen, sondern nur für eine bestimmte Zeit. Dies ermöglicht die Vergabe von IP-Adressen aus einem Pool, der kleiner sein kann als die potenzielle Anzahl an Clientcomputern. Ist ein Client nach der Hälfte der Vergabezeit noch aktiv im Netzwerk, kann er eine Verlängerung beim DHCP-Server beantragen. Ist der ursprüngliche DHCP-Server nicht erreichbar, versucht der Client nach Ablauf von 87,5% der maximalen Vergabezeit einen anderen DHCP-Server zu kontaktieren. Haben sich die Konfigurationswerte für eine IP-Adresse seit der letzten Vergabe an einen Client geändert, so kann der DHCP-Server die Verlängerung der Vergabe verweigern. Er fordert vielmehr den Client auf, die Adresse freizugeben und neue Informationen für seine Konfiguration abzurufen. Hiermit können Konfigurationsänderungen in einem ganzen Netzwerk durchgeführt werden, ohne die Clients vor Ort zu modifizieren. Der Verwaltungsaufwand für Clients sinkt dadurch stark. Das Umkonfigurieren aller aktiven DHCP-Clients in einem Unternehmensnetzwerk kann somit bei Bedarf innerhalb einer vorbestimmten Zeit aus der Ferne geschehen. Dies ist ganz besonders für Umgebungen mit Terminalservern sinnvoll, da dies den Wartungsaufwand ihrer Clients deutlich minimiert. Die Implementierung des dynamischen DNS-Konzepts unter Windows Server 2003 kann in Kombination mit dem DHCP-Dienst genutzt werden. Damit wird nach der Vergabe einer IP-Adresszuordnung durch den DHCP-Server diese Information an den DNS-Server weitergegeben. Die Eintragung in die dortige Datenbank findet dann automatisch statt. Damit ist keinerlei manuelle Konfiguration der Namensauflösung mehr nötig. Dies findet insbesondere für die Clients von Terminalservern seinen Einsatz. Kommunikationsprotokolle und schlanke Clients 77

Routing Das IP-Schema für Netzwerkadressen ermöglicht die Vergabe einer Identifikation für jeden angebundenen Computer. Für die Wegesteuerung in einem Netzwerk wird jedoch noch eine zweite Identifikation genutzt, die MAC-Adresse. Diese weltweit eindeutige und damit unverwechselbare Adresse ist in der Regel durch die Hardware des Netzadapters vorgegeben. Der Weg von einem Terminalserver im Netzwerk zu einem weit entfernten Client wird durch den Begriff Routing beschrieben. Hierfür werden entweder Tabellen auf einem Host oder aber Router als spezielle Netzwerkkomponenten verwendet. Router können IP-Subnetze verbinden, mehrere Protokolle verwenden und Datenpakete zu ihren Zielsubnetzen (z.b. einem Heimarbeitsplatz oder einem entfernten Terminalserver) weiterleiten. Hierbei unterstützt ein Router nur Pakete mit einer spezifischen Zieladresse. Die Routing-Tabellen können manuell vordefiniert oder dynamisch zur Laufzeit erstellt werden. Dynamische Router nutzen für diese Aufgabe eine Reihe von standardisierten Protokollen für unterschiedliche Anforderungen. Die Router-Komponenten enthalten im einfachsten Fall eine Tabelle mit IP-Adressen von Teilnetzen und Informationen, wie Pakete dieser Teilnetze weitergeleitet werden sollen. Hiermit werden Rundrufe (=Broadcasts), die das Netzwerk zu stark belasten könnten, beim Übergang von einem Subnetz (=Segment) in das andere herausgefiltert. Abbildung 3.3: Drei Router, die vier Netzwerksegmente voneinander trennen. Rundrufe (Broadcasts) werden an den Routern gefiltert Ein Datenpaket, das einen Router passiert, kann also b an ein lokales Netzwerk weitergeleitet werden, wenn es zu diesem Subnetz gehört. b über einen anderen Netzwerkadapter an ein anderes Netzwerk weitergeleitet werden, in dem wiederum ein Router steht. b am Router abgewiesen werden, wenn dieser keine Informationen besitzt, wie dieses Paket weiter verschickt werden soll. Weiterhin können viele Router so konfiguriert werden, dass sie entgegen ihrer eigentlichen Aufgabe auf bestimmten TCP/IP-Ports auch Rundrufe zulassen. Damit können eine Reihe von Funktionalitäten, die auf Rundrufen basieren, auch in einem großen, strukturierten Netzwerk genutzt werden (z.b. DHCP). WICHTIG: Das gezielte Öffnen von TCP/IP-Ports auf Routern sollte nur innerhalb von Intranets durchgeführt werden, die durch eine Firewall ausreichend geschützt sind. Andernfalls besteht die erhöhte Gefahr von unberechtigten Zugriffen aus dem Internet. 78 Kapitel 3

Speziell für den Einsatz eines Terminalservers in großen lokalen Netzwerken oder über Weitverkehrsstrecken ist daher die korrekte Konfiguration der Router von zentraler Bedeutung. So entscheiden die Einstellungen eines ISDN-Routers stark über die Leistungsfähigkeit des Netzwerks und die bereitgestellten Dienste für einen angebundenen Heimarbeitsplatz. Dabei können jedoch Kommunikationswege, die über zu viele Router-Komponenten geleitet werden, zu Problemen mit Zeitlimits (Timeouts) führen. Remote Desktop Protocol (RDP) Für die Kommunikation zwischen Terminalservern und ihren Clients unter einem Windows-Betriebssystem entwickelte Microsoft ab Mai 1997 auf der Basis von ITU-Standards ein Protokoll, das den Namen RDP trägt (Remote Desktop Protocol). RDP basiert dabei auf den Standards der Protokollfamilie T.120, speziell auf T.125 Multipoint Communication Service Protocol Secification (MCS) und T.128 Application Sharing der International Telecommunication Union (ITU). RDP ist zudem stark an jenen Kommunikationsmechanismen ausgerichtet, die auch schon für den Datenaustausch unter Microsoft NetMeeting zum Einsatz kamen. Als Clients können eine Reihe von Geräten eingesetzt werden, die hauptsächlich ein Ausgabemedium, Maus und Tastatur zur Verfügung stellen müssen. Zudem besteht die Anforderung, dass sie über das Netzwerk auf der Basis von RDP kommunizieren können. Weitere Intelligenz wird auf der Client-Seite nicht benötigt. Die momentan verfügbaren Microsoft RDP-Clients beschränken sich auf Windows CE, die 32-Bit- und 64-Bit-Windows-Betriebssysteme, ein ActiveX-Kontrollelement für den Internet Explorer und Apple Mac OS X. Abbildung 3.4: Die Einbindung des RDP-Protokolls in Windows Server 2003 Kommunikationsprotokolle und schlanke Clients 79

RDP-Architektur Das RDP-Protokoll erlaubt die Kommunikation über bis zu 64.000 Kanäle. Dabei wird der Bildschirm als Rastergrafik (Bitmap) vom Server zum Client oder zum Terminal übertragen. Der Client übermittelt auf der anderen Seite die Tastatur- und Mausinteraktionen zum Server. Die Kommunikation verläuft dabei stark asymmetrisch. Der deutlich größere Teil der Daten wird vom Server zum Client übertragen. RDP wurde ehemals mit dem Ziel entworfen, um verschiedene Netzwerktopologien zu unterstützen. Es kann in seiner derzeitigen Ausprägung jedoch nur über TCP/IP-Netzwerke ausgeführt werden und ist intern in mehrere Schichten aufgeteilt. Dies lässt sich auf der untersten Ebene dadurch erklären, dass die zugrunde liegende T.120 Protokollfamilie auf einige recht aufwändige Spezifikationen des ISO-Modells optimiert war. Hierbei handelt es sich insbesondere um Mechanismen für die Dienstegüte. Da sich diese nicht auf das TCP/IP-Protokoll abbilden lassen, muss eine X.224-kompatible Adaptionsschicht für die Abbildung der spezifizierten Diensteprimitive der ISO-Schicht auf die Diensteprimitive des TCP/IP-Protokolls sorgen. Grundsätzlich werden in dieser Ebene nur vier Dienstprimitive benötigt, drei davon dienen der Verbindungsverwaltung: Verbindungsaufbauanfrage, Verbindungsbestätigung und Verbindungsabbauanfrage. Verbindungsaufbau und Verbindungsabbau gehen dabei vom Client aus. Sollte der Server die Verbindung beenden, wird dies dem Client nicht gesondert mitgeteilt. Die Implementierung des Clients muss in diesem Fall durch eine entsprechende Ausnahmebehandlung für ein definiertes Verhalten sorgen. Das vierte Dienstprimitiv dient der Übertragung von Daten. Eine darüber liegende Schicht sorgt für die Bereitstellung von Multicast-Diensten. Diese erlauben nicht nur eine Punkt-zu-Punkt-Verbindung, sondern auch eine Punkt-zu-Multipunkt-Verbindung. Nur so lassen sich Funktionalitäten mit mehreren Endpunkten realisieren, z.b. die Remoteüberwachung. Eine spezielle Sicherheitsschicht umfasst alle Dienste im Hinblick auf Verschlüsselung und Signatur. Diese sorgen dafür, dass die RDP-Verbindung nicht unberechtigt abgehört und der übertragene Datenstrom nicht modifiziert werden kann. Für die Verschlüsselung wird der RC4-Algorithmus der RSA Inc. eingesetzt. Die Manipulation der Daten wird durch eine Signatur ausgeschlossen, die aus einer Kombination der Algorithmen MD5 und SHA-1 besteht. Zudem verwaltet die Sicherheitsschicht die Übertragung der Benutzerauthentifizierung und der zugehörigen Lizenzen. Die eigentlich relevante Schicht sorgt für die Übertragung von Maus- und Tastatureingaben sowie Bildschirmausgaben. Dieser Mechanismus ist dabei recht aufwändig gestaltet. Er sorgt für das Aushandeln der genutzten Operationen während dem Verbindungsaufbau. Auch die Informationen zur Zwischenspeicherung (Caching) gewisser Daten wird hier verwaltet, was für die Reduktion der Netzwerklast sorgt. Im Laufe seiner bisherigen Entwicklung wurde das RDP-Protokoll immer weiter speziell für Windows NT, Windows 2000, Windows XP sowie Windows Server 2003 und deren Anwendungen angepasst. Viele Erweiterungen des Protokolls betreffen die spezifische Art dieser Umgebung. Die Daten werden dabei von einem Ausgangsprogramm über den RDP-Protokoll-Stack an den TCP/IP- Protokoll-Stack weitergegeben. Hierzu werden sie über das oben beschriebene Schichtenmodell in einen Kanal geleitet, verschlüsselt, in Abschnitte definierter Länge zerschnitten, an das Netzwerkprotokoll angepasst, mit einer Adresse versehen und abgeschickt. Auf der Empfangsseite läuft dieser Prozess wieder in umgekehrter Reihenfolge ab, um die Daten dann für das Zielprogramm verfügbar zu machen. Hier werden auch die Lizenzierungsmodalitäten überwacht und die Auswahl der Verschlüsselungsmethoden durchgeführt. Zusätzliche Dienste sorgen für die protokollspezifischen Anpassungen im Benutzermodus. 80 Kapitel 3

Die Terminaldienste unter Windows Server 2003 spielen dabei eine Rolle, die unabhängig vom RDP- Protokoll ist. Grundsätzlich ist das Protokoll austauschbar, die Terminaldienste stellen eine flexible Plattform für einen Mehrbenutzermodus zur Verfügung. Dies erlaubt es auch anderen Herstellern alternative Protokolle zu entwickeln, die auf sämtliche Funktionalitäten der Terminaldienste zurückgreifen. Die Bereitstellung der restlichen Laufzeitumgebung zur Erzeugung des RDP-Datenstroms wird aus Gründen der höheren Leistungsfähigkeit auf einen Kernel-Treiber verlegt (siehe auch : Kapitel 1). Dieser ist wiederum unterteilt in einen Anteil für das Transportprotokoll (TCP/IP) und in einen Anteil für das sitzungsspezifische Kommunikationsprotokoll (RDP). Letzteres wird vom Termdd- Treiber durchgeführt, der die Maus- und Tastatureingaben von den entfernten Clients an den Kernel weiterreicht. Fähigkeiten von RDP Ein Terminalserver weiß nicht, welche Art von Client als Nächstes Kontakt zu ihm aufnehmen möchte. Daher müssen bei einem Verbindungsaufbau alle Parameter übertragen werden, die den Client eindeutig charakterisieren und seine Funktionalitäten beschreiben. Dies geschieht über einen Satz von vordefinierten Fähigkeiten. Die Kenntnis der Clientfähigkeiten erlauben es einem Terminalserver, flexibel auf die Anforderungen eines Clients reagieren zu können. Hierbei sind die Fähigkeiten in mehrere Gruppen aufgeteilt: b Generelle Fähigkeiten Verwendete Clientplattform, verwendetes Clientbetriebssystem, Protokollversion und unterstützte Datenkompression. b Bitmaps Größe des Desktops, bevorzugte Farbtiefe, unterstützte Farbtiefen und Bitmap-Kompression. b Zeichenbefehle Unterstützung von lokalen Zeichenoperationen, wie z.b. Textausgabe oder Verwaltung beim Überdecken und Neuzeichnen von Fenstern. b Bitmap Cache Temporäres oder persistentes Zwischenspeichern von häufig genutzten Bitmaps auf dem Client. b Farbtabelle Unterstützung einer Palette für das Zeichnen von Pixeln in Bitmaps b Fensteraktivierung Steuerung des aktiven Anwendungsfensters, wenn es einzeln und nicht im Zusammenhang mit einem kompletten Desktop betrachtet wird. b Fernsteuerung Unterstützung der Remoteunterstützung, wobei sich ein Client fernsteuern lässt. b Zeiger Definition der Farbeigenschaften eines Mauszeigers. Einige der Eigenschaften spielen eine wesentliche Rolle für die Leistungsfähigkeit des RDP-Protokolls und sollen daher ein wenig näher betrachtet werden. Grafikdarstellung unter RDP Betrachtet man die Übertragung einer Benutzeroberfläche oder einer dynamischen Windows-Anwendung auf einen entfernten Client, so erinnert dies stark an einen digitalen Film. Die Handlung ist möglicherweise ein wenig abstrakt, die Schnitte beim Wechseln oder beim Starten von Anwendungsfenstern sind dabei zumeist sehr hart. Grundsätzlich erfordert die Darstellung einer solchen grafischen Benutzerschnittstelle auf einem entfernten Client die Übertragung von riesigen Datenmengen. Werden alle Bereiche, die sich auf dem Bildschirm ändern, immer komplett vom Server auf den Client transferiert, so kann sich dies leicht auf mehrere hundert KB bis hin zu mehr als einem MB addieren. Insbesondere der Start oder die Beendigung einer bildschirmfüllenden Anwendung wird daher teuer in Bezug auf die benötigte Netzwerkbandbreite. Kommunikationsprotokolle und schlanke Clients 81

Mit Abstand der meiste Aufwand wurde daher in die Optimierung des RDP-Protokolls bei der Behandlung von grafischen Elementen gesteckt. Dafür werden möglichst effiziente Kompressionsalgorithmen und Verwaltungsmechanismen eingesetzt, die möglichst alle Grafikoperationen eines Windows-Desktops und von Windows-Anwendungen gleich gut unterstützen. Hierbei sollen als Ergebnis der zugehörige Rechenaufwand und die benötigte Netzwerkbandbreite möglichst klein gehalten werden. Der RDP-Grafiktreiber erhält die Grafikkommandos von den Anwendungen über das Graphics Device Interface (GDI oder GDI+, siehe auch : Kapitel 1). Die Anwendung weist das GDI(+) an, was und wo zu zeichnen ist. Das GDI(+) leitet diese Anweisungen an den RDP-Treiber weiter. Hierbei ist für das GDI(+) nicht ersichtlich, dass die Grafikelemente nicht auf dem lokalen Bildschirm ausgegeben werden. Vielmehr erfolgt durch den RDP-Treiber ihre Netzwerkübertragung zu einem entfernten Client. Genau hier muss die Optimierung daher ansetzen. Die meisten zugehörigen Grafikoperationen betreffen dabei die Ausgabe von Rasterbildern (Bitmaps), das Zeichnen von Grafikprimitiven und die Darstellung von Textzeichen. Ein Bitmap ist ein Rechteck, das aus Pixeln mit verschiedenen Farben besteht und das somit ein spezifisches Muster bildet. Ein Anwendungssymbol (Icon) ist z.b. ein solches Bitmap. Die Ausgabe eines statischen Bitmaps lässt sich dadurch beschleunigen, dass es komprimiert übertragen wird. Hierzu genügt bei geringer Farbtiefe eine einfache Lauflängenkodierung, bei der nur ein Farbwert übertragen wird, wenn mehrere Pixel der gleichen Farbe hintereinander stehen. Die hierbei erreichten Kompressionsraten lassen sich auch durch die verwendeten Anwendungen und durch das Design der grafischen Benutzerschnittstelle stark beeinflussen. Die Verwendung vieler Farben und horizontaler Farbverläufe sind z.b. sehr kritisch. Daher wird bei den Sitzungen auf entfernten Clients die Dekoration der Fenster deutlich einfacher gehalten als auf der Konsole (Farbverlauf im Kopf des Fensters). Auch die Gesamtzahl der verwendeten Farben, wie sie in den Bitmap-Eigenschaften festgelegt wird, spielt eine große Rolle für die Auswahl des Kompressionsalgorithmus und der daraus resultierenden Kompressionsrate. Der Einsatz von Farbpaletten kann die Nutzung von Bitmaps weiter optimieren. Hierbei wird eine Tabelle mit Farbwerten angelegt und an den Client übertragen. Sollen nun einzelne Pixel innerhalb einer Bitmap mit einer Farbe versehen werden, so erfolgt nicht mehr die Übertragung eines Farbwerts, sondern die Angabe der Position innerhalb der Tabelle. Diese Information ist immer dann wesentlich kürzer, wenn die Farbtiefe grundsätzlich sehr groß, die gleichzeitig verwendete Anzahl verschiedener Farben jedoch relativ klein ist. So benötigt ein einzelner Farbwert bis zu drei Bytes, die Position der Farbe innerhalb einer Tabelle mit maximal 256 Einträgen jedoch nur ein Byte. Noch problematischer sind bewegte Bilder, d.h. animierte Bitmaps. Sie führen auch bei geringer Ausdehnung (z.b. als animierte oder blinkende Mauszeiger) zu deutlich erhöhten Transferraten im Netzwerk. Hier muss daher ein anderer Mechanismus zur Begrenzung des Datenvolumens eingesetzt werden, das Caching. Wie funktioniert nun die Ausgabe von Grafikprimitiven, z.b. Linien oder Rechtecke, aus denen viele Elemente der Benutzerschnittstelle bestehen? Die einfachste Lösung ist das Zeichnen einer Linie durch die Angabe jedes einzelnen zugehörigen Pixels. Wesentlich effizienter ist jedoch ein Zeichenbefehl für die Angabe von Anfangspunkt, Endpunkt, Dicke und Farbe einer Linie. Den Rest kann dann das Ausgabegerät selbst berechnen. Natürlich gehören zu dieser Eigenschaft auch komplexere Zeichenbefehle, wie z.b. das Neuzeichnen eines Fensters, wenn es zuvor überdeckt war. Auch hierzu muss über Caching die Information über alle Fensterelemente und den Inhalt zwischengespeichert werden. Einzelne Buchstaben in Zeichenketten werden über einen speziellen Bitmaptyp verwaltet: den Glyph. Grundsätzlich gestaltet sich die Ausgabe von Buchstaben mithilfe von Glyphs wesentlich ein- 82 Kapitel 3

facher als die Übertragung von Buchstabenbitmaps. Ein Kommando fordert nur noch die Ausgabe eines Glyphs an einer bestimmten Bildschirmstelle an. Problematisch sind jedoch die vielen verschiedenen Schriftarten und Schriftgrößen der gängigen Zeichensätze sowie das initiale Transportieren der Glyphs auf den Client. Caching Ein schon weiter oben genannter Mechanismus zur Reduktion der übertragenen Daten nennt sich Caching oder Zwischenspeicherung. Hierbei wird auf dem Client Speicher reserviert, in dem sich häufig genutzte Bildfragmente befinden, die bei Bedarf ohne Netzwerkübertragung wieder zur Darstellung gebracht werden können. Auch einige Zeichenoperationen erfordern aus technischen Gründen zwingend den Einsatz von Cachespeicher. Caching-Funktionalitäten werden nicht nur über den Hauptspeicher des Clients realisiert. Sind auch lokale Festplatten vorhanden, so können diese ein so genanntes persistentes Caching ermöglichen, wobei die zwischengespeicherten Daten auch nach einem Neustart des Clients noch vorliegen. Grundsätzlich können auch spezielle Netzwerkkomponenten RDP-Daten zur späteren Verwendung lagern und somit einen globalen Caching-Bereich in einem LAN-Segment bereitstellen. Welche Cachespeicher werden nun durch RDP unterstützt? b Bitmap Cache Zwischenspeicher für verschiedene Arten von Bitmaps. Die Anzahl und die Größe dieser Caches wird beim Verbindungsaufbau festgelegt. b Font Cache Zwischenspeicher für Buchstabenbitmaps (Glyphs). Der Cache sollte dabei groß genug sein, um möglichst alle Zeichen eines bestimmten Zeichensatzes aufzunehmen. b Desktop Cache Zwischenspeicher für eine Momentaufnahme des Desktops. Ein Zeichenbefehl sorgt für das Speichern oder für die Ausgabe dieser speziellen Bitmap. b Cursor Cache Zwischenspeicher für Mauszeiger, die eine spezielle Behandlung benötigen. Spezielle Grafikalgorithmen sorgen dafür, dass die Ausgabe des korrekten Mauszeigers auf dem Desktop zum einen ohne viel Netzwerkverkehr und zum anderen ohne starke Belastung der lokalen Prozessorressourcen erfolgen kann. Verschiebeoperationen mit der Maus erfordern somit nicht die Übertragung neuer grafischer Elemente, sondern nur noch die Mittelung der neuen Koordinaten. b Text Cache Zwischenspeicher für häufig genutzte Zeichenketten und den zugehörigen Formatierungsinformationen. Hierbei werden die Glyphs aus dem Font Cache genutzt, um eine vollständige Zeichenkette zu erzeugen. Virtuelle Kanäle und Spiegelung Ein virtueller Kanal kann von einem RDP-Client oder einer Anwendung zur Übertragung von spezifischen Informationen genutzt werden. Er dient damit dem Hinzufügen von Funktionalitäten, die bisher nicht im RDP-Protokoll spezifiziert sind. Somit bilden die virtuellen Kanäle eine Plattform, auf der zukünftige Entwicklungen aufsetzen können, ohne die Kommunikationsmethoden zwischen einem Terminalserver und seinen Clients verändern zu müssen. Bei Windows Server 2003 und RDP 5.2 werden virtuelle Kanäle zur gemeinsamen Nutzung von Client- und Server-Zwischenablage sowie zum Umlenken von Druckaufträgen an lokale Client-Drucker verwendet. Konzeptionell erlaubt das RDP-Protokoll die Verteilung von Datenströmen einer Quelle zu vielen Zielen, ohne die Daten jeweils getrennt abschicken zu müssen. Hierdurch kann eine Anwendung auf einen anderen Client»gespiegelt«werden, wobei sogar der Eingabefokus von einem zum anderen Benutzer übergeben werden kann. Diese Funktionalität wird auf dem deutschen Windows Server 2003 etwas missverständlich»remoteüberwachung«genannt. Kommunikationsprotokolle und schlanke Clients 83

Eigenschaften des RDP-Protokolls Die Eigenschaften des RDP-Protokolls spielen für eine breite Akzeptanz von Terminalservern eine wesentliche Rolle. Mit der Version 5.0 von RDP, wie es unter Windows 2000 zum Einsatz kam, wurden schon die Weichen für die Zukunft gestellt. Die wichtigsten Eigenschaften werden im Folgenden aufgelistet: b Unterstützung von 256 Farben (8 Bit) b Einführung der Remoteüberwachung b Verschlüsselungsoptionen mit 56 Bit und 128 Bit b Verbesserte Kompression und Caching zur Verringerung des Netzwerkverkehrs b Möglichkeit zur Wiederherstellen der Verbindung zu einer bestehenden Benutzersitzung b Verbindung zu Druckern und der Zwischenablage auf dem Client Die RDP-Version 5.1 wurde als integraler Bestandteil von Windows XP bei dessen Einführung etabliert. RDP 5.1 beinhaltete eine Reihe von verbesserten oder neuer Eigenschaften, die in ihrer Summe das Konzept der Terminaldienste deutlich stärkte. Ohne den zugehörigen Server konnten Windows XP und RDP 5.1 jedoch noch nicht das ganze Potenzial der Technologie ausschöpfen. Welche neuen Eigenschaften brachte RDP 5.1 mit sich? Die folgende Liste soll diese Frage in einer übersichtlichen Art beantworten. b Unterstützung von bis zu 16 Millionen Farben (24 Bit) b Erhöhte Bildschirmauflösung von 640 x 480 bis 1600 x 1200 Pixel b Abbildung vordefinierter, lokaler Tastenkombinationen auf die Benutzersitzung b Verbindung zum lokalen Dateisystem des Clients b Verbesserte Unterstützung bei der Einbindung von Client- und Netzwerkdruckern b Übertragung von Audioinformationen an den Client, wobei die hierzu benötigte Bandbreite kontrolliert werden kann. Die Einbindung von MIDI-Daten wird dabei nicht unterstützt. b Umlenken von seriellen Ports vom Client in die Benutzersitzung auf dem Terminalserver b Möglichkeit zur Nutzung der Konsolensitzung von einem entfernten Client aus, wodurch alle administrativen Tätigkeiten auch ohne physischen Zugriff auf die Peripheriegeräte des Servers ausgeführt werden können. b Abfrage der Zeitzoneninformation des Clients und entsprechende Anpassung der Benutzersitzung b Unterstützung von Smartcards, wenn ein zugehöriges Lesegerät auf dem Client installiert wurde b Optimierung der Bandbreiteneinstellungen zur Unterstützung verschiedener Netzwerkszenarien (Intranet, Modem etc.) Die RDP-Version 5.2 unter Windows Server 2003 beinhaltet alle Eigenschaften der Vorgängerversionen und erweitert sie nur um kleinere Details, wie z.b. die automatische Wiederverbindungsmöglichkeit von getrennten Sitzungen. Benötigte Netzwerkbandbreite Ein wichtige Frage ist nun natürlich, wie viel Bandbreite das RDP-Protokoll im Netzwerk verbraucht. Leider ist auf diese Frage keine generelle Antwort zu finden, da sie von vielen Randbedingungen beeinflusst wird. b Eingestellte und unterstützte Bildschirmauflösung und Farbtiefe auf dem Client b Verschlüsselung und Kompression 84 Kapitel 3

b Erlauben oder Verbieten von Desktophintergründen, dem Anzeigen von Fensterinhalten bei Ziehen, der Animation von Menüs und Fenstern, von Designs oder der Bitmapzwischenspeicherung b Leistungsfähigkeit der Client- und der Serverplattformen b Art und Mischung der genutzten Anwendungen b Benutzerverhalten beim Verwenden der Anwendungen Grundsätzlich kann als Aussage gemacht werden, dass RDP ab einer verfügbaren Bandbreite von 20 Kilobits pro Sekunde nutzbar und ab ca. 50 Kilobits pro Sekunde flüssiges Arbeiten in der Regel möglich ist. Steht genügend Bandbreite zur Verfügung, nimmt das RDP-Protokoll jedoch bei Bedarf auch bis 500 Kilobits pro Sekunde für sich in Anspruch. Letzteres ist z.b. dann der Fall, wenn ein Programm großflächige Grafiken so schnell wie möglich hintereinander ausgibt und nur von der Leistungsfähigkeit des Ausgabekanals beschränkt wird. Eine solche Situation wird beim Start von Computerspielen, Videos, Animationen oder bestimmten Benchmark-Programmen über einen RDP- Client geschaffen. Solche Programme sind daher in der Regel auch nicht für den Einsatz auf Terminalservern geeignet. Genauere Aussagen über die benötigte Bandbreite in einer Zielumgebung erlauben nur umfangreiche Tests, wie sie auch in : Kapitel 11 vorgestellt werden. Hierbei sollten Sie jedoch auf Überraschungen gefasst sein, da sich das RDP-Protokoll nicht immer so verhält, wie man es zunächst erwarten würde. So ist beispielsweise nicht sicher, dass die Erhöhung der unterstützen Farbtiefe von 8 Bit auf 16 Bit zwangsläufig eine schlechtere Leistung ergibt. Ein 8-Bit-Farbraum wurde auch schon in Vergangenheit unterstützt und daher müssen die damals gebräuchlichen Algorithmen aus Kompatibilitätsgründen noch heute verfügbar sein. Moderne Kompressionsalgorithmen sind insgesamt schneller und auch auf einen größeren Farbraum optimiert. Daher kann es sogar sein, dass der Einsatz von mehr Farben zu einer besseren Leistung führt. Auch spielen die eingesetzten Client- und Serverplattformen eine wesentliche Rolle. So lässt sich beispielsweise die genutzte Netzwerkbandbreite durch den Einsatz von Kompression natürlich verringern. Sollte jedoch der Client bei gleichzeitiger Verschlüsselung der Daten für die Aufbereitung des eintreffenden Datenstroms zu langsam sein, ist das Ergebnis in Bezug auf den flüssigen Sitzungsablauf auch nicht befriedigend. Da hilft es dann auch nicht mehr viel, die Übertragungsrate durch das Verbieten von Desktophintergründen oder Menüanimationen zu optimieren. Ein gutes Beispiel für eine nur bedingt aussagekräftige Messung soll in Abbildung 3.5 (siehe hierzu auch : Kapitel 4) vorgestellt werden. Hier wurde in sechs unterschiedlich konfigurierten RDP-Sitzungen, die parallel auf einem Client ausgeführt wurden, nacheinander die benötigte Bandbreite eines 16-Bit-Programms für grafische Lasttests gemessen. Während der Messung stand den beteiligten Computerplattformen ein 100-MBit-Netzwerk exklusiv zur Verfügung. Jede Sitzung nutzte ein eigenes Benutzerkonto, um auf Benutzerebene einen gegenseitigen Einfluss auszuschließen. Das 16-Bit- Testprogramm wurde innerhalb jeder Benutzersitzung in der 16-Bit-Emulationsumgebung ausgeführt (WoW/VDM, siehe auch : Kapitel 1). Kommunikationsprotokolle und schlanke Clients 85

Abbildung 3.5: Ergebnis eines Bandbreitentests mit mehreren unterschiedlich konfigurierten RDP- Sitzungen im Systemmonitor (siehe hierzu auch : Kapitel 4) Die Ergebnisse sind nicht sehr unterschiedlich, die Lastspitzen liegen durchgehend zwischen 35 und 50 kbyte/s. Dies ist umso überraschender, wenn man sich die jeweiligen Parameter der RDP-Sitzungen ansieht: Sitzungs-ID Auflösung Farbtiefe Bitmapzwischenspeicherung Netzwerkoptimierung 40 1024 x 768 16 Bit Ja LAN (10 Mbit/s) 41 640 x 480 16 Bit Ja LAN (10 Mbit/s) 42 1024 x 768 8 Bit Ja LAN (10 Mbit/s) 43 640 x 480 8 Bit Ja LAN (10 Mbit/s) 44 1024 x 768 16 Bit Nein Modem (28,8 Kbit/s) 45 640 x 480 16 Bit Nein Modem (28,8 Kbit/s) Tabelle 3.1: Konfiguration der unterschiedlichen RDP-Sitzungen für den Bandbreitentest Die unterschiedliche Konfiguration der RDP-Sitzungen führte also hauptsächlich zu unterschiedlichen Ausführungszeiten des Testprogramms. Diese differierten je nach Wahl der Parameter bis zu 50%. Bei der Spitzenlast im Netzwerk ließen sich dagegen keine so deutlichen Unterschiede feststellen. Dennoch ist bemerkenswert, dass die höchste Lastspitze bei einer Sitzung auftrat, die nur mit 256 Farben (= 8 Bit) konfiguriert war. Hier war offensichtlich die Darstellungsgeschwindigkeit auf dem Client am höchsten, was auch mit entsprechenden Anforderungen an das Netzwerk korrelierte. Zum Vergleich zeigt Abbildung 3.6 eine»normale«rdp-sitzung, deren Parameter der Sitzungs-ID 40 aus Abbildung 3.6 entsprechen. Wieder steht exklusiv ein 100 Mbit/s-Netzwerk zur Verfügung, 86 Kapitel 3

das keinerlei Bandbreitenbeschränkungen beinhaltet. Der Benutzer der protokollierten Sitzung startet zunächst das Programm Paint und öffnet eine größere Grafik. Danach startet er WordPad, öffnet ein vorhandenes Dokument und beginnt dieses zu ergänzen. Immer wieder werden die Anwendungsfenster auf dem Desktop verschoben. Kurzzeitige Lastspitzen von über 10 Kilobytes pro Sekunde sind nur dann im Netzwerk zu beobachten, wenn eine neue Anwendung geöffnet wird und das zugehörige Fenster initial übertragen werden muss. Auch die Prozessorlast ist relativ gering bei diesen Aktionen, zumal sich der Benutzer auch alleine auf dem Terminalserver befindet. Abbildung 3.6: Messung einer RDP-Sitzung mit üblichen Benutzeraktionen. Die dicke Linie repräsentiert die zugehörige Netzwerkbandbreite in kbytes/s, die dünne Linie zeigt die Prozessorlast. Die gemessene Bandbreite liegt im Durchschnitt bei 2,5 Kilobytes pro Sekunde, das entspricht ca. 20 Kilobits pro Sekunde. Würde diese Sitzung daher über eine Modemleitung mit 56 Kilobits pro Sekunde laufen, so wäre die damit bereitgestellte Bandbreite deutlich ausreichend. Der einzige Unterschied könnte in Form von leichten Verzögerungen beim initialen Aufbau der Anwendungsfenster beobachtet werden. Eine Optimierung der Übertragungsrate bei den Clienteinstellungen würde die benötigte Bandbreite zusätzlich reduzieren, wodurch bei solche einem Szenario auch auf sehr langsamen Netzwerkverbindungen ein weit gehend störungsfreies Arbeiten möglich sein sollte. Latenzzeiten Stärker als die nominell verfügbare Bandbreite beeinflussen Verzögerungszeiten (Latenzzeiten) im Netzwerk die Zufriedenheit der Benutzer einer Terminalserverumgebung. So ist beispielsweise ein Weitverkehrsnetzwerk, in dem über Satelliten kommuniziert wird, auch bei sehr hoher verfügbarer Bandbreite oftmals ungeeignet für Terminalserver. Die Laufzeiten des Signals von einer Benutzereingabe bis zur sichtbaren Reaktion auf dem Client können dabei bis zu einer Sekunde dauern. Dies lässt sich dadurch begründen, dass zunächst das Signal bei Maus- oder Tastatureingabe zum Server wandern muss, das dort in der zugehörigen Benutzersitzung die entsprechende grafische Reaktion hervorruft, die dann wieder zum Client übertragen wird. Hinzu kommt noch, dass nicht jede Benutzereingabe auf dem RDP-Client sofort zum Server losgeschickt wird. Vielmehr sorgt ein Eingangspuffer zunächst für das Sammeln von Benutzereingaben, um sie dann als Paket zu versenden. Auch dies trägt in bestimmten Situationen zu merklichen Verzö- Kommunikationsprotokolle und schlanke Clients 87

gerungen beim Reaktionsverhalten von Anwendungsprogrammen bei. Abhilfe schafft dabei die Veränderung von Parametern für die Pufferung der RDP-Datenströme. Diese Möglichkeit wird in den : Kapiteln 6 und 15 näher beschrieben. Wer jemals bei großen Latenzzeiten versucht hat, ein hoch interaktives Anwendungsprogramm flüssig zu bedienen, weiß, dass dies sehr problematisch ist. Zudem bestehen Benutzer oftmals auf einer gewissen Dienstegüte, die in Bezug auf Anwendungsprogramme maximale Reaktionslimits und Maskenwechselzeiten beinhaltet. In produktiven Terminalserverumgebungen sollten die Latenzzeiten daher möglichst geringer als 100 ms sein. Ab Latenzzeiten von 150 bis 200 ms ist die Verzögerung deutlich spürbar, ab 300 bis 500 ms wird das Systemverhalten von den Benutzern in der Regel nicht mehr toleriert. Eine einfache Methode die Latenzzeit zwischen zwei Netzwerkknoten (z.b. RDP-Client und Terminalserver) zu messen, ist das Kommando Ping. Es ruft ein Dienstprogramm zum Überprüfen von Verbindungen zu einem entfernten Computer auf. Der Befehl Ping stellt anhand von Echo-Request- und Echo-Reply-Paketen fest, ob ein bestimmter IP-Knoten (d. h., ein bestimmtes Computersystem) innerhalb eines Netzwerkes in Betrieb ist. Ein typisches Ping-Kommando enthält eine Reihe von Parametern, die sein Verhalten genauer spezifizieren. Die Überprüfung der Latenzzeiten zwischen RDP-Clients und Terminalserver würden typischerweise folgendermaßen aussehen: ping t n 20 l 200 <Servername> Die verwendeten Parameter haben dabei folgende Bedeutung. Parameter Beschreibung -t Sendet fortlaufend Ping-Signale an den angegebenen Computer. -n Anzahl Sendet die mit Anzahl angegebene Anzahl an Echo-Pakete. Der Standardwert ist 4. -l Länge Sendet Echo-Pakete mit der durch Länge festgelegten Datenmenge. Der Standardwert beträgt 32 Bytes, der Maximalwert beträgt 65.527 Bytes. Die typische Länge eines RDP-Pakets liegt im Bereich zwischen 50 Bytes und 1.000 Bytes. Tabelle 3.2: Ausgewählte Parameter des Ping-Kommandos RDP im Netzwerkmonitor Der Netzwerkmonitor ist ein Systemwerkzeug des Lieferumfangs von Windows Server 2003, mit dem komplexe Untersuchungen im Netzwerk durchgeführt werden können. Insbesondere dient es zur Netzwerkanalyse und zur Fehlerbehebung. Hierfür sammelt der Netzwerkmonitor selbst oder daran angebundene Agenten sämtliche Daten, die an einer Netzwerkkarte anliegen. Sowohl Windows Server 2003 als auch der Microsoft Systems Management Server werden mit dem Netzwerkmonitor ausgeliefert. Auf den ersten Blick wirken beide Werkzeuge identisch. Es bestehen jedoch bei der Betriebssystemvariante einige funktionale Einschränkungen. Nur der voll ausgebaute Netzwerkmonitor aus dem Systems Management Server kann von anderen Netzwerkmonitoragenten gesammelte Datenpakete empfangen und somit einen globaleren Blick auf das Gesamtsystem gewähren. Dies betrifft auch die Netzwerkverbindungen zwischen zwei entfernten Computern. Der mit dem Terminalserver mitgelieferte Netzwerkmonitor kann immer nur die Verbindung der lokalen Netzwerkkarte(n) protokollieren. 88 Kapitel 3