Przewodnik po serwerze terminali: uruchamianie, połączenie i aplikacja

W tym artykule opisano proces inicjowania serwera terminali i opisano, co ma miejsce, gdy użytkownik łączy się z serwerem i uruchamia aplikację.

Oryginalny numer KB: 186572

Inicjowanie serwera Terminal Windows

Ponieważ serwer Terminal Windows uruchamia i ładuje podstawowy system operacyjny, usługa serwera terminali (Termsrv.exe) jest uruchamiana i tworzy stosy nasłuchiwania (jeden na protokół i parę transportową), które nasłuchują połączeń przychodzących. Każde połączenie ma unikatowy identyfikator sesji lub "SessionID", aby reprezentować pojedynczą sesję serwera terminali. Każdy proces utworzony w ramach sesji jest "oznaczony" skojarzonym identyfikatorem SessionID, aby odróżnić przestrzeń nazw od przestrzeni nazw dowolnego innego połączenia.

Sesja konsoli (klawiatura serwera terminali, mysz i wideo) jest zawsze pierwszą do załadowania i jest traktowana jako połączenie klienta specjalnego przypadku i przypisane identyfikator sessionID. Sesja konsoli rozpoczyna się jako normalna sesja systemu Windows NT ze skonfigurowanym wyświetlaczem, myszą i sterownikami klawiatury systemu Windows NT załadowanymi.

Następnie usługa serwera terminali wywołuje Menedżera sesji systemu Windows NT (Smss.exe), aby utworzyć dwie sesje klienta bezczynne (domyślnie = 2) bezczynne (po utworzeniu sesji konsoli), które oczekują na połączenia klienta. Aby utworzyć sesje bezczynności, Menedżer sesji wykonuje proces podsystemu uruchomieniowego klienta/serwera systemu Windows NT (Csrss.exe), a nowy identyfikator SessionID jest przypisany do tego procesu. Proces CSRSS wywoła również proces Winlogon (Winlogon.exe) i Win32k.sys (Windows Manager i graficzny interfejs urządzenia — GDI) jądra w nowo skojarzonym identyfikatorze SessionID. Zmodyfikowany moduł ładujący obrazów systemu Windows NT rozpozna ten Win32k.sys jako obraz ładowany przez wstępnie zdefiniowany bit ustawiony w nagłówku obrazu. Następnie przeniesie część kodu obrazu do pamięci fizycznej z wskaźnikami z wirtualnej przestrzeni adresowej jądra dla tej sesji, jeśli Win32k.sys nie została jeszcze załadowana. Zgodnie z projektem zawsze będzie on dołączany do wcześniej załadowanego kodu obrazu (Win32k.sys), jeśli już istnieje w pamięci. Na przykład z dowolnej aktywnej aplikacji lub sesji.

Sekcja danych (lub nieudzielona) tego obrazu zostanie następnie przydzielona do nowej sesji z nowo utworzonej sekcji pamięci jądra z możliwością stronicowania SessionSpace. W przeciwieństwie do sesji konsoli sesje klienta serwera terminali są skonfigurowane do ładowania oddzielnych sterowników dla wyświetlacza, klawiatury i myszy.

Nowy sterownik wyświetlania to sterownik urządzenia wyświetlania protokołu RDP (Remote Desktop Protocol), Tsharedd.dll. Sterowniki myszy i klawiatury komunikują się ze stosem za pośrednictwem menedżera stosu wielu wystąpień, termdd.sys. Termdd.sys wysyła komunikaty dotyczące działania myszy i klawiatury do i ze sterownika RDP Wdtshare.sys. Te sterowniki umożliwiają zdalne i interakcyjne udostępnianie sesji klienta RDP. Na koniec serwer terminali wywoła również wątek odbiornika połączenia dla protokołu RDP, ponownie zarządzany przez menedżera stosu wielu wystąpień (Termdd.sys), który nasłuchuje połączeń klienta RDP na porcie TCP numer 3389.

W tym momencie proces CSRSS istnieje w ramach własnej przestrzeni nazw SessionID, a jego dane są tworzone w razie potrzeby. Wszystkie procesy utworzone na podstawie tego identyfikatora sesji będą wykonywane automatycznie w przestrzeni sesji procesu CSRSS. Zapobiega to procesom z różnymi identyfikatorami SessionID uzyskiwanie dostępu do danych innej sesji.

Połączenie klienta

Klienta RDP można zainstalować i uruchomić na dowolnym terminalu opartym na systemie Windows (opartym na WinCE), windows for Workgroups 3.11 z uruchomionym protokołem TCP/IP-32b lub platformą opartą na interfejsie API Systemu Microsoft Win32. Klienci spoza systemu Windows są obsługiwani przez dodatek Citrix Metaframe. Plik wykonywalny klienta RDP systemu Windows for Workgroups ma rozmiar około 70 KB, używa zestawu roboczego o rozmiarze 300 KB i używa 100 KB do wyświetlania danych. Klient oparty na systemie Win32 ma rozmiar około 130 KB, używa zestawu roboczego o rozmiarze 300 KB i 100 KB do wyświetlania danych.

Klient zainicjuje połączenie z serwerem terminali za pośrednictwem portu TCP 3389. Wątek odbiornika RDP serwera terminali wykryje żądanie sesji i utworzy nowe wystąpienie stosu RDP do obsługi nowego żądania sesji. Wątek odbiornika przekaże sesję przychodzącą do nowego wystąpienia stosu RDP i będzie kontynuować nasłuchiwanie na porcie TCP 3389 w celu uzyskania dalszych prób połączenia. Każdy stos protokołu RDP jest tworzony, ponieważ sesje klienta są połączone w celu obsługi negocjacji szczegółów konfiguracji sesji. Pierwszymi szczegółami będzie ustanowienie poziomu szyfrowania dla sesji. Serwer terminali początkowo obsługuje trzy poziomy szyfrowania: niski, średni i wysoki.

Niskie szyfrowanie spowoduje szyfrowanie tylko pakietów wysyłanych z klienta do serwera terminali. To "tylko dane wejściowe" służy do ochrony danych wejściowych poufnych, takich jak hasło użytkownika. Średnie szyfrowanie będzie szyfrować pakiety wychodzące od klienta tak samo jak szyfrowanie niskiego poziomu, ale także szyfruje wszystkie pakiety wyświetlane zwracane do klienta z serwera terminali. Ta metoda szyfrowania zabezpiecza poufne dane podczas podróży przez sieć do wyświetlania na ekranie zdalnym. Zarówno niskie, jak i średnie szyfrowanie używa algorytmu Microsoft-RC4 (zmodyfikowanego algorytmu RC4 o lepszej wydajności) przy użyciu klucza 40-bitowego. Wysokie szyfrowanie będzie szyfrować pakiety w obu kierunkach, do i od klienta, ale będzie używać standardowego algorytmu szyfrowania RC4 w branży, ponownie z 40-bitowym kluczem. Nieeksportowa wersja systemu Windows NT Terminal Server zapewni 128-bitowe szyfrowanie RC4 wysokiego poziomu.

Wymiana czcionek nastąpi między klientem a serwerem w celu określenia, które typowe czcionki systemowe są zainstalowane. Klient powiadomi serwer terminali o wszystkich zainstalowanych czcionkach systemowych, aby umożliwić szybsze renderowanie tekstu podczas sesji protokołu RDP. Gdy serwer terminali wie, jakie czcionki ma dostępny klient, można zaoszczędzić przepustowość sieci, przekazując skompresowaną czcionkę i ciągi znaków Unicode, a nie większe mapy bitowe, do klienta.

Domyślnie wszyscy klienci rezerwują 1,5 MB pamięci dla pamięci podręcznej mapy bitowej używanej do buforowania map bitowych, takich jak ikony, paski narzędzi, kursory itd., ale nie są używane do przechowywania ciągów Unicode. Pamięć podręczna jest dostrajana (za pomocą klucza rejestru) i zastępowana przy użyciu algorytmu LRU (Least Recently Used). Serwer terminali zawiera również umożliwiające sterowane przepływem przekazywanie odświeżeń ekranu do klientów, a nie stały strumień bitowy. Gdy interakcja użytkownika na kliencie jest wysoka, bufor jest opróżniany około 20 razy na sekundę. W czasie bezczynności lub braku interakcji użytkownika bufor jest spowalniany, aby opróżnić tylko 10 razy na sekundę. Wszystkie te liczby można dostroić za pomocą rejestru.

Po wynegocjowaniu szczegółów sesji wystąpienie stosu protokołu RDP serwera dla tego połączenia zostanie zamapowane na istniejącą bezczynną sesję użytkownika Win32k, a użytkownik zostanie wyświetlony monit z ekranem logowania systemu Windows NT. Jeśli skonfigurowano automatyczne logowanie, zaszyfrowana nazwa użytkownika i hasło zostaną przekazane do serwera terminali, a logowanie będzie kontynuowane. Jeśli obecnie nie istnieją bezczynne sesje Win32k, usługa serwera terminali wywoła Menedżera sesji (SMSS), aby utworzyć nowe miejsce użytkownika dla nowej sesji. Większość sesji użytkownika Win32k korzysta z kodu współużytkowanego i będzie ładowana znacznie szybciej po wcześniejszym załadowaniu jednego wystąpienia.

Gdy użytkownik wpisze nazwę użytkownika i hasło, pakiety są wysyłane zaszyfrowane do serwera terminali. Następnie proces Winlogon wykonuje niezbędne uwierzytelnianie konta, aby upewnić się, że użytkownik ma uprawnienia do logowania się i przekazuje domenę użytkownika i nazwę użytkownika do usługi serwera terminali, która utrzymuje listę identyfikatorów sesji domeny/nazwy użytkownika. Jeśli identyfikator sesji jest już skojarzony z tym użytkownikiem (na przykład istnieje rozłączona sesja), aktualnie aktywny stos sesji jest dołączony do starej sesji. Tymczasowa sesja Win32 używana do początkowego logowania jest następnie usuwana. W przeciwnym razie połączenie będzie kontynuowane normalnie, a usługa serwera terminali tworzy nowe mapowanie identyfikatora sesji domeny/nazwy użytkownika. Jeśli z jakiegoś powodu więcej niż jedna sesja jest aktywna dla tego użytkownika, zostanie wyświetlona lista sesji, a użytkownik zdecyduje, który z nich ma wybrać do ponownego nawiązania połączenia.

Uruchamianie aplikacji

Po zalogowaniu użytkownika zostanie wyświetlony pulpit (lub aplikacja w trybie pojedynczej aplikacji). Gdy użytkownik wybierze aplikację 32-bitową do uruchomienia, polecenia myszy są przekazywane do serwera terminali, który uruchamia wybraną aplikację w nowej przestrzeni pamięci wirtualnej (aplikacja 2 GB, jądro 2 GB). Wszystkie procesy na serwerze terminali będą współdzielić kod w trybach jądra i użytkownika wszędzie tam, gdzie to możliwe. Aby uzyskać udostępnianie kodu między procesami, menedżer pamięci wirtualnej systemu Windows NT używa ochrony strony kopiowania na zapis. Gdy wiele procesów chce odczytywać i zapisywać tę samą zawartość pamięci, menedżer maszyny wirtualnej przypisze ochronę strony kopiowania na zapis do regionu pamięci. Procesy (sesje) będą używać tej samej zawartości pamięci do czasu wykonania operacji zapisu, w którym menedżer maszyny wirtualnej skopiuje fizyczną ramkę strony do innej lokalizacji, zaktualizuje wirtualny adres procesu, aby wskazać nową lokalizację strony, a następnie oznaczyć stronę jako odczyt/zapis. Kopiowanie na zapis jest przydatne i wydajne w przypadku aplikacji działających na serwerze terminali.

Gdy aplikacja oparta na systemie Win32, taka jak Microsoft Word, jest ładowana do pamięci fizycznej przez jeden proces (sesja), jest oznaczona jako kopia-zapis. Gdy nowe procesy (Sesje) również wywołają program Word, moduł ładujący obraz będzie po prostu wskazywał nowe procesy (Sesje) do istniejącej kopii, ponieważ aplikacja jest już załadowana w pamięci. Gdy wymagane są i dane specyficzne dla użytkownika (na przykład zapisywanie w pliku), niezbędne strony zostaną skopiowane do nowej lokalizacji pamięci fizycznej i oznaczone jako odczyt/zapis dla pojedynczego procesu (sesja). Menedżer maszyn wirtualnych chroni to miejsce na pamięć przed innymi procesami. Większość aplikacji jest jednak współdzielona i będzie mieć tylko jedno wystąpienie kodu w pamięci fizycznej niezależnie od tego, ile razy jest uruchamiana.

Zaleca się (chociaż nie jest to konieczne) do uruchamiania aplikacji 32-bitowych w środowisku serwera terminali. Aplikacje 32-bitowe (Win32) umożliwią udostępnianie kodu i będą działać wydajniej w sesjach wielu użytkowników. System Windows NT umożliwia uruchamianie aplikacji 16-bitowych (Win16) w środowisku Win32 przez utworzenie wirtualnego komputera opartego na systemie MS-DOS (VDM) dla każdej aplikacji Win16 do wykonania. Wszystkie 16-bitowe dane wyjściowe są tłumaczone na wywołania Win32, które wykonują niezbędne akcje. Ponieważ aplikacje Win16 są wykonywane w ramach własnej maszyny wirtualnej, kod nie może być współużytkowany między aplikacjami w wielu sesjach. Tłumaczenie między wywołaniami Win16 i Win32 zużywa również zasoby systemowe. Uruchamianie aplikacji Win16 w środowisku serwera terminalowego może potencjalnie zużywać dwa razy więcej zasobów niż porównywalna aplikacja oparta na systemie Win32.

Rozłączanie sesji i wylogowanie użytkownika

Rozłączanie sesji

Jeśli użytkownik zdecyduje się na rozłączenie sesji, procesy i wszystkie miejsca w pamięci wirtualnej pozostaną i zostaną odsłonięci na dysk fizyczny, jeśli pamięć fizyczna jest wymagana dla innych procesów. Ponieważ serwer terminali przechowuje mapowanie domeny/nazwy użytkownika i skojarzonego identyfikatora sessionID, gdy ten sam użytkownik ponownie nawiąże połączenie, istniejąca sesja zostanie załadowana i udostępniona ponownie. Dodatkową zaletą protokołu RDP jest możliwość zmiany rozdzielczości ekranu sesji, w zależności od tego, co użytkownik żąda sesji. Załóżmy na przykład, że użytkownik wcześniej nawiązał połączenie z sesją serwera terminali z rozdzielczością 800 x 600 i odłączony. Jeśli użytkownik przejdzie do innego komputera, który obsługuje tylko rozdzielczość 640 x 480 i ponownie nawiąze połączenie z istniejącą sesją, pulpit zostanie ponownie skopiowany, aby obsługiwać nową rozdzielczość.

Wylogowanie użytkownika

Wylogowywanie jest zwykle proste do zaimplementowania. Po wylogowaniu użytkownika z sesji wszystkie procesy skojarzone z identyfikatorem SessionID zostaną zakończone, a każda pamięć przydzielona do sesji zostanie zwolniona. Jeśli użytkownik uruchamia aplikację 32-bitową, taką jak Microsoft Word, i wyloguje się z sesji, kod samej aplikacji pozostanie w pamięci do czasu zakończenia ostatniego użytkownika z aplikacji.