Procédure pas à pas de Terminal Server : démarrage, connexion et application
Cet article décrit le processus d’initialisation d’un serveur Terminal Server et décrit ce qui se produit lorsqu’un utilisateur se connecte au serveur et exécute une application.
Numéro de base de connaissances d’origine : 186572
Initialisation du serveur Terminal Windows
À 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 paire de protocole et de transport) qui écoutent les connexions entrantes. Chaque connexion reçoit un identificateur de session unique ou « SessionID » pour représenter une session individuelle au serveur Terminal Server. Chaque processus créé dans 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 console (clavier, souris et vidéo Terminal Server) est toujours la première à charger et est traitée comme une connexion cliente spéciale et affectée à SessionID. La session de console démarre en tant que session système Windows NT normale avec les pilotes windows NT configurés chargés.
Le service Terminal Server appelle ensuite le Gestionnaire de sessions Windows NT (Smss.exe) pour créer deux sessions clientes inactives (par défaut = 2) (après la création de la session de console) qui attendent les connexions clientes. Pour créer les sessions inactives, le Gestionnaire de sessions exécute le processus du sous-système d’exécution 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 (Window Manager et interface de périphérique graphique - GDI) sous l’ID de session nouvellement 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 en 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 de n’importe quelle application ou session active.
La section données (ou non partagée) de cette image sera ensuite allouée à la nouvelle session à partir d’une section de mémoire du noyau paginable SessionSpace nouvellement créée. Contrairement à la session de 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 de périphérique d’affichage RDP (Remote Desktop Protocol), Tsharedd.dll. Les pilotes de souris et de clavier communiquent dans la pile via le gestionnaire de pile d’instances multiples, termdd.sys. Termdd.sys envoie les messages pour l’activité de la souris et du 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, à nouveau géré par le gestionnaire de pile de plusieurs instances (Termdd.sys), qui écoute les connexions clientES RDP sur le numéro de 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 ID de session 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 for 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 est d’environ 70 Ko, utilise un ensemble de travail de 300 Ko et utilise 100 Ko pour les données d’affichage. Le client Win32 est d’environ 130 Ko de taille, utilise un jeu de travail de 300 Ko et 100 Ko pour les données d’affichage.
Le client lance une connexion au serveur Terminal Server 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 transférera la session entrante à la nouvelle instance de pile RDP et continuera à écouter sur le port TCP 3389 pour les tentatives de connexion supplémentaires. 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 Server prend initialement en charge trois niveaux de chiffrement : faible, moyen et élevé.
Le chiffrement faible chiffre uniquement les paquets envoyés du client au serveur Terminal Server. Ce chiffrement d’entrée uniquement consiste à protéger l’entrée des données sensibles, telles que le mot de passe d’un utilisateur. Le chiffrement moyen chiffre les paquets sortants du client identiques au chiffrement de bas niveau, mais chiffre également tous les paquets d’affichage retournés au client à partir du serveur Terminal Server. Cette méthode de chiffrement sécurise les données sensibles, car 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. Le 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 quelles polices système courantes sont installées. Le client avertit le serveur Terminal Server de toutes les polices système installées pour permettre un rendu plus rapide du texte pendant une session RDP. Lorsque le serveur Terminal Server sait quelles polices le client a disponibles, vous pouvez économiser de la bande passante réseau en passant des chaînes de caractères compressées et Unicode, plutôt que des bitmaps plus volumineuses, 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, telles 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 paramétrable (par le biais d’une clé de Registre) et remplacé à l’aide d’un algorithme LRU (Minimum Récemment Utilisé). Terminal Server contient également des mémoires tampons pour permettre le passage contrôlé par flux d’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 lorsqu’il n’y a pas d’interaction utilisateur, la mémoire tampon est ralentie pour vider seulement 10 fois par seconde. Vous pouvez régler tous ces nombres via le 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 la connexion automatique est configurée, le nom d’utilisateur et le mot de passe chiffrés sont transmis au serveur Terminal Server et l’ouverture de session se poursuit. Si aucune session Win32k inactive n’existe actuellement, 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 chargera sensiblement plus rapidement une fois qu’une instance a déjà été chargée.
Une fois que l’utilisateur tape un nom d’utilisateur et un mot de passe, les paquets sont envoyés chiffrés au serveur Terminal Server. Le processus Winlogon effectue ensuite l’authentification de compte nécessaire pour vous assurer que l’utilisateur a le privilège de se connecter et de passer 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 ID de session 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 de l’option à sélectionner pour la reconnexion.
Exécution d’une application
Après l’ouverture de session de l’utilisateur, le bureau (ou l’application s’il est en mode application unique) 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 Server, qui lance l’application sélectionnée dans un nouvel espace de mémoire virtuel (application de 2 Go, noyau de 2 Go). Tous les processus sur Terminal Server partageront du code dans les modes noyau et utilisateur dans la mesure du possible. 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 en mémoire, le gestionnaire de machines virtuelles affecte la protection de la page de copie en écriture à la région de 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 moment le gestionnaire de machines virtuelles copie le cadre de page physique vers un autre emplacement, mettez à jour l’adresse virtuelle du processus pour pointer vers le nouvel emplacement de la page et marquez maintenant la page comme étant en lecture/écriture. La copie en écriture est utile et efficace pour les applications s’exécutant sur un serveur Terminal Server.
Lorsqu’une application Win32 telle que Microsoft Word est chargée en mémoire physique par un processus (Session), elle est marquée comme 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 en 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, peu importe le nombre de fois qu’il est exécuté.
Il est préférable (bien que non 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 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 VDM, 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 les ressources qu’une application Win32 comparable.
Déconnexion de session et déconnexion de l’utilisateur
Déconnexion de session
Si un utilisateur décide de déconnecter la session, les processus et l’espace mémoire virtuel resteront et seront paginés sur le disque physique, si la mémoire physique est nécessaire pour d’autres processus. Étant donné que le serveur 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 avantage supplémentaire 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 ait déjà connecté à une session Terminal Server à 800 x 600 résolution et 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.
Déconnexion de l’utilisateur
La déconnexion est généralement simple à implémenter. Une fois qu’un utilisateur se déconnecte 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 proprement dite reste en mémoire jusqu’à ce que le dernier utilisateur quitte l’application.