官方网站资料
https://www.ietf.org/rfc/rfc5905.txt
一.下面是摘抄部分内容,其中报文格式字节序入下红色字体为网络字节序,所以对于几个64ibt时间按4字节大端处理
而下图Figure 8: Packet Header Format头部4字节就是按大端格式画的,所以在定义结构体时如果按照下图所画的定义
#pragma pack(1)
typedef struct {
uint8_t flags;
uint8_t stratum;
int8_t poll; // log2 of maximum polling interval
int8_t precision; // log2 of local clock precision
int32_t root_delay; // total roundtrip delay to reference clock
int32_t root_dispersion; // maximum error relative to reference clock
char refer_id[4]; // appropriate for stratum-1 servers, e.g. "GPS\0"
uint64_t refer_timestamp;
uint64_t origin_timestamp;
uint64_t recv_timestamp;
uint64_t trans_timestamp;
} SntpPacket;
#pragma pack()
头部就不需要再次做大小端转换,而在对64bit时间赋值时,如果是小端cpu时如arm等则要先转换成大端在赋值.
7.3. Packet Header Variables
The most important state variables from an external point of view are
the packet header variables described in Figure 7 and below. The NTP
packet header consists of an integral number of 32-bit (4 octet)
words in network byte order. The packet format consists of three
components: the header itself, one or more optional extension fields,
and an optional message authentication code (MAC). The header
component is identical to the NTPv3 header and previous versions.
The optional extension fields are used by the Autokey public key
cryptographic algorithms described in [RFC5906]. The optional MAC is
used by both Autokey and the symmetric key cryptographic algorithm
described in this RFC.
Mills, et al. Standards Track [Page 17]
RFC 5905 NTPv4 Specification June 2010
+-----------+------------+-----------------------+
| Name | Formula | Description |
+-----------+------------+-----------------------+
| leap | leap | leap indicator (LI) |
| version | version | version number (VN) |
| mode | mode | mode |
| stratum | stratum | stratum |
| poll | poll | poll exponent |
| precision | rho | precision exponent |
| rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID |
| reftime | reftime | reference timestamp |
| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp |
| keyid | keyid | key ID |
| dgst | dgst | message digest |
+-----------+------------+-----------------------+
Figure 7: Packet Header Variables
The NTP packet is a UDP datagram [RFC0768]. Some fields use multiple
words and others are packed in smaller fields within a word. The NTP
packet header shown in Figure 8 has 12 words followed by optional
extension fields and finally an optional message authentication code
(MAC) consisting of the Key Identifier field and Message Digest
field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reference Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 2 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dgst (128) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Packet Header Format
二.对于客户端校准
In practice, the precision kernel delivers about the best accuracy and precision available, assuming external synchronization sources are of sufficient quality are available. In general, and even with faster hardware and network links, improved accuracy can only be achieved with minute attention to the residual errors that occur in normal operation, including systematic and stochastic delay variations due to competing network traffic and operating system scheduling.
Stochastic errors are generally mitigated by the NTP mitigfation and discipline algorithms. In general, these errors can be further reduced using some kind of hardware assist or special provisions in the network interface card (NIC) or device driver. Improved means to do this ae discussed in this section.
To better understand the issues, consider the ultimate case where the server and client implement clocks that can be read with exquisite accuracy. The object is to measure the time offset of a server relative to the client.
Figure 1
As shown in Figure 1, the NTP on-wire specification uses what is called here the reference timestamps T1, T2, T3 and T4, respectively called the origin, receive, transmit and destination timestamps. T1 and T4 are struck by peer A from its clock, while T2 and T3 are struck by peer B from its clock. The object of the protocol is to determine the time offset of B relative to A and the roundtrip delay ABA:
offset θ = [(T2 − T1) + (T3 − T4)] / 2, (1)
delay δ = (T4 − T1) − (T3 − T2) / 2. (2)
对于客户端要同步服务器时间
T3(服务端发送时间)+delay δ ,用该值来同步客户端时间系统先减去DIFF_SEC_1900_1970再减去时区8小时
三.关于UTC和本地时间
UTC时间=本地时间-8 本地时间比UTC时间快8小时
wireshark显示的时间为UTC时间,所以在赋值之前需要转换
define DIFF_SEC_1900_1970 (2208988800UL) //1900年1月1号00:00:00到1970年1月1号00:00:00秒数
localtime()函数参数为本地时间
gmtime()函数参数为UTC时间
struct tm *time;//其中year是以1900年为基准,而UTC时间以1970为基准
time_t tt;
time = localtime(&tt);
对time赋值
tt = mktime(time);
tt+=DIFF_SEC_1900_1970;
用tt来赋值NTP报文时间
如果不先调用localtime()函数初始化struct tm指针,直接定义变量
struct tm time;
对time赋值
tt = mktime(&time);
计算出来的tt小时少一小时,不知为什么,多调几次mktime()函数tt值又正确了,没搞清楚