Overzicht van terminalserver: opstarten, verbinding en toepassing

In dit artikel wordt het initialisatieproces van een Terminal Server beschreven en wordt beschreven wat er gebeurt wanneer een gebruiker verbinding maakt met de server en een toepassing uitvoert.

Oorspronkelijk KB-nummer: 186572

Initialisatie van Windows Terminal Server

Wanneer de Windows Terminal Server het kernbesturingssysteem opstart en laadt, wordt de Terminal Server-service (Termsrv.exe) gestart en worden luisterende stacks (één per protocol en transportpaar) gemaakt die luisteren naar binnenkomende verbindingen. Elke verbinding krijgt een unieke sessie-id of 'SessionID' die een afzonderlijke sessie aan de Terminal Server vertegenwoordigt. Elk proces dat in een sessie is gemaakt, wordt 'gelabeld' met de bijbehorende SessionID om de naamruimte van een andere verbinding te onderscheiden van de naamruimte van een andere verbinding.

De consolesessie (Terminal Server-toetsenbord, muis en video) is altijd de eerste die moet worden geladen en wordt behandeld als een speciale clientverbinding en toegewezen SessionID. De consolesessie wordt gestart als een normale Windows NT-systeemsessie met de geconfigureerde Windows NT-weergave, muis en toetsenbordstuurprogramma's geladen.

De Terminal Server-service roept vervolgens Windows NT Session Manager (Smss.exe) aan om twee (standaard = 2) niet-actieve clientsessies te maken (na het maken van de consolesessie) die wachten op clientverbindingen. Als u de niet-actieve sessies wilt maken, voert Session Manager het windows NT-subsysteemproces voor client-/serverruntime (Csrss.exe) uit en wordt er een nieuwe SessionID toegewezen aan dat proces. Het CSRSS-proces roept ook het Winlogon-proces (Winlogon.exe) en de kernelmodule Win32k.sys (Window Manager en graphics device interface - GDI) onder de zojuist gekoppelde SessionID aan. Het gewijzigde windows NT-installatiekopieënlaadprogramma herkent deze Win32k.sys als een SessionSpace-loadable installatiekopieën door een vooraf gedefinieerde bit die is ingesteld in de afbeeldingskoptekst. Vervolgens wordt het codegedeelte van de installatiekopieën verplaatst naar het fysieke geheugen, met aanwijzers van de adresruimte van de virtuele kernel voor die sessie, als Win32k.sys nog niet is geladen. Standaard wordt deze altijd gekoppeld aan de code (Win32k.sys) van een eerder geladen installatiekopieën als deze al in het geheugen aanwezig is. Bijvoorbeeld vanuit een actieve toepassing of sessie.

De gegevenssectie (of niet-gedeeld) van deze installatiekopieën wordt vervolgens toegewezen aan de nieuwe sessie vanuit een zojuist gemaakte sessieruimte voor paginabaar kernelgeheugen. In tegenstelling tot de consolesessie worden Terminal Server-clientsessies geconfigureerd om afzonderlijke stuurprogramma's voor het beeldscherm, het toetsenbord en de muis te laden.

Het nieuwe beeldschermstuurprogramma is het rdp-apparaatstuurprogramma (Remote Desktop Protocol) Tsharedd.dll. De muis- en toetsenbordstuurprogramma's communiceren met de stack via de stack met meerdere exemplaren, termdd.sys. Termdd.sys verzendt de berichten voor muis- en toetsenbordactiviteit naar en van het RDP-stuurprogramma Wdtshare.sys. Met deze stuurprogramma's kan de RDP-clientsessie extern beschikbaar en interactief zijn. Ten slotte roept Terminal Server ook een verbindingslistenerthread aan voor het RDP-protocol, opnieuw beheerd door het beheer van meerdere exemplarenstackbeheer (Termdd.sys), die luistert naar RDP-clientverbindingen op TCP-poortnummer 3389.

Op dit moment bestaat het CSRSS-proces onder een eigen SessionID-naamruimte, waarbij de gegevens zo nodig per proces worden geïnstantieerd. Alle processen die zijn gemaakt vanuit deze SessionID, worden automatisch uitgevoerd in de SessionSpace van het CSRSS-proces. Hiermee voorkomt u dat processen met verschillende sessionID's toegang hebben tot de gegevens van een andere sessie.

Clientverbinding

De RDP-client kan worden geïnstalleerd en uitgevoerd op elke Windows-terminal (op basis van WinCE), Windows for Workgroups 3.11 met TCP/IP-32b of het Microsoft Win32 API-platform. Niet-Windows-clients worden ondersteund door de Citrix Metaframe-invoegtoepassing. Het uitvoerbare bestand van de RDP-client van Windows for Workgroups is ongeveer 70 kB groot, maakt gebruik van een werkset van 300 kB en gebruikt 100 kB voor weergavegegevens. De Win32-client is ongeveer 130 kB groot, gebruikt een werkset van 300 kB en 100 kB voor het weergeven van gegevens.

De client start een verbinding met de terminalserver via TCP-poort 3389. De Terminal Server RDP-listenerthread detecteert de sessieaanvraag en maakt een nieuw RDP-stackexemplaren om de nieuwe sessieaanvraag af te handelen. De listener-thread geeft de binnenkomende sessie over aan het nieuwe RDP-stackexemplaren en blijft luisteren op TCP-poort 3389 voor verdere verbindingspogingen. Elke RDP-stack wordt gemaakt als de clientsessies zijn verbonden om de onderhandeling van sessieconfiguratiegegevens af te handelen. De eerste details zijn het instellen van een versleutelingsniveau voor de sessie. De Terminal Server ondersteunt in eerste instantie drie versleutelingsniveaus: laag, gemiddeld en hoog.

Met lage versleuteling worden alleen pakketten versleuteld die van de client naar de Terminal Server worden verzonden. Deze 'alleen invoer'-versleuteling is bedoeld om de invoer van gevoelige gegevens, zoals het wachtwoord van een gebruiker, te beveiligen. Met middelmatige versleuteling worden uitgaande pakketten van de client hetzelfde versleuteld als versleuteling op laag niveau, maar worden ook alle weergavepakketten die vanaf de terminalserver naar de client worden geretourneerd, versleuteld. Deze versleutelingsmethode beveiligt gevoelige gegevens, omdat deze via het netwerk worden weergegeven op een extern scherm. Zowel lage als gemiddelde versleuteling maken gebruik van het Microsoft-RC4-algoritme (aangepast RC4-algoritme met verbeterde prestaties) met een 40-bits sleutel. Met hoge versleuteling worden pakketten in beide richtingen, van en naar de client versleuteld, maar wordt het standaard RC4-versleutelingsalgoritmen van de industrie gebruikt, opnieuw met een 40-bits sleutel. Een niet-exportversie van Windows NT Terminal Server biedt 128-bits RC4-versleuteling op hoog niveau.

Er wordt een lettertype-uitwisseling uitgevoerd tussen de client en de server om te bepalen welke algemene systeemlettertypen worden geïnstalleerd. De client informeert de Terminal Server over alle geïnstalleerde systeemlettertypen om sneller tekst weer te geven tijdens een RDP-sessie. Wanneer de Terminal Server weet welke lettertypen de client beschikbaar heeft, kunt u netwerkbandbreedte besparen door gecomprimeerde lettertype- en Unicode-tekenreeksen door te geven in plaats van grotere bitmaps aan de client.

Standaard reserveren alle clients 1,5 MB geheugen voor een bitmapcache die wordt gebruikt voor het opslaan van bitmaps, zoals pictogrammen, werkbalken, cursors, enzovoort, maar wordt niet gebruikt voor het opslaan van Unicode-tekenreeksen. De cache kan (via een registersleutel) niet worden overschreven met behulp van een LRU-algoritme (Least Recently Used). De Terminal Server bevat ook buffers voor het inschakelen van stroomgestuurde weergave van schermvernieuwingen aan clients, in plaats van een constante bitstream. Wanneer gebruikersinteractie op de client hoog is, wordt de buffer ongeveer 20 keer per seconde leeggemaakt. Tijdens niet-actieve tijd of wanneer er geen gebruikersinteractie is, wordt de buffer slechts 10 keer per seconde leeggemaakt. U kunt al deze getallen afstemmen via het register.

Nadat er over sessiedetails is onderhandeld, wordt het server-RDP-stackexemplaren voor deze verbinding toegewezen aan een bestaande niet-actieve Win32k-gebruikerssessie en wordt de gebruiker gevraagd met het aanmeldingsscherm van Windows NT. Als automatisch aanmelden is geconfigureerd, worden de versleutelde gebruikersnaam en het versleutelde wachtwoord doorgegeven aan de Terminal Server en wordt de aanmelding voortgezet. Als er momenteel geen niet-actieve Win32k-sessies bestaan, roept de Terminal Server-service smss (Session Manager) aan om een nieuwe gebruikersruimte voor de nieuwe sessie te maken. Veel van de Win32k-gebruikerssessie maakt gebruik van gedeelde code en wordt aanzienlijk sneller geladen nadat één exemplaar eerder is geladen.

Nadat de gebruiker een gebruikersnaam en wachtwoord heeft opgegeven, worden pakketten versleuteld verzonden naar de Terminal Server. Het Winlogon-proces voert vervolgens de benodigde accountverificatie uit om ervoor te zorgen dat de gebruiker gemachtigd is om zich aan te melden en het domein en de gebruikersnaam van de gebruiker door te geven aan de Terminal Server-service, die een sessie-id-lijst met domein/gebruikersnaam onderhoudt. Als er al een SessionID aan deze gebruiker is gekoppeld (bijvoorbeeld een niet-verbonden sessie bestaat), wordt de huidige actieve sessiestack gekoppeld aan de oude sessie. De tijdelijke Win32-sessie die wordt gebruikt voor de eerste aanmelding, wordt vervolgens verwijderd. Anders verloopt de verbinding als normaal en maakt de Terminal Server-service een nieuwe sessionID-toewijzing van een domein/gebruikersnaam. Als om een of andere reden meer dan één sessie actief is voor deze gebruiker, wordt de lijst met sessies weergegeven en bepaalt de gebruiker welke moet worden geselecteerd voor opnieuw verbinding maken.

Een toepassing uitvoeren

Nadat de gebruiker zich heeft aangemeld, wordt het bureaublad (of de toepassing in de modus voor één toepassing) weergegeven voor de gebruiker. Wanneer de gebruiker een 32-bits toepassing selecteert die moet worden uitgevoerd, worden de muisopdrachten doorgegeven aan de Terminal Server, waarmee de geselecteerde toepassing wordt gestart in een nieuwe virtuele geheugenruimte (2 GB-toepassing, 2 GB-kernel). Alle processen op de Terminal Server delen waar mogelijk code in kernel- en gebruikersmodi. Voor het delen van code tussen processen maakt windows NT Virtual Memory (VM)-beheer gebruik van copy-on-write-paginabeveiliging. Wanneer meerdere processen dezelfde geheugeninhoud willen lezen en schrijven, wijst de VM-beheerder beveiliging op paginakopieën toe aan de geheugenregio. De processen (sessies) gebruiken dezelfde geheugeninhoud totdat een schrijfbewerking wordt uitgevoerd. Op dat moment kopieert de VM-beheerder het fysieke paginaframe naar een andere locatie, werkt u het virtuele adres van het proces bij zodat deze verwijst naar de nieuwe paginalocatie en markeert u de pagina als lezen/schrijven. Copy-on-write is handig en efficiënt voor toepassingen die worden uitgevoerd op een Terminal Server.

Wanneer een Win32-toepassing zoals Microsoft Word met één proces (sessie) in het fysieke geheugen wordt geladen, wordt deze gemarkeerd als copy-on-write. Wanneer nieuwe processen (sessies) ook Word aanroepen, wijst het installatiekopielaadprogramma alleen de nieuwe processen (sessies) aan op de bestaande kopie omdat de toepassing al in het geheugen is geladen. Wanneer buffers en gebruikersspecifieke gegevens vereist zijn (bijvoorbeeld opslaan in een bestand), worden de benodigde pagina's gekopieerd naar een nieuwe fysieke geheugenlocatie en gemarkeerd als lezen/schrijven voor het afzonderlijke proces (sessie). De VM-manager beveiligt deze geheugenruimte tegen andere processen. Het grootste deel van een toepassing is echter deelbare code en heeft slechts één exemplaar van code in het fysieke geheugen, ongeacht hoe vaak deze wordt uitgevoerd.

Het verdient de voorkeur (hoewel niet nodig) om 32-bits toepassingen uit te voeren in een Terminal Server-omgeving. Met de 32-bits toepassingen (Win32) kan code worden gedeeld en efficiënter worden uitgevoerd in sessies met meerdere gebruikers. Met Windows NT kunnen 16-bits toepassingen (Win16) worden uitgevoerd in een Win32-omgeving door voor elke Win16-toepassing een virtuele MS-DOS-computer (VDM) te maken. Alle 16-bits uitvoer wordt omgezet in Win32-aanroepen, die de benodigde acties uitvoeren. Omdat Win16-apps worden uitgevoerd binnen hun eigen VDM, kan code niet worden gedeeld tussen toepassingen in meerdere sessies. Vertaling tussen Win16- en Win32-aanroepen verbruikt ook systeembronnen. Het uitvoeren van Win16-toepassingen in een Terminal Server-omgeving kan mogelijk tweemaal de resources verbruiken dan een vergelijkbare Win32-toepassing.

Sessie verbreken en afmelden van gebruiker

Sessie verbreken

Als een gebruiker besluit de sessie te verbreken, blijven de processen en alle ruimte voor het virtuele geheugen behouden en worden ze naar de fysieke schijf gepaginad als fysiek geheugen vereist is voor andere processen. Omdat de Terminal Server een toewijzing van domein/gebruikersnaam en de bijbehorende SessionID behoudt, wordt de bestaande sessie geladen en opnieuw beschikbaar gesteld wanneer dezelfde gebruiker opnieuw verbinding maakt. Een extra voordeel van RDP is dat het de resolutie van het sessiescherm kan wijzigen, afhankelijk van wat de gebruiker voor de sessie aanvraagt. Stel dat een gebruiker eerder verbinding had gemaakt met een Terminal Server-sessie met een resolutie van 800 x 600 en de verbinding is verbroken. Als de gebruiker vervolgens naar een andere computer gaat die slechts 640 x 480 resolutie ondersteunt en opnieuw verbinding maakt met de bestaande sessie, wordt het bureaublad opnieuw getekend om de nieuwe resolutie te ondersteunen.

Gebruikersaanmelding

Afmelden is doorgaans eenvoudig te implementeren. Nadat een gebruiker zich afmeldt bij de sessie, worden alle processen die zijn gekoppeld aan de SessionID beëindigd en wordt het geheugen dat aan de sessie is toegewezen, vrijgegeven. Als de gebruiker een 32-bits toepassing uitvoert, zoals Microsoft Word, en zich afmeldt bij de sessie, blijft de code van de toepassing zelf in het geheugen totdat de laatste gebruiker is afgesloten van de toepassing.