低延迟网络模式——优先让画面更快到达
两种网络模式
BilldDesk 在高级设置中提供了两种网络模式:
默认模式(Default)
平衡画质和延迟,适合大多数常规远程场景。画面质量优先,但偶尔延迟可能高一些。
低延迟模式(Low Latency)
优先降低延迟,让画面更快到达主控端。为了实现更低的延迟,会牺牲一些画质稳定性(画面可能偶尔出现色块或轻微模糊)。
什么时候切换到低延迟模式
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 日常远程办公(看文档、打字) | 默认 | 画质更重要 |
| 远程修图 / 看视频 | 默认 | 需要看清画面细节 |
| 远程操作(点按钮、移动鼠标) | 低延迟 | 操作的即时反馈更重要 |
| 远程游戏 / 游戏串流 | 低延迟 | 游戏对延迟极其敏感 |
| 远程协助(操作密集) | 低延迟 | 操作反应快效率高 |
低延迟模式特别适合游戏场景,配合 驱动级键鼠 和 GPU 硬件加速 使用效果最佳。
帧率模式
BilldDesk 还提供了帧率模式设置,和网络模式配合使用:
- 默认:保持设定帧率,画面变化快时也不降帧率
- 办公低刷:根据画面变化智能降低帧率,静止画面低帧率节省带宽,活动画面自动提升帧率
对于游戏场景,帧率模式保持「默认」或设为高刷;对于办公场景,设为「办公低刷」可以节省带宽。
延迟从哪来
远程桌面的总延迟由以下几个环节组成:
| 环节 | 延迟来源 | 可优化手段 |
|---|---|---|
| 被控端屏幕捕获 + 编码 | GPU / CPU 编码速度 | 开启硬件加速 |
| 网络传输 | 主控端 ↔ 被控端网络延迟 | P2P 直连、选最近中继 |
| 中继转发(如需要) | 中继服务器处理 + 转发延迟 | 切换中继、自建中继 |
| 主控端解码 + 显示 | 浏览器 / 客户端解码速度 | 开启硬件解码 |
低延迟模式主要优化的是编解码环节和帧发送频率——减少编码等待时间、加快帧发送频率、在网络抖动时优先保帧率而不是保画质。
实际能降多少延迟
官方没有公布低延迟模式的具体延迟改善数据,但根据行业经验:
- WebRTC 默认优化后,良好网络下基础延迟约 80ms
- 低延迟模式下,延迟可以降到 50ms 左右
- 如果走中继服务器,额外增加 20-50ms 的延迟
50ms 的延迟对于大部分远程操作已经足够流畅(人类对 100ms 以内的延迟几乎没有感知)。
低延迟 vs 保画质:如何权衡
低延迟模式牺牲的主要是画面的压缩效率(为了更快发送帧,允许更多冗余数据或更粗的压缩),而不是分辨率本身。具体表现:
- 画面整体仍然清晰,但快速移动的区域可能出现轻微的色块
- 画面切换可能比默认模式略粗糙
如果网络带宽充足,低延迟模式的画质损失很小(因为带宽够用,不需要为了省带宽而降低画质)。如果带宽紧张,两者差异会更明显。
延迟测试方法
没有 BilldDesk 自带的延迟显示工具时,可以粗略判断当前延迟:
- 被控端在远程窗口中打开一个记事本
- 在被控端记事本里输入当前时间
- 在主控端看远程画面中时间更新的时刻
- 对比主控端本地时间和远程画面时间,差值大约就是总延迟
更精确的方法是打开被控端的秒表并快速开始,在主控端截图对比两台屏幕。