客戶端時間為什么是隨機的？
現象
在NTS授時狀態監控系統的同步日志頁面中，記錄著所有客戶端向NTS服務器校時的日志信息，我們可以看到有些同步日志中的客戶端時間是隨機的。如下圖所示：
分析
經過統計后得知，隨機時間的客戶端均是centos7（redhat7）及以上版本的Linux系統，centos6.5及以下版本中客戶端同步時間均是正常的。我們都知道Linux7之前的版本同步時間用的是ntpd服務，Linux7以及7之后的版本都改用chrony了，兩者區別參考：https://chrony.tuxfamily.org/comparison.html。
在centos7.9的測試環境中對123端口進行抓包后發現，客戶端發送給服務器的NTP包中，transmit
timestamp（T3）的時間戳是隨機的，同時，服務器收到客戶端請求后，原封不動的將時間賦值給origin
timestamp（T1），如下圖所示：（時間戳參考文末附1）
但是這種情況在使用ntpdate同步本地時間時并不存在，時間都是正確的：
經過抓包后，可以初步確定問題出現在chrony上了。經過查詢資料發現，自chrony2.3開始不顯示客戶端數據包中的本地時間和同步狀態，這個版本是2016年2月16日發布的。參考：https://chrony.tuxfamily.org/news.html
而centos7.9的測試環境中，chrony的版本是3.4。
但是，chrony2.3版本更新記錄中，只是說明不再顯示客戶端數據包中的本地時間和同步狀態，但是沒說明本地時間為什么是隨機的。
經過查詢資料發現，chrony與NTP對比官方文檔的安全性對比表格中，有關于隨機時間戳的說明，如下圖所示
同時RFC5905（NTPv4）中也給出了隨機時間戳的說明：雖然該備忘錄要求客戶端數據包中的大部分字段設置為零，但發送時間戳應該是隨機的。這個決定是出于安全和隱私的動機。在沒有密碼認證的情況下，驗證原始時間戳是客戶端對NTP響應進行盲欺騙的主要防御手段。因此，客戶端的傳輸時間戳不可預測是很重要的。
結論
chrony官方為了安全考慮，從chrony2.3起不在客戶端數據包中顯示本地時間和同步狀態，即客戶端發起NTP校時的數據包中的本地時間直接被賦值為隨機時間，這樣NTP服務器收到客戶端的校時請求后，經過解析后保存同步日志，我們看到的客戶端時間就是一個隨機時間。
根據上面的分析可得出：
使用chrony2.3及以上版本作為同步服務的系統，客戶端時間（T1）均是隨機時間戳。
一些遵循NTPv4(RFC5905)協議開發的時間同步工具，客戶端時間（T1）均是隨機時間戳。
Linux7及以下版本系統使用的同步服務是ntpd，客戶端時間（T1）是客戶端本地時間。
NTS授時狀態監控系統同步日志中的客戶端時間只是將T1時間戳展示出來，作為對客戶端進行同步超時告警和客戶端時間偏差告警時的參考依據。所以，當客戶端時間隨機化后，NTS授時狀態監控系統將無法對此類客戶端進行同步超時告警和時間偏差告警。
NTS授時狀態監控系統如何監控這類客戶端？
目前可以先將chrony的版本降低至chrony2.2.1，這樣可保證正常監控客戶端時間偏差。后續我們會繼續對NTS授時狀態監控系統進行升級，屆時可不降低chrony版本的同時監控高版本的Linux客戶端。
附1：時間戳
一個完整的NTP協議校時請求數據包中有4個時間戳（T1、T2、T3、T4），分別表示：
起源時間戳 T1(origin timestamp)：請求離開服務器時在客戶端的時間，即：請求數據包離開客戶端時，客戶端本地時間
接收時間戳 T2(receive timestamp)：請求從客戶端到達時在服務器的時間，即：請求數據包到達服務器時，服務器本地時間
發送時間戳 T3(transmit timestamp)：響應離開客戶端時在服務器的時間，即：響應數據包離開服務器時，服務器本地時間
目的地時間戳 T4(destination timestamp)：響應到達客戶端時在客戶端的時間，即：響應數據包到達客戶端時，客戶端本地時間
通過這4個時間戳可以得出：
網絡延遲： delay=(T4-T1)-(T3-T2)
客戶端時間偏差： offset=((T2-T1)+(T3-T4))/2
上一篇：AIX主機配置時間同步的方法
下一篇：大華攝像頭時間同步配置方法
