Question

我必须根据他/她的连接速度对内容权重进行动态决策。

即：如果客户端使用的是具有3G（或更慢）连接的移动设备，我会向他/她发送轻量级内容。如果他/她使用WiFi或更快的连接，我会向他/她发送完整的内容。

我尝试测量重新加载之间的时间，向客户端发送标头Location: myurl.com（有关客户端的一些信息以识别它）。这适用于桌面浏览器和一些完整的移动浏览器（如Obigo），但它不适用于迷你（代理）浏览器，如Opera Mini或UCWeb。这些浏览器返回我的服务器和代理服务器之间的连接时间，而不是移动设备。

如果我尝试使用<meta>代码或Javascript document.location重新加载页面，也会出现相同情况。

有没有办法发现或衡量客户端连接的速度，或者他/她是否正在使用3G或WiFi等，这适用于迷你浏览器（即，我可以识别通过迷你浏览器的慢速连接）？

Answer 1

这是一个很好的问题。我之前没有尝试过从浏览器估算客户端速度的任何技术。不过，我确实有一个想法;我没有花太多时间考虑这个，但希望它会给你一些想法。另外，请原谅我的冗长：

首先，在处理客户端 - 服务器性能时需要考虑两件事：吞吐量和延迟。通常，与桌面客户端相比，移动客户端将具有低带宽（因此低吞吐量）。此外，移动客户端的连接可能更容易出错，因此具有更高的延迟。但是，在我有限的经验中，高延迟并不意味着低吞吐量。相反，低延迟并不意味着高吞吐量。

因此，可能需要区分延迟和吞吐量。假设客户端发送一个时间戳（让我们称之为“A”）与每个HTTP请求，服务器只是回复它。然后，客户端可以用当前时间减去此返回的时间戳，以估计进行往返的请求所花费的时间。这一次几乎包括所有内容，包括网络延迟，以及服务器完全接收请求所花费的时间。

现在，假设服务器在发送整个响应主体之前首先在响应头中发回时间戳“A”。还假设您可以逐步读取服务器的响应（例如，非阻塞IO。有多种方法可以执行此操作。）这意味着您可以在读取服务器响应之前获取回显时间戳。此时，客户端时间“B”减去请求时间戳“A”是您的延迟的近似值。保存这个，以及客户端时间“B”。

一旦读完响应，响应正文中的数据量除以新客户端时间“C”减去之前的客户端时间“B”就是吞吐量的近似值。例如，假设C - B = 100ms，并且您已读取100kb数据，那么您的吞吐量为10kb / s。

移动客户端连接再次容易出错，并且随着时间的推移趋势会发生变化。因此，您可能不希望一次测试吞吐量。实际上，您还可以衡量每个响应的吞吐量，并保持客户端吞吐量的moving average。这将降低一个请求上异常错误的吞吐量导致客户端质量降级的可能性，反之亦然。

如果此方法有效，那么您需要做的就是决定用于决定客户端获取内容的策略。例如，您可以从“低质量”模式开始，然后如果客户端在一段时间内具有足够的吞吐量，则将它们升级为高质量内容。然后，如果它们的吞吐量降低，则将它们降级为低质量。

编辑：澄清了一些事情并增加了吞吐量示例。

Answer 2

首先：运行SSL（HTTPS）将避免代理废话的批次。它还会阻止像压缩这样的东西（可能会使HTML，CSS等加载更快，但对已经压缩的数据无效）。

加载页面的时间是延迟 +（带宽×大小）。即使延迟未知，测量小文件和大文件也可以为您提供带宽：

Let L be latency, B be bandwidth, both unknown.
Let t₁ and t₂ be the measured download times.
In this example, the two sizes are 128k and 256k.

t₁ = L + B × 128                             // sure would be nice if SO had Τεχ
t₂ = L + B × 256
t₂ - t₁ = (L + B × 256) - (L + B × 128)
        = L + B × 256 - L - B × 128
        = 256(B) - 128(B)
        = 128(B)

因此，您可以看到，如果您将时间差除以页面大小的差异，则可以获得带宽。由于延迟和带宽不恒定，进行单次测量可能会产生奇怪的结果。重复几次（并抛出异常值和荒谬的[例如，负值]）将收敛于真正的平均带宽。

您可以使用任何AJAX框架在后台轻松地使用JavaScript进行这些测量。获取当前时间，发送请求，而不是收到响应时的时钟时间。请求本身应该是相同的大小，因此发送请求的开销只是延迟的一部分。您可能希望使用不同的主机，以打败持久连接。或者将服务器配置为拒绝持久连接，但仅限于测试文件。

我想我实际上是在滥用延迟这个词，它包括所有持续开销的时间（例如，发送请求）。好吧，它希望接收有效载荷的第一个字节的延迟。

Answer 3

我认为你不应该测量速度或吞吐量。

第一个猜测可能是客户端的浏览器。计算机有许多不同的浏览器，但它们通常与移动设备的浏览器不同。

很容易检查用户使用的浏览器。

你应该提供一个在轻量级和全部内容之间切换的选项，因为猜测可能是错误的。

Answer 4

是的，我知道答复是。

我之所以能够恢复这种古老的讨论，有两个方面：

首先，技术发生了变化，而9年前可能并不容易。现在

其次，我有一个客户的网站可以追溯到20年前，实际上几乎没有变化。他拒绝提供（非常便宜）重写的提议，因为它可以工作并且非常快速。它只有几页，内容仍然有意义（他的确要求我删除传真号码！）他的观点是“如果还没有破裂，就不要修复它”。在拨号调制解调器连接时代，它是用纯HTML编写的，用于640像素宽的屏幕。 Some still use them 固定的屏幕宽度意味着它可以在手机/平板电脑上使用，尤其是在横向模式下。在大屏幕上看起来还不错，因为有平铺的背景。

我运行了Google pagespeed checker，它的得分仅为99％，所以我调整了htaccess文件，现在它的得分为100％。我们大多被快速宽带所宠坏，但是一些农村用户的速度却令人失望。那些家伙到达一个数兆字节的页面时不会高兴。我以为也许可以在另一个网站上尝试一个实验。如果我能检测到该用户正在拨号连接，那么我可以看到如果为这些用户提供一种简单的轻量级替代方案会发生什么情况。

Answer 5

这是您可以在客户端发现的吗？如果您需要绕过代理，那么您始终可以在客户端发现连接类型并将其发回。另一种方法是通过一些脚本机制在客户端下载文件，记录每秒的字节数，并将该信息返回给服务器端。

Answer 6

比较来自同一客户端的两个请求的服务器端时间。

请求内容网址的简单ajax查询怎么样？只需将客户端的ip存储在第一个请求的时间服务器端（文件或数据库），然后将其与客户端javascript请求的时间进行比较，并在比较两次选择后提供URL任意“快速”或“慢”时间限制，并提供适当速度内容的URL。

一些猜测客户端连接速度的方法

6 个答案: