想象一下，在异构网络环境中，您有许多跨多台主机的集群服务器，因此服务器之间的连接可能具有非常不同的延迟和带宽。您希望通过在服务器之间传输数据来构建服务器之间的连接图。
当然，随着网络拓扑的变化，这张地图可能会随着时间的推移而变得陈旧——但现在让我们忽略这些复杂性并假设网络是相对静态的。
鉴于此主机图中节点之间的延迟，计算带宽是一个相对简单的时间练习。但是，我在延迟方面遇到了更多困难。要获得往返时间，只需对从本地主机到远程主机的回程 ping 进行计时——这两个计时事件（开始、停止）都发生在本地主机上。
如果假设延迟在两个方向上不相等，我想要单向时间怎么办？假设各个主机上的时钟不精确同步（至少它们的误差与所涉及的延迟具有相同的量级） - 我如何计算单向延迟？
在一个相关的问题中——这种不对称延迟（一个链接在方向上比另一个更快）在实践中是否常见？出于什么原因/硬件配置？当然，我知道非对称带宽场景，尤其是在最后一英里的消费者链路上，例如 DSL 和 Cable，但我对延迟不太确定。
补充：在考虑了下面的评论后，问题的第二部分可能会更好地使用serverfault。
据我所知，不对称延迟——尤其是“最后一英里”不对称——无法自动确定，因为任何网络时间同步协议都同样受到相同不对称的影响，所以你没有参考点来评估不对称性。
例如，如果每个端点都有自己的 GPS 时钟，那么您将有一个参考点可供使用。
在“消息传递平台的 LogP 参数的快速测量”中，作者指出，延迟测量需要与被测量系统外部的时钟同步。（粗体强调我的，原文中的斜体。）
非对称延迟只能通过发送带有时间戳t s的消息来测量，并让接收者从t r - t s推导出延迟，其中t r是接收时间。这需要发送方和接收方之间的时钟同步。如果没有外部时钟同步（如使用 GPS 接收器或网络时间协议、NTP 等专用软件），时钟只能同步到两台主机之间的往返时间粒度[10]，这对于测量网络延迟是无用的。
但是，没有任何基于网络的算法（例如 NTP）可以消除最后一英里链接问题，因为算法的每个输入本身都将统一受最后一英里链接的性能特征的影响，因此在网络中不是“外部”的。上面给出的意义。（我相信构建一个证明是可能的，但我现在没有时间构建一个。）
有一个名为 One-Way Ping (OWAMP) 的项目专门用于解决此问题。SO_TIMESTAMP在 LKML 中可以看到为传入数据包（ 、等）添加高分辨率时间戳SO_TIMESTAMPNS以帮助计算此统计数据的活动。
http://www.internet2.edu/performance/owamp/
甚至还有一个 Java 版本：
请注意，数据包时间戳确实需要硬件支持，并且许多当前一代的 NIC 仅提供毫秒分辨率，这可能与主机时钟不同步。DDK 中有关于同步主机和 NIC 时钟的 MSDN 文章展示了潜在问题。由于核心差异，来自 TSC 的以纳秒为单位的时间戳是有问题的，并且可能需要 Nehalem 架构才能以所需的分辨率正常工作。
http://msdn.microsoft.com/en-us/library/ff552492(v=VS.85).aspx
您可以通过将不同大小的数据包发送到返回固定大小数据包的端口来测量链路上的不对称延迟，例如将一些 udp 数据包发送到回复 icmp 错误消息的端口。icmp 错误消息的大小始终相同，但您可以调整要发送的 udp 数据包的大小。
在没有同步时钟的情况下，无法像 2011 年的论文中所证明的那样测量不对称性"Fundamental limits on synchronizing clocks over networks".