Windows
macOS
Android
iOS
实时应用出现卡顿，不一定是带宽不足。在线课堂、远程桌面、语音协作或多人会议中，短时延迟尖峰、连续丢包、连接重建和终端负载，都可能造成画面停顿或声音断续。要判断问题来自哪里，可以用一套可复核的实时应用连接质量评分方法，把网络指标和实际体验放在同一张表里。
评分的重点不是得到一个看似精确的分数，而是找出最影响当前场景的短板。下面的六项检查，应在同一设备、同一网络和相近使用时段完成，避免把不同条件下的数据混在一起。
先查这6项：从网络到应用逐层定位
1. 往返延迟
延迟可用往返时间 RTT 表示，即数据发出后得到响应所需的时间。互动操作通常更在意稳定性：约 20 至 60 毫秒一般较顺畅，超过 100 毫秒后，远程操作和对话衔接更容易产生迟滞；具体感受还取决于服务器距离、应用协议和操作类型。不要只记录最低值，应同时记录中位数和峰值。
2. 抖动
抖动是连续数据包到达间隔的变化。平均延迟不高但抖动明显时，语音会出现断续，视频帧也可能等待重排。可按 1 秒或 5 秒窗口记录一段时间内的延迟波动，观察是否在高峰时段集中出现。对语音和实时画面，稳定的延迟通常比偶尔很低、偶尔突然升高更有价值。
3. 丢包率与突发丢包
丢包率表示发送的数据包中未能正常到达的比例。实时应用通常难以容忍持续丢包，尤其是丢包连续发生时，恢复机制可能来不及补齐内容。排查时要区分均匀丢包和突发丢包：前者可能表现为持续降质，后者则更容易直接造成几秒钟卡顿。记录上行和下行两个方向，不能只测下载方向。
4. 可用吞吐量
吞吐量是应用实际拿到的传输能力，不等同于套餐标称速率。多人同时使用、后台同步、云盘上传或系统更新，都可能占用上行资源。实时应用对上行尤其敏感，摄像头画面、屏幕共享和输入数据都要经过上行链路。测量时关闭无关流量，再在正常负载下复测，才能看出余量是否足够。
5. 连接建立与重连
有些卡顿并非传输过程中发生，而是域名解析、身份验证、加密握手或网络切换耗时过长。记录首次连接耗时、断线次数、每次重连时间和失败比例。若只有应用启动慢，重点检查解析和服务端响应；若运行数分钟后频繁重连，则应关注链路稳定性、会话保持和设备休眠策略。
6. 应用连续性
最终评分必须回到用户可感知的结果，例如音频是否连续、画面是否冻结、远程鼠标是否跟手、操作后状态是否及时更新。服务器排队、浏览器进程占用过高、编码器负载过满，也可能让网络指标正常而应用仍卡顿。因此要把卡顿次数、每次持续时间和发生时的设备资源一并记录。
一套可执行的评分流程
- 固定测试条件。选定一台终端、一个接入方式和一个目标服务，连续采集至少 10 至 15 分钟；再在业务高峰期重复一次。不要把家庭网络、公司网络和移动热点的数据直接合并。
- 建立原始记录。每 1 秒至 5 秒记录延迟、抖动、丢包率和吞吐量，同时标记连接建立、重连和实际卡顿发生的时间点。应用日志、系统资源监视器和网络工具应使用统一时钟。
- 转换为分项分数。可将每项指标换算为 0 至 100 分。比如延迟、抖动和丢包率越低分数越高，吞吐余量、连接成功率和应用连续性越高分数越高。超过业务可接受阈值的样本，可直接记为低分，而不是让少量好样本抵消严重异常。
- 设置场景权重。语音协作可提高抖动和丢包的权重；远程控制应提高延迟和应用连续性的权重；高清视频则要同时关注吞吐量和突发丢包。权重总和保持为 100%，并在报告中写明理由。
- 保留分项结果。总分只能用于排序和趋势观察。若总分为 82 分，但重连项仅 45 分，仍应优先处理重连问题，而不是认为整体连接合格。
一种便于解释的计算方式是：总分等于六项分数分别乘以对应权重后相加。建议同时展示最低分、异常样本比例和卡顿时间占比。这样既能比较不同地点或时段，也能避免平均分掩盖突发故障。
评分时最容易犯的四个误区
- 只看平均延迟。平均值可能掩盖少数严重尖峰，应同时查看中位数、较高分位值和时间序列。
- 用测速结果代替应用结果。测速服务器距离、协议和流量方向可能不同，测速高并不表示目标应用路径稳定。
- 只测下行。屏幕共享、视频上传和语音采集都依赖上行；上行拥塞时，下载测速仍可能看起来正常。
- 把所有问题归因于网络。若延迟和丢包正常，却出现画面冻结，应检查 CPU、内存、浏览器标签页、编码负载和服务端处理时间。
评分不是越复杂越好。对日常排障而言，能够重复采集、解释分项差异并对应到具体动作，比追求一个精确到小数点的总分更可靠。
如何把分数转成处理动作
| 主要异常 | 优先检查 | 适合的处理方向 |
|---|---|---|
| 延迟高且稳定 | 目标服务距离、路由路径、代理设置 | 比较不同接入地点或服务节点，减少不必要的中转 |
| 延迟偶发尖峰 | 高峰时段、后台上传、链路切换 | 暂停大流量任务，观察尖峰是否同步消失 |
| 丢包集中发生 | 接入设备、线路质量、拥塞时段 | 分开测试上行和下行，并对照应用卡顿时间 |
| 吞吐不足但网络稳定 | 并发设备、上行余量、应用码率 | 减少并发流量或降低画质、共享分辨率 |
| 网络正常却频繁卡顿 | 终端资源、浏览器、服务端处理 | 查看 CPU、内存和应用日志，区分网络等待与本地处理 |
常见问题
评分需要测试多长时间？
短测适合快速定位，通常 10 至 15 分钟可以发现明显异常；若问题只在晚间或多人使用时出现，应覆盖异常时段，并至少重复两次。
多少分可以认为连接合格？
不宜设定通用及格线。语音、视频、远程控制的容忍范围不同，建议先确定业务阈值，再观察总分和最低分是否同时达标。
为什么丢包率很低，仍然会卡？
少量突发丢包、抖动、重连、终端编码压力或服务端排队，都可能造成卡顿。应回看同一时间点的六项记录，而不是只看一个百分比。
应该优先优化哪一项？
优先处理与卡顿时间高度重合、且分项分数最低的指标。实时互动通常先看延迟、抖动和丢包；大画面传输再重点检查吞吐余量。
总之，可靠的实时应用连接质量评分方法，核心是统一条件、分项采集、保留时间序列，并把网络数据与实际体验对应起来。只有这样，评分才不只是一个数字，而能直接指导排查和优化。