机械的细节不一定让我们感兴趣，但问一下，你就会收到亲爱的读者。今天，我们将在 GerbilMagnus 的带领下带领读者了解我们 Wi-Fi 测试过程的幕后故事——我们还将在此过程中加入一些理论和实践。如果您想在家中尝试我们的方法，请事先了解您不必复制我们的整个测试设置即可开始为自己查看有用的结果。但是，如果您想让 最新最好的网状装备通过挑战，我们绝对会在完成之前涵盖从上到下的所有内容。
为什么我们运行复杂的测试
大多数专业的 Wi-Fi 测试只不过是简单的 Internet 速度测试——设置路由器或网状网络套件，将笔记本电脑放下 10 英尺远，然后让我们进行测试。这里的想法是近距离的最高最高速度也将转化为其他任何地方的最佳性能。
不幸的是，事情通常不会这样。您真正衡量的只是在最佳范围内从一台设备进行单次下载并且没有障碍物的速度——这通常不会让现实世界的用户感到沮丧。当你对你的 Wi-Fi 感到生气时，很少是因为下载速度不够快——更常见的问题是它表现得“不稳定”，点击链接会导致浏览器屏幕空白时间足够长你想知道是否应该点击刷新，或者关闭浏览器再试一次，或者什么。
我们的 Wi-Fi 评测背后的驱动力是准确衡量真实世界的用户体验。如果您接受我们的假设——对点击的缓慢响应是最常见的痛点——那就意味着您不想测量速度。您想测量延迟——特别是 应用延迟，而不是网络延迟。(应用程序延迟是指您的应用程序执行您要求的操作所需的时间，它是网络延迟和吞吐量的函数。)
我们在 Wi-Fi 上投入的最具挑战性的工作负载通常就是我们一开始所说的：Web 浏览。当您单击链接以查看“网页”时，您真正下载的不是单个页面——它通常是由数十个甚至数百个独立资源组成的集合，这些资源的大小各不相同，并且通常分布在多个域中。在浏览器可以直观地呈现页面之前，您需要大部分(如果不是全部)这些资源来完成下载。
如果这些元素中的一个或多个需要很长时间才能下载 - 或者停止并没有下载 - 你会盯着一个空白或只有部分呈现的网页想知道发生了什么。因此，为了获得真实的用户体验概念，我们的测试工作负载 还需要依赖于多个元素，其应用延迟定义为这些元素中的最后一个到达所需的时间。
流媒体视频是满足典型用户 Wi-Fi 需求的另一个重要组成部分。用户希望将 Netflix、Hulu、YouTube 等流式传输到 Roku 或 Amazon Fire Sticks 等机顶盒、智能电视、手机、平板电脑和笔记本电脑。在大多数情况下，流媒体工作负载本身并不困难——流媒体服务保持深度缓冲区以消除不规则性并补偿低吞吐量时期。然而，流媒体给网络的其余部分带来了持续的负载——这很快就会导致我们刚刚谈到的“网页停滞”的痛点。
Wi-Fi 延迟是最差的 ping，而不是最好的
如果您在有大院子的空房子中设置一个简单、廉价的 Wi-Fi 路由器并从笔记本电脑 ping 它，您将不会看到可怕的延迟时间。如果笔记本电脑处于非常好的位置，您可能会收到低至 2 毫秒(毫秒)的 ping。从房子里更远的地方，在墙壁的另一侧，您可能会开始看到延迟高达 50 毫秒。
这已经足够让玩家眼皮一跳了，但在浏览网站方面，听起来还不错——毕竟人类的平均反应时间超过250 毫秒。这里的问题是“低至”2ms 的 ping 很可能在 10 个链中有一两个比这高得多——对于理想条件下的笔记本电脑，10 个 ping 的最高值可能是 35ms。对于房子另一边的一个，它可能是 90 毫秒或更糟。
我们在这里关心的 ping 是 10 个或更多中最差的ping，而不是最低甚至中位数。由于获取网页意味着同时请求数十或数百个资源，并且我们绑定了最慢的一个返回，如果第十个慢得像糖蜜，那么其中的九个多快并不重要—— 糟糕的ping 是我们的一个向上。
但到目前为止，我们仍然只是谈论一个设备与空房子中的 Wi-Fi 接入点通信，没有竞争。这也不太现实。在现实世界中，同一个网络上可能有几十个设备——而且在同一个频道、邻居的房子或公寓中，在“听不到”的范围内可能还有几十个设备。每当他们中的一个说话时，其余的人都必须闭嘴等待轮到他们。
标签：
免责声明：本文由用户上传，如有侵权请联系删除！