Procedura dettagliata per Terminal Server: avvio, connessione e applicazione

Questo articolo descrive il processo di inizializzazione di un server terminal e descrive cosa accade quando un utente si connette al server ed esegue un'applicazione.

Si applica a: Windows Server 2012 R2
Numero KB originale: 186572

Inizializzazione del server Terminale Windows

Quando il Terminale Windows Server avvia e carica il sistema operativo principale, il servizio Terminal Server (Termsrv.exe) viene avviato e crea stack di ascolto (uno per protocollo e coppia di trasporto) in ascolto delle connessioni in ingresso. A ogni connessione viene assegnato un identificatore di sessione univoco o "SessionID" per rappresentare una singola sessione al Server terminal. Ogni processo creato all'interno di una sessione viene "contrassegnato" con l'ID sessione associato per differenziare lo spazio dei nomi da qualsiasi altro spazio dei nomi della connessione.

La sessione console (tastiera, mouse e video di Terminal Server) è sempre la prima da caricare e viene considerata come una connessione client speciale e un SESSIONID assegnato. La sessione della console viene avviata come normale sessione di sistema di Windows NT con i driver di visualizzazione, mouse e tastiera di Windows NT configurati caricati.

Il servizio Terminal Server chiama quindi Gestione sessione Windows NT (Smss.exe) per creare due sessioni client (predefinite = 2) inattive (dopo la creazione della sessione console) che attendono le connessioni client. Per creare le sessioni inattive, Gestione sessioni esegue il processo del sottosistema di runtime client/server basato su Windows NT (Csrss.exe) e a tale processo viene assegnato un nuovo SESSIONID. Il processo CSRSS richiamerà anche il processo Winlogon (Winlogon.exe) e il modulo kernel Win32k.sys (Window Manager e interfaccia del dispositivo grafico - GDI) sotto il nuovo SESSIONID associato. Il caricatore di immagini Windows NT modificato riconoscerà questo Win32k.sys come immagine caricabile da SessionSpace da un bit predefinito impostato nell'intestazione dell'immagine. La parte di codice dell'immagine verrà quindi riposizionata in memoria fisica, con puntatori dallo spazio indirizzi del kernel virtuale per la sessione, se Win32k.sys non è già stato caricato. Per impostazione predefinita, si connetterà sempre al codice di un'immagine caricata in precedenza (Win32k.sys) se ne esiste già uno in memoria. Ad esempio, da qualsiasi applicazione o sessione attiva.

La sezione dei dati (o non condivisa) di questa immagine verrà quindi allocata alla nuova sessione da una sezione di memoria kernel paginabile SessionSpace appena creata. A differenza della sessione della console, le sessioni client di Terminal Server sono configurate per caricare driver separati per lo schermo, la tastiera e il mouse.

Il nuovo driver di visualizzazione è il driver del dispositivo di visualizzazione RDP (Remote Desktop Protocol), Tsharedd.dll. I driver del mouse e della tastiera comunicano nello stack tramite gestione dello stack di più istanze, termdd.sys. Termdd.sys invierà i messaggi per l'attività del mouse e della tastiera da e verso il driver RDP, Wdtshare.sys. Questi driver consentono alla sessione client RDP di essere disponibile in remoto e interattiva. Infine, Terminal Server richiamerà anche un thread del listener di connessione per il protocollo RDP, gestito nuovamente dal gestore dello stack di più istanze (Termdd.sys), che resta in ascolto delle connessioni client RDP sul numero di porta TCP 3389.

A questo punto, il processo CSRSS esiste sotto il proprio spazio dei nomi SessionID, con i relativi dati di cui è stata creata un'istanza per ogni processo, se necessario. Tutti i processi creati dall'interno di questo SessionID verranno eseguiti automaticamente all'interno dello spazio sessione del processo CSRSS. Ciò impedisce ai processi con id sessione diversi di accedere ai dati di un'altra sessione.

Connessione client

Il client RDP può essere installato ed eseguito in qualsiasi terminale basato su Windows (basato su WinCE), Windows per Workgroups 3.11 che esegue TCP/IP-32b o la piattaforma basata su API Microsoft Win32. I client non basati su Windows sono supportati dal componente aggiuntivo Citrix Metaframe. Il file eseguibile del client RDP di Windows for Workgroups ha dimensioni di circa 70 KB, usa un working set di 300 KB e usa 100 KB per i dati di visualizzazione. Il client basato su Win32 ha dimensioni di circa 130 KB, usa un working set di 300 KB e 100 KB per i dati di visualizzazione.

Il client avvierà una connessione a Terminal Server tramite la porta TCP 3389. Il thread del listener RDP di Terminal Server rileverà la richiesta di sessione e creerà una nuova istanza dello stack RDP per gestire la nuova richiesta di sessione. Il thread del listener consegnerà la sessione in ingresso alla nuova istanza dello stack RDP e continuerà l'ascolto sulla porta TCP 3389 per ulteriori tentativi di connessione. Ogni stack RDP viene creato quando le sessioni client sono connesse per gestire la negoziazione dei dettagli di configurazione della sessione. I primi dettagli saranno stabilire un livello di crittografia per la sessione. Terminal Server supporterà inizialmente tre livelli di crittografia: basso, medio e alto.

La crittografia bassa crittograferà solo i pacchetti inviati dal client a Terminal Server. Questa crittografia "solo input" consente di proteggere l'input di dati sensibili, ad esempio la password di un utente. La crittografia media crittograferà i pacchetti in uscita dal client allo stesso modo della crittografia di basso livello, ma crittograferà anche tutti i pacchetti di visualizzazione restituiti al client da Terminal Server. Questo metodo di crittografia protegge i dati sensibili, mentre viaggia attraverso la rete per essere visualizzati su uno schermo remoto. Sia la crittografia bassa che quella media usano l'algoritmo Microsoft-RC4 (algoritmo RC4 modificato con prestazioni migliorate) con una chiave a 40 bit. La crittografia elevata crittograferà i pacchetti in entrambe le direzioni, da e verso il client, ma userà l'algoritmo di crittografia RC4 standard del settore, sempre con una chiave a 40 bit. Una versione non esportata di Windows NT Terminal Server fornirà la crittografia RC4 di alto livello a 128 bit.

Si verificherà uno scambio di tipi di carattere tra il client e il server per determinare quali tipi di carattere di sistema comuni sono installati. Il client notificherà al Terminal Server tutti i tipi di carattere di sistema installati, per consentire un rendering più rapido del testo durante una sessione RDP. Quando Terminal Server conosce i tipi di carattere disponibili dal client, è possibile risparmiare larghezza di banda di rete passando al client stringhe di caratteri e caratteri Unicode compressi, anziché bitmap più grandi.

Per impostazione predefinita, tutti i client riservano 1,5 MB di memoria per una cache bitmap usata per memorizzare nella cache bitmap, ad esempio icone, barre degli strumenti, cursori e così via, ma non viene usata per contenere stringhe Unicode. La cache è tonabile (tramite una chiave del Registro di sistema) e sovrascritta usando un algoritmo LRU (Least Recently Used). Terminal Server contiene anche buffer per consentire il passaggio controllato dal flusso degli aggiornamenti dello schermo ai client, anziché un bitstream costante. Quando l'interazione dell'utente nel client è elevata, il buffer viene scaricato circa 20 volte al secondo. Durante il tempo di inattività o quando non viene eseguita alcuna interazione dell'utente, il buffer viene rallentato fino a scaricare solo 10 volte al secondo. È possibile ottimizzare tutti questi numeri tramite il Registro di sistema.

Dopo aver negoziato i dettagli della sessione, l'istanza dello stack RDP del server per questa connessione verrà mappata a una sessione utente Win32k inattiva esistente e all'utente verrà visualizzata la schermata di accesso a Windows NT. Se l'accesso automatico è configurato, il nome utente e la password crittografati verranno passati a Terminal Server e l'accesso procederà. Se attualmente non esistono sessioni Win32k inattive, il servizio Terminal Server chiamerà Gestione sessione (SMSS) per creare un nuovo spazio utente per la nuova sessione. Gran parte della sessione utente di Win32k usa il codice condiviso e il caricamento sarà notevolmente più veloce dopo il caricamento di un'istanza in precedenza.

Dopo che l'utente ha digitato un nome utente e una password, i pacchetti vengono inviati crittografati a Terminal Server. Il processo Winlogon esegue quindi l'autenticazione dell'account necessaria per assicurarsi che l'utente abbia il privilegio di accedere e passa il dominio e il nome utente dell'utente al servizio Terminal Server, che gestisce un elenco sessionID dominio/nome utente. Se un SessionID è già associato a questo utente (ad esempio, esiste una sessione disconnessa), lo stack di sessioni attualmente attivo è collegato alla sessione precedente. La sessione Win32 temporanea usata per l'accesso iniziale viene quindi eliminata. In caso contrario, la connessione procede normalmente e il servizio Terminal Server crea un nuovo mapping sessionID dominio/nome utente. Se per qualche motivo più di una sessione è attiva per questo utente, viene visualizzato l'elenco delle sessioni e l'utente decide quale selezionare per la riconnessione.

Esecuzione di un'applicazione

Dopo l'accesso utente, viene visualizzato il desktop (o l'applicazione se in modalità applicazione singola) per l'utente. Quando l'utente seleziona un'applicazione a 32 bit da eseguire, i comandi del mouse vengono passati a Terminal Server, che avvia l'applicazione selezionata in un nuovo spazio di memoria virtuale (applicazione da 2 GB, kernel da 2 GB). Tutti i processi in Terminal Server condivideranno il codice in modalità kernel e utente, ove possibile. Per ottenere la condivisione del codice tra i processi, la gestione della memoria virtuale (VM) Windows NT usa la protezione della pagina di copia in scrittura. Quando più processi vogliono leggere e scrivere lo stesso contenuto di memoria, la gestione macchine virtuali assegnerà la protezione della pagina di copia in scrittura all'area di memoria. I processi (sessioni) useranno lo stesso contenuto di memoria fino a quando non viene eseguita un'operazione di scrittura, al momento in cui il gestore di macchine virtuali copia il frame di pagina fisico in un'altra posizione, aggiorna l'indirizzo virtuale del processo in modo che punti alla nuova posizione della pagina e contrassegni la pagina come di lettura/scrittura. La copia in scrittura è utile ed efficiente per le applicazioni in esecuzione in un server terminal.

Quando un'applicazione basata su Win32, ad esempio Microsoft Word, viene caricata in memoria fisica da un unico processo (sessione), viene contrassegnata come copia in scrittura. Quando anche i nuovi processi (sessioni) richiamano Word, il caricatore di immagini punterà solo i nuovi processi (Sessioni) alla copia esistente perché l'applicazione è già caricata in memoria. Quando sono necessari buffer e dati specifici dell'utente (ad esempio, il salvataggio in un file), le pagine necessarie verranno copiate in un nuovo percorso di memoria fisica e contrassegnate come di lettura/scrittura per il singolo processo (sessione). Il gestore di macchine virtuali proteggerà questo spazio di memoria da altri processi. La maggior parte di un'applicazione, tuttavia, è un codice condivisibile e avrà solo una singola istanza di codice in memoria fisica, indipendentemente dal numero di volte in cui viene eseguita.

È preferibile (anche se non è necessario) eseguire applicazioni a 32 bit in un ambiente Terminal Server. Le applicazioni a 32 bit (Win32) consentiranno la condivisione del codice ed eseguiranno in modo più efficiente nelle sessioni multiutenta. Windows NT consente alle applicazioni a 16 bit (Win16) di essere eseguite in un ambiente Win32 creando un computer virtuale basato su MS-DOS (VDM) per ogni applicazione Win16 da eseguire. Tutto l'output a 16 bit viene convertito in chiamate Win32, che eseguono le azioni necessarie. Poiché le app Win16 vengono eseguite all'interno di una propria macchina virtuale, il codice non può essere condiviso tra le applicazioni in più sessioni. La traduzione tra le chiamate Win16 e Win32 usa anche le risorse di sistema. L'esecuzione di applicazioni Win16 in un ambiente Terminal Server può potenzialmente utilizzare il doppio delle risorse rispetto a un'applicazione basata su Win32 paragonabile.

Disconnessione sessione e disconnessione utente

Disconnessione sessione

Se un utente decide di disconnettere la sessione, i processi e tutto lo spazio di memoria virtuale rimarranno e verranno scollegati dal disco fisico, se è necessaria memoria fisica per altri processi. Poiché terminal server mantiene un mapping di dominio/nome utente e il relativo ID sessione associato, quando lo stesso utente si riconnette, la sessione esistente verrà caricata e resa nuovamente disponibile. Un ulteriore vantaggio di RDP è che è in grado di modificare le risoluzioni dello schermo della sessione, a seconda delle richieste dell'utente per la sessione. Si supponga, ad esempio, che un utente si sia connesso in precedenza a una sessione di Terminal Server con risoluzione 800 x 600 e disconnesso. Se l'utente passa quindi a un computer diverso che supporta solo la risoluzione 640 x 480 e si riconnette alla sessione esistente, il desktop verrà ridisegnato per supportare la nuova risoluzione.

Disconnessione utente

La disconnessione è in genere semplice da implementare. Dopo che un utente si disconnette dalla sessione, tutti i processi associati all'ID sessione vengono terminati e viene rilasciata qualsiasi memoria allocata alla sessione. Se l'utente esegue un'applicazione a 32 bit, ad esempio Microsoft Word, e si disconnette dalla sessione, il codice dell'applicazione stessa rimarrà in memoria fino a quando l'ultimo utente non viene chiuso dall'applicazione.