五端之间的双向互控：36 毫秒与 15 Mbps 的读法

双向互控的意思是两端都能发起、也都能被控，不存在只能看不能操作的一端。这句话在功能上成立，在手感上不成立：谁发起、控谁，会明显改变延迟体感与操作方式。下面先把三个读数各自的量法说清楚，再讲方向差异与组合对照。

36 毫秒量的是哪一段

连接延迟 36 毫秒，本站实测口径是发起连接到对端首帧落地：从点下连接、握手完成，到对端画面第一帧真正显示出来。它不包含你按下鼠标到对端响应的时间，那一段要另算，不能拿这个数字去推操作跟手程度。

本站的 36 毫秒自 2026-10-24 起累计 305 次采样并取中位，条件是两端同城、都在有线或稳定无线下、对端未进入省电模式。换成移动网络、跨运营商、或对端刚唤醒，读数会明显偏离这个中位值。

还有一条边界：36 毫秒是握手加首帧，不是全程恒定。连接建立之后的每一帧走的是码流通道，那一段的稳定性要看码流读数，两者不是一回事。

首帧落地不含操作响应那一段

把 36 毫秒当成按下多久有反应，是最常见的误读。它量到首帧落地为止，之后的每次输入走另一条通道，那一段取决于码流稳定度与对端处理，不在这个数里。

• 36 毫秒从点下连接起算，到对端首帧显示为止
• 按键到对端响应属另一段，要用操作类测试单独取
• 首帧落地只发生一次，连接建立后不再重复计入

305 次采样覆盖了哪些条件

采样条件写在读数旁边才有意义：两端同城、有线或稳定无线、对端未进入省电模式。换成移动网络或跨运营商，中位值会往上走，幅度取决于链路。

• 同城有线条件下取 36 毫秒，跨运营商不在这一口径内
• 对端进入省电模式会拉长首帧落地，读数需重新采样
• 采样自 2026-10-24 起累计 305 次、覆盖 8 天，取中位

15 Mbps 为什么要按平台分开取

码流 15 Mbps 由本站逐平台实测，不是平均带宽占用，而是按平台分开取的单向码流：每个平台单独取一次，量的是从一端发往另一端这一个方向的瞬时值。两个方向同时采会把读数叠在一起，数值翻倍且没有参考意义。

另一个容易读错的地方：画面定住后码流自然掉下来，静置时的读数会远低于 15 Mbps。峰值只描那一帧，不摊成持续值，所以既不能拿峰值当常态，也不能拿静置值当平均值，两个方向都错。

两个方向叠加为什么会翻倍

单向码流按平台分开取，一个平台一次，取从一端发往另一端那一侧。两个方向同时采会把两份流量叠进一个读数，数字翻倍，还看不出是哪一侧在吃带宽。

• 按平台分开取单向，15 Mbps 只对应一个方向的瞬时值
• 双向同时采会叠成两倍数值，不能当带宽占用报
• 哪一侧在编码就取哪一侧读数，方向写反结论就反

静置掉码流不等于连接变差

画面定住后编码器不再输出新帧，码流自然往下掉，属正常工作状态。15 Mbps 是峰值口径，不摊成整段的持续值；拿静置时的低读数判断画质，方向就错了。

• 静止画面上码流迅速下降，属编码器行为，不是链路故障
• 15 Mbps 是峰值口径，不能当整段连接的平均值
• 判断画质要看动起来的读数，静置值只说明没在传画面

文件互传 9.6 MB/s 的边界

两端互传文件的实测速率是 9.6 MB/s，条件是桌面端之间、同一局域网、单文件顺序传输。换成大量小文件会明显下降，因为每次建链的开销摊不薄；跨到移动端还要再受一层后台策略影响。

移动端传大文件有一个已知中断点：应用退到后台之后，系统会回收进程，传输随之中断，重连后要从头开始。要传完就保持前台，或者干脆换到桌面端发起。

9.6 MB/s 与 15 Mbps 不能换算成同一件事：前者是落盘速率，含两端读写开销；后者是编码码流，不含落盘。把两者相除得到的结论没有意义。

小文件为什么传不快

9.6 MB/s 的条件是桌面端之间、同一局域网、单文件顺序传输。换成几百个小文件，每次建链与落盘的开销摊不薄，总速率被拉到远低于这个读数。

• 单文件顺序传输取 9.6 MB/s，条件为同局域网两端桌面端
• 大量小文件时建链开销占比升高，总速率明显下降
• 跨到移动端再受一层后台策略影响，读数不能直接套

后台回收造成的中断点

移动端发起的传输有一个明确断点：应用退到后台，系统回收进程，传输当场中断，重连后从头开始。要传完就保持前台，或改由桌面端发起。

• 退到后台被回收时传输中断，已传部分不保留
• 重连后从头开始，条件为大文件且中途断过一次
• 桌面端发起时不受移动端后台策略影响，长传更稳

桌面控移动与移动控桌面不是一回事

方向差异集中在三处：输入设备、画面比例、以及谁承担编码。功能上对称，体验上不对称。

• 桌面控移动：输入端是完整键鼠，落点精确；对端是竖屏比例，横向内容被裁切，实际操作时要频繁滚动。
• 移动控桌面：输入端是触屏或外设，触屏落点误差大；对端是横屏宽幅，缩到手机屏上字小到看不清，只能靠缩放来回找。
• 编码侧：桌面端承担编码时余量充足，画面质量稳定；移动端承担编码时受发热与省电策略影响，连接久了码流会更早掉下来。
• 外设侧：移动端要接键鼠才能接近桌面手感，iOS 端还得先过 OTG 供电与实测 6.8 秒的识别这一关。

谁发起，谁承担编码

方向决定谁在编码：桌面端编码余量充足，画质能顶住；移动端编码受发热与省电策略压制，连久了码流更早掉下来。同样 36 毫秒，两种方向的持久性不同。

• 桌面端承担编码时余量充足，长时间连接画质波动小
• 移动端承担编码时受发热影响，连接久了码流先掉
• 方向反过来，输入端与编码端同时变化，体感不能互换

结论是分用途的：桌面控移动适合临时处理与查看，移动控桌面适合查看与轻量修改，两者都不适合长时间的重操作。把双向互控理解成"哪边都一样"，用起来会一直别扭。

六组常用组合的对照

五个平台两两互连，方向组合远多于实际会被用到的部分，本站取其中六组常用组合对照。表中首帧落地取本站 305 次采样的中位，六组共用同一个读数口径，差别体现在开连前要先满足的条件上。

六组共用中位，差别在最后一列

表里六组的首帧落地都写 36 毫秒，是采样把组间差异折进了中位，不代表六组一样。真正的差别在最后一列：条件不满足时，表现是连上了但画面不动。

• 六组共用 36 毫秒的中位口径，组间差异被中位吸收
• 授权缺一道时能连上但没有画面，症状与网络不通不同
• 版本不对齐会先出现卡顿，再去排查网络容易走弯路

六组的首帧落地读数落在同一个中位上，是本站的采样把组间差异折进了中位。要看组间差别，得看最后一列的前置条件，而不是这一列：条件不满足的组合，实际表现是连上了但画面不动。

三个读数怎么配合看

单看一个数字容易得出偏颇结论：36 毫秒小就以为全程跟手，15 Mbps 高就以为画质稳定，9.6 MB/s 快就以为传什么都快。三个数字量的是连接、编码、落盘三个阶段，各管一段。

1. 先看首帧落地

   决定点下连接之后要等多久。超过一定体感阈值就会觉得慢，但这一段只发生一次，不影响后续操作。

2. 再看单向码流

   决定画面质量与网络占用。按平台分开取，别把两个方向叠起来读；静置时它会自然掉下来。

3. 最后看落盘速率

   只在传文件时才有意义。桌面端之间 9.6 MB/s，跨到移动端要打折扣，还要防后台回收。

4. 按方向修正预期

   移动端发起时，先想一遍外设够不够用；桌面端发起时，先想一遍对端被控端是否允许常驻。

读数顺序反了会得出什么结论

先看码流再看首帧，容易把编码压力当成连接慢；只看落盘速率，会把文件传得快当成画面流畅。三个数各管一段，顺序错了结论就互相打架。

1. 先量首帧

   连接建立那一下的等待用 36 毫秒对齐；超过体感阈值的组合先解决授权与版本。

2. 再量码流

   按平台分开取单向，动起来再读；静置值低不算故障。

3. 最后量落盘

   只在传文件时读 9.6 MB/s，并确认发起端是桌面端。

五端版本对齐的检查顺序

跨版本连线出现卡顿时，先对齐版本再查网络：五端大版本一致最稳，条件不满足时卡顿属预期内。对齐后仍有问题，再去看授权、省电模式与链路。

• 先记录五端各自的大版本，不一致时优先升级再复测
• 版本对齐后仍卡顿，再查授权与后台常驻状态
• 两端都过了门槛仍有问题，按平台分别采样再对比

本页三组读数都由本站实测，只在这套对照机上成立，换机器要重取；移动网络、跨运营商、对端省电模式都会把 36 毫秒推高，把 15 Mbps 压低。