Procedura dettagliata di Terminal Server: avvio, connessione e applicazione

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

Numero KB originale: 186572

Inizializzazione del server Terminale Windows

Quando Terminale Windows Server viene avviato e caricato il sistema operativo principale, viene avviato il servizio Terminal Server (Termsrv.exe) e vengono creati 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 Terminal Server. 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 della console (tastiera, mouse e video di Terminal Server) è sempre la prima da caricare e viene considerata come una connessione client con maiuscole e minuscole e id sessione assegnato. La sessione della console viene avviata come normale sessione di sistema di Windows NT con i driver di visualizzazione, mouse e tastiera configurati per Windows NT.

Il servizio Terminal Server chiama quindi Gestione sessione di Windows NT (Smss.exe) per creare due sessioni client inattive (predefinite = 2) (dopo aver creato la sessione della console) che attendono le connessioni client. Per creare le sessioni inattive, Session Manager esegue il processo del sottosistema 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 Graphics Device Interface - GDI) sotto l'ID sessione appena associato. Il caricatore di immagini windows NT modificato riconoscerà questa Win32k.sys come immagine caricabile sessionspace da un bit predefinito impostato nell'intestazione dell'immagine. Rilocherà quindi la parte di codice dell'immagine in memoria fisica, con puntatori dallo spazio di indirizzi del kernel virtuale per tale sessione, se Win32k.sys non è già stato caricato. Per impostazione predefinita, verrà sempre collegato 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 dati (o non condivisi) di questa immagine verrà quindi allocata alla nuova sessione da una sezione della memoria kernel pageable 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 di dispositivo di visualizzazione RDP (Remote Desktop Protocol), Tsharedd.dll. I driver del mouse e della tastiera comunicano nello stack tramite lo 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 la disponibilità remota e l'interattività della sessione client RDP. Infine, Terminal Server richiamerà anche un thread del listener di connessione per il protocollo RDP, gestito di nuovo dal gestore dello stack di istanze multiple (Termdd.sys), in ascolto delle connessioni client RDP sulla porta TCP numero 3389.

A questo punto, il processo CSRSS esiste nel proprio spazio dei nomi SessionID, con i relativi dati di cui è stata creata un'istanza in base alle esigenze. Tutti i processi creati dall'interno di questo SessionID verranno eseguiti automaticamente all'interno di SessionSpace 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 for 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 per gruppi di lavoro è 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 è di circa 130 KB, usa un working set di 300 KB e 100 KB per i dati di visualizzazione.

Il client avvierà una connessione al 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 passerà la sessione in ingresso alla nuova istanza dello stack RDP e continuerà ad essere in 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 ridotta crittograferà solo i pacchetti inviati dal client al server Terminal. Questa crittografia "solo input" consente di proteggere l'input dei dati sensibili, ad esempio la password di un utente. La crittografia media crittograferà i pacchetti in uscita dal client come la 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 passa attraverso la rete da visualizzare su uno schermo remoto. Sia la crittografia bassa che 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à di nuovo l'algoritmo di crittografia RC4 standard del settore, con una chiave a 40 bit. Una versione non di esportazione di Windows NT Terminal Server fornirà la crittografia RC4 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 informerà il server Terminal di 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 compressi e caratteri Unicode, anziché bitmap di dimensioni maggiori.

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 vengono usate per contenere stringhe Unicode. La cache è ottimizzabile (tramite una chiave del Registro di sistema) e sovrascritta usando un algoritmo LRU (Least Recently Used). Terminal Server contiene anche buffer per abilitare il passaggio controllato dal flusso di aggiornamenti dello schermo ai client, anziché un flusso di bit costante. Quando l'interazione dell'utente nel client è elevata, il buffer viene scaricato a circa 20 volte al secondo. Durante il tempo di inattività o quando non è presente 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 la negoziazione dei 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 di Windows NT. Se l'accesso automatico è configurato, il nome utente crittografato e la password verranno passati al Server Terminal e l'accesso procederà. Se non esistono sessioni Win32k inattive, il servizio Terminal Server chiamerà Session Manager (SMSS) per creare un nuovo spazio utente per la nuova sessione. Gran parte della sessione utente Win32k usa codice condiviso e carica notevolmente più velocemente dopo il caricamento precedente di un'istanza.

Dopo che l'utente digita 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 passare 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 viene collegato alla sessione precedente. La sessione Win32 temporanea usata per l'accesso iniziale viene quindi eliminata. In caso contrario, la connessione procede come di consueto e il servizio Terminal Server crea un nuovo mapping sessionID dominio/nome utente. Se per qualche motivo più sessioni sono attive 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 dell'utente, il desktop (o l'applicazione se in modalità applicazione singola) viene visualizzato 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 a 2 GB, kernel da 2 GB). Tutti i processi in Terminal Server condivideranno il codice nelle modalità kernel e utente laddove possibile. Per ottenere la condivisione del codice tra processi, la gestione della memoria virtuale Windows NT usa la protezione della pagina di copia in scrittura. Quando più processi vogliono leggere e scrivere lo stesso contenuto di memoria, il gestore di 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, quando 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 ora contrassegni la pagina come lettura/scrittura. La copia su scrittura è utile ed efficiente per le applicazioni in esecuzione in un Terminal Server.

Quando un'applicazione basata su Win32, ad esempio Microsoft Word, viene caricata in memoria fisica da un processo (sessione), viene contrassegnato come copia su scrittura. Quando anche i nuovi processi (sessioni) richiamano Word, il caricatore di immagini punterà 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 una nuova posizione di memoria fisica e contrassegnate come lettura/scrittura per il singolo processo (sessione). Gestione macchine virtuali proteggerà questo spazio di memoria da altri processi. La maggior parte di un'applicazione, tuttavia, è codice condivisibile e avrà solo una singola istanza di codice nella memoria fisica indipendentemente dal numero di esecuzioni.

È 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 eseguite in modo più efficiente nelle sessioni multiutente. Windows NT consente l'esecuzione di applicazioni a 16 bit (Win16) 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 del proprio VDM, il codice non può essere condiviso tra applicazioni in più sessioni. La traduzione tra le chiamate Win16 e Win32 utilizza anche le risorse di sistema. L'esecuzione di applicazioni Win16 in un ambiente Terminal Server può potenzialmente utilizzare due volte le 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 visualizzati sul disco fisico, se la memoria fisica è necessaria per altri processi. Poiché Terminal Server mantiene un mapping di dominio/nome utente e l'ID sessione associato, quando lo stesso utente si riconnette, la sessione esistente verrà caricata e resa nuovamente disponibile. Un vantaggio aggiuntivo di RDP è che è in grado di modificare le risoluzioni dello schermo della sessione, a seconda di ciò che l'utente richiede per la sessione. Si supponga, ad esempio, che un utente abbia precedentemente connesso a una sessione di Terminal Server con risoluzione 800 x 600 e disconnessa. 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.

Logoff 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 finché l'ultimo utente non esce dall'applicazione.