5

有没有一种方法可以在 Web 应用程序上指示客户端当前的网络质量（某种条形，类似于手机上的 n/w 质量条）？

我们的一个处理数据传输的网络应用程序由于与客户的网络问题而出现大多数传输失败，而客户显然对此一无所知。客户不断报告故障，而实际问题在于他们的 n/w 连接，我正在寻找一种方法，可以在他们使用应用程序时向他们指示相同（在我的 Web 应用程序中）。

我知道还有其他工具可以进行调查，但外行用户设置没有它们（至少我们的用户）。

谢谢。

4

3 回答 3

2

一种方法是使用window.navigator.onLine例如：

if (navigator.onLine) {
  alert('online')
} else {
  alert('offline');
}

或捕获更改：

window.addEventListener("offline", function(e) {
  alert("offline");
}, false);

window.addEventListener("online", function(e) {
  alert("online");
}, false);

您可以取特定时间间隔的平均值，并开发一种算法来将连通性量化为 10%、50% 等......

您也可以只设置 AJAX 轮询并观察超时，但请注意不要过多地增加流量：

$.ajax({
  type: "GET",
  url: "yourserver.com",
  success: function(data){
    alert("Connection active!")
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
    if(textStatus == 'timeout') {
       alert('Connection seems dead!');
    }
  }
});
于 2013-01-18T19:46:41.830 回答
1

根据您传输数据的方式、一次传输多少以及传输频率，这里有一些假设。

我将首先假设您正在发出 XHR 请求，因为这确实是可靠地衡量我们需要的指标的唯一方法。

至于多少，我希望你不是一次发送兆字节。这使得测量响应时间变得更加困难（因为网络条件在大请求的整个生命周期内可能会发生变化）。此外，如果用户使用某种代理，超大的请求可能会被代理抛出。假设小于 1 MB。

最后，如果您每 5 分钟只发送一次数据，我们显然不会有太多的性能测量数据可供使用。

话虽如此，我会通过测量每个请求的总请求时间并计算失败次数来解决这个问题。就像是：

var recentResults = [], history = 90000;
function sendData() {
    var start = Date.now(); // remember when we started this request
    $.post('/some/api', { some: 'data' }, function(r) {
        recentResults.push({start:start, end:Date.now() - start}); // record how long it took (ms)
    }).fail(function() {
        recentResults.push({start:start, end:null}); // record a failure
    });
}

setInterval(function() {
    var now = Date.now();
    if (recentResults.length > 0) while (now - recentResults[0].start > history) {
        recentResults.shift(); // prune old data
    }


    var sum;
    for (var i = 0, r; i < recentResults.length; r=recentResults[i++]) {
        if (r.end == null) sum += 50000;
        else sum += r.end;
    }

    var movingAverage = sum / recentResults.length;

    // use movingAverage to calculate the overall connection quality

}, 1000);

您将不得不根据反复试验调整我在这里使用的几个值。

  • history是将请求保持在移动平均值中的时间长度（以毫秒为单位）。如果您经常提出请求，则可以将其关闭。如果您每分钟只发出一个请求，则可能需要增加它。
  • 我任意将完全失败指定为相当于 50 秒的响应时间。发生故障的原因有很多，包括暂时的网络问题（例如 WiFi 信号差）和服务器错误（HTTP 500）。您可能希望根据实际场景中的测试来调整它。
  • 我每秒对响应时间数据进行采样。您可以更频繁地执行此操作以获得更灵敏的信号计，但您显然会消耗更多的 CPU 周期来执行此操作。如果您的应用程序在移动设备上运行，请务必小心。

您必须进行实际测试以确定“好”与“差”的平均响应时间是什么样的。

于 2013-01-19T01:43:08.427 回答
0

看看这个http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/

这提供了一个关于新的 W3c 导航计时接口的想法。Chrome/ffox/IE 已经有了

于 2013-02-08T19:00:49.693 回答