¿Por qué RDP va lento si la conexión es rápida? — Investigar por separado la entrada, el dibujado y la red

La prueba de velocidad marca cientos de Mbps y, sin embargo, en Escritorio remoto los caracteres aparecen con un ligero retraso. Al desplazarse por una página llena de fotos, la pantalla se entrecorta. Una aplicación de gestión se detiene unos segundos solo al pulsar su botón de búsqueda. ¿Por dónde conviene empezar a investigar esta situación de «la conexión es rápida, pero RDP va lento»?

La respuesta de RDP a las acciones no depende solo de la velocidad de transferencia de la conexión. Aunque la prueba de velocidad sea rápida, la espera puede producirse en el viaje de ida y vuelta de la red, en la espera de entrada de la aplicación del host, en la codificación de la pantalla o en la descodificación y presentación en el equipo local. Primero, separe «qué operación es lenta» y compare la misma operación cambiando una sola condición cada vez. Acote con comparaciones y mediciones dónde investigar, y elija la configuración de UDP y GPU en función de esos resultados. Véase: Tramos que mide la calidad de conexión, Factores de rendimiento en los hosts de sesión.

Sin embargo, haber acotado dónde investigar no significa que la causa raíz esté determinada. Aunque bajar la resolución mejore la situación, cambia no solo el tráfico de red sino también el procesamiento gráfico en ambos extremos, así que no afirme que «la causa era la conexión». Registre los resultados distinguiendo los tramos que ha medido de los que no ha medido.

Este artículo aísla la entrada, el desplazamiento y la respuesta de las aplicaciones una vez establecida la conexión. Aunque los síntomas se parezcan, la causa no tiene por qué ser una sola. Los casos en que «la pantalla de inicio de sesión tarda mucho en aparecer» o «se detiene solo en la autenticación» se tratan como un problema distinto, que se investiga a partir de los registros del establecimiento de la conexión y de la autenticación.

Se dirige principalmente a usuarios y administradores que se conectan desde «Conexión a Escritorio remoto» de Windows (mstsc) a Windows 11 o Windows Server. Los ejemplos de comandos son para Windows PowerShell 5.1. Se presupone que puede reproducir la misma operación en una sesión ya conectada.

La conexión directa, la VPN, RD Gateway y Azure Virtual Desktop difieren en la ruta, en la información de diagnóstico disponible y en dónde se aplica la configuración. El ejemplo de comprobación de TCP 3389 se limita a conexiones directas autorizadas a un host RDP que usa el puerto estándar. No aplique tal cual a los PC corrientes de la empresa las funciones de diagnóstico ni la configuración de GPU de la documentación de Azure Virtual Desktop.

En los equipos de la empresa, investigue solo dentro de lo que autorice el administrador. En un host compartido, identifique su propia sesión y el proceso en cuestión; si necesita registros de otros usuarios, pídaselos al administrador. Compruebe en cada entorno si los contadores de rendimiento están disponibles, cómo se llaman y qué permisos requieren.

Los métodos de comprobación que se muestran aquí se basan en documentación oficial. No son el informe de una medición en la que se haya reproducido y resuelto una avería en un equipo concreto. Los ejemplos numéricos se presentan claramente diferenciados como supuestos para la explicación.

El mecanismo puede leerse en orden a partir de la siguiente sección, «Velocidad de transferencia y tiempo de ida y vuelta». Si prefiere empezar por el síntoma, vaya a «Primera comparación según el síntoma». Los procedimientos prácticos están en «Comparar las condiciones de una en una» y en «Medir dónde está la espera».

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (7 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

Velocidad de transferencia y tiempo de ida y vuelta

RDP (Remote Desktop Protocol) es el protocolo que intercambia la entrada, la información de pantalla y otros datos entre el equipo local y el host. No solo transporta la pantalla y la entrada, sino también información como la de la redirección de dispositivos o la impresión. Véase: Información que transfiere RDP.

La velocidad de transferencia de la conexión expresa cuántos datos puede transportar por segundo. Los «500 Mbps» de una prueba de velocidad son una cifra referida a esa cantidad. No es una cifra que indique el tiempo que transcurre desde que se realiza una acción hasta que llega la respuesta. Véase: Requisitos de ancho de banda de RDP.

flowchart TB
    accTitle: Lo que representa la cifra de una prueba de velocidad
    accDescr: Muestra que los 500 Mbps de una prueba de velocidad son una cifra de la cantidad de datos que se puede transportar por segundo, distinta del tiempo que tarda en llegar la respuesta a una acción.
    A["Prueba de velocidad: 500 Mbps"] --> B["Datos transportados por segundo"]
    B -.->|"Otra cifra distinta"| C["Tiempo hasta que llega la respuesta"]

Figura 1: La cifra de la prueba de velocidad indica cuánto se puede transportar, no cuánto tarda en llegar la respuesta.

El tiempo de ida y vuelta (RTT) es lo que tarda una comunicación en llegar al otro extremo y volver. La diferencia entre subir la velocidad de transferencia y acortar el tiempo de ida y vuelta se parece a la diferencia entre añadir carriles a una carretera y acortar la distancia hasta el destino. Aunque aumente la capacidad de transportar grandes cantidades de archivos, si el tiempo de ida y vuelta es el mismo, la espera de respuesta a las acciones persiste. Véase: RTT y retardo en la presentación de la pantalla.

flowchart TB
    accTitle: La velocidad de transferencia y el tiempo de ida y vuelta como una carretera
    accDescr: Diagrama que compara subir la velocidad de transferencia con añadir carriles a una carretera, y acortar el tiempo de ida y vuelta con acortar la distancia hasta el destino.
    A["Subir la velocidad de transferencia"] -->|"En una carretera"| B["Añadir carriles"]
    B ~~~ C["Acortar el tiempo de ida y vuelta"]
    C -->|"En una carretera"| D["Acortar la distancia"]

Figura 2: Añadir carriles no acorta la distancia hasta el destino.

El recorrido de ida y vuelta de un carácter

Pensemos en escribir un carácter en el Bloc de notas remoto. El Bloc de notas se ejecuta en el host. Si, para la explicación, suponemos 50 milisegundos hasta que llega la acción y 50 milisegundos hasta que vuelve la información de pantalla resultante, el tiempo dedicado a la red suma 100 milisegundos, es decir, 0,1 segundos. Este ejemplo excluye el tiempo de procesamiento en ambos extremos.

flowchart TB
    accTitle: Ejemplo del tiempo de red hasta que vuelve el resultado de un carácter
    accDescr: Ejemplo que supone, para la explicación, 50 milisegundos a la ida y 50 a la vuelta. No incluye el tiempo de procesamiento en ambos extremos ni representa el número de paquetes por tecla.
    A["Escribir un carácter en local"] -->|"Ida: 50 ms"| B["El host recibe la entrada"]
    B --> C["Enviar la pantalla actualizada"]
    C -->|"Vuelta: 50 ms"| D["El resultado llega al equipo local"]

Figura 3: Suponiendo 50 milisegundos de ida y 50 de vuelta, solo la red ya tarda 0,1 segundos. No son valores medidos.

Aunque aumente lo que puede transportar la conexión, estos 0,1 segundos persisten si el tiempo de ida y vuelta no cambia. La figura 3 es un diagrama conceptual para entender el procesamiento. No significa que se envíe un viaje de ida y vuelta de paquetes independiente por cada tecla. Además, la ruta hacia el servidor de la prueba de velocidad es distinta de la ruta hacia el host RDP, así que hay que tener en cuenta la VPN, las puertas de enlace, el enlace de subida del lado del host y la congestión en el trayecto. Véase: Cómo entender el RTT, Rendimiento de la red y del host.

Generar y entregar la pantalla

El retardo de respuesta a las acciones del que se habla aquí es la espera desde que se realiza una acción en el equipo local hasta que se ve el resultado. Intervienen no solo el RTT, sino también el procesamiento de la aplicación y el trabajo de generar y entregar la pantalla. También se distingue del retardo del tramo de transferencia de la pantalla por sí solo. Véase: Tramo medido desde la captura de la pantalla hasta su presentación.

Cuando la entrada llega del equipo local al host, la aplicación del host procesa la entrada y actualiza la pantalla, la información de pantalla codificada se transporta por la conexión y el equipo local la descodifica y la presenta. Antes y después de la comunicación también hay trabajo del que se encargan PC distintos. Véase: Procesamiento desde la captura de la pantalla hasta su presentación.

flowchart TB
    accTitle: También hay procesamiento de pantalla antes y después de la conexión
    accDescr: Flujo desde que la entrada local llega al host y la aplicación del host la procesa y genera y comprime la pantalla, hasta que la información de pantalla transportada por la conexión se devuelve a una forma presentable y se muestra en el equipo local.
    I["Local: introducir la acción"] --> J["Conexión: transportar la entrada"]
    J --> K["Host: la aplicación procesa"]
    K --> A["Host: generar y comprimir pantalla"]
    A --> B["Conexión: transportar la pantalla"]
    B --> C["Local: devolver a forma presentable"]
    C --> D["Mostrar en la pantalla local"]

Figura 4: Procesar y comprimir en el host, transportar por la conexión y devolver a una forma presentable en el equipo local. Cada tarea se realiza en un lugar distinto.

En este artículo, la codificación es el procesamiento que, en el host, convierte y comprime la pantalla en una forma fácil de enviar. Aparte de la transferencia por la conexión, consume tiempo de procesamiento en el host. Véase: Tiempo de codificación en el host.

En este artículo, la descodificación es el procesamiento que devuelve la información de pantalla recibida a una forma que se pueda presentar en el equipo local. Se distingue del descifrado en el sentido de quitar el cifrado. Véase: Tiempo de descodificación y presentación en el equipo local.

Si la compresión en el host tarda, el envío espera a estar preparado aunque la conexión esté libre. Aunque la información haya llegado, la actualización se retrasa si la descodificación o la presentación locales no dan abasto. No siempre es cierto que «como el PC de la oficina es potente, el equipo local puede ser cualquiera». El margen de la conexión y el margen del procesamiento en sus dos extremos son cosas distintas. Véase: Contadores de rendimiento del procesamiento gráfico.

flowchart TB
    accTitle: Retrasos cuando el procesamiento de los extremos no da abasto
    accDescr: Muestra que, si la compresión en el host tarda, el envío espera aunque la conexión esté libre, y que, si la descodificación o la presentación locales no dan abasto, la actualización se retrasa aunque la información haya llegado.
    A["La compresión del host tarda"] --> B["El envío espera con la red libre"]
    B ~~~ C["La descodificación local no da abasto"]
    C --> D["Retraso aunque los datos lleguen"]

Figura 5: Aunque la conexión tenga margen, la pantalla se actualiza con retraso si el procesamiento de los extremos no da abasto.

Escribir frente a desplazarse

Al añadir un carácter en el Bloc de notas, cambia una parte pequeña de la pantalla. Al desplazarse por una página llena de fotos, la presentación cambia en una zona amplia una y otra vez. RDP contiene el tráfico transfiriendo las partes modificadas y con compresión y caché adaptadas al contenido. No envía cada vez la pantalla entera sin comprimir. La cantidad de trabajo varía según el contenido de la pantalla y la frecuencia de actualización. Véase: Relación entre el contenido de la pantalla y el ancho de banda.

flowchart TB
    accTitle: Cómo cambia el trabajo de pantalla al escribir y al desplazarse
    accDescr: Un cambio pequeño de un carácter y las actualizaciones continuas de una zona amplia difieren en la naturaleza del trabajo de generar y enviar la pantalla.
    A{"Cambio en pantalla"} -->|"Añadir un carácter"| B["Zona pequeña"]
    A -->|"Desplazamiento"| D["Zona amplia, sin pausa"]
    B --> E["Comprimir y enviar según el cambio"]
    D --> E

Figura 6: Incluso en la misma conexión, la cantidad de trabajo es distinta al añadir un carácter que cuando una zona amplia se mueve sin parar.

Aunque un documento estático resulte ligero, durante el desplazamiento la transferencia gráfica puede quedarse sin margen. Si se aumenta la resolución remota o el número de monitores, también crece la pantalla que hay que procesar. La comparación que baja la resolución es un experimento para ver si el movimiento se recupera al reducir el trabajo de generar y enviar la pantalla. No es un cálculo que determine el tráfico solo a partir del número de píxeles. Véase: Efecto de la resolución, las actualizaciones de pantalla y la compresión.

Esperas de la aplicación

Si solo la búsqueda de la aplicación de gestión se detiene unos segundos y en el Bloc de notas de la misma sesión se puede escribir con normalidad, compruebe qué está esperando esa aplicación. La aplicación del host puede, a su vez, pedir una búsqueda a otra base de datos o leer archivos de una carpeta compartida, y quedarse esperando la respuesta. Esa ruta es distinta de la comunicación RDP entre el equipo local y el host. Véase: Comunicación del host con los sistemas de back-end.

flowchart TB
    accTitle: Más allá de RDP también hay interlocutores
    accDescr: Muestra un caso en que, aparte de la comunicación entre el equipo local y el host, la aplicación del host espera la respuesta de un servidor de gestión.
    A["Equipo local"] -->|"RDP"| B["Aplicación de gestión del host"]
    B -->|"Búsqueda, petición de archivo"| C["Base de datos, carpeta compartida"]
    C -->|"Respuesta esperada"| B

Figura 7: La aplicación de gestión que hay detrás de RDP puede estar esperando, a su vez, la respuesta de otro servidor.

Cuando el procesamiento encargado de la pantalla y la entrada carga con un trabajo largo, la siguiente entrada y la siguiente actualización de pantalla se retrasan. En WPF, por ejemplo, la capacidad de respuesta se resiente si el subproceso de UI queda ocupado durante mucho tiempo. Un uso total de CPU bajo no basta por sí solo para descartar esperas en un subproceso de UI concreto. Véase: Dispatcher y el subproceso de UI.

flowchart TB
    accTitle: El procesamiento de la pantalla y la entrada se atasca
    accDescr: Muestra que, cuando el procesamiento encargado de la pantalla y la entrada carga con un trabajo largo, la siguiente entrada y actualización se retrasan, y que un uso total de CPU bajo no basta para descartar esa espera.
    A["Procesamiento de pantalla y entrada"] --> B["Carga con un trabajo largo"]
    B --> C["Se retrasan entrada y actualización"]
    C -.- D["CPU total baja no lo descarta"]

Figura 8: El uso total de CPU no basta para descartar esperas en el subproceso de UI.

Primera comparación según el síntoma

Lo que se puede transportar, el tiempo que se espera una respuesta y el tiempo de generar y presentar la pantalla son cosas distintas. Si se mantiene esta distinción, en lugar de atribuir «RDP va lento» a una única causa, se puede investigar a partir de la operación que va lenta ahora.

flowchart TB
    accTitle: Separar los tres aspectos antes de investigar
    accDescr: Muestra que no se atribuye «RDP va lento» a una única causa, sino que se separan lo que se puede transportar, el tiempo de espera de la respuesta y el tiempo de generar y presentar la pantalla, y se investiga a partir de la operación que va lenta ahora.
    A["«RDP va lento»"] --> S
    subgraph S["Mirar por separado"]
    direction TB
    B["Lo que se puede transportar"] ~~~ C["Tiempo de espera de la respuesta"]
    C ~~~ D["Tiempo de generar y mostrar la pantalla"]
    end
    S --> E["Empezar por la operación lenta"]

Figura 9: Separando lo que se puede transportar, el tiempo de espera de la respuesta y el tiempo de generar y presentar la pantalla, se puede investigar a partir de la operación que va lenta ahora.

El objetivo del aislamiento es limitar los lugares donde se busca la lentitud. No se pretende cambiar la configuración de golpe y conseguir por casualidad que vaya más rápido. Aprovechando diferencias como «el Bloc de notas funciona, pero solo se detiene la búsqueda» o «la escritura va normal, pero solo el desplazamiento va pesado», se puede elegir por dónde empezar a investigar incluso antes de cambiar la configuración de red.

La tabla siguiente es un punto de partida para la investigación. No es una tabla para determinar la causa. Compare primero las operaciones en la misma sesión y, después, cambie el equipo, la ruta o las condiciones de presentación que haga falta.

Los caracteres se retrasan en varias aplicaciones

Si en varias aplicaciones de la misma sesión los caracteres aparecen con retraso uno a uno, compare también la misma operación desde otro equipo o por otra ruta autorizada. Coteje el tiempo de ida y vuelta, las esperas de entrada en el host y la carga global del host, y no determine la causa a partir de una sola cifra.

Solo el desplazamiento se entrecorta

Aunque la escritura vaya normal, al desplazarse por una página llena de fotos se suceden actualizaciones de pantalla en una zona amplia. Cambie de uno en uno la resolución remota o el número de monitores y compare en la misma página. Si mejora, la compresión en el host, la transferencia gráfica y la descodificación local son lo siguiente que hay que investigar. La resolución por sí sola no permite saber cuál de estos tres es la causa. Véase: Carga según el contenido de la pantalla y la resolución.

Solo se bloquea una aplicación

Si solo se detiene la aplicación de gestión en la que se pulsó la búsqueda, compare si el Bloc de notas u otras aplicaciones de la misma sesión responden. Si las demás aplicaciones funcionan, investigue primero el procesamiento de la aplicación en cuestión, el disco y las peticiones a bases de datos o carpetas compartidas. Que la aplicación se maneje por RDP no es lo mismo que la comunicación RDP sea la causa de la espera. Véase: Factores de rendimiento de las aplicaciones y los sistemas de back-end.

Todos van lentos cuando hay más usuarios

Si en la misma franja horaria van lentos varios usuarios, consulte al administrador el estado de las demás sesiones. Coteje la carga de CPU, memoria y almacenamiento del host compartido y la de la línea compartida con las horas del síntoma. No acceda sin autorización a los registros o procesos de otros usuarios ni detenga sus trabajos. Véase: Recursos del host compartido y número de usuarios.

Lentitud al copiar o imprimir

Si el problema coincide con el momento en que empezó su propia copia o impresión, pause solo las transferencias que tenga autorización para detener y compare. Registre si todo se recupera tras la pausa y si vuelve a ir lento al reanudarla, e investigue la competencia con transferencias ajenas a la pantalla y con la redirección de dispositivos. No haga comparaciones que desactiven de golpe los dispositivos necesarios para el trabajo. Véase: Efecto de la redirección de dispositivos.

Comparar las condiciones de una en una

No hace falta cambiar todas las configuraciones una tras otra. Primero establezca una referencia de comparación y elija solo las comprobaciones que se ajusten al síntoma. Antes de cambiar la configuración o volver a conectarse, guarde su trabajo y anote los valores originales y cómo restaurarlos. Si no dispone de los permisos o funciones necesarios, no los active a la fuerza: traspase el caso al administrador.

El uso local y el uso por RDP no siempre se producen en las mismas condiciones. Que vaya rápido en la pantalla física del host es una referencia útil, pero las condiciones de la sesión y del dibujado pueden cambiar. Iguale el usuario, los datos y el estado de la aplicación, y no limite la causa a la conexión solo porque «en la pantalla física va rápido».

Comparar la misma operación

Prepare el mismo usuario, los mismos datos y la misma operación. En un host compartido, confirme cuál es su sesión y no detenga aplicaciones ni procesos de otros usuarios. El uso de otro equipo u otra ruta también se limita a lo que autorice el administrador.

1. Reproduzca la operación lenta con la configuración original y anote la hora y el síntoma.

   En el Bloc de notas de la misma sesión remota que la aplicación problemática, escriba una cantidad de texto parecida. Distinga si afecta solo a una aplicación o a toda la sesión.

2. Compruebe la carga del host y del equipo local en la misma franja horaria.

   En el Administrador de tareas, mire la CPU, la memoria y el disco de la aplicación en cuestión en el host, y la carga del cliente RDP en el equipo local. Compruebe el proceso en cuestión y no solo el valor total de CPU. Véase: Qué examinar al revisar la carga.

3. Cambie una sola condición (otro equipo, otra ruta autorizada o las condiciones de presentación) y repita la misma operación.

   En las comparaciones en las que también cambia a la vez el estado del host o de la aplicación, anote también esa diferencia. No considere el resultado de cambiar varias condiciones como el efecto de una sola.

4. Vuelva a las condiciones originales y compruebe de nuevo la misma operación.

   Si sigue yendo rápido después de restaurar, también puede deberse a un cambio temporal de la carga u otro factor. No dé por hecho que el cambio funcionó; anote las condiciones en las que se reproduce el síntoma.

Con los resultados del estado original, del estado modificado y del estado restaurado se puede comparar qué condiciones se corresponden con el síntoma. Una condición que mejoró la situación es una pista para la investigación; por sí sola no demuestra la causa raíz.

flowchart TB
    accTitle: Limitar las condiciones que se cambian a la vez
    accDescr: Flujo que fija una operación que se reproduce en el estado original, cambia una sola condición para comparar y comprueba también el resultado tras restaurar.
    A["Misma operación, configuración original"] --> B["Cambiar una sola condición"]
    B --> C["Repetir la misma operación"]
    C --> D["Restaurar y volver a comprobar"]
    D --> E["Anotar la condición que mejora"]

Figura 10: Se repite la misma operación en el estado original, tras el cambio y tras restaurar, y se anota la condición que produjo el cambio.

Comparar la resolución remota

Esta comparación sirve cuando las actualizaciones de pantalla, como el desplazamiento, van pesadas. Anote la resolución y el número de monitores antes del cambio, guarde su trabajo y vuelva a conectarse. No siga usando tal cual una configuración que perjudique las pantallas o la legibilidad del texto que necesita para trabajar.

1. Cambie solo uno de los dos: el número de monitores o la resolución.

   En mstsc se puede comparar con la configuración de la pestaña «Pantalla» antes de conectarse o especificando el ancho y el alto. Véase: Opciones de pantalla de mstsc.

2. Confirme que el tamaño real del escritorio del host ha cambiado y desplácese por la misma página.

   Si solo se reduce la ventana local, puede que simplemente se esté mostrando a escala reducida un escritorio grande. Distinga la resolución dinámica de smart sizing y compruebe las condiciones que admite el cliente que utiliza. Véase: Resolución del escritorio y escala de presentación.

3. Vuelva a la configuración original, repita la misma operación y compare la carga de ambos extremos y el movimiento de la pantalla.

   Si ha cambiado a la vez a baja resolución y a un solo monitor, la comparación es solo aproximada. Si mejora, restaure los cambios de uno en uno para separar sus efectos.

Si mejora, hay una pista en el ámbito del procesamiento gráfico y de la transferencia gráfica. 3840×2160 tiene cuatro veces los píxeles de 1920×1080, pero el tráfico no siempre se cuadruplica. Varía según las partes modificadas y la compresión, y el cambio de resolución afecta también al procesamiento en ambos extremos. Véase: Relación entre el número de píxeles y el tráfico, Comprobación del procesamiento gráfico.

flowchart TB
    accTitle: Lo que revela la comparación con menos resolución
    accDescr: Bajar la resolución remota puede cambiar la carga tanto del procesamiento gráfico como de la transferencia, así que una mejora por sí sola no permite limitar la causa a la conexión.
    A["Bajar la resolución remota"] --> S
    subgraph S["Procesos que cambian"]
    direction TB
    B["Procesamiento gráfico del host"] ~~~ C["Cantidad de datos enviados"]
    C ~~~ D["Presentación en el equipo local"]
    end

Figura 11: Cambiar la resolución es una comparación que afecta no solo a la conexión, sino también al procesamiento gráfico del host y del equipo local.

Cotejar copias e impresiones con el síntoma

Solo se pausan los procesos que se tiene autorización para detener, como las transferencias que haya iniciado uno mismo. No detenga las copias de seguridad ni los procesos de seguridad de la empresa, ni los trabajos de otros usuarios. No desactive de golpe la redirección de los dispositivos de audio y de entrada necesarios para el trabajo.

1. Anote la misma operación y la carga antes de empezar una copia, una sincronización en la nube o una impresión, y mientras se ejecuta.

   Además de la pantalla, por RDP también circula información de unidades, impresoras y otros dispositivos. La redirección, que permite usar en el host los dispositivos locales, puede aumentar la carga de red y de procesamiento mientras se usa. Véase: Efecto de la redirección de dispositivos.

2. Pause la transferencia en cuestión dentro de lo autorizado y compruebe de nuevo la misma operación.

   Si puede reanudarla y comparar, anote también el síntoma tras la reanudación. Si prueba a cambiar redirecciones de dispositivos innecesarias, cámbielas también de una en una y asegúrese de poder volver a la configuración original.

Se puede juzgar si el inicio de la transferencia se corresponde con el problema, y la pausa con la recuperación. Si se ve una correspondencia, coteje las transferencias ajenas a la pantalla y la carga de los recursos compartidos con los registros del administrador.

flowchart TB
    accTitle: Ver el antes y el después del problema en la misma línea temporal
    accDescr: Se anotan la misma operación y la carga antes de la transferencia, durante ella y tras detenerla, y se compara la relación entre el problema y la tarea.
    A["Operación y carga antes de transferir"] --> B["Operación y carga al transferir"]
    B --> C["Operación y carga tras detener"]
    C --> D["¿Coinciden problema y recuperación?"]

Figura 12: Se observa cómo cambian la lentitud de la misma operación y la carga antes de la transferencia, durante ella y después de detenerla.

Medir dónde está la espera

Desde el equipo local se examinan el viaje de ida y vuelta de la red y la conexión TCP; en el host, la espera en la cola de entrada y las actualizaciones de pantalla. Todas estas cifras cubren solo un tramo limitado, así que los resultados se leen a la luz de la tabla de «Alcance de los resultados de medición».

Comprobar ICMP y la conexión TCP

Se ejecuta en el equipo Windows local. Solo abarca las configuraciones que se conectan directamente, por la LAN corporativa o una VPN autorizada, a un host RDP que usa el puerto TCP 3389 estándar. En las configuraciones a través de RD Gateway o Azure Virtual Desktop, o con un puerto propio, decida con el administrador qué se comprueba. No exponga puertos ni modifique el firewall.

1. Introduzca un host autorizado y anote los resultados de la respuesta ICMP y de la conexión TCP.

   $target = Read-Host 'Nombre o dirección IP del host RDP que tiene autorización para investigar'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Indique el host de destino.'
   }
       
   # Mirar el tiempo de respuesta ICMP varias veces. Un fallo por sí solo no indica que RDP no esté accesible.
   ping.exe -n 20 $target
       
   # Comprobación limitada a configuraciones con conexión directa al puerto TCP 3389 estándar.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Coteje los resultados de las franjas lentas y de los momentos normales con las horas del síntoma y con la ruta de conexión real.

   Los 20 envíos de ping son una observación breve. Anote las fluctuaciones de los valores y la falta de respuesta, pero tenga en cuenta que ICMP puede estar bloqueado. No descarte paradas intermitentes solo por el valor medio; utilice la información de conexión y los registros de red del administrador. Véase: Qué mide ping.

TcpTestSucceeded: True significa que la conexión TCP al puerto indicado se realizó correctamente. No mide el ancho de banda, UDP, el uso después de la autenticación ni la fluidez de la pantalla. Test-NetConnection no tiene un modificador -UDP para comprobar UDP. Véase: Sintaxis y resultados de Test-NetConnection.

Al juzgar, tenga presentes las diferencias de ruta y de servicio. Con RD Gateway y similares, la ruta del ICMP o de la conexión TCP directa al host puede no coincidir con la ruta real de RDP. En Azure Virtual Desktop se pueden usar el RTT y las estimaciones de ancho de banda de cada conexión, pero esa función de diagnóstico es específica de ese servicio. No descarte paradas breves solo a partir de valores medios. Véase: Registros de calidad de conexión de Azure Virtual Desktop.

flowchart TB
    accTitle: La ruta comprobada y la ruta real de RDP
    accDescr: En configuraciones que usan RD Gateway o similares, la ruta del ICMP o de la conexión TCP directa del equipo local al host puede no coincidir con la ruta real de RDP.
    A["Equipo local"] -->|"ICMP, TCP directo"| C["Host RDP"]
    A -->|"RDP real"| B["RD Gateway u otro"]
    B --> C

Figura 13: El ICMP o la conexión TCP directa al host y el RDP real pueden no seguir la misma ruta.

Medir la espera en la cola de entrada

User Input Delay mide la espera en el host desde que la entrada entra en la cola hasta que un proceso la saca. No es el tiempo total desde que se pulsa una tecla hasta que se ve el carácter. Véase: Definición de User Input Delay.

Se examina dentro de la sesión remota del host. Las condiciones de compatibilidad de Microsoft son Windows 10, versión 1809 o posterior, y Windows Server 2019 o posterior. En estos sistemas no hace falta añadir una entrada de registro para habilitarlo. Compruebe los nombres que se muestran, los permisos y si existen los contadores; si no están disponibles, anote ese hecho y consulte al administrador. Véase: Condiciones de compatibilidad y configuración.

1. En PowerShell, en la misma sesión, anote la hora y el identificador de sesión.

   Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
   (Get-Process -Id $PID).SessionId
   query.exe session
       
   

   Para consultar las sesiones de otros usuarios pueden hacer falta permisos adicionales. El nombre de instancia estándar de un proceso es SessionID:ProcessID <Process Image>. No se guíe solo por el identificador de sesión y acabe mezclando valores de otros usuarios o de procesos con el mismo nombre. Véase: Permisos de query session, Identificación de instancias.

2. En perfmon.exe, agregue el contador disponible de entre User Input Delay per Process y User Input Delay per Session.

   Seleccione el proceso o la sesión en cuestión y observe al principio con el intervalo predeterminado de 1 segundo. Distinga la instancia agregada, que combina varias sesiones, de los valores de cada sesión.

3. Reproduzca la operación en la que la entrada va lenta y compare la espera en la cola con las horas del síntoma.

   Para cada destino de medición individual, el valor muestra la espera máxima dentro del intervalo de medición. Aunque el valor sea bajo, persisten el procesamiento después de que la aplicación saca la entrada y el retraso hasta que el resultado vuelve al equipo local.

Se puede averiguar si la entrada está esperando en la cola de entrada del host. Es un indicador distinto del tiempo percibido, que incluye el viaje de ida y vuelta de la red y la presentación en el equipo local. Véase: Significado del valor máximo y del intervalo de medición.

flowchart TB
    accTitle: El tramo que mide User Input Delay
    accDescr: El tramo medido va desde la cola de entrada del host hasta que la aplicación saca la entrada; no incluye la comunicación ni la presentación de pantalla anteriores y posteriores.
    A["Llega la entrada del equipo local"] --> B["Entra en la cola de entrada del host"]
    B -->|"Se mide aquí"| C["La aplicación saca la entrada"]
    C --> D["Procesamiento y envío de pantalla"]
    D --> E["Se muestra en el equipo local"]

Figura 14: Lo que se mide es la espera en la cola de entrada del host. No es el tiempo total hasta que se ve el resultado en el equipo local.

Examinar las actualizaciones de pantalla y los motivos de omisión

Prepare una operación con actualizaciones de pantalla continuas, como el desplazamiento. La disponibilidad de los contadores RemoteFX Graphics y el lugar en que miden deben comprobarse según el sistema operativo, la configuración del host y los permisos. Aquí solo se leen los contadores disponibles. No es un procedimiento para instalar ni habilitar las antiguas funciones de RemoteFX. Véase: Condiciones de aplicación de los contadores Graphics.

1. Con query session o qwinsta, confirme el nombre de la sesión en cuestión y seleccione la instancia de contador correspondiente.

2. Durante una operación con actualizaciones de pantalla, compare Input Frames/Second y Output Frames/Second.

   Si la salida es menor que la entrada, se están omitiendo fotogramas por el camino. Compruebe los valores de Frames Skipped/Second desglosados por falta de recursos en el host, en la red y en el cliente.

3. Coteje los motivos de omisión con la carga de ambos extremos y de la red, y compruebe también Average Encoding Time.

   Si el tiempo de codificación es largo, investigue el procesamiento de compresión del host. Si el número de fotogramas ya es bajo en la entrada, puede que la aplicación simplemente no actualice la pantalla con frecuencia. Que el número de fotogramas sea bajo con la pantalla estática no es anómalo en sí.

Con la entrada y la salida durante las actualizaciones de pantalla, los motivos de omisión y el tiempo de codificación se puede acotar dónde investigar. La clasificación de los contadores es una pista; hay que juzgarla junto con la carga real y la configuración de la conexión. Véase: Cómo leer el número de fotogramas y el tiempo de codificación.

flowchart TB
    accTitle: Acotar la investigación a partir de los fotogramas omitidos
    accDescr: Durante una operación con actualizaciones de pantalla se comparan los fotogramas de entrada y de salida y, con los contadores de motivos de omisión como pista, se cotejan con la carga del procesamiento, la red y la presentación.
    A["Comparar entrada y salida al desplazar"] --> B["Si la salida es menor, ver omisiones"]
    B --> C["Ver contadores por motivo"]
    C --> D["Cotejar carga de host, red y local"]

Figura 15: Se comparan la entrada y la salida durante el desplazamiento y se cotejan los motivos de omisión con la carga del host, de la conexión y del equipo local.

No generalice a todas las configuraciones los diagramas conceptuales de la transferencia gráfica ni la documentación antigua. Hay configuraciones que transfieren el vídeo y el audio por otro mecanismo. La documentación de los contadores Graphics también describe configuraciones antiguas, así que no reinterprete sus cifras como una especificación común del tipo «todo RDP está limitado a 30 fps». Compruebe a qué se aplican las funciones y las cifras antes de usarlas. Véase: Transferencia gráfica y cargas de trabajo, Documentación de los contadores Graphics.

Alcance de los resultados de medición

No identifique una cifra baja con un uso cómodo. El alcance de cada indicador puede comprobarse en la documentación de Microsoft citada en los procedimientos.

Configuración de red y GPU

La configuración de UDP y GPU se elige en función de lo que se haya averiguado con las comparaciones y mediciones. Si se sospecha de la red, compruebe primero el modo de conexión y la ruta; si se sospecha del procesamiento gráfico, compruebe primero en qué fases se usa la GPU.

Comprobar TCP/UDP y la ruta de conexión

Cuando las comparaciones y mediciones apunten a la red, compruebe con el administrador el cliente en uso, la ruta y las directivas aplicadas. Aunque haga falta cambiar la configuración, limítese al ámbito aprobado y anote los valores previos y el método de restauración. No desactive el firewall ni la autenticación, ni exponga el puerto RDP directamente a Internet.

1. Confirme el uso real de TCP/UDP y la ruta con la información de conexión, los registros de diagnóstico del producto y los registros de red del administrador.

   RDP usa TCP o UDP según la configuración y las condiciones de red. En «Select RDP transport protocols» se puede elegir entre una configuración que usa UDP o TCP y otra que usa solo TCP. Como RDP también puede pasar a TCP cuando no se logra establecer la conexión UDP, el éxito de la conexión por sí solo no indica el modo de transporte. Véase: Selección del transporte de RDP y paso a TCP.

2. Coteje la ruta y el modo con las horas del síntoma y compare solo la configuración necesaria, de una en una.

   No cambie la configuración de forma general pensando que «desactivar UDP lo acelerará». Compare igualando las condiciones de VPN y puerta de enlace, la operación y las condiciones de presentación, y deshaga los cambios innecesarios.

Una vez conocidos el modo y la ruta, se puede registrar la relación entre los cambios y el síntoma. Limitar la conexión a TCP no siempre la hace más rápida.

flowchart TB
    accTitle: Comprobar el modo de conexión antes de comparar la configuración de red
    accDescr: Se distingue la conexión directa normal de la conexión a través de puertas de enlace o servicios, se comprueban la ruta y el modo reales y después se hacen las comparaciones autorizadas.
    A["Cliente en uso y configuración"] --> B["Ver ruta real, TCP o UDP"]
    B --> C["Cotejar con la hora del síntoma"]
    C --> D["Comparar lo necesario de uno en uno"]

Figura 16: Se confirman el modo de conexión y la ruta en uso, se cotejan con el síntoma y solo después se compara la configuración necesaria.

RDP Shortpath es un mecanismo de Azure Virtual Desktop. Establece una ruta UDP de ese servicio y, según la configuración, usa una ruta directa o un relé. Si no puede establecerla, vuelve a una conexión basada en TCP. No puede compartir la misma tabla de configuración que una conexión directa con mstsc a un PC de la empresa. Véase: Rutas de RDP Shortpath y paso a TCP.

flowchart TB
    accTitle: Rutas de RDP Shortpath y paso a TCP
    accDescr: RDP Shortpath de Azure Virtual Desktop intenta establecer una ruta UDP; si lo consigue, usa una ruta directa o un relé según la configuración, y si no, vuelve a una conexión basada en TCP.
    A["RDP Shortpath"] --> B{"Ruta UDP"}
    B -->|"Establecida"| C["Directa o por relé"]
    B -->|"No establecida"| D["Volver a basada en TCP"]

Figura 17: Si RDP Shortpath no puede establecer la ruta UDP, vuelve a una conexión basada en TCP.

Comprobar el uso de la GPU en el procesamiento gráfico

Compruébelo cuando las comparaciones y mediciones apunten al procesamiento gráfico. Revise los resultados de medición del procesamiento gráfico junto con el sistema operativo, los controladores, las directivas y el cliente compatibles. No cambie la configuración solo porque haya una GPU instalada. Obtenga primero la aprobación del administrador y prepárese para restaurar.

1. Separe el dibujado de la aplicación del host, la codificación de RDP y la descodificación local, y elija la fase sospechosa.

   Aunque haya GPU, no todas las fases tienen por qué usarla. También en la documentación de configuración de Microsoft para Azure Virtual Desktop, el dibujado de la sesión remota y la codificación por hardware de los fotogramas se configuran y comprueban por separado. Véase: Configuración y verificación de la GPU para el dibujado y la codificación.

2. Siguiendo el procedimiento del producto en cuestión, confirme el uso real y mida la misma operación antes y después de cada cambio necesario.

   Si el tiempo de compresión es largo, investigue el uso de la GPU en la codificación. Cambiar la configuración de codificación de una aplicación que espera en la cola de entrada es apuntar al lugar equivocado. La legibilidad del texto y la fluidez del vídeo también requieren equilibrios distintos entre calidad de imagen, tráfico y carga de procesamiento. Véase: Diferencias según la carga de trabajo.

Más allá de si hay o no GPU, se puede registrar si la GPU se usa en la fase problemática y cómo cambiaron la carga y la respuesta de la misma operación. Los cambios que no aportan mejora se deshacen tras confirmarlo con el administrador.

flowchart TB
    accTitle: Comprobar el uso de la GPU fase por fase
    accDescr: Se separan el dibujado de la aplicación del host, la codificación de RDP y la descodificación local y, como aunque haya GPU no todas las fases tienen por qué usarla, se comprueba su uso en la fase sospechosa.
    A["Dibujado de la aplicación del host"] --> B["Codificación de RDP"]
    B --> C["Descodificación local"]
    C -.- D["Ver uso de GPU por fase"]

Figura 18: Aunque haya GPU, el dibujado, la codificación y la descodificación no tienen por qué usarla todos.

Nueva comprobación y traspaso

La mejora se confirma comprobando que, tras el cambio, la misma operación se realiza sin problemas y, además, que se mantienen la calidad de imagen, los dispositivos y las funciones de trabajo necesarios. Coteje también el resultado tras volver a las condiciones originales. Si la recuperación es solo momentánea, no dé por determinada la causa y regístrelo incluyendo las horas de mayor congestión y los procesos simultáneos.

flowchart TB
    accTitle: Orden para confirmar una mejora
    accDescr: Muestra que, tras el cambio, se comprueba que la misma operación se realiza sin problemas y que se mantienen la calidad de imagen, los dispositivos y las funciones de trabajo necesarios, se coteja con el resultado tras restaurar y una recuperación momentánea no basta para determinar la causa.
    A["Probar la misma operación tras el cambio"] --> B["Ver calidad, dispositivos, funciones"]
    B --> C["Cotejar con el resultado restaurado"]
    C -.- D["Una mejora puntual no es concluyente"]

Figura 19: Además del resultado de la misma operación, se cotejan las funciones necesarias y el resultado tras restaurar.

Traspaso cuando no se resuelve

Que no mejore, que no se reproduzca o que los contadores no estén disponibles también son resultados útiles. Separe las comparaciones que pudo hacer de las comprobaciones que no pudo hacer y traspase el caso al administrador o a los desarrolladores con la nota siguiente. Elimine de los registros compartidos la información de negocio innecesaria para la investigación, como nombres de usuario o de host.

Hora y zona horaria en que apareció el síntoma:
SO del host, cliente utilizado y su versión:
Conexión directa / VPN / RD Gateway / Azure Virtual Desktop u otra:
Operación y aplicación lentas; respuesta de otras aplicaciones de la sesión:
Resolución remota y número de monitores:
Copias, impresiones u otras tareas en curso al mismo tiempo:
La única condición cambiada y el resultado tras restaurar:
Carga y contadores observados en el host y en el equipo local:

Añada también si se pudo confirmar el uso real de TCP/UDP, qué elementos no se pudieron comprobar por falta de permisos u otros motivos y qué configuración es aceptable para el negocio. Decir «en el Bloc de notas se escribe con normalidad, pero al desplazarme por las fotos se detiene», en lugar de «la conexión va lenta», permite a la siguiente persona investigar en las mismas condiciones.

El usuario deja constancia de la operación que reproduce el problema y de los resultados de las comparaciones, y el administrador coteja los registros de la ruta de conexión, del host compartido y de las sesiones. El mero hecho de estar esperando a través de RDP no significa que el proceso que causa la espera sea RDP. Véase: Reparto de funciones entre el host y los sistemas de back-end.

Los desarrolladores de la aplicación registran por separado la recepción de los eventos de entrada, el inicio y el fin del procesamiento de bases de datos y archivos, y su reflejo en la UI. También estudian un diseño que no deje trabajo pesado instalado en el subproceso de UI. Sin embargo, el registro de fin de procesamiento en el host no registra el fin de la presentación en el equipo local. Véase: Separar el procesamiento para mantener la capacidad de respuesta de la UI.

Artículos relacionados

• Cómo entender el aislamiento de sesiones de Windows
• Diagnosticar con seguridad el disco al 100 % en Windows
• ¿Por qué «queda 1 segundo» tarda tanto?

Referencias

Son fuentes primarias de Microsoft Learn. El contenido citado se comprobó el 17 de septiembre de 2026. Al leerlas, distinga las condiciones de aplicación de cada producto y tenga en cuenta que no son mediciones realizadas para este artículo.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Distinción entre el RTT y el retardo desde la captura de la pantalla en el host hasta su presentación en el equipo local. La función de diagnóstico en sí es para Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Relación entre el contenido de la pantalla, la resolución, la actualización de fotogramas, la compresión, la caché y el tráfico.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Cómo comprobar la entrada y salida de la pantalla, los motivos de omisión de fotogramas y el tiempo de codificación. Como incluye descripciones de configuraciones antiguas, no se generalizan sus límites numéricos a todo RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Carga del host compartido, comunicación del host con los sistemas de back-end y efecto de la redirección de dispositivos.
• Microsoft Learn, Threading model. El subproceso de UI y Dispatcher de WPF, y la separación del procesamiento para mantener la capacidad de respuesta.
• Microsoft Learn, mstsc. Especificación del ancho y el alto de Escritorio remoto y de varios monitores.
• Microsoft Learn, Supported RDP properties. Distinción entre la resolución del escritorio, la resolución dinámica y smart sizing. Compruebe los clientes compatibles y las condiciones de aplicación de cada producto.
• Microsoft Learn, ping. Comprobación de la respuesta mediante ICMP Echo y sus opciones.
• Microsoft Learn, Test-NetConnection. Comprobación de la conexión TCP y significado de los resultados.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Tramo que mide User Input Delay, sistemas operativos admitidos, instancias y significado del valor máximo.
• Microsoft Learn, query session. Información de las sesiones y permisos necesarios para consultar otras sesiones.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Selección de TCP o UDP para RDP y paso a TCP como alternativa.
• Microsoft Learn, RDP Shortpath. Rutas UDP para Azure Virtual Desktop y comportamiento cuando no se pueden establecer.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Configuración y verificación de la GPU que tratan por separado el dibujado y la codificación de fotogramas.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas son páginas de temas cercanos a este. A partir del artículo, puede pasar a los servicios relacionados y a otros artículos.

Servicios relacionados con este tema

Este artículo enlaza con las siguientes páginas de servicios. Puede empezar por una entrada cercana a su situación.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

La prueba de velocidad marca cientos de Mbps; ¿por qué va lenta la entrada en RDP?

La rapidez con que se transportan grandes cantidades de datos y el tiempo que tarda en volver la respuesta a una acción son cosas distintas. Intervienen el envío de la entrada, el procesamiento de la aplicación en el host, la compresión de la pantalla, su transferencia y su presentación en el equipo local. Además, la ruta de red hacia el servidor de la prueba de velocidad no es la misma que hacia el host RDP.

Se puede escribir con normalidad, pero solo el desplazamiento se entrecorta. ¿Es un problema de la conexión?

No se puede atribuir solo a la conexión. Cuando aumentan las actualizaciones de pantalla, puede que el dibujado y la compresión en el host, la red, o la descodificación y la presentación en el equipo local no den abasto. Cambie de uno en uno la resolución remota o el número de monitores y compare; si hace falta, examine los contadores relacionados con los gráficos.

Si el ping es rápido, ¿la comunicación RDP funciona con normalidad?

Eso por sí solo no permite juzgarlo. El ping mide la respuesta a ICMP; no mide la transferencia gráfica de RDP ni el procesamiento de la aplicación. En configuraciones que usan RD Gateway o elementos similares, la ruta tampoco tiene por qué coincidir. Si no hay respuesta, distinga entre el bloqueo de ICMP y la imposibilidad de comunicarse por RDP.

¿User Input Delay es el tiempo entre pulsar una tecla y que aparezca el carácter?

No. Es un contador que mide la espera en el host desde que la entrada entra en la cola hasta que un proceso la saca. No es el retardo percibido, que incluye el viaje de ida y vuelta por la red, el procesamiento de la aplicación después de sacar la entrada y la compresión, descodificación y presentación de la pantalla.

¿Hay que desactivar UDP cuando RDP va lento?

No lo recomendamos de forma general. Compruebe primero el modo de transporte real, la ruta y las directivas aplicadas. Puede que UDP no esté disponible y que la conexión haya recurrido a TCP, y pasar a solo TCP no siempre acelera las cosas. Compare en las mismas condiciones con la autorización del administrador y deshaga los cambios innecesarios.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, con especial solvencia en proyectos en los que perduran activos existentes y en investigaciones de fallos cuya causa cuesta ver.