无需 NTP 即可实现小规模时钟同步

发布于 2024-11-01 05:58:23 字数 193 浏览 1 评论 0原文

我正在寻找一种简单的时钟同步协议，该协议易于实现，占用空间小，并且在没有互联网连接的情况下也可以工作，以便它可以在封闭的实验室网络中使用。需要明确的是，我并不是在寻找仅可用于排序事件的东西（例如矢量时钟），而是在寻找使不同节点上的进程能够根据本地时钟同步其操作的东西。据我了解，这需要一个可以考虑时钟漂移的解决方案。可以假设存在 TCP/IP 或类似的相对低延迟的流连接。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不必你懂 2024-11-08 05:58:23

免责声明：无论如何我都不是 NTP 专家。只是一个周末玩得开心的业余爱好者。

我知道您说过您不想要 NTP 实施，因为您认为很复杂，而且您的环境中可能无法使用 Internet NTP 服务器。

但是，简化的 NTP 查找可能很容易实现，并且如果您有本地 NTP 服务器，则可以实现良好的同步。

操作方法如下：

查看 RFC 5905

您会看到 NTP v4 数据包如下所示：

LI (2 位)
VN (3 位) - 使用“100” (4)
模式 (3 位)
层 (8 位)
轮询 (8 位)
精度 (8 位)
根延迟 (32 位)
根分散 (32 位)
参考Id（32 位）
参考时间戳（64 位）
源时间戳（64 位）
接收时间戳（64 位）
传输时间戳（64 位）
扩展字段 1（变量）
扩展字段 2（变量）
...
密钥标识符
摘要（128 位） )

不需要摘要，因此形成有效的客户端请求非常容易。按照 RFC 中的指导，使用 LI = '00'、VN = '100'（十进制 4）、Mode = '011'（十进制 3）。

用C#来说明：

byte[] ntpData = new byte[48]
Array.Clear(ntpData, 0, ntpData.Length);
ntpData[0] = 0x23;  // LI = 00, VN = 100, Mode = 011

打开一个到目标服务器的套接字并将其发送过来。

int ntpPort = 123;
IPEndPoint target = new IPEndPoint(Dns.GetHostEntry(serverDnsName).AddressList[0], ntpPort);
Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
s.Connect(target);
s.Send(ntpData);

在响应中，当前时间将位于传输时间戳（字节 [40 - 48]）中。时间戳是 64 位无符号定点数。整数部分是前32位，小数部分是后32位。它表示从 1900 年 1 月 1 日 0 点开始的秒数。

s.Receive(ntpData);
s.Close();

ulong intPart = 0;
ulong fractPart = 0;

for (int i = 0; i < 4; i++)
    intPart = (intPart << 8) | ntpData[40 + i];

for (int i = 4; i < 8; i++)
    fractPart = (fractPart << 8) | ntpData[40 + i];

要以（大致）秒粒度更新时钟，请使用：自 1900 年 1 月 1 日 0 点以来的秒数 = intPart + (fractPart / 2^32)。（我粗略地说是因为没有考虑网络延迟，我们在这里四舍五入）

ulong seconds = intPart + (fractPart / 4294967296);

TimeSpan ts = TimeSpan.FromTicks((long)seconds * TimeSpan.TicksPerSecond);

DateTime now = new DateTime(1900, 1, 1);
now = DateTime.SpecifyKind(now, DateTimeKind.Utc);
now += ts;

“now”现在是一个包含当前时间的 DateTime（UTC 时间）。

虽然这可能无法回答您的问题，但希望它能让 NTP 不那么不透明。 =)

Disclaimer: I'm not an NTP expert by any means. Just a hobbyist having fun on the weekend.

I realize you said you didn't want an NTP implementation, because of the perceived complexity and because an Internet NTP server may not be available in your environment.

However, an simplified NTP look-up may be easy to implement, and if you have a local NTP server you can achieve good synchronization.

Here's how:

Review RFC 5905

You'll see NTP v4 packets look something like:

LI (2 bits)
VN (3 bits) - Use '100' (4)
Mode (3 bits)
Stratum (8 bits)
Poll (8 bits)
Precision (8 bits)
Root Delay (32 bits)
Root Dispersion (32 bits)
Reference Id (32 bits)
Reference Timestamp (64 bits)
Origin Timestamp (64 bits)
Receive Timestamp (64 bits)
Transmit Timestamp (64 bits)
Extension Field 1 (variable)
Extension Field 2 (variable)
...
Key Identifier
Digest (128 bits)

The digest is not required, so forming a valid client request is very easy. Following the guidance in the RFC, use LI = '00', VN = '100' (decimal 4), Mode = '011' (decimal 3).

Using C# to illustrate:

byte[] ntpData = new byte[48]
Array.Clear(ntpData, 0, ntpData.Length);
ntpData[0] = 0x23;  // LI = 00, VN = 100, Mode = 011

Open a socket to your target server and send it over.

int ntpPort = 123;
IPEndPoint target = new IPEndPoint(Dns.GetHostEntry(serverDnsName).AddressList[0], ntpPort);
Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
s.Connect(target);
s.Send(ntpData);

In the response, the current time will be in the Transmit Timestamp (bytes [40 - 48]). Timestamps are 64-bit unsigned fixed-point numbers. The integer part is the first 32 bits, the fractional part is the last 32 bits. It represents the number of seconds since 0h on Jan-1-1900.

s.Receive(ntpData);
s.Close();

ulong intPart = 0;
ulong fractPart = 0;

for (int i = 0; i < 4; i++)
    intPart = (intPart << 8) | ntpData[40 + i];

for (int i = 4; i < 8; i++)
    fractPart = (fractPart << 8) | ntpData[40 + i];

To update the clock with (roughly) second granularity, use: # of seconds since 0h Jan-1-1900 = intPart + (fractPart / 2^32). (I say roughly because network latency isn't accounted for, and we're rounding down here)

ulong seconds = intPart + (fractPart / 4294967296);

TimeSpan ts = TimeSpan.FromTicks((long)seconds * TimeSpan.TicksPerSecond);

DateTime now = new DateTime(1900, 1, 1);
now = DateTime.SpecifyKind(now, DateTimeKind.Utc);
now += ts;

"now" is now a DateTime with the current time, in UTC.

While this might not answer your question, hopefully it makes NTP a little less opaque. =)

回复收藏 0 原文

﹉夏雨初晴づ 2024-11-08 05:58:23

仅根据维基百科文章，我就能够非常快速且轻松地实现精确时间协议的简化版本。如果您感兴趣的是使它们相互同步而不是与外界同步，那么您应该能够以最小的努力获得毫秒精度。

该协议的基本原理如下：

主时钟广播一条同步消息，其中包含发送消息时的时间戳 (T1)。
客户端将收到同步消息的时间记录为 T1'。
客户端将延迟请求发送回主服务器，并将发送消息的时间记录为 T2。
主站以收到消息的时间响应延迟请求。这次是T2'。
客户端将时钟调整为 (T1' - T1 - T2' + T2)/2。

如果您需要更好的稳定性，您可以实现锁相环或线性回归或类似的东西，以更好地控制抖动并避免由于网络滞后而导致的大幅波动。协议指定了许多更复杂的功能，但是否要实现它们取决于“足够好”的程度。

回复收藏 0 原文

━╋う一瞬間旳綻放 2024-11-08 05:58:23

ntp 是完成这项工作的正确工具。你不需要互联网连接，只要额外支付 105 美元和你生命中的几个小时，你甚至可以在没有互联网连接的情况下进行 GPS 同步以获得绝对时间参考，尽管这对你来说似乎并不重要。

忽略 GPS 同步稍微增加的复杂性，您可以使用几行配置文件（每个客户端上四行，服务器上五行）来同步到所选系统的时钟。我的系统上的 ntpd 二进制文件大小为 505kB。您还可以使用 ntpdate，它可以定期运行来调整系统时钟（客户端上的零行配置，而不是使用正确的参数调用 ntpdate 应用程序）。该二进制文件大小为 80kb。有一个 SNTP 协议，它允许嵌入式应用程序占用更小的空间（与普通的 ntp 服务器通信）。还有一种称为 chrony 的替代 NTP 实现。

还有一个名为 rdate 的程序（通常仅在较旧的系统上，尽管源是可用），其工作方式有点像 ntpdate，但不太精确。您还需要一个 RFC 868 服务器，通常在 inetd 中提供。

唯一的其他选择是已经提到的精确时间协议。

回复收藏 0 原文