H3C Workspace 云桌面解决方案：从 VDI 架构到企业部署实战

这篇文章要解决的问题是：如何设计与部署一套 H3C Workspace 云桌面（VDI，Virtual Desktop Infrastructure），让用户通过瘦客户端获得的远程桌面体验尽可能接近本机，并在"卡""启动慢""扩容难"这类真问题出现之前，先把机制想清楚。它背后最基础的事实只有一条：桌面操作系统并没有消失，它只是把执行位置从用户手边的物理机搬到了数据中心的虚拟机里继续运行；用户每敲一个键、每看到一个像素，都必须跨越"本地终端—网络—数据中心"这条链路往返一次。

从这个事实出发，后续内容几乎都是推导：操作系统在数据中心运行，那么屏幕画面、音频与外设都必须依靠一种显示协议在两端之间搬运；所有桌面共享同一批宿主机的 CPU、内存、存储与网络，那么一个人的负载就可能挤占另一个人的资源；画面要经过网络传输，那么延迟预算就取代"本机性能"成为体验的新度量；状态全部集中在数据中心，那么集中管控与离线可用就成了一对必须做取舍的矛盾。下文按因果链展开：原理层讲清机制，操作层给出架构组件、连接流程与运维路径，验证层说明怎么确认做对了，边界与坑回答什么场景不该用以及常见失败模式，最后简短收尾。

#原理层：从"本地电脑"到"远程桌面"，发生了什么

#第一步：操作系统执行位置的转移

在传统 PC 上，操作系统与硬件天然是一体的：键盘与鼠标的中断由本机内核处理，应用的绘图指令由本机显卡驱动完成，文件打开发生在本地磁盘，屏幕刷新发生在本地显示器。整条链路闭合在用户面前几十厘米的空间内，用户感知到的"本机操作"就是这一套本地闭环的结果。它的延迟基线很低（典型为 10–20 ms），而且每台 PC 的劣化都是孤立的——你的机器慢是你的事，不影响隔壁，也没有人需要为整条链路负责。

VDI 把这条闭环拆开了。虚拟化平台（Hypervisor）把物理服务器的 CPU、内存、磁盘切成多份虚拟资源，每个虚拟桌面就是一台运行在数据中心宿主机上的虚拟机（VM），虚拟机内部是一个完整、独立的操作系统实例；用户的本地终端退化为一个轻量客户端，只承担两件事：采集输入（键盘、鼠标、触控），显示服务端送来的画面。中间隔着网络，所有用户操作都变成一次跨网络的往返事务。

这一步转移带来三个结构性后果，也是后面所有讨论的前提：

1. 数据与算力集中：操作系统、应用、文件都运行和存放在数据中心，终端的本地存储可以几乎为零——这正是"数据不落地"安全模型的基础，也是集中备份、集中补丁、集中防泄露的前提。
2. 体验变成网络函数：用户在终端上感知到的每一毫秒延迟，都是输入上行、画面下行两条网络路径与服务端处理时间的总和。体验不再由终端性能决定，而由整条共享链路决定。
3. 资源变成共享池：几十台、几百台桌面跑在同一批宿主机上，CPU 排队、内存争抢、存储排队、网络拥塞都会跨用户传染。这在传统 PC 上不存在，却是 VDI 的常态。

所以 VDI 的第一个设计动作，不是选协议，也不是挑硬件，而是先承认这是一个共享资源系统，然后决定谁跟谁共享。

#第二步：显示协议——把桌面"搬"过网络的那条管道

解决了"操作系统在哪运行"，下一个问题是"用户如何看到它"。答案是显示协议（Display Protocol）。它负责在服务端虚拟机与客户端终端之间搬运四类东西：屏幕画面（下行）、键盘鼠标输入（上行）、音频（双向）、外设（U 盘、打印机、摄像头、加密狗等）。

画面搬运有两种基本策略，理解它们就理解了所有协议差异的根源：

• 像素流（Pixel Streaming）：服务端把渲染完成的画面直接采集、编码成视频流，发给客户端解码显示。优点是实现简单、与应用程序无关，任何界面都能传；缺点是带宽占用高、编码要消耗 CPU/GPU 资源，动态画面会成倍放大开销。
• 指令重定向（Instruction/API Redirection）：服务端不传画面，而是把绘图指令（如 GDI、DirectX、OpenGL 调用）转发给客户端，由客户端本地显卡重新渲染。优点是带宽极低、画质在本地分辨率下接近无损；缺点是对客户端软硬件能力要求高，遇到不支持的指令或应用会退化，兼容性排查困难。

现代桌面协议几乎没有纯像素或纯指令的实现，都是混合策略：静态区域做增量更新与缓存，文本和矢量图形尽量走指令重定向，视频和动态媒体走专门的重定向通道，实在无法识别的场景才回落为像素流。H3C Workspace 采用的桌面传输协议同样是这类混合实现，具体内部策略随版本演进，本文不再展开横向对比。

输入方向的路径是：客户端采集键盘、鼠标事件，打包后通过网络发送到服务端，由服务端注入虚拟机操作系统的输入队列。这段上行延迟叠加在显示下行延迟之上，共同构成用户感知的端到端延迟。

音频方向有两种做法：一是音频重定向，服务端把音频流单独编码，客户端用本地声卡播放，延迟低、音质可控；二是让声音混进像素流里，画面和声音一起编码传输，两者相互拖累。视频播放是同一道理：一段本地本来可以解码的视频，如果走像素流传输，等于用整条桌面链路的高带宽去传一段原本几 MB 就能表达的数据。所以各协议都会尝试识别媒体会话，把视频流分流到客户端本地解码。原稿对这一点的判断非常直接：能重定向到客户端解码，就不要走像素流——这是少数"架构上绕过问题"而不是"调参解决问题"的场景。

外设方向的核心机制是设备重定向。以 U 盘为例，客户端把本地 USB 设备通过协议通道"逻辑插入"远端虚拟机，虚拟机看到的是一个完整的 USB 设备，可以做读写、格式化和加密狗签名；打印机的常见做法是驱动映射，客户端本地驱动接管物理打印机，服务端只需按逻辑打印机提交作业；摄像头、扫描仪等输入设备类似。重定向通道本身要消耗带宽与延迟预算，外设数量多、数据量大（例如 4K 摄像头视频流），会与桌面画面争抢链路资源——这是后文验证层需要专门测的一项。

把以上四类流量合成一幅图，就是一条完整的延迟链路：

用户输入 → 客户端采集 → 传输 → 服务端处理 → 渲染 → 编码 → 传输 → 客户端解码 → 显示
   ↑                                                                              ↑
   这中间任何一段变慢，用户都只感受到一个结果：卡

#第三步：延迟链条——为什么"卡"是 VDI 的第一性问题

云桌面上线后收到最多的反馈是两个字："卡"。这两个字不是指标，也不是抱怨，而是一个信号：用户感知到的延迟超过了他对"本机操作"的预期。VDI 这类项目的成败，很大程度上取决于你能不能把"卡"拆成一条可分配、可测量的毫秒预算，而不是把它当成一个笼统的性能问题去调参数。

工程上常用的经验区间如下——请务必注意，这是行业经验值，不是实测数据，每家的协议与编解码实现差别很大：

把各环节相加，就得到一句可操作的话："输入到显示"的总量控制在几十毫秒内，用户基本不会说卡；超过百毫秒，无论怎么解释，他都会说卡。

这张表最大的用处不在数字本身，而在于它把"卡"变成了可以分配的东西。如果网络这一段已经占掉一半预算，剩下的只能靠提升编码效率和渲染性能来挤；如果是在跨地域的场景里，那么"能不能做"在物理上就已经被回答了——调参无法改变光速与路由跳数。

这个结构还有一个非常具体的后果：在本地 PC 上互相独立、可以各自劣化的问题，在 VDI 里变成了同一个池子里的竞争。 一台机器在做大文件解压，可能让隔壁几个人的桌面出现瞬断——那不是网络不够，而是服务端那一段的 CPU 或存储队列被占满了。

#第四步：会话的组织方式——桌面池与个人桌面的生命周期差异

"会话"（Session）在 VDI 里指一次用户登录到注销/断开的完整生命周期。会话背后是否绑定某个固定的虚拟机实例，决定了桌面系统的两种组织形态：个人桌面与桌面池。这是架构层面最重要的一个选择，它决定了运维模型、成本模型与用户体验。

个人桌面（Personal/Static Desktop）：用户与虚拟机实例 1:1 长期绑定，这台虚拟机就是"某个人的云上电脑"。用户的数据、个性化设置、安装的应用都会保留；断线重连回到同一台机器，会话状态尽可能延续。它的生命周期很长（以月、年计），适合需要持久状态、强个性化和不能接受状态丢失的场景。代价是运维负担最重：每一台都要单独打补丁、迁移、备份，故障时只能针对单机处理。

桌面池（Desktop Pool / Dynamic Pool）：一批由同一模板克隆出来的同构虚拟机组成一个池，用户每次登录时由连接代理从池中分配一台，注销后回收；断线后按策略保留一段时间（等用户重连）或立即回收。池桌面的生命周期很短（以一次登录会话计），状态默认不保留（用户数据需通过个人盘或用户配置文件重定向实现持久化）。它的优势是运维高度统一：更新应用或补丁时替换模板、重建池即可；负载天然均衡，因为用户不再绑定特定机器；配合预启动，登录时间可以从分钟级降到秒级。

会话生命周期还会影响一个容易被忽视的体验点：个人桌面的"登录"通常会落到操作系统级别，虚拟机一直在跑，登录只是解锁；池桌面的"登录"可能包含虚拟机冷启动或从池中分配，登录时间取决于池的预热程度。 这也是为什么"登录慢"这个反馈首先要分清是哪种桌面形态造成的。

#操作层：H3C Workspace 的架构组件与落地路径

本文不绑定具体产品版本——原稿明确不提供安装与配置步骤，版本差异很大，请以手上版本的官方手册为准。下文按角色描述 H3C Workspace 涉及的架构组件与流程，组件名称随版本可能调整。

#架构组件

一套完整的 VDI 系统，无论厂商是谁，都可以按角色拆成七类组件。H3C Workspace 的落地形态同样落在这些角色上：

1. 接入网关（Access Gateway）：对外唯一入口，终结 TLS 加密连接、做 URL 转发与防火墙穿透，避免客户端直接访问内网管理端口和虚拟机端口。多活部署是网络可靠性的第一道保障。
2. 连接代理（Broker/控制器）：认证、授权、桌面分配与会话路由的中枢。用户"要一台什么样的桌面"由它决定，因此它也承载容量与策略逻辑。
3. 虚拟化平台（计算）：宿主机集群与 Hypervisor，实际运行虚拟桌面操作系统的地方。H3C 侧对应其虚拟化/云平台产品线；GPU 直通或虚拟 GPU 也挂在这一层。
4. 桌面模板与镜像库：裁好系统和应用的"黄金镜像"（模板）保存在镜像库，通过完整克隆或链接克隆批量生成桌面。模板管理是运维的核心杠杆。
5. 存储：三类存储角色要分清——系统盘镜像（读多写少，适合缓存与去重）、用户数据盘（读写都有，要求 IOPS 与可靠性）、备份与快照（容量型）。
6. 网络：至少三个平面——管理网（管理平台与宿主机）、业务网（虚拟桌面与客户端之间的协议流量）、存储网（宿主机与存储之间的数据流量），按安全要求还可以再做管理面与业务面隔离。DNS、DHCP、AD/LDAP 等基础服务是连接流程正常工作的隐含依赖。
7. 终端：瘦客户端（Thin Client）或存量 PC 上安装的客户端软件。终端的解码能力直接进延迟预算表。

一个简化的逻辑拓扑如下（以角色表示，具体网段与设备以实际规划为准）：

终端侧                                   数据中心
┌─────────┐   TLS   ┌──────────┐   ┌──────────────┐
│ 瘦客户端  │ ─────→ │ 接入网关   │ → │ 连接代理/控制器 │
└─────────┘         └──────────┘   └──────┬───────┘
     │                                   │ 分配桌面
     │          显示协议会话（业务网）       ↓
     └──────────────────────────→ ┌──────────────┐
                                  │ 虚拟化平台     │ ← 模板/镜像库
                                  │（宿主机集群）   │ ← 存储池（系统盘/数据盘）
                                  └──────────────┘

#典型连接流程

一次完整的桌面接入，按时间顺序发生如下事情：

1. 用户打开客户端，输入桌面门户地址或接入网关地址
2. 客户端与接入网关建立 TLS 连接，网关把认证请求转发给连接代理
3. 连接代理向身份源（AD/LDAP）验证用户身份与授权策略
4. 代理按策略选择桌面：个人桌面 → 返回绑定虚拟机；桌面池 → 从池中分配一台
5. 代理把虚拟机地址与会话参数返回客户端
6. 客户端与虚拟桌面所在宿主机的显示协议端口建立会话
7. 会话建立后，输入/画面/外设/音频开始双向流动；启用 SSO 时自动注入凭据，
   用户无感完成操作系统登录
8. 用户断开：池桌面按策略保留或立即回收；个人桌面保持运行等待下次重连

每一步都有设计原因。第 2 步让网关终结 TLS，是为了避免把内网端口暴露到公网，同时让接入层可以独立扩容和做多活；第 4 步把分配集中到代理，是为了把负载均衡、故障转移与容量策略收口到一个可审计的位置；第 6 步的会话虽然是业务网直连，但它建立在第 2 步已经完成的认证之上，业务网里跑的是协议流量而非裸认证流量。

#运维路径：从模板到桌面池

运维的核心杠杆是模板。标准路径是：

1. 制作黄金镜像：安装操作系统 → 安装虚拟化驱动（半虚拟化驱动与显示协议
   agent）→ 安装办公软件与安全软件 → 清理日志与临时文件 → 封装（系统准备）
   → 转为模板
2. 从模板生成桌面：完整克隆（每台独立完整盘）或链接克隆（所有桌面共享
   只读基线，差异写到自己层，节省空间与 IO）
3. 发布与分配：把克隆生成的桌面加入个人桌面分配名单，或组成桌面池
4. 更新：修改模板 → 重建池（池桌面）或做增量更新；个人桌面只能逐个打
   补丁或在维护窗口内迁移更新
5. 扩容：先扩存储与计算节点，再扩展池配额；故障预留资源不能挪用

关于链接克隆补充一个底层事实：共享基线镜像之所以能扛启动风暴，是因为几百台虚拟机读的是同一份只读数据，物理盘上只存一份，配合缓存命中率极高；而每次写入走写时复制（COW，Copy-on-Write），落在各自的差异层。系统盘因此是"读集中、写分散"，把它放在高 IOPS 介质上收益最大；用户数据盘则是读写都分散，与镜像盘分开规划。

#画质与带宽：一次价值选择

桌面协议里最核心的旋钮是图像编码策略。它在两个方向之间移动：

需要说清楚：这不是技术选型，是价值选择。没有任何一组参数能同时最优，你实际上是在回答"当带宽不够时，先牺牲谁的体验"。实践上比较有效的方式是按场景分层，而不是全局一套参数：

• 办公/文字类：优先保文字清晰度与滚动流畅度，这类负载对带宽的瞬时需求很尖。
• 研发类：终端与编辑器的重绘频繁，优先降低编码延迟，画质可以略放。
• CAD/图形类：优先保几何精度，但要接受带宽明显更高；同时"能不能用"往往取决于虚拟显卡的类型，而不是参数调优。
• 视频播放类：能重定向到客户端解码就不要走像素流。

把所有场景塞进一套参数，等于让最难的那个场景替所有人做决定。这往往是"部分人觉得清晰、部分人觉得卡"的真正原因。

#启动风暴：VDI 特有的时间现象

VDI 有一个别的系统很少有的现象：早上 8:30 到 9:00，几百台桌面同时启动。这不是容量问题——平时这些资源的利用率可能只有 20%。这是一个时间上的集中：所有请求挤在同一个窗口里，而每个请求都要求在有限时间内完成。

它给存储带来的压力尤其明显：几百台虚拟机同时读取系统盘镜像，是典型的随机读风暴。应对手段主要是三个层次：

1. 消除重复读：链接克隆/共享基线镜像，把"几百份读同一个镜像"变成"一份数据被共享读"。这是治本的一层，靠的是存储去重与缓存命中。
2. 分层放置：把系统盘放在高 IOPS 介质上，数据盘可以靠后。这是把随机读打到正确的介质上，避免镜像读风暴拖垮用户数据 IO。
3. 错峰与预热：错峰靠制度（分批上班）或靠技术（分批启动、预启动常驻池）。这是把时间上的集中摊平。

第三条里"预启动常驻池"值得单独说：它本质上是拿内存换时间——提前把一批桌面跑起来放着，用户登录时直接接管。代价是闲置资源，收益是登录时间从分钟级降到秒级。这也是一次价值选择，只是它发生在架构设计阶段而不是参数页面。

#规模化：并发之外还要留一层

容量规划上最常见的错误是：按"注册用户数 × 每用户资源"来算，然后加一个 N+1。实际上 VDI 的容量有三个不同的口径，混在一起就会算错：

设计应该按峰值并发，并且额外留出一层用于"故障与维护"：

• 一台宿主机下线维护时，它的桌面要能在别处起来——这需要预留，不是自动就有。
• 重建/迁移本身也要消耗资源。故障时的资源需求总是大于稳态需求，这两者不能用同一个数字。

这跟超融合场景讲的是同一件事：冗余不是"多一台机器"，是"多出来的那部分资源足够在故障时接管"。

#验证层：怎么确认做对了

VDI 项目最容易犯的错误是把"上线"当"完成"。真正的验收必须回答三个问题：延迟预算达标了吗、功能链路通了吗、容量扛得住真实峰值吗。

#把延迟预算在真实链路上测出来

原稿反复强调：经验区间是行业经验值，不是实测。真正的预算必须在你自己的链路上量出来。测量可以从粗到细分三步：

1. 端到端感知测量：在虚拟机桌面上打开一个毫秒计时器或 60 fps 的动画，用慢动作视频同时拍摄本地计时器与终端屏幕，比较两者相位差。这个值就是"输入到显示"的近似端到端延迟，也是与用户主观感受最相关的指标。
2. 网络分项：用 ping 与 traceroute 等网络工具测办公网到网关、网关到宿主机的往返时间（RTT，Round-Trip Time），并连续测一段时间记录抖动（抖动比平均延迟更影响输入跟手度）。
3. 分环节定位：用替换法——换一台已知性能好的终端，若延迟显著下降，瓶颈在客户端解码；在同一局域网和跨地域分别测，若差异巨大，瓶颈在网络；观察宿主机上虚拟机的 CPU 就绪时间与存储延迟，若偏高，瓶颈在服务端。

判定标准沿用前文的经验线：总量几十毫秒内用户基本不说卡，超过百毫秒必定说卡。测量记录建议按下面的格式留存，作为后续调参的对照基线（示例）：

测量日期：2026-xx-xx    终端型号：xxx（瘦客户端 / PC 客户端）
场景：同园区 / 跨地域（RTT = xx ms）
端到端延迟（动画相位差）：xx ms
其中  网络 RTT：xx ms    服务端渲染：xx ms    客户端解码：xx ms
判定：达标 / 未达标（超预算环节：______）

#功能链路验证清单

协议四个方向的流量都要实测，而不是"能连上就行"。建议逐项过一遍：

□ 键盘输入：连续快速输入无丢键，中文输入法候选框跟手
□ 鼠标/触控：拖拽窗口无残影，滚动跟手无跳帧
□ U 盘重定向：读写速度可接受，加密狗可被远端虚拟机识别
□ 打印机映射：从虚拟桌面提交打印任务正常输出
□ 摄像头/麦克风：视频会议场景双向音视频可用
□ 音频：声音无爆音、无明显回声（重定向模式下延迟低）
□ 视频播放：可触发客户端解码（协议统计中重定向命中，或客户端解码
   器占用明显上升）
□ 多屏与分辨率：扩展屏、缩放比例、DPI 感知符合预期
□ 断线重连：拔掉网线再恢复，会话恢复时间在可接受范围
□ 登录耗时：从点击登录到桌面完全可用，在预算内（预启动池应达秒级）

其中"视频重定向是否命中"是容易被忽略的一项：很多人看到画面流畅就认为没问题，但像素流下的流畅是靠带宽换来的，同一个场景换到带宽紧张的网络就会崩；而重定向命中的场景天然不吃带宽。

#容量与故障演练

容量验证不能用注册用户数，必须用峰值并发。方法是在测试窗口内模拟早高峰：批量登录 N 台桌面（N 等于预估峰值并发），观察四项指标——宿主机 CPU 与内存、存储 IOPS 与延迟、网络吞吐、登录排队时间。判断标准是：峰值并发下存储延迟与登录时间仍在预算内，且没有出现跨用户的服务端抖动。

故障演练至少要覆盖两件事：一是拔掉一台宿主机（或停服维护），观察其上的个人桌面能否在线迁移、池桌面能否在其他节点重建；二是验证预留容量确实够用——如果演练时发现桌面起不来，说明"预留"只是纸面上的数字。这些演练同时就是容量规划的验收。

#边界与坑：什么场景不该用，以及常见的失败模式

#集中管控与离线使用的固有矛盾

VDI 的集中管控能力（数据不落地、策略统一下发、补丁统一升级、日志集中审计）全部建立在同一个前提上：桌面运行在数据中心，终端只是一个显示窗口。这个前提直接推出了一个架构级矛盾——终端必须在线才能使用桌面，断网即黑屏。想离线可用，就必须把桌面或至少一部分数据放回本地，而本地一旦有数据，"数据不落地""统一升级"这些集中管控红利就开始瓦解。

这就是为什么"能不能离线"不是一个功能开关，而是一次架构取舍。现实中的折中路径有几种：网络双链路冗余（专线 + 4G 兜底）尽量降低断网概率；部分产品提供的离线缓存模式（客户端本地临时运行、联网后同步）适用于短时离线，但要接受数据留在终端的风险；如果业务对离线有硬性要求且时长以天计，集中式 VDI 可能根本不该选，应回到本地计算。

#与 RDS 会话桌面的区别

容易与 VDI 混淆的是 RDS（Remote Desktop Services，远程桌面服务）会话桌面。两者都提供"远程桌面"体验，但底层机制完全不同：

• VDI：每个用户一个独立、完整的操作系统实例（虚拟机），隔离性最强，应用按单用户环境开发即可兼容，还支持 Linux 等非 Windows 桌面；代价是每用户要付出一整套操作系统的内存与 CPU 开销，密度低、成本高。
• RDS：一台 Windows Server 上多用户共享同一个操作系统内核，每个用户只有一个会话（Session）；开销小、密度高、管理最集中；代价是应用必须支持多会话（很多桌面应用在 RDS 上无法正常运行）、隔离弱（一个会话的异常可能影响同机其他会话）、且只能提供 Windows Server 环境。

选择判断可以简化为：标准化、任务型的负载（浏览器、Office、固定业务系统）优先考虑 RDS，密度与成本优势明显；需要个性化桌面、图形应用、Linux、强隔离或应用兼容性敏感的场景，走 VDI。两者也可以在同一平台混合存在，按用户角色分配到不同类型的桌面——这本身就是"按场景分层"在架构层面的一次应用。

#与本地虚拟化的区别

另一类容易混淆的是本地虚拟化：在用户自己的电脑上用本地虚拟机软件（如本地的 Hypervisor 类产品或 Workstation 类产品）跑一个虚拟桌面。它的"虚拟"发生在终端本地，宿主机就是用户本人的机器。好处是无网络依赖、无数据中心成本、不受"断网黑屏"约束；但代价是集中管控能力几乎为零：数据仍留在终端、补丁与应用分发仍然分散、无法集中审计、远程访问能力弱。

看清这一点很重要：VDI 与本地虚拟化共享同一门虚拟化技术（隔离操作系统实例），却分属完全相反的管控架构。不要把"在本地电脑装了虚拟机"当成"做了云桌面"——它们的运维模型、安全模型与体验模型都不在一个维度。

#常见失败模式与排查路径

• 失败模式 1：一台机器做大文件解压，隔壁出现瞬断。 根因通常是服务端 CPU 或存储队列被占满，而不是网络。排查先看宿主机的就绪时间、存储延迟与队列深度，不要一上来就查网络。
• 失败模式 2：跨地域部署，怎么调都卡。 网络 RTT 已经吃掉延迟预算的大头，调参数无效，这是物理限制。排查先测 RTT；若超预算，只能改架构（分支部署缓存与接入网关、应用改造或换场景）。
• 失败模式 3：整体延迟高，换新终端立竿见影。 老客户端的解码与显示环节拖了后腿——它对应延迟预算表"解码 + 显示"那一栏。终端换代是预算表里最直接可兑现的一笔。
• 失败模式 4：一套参数走天下，部分用户说清晰、部分用户说卡。 根因是场景混用同一套编码策略。按场景分层配置，而不是全局调优。
• 失败模式 5：按注册用户数规划容量，早高峰登录集体变慢。 三个口径（注册/并发/峰值并发）被混用。按峰值并发设计，并保留故障预留。

#本文的边界

原稿对自己的边界说得很清楚，这里原样保留并补充一点：

• 本文没写具体产品的安装与配置步骤。版本差异大，请以手上版本的官方手册为准。
• 本文没写协议的技术细节对比。各家协议都在演进，做横向对比很容易过期，而且结论高度依赖客户端设备与网络环境。
• 延迟数字是行业经验值，不是实测；真正的预算必须在你自己的链路上量出来。
• 本文没写安全与合规部分（外设管控、水印、审计）。这是 VDI 里独立且分量很重的一块，值得单独一篇。

#收尾

回到开头那句话：桌面操作系统只是换了执行位置，并没有消失。理解这一点后，VDI 的所有设计问题都可以还原成同一类问题——在这条共享链路上，延迟预算怎么分、资源怎么共享、状态怎么组织、离线与集中怎么取舍。

原稿给了一句话收束，我认为是全文最好的概括：云桌面卖的从来不是"把 PC 搬到机房"，而是把每个人私有的延迟换成一条公共的延迟预算并重新分配。 做这个项目的工夫，八成花在"怎么分"上。

如果你的网络不可靠、对离线有硬性要求，或者负载全部是标准化的任务型办公，请先停下来想想 VDI 是不是最优解——RDS 和本地计算也是选项。如果决定要走 VDI，下一步不是选协议，而是先在自己的链路上把延迟预算量出来，再谈架构与参数。