Procédure pas à pas du serveur terminal : démarrage, connexion et application

Cet article décrit le processus d’initialisation d’un serveur terminal et décrit ce qui se produit lorsqu’un utilisateur se connecte au serveur et exécute une application.

S’applique à : Windows Server 2012 R2
Numéro de base de connaissances d’origine : 186572

Terminal Windows l’initialisation du serveur

À mesure que le serveur Terminal Windows démarre et charge le système d’exploitation principal, le service Terminal Server (Termsrv.exe) est démarré et crée des piles d’écoute (une par protocole et paire de transport) qui écoutent les connexions entrantes. Chaque connexion reçoit un identificateur de session unique ou « SessionID » pour représenter une session individuelle sur le serveur terminal. Chaque processus créé au sein d’une session est « marqué » avec l’ID de session associé pour différencier son espace de noms de l’espace de noms d’une autre connexion.

La session de console (clavier Terminal Server, souris et vidéo) est toujours la première à se charger et est traitée comme une connexion client à cas spécial et un SessionID attribué. La session de console démarre comme une session système Windows NT normale avec l’affichage Windows NT configuré, la souris et les pilotes clavier chargés.

Le service Terminal Server appelle ensuite le Gestionnaire de sessions Windows NT (Smss.exe) pour créer deux sessions client inactives (par défaut = 2) (après avoir créé la session console) qui attendent les connexions client. Pour créer les sessions inactives, le Gestionnaire de session exécute le processus de sous-système de runtime client/serveur windows NT (Csrss.exe) et un nouvel ID de session est affecté à ce processus. Le processus CSRSS appelle également le processus Winlogon (Winlogon.exe) et le module de noyau Win32k.sys (Gestionnaire de fenêtres et interface de périphérique graphique - GDI) sous le sessionID qui vient d’être associé. Le chargeur d’images Windows NT modifié reconnaît cette Win32k.sys en tant qu’image pouvant être chargée par SessionSpace par un jeu de bits prédéfini dans l’en-tête d’image. Il déplace ensuite la partie de code de l’image dans la mémoire physique, avec des pointeurs de l’espace d’adressage du noyau virtuel pour cette session, si Win32k.sys n’a pas déjà été chargé. Par conception, il est toujours attaché au code d’une image précédemment chargée (Win32k.sys) s’il en existe déjà une en mémoire. Par exemple, à partir d’une application ou d’une session active.

La section données (ou non partagées) de cette image sera ensuite allouée à la nouvelle session à partir d’une section mémoire du noyau paginé SessionSpace nouvellement créée. Contrairement à la session console, les sessions du client Terminal Server sont configurées pour charger des pilotes distincts pour l’affichage, le clavier et la souris.

Le nouveau pilote d’affichage est le pilote d’appareil d’affichage RDP (Remote Desktop Protocol), Tsharedd.dll. Les pilotes de souris et de clavier communiquent dans la pile via le gestionnaire de pile à plusieurs instances, termdd.sys. Termdd.sys envoie les messages pour l’activité de souris et de clavier vers et depuis le pilote RDP, Wdtshare.sys. Ces pilotes permettent à la session cliente RDP d’être disponible à distance et interactive. Enfin, Terminal Server appelle également un thread d’écouteur de connexion pour le protocole RDP, de nouveau géré par le gestionnaire de pile à plusieurs instances (Termdd.sys), qui écoute les connexions clientes RDP sur le port TCP 3389.

À ce stade, le processus CSRSS existe sous son propre espace de noms SessionID, avec ses données instanciées par processus si nécessaire. Tous les processus créés à partir de cet ID de session s’exécutent automatiquement dans l’espace de session du processus CSRSS. Cela empêche les processus avec différents SessionID d’accéder aux données d’une autre session.

Connexion client

Le client RDP peut être installé et exécuté sur n’importe quel terminal Windows (basé sur WinCE), Windows pour Workgroups 3.11 exécutant TCP/IP-32b ou la plateforme basée sur l’API Microsoft Win32. Les clients non windows sont pris en charge par le module complémentaire Citrix Metaframe. Le fichier exécutable du client RDP Windows for Workgroups a une taille d’environ 70 Ko, utilise un jeu de travail de 300 Ko et utilise 100 Ko pour afficher les données. Le client Win32 a une taille d’environ 130 Ko, utilise un jeu de travail de 300 Ko et 100 Ko pour les données d’affichage.

Le client initialise une connexion au serveur terminal via le port TCP 3389. Le thread d’écouteur RDP Terminal Server détecte la demande de session et crée une instance de pile RDP pour gérer la nouvelle demande de session. Le thread d’écouteur passe la session entrante à la nouvelle instance de pile RDP et continue à écouter sur le port TCP 3389 pour d’autres tentatives de connexion. Chaque pile RDP est créée à mesure que les sessions clientes sont connectées pour gérer la négociation des détails de configuration de session. Les premiers détails seront d’établir un niveau de chiffrement pour la session. Le serveur terminal prend initialement en charge trois niveaux de chiffrement : faible, moyen et élevé.

Un chiffrement faible chiffre uniquement les paquets envoyés du client au serveur terminal. Ce chiffrement d’entrée uniquement permet de protéger l’entrée de données sensibles, telles que le mot de passe d’un utilisateur. Le chiffrement moyen chiffre les paquets sortants du client de la même façon que le chiffrement de bas niveau, mais chiffre également tous les paquets d’affichage retournés au client à partir du serveur terminal. Cette méthode de chiffrement sécurise les données sensibles à mesure qu’elles transitent sur le réseau pour être affichées sur un écran distant. Le chiffrement faible et moyen utilise l’algorithme Microsoft-RC4 (algorithme RC4 modifié avec des performances améliorées) avec une clé 40 bits. Un chiffrement élevé chiffre les paquets dans les deux sens, vers et depuis le client, mais utilise l’algorithme de chiffrement RC4 standard du secteur, à nouveau avec une clé 40 bits. Une version non exportée de Windows NT Terminal Server fournit un chiffrement RC4 de haut niveau 128 bits.

Un échange de polices se produit entre le client et le serveur pour déterminer les polices système courantes installées. Le client notifie le serveur terminal de toutes les polices système installées, afin d’accélérer le rendu du texte pendant une session RDP. Lorsque le serveur terminal sait quelles polices le client a disponibles, vous pouvez économiser la bande passante réseau en transmettant des chaînes de caractères Unicode et de police compressée, plutôt que des bitmaps plus volumineux, au client.

Par défaut, tous les clients réservent 1,5 Mo de mémoire pour un cache bitmap utilisé pour mettre en cache des bitmaps, tels que des icônes, des barres d’outils, des curseurs, etc., mais qui n’est pas utilisé pour contenir des chaînes Unicode. Le cache est réglable (via une clé de Registre) et remplacé à l’aide d’un algorithme LRU (Least Recently Used). Le serveur terminal contient également des mémoires tampons pour permettre le passage contrôlé par le flux des actualisations d’écran aux clients, plutôt qu’un flux de bits constant. Lorsque l’interaction utilisateur au niveau du client est élevée, la mémoire tampon est vidée environ 20 fois par seconde. Pendant le temps d’inactivité, ou en l’absence d’interaction de l’utilisateur, la mémoire tampon est ralentie pour ne vider que 10 fois par seconde. Vous pouvez régler tous ces nombres par le biais du Registre.

Une fois les détails de session négociés, l’instance de pile RDP du serveur pour cette connexion est mappée à une session utilisateur Win32k inactive existante, et l’utilisateur est invité à utiliser l’écran d’ouverture de session Windows NT. Si l’autologon est configuré, le nom d’utilisateur et le mot de passe chiffrés sont transmis au serveur terminal et l’ouverture de session se poursuit. S’il n’existe actuellement aucune session Win32k inactive, le service Terminal Server appelle le Gestionnaire de sessions (SMSS) pour créer un espace utilisateur pour la nouvelle session. Une grande partie de la session utilisateur Win32k utilise du code partagé et se charge sensiblement plus rapidement après le chargement d’une instance.

Une fois que l’utilisateur a tape un nom d’utilisateur et un mot de passe, les paquets sont envoyés chiffrés au serveur terminal. Le processus Winlogon effectue ensuite l’authentification de compte nécessaire pour s’assurer que l’utilisateur a le privilège de se connecter et transmet le domaine et le nom d’utilisateur de l’utilisateur au service Terminal Server, qui gère une liste SessionID de domaine/nom d’utilisateur. Si un SessionID est déjà associé à cet utilisateur (par exemple, une session déconnectée existe), la pile de sessions actuellement active est attachée à l’ancienne session. La session Win32 temporaire utilisée pour l’ouverture de session initiale est ensuite supprimée. Sinon, la connexion se poursuit normalement et le service Terminal Server crée un mappage SessionID de domaine/nom d’utilisateur. Si, pour une raison quelconque, plusieurs sessions sont actives pour cet utilisateur, la liste des sessions s’affiche et l’utilisateur décide lequel sélectionner pour la reconnexion.

Exécution d’une application

Après l’ouverture de session de l’utilisateur, le bureau (ou l’application en mode mono-application) s’affiche pour l’utilisateur. Lorsque l’utilisateur sélectionne une application 32 bits à exécuter, les commandes de la souris sont transmises au serveur terminal, qui lance l’application sélectionnée dans un nouvel espace de mémoire virtuel (application de 2 Go, noyau de 2 Go). Dans la mesure du possible, tous les processus sur le serveur terminal partagent du code en mode noyau et utilisateur. Pour obtenir le partage de code entre les processus, le gestionnaire de mémoire virtuelle Windows NT utilise la protection de page de copie en écriture. Lorsque plusieurs processus souhaitent lire et écrire le même contenu mémoire, le gestionnaire de machines virtuelles affecte la protection de la page de copie en écriture à la région mémoire. Les processus (sessions) utilisent le même contenu de mémoire jusqu’à ce qu’une opération d’écriture soit effectuée, auquel cas le gestionnaire de machine virtuelle copie le cadre de page physique vers un autre emplacement, met à jour l’adresse virtuelle du processus pour pointer vers le nouvel emplacement de la page et marque désormais la page comme lecture/écriture. La copie en écriture est utile et efficace pour les applications s’exécutant sur un serveur terminal.

Lorsqu’une application Win32 telle que Microsoft Word est chargée dans la mémoire physique par un processus (session), elle est marquée en tant que copie en écriture. Lorsque de nouveaux processus (sessions) appellent également Word, le chargeur d’images pointe simplement les nouveaux processus (Sessions) vers la copie existante, car l’application est déjà chargée en mémoire. Lorsque des mémoires tampons et des données spécifiques à l’utilisateur sont requises (par exemple, l’enregistrement dans un fichier), les pages nécessaires sont copiées dans un nouvel emplacement de mémoire physique et marquées comme lecture/écriture pour le processus individuel (session). Le gestionnaire de machines virtuelles protège cet espace mémoire contre d’autres processus. Toutefois, la plupart d’une application est du code partageable et n’aura qu’une seule instance de code en mémoire physique, quel que soit le nombre de fois où elle est exécutée.

Il est préférable (bien que cela ne soit pas nécessaire) d’exécuter des applications 32 bits dans un environnement Terminal Server. Les applications 32 bits (Win32) permettent le partage de code et s’exécutent plus efficacement dans les sessions multi-utilisateurs. Windows NT permet aux applications 16 bits (Win16) de s’exécuter dans un environnement Win32 en créant un ordinateur virtuel basé sur MS-DOS (VDM) pour chaque application Win16 à exécuter. Toutes les sorties 16 bits sont traduites en appels Win32, qui effectuent les actions nécessaires. Étant donné que les applications Win16 s’exécutent dans leur propre machine virtuelle, le code ne peut pas être partagé entre les applications dans plusieurs sessions. La traduction entre les appels Win16 et Win32 consomme également des ressources système. L’exécution d’applications Win16 dans un environnement Terminal Server peut potentiellement consommer deux fois plus de ressources qu’une application Win32 comparable.

Déconnexion de session et fermeture de session de l’utilisateur

Déconnexion de session

Si un utilisateur décide de déconnecter la session, les processus et tout l’espace mémoire virtuelle restent et sont pagagés sur le disque physique, si la mémoire physique est requise pour d’autres processus. Étant donné que terminal Server conserve un mappage de domaine/nom d’utilisateur et de son ID de session associé, lorsque le même utilisateur se reconnecte, la session existante est chargée et rendue à nouveau disponible. Un autre avantage de RDP est qu’il est en mesure de modifier les résolutions d’écran de session, en fonction de ce que l’utilisateur demande pour la session. Par exemple, supposons qu’un utilisateur s’était précédemment connecté à une session Terminal Server avec une résolution de 800 x 600 et qu’il s’était déconnecté. Si l’utilisateur passe ensuite à un autre ordinateur qui prend en charge uniquement la résolution 640 x 480 et se reconnecte à la session existante, le bureau est redessiné pour prendre en charge la nouvelle résolution.

Ouverture de session de l’utilisateur

La fermeture de session est généralement simple à implémenter. Une fois qu’un utilisateur s’est déconnecté de la session, tous les processus associés à l’ID de session sont arrêtés et toute mémoire allouée à la session est libérée. Si l’utilisateur exécute une application 32 bits telle que Microsoft Word et se déconnecte de la session, le code de l’application elle-même reste en mémoire jusqu’à ce que le dernier utilisateur quitte l’application.