测速能跑到几百 Mbps，为什么 RDP 的输入还是很慢？

搬运大量数据的速度，与操作后得到响应所需的时间是两回事。输入的发送、远程端应用的处理、画面的压缩、传输以及本地的显示都与之相关。此外，测速的对端与 RDP 的远程端之间，通信路径也不相同。

打字很正常，只有滚动时卡顿，这是网络的问题吗？

不能只归结到网络。画面更新增多时，远程端的绘制和压缩、通信、本地的解码和显示中，任何一个环节都可能跟不上。逐一改变远程端的分辨率或显示器数量进行比较，必要时再调查与绘制相关的计数器。

ping 很快，就说明 RDP 的通信正常吗？

仅凭这一点无法判断。ping 测量的是对 ICMP 的响应，并不测量 RDP 的画面传输或应用的处理。在使用 RD Gateway 等的配置中，路径也可能不一致。没有响应时，也请区分是 ICMP 被阻止，还是 RDP 本身不通。

User Input Delay 是从按键到字符出现的时间吗？

不是。它是测量在远程端输入进入队列后、到进程将其取出为止的等待时间的计数器。它并不是包含通信往返、取出后的应用处理，以及画面的压缩、解码和显示在内的体感延迟。

RDP 很卡时，应该禁用 UDP 吗？

不建议一概这样做。首先确认实际的连接方式、路径和所应用的策略。有时是因为 UDP 无法使用而回退到了 TCP，改为仅用 TCP 并不一定总会变快。在管理员的许可下统一条件进行比较，并撤销不必要的更改。

网络很快，RDP 为什么还是很卡？ ── 把输入、绘制与通信分开排查

2026年09月11日 02:00 · 更新日期: 2026年10月26日 · Go Komura · Windows, RDP, 远程桌面, 性能, 故障排查

测速能跑到几百 Mbps，可在远程桌面里，字符却要稍晚一点才出现。滚动图片很多的网页时，画面会卡一下。只有在业务应用里点击搜索时，才会停顿几秒。遇到这种“网络很快，RDP 却很卡”的情况，应该从哪里开始调查呢？

RDP 的操作响应并不只由网络的传输速率决定。即使测速很快，也可能在通信往返、远程端应用的输入等待、画面的编码、本地的解码和显示中的某个环节发生等待。请先区分“哪种操作慢”，再每次只改变一个条件，比较同一操作。通过比较和测量缩小调查范围，UDP 和 GPU 的设置则根据其结果来选择。参见：连接质量的测量区间、会话主机的性能因素。

不过，在缩小调查范围的阶段，根本原因尚未确定。即使降低分辨率后有所改善，由于变化的不只是通信，两端的画面处理也随之改变，因此不断定“原因在网络”。要把测量过的区间和没有测量的区间分开，记录结果。

本文排查的是连接建立之后的输入、滚动和应用响应。即使症状相似，原因也不一定只有一个。“登录画面要很久才出现”“只在身份验证时卡住”这类情况，属于需要从连接建立和身份验证的记录开始调查的另一类问题。

主要对象是从 Windows 的“远程桌面连接”（mstsc）连接到 Windows 11 或 Windows Server 的用户和管理员。命令示例面向 Windows PowerShell 5.1。前提是能在已连接的会话中复现同一操作。

直接连接、VPN、RD Gateway 和 Azure Virtual Desktop 之间，路径、可用的诊断信息以及设置的应用对象各不相同。TCP 3389 的检查示例仅限于经许可、直接连接到使用标准端口的 RDP 主机的情况。不要把面向 Azure Virtual Desktop 的资料中的诊断功能或 GPU 设置，原样套用到一般的公司内部 PC 上。

在公司的设备上，只在管理员许可的范围内进行调查。在共享主机上，要识别自己的会话和目标进程；如果需要其他用户的记录，请委托管理员。性能计数器是否可用、显示名称以及所需权限，需要针对各自的环境确认。

这里介绍的检查方法以官方资料为依据，并不是在特定设备上复现并解决了故障的实测报告。数值示例会与用于说明的假设区分开来展示。

想了解原理，可以从下一节“传输速率与往返时间”开始按顺序阅读。如果想从症状入手调查，请直接跳到“按症状选择最初的比较”。操作步骤见“逐一比较条件”和“测量等待发生的位置”。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 7 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

传输速率与往返时间

RDP（Remote Desktop Protocol）是在本地设备与远程端之间交换输入和画面信息等的协议。它处理的不只是画面和输入，还包括设备重定向和打印等信息。参见：RDP 传输的信息。

网络的传输速率表示 1 秒内能搬运多少数据。测速结果中的“500Mbps”就是关于这个量的数字，而不是表示从操作到收到回应所需时间的数字。参见：RDP 的带宽要求。

flowchart TB
    accTitle: 测速数字代表什么
    accDescr: 测速得到的 500Mbps 表示 1 秒内能搬运的数据量，与从操作到收到回应所需的时间是不同的数字。
    A["测速：500Mbps"] --> B["1 秒内能搬运的数据量"]
    B -.->|"另一个数字"| C["收到回应所需的时间"]

图1：测速的数字表示能搬运的量，不表示收到回应所需的时间。

往返时间（RTT）是指通信到达对方再返回所需的时间。提高传输速率与缩短往返时间之间的区别，就像增加道路的车道数与缩短到目的地的距离之间的区别。即使搬运大量文件的能力提高了，只要往返时间不变，等待操作回应的时间依然存在。参见：RTT 与画面显示的延迟。

flowchart TB
    accTitle: 用道路比喻传输速率与往返时间
    accDescr: 把提高传输速率比作增加道路的车道数，把缩短往返时间比作缩短到目的地的距离。
    A["提高传输速率"] -->|"换成道路"| B["增加车道"]
    B ~~~ C["缩短往返时间"]
    C -->|"换成道路"| D["缩短距离"]

图2：即使增加车道，到目的地的距离也不会变短。

从输入一个字符到结果返回

设想在远程的记事本中输入一个字符的场景。记事本运行在远程端。为便于说明，假设操作到达需要 50 毫秒，结果的画面信息返回需要 50 毫秒，那么用于通信的时间合计为 100 毫秒，也就是 0.1 秒。两端的处理时间不包含在这个例子中。

flowchart TB
    accTitle: 一个字符的结果返回前的通信时间示例
    accDescr: 为便于说明，假设去程和回程各 50 毫秒。不包含两端的处理时间，也不代表每次按键的数据包数量。
    A["在本地输入一个字符"] -->|"去程：50 毫秒"| B["远程端接收输入"]
    B --> C["发送反映了输入的画面"]
    C -->|"回程：50 毫秒"| D["结果到达本地"]

图3：假如去程 50 毫秒、回程 50 毫秒，仅通信就需要 0.1 秒。这不是实测值。

即使网络能搬运的量增加了，只要往返时间不变，这 0.1 秒就依然存在。图3是用于理解处理过程的概念图，并不表示每次按键都会发送一个独立往返的数据包。测速的对端与 RDP 的远程端之间路径也不相同，需要把 VPN、网关、远程端一侧的上行以及途中的拥塞都考虑在内。参见：RTT 的概念、网络与主机的性能。

生成并传送画面的处理

这里所说的操作响应延迟，是指从在本地操作到看见结果之间的等待。与之相关的不只有 RTT，还有应用的处理以及生成并传送画面的处理。它也要与仅限于画面传输区间的延迟区分开来。参见：从画面捕获到显示的测量区间。

输入从本地到达远程端后，远程端应用处理输入并更新画面，经过编码的画面信息通过网络传送，再在本地解码并显示。在通信的前后，也有分别由不同 PC 承担的工作。参见：从画面捕获到显示的处理。

flowchart TB
    accTitle: 网络的前后也有画面的处理
    accDescr: 本地的输入到达远程端，远程端应用处理后生成并压缩画面，通过网络传送的画面信息在本地还原成可显示的形式并显示出来的流程。
    I["本地：输入操作"] --> J["网络：传送输入"]
    J --> K["远程端：应用处理"]
    K --> A["远程端：生成并压缩画面"]
    A --> B["网络：传送画面信息"]
    B --> C["本地：还原成可显示的形式"]
    C --> D["显示在本地屏幕上"]

图4：在远程端处理和压缩，通过网络传送，在本地还原以供显示。这些是分别在不同地方进行的工作。

本文所说的编码，是指在远程端把画面转换、压缩成便于发送的形式的处理。它与通过网络进行的传输是两回事，会在远程端花费处理时间。参见：远程端的编码时间。

本文所说的解码，是指在本地把收到的画面信息还原成可显示形式的处理。它与表示解除加密的“解密”是不同的概念。参见：本地的解码与显示时间。

如果远程端的压缩很耗时，即使网络空闲，也要等待发送准备就绪。即使信息已经到达，如果本地的解码或显示跟不上，更新也会延迟。“公司的 PC 性能很高，所以本地用什么都行”并不一定成立。网络的余量和两端处理的余量是两回事。参见：画面处理的性能计数器。

flowchart TB
    accTitle: 两端的处理跟不上时的延迟
    accDescr: 如果远程端的压缩耗时，即使网络空闲也要等待发送准备；如果本地的解码或显示跟不上，即使信息已经到达，更新也会延迟。
    A["远程端的压缩耗时"] --> B["网络空闲也要等待发送"]
    B ~~~ C["本地的解码跟不上"]
    C --> D["已到达但更新延迟"]

图5：即使网络有余量，如果两端的处理跟不上，画面的更新也会延迟。

文字输入与滚动的区别

在记事本里添加一个字符时，变化的只是画面的一小部分。滚动图片很多的网页时，大范围的显示内容会接连变化。RDP 会通过只传输变化的部分，以及采用与内容相适应的压缩和缓存来抑制流量，并不是每次都把整个画面不经压缩地发送出去。工作量会随画面的内容和更新频率而变化。参见：画面内容与带宽的关系。

flowchart TB
    accTitle: 文字输入与滚动带来的画面工作量差异
    accDescr: 小范围的文字变化与大范围的连续更新相比，生成并发送画面的工作性质不同。
    A{"画面的变化"} -->|"添加一个字符"| B["小范围"]
    A -->|"滚动"| D["大范围连续变化"]
    B --> E["按变化压缩并传输"]
    D --> E

图6：即使是同一个连接，添加一个字符的场景与大范围持续变动的场景，工作量也不同。

即使显示静止的文档时负担很轻，滚动时画面传输也可能失去余量。增加远程端的分辨率或显示器数量，需要处理的画面也会变大。降低分辨率的比较，是观察减少生成和发送画面的工作后动作是否恢复流畅的实验，并不是仅凭像素数来确定流量的计算。参见：分辨率、画面更新与压缩的影响。

应用的等待

如果只有业务应用的搜索会停顿几秒，而在同一会话的记事本里可以正常输入，就要确认这个应用在等待什么。远程端应用有时会进一步向另一台数据库发起查询，或者从共享文件夹读取文件，并等待其回应。这与连接本地和远程端的 RDP 通信是不同的路径。参见：从远程端到后端的通信。

flowchart TB
    accTitle: RDP 的另一头还有通信对象
    accDescr: 除了连接本地设备与远程端的通信之外，远程端应用还可能在等待业务服务器的回应。
    A["本地设备"] -->|"RDP"| B["远程端的业务应用"]
    B -->|"查询与文件请求"| C["数据库、共享文件夹"]
    C -->|"正在等待的回应"| B

图7：RDP 另一头的业务应用，有时还在等待另一台服务器的回应。

负责画面或输入的处理一旦承担了耗时的工作，下一次输入和画面更新就会延迟。例如在 WPF 中，UI 线程被长时间占用会损害响应性。仅凭 CPU 整体使用率低，并不能排除特定 UI 线程的等待。参见：Dispatcher 与 UI 线程。

flowchart TB
    accTitle: 负责画面和输入的处理发生阻塞
    accDescr: 负责画面和输入的处理承担了耗时的工作后，下一次输入和画面更新会延迟；仅凭 CPU 整体使用率低，并不能排除这种等待。
    A["负责画面和输入的处理"] --> B["承担耗时的工作"]
    B --> C["下一次输入和画面更新延迟"]
    C -.- D["CPU 整体低也不能排除"]

图8：仅凭 CPU 整体使用率，无法排除 UI 线程的等待。

按症状选择最初的比较

能搬运的量、等待回应的时间，以及生成并显示画面的时间，是三件不同的事。只要保持这种区分，就不会把“RDP 很卡”归结为单一原因，而能从眼下慢的操作开始调查。

flowchart TB
    accTitle: 先分成三项再调查
    accDescr: 不把“RDP 很卡”归结为单一原因，而是把能搬运的量、等待回应的时间、生成并显示画面的时间分开，从眼下慢的操作开始调查。
    A["“RDP 很卡”"] --> S
    subgraph S["分别查看"]
    direction TB
    B["能搬运的量"] ~~~ C["等待回应的时间"]
    C ~~~ D["生成并显示画面的时间"]
    end
    S --> E["从眼下慢的操作开始调查"]

图9：把能搬运的量、等待回应的时间、生成并显示画面的时间分开，就能从眼下慢的操作开始调查。

排查的目标是限定调查慢的位置，而不是一口气改动设置、碰巧让它变快。利用“记事本能动，只有搜索会卡住”“打字正常，只有滚动很卡”这类差别，即使在更改通信设置之前，也能选定调查的切入点。

下表是调查的出发点，并不是判定原因的表。先在同一会话中比较操作，再改变所需的设备、路径和显示条件。

看到的症状	最先比较的内容	之后要看的地方
在多个应用中字符都逐个延迟出现	从另一台设备、另一条许可的路径连接同一远程端	往返时间、输入等待、远程端整体的负载
输入正常，但滚动卡顿	远程端的分辨率或显示器数量	远程端的压缩、画面传输、本地的解码
只有一个应用卡住	同一会话中的记事本等是否有响应	该应用的处理、磁盘、从远程端往外的通信
只在用户增多的时段大家都慢	同一时段的其他会话是否也一样	共享主机的 CPU、内存、存储，共享线路
开始复制或打印后变慢	暂停自己的传输后是否恢复	传输或设备重定向与画面通信的争用

多个应用中字符都延迟出现

如果在同一会话的多个应用中字符都逐个延迟出现，就用另一台设备或另一条许可的路径比较同一操作。对照往返时间、远程端的输入等待和远程端整体的负载，不要仅凭一个数值确定原因。

只有滚动时卡顿

即使文字输入正常，滚动图片很多的网页时也会持续出现大范围的画面更新。逐一改变远程端的分辨率或显示器数量，在同一网页上进行比较。如果有所改善，远程端的压缩、画面传输和本地的解码就是下一步的调查对象。仅凭分辨率，无法判断这三者中哪一个才是原因。参见：画面内容与分辨率带来的负载。

只有一个应用卡住

如果只有点击了搜索的业务应用停住，就比较同一会话中的记事本等是否有响应。如果其他应用在正常运行，就先调查目标应用的处理、磁盘，以及对数据库或共享文件夹的请求。通过 RDP 进行操作，与 RDP 通信是等待的原因，是两回事。参见：应用与后端的性能因素。

只在用户增多的时段大家都慢

如果同一时段多个用户都变慢，就向管理员确认其他会话的情况。把共享主机的 CPU、内存、存储以及共享线路的负载，与出现症状的时间对照。不要擅自访问其他用户的记录或处理，也不要停止他们的作业。参见：共享主机的资源与用户数。

复制或打印时变慢

如果自己开始复制或打印的时间与异常重合，就只暂停获准停止的传输来进行比较。记录停止后是否恢复、重新开始后是否变慢，并调查与画面以外的传输或设备重定向之间的争用。不要通过一次性禁用业务所需的设备来进行比较。参见：设备重定向的影响。

逐一比较条件

不需要依次更改所有设置。先建立比较的基准，只选择与症状相符的检查。在更改设置或重新连接之前，请保存工作，并记录原来的值和恢复方法。如果没有所需的权限或功能，不要勉强启用，而是交接给管理员。

本地操作与 RDP 操作的条件不一定相同。在远程端的实体屏幕上操作很快，可以作为参考，但会话和绘制条件有时会不同。请统一用户、数据和应用的状态，不要只凭“在实体屏幕上很快”就把原因限定在网络上。

比较同一操作

准备相同的用户、数据和操作。在共享主机上要确认自己的会话，不要停止其他用户的应用或处理。使用另一台设备或另一条路径，也仅限于管理员许可的范围。

在原来的设置下复现慢的操作，记录时间和症状。

在与问题应用相同的远程会话中，用记事本输入同等数量的字符。区分是只有一个应用慢，还是整个会话都慢。
在同一时段检查远程端和本地的负载。

在任务管理器中，远程端查看目标应用的 CPU、内存和磁盘，本地查看 RDP 客户端的负载。不只看 CPU 的整体值，也要确认目标进程。参见：负载的调查对象。
在另一台设备、另一条许可的路径和显示条件中只改变一个条件，重复同一操作。

如果比较时远程端或应用的状态也同时发生了变化，也要把这些差异记录下来。不要把多个条件变化后的结果，当作只改变一个条件的效果。
恢复到原来的条件，再次确认同一操作。

如果恢复原状后仍然很快，也可能是暂时的负载变化等原因。不要断定是更改起了作用，而要记录症状能复现的条件。

这样就能凑齐原始状态、更改后和恢复原状后的结果，比较哪个条件与症状相对应。改善了的条件是调查的线索，单凭它并不能证明根本原因。

flowchart TB
    accTitle: 限定一次改变的条件
    accDescr: 确定在原始状态下能复现的操作，只改变一个条件进行比较，并确认恢复原状后的结果的流程。
    A["在原来的设置下做同一操作"] --> B["只改变一个条件"]
    B --> C["重复同一操作"]
    C --> D["恢复原状后再次确认"]
    D --> E["记录改善了的条件"]

图10：在原始状态、更改后、恢复原状后的状态下重复同一操作，记录发生变化的条件。

比较远程端的分辨率

在滚动等画面更新很卡时进行比较。记录更改前的分辨率和显示器数量，保存工作后再重新连接。不要把损害业务所需画面或文字可读性的设置直接沿用为日常设置。

在显示器数量和分辨率中只改变其中一项。

在 mstsc 中，可以通过连接前“显示”选项卡中的设置，或指定宽度和高度来进行比较。参见：mstsc 的显示指定。
确认远程桌面的实际大小已经改变，再滚动同一网页。

仅仅把本地窗口缩小，有时只是把大的桌面缩小显示而已。请区分动态分辨率和 smart sizing，并确认所用客户端的支持条件。参见：桌面分辨率与显示缩放。
恢复原来的设置并重复同一操作，比较两端的负载和画面的动作。

如果同时改成低分辨率并合并为一台显示器，就只能算是粗略的比较。如果有所改善，请逐项恢复，把各自的影响区分开。

如果有所改善，线索就在画面处理和画面传输的范围内。3840×2160 的像素数是 1920×1080 的 4 倍，但流量并不总是 4 倍。它会随变化的部分和压缩而改变，而且分辨率的更改也会影响两端的处理。参见：像素数与流量的关系、画面处理的检查。

flowchart TB
    accTitle: 降低分辨率的比较能看出的范围
    accDescr: 降低远程端的分辨率后，画面处理和传输双方的负担都可能改变，因此仅凭改善无法把原因限定在网络上。
    A["降低远程端的分辨率"] --> S
    subgraph S["会改变的处理"]
    direction TB
    B["远程端的画面处理"] ~~~ C["发送的信息量"]
    C ~~~ D["本地的显示处理"]
    end

图11：更改分辨率是一种不仅影响网络、也影响远程端和本地画面处理的比较。

将复制、打印与症状对照

只暂停自己发起的传输等获准停止的处理。不要停止公司的备份或安全处理，也不要停止其他用户的作业。不要一次性禁用业务所需的音频和输入设备的重定向。

在开始复制、云同步或打印之前以及执行过程中，记录同一操作和负载。

除了画面之外，RDP 中还会传输驱动器、打印机等的信息。在远程端使用本地设备的重定向，在使用时有时会增加通信和处理的负担。参见：设备重定向的影响。
在许可的范围内暂停目标传输，再次确认同一操作。

如果可以重新开始并进行比较，也要记录重新开始后的症状。尝试停用不需要的设备重定向时，也要逐一更改，并确保能恢复到原来的设置。

这样就能判断传输开始与异常、暂停与恢复是否相对应。如果看到了对应关系，就把画面以外的传输以及共享资源的负载，与管理员的记录进行对照。

flowchart TB
    accTitle: 在同一时间轴上查看异常前后
    accDescr: 在传输前、传输中、停止后记录同一操作和负载，比较异常与作业之间的关系。
    A["传输前的操作与负载"] --> B["传输中的操作与负载"]
    B --> C["停止后的操作与负载"]
    C --> D["异常与恢复是否对应"]

图12：观察同一操作的慢速程度和负载在传输前、传输中、停止后如何变化。

测量等待发生的位置

在本地调查通信往返和 TCP 连接，在远程端调查输入队列的等待和画面更新。每个数值能测量的区间都有限，因此要对照“测量结果的适用范围”中的表来解读结果。

检查 ICMP 与 TCP 连接

执行位置是本地的 Windows 设备。对象仅限于通过公司内部 LAN 或许可的 VPN，直接连接到使用标准 TCP 3389 的 RDP 主机的配置。对于经由 RD Gateway、Azure Virtual Desktop 或使用自定义端口的配置，请与管理员商定检查对象。不要开放端口或更改防火墙。

输入许可的连接目标，记录 ICMP 响应和 TCP 连接的结果。

$target = Read-Host '已获准调查的 RDP 主机的名称或 IP 地址'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw '请指定连接目标。'
}
    
# 多次查看 ICMP 的响应时间。不能仅凭失败就判断 RDP 不通。
ping.exe -n 20 $target
    
# 仅限于直接连接标准 TCP 3389 的配置的检查。
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
    

把慢的时段和平常时的结果，与症状出现的时间以及实际的连接路径对照。

20 次 ping 只是短暂的观察。要记录数值的波动和无响应的情况，但 ICMP 有时会被阻止。不要只凭平均值就排除断断续续的停顿，而要使用连接信息和管理员的通信记录。参见：ping 的测量对象。

TcpTestSucceeded: True 的意思是成功建立了到指定端口的 TCP 连接。它没有测量带宽、UDP、身份验证后的操作以及画面的流畅度。Test-NetConnection 中没有用于调查 UDP 的 -UDP 开关。参见：Test-NetConnection 的语法与结果。

判断时要考虑路径和服务的差异。在 RD Gateway 等环境中，到主机的 ICMP 或直接 TCP 连接的路径，与实际的 RDP 路径有时并不一致。Azure Virtual Desktop 可以使用每个连接的 RTT 和带宽估计值，但这项诊断功能是面向该服务的。不要只凭平均值就排除短暂的停顿。参见：Azure Virtual Desktop 的连接质量日志。

flowchart TB
    accTitle: 检查过的路径与实际的 RDP 路径
    accDescr: 在使用 RD Gateway 等的配置中，从本地到主机的 ICMP 或直接 TCP 连接的路径，与实际的 RDP 路径有时并不一致。
    A["本地设备"] -->|"ICMP、直接 TCP"| C["RDP 主机"]
    A -->|"实际的 RDP"| B["RD Gateway 等"]
    B --> C

图13：到主机的 ICMP 或直接 TCP 连接与实际的 RDP，路径有时并不一致。

测量输入队列的等待

User Input Delay 测量的是在远程端输入进入队列后、到进程将其取出为止的等待，而不是从按键到看见字符的总时间。参见：User Input Delay 的定义。

在远程端的远程会话内进行调查。Microsoft 给出的支持条件是 Windows 10 版本 1809 及更高版本、Windows Server 2019 及更高版本。对于这些对象，不需要为启用而添加注册表项。请确认显示名称、权限以及计数器是否存在；如果无法使用，就记录这一事实并与管理员商量。参见：支持条件与设置。

在同一会话的 PowerShell 中，记下时间和会话 ID。
```
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session
    
```
查询其他用户的会话可能需要额外的权限。目标进程的标准实例名是 SessionID:ProcessID <Process Image>。不要仅凭会话 ID 就把其他用户或同名进程的值混在一起。参见：query session 的权限、实例的识别。
在 perfmon.exe 中，添加可用的 User Input Delay per Process 或 User Input Delay per Session。

选择目标进程或会话，起初以默认的 1 秒间隔进行观察。请把汇总多个会话的聚合实例与单个会话的值区分开。
复现输入慢的操作，比较队列的等待与症状出现的时间。

对单个测量对象而言，看到的是测量区间内的最大等待时间。即使数值很低，应用取出输入后的处理以及结果返回本地之前的延迟依然存在。

这样就能调查是否在远程端的输入队列中等待。它与包含通信往返和本地显示在内的体感时间是不同的指标。参见：最大值与测量区间的含义。

flowchart TB
    accTitle: User Input Delay 测量的区间
    accDescr: 测量区间是从远程端的输入队列到应用将输入取出为止，不包含前后的通信和画面显示。
    A["输入从本地到达"] --> B["进入远程端的输入队列"]
    B -->|"测量这里"| C["应用取出输入"]
    C --> D["应用处理与画面传输"]
    D --> E["显示在本地"]

图14：测量的是远程端输入队列中的等待，与到本地看见结果为止的总时间不同。

调查画面更新与跳帧原因

准备滚动等画面持续更新的操作。RemoteFX Graphics 计数器是否可用以及测量位置，需要根据 OS、主机配置和权限加以确认。这里只是读取可用的计数器，并不是安装或启用旧版 RemoteFX 功能的步骤。参见：Graphics 计数器的适用条件。

用 query session 或 qwinsta 确认目标会话名，选择对应的计数器实例。
在有画面更新的操作过程中，比较 Input Frames/Second 和 Output Frames/Second。

如果输出少于输入，说明画面在中途被跳过了一部分帧。查看 Frames Skipped/Second 中按远程端、网络、客户端资源不足分别给出的值。
把跳帧原因与两端和通信的负载对照，并确认 Average Encoding Time。

如果编码时间很长，就调查远程端的压缩处理。如果从输入端开始帧数就很少，也可能是应用并没有频繁地更新画面。静止画面下帧数低本身并不是异常。

根据画面更新时的输入输出、跳帧原因和编码时间，可以缩小调查范围。计数器的分类只是线索，要结合实际的负载和连接配置来判断。参见：帧数与编码时间的解读方法。

flowchart TB
    accTitle: 根据画面的跳帧缩小调查范围
    accDescr: 在有画面更新的操作过程中比较输入输出帧数，以跳帧原因的计数器为线索，与处理、通信和显示的负载对照。
    A["比较滚动时的输入输出"] --> B["输出少则确认跳帧"]
    B --> C["查看按原因分类的计数器"]
    C --> D["与远程端、通信、本地负载对照"]

图15：比较滚动时的输入输出，把跳帧原因与远程端、网络、本地的负载对照。

不要把画面传输的概念图或旧资料推广到所有配置。也有用其他机制传输视频和音频的配置。Graphics 计数器的资料中也包含对旧配置的说明，因此不要把其中记载的数值理解为“所有 RDP 最高 30fps”这样的通用规格。请确认功能和数值的适用对象后再使用。参见：画面传输与工作负载、Graphics 计数器资料。

测量结果的适用范围

不要把数值低与操作流畅等同起来。各项指标的范围，可以在步骤中给出的 Microsoft 资料中确认。

观测到的结果	能知道的事	仍不知道的事
ping 的响应很小	到该对端的 ICMP 响应时间	实际的整条 RDP 路径、应用处理、画面显示是否正常
TcpTestSucceeded 为 True	成功建立到指定目标、指定端口的 TCP 连接	UDP、带宽、身份验证后的响应
User Input Delay 很大	目标远程端输入队列中的等待	取出输入后的处理，以及到本地为止的总延迟
更新时输出帧很少	调查画面跳帧及其原因的线索	单一的根本原因。需要与两端和通信的记录对照
降低分辨率后有所改善	显示条件与症状可能相对应	原因是网络、编码还是解码

通信与 GPU 设置

UDP 和 GPU 的设置，要根据比较和测量中查明的情况来选择。如果怀疑是通信，就先确认连接方式和路径；如果怀疑是画面处理，就先确认 GPU 在哪个阶段被使用。

确认 TCP、UDP 与连接路径

当比较和测量显示通信可疑时，与管理员一起确认正在使用的客户端、路径以及所应用的策略。即使需要更改设置，也仅限于获批准的范围，并记录更改前的值和恢复方法。不要禁用防火墙或身份验证，也不要把 RDP 端口直接暴露到互联网上。

通过连接信息、产品的诊断日志和管理员的通信记录，确认实际使用的 TCP、UDP 和路径。

RDP 会根据配置和通信条件使用 TCP 或 UDP。在“Select RDP transport protocols”中，可以在使用 UDP 或 TCP 的设置与仅使用 TCP 的设置之间进行选择。由于存在 UDP 连接无法建立时改用 TCP 的行为，仅凭连接成功无法得知所用的方式。参见：RDP transport 的选择与回退。
把症状出现的时间与路径和方式对照，只逐一比较必要的设置。

不要一概认为“关掉 UDP 就会变快”而进行更改。统一 VPN 或网关的条件、操作和显示条件后再比较，并撤销不必要的更改。

在掌握方式和路径的基础上，就能记录更改与症状之间的关系。改为仅用 TCP 并不一定总能提速。

flowchart TB
    accTitle: 先确认连接方式再比较通信设置
    accDescr: 区分普通的直接连接与经由网关或服务的连接，确认实际的路径和方式后，再进行许可范围内的比较。
    A["所用客户端与连接配置"] --> B["确认实际路径与 TCP、UDP"]
    B --> C["与症状出现的时间对照"]
    C --> D["只逐一比较必要的设置"]

图16：确认正在使用的连接方式和路径，与症状对照之后，再只比较必要的设置。

RDP Shortpath 是 Azure Virtual Desktop 的机制。它会为该服务建立 UDP 路径，并根据配置使用直接路径或中继。如果无法建立，就回退到基于 TCP 的连接。它不能与用 mstsc 直接连接公司内部 PC 的情况放在同一张设置表里。参见：RDP Shortpath 的路径与回退。

flowchart TB
    accTitle: RDP Shortpath 的路径与回退
    accDescr: Azure Virtual Desktop 的 RDP Shortpath 会尝试建立 UDP 路径，建立成功时根据配置使用直接路径或中继，无法建立时回退到基于 TCP 的连接。
    A["RDP Shortpath"] --> B{"UDP 路径"}
    B -->|"建立"| C["直接或中继"]
    B -->|"未建立"| D["回退到基于 TCP"]

图17：RDP Shortpath 如果无法建立 UDP 路径，就会回退到基于 TCP 的连接。

确认画面处理是否使用 GPU

当比较和测量显示画面处理可疑时进行确认。确认画面处理的测量结果，以及支持的 OS、驱动程序、策略和客户端。不要仅仅因为装有 GPU 就更改设置。请先取得管理员的批准，并做好恢复原状的准备。

把远程端应用的绘制、RDP 的编码和本地的解码分开，选出可疑的阶段。

即使有 GPU，也不一定所有阶段都使用 GPU。在 Microsoft 面向 Azure Virtual Desktop 的配置资料中，远程会话的绘制与帧的硬件编码也是分别设置和确认的。参见：绘制与编码的 GPU 配置及验证。
按照目标产品的步骤确认实际的使用情况，在必要的更改前后测量同一操作。

如果压缩时间很长，就调查编码是否使用 GPU。对于在输入队列中等待的应用，即使更改编码设置，瞄准的位置也不对。文字的可读性与视频的流畅度，在画质、流量和处理负载上的取舍也不同。参见：工作负载带来的差异。

这样就不止于 GPU 的有无，而能记录问题所在的阶段是否使用了 GPU，以及同一操作的负载和响应如何变化。没有带来改善的更改，要与管理员确认后恢复原状。

flowchart TB
    accTitle: 按阶段确认 GPU 的使用
    accDescr: 把远程端应用的绘制、RDP 的编码和本地的解码分开；即使有 GPU，也不一定所有阶段都使用 GPU，因此要确认可疑阶段的使用情况。
    A["远程端应用的绘制"] --> B["RDP 的编码"]
    B --> C["本地的解码"]
    C -.- D["按阶段确认 GPU 使用"]

图18：即使有 GPU，绘制、编码、解码也不一定全部使用 GPU。

重新验证与交接

确认改善时，除了更改后同一操作能顺利完成之外，还要确认所需的画质、设备和业务功能得以保持。也请对照恢复原来条件后的结果。如果只是瞬间恢复，就不要确定原因，而要连同拥挤时段和同时进行的处理一起记录。

flowchart TB
    accTitle: 确认改善的顺序
    accDescr: 确认更改后同一操作能否顺利完成，以及所需的画质、设备和业务功能是否得以保持，并与恢复原来条件后的结果对照；仅凭瞬间的恢复不能确定原因。
    A["更改后试做同一操作"] --> B["确认画质、设备、业务功能"]
    B --> C["与恢复原条件后的结果对照"]
    C -.- D["瞬间恢复不能确定原因"]

图19：除了同一操作的结果，还要对照所需的功能以及恢复原状后的结果。

未解决时的交接

没有改善、无法复现、计数器无法使用，这些也都是有用的结果。把已经完成的比较和未能进行的检查分开，用下面的备忘交接给管理员和开发人员。请从共享的日志中删除调查不需要的用户名、连接目标等业务信息。

出现症状的时间与时区：
远程端 OS、所用客户端及版本：
直接连接／VPN／RD Gateway／Azure Virtual Desktop 等：
慢的操作与应用，同一会话中其他应用的反应：
远程端的分辨率、显示器数量：
同时进行的复制、打印等：
只改变的一个条件，以及恢复原状后的结果：
在远程端、本地观测到的负载或计数器：

还要补充是否确认了实际使用的 TCP、UDP，因权限不足等原因未能确认的项目，以及业务上可以接受的设置。与其说“网络很慢”，不如说“记事本能正常打字，但滚动照片时会卡住”，这样下一位负责人才能在相同条件下调查。

用户留下能复现的操作和比较结果，管理员对照连接路径、共享主机和会话的记录。仅凭在 RDP 上等待这一事实，并不能说明造成等待的处理也一定在 RDP。参见：主机与后端的分工。

应用的开发人员要把输入事件的接收、数据库和文件处理的开始与结束，以及向 UI 的反映分开记录，还要考虑不让耗时的工作长时间占据 UI 线程的设计。不过，远程端的处理完成日志，并不是对本地显示完成的记录。参见：保持 UI 响应性的处理分离。

参考资料

以下是 Microsoft Learn 的一手资料，已于 2026年9月17日确认所引用的内容。阅读时请区分各产品的适用条件，并注意这些内容并不是本文已实施的实测。

Microsoft Learn, Analyze connection quality in Azure Virtual Desktop。RTT，以及从远程端捕获画面到本地显示为止的延迟之间的区别。诊断功能本身面向 Azure Virtual Desktop。
Microsoft Learn, Remote Desktop Protocol bandwidth requirements。画面内容、分辨率、帧更新、压缩、缓存与流量之间的关系。
Microsoft Learn, Diagnose graphics performance issues in Remote Desktop。画面输入输出、跳帧原因、编码时间的确认方法。其中包含对旧配置的说明，因此不要把数值上限推广到所有 RDP。
Microsoft Learn, Performance Tuning Remote Desktop Session Hosts。共享主机的负载、从远程端到后端的通信，以及设备重定向的影响。
Microsoft Learn, Threading model。WPF 的 UI 线程与 Dispatcher，以及为保持响应性而进行的处理分离。
Microsoft Learn, mstsc。远程桌面的宽度、高度以及多显示器的指定。
Microsoft Learn, Supported RDP properties。桌面分辨率、动态分辨率与 smart sizing 的区别。需要确认所支持的客户端以及各产品的适用条件。
Microsoft Learn, ping。通过 ICMP Echo 确认响应，以及各选项。
Microsoft Learn, Test-NetConnection。TCP 连接检查与输出的含义。
Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts。User Input Delay 的测量区间、对象 OS、实例以及最大值的含义。
Microsoft Learn, query session。会话信息，以及查询其他会话所需的权限。
Microsoft Learn, ADMX_TerminalServer Policy CSP。RDP 所用 TCP、UDP 的选择与回退。
Microsoft Learn, RDP Shortpath。面向 Azure Virtual Desktop 的 UDP 路径，以及无法建立时的行为。
Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop。把绘制与帧编码分开的 GPU 配置及验证。

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

Windows 应用程序开发

支持业务应用、设备联动、通信工具等 Windows 软件的开发。

查看服务联系我们

常见问题

汇总了咨询这一主题时常见的问题。

测速能跑到几百 Mbps，为什么 RDP 的输入还是很慢？: 搬运大量数据的速度，与操作后得到响应所需的时间是两回事。输入的发送、远程端应用的处理、画面的压缩、传输以及本地的显示都与之相关。此外，测速的对端与 RDP 的远程端之间，通信路径也不相同。
打字很正常，只有滚动时卡顿，这是网络的问题吗？: 不能只归结到网络。画面更新增多时，远程端的绘制和压缩、通信、本地的解码和显示中，任何一个环节都可能跟不上。逐一改变远程端的分辨率或显示器数量进行比较，必要时再调查与绘制相关的计数器。
ping 很快，就说明 RDP 的通信正常吗？: 仅凭这一点无法判断。ping 测量的是对 ICMP 的响应，并不测量 RDP 的画面传输或应用的处理。在使用 RD Gateway 等的配置中，路径也可能不一致。没有响应时，也请区分是 ICMP 被阻止，还是 RDP 本身不通。
User Input Delay 是从按键到字符出现的时间吗？: 不是。它是测量在远程端输入进入队列后、到进程将其取出为止的等待时间的计数器。它并不是包含通信往返、取出后的应用处理，以及画面的压缩、解码和显示在内的体感延迟。
RDP 很卡时，应该禁用 UDP 吗？: 不建议一概这样做。首先确认实际的连接方式、路径和所应用的策略。有时是因为 UDP 无法使用而回退到了 TCP，改为仅用 TCP 并不一定总会变快。在管理员的许可下统一条件进行比较，并撤销不必要的更改。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长保留有既有资产的项目，以及原因难以看清的故障调查。

查看简介联系我们

公开链接

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

返回博客列表