很多企业员工通过VPN接入内网访问远程桌面时，经常遇到鼠标拖拽卡顿、画面跳帧、输入指令延迟数秒才响应的问题，这类问题很多时候并非公网带宽不足，而是VPN链路中多个核心节点的设备性能没有达到运行要求，本文梳理VPN远程桌面延迟排查必做的核心设备性能检查项，帮运维人员快速定位性能瓶颈，排除不必要的网络链路排查成本。
运维人员在机房核查VPN网关的算力负载与并发隧道规格，排查远程桌面延迟问题
VPN网关自身算力负载检查
很多运维排查延迟问题第一反应先查公网带宽，反而忽略了VPN网关本身的性能占用情况，当VPN网关同时承载的加密隧道数量、并发接入终端数超过设备标称的处理阈值时，加密解密运算的排队延迟会直接传导到后续的远程桌面链路中。
检查的时候可以直接登录VPN网关的管理后台，查看CPU、内存的实时占用率，同时核对当前在线VPN隧道的总数量，和设备官方给出的最大并发隧道规格做比对。如果发现核心运算模块的负载长期处于高占用状态，即便公网链路带宽还有剩余，VPN封装解密的过程也会出现数据包排队，直接引发远程桌面的操作延迟，这也是很多中小公司VPN接入人数突增后远程桌面集体卡顿的核心原因。
内网出口网卡与端口转发性能检查
不少VPN网关是部署在原有内网出口防火墙之后，或者直接和核心交换机做端口对接，很多人会忽略对接端口的双工模式、流量队列配置对VPN流量的影响。
排查的时候需要分别查看VPN网关连接内网侧、公网侧的两个物理网卡的实时流量占用，确认端口没有出现半双工模式下的频繁冲突丢包，同时查看端口的输出队列是否存在持续的数据包积压。如果端口的队列调度规则没有给VPN远程桌面这类低延迟流量配置优先级，大体积的内网备份、文件传输流量会挤占端口的处理资源，导致远程桌面的小体积交互数据包被延后发送，表现出来就是鼠标移动的反馈明显滞后。
远程桌面宿主机的硬件资源占用检查
很多运维排查外围网络设备之后，还是找不到延迟原因，问题往往出在提供远程桌面服务的终端或者服务器本身的性能状态上。
用户通过VPN接入之后，远程桌面服务需要实时对屏幕画面做编码压缩，再通过VPN隧道回传给接入端，如果宿主机的CPU被其他后台任务占满，画面编码的运算速度跟不上屏幕刷新的需求，就会出现画面卡顿、跳帧的现象。检查的时候可以直接在宿主机本地登录，查看任务管理器中远程桌面相关进程的资源占用情况，同时确认宿主机的显卡编码模块没有被其他应用占用，没有开启多余的后台特效占用渲染资源。如果本地直接操作宿主机都出现画面响应慢的情况，即便VPN链路状态完全正常，远程接入的体验也会出现明显延迟。
终端侧VPN客户端的运行资源检查
除了服务端的设备，发起VPN连接的用户终端本身的性能状态，也可能成为VPN远程桌面延迟的诱因。很多用户的个人终端同时运行着大量后台下载、云同步、实时渲染类的高负载程序，科学上网留给VPN客户端加解密运算、远程桌面客户端画面解码的资源不足。
排查的时候可以指导用户关闭终端上非必要的高负载后台程序，查看终端的CPU、科学上网内存占用率回落之后，再重新测试VPN远程桌面的操作流畅度。部分老旧终端的无线网卡驱动存在兼容问题，处理VPN封装之后的加密数据包时会出现运算卡顿，替换有线连接或者更新网卡驱动之后，延迟问题大概率会得到缓解。
需要注意的是，以上所有设备性能检查项都只能覆盖性能不足引发的VPN远程桌面延迟场景，排查完所有性能维度之后如果问题仍然存在，才需要进一步排查公网链路丢包、跨运营商访问、路由绕行这类网络层面的问题，猎豹避免一开始就大范围排查无关节点浪费运维时间。单次性能排查的结果也只能定位当前发现的瓶颈点，不能完全排除其他隐性网络问题叠加引发延迟的可能性，后续还需要结合链路层面的检测做交叉验证。
