创建使用服务器系统时间响应的简单NTP服务器时出现问题
我正在尝试构建一个非常简单的NTP (v3)服务器，用于接收来自局域网上IP摄像机的NTP请求，以实现时间同步。相机与互联网断开连接，所以我们的想法是使用本地PC服务器作为摄像头的NTP服务器。
我尝试过两种不同的方法。
- 编写简单的UDP转发到已知的NTP服务器(例如time.windows.com)。效果很好。
- 编写一个简单的UDP服务器，监听传入NTP请求的端口123，这只会返回服务器的系统时间。对于简单、不需要的NTP客户端(例如物理网络路由器)来说，这也非常有效，但是对于本地HIKVISION摄像机来说，它一直失败。
方法:接收一个48字节的缓冲区。确保偏移量0处的字节为0x1B。将偏移量0处的字节转换为0x1C，并将当前的UTC时间作为NTP时间戳写入持续8字节。对于大多数NTP客户端来说，这是很好的工作方式，但HIKVISION则不然。
摄像机发出这样的请求：
1B-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
00-00-00-00-00-00-00-00-61-8C-DE-CA-C3-73-89-DC最后8个字节是非零的.如果我试图修改我的UDP转发解决方案1，使最后8个字节在转发之前被归零，则摄像机会报告一个错误。因此，这些位元是很重要的，并且可能有一些密码学意义。
为了理解这一点，我在RFCs中进行了挖掘，但我找不到解释。我能找到的任何示例代码都完全忽略了这一点，并沿着简单的路线前进。
所以问题是..。如何解释NTP请求的尾随字节，以及如何返回正确的NTP响应？欢迎使用一些示例代码或指向资源的指针。
回答 1
Stack Overflow用户
发布于 2019-02-26 04:45:52
有关NTP数据包格式的说明，请参见https://www.ietf.org/rfc/rfc1305.pdf第50页开始的附录A。最后8个字节应该携带服务器的响应时间戳--这就是为什么在构建最小响应数据包时将时间戳放入这些字节的原因。
但是，基于此客户端将值放入最后8个字节的事实，它似乎希望使用SNTP (Simple )协议第5节中描述的机制，每个https://www.ietf.org/rfc/rfc2030.txt SNTP使用与NTP相同的数据包格式，但使用字段的方式略有不同。在SNTP中，客户端将40到47字节的值是当时客户端的最新想法。(在这种情况下，AFAICT的时间戳大约是1951年左右。)
如果客户端正在尝试这样做，那么它希望服务器将这8个字节复制到24-31字节(初始时间戳字段)，然后将服务器当前时间写入字节32-39 (接收时间戳)和字节40-47 (传输时间戳)，并将其作为响应发送。当然，还继续将响应中的第一个字节更改为0x1C，以指示该数据包来自服务器。您还应该将字节1中的Stratum值设置为一个看似合理的非零值，类似于3或4。
考虑到客户端的时钟离得很远，它可能需要几轮请求/响应才能同步。因此，不要期望它的时钟立即跳转以匹配服务器的时钟。(它可能会这样做，但我不会指望它。)
我不认为你需要通过特殊对待这个客户来使你的逻辑复杂化。您可能完全可以将相同的逻辑应用于来自将零放入最后8个字节的客户端的数据包。这只意味着在构建对这些客户端的响应时，您将把零复制到原始时间戳字段中。
https://stackoverflow.com/questions/54826694
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号