我正在寻找一种方法来区分客户端时钟和服务器时钟。
直到现在我尝试了以下方法。
收集:
问题是我们在到达服务器的请求和到达客户端的响应之间会出现未知的延迟。
以下是使用JavaScript和PHP的此方案的实现:
time.js
var request = new XMLHttpRequest();
request.onreadystatechange = readystatechangehandler;
request.open("POST", "http://www.example.com/sync.php", true);
request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
request.send("original=" + (new Date).getTime());
function readystatechangehandler() {
var returned = (new Date).getTime();
if (request.readyState === 4 && request.status === 200) {
var timestamp = request.responseText.split('|');
var original = + timestamp[0];
var receive = + timestamp[1];
var transmit = + timestamp[2];
var sending = receive - original;
var receiving = returned - transmit;
var roundtrip = sending + receiving;
var oneway = roundtrip / 2;
var difference = sending - oneway; // this is what you want
// so the server time will be client time + difference
}
}
Sync.php
<?php
$receive = round(microtime(true) * 1000);
echo $_POST["original"] . '|';
echo $receive . '|';
echo round(microtime(true) * 1000);
?>
即使采用这种方法,我也会得到50-500毫秒的错误。如果延迟很高,则误差会更大。
但我想知道一家名为“adtruth”的公司声称他们能够根据时钟时间区分设备。他们称之为“时差链接” 设备识别AdTruth风格的关键是其专利技术TDL,用于时间差分链接。虽然在数十亿个连接设备中可能有数千个具有相同配置,但没有两个设备的时钟设置为同一时间 - 至少,当你将其降低到毫秒时。 第41参数和AdTruth的创始人Ori Eisen说:“我们采用这些不同的时间戳并将它们与服务器主时钟进行比较。如果有任何疑问,TDL就是决胜局。”
http://www.admonsters.com/blog/adtruth-joins-w3c-qa-ori-eisen-founder-and-chief-innovation-officer
这是他们的“时间差异链接”专利的链接
答案 0 :(得分:2)
它实际上非常简单,首先让客户计算一个固定的时间 - 2005年1月31日,18:34:20.050(以毫秒为单位)。然后计算客户端计算机上的时间(当前时间)并计算当前时间和固定时间之间的差值。将客户端时间和增量发送回服务器。在服务器上,从相同的固定时间开始,如果添加相同的增量,服务器当前时间(由于响应时间滞后而不再是当前时间等)将是多少。客户端当前时间和服务器当前时间之间的差异将为您提供客户端和服务器之间的时差。
答案 1 :(得分:1)
var oneway = roundtrip / 2;
为什么你认为网络是对称的?实际上这是一个相当合理的假设 - 您可以尝试通过双向发送数据来校准连接,以估算吞吐量和延迟(请参阅boomerang's bw module以获取服务器 - 客户端测量的示例)但是这是一个基本功能TCP的拥塞窗口是逐步适应的 - 因此即使在静态连接上,吞吐量在连接的早期阶段也会发生显着变化(恰好是您可能尝试捕获客户端设备身份的点)。
尝试确保响应小于1kb(包括标头)(以确保它适合单个数据包)并且保持活动状态。 GET请求将略小于POST,尽管使用websockets可以提供更准确的数字。
更现实的方法是以已知的间隔捕获几个样本,然后计算平均值,例如
estmatedRtt=300;
for (var x=0; x<10; x++) {
setTimeout(estimatedRtt * x * 1.3, captureOffset);
}
答案 2 :(得分:0)
看起来他们只是忽略了描述中网络延迟的问题。我注意到他们(模糊)的措辞:
(...)基于确定匹配的 [时间增量] 参数属于选定范围(...)
这可以解释网络滞后变化。
在诸如因特网之类的大型繁忙网络中,不可能将精度“降低到毫秒”。其他网络类型(我认为令牌环或具有非常非常严格的QoS策略的网络)可能允许这种精确度。