为什么丢包需要单独测试
您在互联网上发送的所有内容都会被拆分成小数据包。当其中一部分丢失时，网页照样能加载，下载也照样能完成，因为基于 TCP 的应用只需重新请求丢失的部分。而游戏、语音聊天和视频通话等不起，只能继续处理下一个数据包。结果就是对手"瞬移"、话语被吞掉或视频画面卡住。丢包测试能让普通网速测试所掩盖的问题显现出来。
测量原理
测试会在您的浏览器和您选择的测试服务器之间建立一条 WebRTC 数据通道。该通道配置为无序传输且不重传（maxRetransmits: 0），因此丢失的数据包永远不会被重发。这与 UDP 的行为非常接近，而大多数游戏和 VoIP 应用使用的正是 UDP。由于连接通过服务器自有的 TURN 服务中继，即使在严格的 NAT 之后以及许多企业网络中也能正常工作。
每个数据包都带有序列号。服务器会立即回传每个数据包，并在测试结束时发回它收到的 ID 列表。您的浏览器会将该列表与自己发送的和收到回传的数据包进行比对：
- 从未到达服务器的数据包计为上传丢包。
- 到达了服务器但没有返回的数据包计为下载丢包。
- 虽然返回了、但到得太晚已无用处的数据包标记为迟到。
- 乱序和重复的数据包分别单独计数。
选择合适的设置
数据包大小、频率和时长决定了测试模拟的流量类型。默认设置适合大多数人，但如果您在排查某个具体问题，可以尝试以下配置：
- 游戏：64–128 字节，每秒 60–100 个数据包，1–2 分钟。
- 语音通话：160–200 字节，每秒 50 个数据包，1 分钟。
- 大数据包：1000–1200 字节，每秒 20–50 个数据包。
- 长时间监测：低频率，5 分钟。
如果大数据包丢包增加而小数据包没有，请检查 MTU 设置或线路的容量限制。如果短时间测试正常，而长时间测试偶尔出现突发丢包，问题很可能是间歇性的：Wi-Fi 干扰、路由器过热或晚间网络拥塞。
分方向丢包说明了什么
了解数据包在哪个方向丢失，是判断该由谁来解决问题的最快方法。家庭内部的问题，例如 Wi-Fi 信号弱或云备份占满上行带宽，通常会造成上传丢包。下载丢包则更多指向运营商网络拥塞、DSL 或有线电视宽带的线路质量，或通往服务器路径上某个拥塞的节点。如果两个方向都有丢包，请先检查设备与路由器之间的连接，再检查路由器与外部线路之间的连接。
抖动、MOS 和连接评级
丢包绝不应孤立地评判。抖动（jitter）即相邻往返时间之差的平均绝对值，反映延迟的不稳定程度。高抖动会迫使应用进行缓冲，而在缓冲播放完之后才到达的数据包实际上等同于丢失。MOS 评分采用简化的 ITU-T G.107 E 模型，综合延迟、抖动和丢包来估计语音通话的听感：4 分及以上为良好，低于 3.5 分则表示质量明显下降。A–F 评级和稳定性百分比则将这一切汇总为一个结论。
缩小问题范围
- 在同一台设备上先通过 Wi-Fi 测试，再通过网线测试。如果差异很大，问题就出在您的无线网络。
- 换一个服务器位置重新测试。如果只有某一台服务器出现丢包，问题就在那条线路上。
- 早上测一次，晚上再测一次。只在高峰时段出现的丢包说明是网络容量问题。
- 将结果下载为 CSV 或 JSON，必要时附在报修工单中。
如需快速全面检查，请使用首页上的 ping 测试。如果某款游戏卡顿，可以在 Valorant ping 测试等页面比较各区域的延迟。