Tutorial de Terminal Server: inicio, conexión y aplicación

En este artículo se describe el proceso de inicialización de un terminal Server y se describe lo que ocurre cuando un usuario se conecta al servidor y ejecuta una aplicación.

Número de KB original: 186572

Inicialización del servidor Terminal Windows

A medida que el servidor de Terminal Windows arranca y carga el sistema operativo principal, se inicia el servicio Terminal Server (Termsrv.exe) y crea pilas de escucha (una por protocolo y par de transporte) que escuchan las conexiones entrantes. Cada conexión recibe un identificador de sesión único o "SessionID" para representar una sesión individual en Terminal Server. Cada proceso creado dentro de una sesión se "etiqueta" con el sessionID asociado para diferenciar su espacio de nombres de cualquier otro espacio de nombres de la conexión.

La sesión de consola (teclado, mouse y vídeo de Terminal Server) es siempre la primera que se carga y se trata como una conexión de cliente de caso especial y se le asigna SessionID. La sesión de consola se inicia como una sesión normal del sistema Windows NT con la pantalla, el mouse y los controladores de teclado configurados de Windows NT cargados.

A continuación, el servicio Terminal Server llama al Administrador de sesiones de Windows NT (Smss.exe) para crear dos sesiones de cliente inactivas (valor predeterminado = 2) (después de crear la sesión de consola) que esperan conexiones de cliente. Para crear las sesiones inactivas, el Administrador de sesiones ejecuta el proceso del subsistema de tiempo de ejecución de servidor o cliente basado en Windows NT (Csrss.exe) y se asigna un nuevo SessionID a ese proceso. El proceso CSRSS también invocará el proceso de Winlogon (Winlogon.exe) y el módulo del kernel Win32k.sys (Window Manager y la interfaz de dispositivo gráfico - GDI) en el sessionID recién asociado. El cargador de imágenes de Windows NT modificado reconocerá este Win32k.sys como una imagen cargable de SessionSpace mediante un conjunto de bits predefinido en el encabezado de imagen. A continuación, reubicará la parte de código de la imagen en memoria física, con punteros del espacio de direcciones del kernel virtual para esa sesión, si aún no se ha cargado Win32k.sys. Por diseño, siempre se asociará al código de una imagen cargada previamente (Win32k.sys) si ya existe en la memoria. Por ejemplo, desde cualquier aplicación o sesión activa.

A continuación, la sección de datos (o no compartida) de esta imagen se asignará a la nueva sesión desde una sección de memoria del kernel paginable sessionSpace recién creada. A diferencia de la sesión de consola, las sesiones de cliente de Terminal Server están configuradas para cargar controladores independientes para la pantalla, el teclado y el mouse.

El nuevo controlador de pantalla es el controlador de dispositivo de pantalla del Protocolo de escritorio remoto (RDP), Tsharedd.dll. Los controladores de teclado y mouse se comunican en la pila a través del administrador de pila de varias instancias, termdd.sys. Termdd.sys enviará los mensajes para la actividad del mouse y el teclado hacia y desde el controlador RDP, Wdtshare.sys. Estos controladores permiten que la sesión del cliente RDP esté disponible de forma remota e interactiva. Por último, Terminal Server también invocará un subproceso de agente de escucha de conexión para el protocolo RDP, administrado de nuevo por el administrador de pila de varias instancias (Termdd.sys), que escucha las conexiones de cliente RDP en el número de puerto TCP 3389.

En este momento, el proceso CSRSS existe en su propio espacio de nombres SessionID, con sus datos creados en instancias de cada proceso según sea necesario. Los procesos creados desde este SessionID se ejecutarán automáticamente en sessionSpace del proceso CSRSS. Esto impide que los procesos con diferentes identificadores de sesión accedan a los datos de otra sesión.

Conexión del cliente

El cliente RDP se puede instalar y ejecutar en cualquier terminal basado en Windows (basado en WinCE), Windows for Workgroups 3.11 que ejecute TCP/IP-32b o en la plataforma basada en API de Microsoft Win32. Los clientes no basados en Windows son compatibles con el complemento Citrix Metaframe. El archivo ejecutable del cliente RDP de Windows for Workgroups tiene un tamaño aproximado de 70 KB, usa un conjunto de trabajo de 300 KB y usa 100 KB para mostrar datos. El cliente basado en Win32 tiene un tamaño aproximado de 130 KB, usa un conjunto de trabajo de 300 KB y 100 KB para mostrar datos.

El cliente iniciará una conexión con Terminal Server a través del puerto TCP 3389. El subproceso del agente de escucha RDP de Terminal Server detectará la solicitud de sesión y creará una nueva instancia de pila de RDP para controlar la nueva solicitud de sesión. El subproceso del agente de escucha entregará la sesión entrante a la nueva instancia de pila RDP y seguirá escuchando en el puerto TCP 3389 para realizar más intentos de conexión. Cada pila de RDP se crea a medida que las sesiones de cliente están conectadas para controlar la negociación de los detalles de configuración de la sesión. Los primeros detalles serán establecer un nivel de cifrado para la sesión. Terminal Server admitirá inicialmente tres niveles de cifrado: bajo, medio y alto.

El cifrado bajo cifrará solo los paquetes que se envían desde el cliente a Terminal Server. Este cifrado de "solo entrada" es proteger la entrada de datos confidenciales, como la contraseña de un usuario. El cifrado medio cifrará los paquetes salientes del cliente igual que el cifrado de bajo nivel, pero también cifrará todos los paquetes de visualización que se devuelven al cliente desde Terminal Server. Este método de cifrado protege los datos confidenciales, ya que viaja a través de la red para que se muestre en una pantalla remota. Tanto el cifrado bajo como medio usan el algoritmo Microsoft-RC4 (algoritmo RC4 modificado con un rendimiento mejorado) con una clave de 40 bits. El cifrado alto cifrará los paquetes en ambas direcciones, hacia y desde el cliente, pero usará el algoritmo de cifrado RC4 estándar del sector, de nuevo con una clave de 40 bits. Una versión que no sea de exportación de Windows NT Terminal Server proporcionará cifrado RC4 de 128 bits de alto nivel.

Se producirá un intercambio de fuentes entre el cliente y el servidor para determinar qué fuentes comunes del sistema están instaladas. El cliente notificará a Terminal Server todas las fuentes del sistema instaladas para permitir una representación más rápida del texto durante una sesión RDP. Cuando Terminal Server sabe qué fuentes tiene disponible el cliente, puede ahorrar ancho de banda de red pasando cadenas de caracteres Unicode y fuente comprimida, en lugar de mapas de bits más grandes, al cliente.

De forma predeterminada, todos los clientes reservan 1,5 MB de memoria para una caché de mapa de bits que se usa para almacenar en caché mapas de bits, como iconos, barras de herramientas, cursores, etc., pero no se usan para contener cadenas Unicode. La memoria caché se puede optimizar (a través de una clave del Registro) y se sobrescribe mediante un algoritmo de uso menos reciente (LRU). Terminal Server también contiene búferes para permitir el paso controlado por flujo de las actualizaciones de pantalla a los clientes, en lugar de una secuencia de bits constante. Cuando la interacción del usuario en el cliente es alta, el búfer se vacía aproximadamente 20 veces por segundo. Durante el tiempo de inactividad, o cuando no hay ninguna interacción del usuario, el búfer se ralentiza solo a vaciar 10 veces por segundo. Puede ajustar todos estos números a través del Registro.

Una vez negociados los detalles de la sesión, la instancia de pila rdP del servidor para esta conexión se asignará a una sesión de usuario de Win32k inactiva existente y se le pedirá al usuario la pantalla de inicio de sesión de Windows NT. Si se configura el registro automático, el nombre de usuario y la contraseña cifrados se pasarán al servidor de Terminal Server y el inicio de sesión continuará. Si actualmente no existen sesiones win32k inactivas, el servicio Terminal Server llamará al Administrador de sesiones (SMSS) para crear un nuevo espacio de usuario para la nueva sesión. Gran parte de la sesión de usuario de Win32k usa código compartido y se cargará notablemente más rápido después de que una instancia se haya cargado anteriormente.

Después de que el usuario escriba un nombre de usuario y una contraseña, los paquetes se envían cifrados a Terminal Server. A continuación, el proceso de Winlogon realiza la autenticación de cuenta necesaria para asegurarse de que el usuario tiene privilegios para iniciar sesión y pasa el dominio y el nombre de usuario del usuario al servicio Terminal Server, que mantiene una lista de SessionID de dominio o nombre de usuario. Si un SessionID ya está asociado a este usuario (por ejemplo, existe una sesión desconectada), la pila de sesión activa se adjunta a la sesión anterior. A continuación, se elimina la sesión temporal de Win32 que se usa para el inicio de sesión inicial. De lo contrario, la conexión continúa como normal y el servicio Terminal Server crea una nueva asignación de SessionID de dominio o nombre de usuario. Si por algún motivo hay más de una sesión activa para este usuario, se muestra la lista de sesiones y el usuario decide cuál seleccionar para la reconexión.

Ejecución de una aplicación

Después de iniciar sesión del usuario, se muestra el escritorio (o la aplicación si está en modo de aplicación única) para el usuario. Cuando el usuario selecciona una aplicación de 32 bits para ejecutarse, los comandos del mouse se pasan a Terminal Server, que inicia la aplicación seleccionada en un nuevo espacio de memoria virtual (aplicación de 2 GB, kernel de 2 GB). Todos los procesos de Terminal Server compartirán código en los modos de usuario y kernel siempre que sea posible. Para lograr el uso compartido de código entre procesos, el administrador de memoria virtual (VM) de Windows NT usa la protección de páginas de copia en escritura. Cuando varios procesos quieren leer y escribir el mismo contenido de memoria, el administrador de máquinas virtuales asignará la protección de página de copia en escritura a la región de memoria. Los procesos (sesiones) usarán el mismo contenido de memoria hasta que se realice una operación de escritura, en cuyo momento el administrador de máquinas virtuales copiará el marco de página físico en otra ubicación, actualice la dirección virtual del proceso para que apunte a la nueva ubicación de página y marque la página como lectura y escritura. La copia en escritura es útil y eficaz para las aplicaciones que se ejecutan en un Terminal Server.

Cuando una aplicación basada en Win32, como Microsoft Word, se carga en memoria física mediante un proceso (sesión), se marca como copia en escritura. Cuando los nuevos procesos (sesiones) también invocan Word, el cargador de imágenes simplemente apuntará los nuevos procesos (Sesiones) a la copia existente porque la aplicación ya está cargada en memoria. Cuando se requieren búferes y datos específicos del usuario (por ejemplo, guardar en un archivo), las páginas necesarias se copiarán en una nueva ubicación de memoria física y se marcarán como lectura y escritura para el proceso individual (Sesión). El administrador de máquinas virtuales protegerá este espacio de memoria de otros procesos. Sin embargo, la mayoría de una aplicación es código que se puede compartir y solo tendrá una sola instancia de código en memoria física independientemente de cuántas veces se ejecute.

Es preferible (aunque no es necesario) ejecutar aplicaciones de 32 bits en un entorno de Terminal Server. Las aplicaciones de 32 bits (Win32) permitirán compartir código y se ejecutarán de forma más eficaz en sesiones multiusuario. Windows NT permite que las aplicaciones de 16 bits (Win16) se ejecuten en un entorno de Win32 mediante la creación de un equipo virtual basado en MS-DOS (VDM) para que se ejecute cada aplicación Win16. La salida de 16 bits se traduce en llamadas Win32, que realizan las acciones necesarias. Dado que las aplicaciones Win16 se ejecutan dentro de su propio VDM, el código no se puede compartir entre aplicaciones en varias sesiones. La traducción entre las llamadas Win16 y Win32 también consume recursos del sistema. La ejecución de aplicaciones Win16 en un entorno de Terminal Server puede consumir potencialmente dos veces los recursos que una aplicación comparable basada en Win32.

Desconectar sesión y cerrar sesión de usuario

Desconectar sesión

Si un usuario decide desconectar la sesión, los procesos y todo el espacio de memoria virtual permanecerán y se paginarán en el disco físico, si se requiere memoria física para otros procesos. Dado que Terminal Server mantiene una asignación de dominio o nombre de usuario y su sessionID asociado, cuando el mismo usuario se vuelve a conectar, la sesión existente se cargará y volverá a estar disponible. Una ventaja adicional de RDP es que puede cambiar las resoluciones de pantalla de sesión, en función de lo que el usuario solicite para la sesión. Por ejemplo, supongamos que un usuario se había conectado previamente a una sesión de Terminal Server con una resolución de 800 x 600 y desconectada. Si el usuario se mueve a un equipo diferente que solo admite la resolución 640 x 480 y vuelve a conectarse a la sesión existente, el escritorio se volverá a dibujar para admitir la nueva resolución.

Inicio de sesión de usuario

El logoff suele ser sencillo de implementar. Una vez que un usuario cierra sesión de la sesión, se finalizan todos los procesos asociados a SessionID y se libera cualquier memoria asignada a la sesión. Si el usuario ejecuta una aplicación de 32 bits como Microsoft Word y cierra sesión de la sesión, el código de la propia aplicación permanecerá en memoria hasta que el último usuario salga de la aplicación.