基本介紹
協定概況,工作模式,協定套用,參考資料,
協定概況
簡單網路時間協定（SNTP：Simple Network Time Protocol）
RFC 1305 指定了NTP協定機制中的事件，狀態，傳輸功能和操作，另外，還有可選擇的算法，它改進測時質量並且減少了一些同步源中可能存在的錯誤。為了獲得網際網路上主要路徑的延時精確到毫秒級，使用一些複雜的算法或者他們的等價算法是必要的。但是，在許多場合這樣的精確度是不要求，或許精確到秒已足夠了。在這樣的情況下，更簡單的協定例如“時間協定”[POS83 ]已被使用。這些協定通過基於RPC交換：客戶端請求此刻時間，然後伺服器回傳從某個已知時間點到現在的秒鐘數。
NTP被設計成了性能差異很大的客戶端及伺服器均能適用，且適用於客戶端及伺服器所在網路有大範圍的網路延遲和抖動的情況。今天的網際網路上的NTP同步子網的大多數用戶使用一個軟體包包括了一整套的NTP 的選擇和算法，是一個比較複雜，實時的套用系統。軟體要適用於多種硬體平台：從巨型計算機到個人計算機。要在這樣的範圍都適用，它的龐大尺寸和複雜性就不適合於很多套用了。按照要求，探求一些可供選擇的訪問策略( 使用適合於精確度要求不是很嚴格的簡單軟體)是有用的。
本備忘錄描述簡單網路時間協定(SNTP)，它是一個簡化了的NTP伺服器和NTP客戶端策略。SNTP在協定實現上沒有什麼更改，在最近也不會有什麼變動。訪問範例與UDP/TIME 協定是一致的，實際上，SNTP應該更容易適用於使用個人計算機的 UDP/TIME 客戶。而且，SNTP 也被設計在一個專門的伺服器( 包括一台集成的無線電時鐘)里操作。由於在系統里的那些各種各樣反應機制的設計和控制，交付調節時間精確到微秒是可能的。這樣的專門設計是切實可行的。
強烈建議SNTP 僅僅在同步子網的末端被使用。 SNTP 客戶端應該僅在子網的葉子( 最高的階層) 操作並在配置過程中沒有依靠其它NTP或者SNTP客戶端來同步。SNTP 伺服器應該僅在子網的根( 階層1) 操作並在配置過程中，除一台可靠的無線電時鐘外中沒有其它同步源。只有使用了有冗餘的同步源及不同的子網路徑及整套NTP實現中的crafted 算法，主伺服器通常期望的可靠性才有可能達到。這種做法使主同步源在無線電時鐘通信失敗或者交付了錯誤時間時，還能用到其它幾個無線電時鐘和通向其它主要伺服器的備份路徑。因此，應該仔細考慮客戶端中SNTP的使用，而不是在主伺服器里的NTP的使用。
工作模式
在單播方式下，客戶端和伺服器的IP 地址按常規被分配。在廣播方式下，伺服器使用一指定的IP播送地址或者IP多播地址，以及指明的媒介訪問播送地址，客戶端要在這些地址上幀聽。為此，IP 廣播地址將限制在一個單獨的IP子網範圍，因為路由器不傳播IP廣播數據報。就乙太網而論，例如，乙太網媒介訪問廣播地址(主機部分全部為1) 被用於表示IP廣播地址。
另一方面，IP 多播地址將廣播的潛在有效範圍擴展到整個網際網路。其真實範圍，組會員和路由由網際網路組管理協定(IGMP) 確定 [DEE89 ]，對於各種路由協定，超出了這份資料的討論範圍。就乙太網而論，例如，乙太網媒介訪問播送地址(全部為1)要和分配的224.0.1.1 的IP 多播地址合用。 除了IP 地址規範和IGMP，在伺服器操作IP廣播地址或者IP多播地址沒有什麼不同。
廣播客戶端幀聽廣播地址，例如在乙太網情況下主機地址全部為1的。就廣播地址的IP而論，沒有更進一步規定的必要了。在IP多組廣播情況下，主機可能需要實現IGMP，為的是讓本地路由器把訊息攔截後送到224.0.1.1 多播組。這些考慮不屬於這份資料的討論範圍。
就當前指定的SNTP而論，其真正的弱點是多目廣播客戶端可能被一些行為不當或者敵對的在網際網路別處的SNTP/NTP 多播伺服器攻擊而癱瘓，因為目前全部這樣伺服器使用相同的IP 多播地址：224.0.1.1 組地址。 所以有必要，存取控制要基於那些以客戶端信任的伺服器源地址，即客戶端選擇僅僅為自己所知的伺服器。或者，按照慣列和非正式協定，全部NTP多播伺服器現在在每條訊息內應包括已用MD5加密的加密位，以便客戶端確定訊息沒有在傳輸中被修改。SNTP 客戶端能實現那些必要加密和密鑰分發計畫在原則上是可能的，但是這在SNTP被設計成的那些簡單的系統里不可能被考慮。
考慮到沒有一個完整的SNTP規範，故IP 廣播地址將使用在IP子網和區域網路部分(指有完整功能的NTP伺服器和SNTP客戶端在同一子網上的區域網路)，而對於IP 多播地址來說，將只能用在為達到以上相同目而設計的特例中。尤其，只有伺服器實現了RFC 1305 描述的NTP認證時（包括支持MD5訊息位的算法），在SNTP 伺服器里的IP 多播地址才被使用。
協定套用
SNTP時間戳格式
sntp使用在RFC 1305 及其以前的版本所描述標準NTP時間戳的格式。與網際網路標準標準一致， NTP 數據被指定為整數或定點小數，位以big-endian風格從左邊0位或者高位計數。除非不這樣指定，全部數量都將設成unsigned的類型，並且可能用一個在bit0前的隱含0填充全部欄位寬度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注意，從1968 年起，最高有效位(整數部分的0 bit位) 已經被確定，64 位比特欄位在2036 年將溢出。 如果NTP或者SNTP在2036 年還在使用的話，一些外部方法將有必要用來調整與1900年及2036 年有關的時間 (136 年的其它倍數也一樣)。 用這樣的限制使時間戳數據變得很講究(要求合適的方法可容易地被找到)。從今以後每136 年，就會有200picosecond 的間隔，會被忽略掉，64 個比特欄位將全部置為0 ，按照慣列它將被解釋為一個無效的或者不可獲得的時間戳。
SNTP報文格式
NTP 和SNTP 是用戶數據報協定( UDP) 的客戶端 [POS80 ]，而UDP自己是網際協定( IP) [DAR81 ] 的客戶端. IP 和UDP 報頭的結構在被引用的指定資料里描述，這裡就不更進一步描述了。UDP的連線埠是123，UDP頭中的源斷口和目的斷口都是一樣的，保留的UDP頭如規範中所述。
以下是SNTP 報文格式的描述，它緊跟在IP 和UDP 報頭之後。SNTP的訊息格式與RFC-1305中所描述的NTP格式是一致的，不同的地方是：
一些SNTP的數據域已被封裝，也就是說已初始化為一些預定的值。NTP 訊息的格式被顯示如下。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 根延遲 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 根差量 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 參考標識符 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 參考時間戳(64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 原始時間戳(64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 接受時間戳 (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 傳送時間戳(64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| 認證符(可選項) (96) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
如下一部分描述，在SNTP 里大多數這些欄位被預規定的數據給賦初值。為完整起見，每個欄位的功能在下面被簡要總結。
1. 閏秒標識器：這是一個二位碼，預報當天最近的分鐘裡要被插入或刪除的閏秒秒數。用1/0表示，分別說明如下：
LI Value 含 義
--------------------------------------------------------------------------------------00 0 無預告
01 1 最近一分鐘有61秒
10 2 最近一分鐘有59秒
11 3 警告狀態（時鐘未同步）
2. 版本號：這是一個三bits的整數，表示NTP的版本號，現在為3。
3. 模式：這是一個三bits的整數，表示模式，定義如下：
mode 含 義
0 保留
1 對稱性激活
2 被動的對稱性
3 客戶端幾
4 伺服器
5 廣播
6 為NTP控制性系保留
7 為自用保留
在點對點模式下，客戶端機在請求中設定此欄位為3，伺服器在回答時設定此欄位為4；在廣播模式下，伺服器在回答時設定此欄位為5。
4. stratum（層）：這是一個8bits的整數（無符號），表示本地時鐘的層次水平，數值定義如下：
stratum 含 義
0 未指定或難以獲得
1 主要參考（如無線電時鐘鐘）
2-15 第二參考（通過NTP/SNTP）
16-255 保留
5．測試間隔：八位signed integer，表示連續信息之間的最大間隔，精確到秒的平方及。本欄位的值從4（16s）到14（16284s）；然而，大多數套用使用6（64s）到10（1024s）。
6．精度：八位signed integer，表示本地時鐘精度，精確到秒的平方級。值從-6（主平）到-20（微妙級時鐘）。
7. 根時延：32位帶符號定點小數，表示在主參考源之間往返的總共時延，以小數位後15~16bits。數值根據相關的時間與頻率可正可負，從負的幾毫秒到正的幾百毫秒。
8. 根離散：32位帶符號定點小數，表示在主參考源有關的名義錯誤，以小數位後15~16bits。範圍：0~幾百毫秒。
9. 參考時鐘標識符：32bits，用來標識特殊的參考源。在stratum 0（未指定）或stratum 1（基本參考）的情況下，該欄位以四個八位位元組，左對齊，零填充的string表示。當沒有NTP枚舉時，使用下列ASCII標識符：
階層 代碼 意思
----------------------------------------------------------------
1 pps 精度校準源，例如ATOM(原子鐘)，PPS代表(
每秒脈衝精度源)，等等
1 service 除了一般的NTP報時服務外，例如ACTS
(計算機自動化報時服務)，TIME（UDP/Time協定)，
TSP(Unix 報時服務協定)，DTSS.
(數位化時間同步服務)，等等
1 radio 一般的收音機服務，帶有callsigns，例如CHU，
DCF77， MSF， TDF， WWV， WWVB， WWVH，等等
1 nav 無線電導航系統，例如OMEG(歐米加導航系統)，
LORC(遠距離無線電導航系統)，等等
1 satellite 一般的衛星業務，例如GOES(地球同步軌道環境衛星)，
GPS(全球衛星定位服務)，等等
2 address 二級參考(4個八位二進制位元組表示的NTP伺服器網際網路
地址）
--------------------------------------------------------------------------------
10. 參考時間戳：64bits時間戳，本地時鐘被修改的最新時間。
11. 原始時間戳：客戶端傳送的時間，64bits。
13. 傳送時間戳：服務端送出應答的時間，64bits。
14. 認證符（可選項）：當NTP的認證機制已運行後，這個欄位包含認證者的信息（參見RFC1305 中的附屬檔案C）。在SNTP中本欄位一般被來報輸入訊息所忽略，也不用在輸出訊息中。
SNTP客戶端操作
單播客戶端初始化SNTP 報文首部，再把訊息傳送到伺服器，然後從伺服器回復的報文中剝去時間包。為此，上面提到的所有報文首部欄位，除第一個八位位元組外都設定成0。 在這個八位位元組里Li 欄位設定為0( 沒有警告) 和方式欄位設定為3(客戶端)。VN 欄位必須同NTP 或者SNTP 伺服器的軟體版本一致；但是，NTP 版本3( RFC 1305)的伺服器也將接受第2( RFC 1119) 版本的訊息以及版本1( RFC 1059)的訊息，而NTP 版本2伺服器也將接受NTP 為版本1的訊息。版本0 ( RFC 959) 訊息不再被支持。因為今天網際網路已有了NTP 伺服器操作的3個版本，推薦VN 欄位設定1。
在單播及廣播方式下，單播伺服器回答及廣播以上所述的所有欄位；但是，在SNTP下，各欄位中，只有傳送時間戳在非零情況下才有明確的意思.這個欄位的整數部分包含伺服器此刻的時間，其格式與UDP/TIME 協定相同[POS83].這個欄位的fraction部分通常是有效的, SNTP的精確度證明可以精確到秒。如果傳送用時間戳欄位是全0，則該訊息將被忽略。
在廣播方式下，客戶端沒有附加信息用以計算在伺服器和客戶端之間的傳播延遲，因為在此方式下，傳送用時間戳和接收時間戳欄位是沒有意義的。即使在單播方式，大多數客戶端也會選擇忽略原始時間戳和接收時間戳欄位。但是，在單播方式下，一種簡單的計算可以用來計算與伺服器有關的往返傳播延遲d及本地時鐘補償t，通常對在數十毫秒內。為此，客戶端在請求包中將本地時鐘時間按NTP的格式寫入源時間戳。當收到答覆時，客戶端將目的時間戳作為到達時間，並根據它的本地時鐘，將其轉變成NTP格式。下述表格總結4個時間戳。
用時間戳名字 ID 產生
------------------------------------------------------------
原始時間戳 T1 時間請求由客戶端送
收到時間戳 T2 時間請求在伺服器收到
傳送時間戳 T3 時間答覆通過伺服器送
目的地時間戳 T4 時間答覆在客戶端收到
往返傳播延遲d和本地時鐘補償t定義為：
D =( T4 - T1) - ( T2 - T3)
T =(( T2 - T1) +( T3 - T4)) /2。
下述表格是SNTP客戶端操作的總結。在表格里顯示有兩種推薦的錯誤檢查方式。在全部NTP 版本里，如果Li 欄位為3；或者階層欄位不在第1-15範圍里；或者傳送用時間戳是0，伺服器決不同步或者不予同步成過去24小時內有效的時間源。在客戶端的判斷中，保留欄位值也可能被檢查。 是否相信傳送用時間戳取決於對這些欄位中的一個或多個欄位的有效性判斷。
欄位名 請求 回答
-------------------------------------------------------------
Li 0 閏秒指示器； 如果是3
(非同步)，則放棄該訊息
VN 1( 參見正文) 忽略
方式 3( 客戶端) 忽略
階層 0 忽略
輪詢 0 忽略
精度 0 忽略
根延遲 0 忽略
根差量 0 忽略
參考標識符 0 忽略
參考時間戳 0 忽略
原始用時間戳 0 忽略( 參見正文)
收到用時間戳 0 忽略( 參見正文)
傳送天的時間戳 0 時間； 如果是0
(非同步)，則忽略該訊息
Authenticator. (不使用) 忽略
SNTP伺服器操作
SNTP 伺服器與NTP 或者SNTP客戶端操作的模式是一種沒有持久狀態的RPC 模式。全套的NTP 算法用來支持冗餘校驗和不同的網路路徑，SNTP伺服器通常不實現全套的NTP 算法，建議一台SNTP 伺服器只與一個外部同步的時鐘源一道操作，例如一台可靠的無線電時鐘。這樣的話，伺服器總是工作在階層1。
伺服器可以工作在單播方式或廣播方式或兩者同時都用。當單播方式的伺服器得到一條請求訊息時，就在NTP或者SNTP 的來報頭裡修改特定欄位，並把訊息返回給傳送人，也許還使用了與請求相同的信息緩衝區。如果不同步到一台正確操作的無線電時鐘的話，伺服器可能也可能不回答請求，但是回答是首選的，因為可達性可以忽略同步狀態如何。在單播方式下，VN 和poll欄位被完整地複製到應答包中的相同欄位。如果請求的方式欄位是3(客戶端)，那么在答覆過程中它設定成4(伺服器)；否則，為了與NTP規範相符，這個欄位設定成2(被動的對稱性)。
在廣播方式下，伺服器只有在已同步的情況下，才發訊息給一個正常運行的參考時鐘。在此方式下， VN 欄位設定成3(針對當前的SNTP 版本)，方式欄位設成5(廣播)。欄位poll設定伺服器測試間隔，接近秒的平方。一台伺服器既支持廣播方式，同時也支持單播方式，這是非常合乎需要的。這對一些潛在的廣播客戶端來說尤其必要，因為這樣做，能使用客戶端機/伺服器的訊息來計算傳播延遲，這一方法要優於只定時接收廣播訊息的方法。
在單播方式和廣播方式下保留的欄位被同樣地設定。假定伺服器是被同步成一台無線電時鐘或者其它正確的主要參考源，則階層欄位設定為1(主要伺服器)，Li 欄位設定為0；如果不是，階層欄位設定0，Li 欄位設定3。精度欄位的設定反映出本地時鐘的最大的讀數誤差。對所有的實際情況來說，在NTP格式里被計算的值是小數點右邊的有效數值，值被表示成負數時間戳形式。為了主伺服器，根延遲和根差量欄位可以設定成0，根差量欄位能設定成任意數值(表示時鐘的最大的期望誤差值)。參考標識符設定指明主要參考源，如在上面在表格里說明的。
這些時間戳欄位被設定如下。如果伺服器未被同步或是首先啟動的話，全部時間戳欄位設定成零。如果同步，參考用時間戳設定成最後更新時間（來源於無線電時鐘）或者設定成訊息被送出的時間（如果更新時間不可以獲得）。接收時間戳和傳送時間戳欄位設定成當時訊息發出的時間。在單播方式下，原始時間戳欄位直接從請求包的傳送時間戳拷貝過來。因為客戶端要用它來檢查應答，所以複製完整很重要。用廣播方式下，這個欄位被設定成訊息被送出的時間。下面的表格總結這些操作。
欄位名 請求 回答
----------------------------------------------------------
Li 忽略 0(正常)， 3
(非同步)
VN 1， 2 或者3 3 或者從請求包中拷貝
方式 3(參見正文) 2，4 或者5(參見正文)
階層 忽略 伺服器階層
投票 忽略 拷貝請求包
精度 忽略 伺服器精度
根延遲 忽略 0
根差量 忽略 0(參見正文)
參考標識符 忽略 來源標識符
參考時間戳 忽略 0 或者當前的時間
創造時間戳 忽略 0 或者當前的時間或者從
傳送時間戳請求複製
收到時間戳 忽略 0 或者當前的時間
傳送時間戳 (參見正文) 0 或者當前的時間
Authenticator 忽略 (不使用)
當例如可能發生在剛啟動或在運行期間主要參考源不起作用時，有一些多數客戶端允許的無效時間戳的範圍。一台運行不正常的伺服器的最重要的標誌是Li 欄位，其中一3 的值表明一種非同步的狀態。當這值被出現時，客戶端應該丟掉該條伺服器訊息，而不管其它欄位的內容。
參考資料
[DAR81 ]波斯特爾， J.，" 網際協定 - DARPA網際計畫協定說明"，標準5，1981 年9月， DARPA， RFC 791。
[MIL92 ] Mills, D，" 網路時間協定( 第3 版本) 說明，實現和分析。 RFC 1305，德拉瓦大學， 1992 年3月。
[POS80 ]波斯特爾， J.，" 用戶數據報協定"，標準6， RFC 768， USC/Information 科學研究所， 1980 年8月。
[POS83 ]波斯特爾， J. 和K. Harrenstien，" 時間協定"，標準26， RFC 868， USC/Information 科學研究所， SRI， 1983 年5月。
