官方網站資料
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值又正確了,沒搞清楚