NTPv5网络时间协议简介

报文格式来自文档
https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-ntpv5-00
由于2036问题的临近，旧有的NTPv4协议即将面临一个问题那就时间戳耗尽，在2036年的2月7日6时28分16秒（UTC）会出现数据溢出
但很无奈的是ntpv4协议虽提出了128位时间戳的可能性，但并未提供任何参数及报文，所以变成了纸面上的协议，无法实现
新协议也是秉承了改BUG的鸟性，仅仅在时间戳上加了8位，对也就是大约3万年后也会面临同样的问题，只能说是暂时解决了问题。
协议大概还是和4版本一样 但报文的多种对时方式只留了
客户端和授时服务器两个角色 报文格式也略有区别

LI 润秒
0: 无leap秒调整
1: 一天的最后一分钟为61秒
2: 一天的最后一分钟为59秒
3:时钟未同步

VN 版本号 这里填5 也就是二进制101

MODE模式 5版本删去了多种对时模式
这包含值 3（请求）或 4（响应）的 3 位字段
曾经NTPv4
是0：保留
1：对称主动
2：对称被动
3：客户端 请求
4：服务器 返回结果
5：广播
6：NTP控制消息
7：保留供私人使用

Scale
时间刻度的 4 位标识符。在请求中它是 要求的时间尺度
响应中，它是接收和传输时间戳的时间刻度
0：UTC 1：TAI 2：UT1 3：Leap-smeared UTC

Stratum 服务器等级
包含主机层的 4 位字段。主时间 服务器的层数为 1，其客户端的层数为 2， 依此类推。值 0 表示未知或无限层。在请求中，它始终为 0

Poll 轮询间隔
一个 8 位有符号整数，包含轮询间隔作为以秒为单位的舍入 log2 值。在请求中，它是当前的轮询间隔。在响应中，它是允许的最小轮询间隔。

Precision
时间精度
包含时间戳精度的 8 位有符号整数
以秒为单位作为四舍五入的 log2 值包含在消息中。在
不包含任何时间戳的请求，它始终为 0
Flags 标志位
一个 8 位整数，可以包含以下标志
0x1：多消息响应 在请求中，它是对多消息响应的请求。在响应中，它表示响应可能但不一定包含多条消息
0x2：后续消息在响应中它表示它不是多消息响应的第一条消息。
0x4：Interleaved mode 在requests中，它是在interleaved模式下请求响应。在响应中，它表示响应处于交错模式。

Era 时代位
一个 8 位无符号的 NTP 时代号对应于接收 时间戳。在请求中它始终为 0。预计在2036年就会置1，每136年+1.

Timescale Offset 我也不懂
特定于所选时间刻度的 16 位值，它参考接收时间戳。在请求中，它始终为 0。
在 UTC (0) 和 TAI (1) 时间尺度中，它是作为有符号整数的 TAI-UTC 偏移量，如果未知则为 0x8000。
在 UT1 时间刻度 (2) 中，它是作为 16 位 定点数的 UT1-UTC 偏移量，如果未知则为 0x8000 (-1.0)。 在 leap-smeared UTC 中，它是leap-smeared 时间和作为 16 位定点数的 UTC
之间的当前偏移量， 如果未知则为 0x8000 (-1.0)。

Root Delay
使用 32 位定点类型的字段。在响应中，它是服务器的根延迟。在请求中它始终为 0。

Root Dispersion
使用 32 位定点类型的字段。作为响应，它是
服务器的根分散。在请求中，它始终为 0。

Server Cookie
使用 32 位定点类型的字段。在响应中，它是
服务器的根延迟。在请求中它始终为 0。
Client Cookie
包含客户端生成的随机数的 32 位字段。响应包含相应字段的副本请求，它允许客户端验证响应是否是对请求的有效响应。

Receive Timestamp
使用 64 位定点类型的字段。在请求中，它
始终为 0。在响应中，它是收到请求的时间
。时间戳对应于接收的结束。

Transmit Timestamp
使用 64 位定点类型的字段。在请求中，它始终为0。在响应中，它是
传输
对客户端的响应的时间。具体响应取决于
所选模式（基本、后续、交错）。时间戳
对应于传输的开始。

此协议只会返回两个时间戳即服务器收到请求的时间 和请求离开的时间
所以如果想得到精确时间
需要客户端请求前开启精确计时器
收到请求后立刻关闭精确计时器
可用求出全部路程时间（t3-t0）

用（路程时间-服务器计算时间）/2可用得到单程时间
t2时刻时间戳+单程时间+计算耗时=授时点时刻。
其存在网络不对称的bug即如果我向一附近的服务器请求，由于数据包发送时需要各自打开NAT寻找路由表之类的操作，所以t0t1段的时间会比t2t3段略长一点点。但做的东西又不是什么航天需要分秒不差也就无所谓了。

我首先尝试发了一个UDP数据包 内容如下
发给了pool.ntp.org由于是抄的V4的代码所以请求包应该是哪里有误的
byte packetBuffer[48];
packetBuffer[0] = 0b00101011;// LI, Version, Mode 不闰秒 ntpv5 客户端
packetBuffer[1] = 1; // Stratum, or type of clock时钟精度 1最高15最低
packetBuffer[2] = 6;
packetBuffer[3] = 0xEC;
packetBuffer[12] = 49;//Reference Identifier
packetBuffer[13] = 0x4E;//这个标志特定参考时钟我也不知道什么意思
packetBuffer[14] = 49;
packetBuffer[15] = 52;

其返回
2c 03 06 ec
00 00 07 fc
00 00 11 d9
ce 37 40 4d
e8 31 22 db
31 9a 4a e5
00 00 00 00
00 00 00 00
e8 31 26 28
a8 20 15 2d
e8 31 26 28
a8 22 5f 57

第一行2c 03 06 ec
第一行00101100 00000011 00000110 11101100
00不闰秒101协议版本号5 100返回时间数据包
Scal 0000 时区UTC Stratum 0011 第三层主机应该意思是离原子钟的距离？
Poll 1110 轮询间隔14秒还是log2/14我也不懂后续轮询也不会管 Precision 1100精度12

第二行00 00 07 fc
第二行00000000 00000000 00000111 11111100
flag 0000 Era时代0000代表是1900年1月1日（UTC）为时代起点 和1970年时间戳差了2208988800还是2208989143秒我也不是很懂
Timescale Offset 时间刻度偏移07 fc

第三行 00 00 11 d9
Root Delay一般根延迟应该是代表服务器最少延迟？

第四行ce 37 40 4d
Root Dispersion 服务器描述符（没用）

第五行及第六行 服务器COOKIE(没用)
e8 31 22 db 31 9a 4a e5

第7行及第8行客户端COOKIE(没用)
00 00 00 00 00 00 00 00
第9行及第10行 关键数据 数据包到达服务器的时间戳
e8 31 26 28 前32位为1900年到现在的秒数
a8 20 15 2d 后32位为把最后1秒分为2^32次

第11第12行 关键数据 数据包离开服务器的时间戳
e8 31 26 28 前32位为1900年到现在的秒数
a8 22 5f 57 后32位为把最后1秒分为2^32次

解析关键数据在于e8 31 26 28代表纪元原点到现在的时间
现在的纪元是0纪元也就是1900-2036年
e8 31 26 28也就是
2208988800是1900年时间戳与1970年时间戳的差值

3895535144-2208988800=1,686,546,344
去时间戳转换网站上转换得到

=2023-06-12 13:05:44（北京时间）也就是我现在写文章的这段时间