测量单向网络延迟

这是关于衡量我创建的网络延迟的一个难题。我相信解决方案是不可能的，但是朋友们不同意。无论哪种方式，我都在寻找令人信服的解释。（尽管我认为它很困惑，但我认为它适合本网站，因为它适用于通信协议（例如在线游戏）的设计和体验，更不用说NTP了。）

假设两个机器人位于两个房间中，并通过具有不同单向延迟的网络连接，如下图所示。当机器人A向机器人B发送消息时，它需要3秒钟才能到达，但是当机器人B向机器人A发送消息时，它需要1秒钟才能到达。延迟永远不会改变。

尽管它们可以测量时间的流逝（例如，它们具有秒表），但是它们是相同的，并且没有共享的时钟。他们不知道其中哪个是机械手A（消息延迟3s），哪个是机械手B（消息延迟1s）。

发现往返时间的协议是：

whenReceive(TICK).then(send TOCK)

// Wait for other other robot to wake up
send READY
await READY
send READY

// Measure RTT
t0 = startStopWatch()
send TICK
await TOCK
t1 = stopStopWatch()
rtt = t1 - t0  //ends up equalling 4 seconds

是否有确定单程行程延迟的协议？机器人可以发现其中哪个机器人的消息发送延迟更长？

下图是我写的博客文章中的图表，直观地证明了这是不可能的：

请注意，即使单向延迟发生变化（甚至变为负数），每侧的数据包到达时间也将保持不变。第一个数据包总是在服务器时钟的1.5s到达服务器，第二个数据包总是在客户端的时钟2s到达客户端，依此类推。数据包的内容和本地到达时间是协议唯一可基于的内容，但是当不对称性发生变化时，内容和到达时间也可以保持不变，这还可以通过改变初始时钟偏斜来实现。

基本上，单向延迟中的不对称性看起来完全像时钟偏斜。由于问题表明我们并非一开始就知道初始时钟偏斜或单向等待时间不对称，并且改变一个看起来就像改变另一个，因此它们的影响是无法区分的，因此我们无法分离它们的作用以解决问题。单向潜伏期不对称。不可能。

更正式地讲，仅给出循环长度时，就不能求解边缘长度。周期基准具有个自由度，对应于相对于参与者之一的未知时钟偏斜。即使有很多参与者，您也可以始终隐藏单向等待时间：n − $n-1$$n-1$

如果您不那么喜欢视觉，我还有另一个直觉的说法。想象一下未来一百年的时间门户。当您与另一边的人聊天时，您会发现对话是完全正常的，尽管单向延迟中存在一百年的不对称性。在这种规模上，任何可观察到的效果都是显而易见的！

我认为仅通过比较秒表是不可能找出单向延迟的。

$A$$B$$C_{A1}$
$B$$C_{B1}=1$
$A$$C_{A2}=9$
$B$$C_{B2}=5$
$A$$B$

也许如果您将其定为赏金问题，就会有人破解。在那之前，荣誉。

我找到了一种方法来同时发现哪个节点是谁（即谁具有更长的消息延迟）并估计单向行程延迟。尽管其他答案是正确的，但它们仅考虑采用直接时钟测量，这当然是行不通的。但是，正如我在这里证明的那样，这只是故事的一部分，因为这是我针对上述情况的有效算法：

假设在现实生活中：

• 有限带宽的链接b

• 每个节点都有唯一的地址（例如A和B）

• 数据包大小p比带宽*延迟乘积小得多

• 节点A和B能够填充频道

• 节点具有random（）函数

每个节点用自己的数据包（分别标记为A或B）填充通道，或按以下方式转发从其他节点收到的数据包：

Always fill the channel with my own packets except:
if I receive a packet from another node then
   Randomly choose to 
          either forward that packet from the other node
          or discard that packet and forward my own packet

直观说明 由于A的带宽*延迟乘积较高（因为延迟较高），因此A将设法接收比B多的数据包，因此每个节点都可以知道它们在图中的身份。

此外，通过在上述算法上运行足够的收敛时间，A与B的数据包比率将表示A与B 的RTT延迟的实际比率，从而表示所需的OTT。

仿真结果跟踪 这是一个证明上述情况的仿真，并演示了A如何成功收敛到3秒延迟，而B如何收敛在1秒延迟附近：

附图说明： 每条线代表1秒的时间（为清楚起见，选择分组大小以具有1秒的传输时间）。请注意，每个节点都可以在任何时间以任何特定顺序或时间启动算法。列如下：

• 节点A接收：节点A在其接收方看到的内容（以下也是P4）

• NODE A注入：节点A发出的内容（请注意，这是A，或者随机是A或B）

• P1，P2，P3：在A和B之间（按顺序）传输的三个数据包（1秒传输意味着3个数据包在传输中的等待时间为3）

• 节点B接收：B在其接收端看到的（这是P3）

• NODE B注入：B发出的信息（请注意，这是B，或者根据算法随机地选择A或B）

• P4：从B到A的传输数据包（另请参见P1，P2，P3）

• A计数A：A对它所看到的A数据包的计数

• A计数B：A对其看到的B数据包的计数

• B计数A：B对已看到的A数据包进行计数

• B计数B：B对其看到的B数据包进行计数

• A-> B：A估计的延迟时间B（基于看到的数据包的RTT比率为4秒）

• B-> A：B向A估算的延迟（基于看到的数据包的RTT比率为4秒）

正如我们看到的那样，两个节点都收敛并保持在其真实延迟附近（实际上我们看不到A，因为收敛需要更多的时间，但它的收敛行为与B相同）

更好的滤波器收敛速度更快，但是我们可以清楚地看到它们如何在正确的延迟值附近收敛，因此它们可以确切地知道它们的延迟（即使我只是出于说明目的而展示它们的估计）。

同样，即使链路之间的带宽不同，上述方法仍可以通过使用数据包对来计算带宽估计值，然后仍然适用于上述比例方程式（尽管必须更仔细地考虑这一点）。

结论 对于上图，我们为A和B提供了一种算法，以了解A和B在网络中的位置并知道它们到另一个节点的等待时间。我们使用了一种网络测量估计方法，而不是基于时钟的方法，由于递归时钟同步问题，它的确无法解决。

请注意，我现在编辑了提供所有模拟的答案，因为就您在第一条评论中所看到的，没有人相信我可以解决它。希望有了这些结果，可以使某个人更有说服力并愿意帮助每个人至少在此网络测量难题中找到一个错误或正确性！

这是对@ user3134164的答复，但太大了，无法发表评论。

$P_x$$x$$R_x$$x$

• $R_1 = (1 - R_2) \times (1 - P_2)$$R_2 = (1 - R_1) \times (1 - P_1)$$1 - R_2$$1 - P_2$
• $R_1$$R_2$$\frac{R_1}{1 - R_1}$$\frac{R_2}{1 - R_2}$

这就是为什么我相信这不会带您到任何地方。请指出在此推理过程中可能犯的任何错误。