Passo a passo do Servidor do Terminal: Inicialização, Conexão e Aplicativo

Este artigo descreve o processo de inicialização de um Terminal Server e descreve o que ocorre quando um usuário se conecta ao servidor e executa um aplicativo.

Aplica-se a: Windows Server 2012 R2
Número de KB original: 186572

Inicialização do servidor Terminal do Windows

À medida que o servidor Terminal do Windows inicializa e carrega o sistema operacional principal, o serviço do Terminal Server (Termsrv.exe) é iniciado e cria pilhas de escuta (uma por protocolo e par de transporte) que escutam conexões de entrada. Cada conexão recebe um identificador de sessão exclusivo ou "SessionID" para representar uma sessão individual para o Terminal Server. Cada processo criado em uma sessão é "marcado" com o SessionID associado para diferenciar seu namespace do namespace de qualquer outra conexão.

A sessão console (teclado, mouse e vídeo do Terminal Server) é sempre a primeira a ser carregada e é tratada como uma conexão de cliente de caso especial e SessionID atribuída. A sessão do console começa como uma sessão normal do sistema Windows NT com os drivers de Windows NT, mouse e teclado configurados carregados.

Em seguida, o serviço do Terminal Server chama o Windows NT Session Manager (Smss.exe) para criar duas sessões de cliente ociosas (padrão = 2) (depois de criar a sessão do console) que aguardam conexões do cliente. Para criar as sessões ociosas, o Session Manager executa o processo de subsistema de runtime do cliente/servidor baseado em Windows NT (Csrss.exe) e um novo SessionID é atribuído a esse processo. O processo CSRSS também invocará o processo Winlogon (Winlogon.exe) e o módulo de kernel Win32k.sys (Gerenciador de Janelas e interface do dispositivo gráfico – GDI) no SessionID recém-associado. O carregador de imagem Windows NT modificado reconhecerá esse Win32k.sys como uma imagem carregável do SessionSpace por um bit predefinido definido no cabeçalho da imagem. Em seguida, ele realocará a parte de código da imagem em memória física, com ponteiros do espaço de endereço do kernel virtual para essa sessão, se Win32k.sys ainda não tiver sido carregado. Por design, ele sempre será anexado ao código de uma imagem carregada anteriormente (Win32k.sys) se já existir na memória. Por exemplo, de qualquer aplicativo ativo ou sessão.

A seção dados (ou não compartilhados) dessa imagem será alocada para a nova sessão de uma seção de memória de kernel pageable do SessionSpace recém-criada. Ao contrário da sessão do console, as sessões do Cliente do Terminal Server são configuradas para carregar drivers separados para a exibição, teclado e mouse.

O novo driver de exibição é o dispositivo de exibição driver de dispositivo RDP (Protocolo de Área de Trabalho Remota), Tsharedd.dll. Os drivers de mouse e teclado se comunicam na pilha por meio do gerenciador de pilhas de várias instâncias, termdd.sys. Termdd.sys enviará as mensagens para atividades de mouse e teclado de e para o driver RDP, Wdtshare.sys. Esses drivers permitem que a sessão do cliente RDP esteja remotamente disponível e interativa. Por fim, o Terminal Server também invocará um thread de ouvinte de conexão para o protocolo RDP, novamente gerenciado pelo gerenciador de pilhas de várias instâncias (Termdd.sys), que escuta conexões de cliente RDP na porta TCP número 3389.

Neste ponto, o processo CSRSS existe em seu próprio namespace SessionID, com seus dados instanciados por processo conforme necessário. Todos os processos criados dentro deste SessionID serão executados no SessionSpace do processo CSRSS automaticamente. Isso impede que processos com diferentes SessionIDs acessem os dados de outra sessão.

Conexão cliente

O cliente RDP pode ser instalado e executado em qualquer terminal baseado no Windows (com base no WinCE), no Windows for Workgroups 3.11 executando o TCP/IP-32b ou na plataforma baseada em API do Microsoft Win32. Clientes não baseados no Windows têm suporte para o complemento do Metaframe do Citrix. O arquivo executável do cliente RDP do Windows for Workgroups tem aproximadamente 70 KB de tamanho, usa um conjunto de trabalho de 300 KB e usa 100 KB para exibir dados. O cliente baseado em Win32 tem aproximadamente 130 KB de tamanho, usa um conjunto de trabalho de 300 KB e 100 KB para dados de exibição.

O cliente iniciará uma conexão com o Terminal Server por meio da porta TCP 3389. O thread do ouvinte RDP do Terminal Server detectará a solicitação de sessão e criará uma nova instância de pilha RDP para lidar com a nova solicitação de sessão. O thread do ouvinte entregará a sessão de entrada para a nova instância de pilha de RDP e continuará ouvindo na porta TCP 3389 para novas tentativas de conexão. Cada pilha RDP é criada à medida que as sessões do cliente são conectadas para lidar com a negociação de detalhes da configuração da sessão. Os primeiros detalhes serão estabelecer um nível de criptografia para a sessão. Inicialmente, o Terminal Server oferecerá suporte a três níveis de criptografia: baixo, médio e alto.

A criptografia baixa criptografará apenas pacotes que estão sendo enviados do cliente para o Terminal Server. Essa criptografia de "somente entrada" é para proteger a entrada de dados confidenciais, como a senha de um usuário. A criptografia média criptografará pacotes de saída do cliente da mesma forma que a criptografia de baixo nível, mas também criptografará todos os pacotes de exibição que estão sendo retornados ao cliente do Terminal Server. Esse método de criptografia protege dados confidenciais, pois ele viaja pela rede para ser exibido em uma tela remota. A criptografia baixa e média usa o algoritmo Microsoft-RC4 (algoritmo RC4 modificado com melhor desempenho) com uma chave de 40 bits. A criptografia alta criptografará pacotes em ambas as direções, de e para o cliente, mas usará o algoritmo de criptografia RC4 padrão do setor, novamente com uma chave de 40 bits. Uma versão não exportada do Windows NT Terminal Server fornecerá criptografia RC4 de alto nível de 128 bits.

Uma troca de fontes ocorrerá entre o cliente e o servidor para determinar quais fontes comuns do sistema estão instaladas. O cliente notificará o Terminal Server de todas as fontes do sistema instaladas para habilitar a renderização mais rápida de texto durante uma sessão RDP. Quando o Terminal Server sabe quais fontes o cliente tem disponíveis, você pode salvar a largura de banda de rede passando cadeias de caracteres compactadas e caracteres Unicode, em vez de bitmaps maiores, para o cliente.

Por padrão, todos os clientes reservam 1,5 MB de memória para um cache bitmap que é usado para armazenar em cache bitmaps, como ícones, barras de ferramentas, cursores e assim por diante, mas não é usado para conter cadeias de caracteres Unicode. O cache é tunável (por meio de uma chave de registro) e substituído usando um algoritmo LRU (Menos Usado Recentemente). O Terminal Server também contém buffers para habilitar a passagem controlada pelo fluxo de atualizações de tela para os clientes, em vez de um bitstream constante. Quando a interação do usuário no cliente é alta, o buffer é liberado a aproximadamente 20 vezes por segundo. Durante o tempo ocioso ou quando não há interação do usuário, o buffer é lento para apenas liberar 10 vezes por segundo. Você pode ajustar todos esses números por meio do registro.

Depois que os detalhes da sessão forem negociados, a instância de pilha RDP do servidor para essa conexão será mapeada para uma sessão de usuário win32k ociosa existente, e o usuário será solicitado com a tela de logon Windows NT. Se o autologon estiver configurado, o nome de usuário criptografado e a senha serão passados para o Terminal Server e o logon continuará. Se não houver sessões ociosas do Win32k no momento, o serviço do Terminal Server chamará o SMSS (Gerenciador de Sessão) para criar um novo espaço de usuário para a nova sessão. Grande parte da sessão de usuário do Win32k está utilizando código compartilhado e será carregada visivelmente mais rapidamente depois que uma instância tiver sido carregada anteriormente.

Depois que o usuário digita um nome de usuário e uma senha, os pacotes são enviados criptografados para o Terminal Server. Em seguida, o processo Winlogon executa a autenticação de conta necessária para garantir que o usuário tenha o privilégio de fazer logon e passe o domínio e o nome de usuário do usuário para o serviço Terminal Server, que mantém uma lista SessionID de domínio/nome de usuário. Se um SessionID já estiver associado a esse usuário (por exemplo, existe uma sessão desconectada), a pilha de sessão ativa atualmente será anexada à sessão antiga. A sessão temporária do Win32 usada para o logon inicial é excluída. Caso contrário, a conexão continua normalmente e o serviço do Terminal Server cria um mapeamento SessionID de domínio/nome de usuário. Se, por algum motivo, mais de uma sessão estiver ativa para esse usuário, a lista de sessões será exibida e o usuário decidir qual selecionará para reconexão.

Executando um aplicativo

Após o logon do usuário, a área de trabalho (ou aplicativo se estiver no modo de aplicativo único) será exibida para o usuário. Quando o usuário seleciona um aplicativo de 32 bits para ser executado, os comandos do mouse são passados para o Terminal Server, que inicia o aplicativo selecionado em um novo espaço de memória virtual (aplicativo de 2 GB, kernel de 2 GB). Todos os processos no Terminal Server compartilharão código nos modos kernel e usuário sempre que possível. Para obter o compartilhamento de código entre processos, o gerenciador de VM (memória virtual) Windows NT usa a proteção de página de cópia na gravação. Quando vários processos desejarem ler e gravar o mesmo conteúdo de memória, o gerenciador de VM atribuirá proteção de página de cópia na gravação à região da memória. Os processos (Sessões) usarão o mesmo conteúdo de memória até que uma operação de gravação seja executada, momento em que o gerenciador de VM copiará o quadro de página física para outro local, atualizará o endereço virtual do processo para apontar para o novo local da página e agora marcará a página como leitura/gravação. Copiar na gravação é útil e eficiente para aplicativos em execução em um Servidor de Terminal.

Quando um aplicativo baseado em Win32, como o Microsoft Word é carregado na memória física por um processo (Sessão), ele é marcado como cópia na gravação. Quando novos processos (Sessões) também invocam Word, o carregador de imagem apenas apontará os novos processos (Sessões) para a cópia existente porque o aplicativo já está carregado na memória. Quando buffers e dados específicos do usuário forem necessários (por exemplo, salvando em um arquivo), as páginas necessárias serão copiadas em um novo local de memória física e marcadas como leitura/gravação para o processo individual (Sessão). O gerenciador de VM protegerá esse espaço de memória de outros processos. A maioria de um aplicativo, no entanto, é código compartilhável e terá apenas uma única instância de código na memória física, não importa quantas vezes ele seja executado.

É preferível (embora não necessário) executar aplicativos de 32 bits em um ambiente do Terminal Server. Os aplicativos de 32 bits (Win32) permitirão o compartilhamento de código e serão executados com mais eficiência em sessões de vários usuários. Windows NT permite que aplicativos de 16 bits (Win16) sejam executados em um ambiente Win32 criando uma VDM (computador virtual baseada em MS-DOS) para cada aplicativo Win16 a ser executado. Toda a saída de 16 bits é convertida em chamadas win32, que executam as ações necessárias. Como os aplicativos Win16 estão sendo executados dentro de sua própria VDM, o código não pode ser compartilhado entre aplicativos em várias sessões. A tradução entre as chamadas Win16 e Win32 também consome recursos do sistema. Executar aplicativos Win16 em um ambiente do Terminal Server pode potencialmente consumir o dobro dos recursos do que um aplicativo baseado em Win32 comparável.

Desconexão de sessão e logoff do usuário

Desconexão de sessão

Se um usuário decidir desconectar a sessão, os processos e todo o espaço de memória virtual permanecerão e serão excluídos no disco físico, se a memória física for necessária para outros processos. Como o Terminal Server mantém um mapeamento de domínio/nome de usuário e seu SessionID associado, quando o mesmo usuário se reconectar, a sessão existente será carregada e disponibilizada novamente. Um benefício adicional do RDP é que ele é capaz de alterar resoluções de tela de sessão, dependendo do que o usuário solicita para a sessão. Por exemplo, suponha que um usuário tenha se conectado anteriormente a uma sessão do Terminal Server com resolução 800 x 600 e desconectado. Se o usuário se mover para um computador diferente que dá suporte apenas à resolução 640 x 480 e se reconectar à sessão existente, a área de trabalho será redesenhada para dar suporte à nova resolução.

Logoff do usuário

O logoff normalmente é simples de implementar. Depois que um usuário faz logon da sessão, todos os processos associados ao SessionID são encerrados e qualquer memória alocada na sessão é liberada. Se o usuário estiver executando um aplicativo de 32 bits, como o Microsoft Word, e fizer logon da sessão, o código do próprio aplicativo permanecerá na memória até que o último usuário saia do aplicativo.