webapp上的网络质量指示器

Question

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

我们的一个处理数据传输的web应用程序，大多数传输失败都是因为客户端的网络问题，而这些客户端显然不知道这一点。客户端不断报告失败，而实际问题是他们的n/w连接，我正在寻找一种方法，当他们使用应用程序时，可以向他们指示相同的(在我的web应用程序内)。

我知道有其他工具可以调查这一点，但外行用户设置没有这些工具(至少我们的用户没有)。

谢谢。

Answer 1

一种方法是使用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!');
    }
  }
});

Answer 2

这里有一些假设，基于您如何传输数据，一次传输多少数据，以及多长时间传输一次。

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

至于有多少，我希望你不是一次发送兆字节。这使得测量响应时间变得更加困难(因为网络条件在大型请求的生命周期中可能会有所不同)。此外，如果用户在某种类型的代理之后，过大的请求可能会被代理抛出。让我们假设小于1MB。

最后，如果您每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信号差)和服务器错误(HTTP500)。你可能想要根据真实场景中的测试来调整它。
• 我每秒都在采样响应时间数据。为了获得响应更灵敏的信号表，您可以更频繁地执行此操作，但这样做显然会消耗更多的CPU周期。如果您的应用程序在移动设备上运行，请非常小心。

您必须进行真实世界的测试，以确定“好”与“坏”的平均响应时间是什么样子。

Answer 3

请查看此http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/

这给出了一个关于新的W3c导航定时接口的想法。Chrome/ffox/IE已有