Por que a digitação no RDP fica lenta se o teste de velocidade mostra centenas de Mbps?

A velocidade para transportar grandes volumes de dados e o tempo até uma operação receber resposta são coisas diferentes. Entram em jogo o envio da entrada, o processamento do aplicativo no computador remoto, a compressão da tela, a transferência e a exibição no computador local. Além disso, o caminho de comunicação até o servidor do teste de velocidade é diferente do caminho até o destino da conexão RDP.

Consigo digitar normalmente, mas só a rolagem fica travando. O problema é a conexão?

Não dá para restringir a causa apenas à conexão. Quando as atualizações de tela aumentam, pode ser que algum ponto não acompanhe: a renderização e a compressão no computador remoto, a comunicação ou a decodificação e a exibição no computador local. Compare alterando a resolução do lado remoto ou o número de monitores, um de cada vez, e, se necessário, examine os contadores relacionados à renderização.

Se o ping está rápido, a comunicação do RDP está normal?

Só com isso não é possível concluir. O ping mede a resposta ao ICMP; não mede a transferência de tela do RDP nem o processamento dos aplicativos. Em configurações que usam RD Gateway ou similares, o caminho também pode não coincidir. Mesmo quando não há resposta, distinga o bloqueio do ICMP de uma falha de conexão do próprio RDP.

O User Input Delay é o tempo entre pressionar uma tecla e o caractere aparecer?

Não. É um contador que mede o tempo de espera desde que a entrada entra na fila no computador remoto até que o processo a retire. Não é o atraso percebido, que inclui a ida e volta da comunicação, o processamento do aplicativo depois de retirar a entrada e a compressão, a decodificação e a exibição da tela.

Devo desativar o UDP quando o RDP está lento?

Não recomendamos isso como regra geral. Primeiro, verifique o método de conexão e o caminho reais e as políticas aplicadas. Há casos em que o UDP não pode ser usado e a conexão já recorreu ao TCP, e restringir ao TCP nem sempre deixa tudo mais rápido. Com a permissão do administrador, compare com as condições igualadas e desfaça as mudanças desnecessárias.

Por que o RDP fica lento se a conexão é rápida? — Investigando entrada, renderização e comunicação separadamente

11/09/2026 02:00 · Atualizado em: 26/10/2026 · Go Komura · Windows, RDP, Área de Trabalho Remota, Desempenho, Solução de problemas

O teste de velocidade mostra centenas de Mbps, mas, na Área de Trabalho Remota, os caracteres aparecem com um pequeno atraso. Ao rolar uma página cheia de fotos, a tela engasga. Só ao clicar em pesquisar no aplicativo corporativo é que tudo para por alguns segundos. Por onde começar a investigar esse estado de “a conexão é rápida, mas o RDP está lento”?

A resposta às operações no RDP não é determinada apenas pela velocidade de transferência da conexão. Mesmo com um teste de velocidade rápido, pode haver espera em algum ponto: na ida e volta da comunicação, na espera de entrada do aplicativo no computador remoto, na codificação da tela ou na decodificação e exibição no computador local. Primeiro, separe “qual operação está lenta” e compare a mesma operação mudando uma condição de cada vez. Restrinja onde investigar com comparações e medições, e escolha as configurações de UDP e GPU de acordo com esses resultados. Veja: trechos medidos na qualidade da conexão, fatores de desempenho do host de sessão.

No entanto, quando você restringe onde investigar, a causa raiz ainda não está confirmada. Mesmo que a situação melhore ao reduzir a resolução, muda não só a comunicação, mas também o processamento de tela nas duas pontas, por isso não afirmamos que “a causa era a conexão”. Registre os resultados separando os trechos que você mediu dos que não mediu.

Este artigo isola as causas da lentidão na digitação, na rolagem e na resposta dos aplicativos depois de conectado. Mesmo com sintomas parecidos, a causa nem sempre é uma só. Quando “a tela de login demora a aparecer” ou “tudo para só na autenticação”, tratamos como um problema diferente, a ser investigado a partir dos registros de estabelecimento da conexão e de autenticação.

O público principal são usuários e administradores que se conectam ao Windows 11 ou ao Windows Server pela “Conexão de Área de Trabalho Remota” (mstsc) do Windows. Os exemplos de comando são para o Windows PowerShell 5.1. Pressupomos que a mesma operação possa ser reproduzida em uma sessão já conectada.

Em conexões diretas, VPN, RD Gateway e Azure Virtual Desktop, variam o caminho, as informações de diagnóstico disponíveis e onde as configurações se aplicam. O exemplo de verificação da porta TCP 3389 vale apenas para conexões diretas autorizadas a hosts RDP que usam a porta padrão. Não aplicamos diretamente a PCs corporativos comuns os recursos de diagnóstico e as configurações de GPU da documentação voltada ao Azure Virtual Desktop.

Em dispositivos da empresa, a investigação se limita ao que o administrador autorizar. Em hosts compartilhados, identifique a sua sessão e os processos em questão e, se precisar de registros de outros usuários, peça ao administrador. A disponibilidade dos contadores de desempenho, os nomes exibidos e as permissões necessárias são verificados em cada ambiente.

Os métodos de verificação apresentados aqui se baseiam na documentação oficial. Não são um relato de medições em que uma falha foi reproduzida e resolvida em um dispositivo específico. Os exemplos numéricos são apresentados identificados como suposições para fins de explicação.

Para entender o mecanismo, leia em ordem a partir da próxima seção, “Velocidade de transferência e tempo de ida e volta”. Se preferir começar pelo sintoma, vá para “Primeira comparação conforme o sintoma”. Os procedimentos práticos estão em “Comparar uma condição de cada vez” e “Medir onde está a espera”.

No diagrama, uma linha contínua indica uma relação que sempre se aplica e uma linha tracejada indica uma relação condicional (as condições aparecem em cada relação, na página de detalhes). A lista completa das relações (7 no total, com evidências e grau de certeza) e as definições dos principais conceitos estão reunidas na página de detalhes do mapa de conhecimento (em japonês). Dados: JSON-LD / Turtle

Velocidade de transferência e tempo de ida e volta

O RDP (Remote Desktop Protocol) é o protocolo que troca entrada, informações de tela e outros dados entre o dispositivo local e o computador remoto. Além da tela e da entrada, ele também transporta informações de redirecionamento de dispositivos, de impressão e outras. Veja: informações que o RDP transfere.

A velocidade de transferência da conexão indica quantos dados ela consegue transportar por segundo. Os “500 Mbps” de um teste de velocidade são um número sobre essa quantidade. Não é um número que indique o tempo entre fazer uma operação e a resposta chegar. Veja: requisitos de largura de banda do RDP.

flowchart TB
    accTitle: O que o número do teste de velocidade representa
    accDescr: Mostra que os 500 Mbps do teste de velocidade indicam a quantidade de dados transportada por segundo e são um número diferente do tempo entre a operação e a chegada da resposta.
    A["Teste de velocidade: 500 Mbps"] --> B["Dados transportados por segundo"]
    B -.->|"Outro número"| C["Tempo até a resposta chegar"]

Figura 1: O número do teste de velocidade indica a quantidade transportada, não o tempo até a resposta chegar.

O tempo de ida e volta (RTT) é o tempo que uma comunicação leva para chegar ao outro lado e voltar. Aumentar a velocidade de transferência e encurtar o tempo de ida e volta diferem como aumentar o número de faixas de uma estrada difere de encurtar a distância até o destino. Mesmo que aumente a capacidade de transportar grandes volumes de arquivos, se o tempo de ida e volta for o mesmo, a espera pela resposta às operações continua. Veja: RTT e atraso na exibição da tela.

flowchart TB
    accTitle: Velocidade de transferência e tempo de ida e volta comparados a uma estrada
    accDescr: Compara aumentar a velocidade de transferência a aumentar as faixas de uma estrada, e encurtar o tempo de ida e volta a encurtar a distância até o destino.
    A["Aumentar a velocidade"] -->|"Na estrada"| B["Mais faixas"]
    B ~~~ C["Encurtar a ida e volta"]
    C -->|"Na estrada"| D["Encurtar a distância"]

Figura 2: Aumentar as faixas não encurta a distância até o destino.

Até o resultado de um caractere voltar

Considere a digitação de um caractere no Bloco de Notas remoto. O Bloco de Notas roda no computador remoto. Se, para fins de explicação, supusermos 50 milissegundos para a operação chegar e 50 milissegundos para as informações de tela com o resultado voltarem, o tempo gasto em comunicação soma 100 milissegundos, ou seja, 0,1 segundo. O tempo de processamento nas duas pontas foi excluído deste exemplo.

flowchart TB
    accTitle: Exemplo do tempo de comunicação até o resultado de um caractere voltar
    accDescr: Exemplo ilustrativo que supõe 50 milissegundos tanto na ida quanto na volta. Não inclui o processamento nas duas pontas nem representa o número de pacotes por tecla.
    A["Digitar um caractere no local"] -->|"Ida: 50 ms"| B["Remoto recebe a entrada"]
    B --> C["Envia a tela com a entrada"]
    C -->|"Volta: 50 ms"| D["Resultado chega ao local"]

Figura 3: Supondo 50 milissegundos na ida e 50 na volta, só a comunicação leva 0,1 segundo. Não são valores medidos.

Mesmo que a quantidade que a conexão transporta aumente, esse 0,1 segundo continua se o tempo de ida e volta não mudar. A figura 3 é um diagrama conceitual para entender o processamento. Não significa que cada tecla envie um pacote em uma ida e volta independente. O caminho até o servidor do teste de velocidade também é diferente do caminho até o destino RDP, por isso é preciso considerar a VPN, o gateway, o upload do lado remoto e o congestionamento no meio do caminho. Veja: como entender o RTT, desempenho da rede e do host.

Gerar e entregar a tela

Aqui, atraso na resposta às operações significa a espera entre fazer uma operação no computador local e ver o resultado. Além do RTT, também influem o processamento do aplicativo e o processamento que gera e entrega a tela. Também o distinguimos do atraso apenas no trecho de transferência da tela. Veja: trecho medido da captura da tela até a exibição.

Quando a entrada chega do computador local ao remoto, o aplicativo remoto processa a entrada e atualiza a tela, as informações de tela codificadas são transportadas pela conexão e o computador local as decodifica e exibe. Antes e depois da comunicação, há trabalhos a cargo de PCs diferentes. Veja: processamento da captura da tela até a exibição.

flowchart TB
    accTitle: Também há processamento de tela antes e depois da conexão
    accDescr: Fluxo em que a entrada local chega ao computador remoto, o aplicativo remoto a processa, gera e comprime a tela, e as informações de tela transportadas pela conexão são convertidas de volta a um formato exibível e mostradas no local.
    I["Local: entrada da operação"] --> J["Conexão: transporta a entrada"]
    J --> K["Remoto: app processa"]
    K --> A["Remoto: gera e comprime a tela"]
    A --> B["Conexão: transporta a tela"]
    B --> C["Local: volta ao formato exibível"]
    C --> D["Exibe na tela local"]

Figura 4: Processar e comprimir no remoto, transportar pela conexão e converter para exibição no local. Cada trabalho é feito em um lugar diferente.

Neste artigo, codificação é o processamento que converte e comprime a tela no computador remoto para um formato fácil de enviar. Além da transferência pela conexão, ela consome tempo de processamento no computador remoto. Veja: tempo de codificação no computador remoto.

Neste artigo, decodificação é o processamento que converte as informações de tela recebidas de volta a um formato que o computador local consegue exibir. Distinguimos isso da descriptografia, no sentido de desfazer uma criptografia. Veja: tempo de decodificação e exibição no computador local.

Se a compressão no computador remoto demora, o envio espera a preparação mesmo com a conexão livre. Mesmo que as informações cheguem, a atualização atrasa se a decodificação ou a exibição no computador local não acompanharem. Nem sempre vale o raciocínio “o PC da empresa é potente, então qualquer computador local serve”. A folga da conexão e a folga do processamento em suas duas pontas são coisas diferentes. Veja: contadores de desempenho do processamento de tela.

flowchart TB
    accTitle: Atrasos quando as duas pontas não acompanham
    accDescr: Mostra que, se a compressão no remoto demora, o envio espera a preparação mesmo com a conexão livre, e que, se a decodificação ou a exibição no local não acompanham, a atualização atrasa mesmo com as informações já recebidas.
    A["Compressão remota demora"] --> B["Envio espera com a conexão livre"]
    B ~~~ C["Decodificação local não acompanha"]
    C --> D["Atualiza com atraso mesmo recebido"]

Figura 5: Mesmo com folga na conexão, a atualização da tela atrasa se as duas pontas não acompanharem.

Diferença entre digitar e rolar

Ao acrescentar um caractere no Bloco de Notas, muda apenas uma pequena parte da tela. Ao rolar uma página cheia de fotos, uma área grande da exibição muda sem parar. O RDP reduz o volume de comunicação transferindo as partes alteradas e usando compressão e cache adequados ao conteúdo. Ele não envia a tela inteira sem compressão a cada vez. A quantidade de trabalho varia conforme o conteúdo da tela e a frequência das atualizações. Veja: relação entre conteúdo da tela e largura de banda.

flowchart TB
    accTitle: Trabalho de tela ao digitar e ao rolar
    accDescr: Uma pequena mudança de texto e atualizações contínuas de uma área grande diferem na natureza do trabalho de gerar e enviar a tela.
    A{"Mudança na tela"} -->|"Um caractere"| B["Área pequena"]
    A -->|"Rolagem"| D["Área grande contínua"]
    B --> E["Comprime e transfere conforme a mudança"]
    D --> E

Figura 6: Na mesma conexão, a quantidade de trabalho muda entre acrescentar um caractere e uma área grande em movimento contínuo.

Mesmo que um documento parado seja leve, a transferência de tela pode ficar sem folga durante a rolagem. Aumentar a resolução do lado remoto ou o número de monitores também aumenta a tela a ser processada. A comparação reduzindo a resolução é um experimento para ver se o movimento volta ao normal quando o trabalho de gerar e enviar a tela diminui. Não é um cálculo que determina o volume de comunicação apenas pelo número de pixels. Veja: efeitos da resolução, das atualizações de tela e da compressão.

Esperas do aplicativo

Se só a pesquisa do aplicativo corporativo trava por alguns segundos e você consegue digitar normalmente no Bloco de Notas da mesma sessão, verifique o que esse aplicativo está esperando. O aplicativo remoto pode enviar uma consulta a outro banco de dados ou ler arquivos de uma pasta compartilhada e ficar esperando essa resposta. Esse é um caminho diferente da comunicação RDP que liga o computador local ao remoto. Veja: comunicação do computador remoto com o back-end.

flowchart TB
    accTitle: Também há interlocutores além do RDP
    accDescr: Mostra o caso em que, além da comunicação entre o dispositivo local e o computador remoto, o aplicativo remoto espera a resposta de um servidor corporativo.
    A["Dispositivo local"] -->|"RDP"| B["App corporativo remoto"]
    B -->|"Consulta/arquivo"| C["BD/pasta compartilhada"]
    C -->|"Resposta esperada"| B

Figura 7: O aplicativo corporativo do outro lado do RDP pode estar esperando a resposta de mais um servidor.

Quando o processamento responsável pela tela e pela entrada fica ocupado com um trabalho longo, a próxima entrada e a próxima atualização de tela atrasam. No WPF, por exemplo, a capacidade de resposta é prejudicada quando a thread de UI fica ocupada por muito tempo. Apenas o uso total de CPU estar baixo não permite descartar uma espera em uma thread de UI específica. Veja: Dispatcher e thread de UI.

flowchart TB
    accTitle: O processamento da tela e da entrada fica travado
    accDescr: Mostra que, quando o processamento responsável pela tela e pela entrada fica ocupado com um trabalho longo, a próxima entrada e atualização de tela atrasam, e que o uso total de CPU baixo, por si só, não descarta essa espera.
    A["Processamento de tela e entrada"] --> B["Fica com um trabalho longo"]
    B --> C["Próxima entrada ou atualização atrasa"]
    C -.- D["CPU total baixa não descarta"]

Figura 8: O uso total de CPU, por si só, não descarta uma espera na thread de UI.

Primeira comparação conforme o sintoma

A quantidade que se consegue transportar, o tempo de espera pela resposta e o tempo para gerar e exibir a tela são coisas diferentes. Mantendo essa distinção, você não reduz “o RDP está lento” a uma única causa e pode investigar a partir da operação que está lenta agora.

flowchart TB
    accTitle: Separar os três antes de investigar
    accDescr: Mostra que “o RDP está lento” não é atribuído a uma única causa e que, separando a quantidade transportada, o tempo de espera pela resposta e o tempo para gerar e exibir a tela, investiga-se a partir da operação lenta no momento.
    A["“O RDP está lento”"] --> S
    subgraph S["Ver separadamente"]
    direction TB
    B["Quantidade transportada"] ~~~ C["Espera pela resposta"]
    C ~~~ D["Gerar e exibir a tela"]
    end
    S --> E["Investigar a operação lenta agora"]

Figura 9: Separando a quantidade transportada, a espera pela resposta e o tempo para gerar e exibir a tela, você pode investigar a partir da operação lenta agora.

O objetivo de isolar a causa é limitar os lugares onde investigar a lentidão. Mudar todas as configurações de uma vez e deixar tudo mais rápido por acaso não é o objetivo. Usando diferenças como “o Bloco de Notas funciona, mas só a pesquisa trava” ou “a digitação está normal, mas só a rolagem pesa”, você pode escolher por onde começar a investigação antes mesmo de mudar as configurações de comunicação.

A tabela a seguir é um ponto de partida para a investigação. Não é uma tabela para determinar a causa. Compare as operações na mesma sessão e só então mude o dispositivo, o caminho ou as condições de exibição necessários.

Sintoma visível	O que comparar primeiro	Onde olhar depois
Caracteres aparecem com atraso, um a um, em vários aplicativos	Outro dispositivo ou outro caminho autorizado até o mesmo computador remoto	Tempo de ida e volta, espera de entrada, carga geral do computador remoto
A digitação está normal, mas a rolagem trava	Resolução do lado remoto ou número de monitores	Compressão no remoto, transferência de tela, decodificação no local
Só um aplicativo congela	Se o Bloco de Notas e outros aplicativos da mesma sessão respondem	Processamento desse aplicativo, disco, comunicação do computador remoto em diante
Todos ficam lentos só nos horários com mais usuários	Se outras sessões no mesmo horário também ficam lentas	CPU, memória e armazenamento do host compartilhado; conexão compartilhada
Fica lento ao iniciar uma cópia ou impressão	Se volta ao normal ao pausar a sua transferência	Concorrência entre transferências ou redirecionamento de dispositivos e a comunicação de tela

Caracteres atrasados em vários aplicativos

Se os caracteres aparecem com atraso, um a um, em vários aplicativos da mesma sessão, compare a mesma operação também a partir de outro dispositivo ou de outro caminho autorizado. Cruze o tempo de ida e volta, a espera de entrada no computador remoto e a carga geral do computador remoto, e não determine a causa com base em um único número.

Só a rolagem trava

Mesmo com a digitação normal, rolar uma página cheia de fotos gera atualizações contínuas de uma área grande da tela. Altere a resolução do lado remoto ou o número de monitores, um de cada vez, e compare na mesma página. Se houver melhora, os próximos alvos da investigação são a compressão no computador remoto, a transferência de tela e a decodificação no computador local. Só pela resolução não é possível saber qual desses três é a causa. Veja: carga conforme o conteúdo da tela e a resolução.

Só um aplicativo congela

Se só o aplicativo corporativo em que você clicou em pesquisar trava, compare se o Bloco de Notas ou outros aplicativos da mesma sessão respondem. Se os outros aplicativos funcionam, investigue primeiro o processamento do aplicativo em questão, o disco e as requisições ao banco de dados ou à pasta compartilhada. Estar operando via RDP é diferente de a comunicação RDP ser a causa da espera. Veja: fatores de desempenho do aplicativo e do back-end.

Todos lentos só quando há mais usuários

Se vários usuários ficam lentos no mesmo horário, confirme com o administrador a situação das outras sessões. Cruze a carga de CPU, memória e armazenamento do host compartilhado e da conexão compartilhada com o horário do sintoma. Não acesse sem autorização os registros ou processos de outros usuários nem interrompa os trabalhos deles. Veja: recursos do host compartilhado e número de usuários.

Lentidão durante cópias ou impressões

Se o problema coincide com o momento em que você iniciou uma cópia ou impressão, pause apenas as transferências que você tem autorização para interromper e compare. Registre se a situação volta ao normal depois da pausa e se fica lenta de novo ao retomar, e investigue a concorrência com transferências que não são de tela ou com o redirecionamento de dispositivos. Não faça comparações desativando de uma vez os dispositivos necessários para o trabalho. Veja: efeitos do redirecionamento de dispositivos.

Comparar uma condição de cada vez

Não é preciso mudar todas as configurações em sequência. Primeiro, estabeleça uma referência para comparação e escolha apenas as verificações que combinam com o sintoma. Antes de mudar configurações ou reconectar, salve o seu trabalho e anote os valores originais e como restaurá-los. Se não tiver as permissões ou os recursos necessários, não force a ativação; passe o caso ao administrador.

Operar localmente e operar via RDP nem sempre são a mesma condição. Ser rápido na tela física do computador remoto é uma referência útil, mas a sessão e as condições de renderização podem mudar. Iguale o usuário, os dados e o estado do aplicativo, e não restrinja a causa à conexão só porque “na tela física é rápido”.

Comparar a mesma operação

Prepare o mesmo usuário, os mesmos dados e a mesma operação. Em hosts compartilhados, confirme qual é a sua sessão e não interrompa aplicativos ou processos de outros usuários. O uso de outro dispositivo ou de outro caminho também se limita ao que o administrador autorizar.

Reproduza a operação lenta com as configurações originais e anote o horário e o sintoma.

No Bloco de Notas da mesma sessão remota do aplicativo com problema, digite uma quantidade semelhante de texto. Distinga se o problema está em um único aplicativo ou na sessão inteira.
Verifique a carga do computador remoto e do local no mesmo horário.

No Gerenciador de Tarefas, observe a CPU, a memória e o disco do aplicativo em questão no computador remoto e a carga do cliente RDP no computador local. Verifique o processo em questão, não apenas o valor total de CPU. Veja: o que examinar ao investigar a carga.
Mude apenas uma condição entre outro dispositivo, outro caminho autorizado e as condições de exibição, e repita a mesma operação.

Em comparações em que o estado do computador remoto ou do aplicativo também muda ao mesmo tempo, registre essa diferença também. Não trate o resultado de uma mudança em várias condições como o efeito de uma única condição.
Volte às condições originais e verifique de novo a mesma operação.

Se continuar rápido mesmo depois de restaurar, também é possível que tenha sido, por exemplo, uma variação temporária de carga. Não conclua que a mudança funcionou; registre as condições em que o sintoma se reproduz.

Com os resultados do estado original, após a mudança e após a restauração em mãos, você pode comparar qual condição corresponde ao sintoma. Uma condição que trouxe melhora é uma pista para a investigação; sozinha, não prova a causa raiz.

flowchart TB
    accTitle: Limitar as condições alteradas de cada vez
    accDescr: Fluxo em que se define uma operação que reproduz o problema no estado original, se compara mudando só uma condição e também se verifica o resultado após restaurar.
    A["Mesma operação na config. original"] --> B["Mudar só uma condição"]
    B --> C["Repetir a mesma operação"]
    C --> D["Restaurar e verificar de novo"]
    D --> E["Registrar a condição que melhorou"]

Figura 10: Repita a mesma operação no estado original, após a mudança e após restaurar, e registre a condição que mudou.

Comparar a resolução do lado remoto

Faça esta comparação quando as atualizações de tela estiverem pesadas, como na rolagem. Anote a resolução e o número de monitores antes da mudança, salve o seu trabalho e reconecte. Não adotamos no uso diário, sem mais, configurações que prejudiquem as telas necessárias para o trabalho ou a legibilidade do texto.

Mude apenas o número de monitores ou apenas a resolução.

No mstsc, você pode comparar usando as configurações da guia “Exibição” antes de conectar ou especificando a largura e a altura. Veja: especificação de tela no mstsc.
Confirme que o tamanho real da área de trabalho remota mudou e role a mesma página.

Apenas diminuir a janela local pode resultar em uma área de trabalho grande exibida em escala reduzida. Distinga a resolução dinâmica do smart sizing e verifique as condições de suporte do cliente que você usa. Veja: resolução da área de trabalho e escala de exibição.
Volte à configuração original, repita a mesma operação e compare a carga nas duas pontas e o movimento da tela.

Se você mudou ao mesmo tempo para uma resolução baixa e um único monitor, a comparação fica apenas aproximada. Se houver melhora, restaure um de cada vez para separar os efeitos.

Se houver melhora, há uma pista no âmbito do processamento e da transferência de tela. A resolução 3840×2160 tem quatro vezes o número de pixels de 1920×1080, mas o volume de comunicação nem sempre fica quatro vezes maior. Ele varia conforme as partes alteradas e a compressão, e a mudança de resolução também afeta o processamento nas duas pontas. Veja: relação entre número de pixels e volume de comunicação, verificação do processamento de tela.

flowchart TB
    accTitle: O que a comparação com resolução menor revela
    accDescr: Reduzir a resolução do lado remoto pode mudar a carga tanto do processamento de tela quanto da transferência, por isso só a melhora não permite restringir a causa à conexão.
    A["Reduzir a resolução remota"] --> S
    subgraph S["Processamentos que mudam"]
    direction TB
    B["Processamento de tela remoto"] ~~~ C["Volume de dados enviado"]
    C ~~~ D["Processamento de exibição local"]
    end

Figura 11: Mudar a resolução é uma comparação que afeta não só a conexão, mas também o processamento de tela no remoto e no local.

Cruzar cópias e impressões com o sintoma

Os únicos processos a pausar são os que você tem autorização para interromper, como transferências que você mesmo iniciou. Não interrompa backups ou processos de segurança da empresa nem trabalhos de outros usuários. Não desative de uma vez o redirecionamento de dispositivos de áudio e de entrada necessários para o trabalho.

Antes e durante uma cópia, uma sincronização com a nuvem ou uma impressão, registre a mesma operação e a carga.

Além da tela, o RDP também transporta informações de unidades de disco, impressoras e outros. O redirecionamento, que permite usar dispositivos locais no computador remoto, pode aumentar a carga de comunicação e de processamento enquanto está em uso. Veja: efeitos do redirecionamento de dispositivos.
Pause a transferência em questão dentro do que for autorizado e verifique de novo a mesma operação.

Se puder retomar e comparar, registre também o sintoma depois de retomar. Ao testar redirecionamentos de dispositivos desnecessários, mude também um de cada vez, de forma que seja possível voltar à configuração original.

Você pode avaliar se o início da transferência corresponde ao problema e se a pausa corresponde à recuperação. Se a correspondência aparecer, cruze as transferências que não são de tela e a carga dos recursos compartilhados com os registros do administrador.

flowchart TB
    accTitle: Ver antes e depois do problema na mesma linha do tempo
    accDescr: Registra-se a mesma operação e a carga antes da transferência, durante e depois da pausa, e compara-se a relação entre o problema e a tarefa.
    A["Operação e carga antes"] --> B["Operação e carga durante"]
    B --> C["Operação e carga após a pausa"]
    C --> D["Problema e recuperação batem?"]

Figura 12: Veja como a lentidão da mesma operação e a carga mudam antes da transferência, durante e depois da pausa.

Medir onde está a espera

A partir do computador local, investigue a ida e volta da comunicação e a conexão TCP; no computador remoto, a espera na fila de entrada e as atualizações de tela. Como cada número mede apenas um trecho limitado, leia os resultados à luz da tabela em “Alcance dos resultados das medições”.

Verificar o ICMP e a conexão TCP

O local de execução é o dispositivo Windows local. Só são abrangidas as configurações em que você se conecta diretamente, pela LAN corporativa ou por uma VPN autorizada, a um host RDP que usa a porta padrão TCP 3389. Em configurações via RD Gateway ou Azure Virtual Desktop, ou com porta personalizada, defina com o administrador o que verificar. Não expomos portas nem alteramos firewalls.

Informe o destino autorizado e registre os resultados da resposta ICMP e da conexão TCP.

$target = Read-Host 'Nome ou endereço IP do host RDP que você tem autorização para investigar'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Informe o destino da conexão.'
}
    
# Observar o tempo de resposta ICMP várias vezes. Uma falha, por si só, não indica que o RDP está inacessível.
ping.exe -n 20 $target
    
# Verificação restrita a configurações com conexão direta à porta padrão TCP 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
    

Cruze os resultados do horário lento e do horário normal com o horário do sintoma e o caminho real da conexão.

As 20 execuções de ping são uma observação curta. Registre a variação dos valores e a ausência de resposta, mas o ICMP pode estar bloqueado. Não descarte interrupções intermitentes só pela média; use as informações da conexão e os registros de comunicação do administrador. Veja: o que o ping mede.

TcpTestSucceeded: True significa que a conexão TCP com a porta especificada foi bem-sucedida. Não mede a largura de banda, o UDP, as operações após a autenticação nem a fluidez da tela. O Test-NetConnection não tem uma opção -UDP para verificar o UDP. Veja: sintaxe e resultados do Test-NetConnection.

Avalie sem perder de vista as diferenças de caminho e de serviço. Com RD Gateway e similares, o caminho do ICMP ou da conexão TCP direta até o host pode não coincidir com o caminho real do RDP. No Azure Virtual Desktop, é possível usar o RTT e a estimativa de largura de banda de cada conexão, mas esse recurso de diagnóstico é específico desse serviço. Não descarte interrupções curtas só pela média. Veja: logs de qualidade da conexão do Azure Virtual Desktop.

flowchart TB
    accTitle: Caminho verificado e caminho real do RDP
    accDescr: Em configurações com RD Gateway e similares, o caminho do ICMP ou da conexão TCP direta do computador local até o host pode não coincidir com o caminho real do RDP.
    A["Dispositivo local"] -->|"ICMP/TCP direto"| C["Host RDP"]
    A -->|"RDP real"| B["RD Gateway etc."]
    B --> C

Figura 13: O caminho do ICMP ou da conexão TCP direta até o host pode não coincidir com o do RDP real.

Medir a espera na fila de entrada

O User Input Delay mede a espera desde que a entrada entra na fila no computador remoto até que o processo a retire. Não é o tempo total entre pressionar uma tecla e ver o caractere. Veja: definição do User Input Delay.

A investigação é feita dentro da sessão remota, no computador remoto. As condições de suporte da Microsoft são Windows 10 versão 1809 ou posterior e Windows Server 2019 ou posterior. Nesses sistemas, não é necessário adicionar entradas no Registro para a ativação. Verifique os nomes exibidos, as permissões e se os contadores existem; se não estiverem disponíveis, registre esse fato e consulte o administrador. Veja: condições de suporte e configuração.

No PowerShell da mesma sessão, anote o horário e o ID da sessão.
```
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session
    
```
Consultar sessões de outros usuários pode exigir permissões adicionais. O nome de instância padrão do processo em questão é SessionID:ProcessID <Process Image>. Não misture, guiando-se só pelo ID da sessão, valores de outros usuários ou de processos com o mesmo nome. Veja: permissões do query session, identificação da instância.
No perfmon.exe, adicione o User Input Delay per Process ou o User Input Delay per Session que estiver disponível.

Selecione o processo ou a sessão em questão e, de início, observe com o intervalo padrão de 1 segundo. Distinga a instância agregada, que reúne várias sessões, dos valores de cada sessão.
Reproduza a operação em que a entrada fica lenta e compare a espera na fila com o horário do sintoma.

Para cada alvo de medição individual, o valor observado é a maior espera dentro do intervalo de medição. Mesmo que o valor seja baixo, ainda restam o processamento depois que o aplicativo retira a entrada e o atraso até o resultado voltar ao computador local.

Você pode verificar se há espera na fila de entrada do computador remoto. É um indicador diferente do tempo percebido, que inclui a ida e volta da comunicação e a exibição no computador local. Veja: significado do valor máximo e do intervalo de medição.

flowchart TB
    accTitle: O trecho medido pelo User Input Delay
    accDescr: O trecho medido vai da fila de entrada do computador remoto até o aplicativo retirar a entrada, e não inclui a comunicação nem a exibição da tela antes e depois.
    A["Entrada chega do local"] --> B["Entra na fila de entrada remota"]
    B -->|"Mede-se aqui"| C["App retira a entrada"]
    C --> D["Processamento e transferência"]
    D --> E["Exibido no local"]

Figura 14: O que se mede é a espera na fila de entrada do computador remoto. É diferente do tempo total até ver o resultado no computador local.

Investigar as atualizações de tela e os motivos de descarte

Prepare uma operação com atualizações de tela contínuas, como a rolagem. A disponibilidade dos contadores RemoteFX Graphics e o local de medição precisam ser verificados conforme o sistema operacional, a configuração do host e as permissões. Aqui apenas lemos os contadores disponíveis. Não é um procedimento para instalar ou ativar o antigo recurso RemoteFX. Veja: condições de aplicação dos contadores Graphics.

Confirme o nome da sessão em questão com query session ou qwinsta e selecione a instância de contador correspondente.
Durante uma operação com atualizações de tela, compare Input Frames/Second e Output Frames/Second.

Se a saída for menor que a entrada, quadros da tela estão sendo descartados no meio do caminho. Verifique os valores de Frames Skipped/Second por falta de recursos no computador remoto, na rede e no cliente.
Cruze os motivos de descarte com a carga nas duas pontas e na comunicação, e verifique também o Average Encoding Time.

Se o tempo de codificação for longo, investigue o processamento de compressão no computador remoto. Se o número de quadros já for baixo do lado da entrada, também é possível que o aplicativo não esteja atualizando a tela com frequência. Um número baixo de quadros com a tela parada não é, por si só, uma anomalia.

Com a entrada e a saída durante as atualizações de tela, os motivos de descarte e o tempo de codificação, você pode restringir onde investigar. A classificação dos contadores é uma pista; avalie-a junto com a carga real e a configuração da conexão. Veja: como ler o número de quadros e o tempo de codificação.

flowchart TB
    accTitle: Restringir onde investigar a partir do descarte de quadros
    accDescr: Durante uma operação com atualizações de tela, compara-se o número de quadros de entrada e de saída e, usando os contadores de motivos de descarte como pista, cruza-se com a carga de processamento, comunicação e exibição.
    A["Comparar entrada/saída na rolagem"] --> B["Saída menor: verificar descarte"]
    B --> C["Ver contadores por motivo"]
    C --> D["Cruzar com carga remota/rede/local"]

Figura 15: Compare a entrada e a saída durante a rolagem e cruze os motivos de descarte com a carga no computador remoto, na conexão e no computador local.

Não generalizamos para todas as configurações o diagrama conceitual de transferência de tela nem documentos antigos. Há configurações que transferem vídeo e áudio por mecanismos separados. Como a documentação dos contadores Graphics também descreve configurações antigas, não reinterpretamos os números citados como uma especificação comum do tipo “todo RDP tem no máximo 30 fps”. Verifique a que se aplicam os recursos e os números antes de usá-los. Veja: transferência de tela e cargas de trabalho, documentação dos contadores Graphics.

Alcance dos resultados das medições

Não confundimos um número baixo com uma operação confortável. O alcance de cada indicador pode ser verificado na documentação da Microsoft indicada nos procedimentos.

Resultado observado	O que se sabe	O que ainda não se sabe
Tempo de resposta do ping baixo	Tempo de resposta ICMP até aquele destino	Se o caminho RDP real inteiro, o processamento do aplicativo e a exibição da tela estão normais
TcpTestSucceeded é True	Conexão TCP bem-sucedida ao destino e à porta especificados	UDP, largura de banda, resposta após a autenticação
User Input Delay alto	Espera na fila de entrada do computador remoto em questão	O processamento depois de retirar a entrada e o atraso total até o computador local
Poucos quadros de saída durante as atualizações	Uma pista para investigar o descarte de quadros e seus motivos	Uma causa raiz única; é preciso cruzar com os registros das duas pontas e da comunicação
Melhora ao reduzir a resolução	Possível correspondência entre as condições de exibição e o sintoma	Se a causa é a conexão, a codificação ou a decodificação

Configurações de comunicação e GPU

As configurações de UDP e GPU são escolhidas de acordo com o que as comparações e medições revelaram. Se a comunicação for suspeita, verifique primeiro o método de conexão e o caminho; se o processamento de tela for suspeito, verifique primeiro em que etapas a GPU é usada.

Verificar TCP/UDP e o caminho da conexão

Quando as comparações e medições apontarem a comunicação como suspeita, verifique com o administrador o cliente em uso, o caminho e as políticas aplicadas. Mesmo que seja necessário mudar configurações, limite-se ao que foi aprovado e registre os valores anteriores e o método de recuperação. Não desativamos firewalls nem autenticação, nem expomos a porta RDP diretamente à internet.

Confirme o TCP/UDP e o caminho reais pelas informações da conexão, pelos logs de diagnóstico do produto e pelos registros de comunicação do administrador.

O RDP usa TCP ou UDP conforme a configuração e as condições de comunicação. Em “Select RDP transport protocols”, é possível escolher entre a configuração que usa UDP ou TCP e a que usa apenas TCP. Como também existe o comportamento de usar TCP quando a conexão UDP não se estabelece, só o sucesso da conexão não revela o método. Veja: seleção e fallback do RDP transport.
Cruze o caminho e o método com o horário do sintoma e compare apenas as configurações necessárias, uma de cada vez.

Não mudamos tudo de forma generalizada com a ideia de que “desligar o UDP deixa mais rápido”. Compare igualando as condições de VPN e gateway, a operação e as condições de exibição, e desfaça as mudanças desnecessárias.

Conhecendo o método e o caminho, você pode registrar a relação entre a mudança e o sintoma. Restringir ao TCP nem sempre deixa tudo mais rápido.

flowchart TB
    accTitle: Verificar o método de conexão antes de comparar configurações de comunicação
    accDescr: Distingue-se a conexão direta comum da conexão via gateway ou serviço, verifica-se o caminho e o método reais e só então se fazem as comparações autorizadas.
    A["Cliente e configuração da conexão"] --> B["Verificar caminho real e TCP/UDP"]
    B --> C["Cruzar com o horário do sintoma"]
    C --> D["Comparar só o necessário, um a um"]

Figura 16: Confirme o método e o caminho de conexão em uso, cruze com o sintoma e só então compare apenas as configurações necessárias.

O RDP Shortpath é um mecanismo do Azure Virtual Desktop. Ele estabelece um caminho UDP desse serviço e, conforme a configuração, usa um caminho direto ou uma retransmissão. Se não conseguir estabelecê-lo, volta para uma conexão baseada em TCP. Não é possível usar a mesma tabela de configurações do caso em que você se conecta diretamente a um PC corporativo com o mstsc. Veja: caminhos e fallback do RDP Shortpath.

flowchart TB
    accTitle: Caminhos e fallback do RDP Shortpath
    accDescr: O RDP Shortpath do Azure Virtual Desktop tenta estabelecer um caminho UDP; se conseguir, usa um caminho direto ou uma retransmissão conforme a configuração; se não conseguir, volta para uma conexão baseada em TCP.
    A["RDP Shortpath"] --> B{"Caminho UDP"}
    B -->|"Estabelecido"| C["Direto ou retransmissão"]
    B -->|"Falhou"| D["Volta para base TCP"]

Figura 17: Se não conseguir estabelecer o caminho UDP, o RDP Shortpath volta para uma conexão baseada em TCP.

Verificar o uso da GPU no processamento de tela

Faça esta verificação quando as comparações e medições apontarem o processamento de tela como suspeito. Verifique os resultados das medições do processamento de tela e os sistemas operacionais, drivers, políticas e clientes compatíveis. Não mudamos configurações só porque há uma GPU instalada. Obtenha antes a aprovação do administrador e prepare-se para voltar ao estado original.

Separe a renderização do aplicativo remoto, a codificação do RDP e a decodificação no local, e escolha a etapa suspeita.

Mesmo que haja uma GPU, nem todas as etapas necessariamente a usam. Também na documentação de configuração da Microsoft para o Azure Virtual Desktop, a renderização da sessão remota e a codificação de quadros por hardware são configuradas e verificadas separadamente. Veja: configuração e validação da GPU para renderização e codificação.
Verifique o uso real seguindo os procedimentos do produto em questão e meça a mesma operação antes e depois das mudanças necessárias.

Se o tempo de compressão for longo, investigue o uso da GPU na codificação. Mudar as configurações de codificação para um aplicativo que espera na fila de entrada mira o lugar errado. A escolha entre qualidade de imagem, volume de comunicação e carga de processamento também difere entre a legibilidade do texto e a fluidez do vídeo. Veja: diferenças conforme a carga de trabalho.

Indo além de saber se há ou não uma GPU, você pode registrar se a GPU é usada na etapa problemática e como a carga e a resposta da mesma operação mudaram. Mudanças que não trouxeram melhora são desfeitas após confirmação com o administrador.

flowchart TB
    accTitle: Verificar o uso da GPU etapa por etapa
    accDescr: Separa-se a renderização do aplicativo remoto, a codificação do RDP e a decodificação no local e, como mesmo com GPU nem todas as etapas a usam, verifica-se o uso na etapa suspeita.
    A["Renderização do app remoto"] --> B["Codificação do RDP"]
    B --> C["Decodificação no local"]
    C -.- D["Verificar GPU por etapa"]

Figura 18: Mesmo havendo GPU, nem todas as etapas, entre renderização, codificação e decodificação, necessariamente a usam.

Nova verificação e repasse

A melhora é confirmada quando, após a mudança, a mesma operação pode ser feita sem problemas e, além disso, a qualidade de imagem, os dispositivos e as funções de trabalho necessários são preservados. Cruze também com o resultado de voltar às condições originais. Se houver apenas uma recuperação momentânea, não dê a causa como confirmada; registre incluindo os horários de congestionamento e os processamentos simultâneos.

flowchart TB
    accTitle: Ordem para confirmar uma melhora
    accDescr: Mostra que se verifica se, após a mudança, a mesma operação pode ser feita sem problemas e se a qualidade de imagem, os dispositivos e as funções de trabalho necessários são preservados, que se cruza com o resultado de voltar às condições originais e que uma recuperação momentânea não confirma a causa.
    A["Testar a mesma operação após mudar"] --> B["Ver imagem, dispositivos e funções"]
    B --> C["Cruzar com o resultado restaurado"]
    C -.- D["Recuperação momentânea não confirma"]

Figura 19: Além do resultado da mesma operação, cruze também as funções necessárias e o resultado após restaurar.

Repasse quando não houver solução

Não melhorar, não reproduzir ou não ter os contadores disponíveis também são resultados úteis. Separe as comparações que conseguiu fazer das verificações que não conseguiu e passe o caso a administradores e desenvolvedores com a anotação a seguir. Remova dos logs compartilhados as informações de negócio desnecessárias para a investigação, como nomes de usuário e destinos de conexão.

Horário do sintoma e fuso horário:
SO remoto, cliente usado e versão:
Direta/VPN/RD Gateway/Azure Virtual Desktop etc.:
Operação e app lentos; resposta de outro app na mesma sessão:
Resolução do lado remoto e número de monitores:
Cópias, impressões etc. em andamento ao mesmo tempo:
Única condição alterada e resultado após restaurar:
Carga e contadores observados no remoto e no local:

Acrescente também se foi possível confirmar o TCP/UDP real, os itens que não puderam ser verificados por falta de permissões ou outros motivos e as configurações aceitáveis para o trabalho. Em vez de dizer “a conexão está lenta”, dizer “consigo digitar normalmente no Bloco de Notas, mas trava quando rolo fotos” permite que a próxima pessoa responsável investigue nas mesmas condições.

Os usuários registram a operação que reproduz o problema e os resultados das comparações; os administradores cruzam os registros do caminho de conexão, do host compartilhado e das sessões. O simples fato de a espera ocorrer sobre o RDP não significa que o processamento que causa a espera seja o RDP. Veja: divisão de papéis entre o host e o back-end.

Os desenvolvedores do aplicativo registram separadamente a recepção dos eventos de entrada, o início e o fim do processamento de banco de dados e de arquivos e o reflexo na UI. Também consideram um projeto que não deixe trabalhos pesados ocupando a thread de UI. No entanto, um log de conclusão do processamento no computador remoto não registra a conclusão da exibição no computador local. Veja: separar o processamento para manter a UI responsiva.

Referências

Estas são fontes primárias do Microsoft Learn. O conteúdo referenciado foi verificado em 17 de setembro de 2026. Ao lê-las, distinga as condições de aplicação de cada produto e tenha em mente que não se trata de medições realizadas neste artigo.

Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. A distinção entre o RTT e o atraso desde a captura da tela no computador remoto até a exibição no computador local. O recurso de diagnóstico em si é voltado ao Azure Virtual Desktop.
Microsoft Learn, Remote Desktop Protocol bandwidth requirements. A relação entre o conteúdo da tela, a resolução, a atualização de quadros, a compressão, o cache e o volume de comunicação.
Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Como verificar a entrada e a saída de quadros, os motivos de descarte e o tempo de codificação. Como inclui descrições de configurações antigas, não generalizamos os limites numéricos para todo RDP.
Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. A carga do host compartilhado, a comunicação do computador remoto com o back-end e os efeitos do redirecionamento de dispositivos.
Microsoft Learn, Threading model. A thread de UI e o Dispatcher do WPF e a separação do processamento para manter a capacidade de resposta.
Microsoft Learn, mstsc. Como especificar a largura e a altura da Área de Trabalho Remota e o uso de vários monitores.
Microsoft Learn, Supported RDP properties. A distinção entre a resolução da área de trabalho, a resolução dinâmica e o smart sizing. Verifique os clientes compatíveis e as condições de aplicação de cada produto.
Microsoft Learn, ping. Verificação da resposta por ICMP Echo e opções.
Microsoft Learn, Test-NetConnection. Verificação da conexão TCP e significado da saída.
Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. O trecho medido pelo User Input Delay, os sistemas operacionais abrangidos, as instâncias e o significado do valor máximo.
Microsoft Learn, query session. Informações de sessão e as permissões necessárias para consultar outras sessões.
Microsoft Learn, ADMX_TerminalServer Policy CSP. A seleção do TCP/UDP usado pelo RDP e o fallback.
Microsoft Learn, RDP Shortpath. O caminho UDP para o Azure Virtual Desktop e o comportamento quando não é possível estabelecê-lo.
Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Configuração e validação da GPU separando a renderização e a codificação de quadros.

Artigos recentes que compartilham as mesmas tags. Aprofunde seu conhecimento com temas próximos.

Por que o som corta mesmo com uso de CPU baixo? — Pensando em buffers e prazos

Explicamos por que o som corta mesmo com uso de CPU baixo, a partir do buffer e do prazo de reabastecimento. Reunimos o ambiente-alvo, um...

Ler artigo

Anúncio de abertura do blog técnico - Começamos um blog sobre desenvolvimento Windows / C# / COM

Anúncio da abertura do blog técnico da KomuraSoft LLC. Vamos compartilhar conhecimento sobre desenvolvimento Windows, C# / .NET, COM, pro...

Ler artigo

Tópicos relacionados

Páginas de tópicos próximos a este tema. A partir do artigo, você pode seguir para serviços relacionados e outros artigos.

Tópicos técnicos de Windows

Página de entrada que reúne os tópicos técnicos sobre desenvolvimento para Windows, investigação de falhas e reaproveitamento de ativos existentes.

Ver tópico

Serviços ligados a este tema

Este artigo se conecta às páginas de serviço abaixo. Escolha a porta de entrada mais próxima.

Desenvolvimento de aplicativos Windows

Apoiamos o desenvolvimento de software Windows, como aplicativos corporativos, integração com equipamentos e ferramentas de comunicação.

Ver serviço Contato

Perguntas frequentes

Reunimos as perguntas mais comuns, em consultas, sobre o tema deste artigo.

Por que a digitação no RDP fica lenta se o teste de velocidade mostra centenas de Mbps?: A velocidade para transportar grandes volumes de dados e o tempo até uma operação receber resposta são coisas diferentes. Entram em jogo o envio da entrada, o processamento do aplicativo no computador remoto, a compressão da tela, a transferência e a exibição no computador local. Além disso, o caminho de comunicação até o servidor do teste de velocidade é diferente do caminho até o destino da conexão RDP.
Consigo digitar normalmente, mas só a rolagem fica travando. O problema é a conexão?: Não dá para restringir a causa apenas à conexão. Quando as atualizações de tela aumentam, pode ser que algum ponto não acompanhe: a renderização e a compressão no computador remoto, a comunicação ou a decodificação e a exibição no computador local. Compare alterando a resolução do lado remoto ou o número de monitores, um de cada vez, e, se necessário, examine os contadores relacionados à renderização.
Se o ping está rápido, a comunicação do RDP está normal?: Só com isso não é possível concluir. O ping mede a resposta ao ICMP; não mede a transferência de tela do RDP nem o processamento dos aplicativos. Em configurações que usam RD Gateway ou similares, o caminho também pode não coincidir. Mesmo quando não há resposta, distinga o bloqueio do ICMP de uma falha de conexão do próprio RDP.
O User Input Delay é o tempo entre pressionar uma tecla e o caractere aparecer?: Não. É um contador que mede o tempo de espera desde que a entrada entra na fila no computador remoto até que o processo a retire. Não é o atraso percebido, que inclui a ida e volta da comunicação, o processamento do aplicativo depois de retirar a entrada e a compressão, a decodificação e a exibição da tela.
Devo desativar o UDP quando o RDP está lento?: Não recomendamos isso como regra geral. Primeiro, verifique o método de conexão e o caminho reais e as políticas aplicadas. Há casos em que o UDP não pode ser usado e a conexão já recorreu ao TCP, e restringir ao TCP nem sempre deixa tudo mais rápido. Com a permissão do administrador, compare com as condições igualadas e desfaça as mudanças desnecessárias.

Perfil do autor

Página de perfil do autor do artigo.

Go Komura

Representante da KomuraSoft LLC

Atua principalmente com desenvolvimento de software para Windows, consultoria técnica e investigação de falhas, com especial força em projetos em que ativos existentes permanecem e em investigações de falhas cuja causa é difícil de enxergar.

Ver perfil Contato

Links públicos

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Voltar à lista do blog