Exemplarische Vorgehensweise für Terminalserver: Start, Verbindung und Anwendung

In diesem Artikel wird der Initialisierungsprozess eines Terminalservers beschrieben und beschrieben, was geschieht, wenn ein Benutzer eine Verbindung mit dem Server herstellt und eine Anwendung ausführt.

Ursprüngliche KB-Nummer: 186572

Windows-Terminal Serverinitialisierung

Während der Windows-Terminal Server startet und das Kernbetriebssystem lädt, wird der Terminalserverdienst (Termsrv.exe) gestartet und erstellt Überwachungsstapel (ein Pro Protokoll- und Transportpaar), die auf eingehende Verbindungen lauschen. Jede Verbindung erhält einen eindeutigen Sitzungsbezeichner oder "SessionID", um eine einzelne Sitzung auf dem Terminalserver darzustellen. Jeder prozess, der in einer Sitzung erstellt wird, ist mit der zugehörigen SessionID gekennzeichnet, um seinen Namespace von dem Namespace einer anderen Verbindung zu unterscheiden.

Die Konsolensitzung (Terminalservertastatatur, Maus und Video) ist immer die erste, die geladen werden soll, und wird als Spezielle Clientverbindung behandelt und SessionID zugewiesen. Die Konsolensitzung beginnt als normale Windows NT-Systemsitzung mit geladenen Windows NT-Anzeige-, Maus- und Tastaturtreibern.

Der Terminalserverdienst ruft dann den Windows NT Session Manager (Smss.exe) auf, um zwei (Standard = 2) Leerlaufclientsitzungen (nach dem Erstellen der Konsolensitzung) zu erstellen, die auf Clientverbindungen warten. Um die Leerlaufsitzungen zu erstellen, führt der Sitzungs-Manager den Windows NT-basierten Client-/Server-Runtime-Subsystemprozess (Csrss.exe) aus, und diesem Prozess wird eine neue SessionID zugewiesen. Der CSRSS-Prozess ruft auch den Winlogon-Prozess (Winlogon.exe) und das Kernelmodul Win32k.sys (Window Manager und Graphics Device Interface - GDI) unter der neu zugeordneten SessionID auf. Das geänderte Windows NT-Imageladeprogramm erkennt diese Win32k.sys als SessionSpace-ladebares Bild durch ein vordefiniertes Bit, das in der Bildkopfzeile festgelegt ist. Anschließend wird der Codeteil des Images in den physischen Speicher verschoben, wobei Zeiger aus dem virtuellen Kerneladressbereich für diese Sitzung angezeigt werden, wenn Win32k.sys noch nicht geladen wurde. Standardmäßig wird es immer an den Code eines zuvor geladenen Bilds (Win32k.sys) angefügt, wenn bereits im Arbeitsspeicher vorhanden ist. Beispielsweise aus einer beliebigen aktiven Anwendung oder Sitzung.

Der Datenabschnitt (oder der nicht freigegebene) Abschnitt dieses Bilds wird dann der neuen Sitzung aus einem neu erstellten SessionSpace pageable Kernel Memory Section zugewiesen. Im Gegensatz zur Konsolensitzung sind Terminalserverclientsitzungen so konfiguriert, dass separate Treiber für die Anzeige, Tastatur und Maus geladen werden.

Der neue Anzeigetreiber ist der RDP-Anzeigegerätetreiber (Remote Desktop Protocol), Tsharedd.dll. Die Maus- und Tastaturtreiber kommunizieren über den Stapelstapel-Manager termdd.sys. Termdd.sys sendet die Nachrichten für Maus- und Tastaturaktivitäten an und vom RDP-Treiber, Wdtshare.sys. Diese Treiber ermöglichen es der RDP-Clientsitzung, remote verfügbar und interaktiv zu sein. Schließlich ruft Terminal Server auch einen Verbindungslistenerthread für das RDP-Protokoll auf, der erneut vom Multiple Instance Stack Manager (Termdd.sys) verwaltet wird, der auf RDP-Clientverbindungen auf TCP-Portnummer 3389 lauscht.

An dieser Stelle ist der CSRSS-Prozess unter seinem eigenen SessionID-Namespace vorhanden, wobei seine Daten nach Bedarf pro Prozess instanziiert werden. Alle Prozesse, die innerhalb dieser SessionID erstellt wurden, werden automatisch im SessionSpace des CSRSS-Prozesses ausgeführt. Dadurch wird verhindert, dass Prozesse mit unterschiedlichen SessionIDs auf die Daten einer anderen Sitzung zugreifen.

Clientverbindung

Der RDP-Client kann auf jedem Windows-basierten Terminal (basierend auf WinCE), Windows for Workgroups 3.11 unter TCP/IP-32b oder auf der Microsoft Win32-API-basierten Plattform installiert und ausgeführt werden. Nicht windowsbasierte Clients werden vom Citrix Metaframe-Add-On unterstützt. Die ausführbare Datei des RDP-Clients für Windows for Workgroups ist ungefähr 70 KB groß, verwendet einen Arbeitssatz von 300 KB und verwendet 100 KB für Anzeigedaten. Der Win32-basierte Client ist ungefähr 130 KB groß, verwendet einen Arbeitssatz von 300 KB und 100 KB für Anzeigedaten.

Der Client initiiert eine Verbindung mit dem Terminalserver über TCP-Port 3389. Der RDP-Listenerthread des Terminalservers erkennt die Sitzungsanforderung und erstellt eine neue RDP-Stapelinstanz, um die neue Sitzungsanforderung zu verarbeiten. Der Listenerthread übergibt die eingehende Sitzung an die neue RDP-Stapelinstanz und überwacht weiterhin TCP-Port 3389 für weitere Verbindungsversuche. Jeder RDP-Stapel wird erstellt, da die Clientsitzungen mit der Aushandlung von Sitzungskonfigurationsdetails verbunden sind. Die ersten Details sollen eine Verschlüsselungsstufe für die Sitzung einrichten. Der Terminalserver unterstützt zunächst drei Verschlüsselungsstufen: niedrig, mittel und hoch.

Mit niedriger Verschlüsselung werden nur Pakete verschlüsselt, die vom Client an den Terminalserver gesendet werden. Diese "nur Eingabe"-Verschlüsselung dient zum Schutz der Eingabe vertraulicher Daten, z. B. des Kennworts eines Benutzers. Die mittlere Verschlüsselung verschlüsselt ausgehende Pakete vom Client genauso wie die Verschlüsselung auf niedriger Ebene, verschlüsselt aber auch alle Anzeigepakete, die vom Terminalserver an den Client zurückgegeben werden. Diese Verschlüsselungsmethode sichert vertrauliche Daten, da sie über das Netzwerk bewegt wird, um auf einem Remotebildschirm angezeigt zu werden. Sowohl niedrige als auch mittlere Verschlüsselung verwenden den Microsoft-RC4-Algorithmus (modifizierter RC4-Algorithmus mit verbesserter Leistung) mit einem 40-Bit-Schlüssel. Mit hoher Verschlüsselung werden Pakete in beide Richtungen zu und vom Client verschlüsselt, aber der standardmäßige RC4-Verschlüsselungsalgorithmus wird erneut mit einem 40-Bit-Schlüssel verwendet. Eine nicht exportierende Version von Windows NT Terminal Server stellt eine 128-Bit-High-Level RC4-Verschlüsselung bereit.

Zwischen Client und Server erfolgt ein Schriftaustausch, um zu bestimmen, welche allgemeinen Systemschriftarten installiert sind. Der Client benachrichtigt den Terminalserver über alle installierten Systemschriftarten, um ein schnelleres Rendern von Text während einer RDP-Sitzung zu ermöglichen. Wenn der Terminalserver weiß, welche Schriftarten der Client verfügbar hat, können Sie die Netzwerkbandbreite sparen, indem Sie komprimierte Schriftarten und Unicode-Zeichenzeichenfolgen anstelle größerer Bitmaps an den Client übergeben.

Standardmäßig reservieren alle Clients 1,5 MB Arbeitsspeicher für einen Bitmapcache, der zum Zwischenspeichern von Bitmaps verwendet wird, z. B. Symbole, Symbolleisten, Cursor usw., wird jedoch nicht zum Speichern von Unicode-Zeichenfolgen verwendet. Der Cache kann (über einen Registrierungsschlüssel) optimiert und mit einem LRU-Algorithmus (Least Recently Used) überschrieben werden. Der Terminalserver enthält auch Puffer, um die flussgesteuerte Übergabe von Bildschirmaktualisierungen an Clients zu ermöglichen, anstatt einen konstanten Bitstream. Wenn die Benutzerinteraktion auf dem Client hoch ist, wird der Puffer ungefähr 20 Mal pro Sekunde geleert. Während der Leerlaufzeit oder wenn keine Benutzerinteraktion vorhanden ist, wird der Puffer nur 10 Mal pro Sekunde geleert. Sie können alle diese Nummern über die Registrierung optimieren.

Nachdem Sitzungsdetails ausgehandelt wurden, wird die RDP-Stapelinstanz des Servers für diese Verbindung einer vorhandenen Win32k-Benutzersitzung zugeordnet, und der Benutzer wird mit dem Windows NT-Anmeldebildschirm aufgefordert. Wenn die automatische Anmeldung konfiguriert ist, wird der verschlüsselte Benutzername und das Kennwort an den Terminalserver übergeben, und die Anmeldung wird fortgesetzt. Wenn derzeit keine win32k-Sitzungen im Leerlauf vorhanden sind, ruft der Terminalserverdienst den Session Manager (SMSS) auf, um einen neuen Benutzerbereich für die neue Sitzung zu erstellen. Ein Großteil der Win32k-Benutzersitzung verwendet gemeinsam genutzten Code und wird deutlich schneller geladen, nachdem eine Instanz zuvor geladen wurde.

Nachdem der Benutzer einen Benutzernamen und ein Kennwort eingibt, werden Pakete verschlüsselt an den Terminalserver gesendet. Der Winlogon-Prozess führt dann die erforderliche Kontoauthentifizierung aus, um sicherzustellen, dass der Benutzer über die Berechtigung zum Anmelden verfügt und die Domäne und den Benutzernamen des Benutzers an den Terminalserverdienst weitergibt, der eine Liste der Domänen-/Benutzernamen-Sitzungs-ID verwaltet. Wenn dieser Benutzer bereits eine SessionID zugeordnet ist (z. B. ist eine getrennte Sitzung vorhanden), wird der derzeit aktive Sitzungsstapel an die alte Sitzung angefügt. Die temporäre Win32-Sitzung, die für die anfängliche Anmeldung verwendet wird, wird dann gelöscht. Andernfalls wird die Verbindung normal fortgesetzt, und der Terminalserverdienst erstellt eine neue Domänen-/Benutzername SessionID-Zuordnung. Wenn für diesen Benutzer aus irgendeinem Grund mehr als eine Sitzung aktiv ist, wird die Liste der Sitzungen angezeigt, und der Benutzer entscheidet, welche Sitzung für die erneute Verbindung ausgewählt werden soll.

Ausführen einer Anwendung

Nach der Anmeldung des Benutzers wird der Desktop (oder die Anwendung im Einzelanwendungsmodus) für den Benutzer angezeigt. Wenn der Benutzer eine auszuführende 32-Bit-Anwendung auswählt, werden die Mausbefehle an den Terminalserver übergeben, der die ausgewählte Anwendung in einem neuen virtuellen Speicherbereich startet (2-GB-Anwendung, 2-GB-Kernel). Alle Prozesse auf dem Terminalserver teilen code in Kernel- und Benutzermodi, wo immer möglich. Um die Gemeinsame Nutzung von Code zwischen Prozessen zu erreichen, verwendet der Windows NT Virtual Memory (VM)-Manager den Kopier-on-Write-Seitenschutz. Wenn mehrere Prozesse denselben Speicherinhalt lesen und schreiben möchten, weist der VM-Manager dem Speicherbereich Kopier-on-Write-Seitenschutz zu. Die Prozesse (Sitzungen) verwenden denselben Speicherinhalt, bis ein Schreibvorgang ausgeführt wird. Zu diesem Zeitpunkt kopiert der VM-Manager den physischen Seitenframe an einen anderen Speicherort, aktualisiert die virtuelle Adresse des Prozesses so, dass er auf den neuen Seitenspeicherort verweist und die Seite jetzt als Lese-/Schreibzugriff markiert. Kopieren-on-Write ist nützlich und effizient für Anwendungen, die auf einem Terminalserver ausgeführt werden.

Wenn eine win32-basierte Anwendung, z. B. Microsoft Word, durch einen Prozess (Sitzung) in den physischen Speicher geladen wird, wird sie als "Kopieren beim Schreiben" markiert. Wenn neue Prozesse (Sitzungen) auch Word aufrufen, zeigt das Bildladeprogramm einfach die neuen Prozesse (Sitzungen) auf die vorhandene Kopie, da die Anwendung bereits im Arbeitsspeicher geladen ist. Wenn Puffer und benutzerspezifische Daten erforderlich sind (z. B. Speichern in einer Datei), werden die erforderlichen Seiten in einen neuen physischen Speicherspeicherort kopiert und für den einzelnen Prozess (Session) als Lese-/Schreibzugriff markiert. Der VM-Manager schützt diesen Speicherplatz vor anderen Prozessen. Die meisten Anwendungen sind jedoch gemeinsam nutzbarer Code und verfügen nur über eine einzige Instanz von Code im physischen Speicher, unabhängig davon, wie oft sie ausgeführt wird.

Es ist vorzuziehen (obwohl nicht erforderlich), 32-Bit-Anwendungen in einer Terminalserverumgebung auszuführen. Die 32-Bit-Anwendungen (Win32) ermöglichen das Teilen von Code und die effizientere Ausführung in Mehrbenutzersitzungen. Windows NT ermöglicht die Ausführung von 16-Bit-Anwendungen (Win16) in einer Win32-Umgebung, indem ein virtueller MS-DOS-basierter Computer (VDM) für jede auszuführende Win16-Anwendung erstellt wird. Alle 16-Bit-Ausgaben werden in Win32-Aufrufe übersetzt, die die erforderlichen Aktionen ausführen. Da Win16-Apps innerhalb ihres eigenen VDM ausgeführt werden, kann Code nicht zwischen Anwendungen in mehreren Sitzungen gemeinsam genutzt werden. Die Übersetzung zwischen Win16- und Win32-Aufrufen verbraucht auch Systemressourcen. Das Ausführen von Win16-Anwendungen in einer Terminalserverumgebung kann potenziell doppelt so viele Ressourcen verbrauchen wie eine vergleichbare Win32-basierte Anwendung.

Sitzungsverbindung und Benutzerabmeldung

Sitzungsverbindung trennen

Wenn ein Benutzer entscheidet, die Sitzung zu trennen, bleiben die Prozesse und der gesamte virtuelle Speicherplatz auf dem physischen Datenträger aus, wenn für andere Prozesse physischen Arbeitsspeicher erforderlich ist. Da der Terminalserver eine Zuordnung von Domäne/Benutzername und zugehöriger SessionID beibehält, wird die vorhandene Sitzung geladen und wieder verfügbar gemacht. Ein weiterer Vorteil von RDP besteht darin, dass die Sitzungsbildschirmauflösungen geändert werden können, je nachdem, was der Benutzer für die Sitzung anfordert. Angenommen, ein Benutzer hatte zuvor mit einer Terminalserversitzung mit einer Auflösung von 800 x 600 verbunden und getrennt. Wenn der Benutzer dann zu einem anderen Computer wechselt, der nur 640 x 480 Auflösung unterstützt, und die Verbindung zur vorhandenen Sitzung erneut hergestellt wird, wird der Desktop neu gezeichnet, um die neue Auflösung zu unterstützen.

Benutzeranmeldung

Logoff ist in der Regel einfach zu implementieren. Nachdem sich ein Benutzer von der Sitzung abmeldet, werden alle mit der SessionID verknüpften Prozesse beendet, und alle der Sitzung zugeordneten Speicher werden freigegeben. Wenn der Benutzer eine 32-Bit-Anwendung wie Microsoft Word ausführt und sich von der Sitzung abmeldet, verbleibt der Code der Anwendung selbst im Arbeitsspeicher, bis der letzte Benutzer von der Anwendung beendet wurde.