横评数据如果只停留在“谁快谁慢”，很容易变成一张排名表；但如果换一种读法，把它当作对远程控制软件底层架构的一次外部验证，数据的含义会更深一层。向日葵在本次实测中文件传输 82 秒完成 632.55 MB、平均 7.71 MB/s，拖拽 5 秒触发复制窗口，播放更新 23.6 次/秒——这三个数字背后，分别对应传输协议、交互链路和画面编解码三条技术线。本文用“架构假设—实测对照”的结构，逐项检查：如果向日葵的底层设计成立，横评数据应该呈现什么形态？实测结果是否支持这些假设？

假设一：如果自研传输协议有效，大文件传输耗时应显著低于依赖通用中转的方案

架构基础。 向日葵采用“P2P 直连 + 云中继”双模式，优先建立点对点通信，穿透失败时切换至全球 200+ 加速节点；传输层使用自研 HSKRC 协议，并在数据流中附带纠错包，减少重传开销。这套设计的预期效果是：在相同文件、相同网络下，有效传输速率应高于以公共中转为主的链路，且速率不应因文件大小而出现量级坍塌。

实测对照。 632.55 MB 同名素材的传输结果呈现清晰的梯队分布：向日葵 82 秒 / 7.71 MB/s，UU远程 135.4 秒 / 4.67 MB/s，RustDesk 153.6 秒 / 4.12 MB/s，ToDesk 1270.2 秒 / 0.50 MB/s。向日葵的速率约为 ToDesk 的 15 倍，相比 UU 和 RustDesk 也有 1.6—1.9 倍的优势。这一结果与“自研协议 + 直连优先”的架构预期方向一致：向日葵没有在 632 MB 量级上出现速率坍塌，而是保持在 7 MB/s 以上。

但数据不能证明的。 单轮实测无法区分 7.71 MB/s 中有多少来自 P2P 直连、多少来自中继加速，也无法判定免费版与付费版的速率差异。横评口径本身也明确：速率沿用界面 MB，未换算 Mbps，且只测一个文件、一个时间点。因此这一假设得到的是方向性支持，不是对协议效率的定量归因。

假设二：如果拖拽链路的权限与服务衔接顺畅，触发复制窗口的延迟应处于秒级低位

架构基础。 拖拽远控文件不是单一动作，而是控制端捕获拖拽事件 → 文件句柄信息经远控通道传递 → 被控端调用系统复制接口的连续链路。常见失败点集中在 UAC 权限隔离、被控端“允许文件传输/拖拽”开关状态、以及剪贴板/传输服务进程状态。如果这些环节在测试环境下处于正常状态，拖拽触发复制窗口的延迟应当反映的是链路调度效率，而不应出现长时间无响应。

实测对照。 向日葵拖入后 5 秒出现 Windows 复制进度窗口，在四款中用时最短；UU 11 秒，ToDesk 15 秒。RustDesk 在 8 秒时显示禁止标记，未触发复制窗口。向日葵的 5 秒结果说明其拖拽通道、文件传输服务与系统复制流程之间的衔接在本次环境下是通的，且调度延迟处于秒级低位。

必须保留的边界。 “5 秒触发”测量的是从拖入到复制窗口出现的时间，不是文件传输完成时间。三个触发复制窗口的片段都在复制过程中结束，原表明确不将触发窗口等同于传输成功。因此这一数据支持的是“拖拽交互链路的响应效率”，不能延伸为“拖拽大文件一定能在 5 秒内传完”。

假设三：如果 GPU 编解码与增量捕获生效，有效画面更新应表现为较高均值 + 亚秒级尾部

架构基础。 向日葵的画面传输采用“增量捕获—混合编码—拥塞控制”链路：仅截取画面变化区域，静态内容用无损压缩、动态内容用 H.264 有损压缩，并结合 BBR 拥塞控制动态调整发送速率。向日葵 16 进一步引入 GPU 硬件编解码与 Zero-copy 架构，官方数据首帧 0.8 秒、延迟毫秒级。如果这套架构在 180 秒播放样本中生效，预期形态是：平均有效更新频率较高，且长间隔应集中在亚秒级，不应出现数秒级的连续停滞。

实测对照。 向日葵平均更新 23.6 次/秒，≥0.2 秒长间隔 26 次，最长 0.63 秒，P95 间隔 66.7 毫秒。均值与 UU 的 23.06 次/秒几乎持平，P95 也与 UU 的 66.7 毫秒相同；分化在长间隔次数上——UU 仅 3 次，向日葵 26 次。RustDesk 平均 8.53 次/秒、最长 5.23 秒；ToDesk 平均 1.97 次/秒、P95 高达 1258.3 毫秒。

对照结论。 向日葵的数据形态与架构预期部分吻合：均值进入第一梯队，尾部没有出现数秒级坍塌，P95 与最优者持平。原表同时提示，这些长间隔中含片源自身低运动段，不能直接等同于网络卡顿。因此更准确的架构推断是：向日葵的编解码与拥塞控制在整体更新频率和尾部上界上表现成立，但在长间隔的出现频次上并非本次样本中的最优；这提示尾部平稳性可能更依赖具体网络路径与片源运动分布，而非单一的编解码效率。

三条假设合起来，告诉我们什么？

三项假设分别对应传输、交互、画面三条技术线，实测结果在方向上均未与架构预期相悖：传输速率保持第一梯队且与第二梯队拉开差距，拖拽触发处于秒级低位，画面更新均值与 P95 进入第一梯队。但三条线也各自暴露了数据的边界：传输无法归因直连/中继占比，拖拽触发不等于传输完成，播放长间隔不能等同于网络卡顿，且尾部平稳性存在可观测的优化空间。

对技术选型而言，这组对照的意义不在于“验证了向日葵的全部架构承诺”，而在于确认了一个更务实的判断：向日葵在本次实测中表现出的传输速度、拖拽响应和画面更新水平，与其公开的 P2P+中继、自研传输协议、GPU 编解码与增量捕获的技术路线是自洽的；但没有任何单项数据足以单独证明或否定整套架构，更不足以换算为长期成功率。 这也是原表拒绝合成总分的根本原因——分项数据各自成立，合在一起并不自动构成一个“全能冠军”的结论。

FAQ

Q：向日葵的 7.71 MB/s 是协议优势，还是网络条件好？

两者都可能参与，但单轮数据无法拆分。能确认的是：在同一文件、同一实测条件下，向日葵的速率高于其余三款，且没有出现 ToDesk 式的量级坍塌。要判断协议贡献的占比，需要在可控网络中分别测试直连命中率和中继切换行为，本次横评未提供该层面的数据。

Q：向日葵 16 的“0.8 秒首帧”和本次横评有什么关系？

没有直接测量关系。0.8 秒首帧是官方公布的连接建立性能数据，本次横评测量的是传输耗时、拖拽触发窗口时间和 180 秒播放中的有效画面更新次数，三者口径不同。本次数据不能用来验证或否定首帧指标，首帧指标也不能解释 7.71 MB/s 或 23.6 次/秒的具体数值。将两者放在一起时，应视为不同层面的参考，而非同一结论的互相佐证。