2011-06-09 71 views
11

我必须根据他/她的连接速度对发送给客户端的内容权重做出动态决定。一些猜测客户端连接速度的方法

也就是说:如果客户端使用3G(或更慢)连接的移动设备,我会向他/她发送一个轻量级内容。如果他/她正在使用WiFi或更快的连接,我会向他/她发送完整的内容。

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

如果我尝试使用<meta>标记或Javascript document.location重新加载页面,则会发生同样的情况。

有什么方法可以发现或测量客户端连接的速度,或者他/她是否使用3G或WiFi等,它可以在微型浏览器上工作(也就是说,我可以通过迷你浏览器识别慢速连接)?

+0

测量速度可以通过javascript或flash(或类似的客户端技术)下载一个特定的文件并计算需要多少时间。但有一个主要的缩写,确保您需要至少1秒的时间来测量(速度是每个时间单位的数据),这实际上会延迟1秒的加载时间。您需要娱乐用户,直到您测量速度,在大多数情况下,实际上并不是用户在您的网站上提供的速度。此外,为了做出准确的测量,您可能需要更多时间。 – venimus 2011-06-23 17:26:14

回答

2

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

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

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

仍然应该提供一个选项,以轻量级和完整内容之间切换,因为您的猜测可能是错误的。

+0

即使我可以检测到客户端是手机,我无法检测到它是使用快速还是慢速连接 - 这就是问题所在。无论如何,你提供一个选项开关是完全正确的(我已经在另一个项目中这样做了)。 – 2011-06-23 13:16:24

+1

我认为把用户放在控制之中是最好的选择。如果您检测到移动浏览器,请提供“精简版”版本,并为用户提供一种轻松交换所获取版本的方法。 – 2011-06-23 21:18:08

+0

@Hugh Brackett:这就是我的意思。你不能假设连接速度在整个会话期间都是恒定的。如果你使用WiFi,用户可以远离热点,速度会下降。或者如果有人在浏览会话期间通过洪流开始下载大量数据呢? – ayckoster 2011-06-23 21:59:29

0

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

+0

对不起,但我看不到我怎么能“总是发现客户端的连接类型”。你能给一个Javascript的例子吗? – 2011-06-22 01:34:19

6

这是一个很好的问题。我以前没有运行任何技术来估算浏览器的客户端速度。不过,我确实有一个想法。我没有把这个想法花费几分钟,但希望它能给你一些想法。另外,请原谅我的详细程度:

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

因此,您需要区分延迟和吞吐量。假设客户端发送一个时间戳(让我们称之为“A”)与每个HTTP请求和服务器简单地回声。然后,客户可以用当前时间减去返回的时间戳,以估计请求进行往返的时间。这一次包括几乎所有事情,包括网络延迟,以及服务器完全接收您的请求所用的时间。

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

读完响应后,响应主体中的数据量除以新的客户端时间“C”减去之前的客户端时间“B”即为吞吐量的近似值。例如,假设C-B = 100ms,并且你已经读取了100kb的数据,那么你的吞吐量是10kb/s。

再一次,移动客户端连接很容易出错,并且随着时间的推移有强度变化的趋势。因此,你可能不想测试吞吐量一次。实际上,您也可以衡量每个响应的吞吐量,并保持客户端吞吐量的moving average。这样可以减少一次请求中吞吐量异常恶化导致客户端质量降级的可能性,反之亦然。

如果此方法有效,那么您只需确定策略是决定客户端获得什么内容。例如,您可以从“低质量”模式开始,然后如果客户端在一段时间内具有足够的吞吐量,请将其升级到高质量内容。然后,如果他们的吞吐量回落,则将其降级为低质量。

编辑:澄清了一些事情,并增加了吞吐量的例子。

+0

你的解释非常有趣,但我不确定它是“代理证明”。我还没有测试你的算法,但我想它会在迷你浏览器的代理上注册客户端时间戳,而不是真正的移动设备时间戳。代理将读取整个页面(并采取措施),处理它(通过压缩,降级图像质量等),然后将结果发送到移动设备。在这种情况下,吞吐量和延迟将相对于代理而不是设备。如果你有不同的想法,请告诉我如何。 – 2011-06-22 02:07:47

+0

你可能是对的 - 我不确定在代理的情况下你可以做多少事情。您可以将总请求+响应大小除以总往返时间作为吞吐量的近似值。这可能会让你足够接近。 – Tom 2011-06-23 23:39:21

+0

+1:您的答案可以在桌面浏览器中使用。谢谢! – 2011-06-24 07:16:32

0

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

如何为请求内容的URL的简单ajax查询?只需将第一个请求的时间服务器端用客户端存储在某处的文件或数据库的IP地址记录下来,然后将其与来自客户端JavaScript的请求时间进行比较,并在比较两次选择后提供一个URL一个任意的“快”或“慢”时间限制,并提供适当速度内容的URL。

4

第一件事:通过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测量。获取当前时间,发送请求,而不是时间收到响应时间。请求本身应该是相同的大小,所以发送请求的开销只是延迟的一部分。尽管如此,你可能会想要使用不同的主机来击败持久连接。要么这样做,要么将您的服务器配置为拒绝持久连接,但仅限于测试文件。

我想我实际上会滥用延迟一词,它包括所有常量开销的时间(例如,发送请求)。那么,它想要接收有效负载的第一个字节的延迟。