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

Dieser Artikel beschreibt den Initialisierungsprozess eines Terminalservers und beschreibt, was geschieht, wenn ein Benutzer eine Verbindung mit dem Server herstellt und eine Anwendung ausführt.

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 186572

Windows-Terminal Serverinitialisierung

Wenn der Windows-Terminal Server das Kernbetriebssystem startet und lädt, wird der Terminalserverdienst (Termsrv.exe) gestartet und erstellt Lauschstapel (einen pro Protokoll- und Transportpaar), die auf eingehende Verbindungen lauschen. Jede Verbindung erhält einen eindeutigen Sitzungsbezeichner oder "SessionID", um eine einzelne Sitzung für den Terminalserver darzustellen. Jeder prozess, der innerhalb einer Sitzung erstellt wird, wird mit der zugeordneten SessionID gekennzeichnet, um seinen Namespace vom Namespace einer anderen Verbindung zu unterscheiden.

Die Konsolensitzung (Tastatur, Maus und Video) des Terminalservers ist immer die erste, die geladen wird, und wird als Spezielle Clientverbindung und zugewiesene SessionID behandelt. Die Konsolensitzung wird als normale Windows NT-Systemsitzung gestartet, wobei die konfigurierten Windows NT-Anzeige-, Maus- und Tastaturtreiber geladen sind.

Der Terminalserverdienst ruft dann den Windows NT-Sitzungs-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-Laufzeitsubsystemprozess (Csrss.exe) aus, und diesem Prozess wird eine neue SessionID zugewiesen. Der CSRSS-Prozess ruft auch den Winlogon-Prozess (Winlogon.exe) und das Win32k.sys-Kernelmodul (Windows-Manager und Grafikgeräteschnittstelle - GDI) unter der neu zugeordneten SessionID auf. Das geänderte Windows NT-Imageladeprogramm erkennt dieses Win32k.sys als sessionSpace-ladebares Image durch ein vordefiniertes Bit, das im Imageheader festgelegt ist. Anschließend wird der Codeteil des Images in den physischen Speicher mit Zeigern aus dem Adressraum des virtuellen Kernels für diese Sitzung verschoben, wenn Win32k.sys noch nicht geladen wurde. Standardmäßig wird es immer an den Code eines zuvor geladenen Images (Win32k.sys) angefügt, wenn bereits eins im Arbeitsspeicher vorhanden ist. Beispielsweise aus einer beliebigen aktiven Anwendung oder Sitzung.

Der Datenabschnitt (oder der nicht freigegebene) Abschnitt dieses Images wird dann der neuen Sitzung aus einem neu erstellten SessionSpace-Auslagerungs-Kernelspeicherabschnitt zugeordnet. 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ättreiber( Remotedesktopprotokoll), Tsharedd.dll. Die Maus- und Tastaturtreiber kommunizieren mit dem Stapel über den stapelübergreifende instance-Manager, termdd.sys. Termdd.sys sendet die Nachrichten für Maus- und Tastaturaktivitäten an den und vom RDP-Treiber, Wdtshare.sys. Diese Treiber ermöglichen es, dass die RDP-Clientsitzung remote verfügbar und interaktiv ist. Schließlich ruft der Terminalserver auch einen Verbindungslistenerthread für das RDP-Protokoll auf, der wiederum vom mehrfachen instance Stack Manager (Termdd.sys) verwaltet wird, der auf RDP-Clientverbindungen an TCP-Port 3389 lauscht.

An diesem Punkt befindet sich der CSRSS-Prozess unter seinem eigenen SessionID-Namespace, wobei die Daten nach Bedarf pro Prozess instanziiert werden. Alle Prozesse, die aus dieser SessionID erstellt werden, 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 mit TCP/IP-32b oder auf der Microsoft Win32-API-basierten Plattform installiert und ausgeführt werden. Nicht Windows-basierte Clients werden vom Citrix Metaframe-Add-On unterstützt. Die ausführbare Datei des Windows for Workgroups RDP-Clients 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 einen neuen RDP-Stapel instance, um die neue Sitzungsanforderung zu verarbeiten. Der Listenerthread übergibt die eingehende Sitzung an den neuen RDP-Stapel instance und lauscht weiterhin an TCP-Port 3389 für weitere Verbindungsversuche. Jeder RDP-Stapel wird erstellt, wenn die Clientsitzungen verbunden sind, um die Aushandlung von Sitzungskonfigurationsdetails zu verarbeiten. Die ersten Details sind das Einrichten einer Verschlüsselungsstufe für die Sitzung. Der Terminalserver unterstützt zunächst drei Verschlüsselungsebenen: niedrig, mittel und hoch.

Bei 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 schützt vertrauliche Daten, da sie über das Netzwerk übertragen werden, um auf einem Remotebildschirm angezeigt zu werden. Sowohl die niedrige als auch die mittlere Verschlüsselung verwenden den Microsoft-RC4-Algorithmus (modifizierter RC4-Algorithmus mit verbesserter Leistung) mit einem 40-Bit-Schlüssel. Die hohe Verschlüsselung verschlüsselt Pakete in beide Richtungen, zum und vom Client, verwendet jedoch den RC4-Verschlüsselungsalgorithmus nach Industriestandard, wieder mit einem 40-Bit-Schlüssel. Eine Nicht-Exportversion von Windows NT Terminal Server bietet eine 128-Bit-RC4-Verschlüsselung auf hoher Ebene.

Zwischen Client und Server wird ein Schriftartenaustausch durchgeführt, um zu bestimmen, welche gängigen 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 auf dem Client verfügbar sind, können Sie Netzwerkbandbreite sparen, indem Sie komprimierte Schriftarten und Unicode-Zeichenfolgen 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 wie Symbolen, Symbolleisten, Cursorn usw. verwendet wird, aber nicht zum Speichern von Unicode-Zeichenfolgen verwendet wird. Der Cache kann (über einen Registrierungsschlüssel) angepasst und mit einem LRU-Algorithmus (Least Recently Used) überschrieben werden. Der Terminalserver enthält auch Puffer, um die flussgesteuerte Übergabe von Bildschirmaktualisierungen an Clients anstelle eines konstanten Bitstreams zu ermöglichen. 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 stattfindet, wird der Puffer so verlangsamt, dass er nur 10 Mal pro Sekunde geleert wird. Sie können alle diese Nummern über die Registrierung optimieren.

Nachdem die Sitzungsdetails ausgehandelt wurden, wird der RDP-Instance des Servers für diese Verbindung einer vorhandenen Win32k-Benutzersitzung im Leerlauf zugeordnet, und der Benutzer wird mit dem Windows NT-Anmeldebildschirm aufgefordert. Wenn die automatische Anmeldung konfiguriert ist, werden 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 Sitzungs-Manager (SMSS) auf, um einen neuen Benutzerbereich für die neue Sitzung zu erstellen. Ein Großteil der Win32k-Benutzersitzung verwendet freigegebenen Code und wird deutlich schneller geladen, nachdem zuvor ein instance geladen wurde.

Nachdem der Benutzer einen Benutzernamen und ein Kennwort eingegeben hat, werden Pakete verschlüsselt an den Terminalserver gesendet. Der Winlogon-Prozess führt dann die erforderliche Kontoauthentifizierung durch, um sicherzustellen, dass der Benutzer über die Berechtigung zum Anmelden verfügt, und übergibt die Domäne und den Benutzernamen des Benutzers an den Terminalserverdienst, der eine SessionID-Liste für Domäne/Benutzername verwaltet. Wenn diesem Benutzer bereits eine SessionID zugeordnet ist (z. B. wenn eine getrennte Sitzung vorhanden ist), wird der derzeit aktive Sitzungsstapel an die alte Sitzung angefügt. Die temporäre Win32-Sitzung, die für die erste Anmeldung verwendet wird, wird dann gelöscht. Andernfalls wird die Verbindung wie gewohnt fortgesetzt, und der Terminalserverdienst erstellt eine neue Domäne/Benutzername SessionID-Zuordnung. Wenn aus irgendeinem Grund mehr als eine Sitzung für diesen Benutzer 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 Benutzeranmeldung 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 (2 GB-Anwendung, 2-GB-Kernel) startet. Alle Prozesse auf dem Terminalserver geben Code im Kernel- und Benutzermodus frei, wo immer möglich. Um die gemeinsame Nutzung von Code zwischen Prozessen zu erreichen, verwendet der Windows NT Virtual Memory-Manager (VM) den Seitenschutz zum Kopieren bei Schreibvorgängen. Wenn mehrere Prozesse denselben Speicherinhalt lesen und schreiben möchten, weist der VM-Manager dem Speicherbereich Seitenschutz zum Kopieren beim Schreiben zu. Die Prozesse (Sitzungen) verwenden denselben Speicherinhalt, bis ein Schreibvorgang ausgeführt wird. Zu diesem Zeitpunkt kopiert der VM-Manager den physischen Seitenrahmen an einen anderen Speicherort, aktualisiert die virtuelle Adresse des Prozesses so, dass er auf den neuen Seitenspeicherort verweist, und markiert die Seite nun als Lese-/Schreibzugriff. Copy-On-Write ist nützlich und effizient für Anwendungen, die auf einem Terminalserver ausgeführt werden.

Wenn eine Win32-basierte Anwendung wie Microsoft Word von einem Prozess (Sitzung) in den physischen Speicher geladen wird, wird sie als "Copy-On-Write" markiert. Wenn neue Prozesse (Sitzungen) auch Word aufrufen, verweist das Imageloader nur 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 als Lese-/Schreibzugriff für den einzelnen Prozess (Sitzung) markiert. Der VM-Manager schützt diesen Speicherplatz vor anderen Prozessen. Der Großteil einer Anwendung ist jedoch freigegebener Code und verfügt nur über eine einzelne instance 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 die gemeinsame Nutzung von Code und die effizientere Ausführung in Sitzungen mit mehreren Benutzern. Windows NT ermöglicht die Ausführung von 16-Bit-Anwendungen (Win16) in einer Win32-Umgebung, indem für jede Win16-Anwendung ein virtueller MS-DOS-basierter Computer (VDM) erstellt wird. Die gesamte 16-Bit-Ausgabe wird in Win32-Aufrufe übersetzt, die die erforderlichen Aktionen ausführen. Da Win16-Apps in ihrem eigenen VDM ausgeführt werden, kann Code nicht in mehreren Sitzungen von Anwendungen gemeinsam genutzt werden. Die Übersetzung zwischen Win16- und Win32-Aufrufen verbraucht auch Systemressourcen. Die Ausführung von Win16-Anwendungen in einer Terminalserverumgebung kann potenziell doppelt so viele Ressourcen verbrauchen wie eine vergleichbare Win32-basierte Anwendung.

Sitzungstrennung und Benutzerabmeldung

Sitzung trennen

Wenn ein Benutzer entscheidet, die Sitzung zu trennen, bleiben die Prozesse und der gesamte virtuelle Speicherplatz erhalten und werden auf den physischen Datenträger ausgelagert, wenn physischer Arbeitsspeicher für andere Prozesse erforderlich ist. Da der Terminalserver eine Zuordnung der Domäne/des Benutzernamens und der zugehörigen SessionID beibehält, wird die vorhandene Sitzung geladen und wieder verfügbar gemacht, wenn derselbe Benutzer erneut eine Verbindung herstellt. Ein weiterer Vorteil von RDP ist, dass es die Auflösung von Sitzungsbildschirmen ändern kann, je nachdem, was der Benutzer für die Sitzung anfordert. Angenommen, ein Benutzer hatte zuvor eine Verbindung mit einer Terminalserversitzung mit einer Auflösung von 800 x 600 hergestellt und die Verbindung getrennt. Wenn der Benutzer dann zu einem anderen Computer wechselt, der nur eine Auflösung von 640 x 480 unterstützt, und wieder eine Verbindung mit der vorhandenen Sitzung herstellen, wird der Desktop neu gezeichnet, um die neue Auflösung zu unterstützen.

Benutzer-Abmeldung

Die Abmeldung ist in der Regel einfach zu implementieren. Nachdem sich ein Benutzer von der Sitzung abmeldet, werden alle prozesse, die der SessionID zugeordnet sind, beendet, und der Sitzung zugeordneter Arbeitsspeicher wird freigegeben. Wenn der Benutzer eine 32-Bit-Anwendung wie Microsoft Word ausführt und sich von der Sitzung abmeldet, bleibt der Code der Anwendung selbst im Arbeitsspeicher, bis der letzte Benutzer die Anwendung verlassen hat.