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

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

Se aplica a: Windows Server 2012 R2
Número de KB original: 186572

Inicialización del servidor de Terminal Windows

A medida que el Terminal Windows Server inicia 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. A cada conexión se le asigna 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 conexión.

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

A continuación, el servicio Terminal Server llama al Administrador de sesión 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 cliente o servidor basado en Windows NT (Csrss.exe) y se asigna un nuevo id. de sesión a ese proceso. El proceso CSRSS también invocará el proceso winlogon (Winlogon.exe) y el módulo de kernel de Win32k.sys (Interfaz de dispositivo gráfico y administrador de ventanas - GDI) en el id. de sesión recién asociado. El cargador de imágenes modificado de Windows NT reconocerá este Win32k.sys como una imagen cargable de SessionSpace por un bit predefinido establecido 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 Win32k.sys aún no se ha cargado. Por diseño, siempre se adjuntará al código de una imagen cargada anteriormente (Win32k.sys) si ya existe una en la memoria. Por ejemplo, desde cualquier aplicación o sesión activa.

La sección de datos (o no compartidos) 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 del dispositivo de pantalla del Protocolo de Escritorio remoto (RDP), Tsharedd.dll. Los controladores de mouse y teclado 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 de 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 puerto TCP número 3389.

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

Conexión de cliente

El cliente RDP se puede instalar y ejecutar en cualquier terminal basado en Windows (basado en WinCE), Windows para grupos de trabajo 3.11 que ejecute TCP/IP-32b o la plataforma basada en api de Microsoft Win32. El complemento Citrix Metaframe admite clientes no basados en Windows. El archivo ejecutable del cliente RDP de Windows para grupos de trabajo 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 a Terminal Server a través del puerto TCP 3389. El subproceso de agente de escucha RDP de Terminal Server detectará la solicitud de sesión y creará una nueva instancia de pila RDP para controlar la nueva solicitud de sesión. El subproceso de escucha entregará la sesión entrante a la nueva instancia de pila RDP y seguirá escuchando en el puerto TCP 3389 para más intentos de conexión. Cada pila 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 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 solo cifrará los paquetes que se envían desde el cliente a Terminal Server. Este cifrado de "solo entrada" es para 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 la información confidencial, ya que viaja a través de la red para mostrarse en una pantalla remota. Tanto el cifrado bajo como el medio usan el algoritmo Microsoft-RC4 (algoritmo RC4 modificado con 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 alto nivel de 128 bits.

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 disponibles el cliente, puede ahorrar ancho de banda de red pasando cadenas de caracteres Unicode y fuente comprimidas, 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 usa para contener cadenas Unicode. La memoria caché se puede tunable (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 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 para vaciar solo 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 autologon, el nombre de usuario y la contraseña cifrados se pasarán a Terminal Server y se iniciará el inicio de sesión. Si actualmente no hay ninguna sesión de Win32k inactiva, 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 se haya cargado anteriormente una instancia.

Una vez que el usuario escribe 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 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 sesiones actualmente activa se adjunta a la sesión anterior. A continuación, se elimina la sesión temporal de Win32 utilizada para el inicio de sesión inicial. De lo contrario, la conexión continúa con normalidad y el servicio Terminal Server crea una nueva asignación 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 del inicio de 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 kernel y user 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 quieran leer y escribir el mismo contenido de memoria, el administrador de máquinas virtuales asignará la protección de la 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, momento en el que el administrador de máquinas virtuales copiará el marco de página físico en otra ubicación, actualizará la dirección virtual del proceso para que apunte a la nueva ubicación de página y ahora marcará la página como de lectura y escritura. La copia en escritura es útil y eficaz para las aplicaciones que se ejecutan en terminal Server.

Cuando un proceso (sesión) carga una aplicación basada en Win32, como Microsoft Word, en la memoria física, 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 única instancia de código en la memoria física, independientemente del número de veces que 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 el uso compartido de código y se ejecutarán de forma más eficaz en sesiones de varios usuarios. 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. Toda 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 las aplicaciones en varias sesiones. La traducción entre las llamadas de Win16 y Win32 también consume recursos del sistema. La ejecución de aplicaciones Win16 en un entorno de Terminal Server puede consumir potencialmente el doble de recursos que una aplicación basada en Win32 comparable.

Desconexión de sesión y cierre de sesión del usuario

Desconexión de 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 es capaz de 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 conectó previamente a una sesión de Terminal Server con una resolución de 800 x 600 y se desconectó. Si el usuario se mueve a otro equipo que solo admite una resolución de 640 x 480 y se vuelve a conectar a la sesión existente, el escritorio se volverá a dibujar para admitir la nueva resolución.

Cierre de sesión del usuario

El cierre de sesión suele ser sencillo de implementar. Una vez que un usuario cierra la sesión, se finalizan todos los procesos asociados a SessionID y se libera la 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.