¿Por qué RDP va lento en una conexión rápida? — Separar la entrada, el dibujado y la red

Una prueba de velocidad marca cientos de Mbps y, sin embargo, en Escritorio remoto los caracteres aparecen con un compás de retraso. Desplace una página llena de fotos y la pantalla se entrecorta aún más.

La clave para entender esa discrepancia es esta: poder transportar muchos datos y obtener una respuesta rápida a una acción son dos cosas distintas. Además, la pantalla que vuelve como respuesta se produce en el PC host y se muestra en el PC que tiene delante. No es un trabajo que el enlace de red haga por sí solo.¹

En la misma pantalla remota, sigamos qué cambia al pasar de escribir a desplazarse y luego a ejecutar una búsqueda en una aplicación de negocio. Las secciones 1 a 4 explican el mecanismo, y de la sección 5 en adelante viene la parte de investigación, para examinarlo de verdad.

1. Un enlace más rápido no acorta necesariamente la espera de una respuesta

Suponga que escribe un carácter en el Bloc de notas de la máquina remota. Lo que ve es la pantalla justo delante de usted, pero el Bloc de notas se ejecuta en el PC host. Su acción se envía allí, la información sobre la pantalla modificada vuelve aquí y el carácter aparece.

¿Qué parte de ese viaje de ida y vuelta representan entonces los «500 Mbps» de una prueba de velocidad?

Es una cifra de cuántos datos pueden transportarse en un segundo. Esa capacidad es lo que importa cuando el archivo que descarga es grande. Lo que usted nota al escribir un solo carácter, en cambio, es el tiempo desde que pulsa la tecla hasta que vuelve el resultado. Es como la diferencia entre añadir carriles a una carretera y acortar la distancia hasta el destino.¹

Para explicarlo, supongamos que la acción tarda 50 milisegundos en llegar al host y que la información de pantalla resultante tarda 50 milisegundos en volver. En ese caso, el tiempo dedicado solo a la red suma 100 milisegundos, es decir, 0,1 segundos. El tiempo de procesamiento en los PC de ambos extremos queda de momento al margen.

flowchart TB
    accTitle: Ejemplo del tiempo de red hasta que vuelve el resultado de un carácter
    accDescr: Un ejemplo que supone 50 milisegundos en cada sentido para explicarlo. Excluye el tiempo de procesamiento en ambos extremos y no representa un 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 con la entrada aplicada"]
    C -->|"Vuelta, 50 ms"| D["El resultado llega a su equipo"]

Figura 1: Si la ida tarda 50 milisegundos y la vuelta 50 milisegundos, solo la red supone 0,1 segundos. No son valores medidos.

Ese tiempo para cruzar la red y volver se llama tiempo de ida y vuelta (RTT). Aunque cambie a un enlace capaz de transportar más, la espera de una respuesta de la figura 1 sigue igual mientras el tiempo de ida y vuelta se mantenga.¹

Por eso las descargas pueden ir rápidas mientras escribir sigue llegando con un compás de retraso. Veamos ahora el caso en que, en la misma conexión, escribir no da problemas pero el desplazamiento se vuelve pesado.

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

2. El desplazamiento aumenta el trabajo de enviar la pantalla

Cuando añade un carácter en el Bloc de notas, solo cambia visualmente una pequeña parte de la pantalla. Desplace, en cambio, una página cuajada de fotos y un área amplia de la presentación cambia fotograma tras fotograma.

RDP no envía toda la pantalla sin comprimir cada vez. Envía las regiones que cambiaron y contiene el tráfico con compresión y almacenamiento en caché adecuados al contenido. La cantidad de trabajo de actualizar y enviar es distinta entre añadir un carácter y fotos que no dejan de moverse.²

flowchart TB
    accTitle: Cómo cambia la carga de pantalla entre escribir y desplazarse
    accDescr: Un pequeño cambio de carácter y una actualización continua sobre un área amplia difieren en la naturaleza del trabajo de producir y enviar la pantalla.
    A["Añadir un carácter en el Bloc de notas"] --> B["Cambia una región pequeña"]
    C["Desplazar una pantalla llena de fotos"] --> D["Un área amplia cambia continuamente"]
    B --> E["Comprimir y transferir según el cambio"]
    D --> E

Figura 2: En la misma conexión, la cantidad de trabajo difiere entre añadir un carácter y un área amplia que no deja de moverse.

Como consecuencia, todo puede sentirse ligero mientras lee un documento estático y, sin embargo, la transferencia gráfica puede quedarse sin margen en cuanto empieza a desplazarse. Subir la resolución del lado remoto o añadir monitores también agranda lo que hay que producir y enviar.²

Solo ahora queda claro por qué merece la pena bajar la resolución y comparar. No es un conjuro para hacer RDP más rápido, sino un experimento para ver si la capacidad de respuesta vuelve una vez reducido el trabajo de producir y enviar la pantalla. La sección 5 explica cómo probarlo en detalle.

Si escribir va bien pero solo el desplazamiento es pesado, puede deberse a que el mismo enlace está atendiendo muchas más actualizaciones de pantalla. ¿Y qué ocurre entonces cuando el enlace aún tiene margen pero la pantalla no da abasto?

3. Aun con el enlace desocupado, el PC que produce la pantalla puede hacerle esperar

La pantalla se procesa tanto antes de enviarse como después de recibirse

Cuando desplaza una página de fotos, el PC host actualiza la presentación y convierte y comprime la información de pantalla en una forma más fácil de enviar. Eso es la codificación. El PC que tiene delante vuelve a convertir la información que llega en una forma que pueda mostrar. Ese lado se llama descodificación.¹

flowchart TB
    accTitle: El procesamiento de pantalla ocurre a ambos lados del enlace
    accDescr: La compresión en el host, la transferencia por la red y la descodificación y presentación en su equipo son pasos distintos, y las actualizaciones de pantalla se retrasan si alguno no da abasto.
    A["El host produce y comprime la pantalla"] --> B["El enlace transporta la información de pantalla"]
    B --> C["El equipo local la vuelve a convertir en forma presentable"]
    C --> D["Mostrado en la pantalla local"]

Figura 3: Comprimir en el host, transportarlo por el enlace, volver a convertirlo en presentación en el equipo local. Cada cosa es trabajo hecho en un lugar distinto.

Suponga, por ejemplo, que comprimir la pantalla en el host está llevando tiempo. Aun con el enlace desocupado, usted espera a que la información que enviar esté lista. A la inversa, aunque la información haya llegado, la actualización de pantalla llega tarde si el PC local no da abasto con la descodificación y la presentación.³

El reflejo es pensar que el PC de la oficina es potente y que en el extremo local vale cualquier cosa, pero el PC local sigue teniendo la tarea de mostrar la pantalla que recibe. El margen en el enlace y el margen en el procesamiento de ambos extremos son dos cosas distintas.

Si solo se congela una aplicación, puede que esté esperando la respuesta de esa aplicación

Considere ahora un caso en que, en la misma pantalla remota, pulsar Buscar en una aplicación de negocio la congela varios segundos. Mientras tanto, suponga que puede escribir con normalidad en una ventana del Bloc de notas abierta al lado.

En ese caso querrá ver qué está esperando la aplicación de negocio. La aplicación del host puede estar pidiendo a una base de datos aparte que ejecute la búsqueda, y la respuesta puede tardar en volver. Leer un archivo de una carpeta compartida produce el mismo tipo de espera.⁴

flowchart TB
    accTitle: Más allá de RDP hay otro interlocutor
    accDescr: Muestra el caso en que, aparte del tráfico que enlaza el cliente local y el host, la aplicación del host espera una respuesta de un servidor de negocio.
    A["Cliente local"] -->|"RDP"| B["Aplicación de negocio en el host"]
    B -->|"Petición de búsqueda o de archivo"| C["Base de datos y carpetas compartidas"]
    C -->|"La respuesta que la aplicación espera"| B

Figura 4: La aplicación de negocio al otro lado de la conexión RDP puede, a su vez, estar esperando la respuesta de otro servidor más.

Además, cuando el código responsable de la pantalla y la entrada de una aplicación asume una tarea larga, no puede pasar a la siguiente entrada o actualización de pantalla. Un subproceso de interfaz de WPF que permanece ocupado mucho rato produce exactamente ese tipo de respuesta demorada. Mirar solo el uso global de CPU puede dejarle ciego ante una espera en el código que gestiona la pantalla.⁵

Que esté esperando ante una pantalla de RDP no significa que sea RDP quien le hace esperar. Esa diferencia de «el Bloc de notas funciona pero solo se congela la búsqueda» es una pista que puede encontrar antes de cambiar ningún ajuste de red.

4. Balance provisional: la velocidad del enlace es solo una parte de la capacidad de respuesta

Volvamos a la pregunta inicial: ¿por qué va lento si el enlace es rápido?

En el caso de escribir había una espera de respuesta entre enviar la acción y recibir el resultado. En el caso del desplazamiento subió la cantidad de pantalla que actualizar y enviar. Y la aplicación que produce esa pantalla, junto con el procesamiento gráfico en los PC de ambos extremos, también lleva tiempo.

Una cifra grande en una prueba de velocidad no le dice por sí sola si esos tres elementos están en buen estado. Es más, al servidor de la prueba de velocidad y al host RDP situado tras una VPN o una puerta de enlace se llega por rutas distintas. También intervienen el sentido de subida en el host que empuja la pantalla y la congestión del camino.¹⁴

Lo cómodo que resulta RDP lo decide no solo cuánto se puede transportar, sino con qué rapidez se hace visible el resultado de una acción. Aquí termina la explicación del mecanismo. Cuando investigue de verdad la lentitud, use las secciones de investigación siguientes para elegir la comparación que encaje con su síntoma.

5. Investigación: primero compare la misma acción, una condición cada vez

Los ejemplos de investigación suponen el cliente Conexión a Escritorio remoto de Windows y un host con Windows 11 o Windows Server. Los ejemplos de comandos apuntan a Windows PowerShell 5.1. En un dispositivo de empresa, mantenga las comparaciones dentro del alcance que permita su administrador, y guarde su trabajo antes de cambiar ajustes y volver a conectarse.

Use los tres casos anteriores como punto de entrada para elegir una comparación. La tabla no es un veredicto sobre la causa, sino un punto de partida para la investigación.

Si la pantalla de inicio de sesión tarda mucho en aparecer, o si todo se atasca solo en la autenticación, empiece examinando los registros de establecimiento de conexión y autenticación. El punto de entrada de esa investigación es distinto de la entrada y el desplazamiento posteriores a la conexión que se tratan aquí.

¿Hay otra aplicación demorada del mismo modo?

Escriba aproximadamente la misma cantidad de texto en la aplicación problemática y en el Bloc de notas. Comparar primero dentro de la misma sesión remota le permite ver la diferencia entre aplicaciones sin cambiar el host ni el enlace. En el Administrador de tareas, compruebe la CPU, la memoria y el disco de la aplicación en cuestión en el host, y la carga del cliente RDP en su propio equipo.⁴

Cuando compare en otro cliente u otra ruta permitida, repita allí la misma acción y registre también el resultado tras deshacer el cambio. En un host usado por varios usuarios, asegúrese de estar mirando su propia sesión y sus propios procesos.

flowchart TB
    accTitle: Limite las condiciones que cambia a la vez
    accDescr: Un flujo que fija una acción que reproduce el problema en el estado original, cambia una sola condición y compara, y después comprueba también el resultado tras deshacerlo.
    A["Misma acción con los ajustes originales"] --> B["Cambiar solo una condición"]
    B --> C["Repetir la misma acción"]
    C --> D["Deshacer y comprobar de nuevo"]
    D --> E["Registrar la condición que mejoró las cosas"]

Figura 5: Repita la misma acción en el estado original, tras el cambio y tras deshacerlo, y registre qué condición marcó la diferencia.

Comparar trabajando en la pantalla física del host también resulta instructivo. Tenga en cuenta, no obstante, que la sesión y las condiciones de dibujado pueden diferir entre el trabajo local y RDP. Iguale el usuario, los datos y el estado de la aplicación, y no cargue la causa al enlace solo porque «en la pantalla física va rápido».

Cuando el desplazamiento sea pesado, baje la resolución del lado remoto

Cambie primero o bien el número de monitores o bien la resolución, y desplace después la misma página. Con mstsc en Windows puede comparar usando los ajustes de pantalla antes de conectar o especificando un ancho y un alto. Compruebe que el escritorio del host ha cambiado realmente de tamaño, y no solo que la ventana de su equipo se ha hecho más pequeña. A veces una pantalla grande se muestra simplemente reducida a escala.⁶⁷

3840 × 2160 tiene cuatro veces los píxeles de 1920 × 1080, pero eso no significa que el tráfico sea siempre el cuádruple. Varía con las regiones que cambiaron y con lo bien que funcione la compresión. Bajar la resolución cambia además el procesamiento gráfico de ambos extremos, no solo el tráfico, así que si mejora las cosas tómelo como el ámbito en el que está la pista.²³

flowchart TB
    accTitle: Qué puede decirle una comparación con la resolución bajada
    accDescr: Bajar la resolución del lado remoto puede cambiar tanto el procesamiento gráfico como la carga de transferencia, así que una mejora por sí sola no puede cargar la causa al enlace.
    A["Bajar la resolución del lado remoto"] --> B["El procesamiento gráfico en el host cambia"]
    A --> C["La cantidad de información enviada cambia"]
    A --> D["El procesamiento de presentación en su equipo cambia"]

Figura 6: Cambiar la resolución es una comparación que afecta no solo al enlace, sino también al procesamiento gráfico en el host y en su propio equipo.

Cambiar varias condiciones a la vez, como pasar a una única pantalla de baja resolución, solo da una comparación burda. Tras la mejora, deshaga una cada vez para separar los efectos, y elija los ajustes del día a día pensando también en la legibilidad del texto.

¿Se ralentiza en cuanto arranca una copia o una impresión?

Por RDP fluye más que la pantalla: también viaja información para unidades, impresoras y otros dispositivos. La redirección, que hace utilizables sus dispositivos locales en el lado remoto, puede aumentar la carga de red y de procesamiento mientras está en uso. Pause las copias, la sincronización en la nube y las impresiones que haya iniciado usted, dentro de lo que tenga permitido, y compare.⁴

flowchart TB
    accTitle: Ver en una sola línea de tiempo el periodo anterior y posterior al problema
    accDescr: Registrar la misma acción y la carga antes de una transferencia, durante ella y tras detenerla, y comparar cómo se relaciona el problema con ese trabajo.
    A["Acción y carga antes de la transferencia"] --> B["Acción y carga durante la transferencia"]
    B --> C["Acción y carga tras detenerla"]
    C --> D["Si el problema y la recuperación coinciden"]

Figura 7: Observe cómo cambian la lentitud de la misma acción y la carga antes de la transferencia, durante ella y tras detenerla.

También puede comparar la redirección de dispositivos innecesarios de uno en uno. No es un procedimiento para desactivar de golpe los dispositivos de audio y entrada que el negocio necesita, ni para detener por iniciativa propia los procesos de copia de seguridad o de seguridad de la empresa.

6. Investigación: confirme con números dónde está la espera

Confirme con mediciones las comparaciones de la sección 5. Para escribir, mire los números de la red y de la espera de entrada; para el desplazamiento, los del procesamiento gráfico.

Desde su equipo: examine el viaje de red y la conexión TCP

Lo que sigue es un ejemplo en su propio cliente Windows. Supone que se conecta directamente al host RDP por la LAN corporativa o una VPN permitida, y que el host usa el puerto TCP estándar 3389. Pasar por una puerta de enlace RD o por Azure Virtual Desktop cambia tanto lo que comprueba como la ruta seguida. No exponga puertos ni cambie ajustes del firewall.

$target = Read-Host 'Nombre o dirección IP de un host RDP que tenga permitido investigar'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Indique el host al que conectarse.'
}

# Mirar varias veces el tiempo de respuesta a ICMP. Un fallo por sí solo no prueba que RDP sea inalcanzable.
ping.exe -n 20 $target

# Una comprobación limitada a configuraciones que conectan directamente al puerto TCP estándar 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping examina el tiempo de respuesta a ICMP. Si los valores oscilan mucho durante la franja lenta, regístrelo. ICMP también puede estar bloqueado, en cuyo caso no responde nada. A la inversa, una serie de valores pequeños no significa que haya examinado la transferencia gráfica de RDP ni el procesamiento de la aplicación.⁸

TcpTestSucceeded: True es un resultado que dice que la conexión TCP a ese puerto tuvo éxito. No mide ni el ancho de banda, ni UDP, ni lo fluidos que son el manejo y la pantalla tras la autenticación. Test-NetConnection no tiene un modificador -UDP para examinar UDP.⁹

Veinte sondeos de ping son una observación breve. Para incidencias intermitentes, contraste la hora del síntoma con la información de conexión. Azure Virtual Desktop también ofrece el RTT y el ancho de banda estimado por conexión, pero no descarte atascos breves basándose solo en las medias.¹

En el host: examine la espera hasta que la aplicación recoge la entrada

Abra perfmon.exe dentro de la sesión remota del host y, donde el entorno lo admita, añada User Input Delay per Process o User Input Delay per Session. Seleccionar la sesión y el proceso en cuestión permite observar la espera entre el encolado de la entrada y su recogida por la aplicación.¹⁰

flowchart TB
    accTitle: El intervalo que mide User Input Delay
    accDescr: El intervalo medido va desde la cola de entrada del host hasta que la aplicación recoge la entrada, y no incluye ni la red ni la presentación de la pantalla antes y después.
    A["La entrada llega desde su equipo"] --> B["Entra en la cola de entrada del host"]
    B -->|"Esto es lo que se mide"| C["La aplicación recoge la entrada"]
    C --> D["Procesamiento de la aplicación y transferencia gráfica"]
    D --> E["Mostrado en su equipo"]

Figura 8: Lo que se mide es la espera en la cola de entrada del host. Ese no es el tiempo total hasta que el resultado se hace visible en su equipo.

El valor es la espera más larga dentro del intervalo de medición. Se admite en Windows 10 versión 1809 y posteriores y en Windows Server 2019 y posteriores, y en esos destinos no hace falta ninguna entrada del Registro para habilitarlo. Observe para empezar con el intervalo predeterminado de un segundo. Compruebe los nombres mostrados, los contadores disponibles y los permisos necesarios frente a su propio entorno.¹⁰

El nombre de instancia estándar por proceso es SessionID:ProcessID <Process Image>. Desde 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

Mostrar las sesiones de otros usuarios puede requerir permisos adicionales. Contraste con los registros del administrador si hace falta, y retire de los registros que comparta los nombres de usuario y la información de host que el negocio no necesite.¹¹

Aunque este valor sea bajo, siguen quedando el procesamiento posterior a que la aplicación recoja la entrada y el retardo hasta que vuelve la pantalla resultante. El intervalo que mide es distinto del tiempo de ida y vuelta de la sección 1 y del tiempo percibido entre pulsar una tecla y ver el carácter.

En el host: examine si las actualizaciones de pantalla se envían íntegras

Para los tirones durante el desplazamiento, use los contadores RemoteFX Graphics donde estén disponibles. Compruebe el nombre de la sesión en cuestión con query session o qwinsta y seleccione la instancia correspondiente. Dónde mide un contador y si está disponible hay que confirmarlo frente al sistema operativo, la configuración del host y sus permisos.³

Durante una operación que actualice la pantalla, compare Input Frames/Second con Output Frames/Second. Si la salida es menor que la entrada, se están perdiendo fotogramas por el camino. Mirar los valores de Frames Skipped/Second desglosados por recursos insuficientes de host, red y cliente le da una pista para acotar dónde investigar.³

flowchart TB
    accTitle: Acotar dónde investigar a partir de los fotogramas perdidos
    accDescr: Comparar el número de fotogramas de entrada y de salida durante una operación que actualiza la pantalla y, usando como pista los contadores del motivo de la pérdida, contrastar con la carga de procesamiento, de red y de presentación.
    A["Comparar entrada y salida al desplazarse"] --> B["Si la salida es menor, buscar fotogramas perdidos"]
    B --> C["Mirar los contadores desglosados por motivo"]
    C --> D["Contrastar con la carga del host, la red y el equipo local"]

Figura 9: Compare entrada y salida al desplazarse, y contraste el motivo de los fotogramas perdidos con la carga en el host, el enlace y su propio equipo.

Cuando el número de fotogramas ya es bajo del lado de la entrada, puede que la aplicación simplemente no actualice la pantalla a menudo. Un número bajo de fotogramas en una pantalla estática no es anómalo. Si hay actualizaciones y aun así va lento, mire también Average Encoding Time para ver si la compresión en el host está llevando tiempo.³

Una nota sobre cómo leer la documentación de medición. El diagrama de la sección 1 es conceptual, para entender una transferencia gráfica corriente, no una afirmación de que se envíe un paquete de ida y vuelta independiente por tecla. Algunas configuraciones transfieren vídeo y audio mediante un mecanismo aparte. Use los registros de calidad de conexión de Azure Virtual Desktop, y la documentación de los contadores Graphics que todavía cubre configuraciones antiguas, solo tras confirmar a qué se aplica la funcionalidad. No lea las cifras de esa documentación como una especificación común del tipo «todo RDP está limitado a 30 fps».²¹³

7. Investigación: elija los ajustes de UDP y GPU acordes con lo que haya encontrado

Si la red es sospechosa, confirme primero la ruta y el transporte reales

RDP usa TCP o UDP según la configuración y las condiciones de red. La directiva «Seleccionar protocolos de transporte RDP» permite elegir entre un ajuste que usa UDP o TCP y otro que usa solo TCP. Como también existe un comportamiento que usa TCP cuando no se puede establecer una conexión UDP, el hecho de que se haya conectado no le dice nada sobre el transporte. Confírmelo a partir de la información de conexión del cliente, los registros de diagnóstico del producto y los registros de red del administrador.¹²

flowchart TB
    accTitle: Confirmar el transporte antes de comparar ajustes de red
    accDescr: Distinguir una conexión directa corriente de una que pasa por una puerta de enlace o un servicio, confirmar la ruta y el transporte reales, y solo entonces realizar las comparaciones permitidas.
    A["El cliente en uso y la configuración de conexión"] --> B["Confirmar la ruta real y si es TCP o UDP"]
    B --> C["Contrastar con la hora del síntoma"]
    C --> D["Comparar de una en una solo los ajustes necesarios"]

Figura 10: Confirme el transporte y la ruta en uso, contrástelos con el síntoma y solo entonces compare los ajustes necesarios.

RDP Shortpath en Azure Virtual Desktop es el mecanismo que establece una ruta UDP para ese servicio. Incluido el modo en que se usan las rutas directas y los reenvíos, no puede meterse en la misma tabla de ajustes que conectarse directamente a un PC interno con mstsc. Cuando no se puede establecer Shortpath, la conexión recae en una basada en TCP.¹³

No cambie cosas en bloque partiendo de la idea de que desactivar UDP acelera. Iguale el transporte en uso, las directivas y las condiciones de VPN o puerta de enlace, y compare después. Desactivar el firewall o la autenticación, o exponer el puerto RDP directamente a Internet, no son remedios que aplicar.

Si el procesamiento gráfico es sospechoso, compruebe si se usa la GPU para ello

Aunque haya una GPU, de ahí no se sigue que el dibujado de la aplicación del host, la codificación de RDP y la descodificación en su equipo la usen todos. La documentación de Microsoft sobre configuración de GPU también configura y verifica por separado el dibujado en la sesión remota y la codificación por hardware de los fotogramas. Examine las versiones de sistema operativo admitidas, los controladores, las directivas y los requisitos del cliente.¹⁴

Si la sección 6 mostró que el tiempo de compresión es largo, ese es el momento de comprobar el uso de la GPU para codificar. Cambiar los ajustes de codificación de una aplicación que espera en la cola de entrada apunta al lugar equivocado. Un trabajo en el que quiere texto legible y otro en el que quiere vídeo fluido también exigen elecciones distintas entre calidad de imagen, tráfico y carga de procesamiento.¹⁴²

Quienes desarrollan aplicaciones de negocio pueden rastrear las esperas internas de una aplicación registrando por separado la hora de recepción de un evento de entrada, el inicio y el fin del procesamiento de base de datos y archivos, y el momento en que el resultado llegó a la interfaz. También importa un diseño que evite que el trabajo pesado se asiente en el subproceso de interfaz. Tenga en cuenta que un registro de «procesamiento completado» en el host no es un registro de que la presentación se completara en su propia pantalla.⁵

8. Notas que merece la pena dejar al traspasar la investigación

Describa la acción lenta de forma concreta, como «escribir en el Bloc de notas es normal, pero desplazar fotos se atasca». Deje también las condiciones probadas y los resultados.

Hora en que se produjo el síntoma, con zona horaria:
Sistema operativo del host, cliente en uso y versiones:
Conexión directa / VPN / puerta de enlace RD / Azure Virtual Desktop, etc.:
La acción y la aplicación lentas, y cómo responden otras aplicaciones de la misma sesión:
Resolución y número de monitores del lado remoto:
Copias, impresiones y similares en curso al mismo tiempo:
La única condición cambiada, y el resultado tras deshacerla:
Carga y contadores observados en el host y en su equipo:

Cuánto se puede transportar, cuánto se espera una respuesta y cuánto se tarda en producir y mostrar la pantalla. Una vez clara esa distinción, se deja de atribuir «RDP va lento» a una única causa y se puede partir de la acción que va lenta ahora mismo.

Artículos relacionados

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

Enlaces de referencia

Artículos relacionados

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

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

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

Una prueba de velocidad marca cientos de Mbps, así que ¿por qué va lenta la escritura en RDP?

La rapidez con que se mueven grandes cantidades de datos y lo que tarda una acción en volver son dos cosas distintas. 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 su propio equipo intervienen todos. Además, al servidor de la prueba de velocidad y al host RDP se llega por rutas de red distintas.

Escribir va bien, pero solo el desplazamiento se entrecorta. ¿Es un problema de red?

No se puede reducir solo a la red. Cuando aumentan las actualizaciones de pantalla, el dibujado y la compresión en el host, la transferencia, o la descodificación y presentación en su equipo pueden no dar abasto. Cambie la resolución remota y el número de monitores de uno en uno y compare, y después mire los contadores gráficos si hace falta.

Si el ping es rápido, ¿la comunicación de RDP está sana?

Eso por sí solo no lo resuelve. El ping mide la respuesta a ICMP y no mide ni la transferencia gráfica de RDP ni el procesamiento de la aplicación. En configuraciones que pasan por una puerta de enlace RD o similar, la ruta puede no coincidir tampoco. Cuando no hay respuesta, distinga un ICMP bloqueado de que RDP en sí sea inalcanzable.

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

No. Es un contador que mide cuánto espera una entrada en el host, una vez encolada, hasta que el proceso la recoge. No es el retardo percibido, que incluye el viaje de ida y vuelta por la red, el procesamiento de la aplicación tras recoger la entrada y la compresión, descodificación y presentación de la pantalla.

¿Debería desactivar UDP cuando RDP parece lento?

No como recomendación general. Compruebe primero el transporte realmente en uso, la ruta y las directivas aplicadas. Puede que UDP no esté disponible y que la conexión haya recaído en TCP, de modo que pasar a solo TCP no siempre acelera las cosas. Compare en condiciones equivalentes con el permiso de su administrador y deshaga los cambios que resulten 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, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.