|
|
簡單網絡時間協議
（sntp：simple network time protocol）
sntpv4 由 ntp 改編而來，主要用來同步因特網中的計算機時鐘。 sntp 適用於無需完全使用 ntp 功能的情況。比較以前的 ntp 和 sntp 版本， sntpv4 的引入沒有改變 ntp 規範和原有實現過程，它是對 ntp 的進一步改進，支持以一種簡單、無狀態遠程過程調用模式執行精確而可靠的操作，這類似於 udp / time 協議。
強烈建議 sntp 僅用於同步子網的末端情況。 sntp 客戶機操作於子網末端，一個 sntp 客戶機不應靠另一個 sntp 客戶機來同步。 sntp 服務器位於子網根部（即第 1 層），且不應有其它時間同步源，除了有用的可靠無綫電波（radio）及調製解調器時間服務器外。一般通過冗餘時間同步源、不同子網路徑及完整的 ntp 運行算法等共同作用，可實現基本服務器的完全可靠度。如果所有的時間同步源失效或大部分時間不準確，主同步時間源就會切換到使用無綫電波或調製解調器，所以，在主服務器上使用 sntp 而不是 ntp 時要多加註意。
與 ntp 及 sntp 相比， sntpv4 中唯一改進了協議頭使其適用於 ipv6 和 osi 尋址。此外 sntpv4 包括了對基本 v3 模式的可選項擴展，包括任意播模式（anycast）和認證方式（用於組播和任意播模式）。 |
|
| （SNTP：Simple Network Time Protocol） |
|
RFC 1305 [MIL92] 指定網絡時間協議(NTP)來同步因特網上的計算機時鐘。它提供了全面訪問國傢時間和頻率傳播服務的機製，組織時間同步子網並且為參加子網每一個地方時鐘調整時間。在今天的因特網的大多數地方， NTP 提供了1-50 ms 的精確度，精確度的大小取决於同步源和網絡路徑等特性。
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的使用。 |
|
象NTP一樣，SNTP 能在單播(點嚮點) 或者廣播(點對多點) 模式中操作。單播客戶端發送請求到服務器並且期望從那裏得到答復，並且（可選的），得到有關服務器的往返傳播延遲和本地時鐘補償。廣播服務器周期性地送消息給一指定的IP 廣播地址或者IP多播地址，並且通常不期望從客戶端得到請求，廣播客戶端監聽地址但通常並不給服務器發請求。一些廣播服務器可能選擇對客戶端作出反應請求以及發出未經請求廣播消息；同時一些廣播客戶端可能會送請求僅為了確定在服務器和客戶端之間的網絡傳播延遲。
在單播方式下，客戶端和服務器的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使用在RFC 1305 及其以前的版本所描述標準NTP時間戳的格式。與因特網標準標準一致， NTP 數據被指定為整數或定點小數，位以big-endian風格從左邊0位或者高位計數。除非不這樣指定，全部數量都將設成unsigned的類型，並且可能用一個在bit0前的隱含0填充全部字段寬度。
因為SNTP時間戳是重要的數據和用來描述協議主要産品的，一個專門的時間戳格式已經建立。 NTP用時間戳表示為一64 bits unsigned 定點數，以秒的形式從1900 年1月1 日的0：0：0算起。整數部分在前32位裏，32bits（seconds Fraction）用以表示秒以下的部分。在Seconds Fraction 部分，無意義的低位應該設置為0。這種格式把方便的多精度算法和變換用於UDP/TIME 的表示（單位：秒），但使得轉化為ICMP的時間戳消息表示法(單位：毫秒)的過程變得復雜了。它代表的精度是大約是200 picoseconds，這應該足以滿足最高的要求了。
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 ，按照慣列它將被解釋為一個無效的或者不可獲得的時間戳。 |
|
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。
12. 接受時間戳：服務端接受到的時間，64bits。
13. 傳送時間戳：服務端送出應答的時間，64bits。
14. 認證符（可選項）：當NTP的認證機製已運行後，這個字段包含認證者的信息（參見RFC1305 中的附件C）。在SNTP中本字段一般被來報輸入消息所忽略，也不用在輸出消息中。 |
|
SNTP客戶端與NTP/SNTP 服務器通信的模式是一個非持久狀態的遠程過程調用。在單播方式，客戶端發給服務器(方式3) 請求並且期望服務器答復 (方式4)。 在廣播方式，客戶端送並不請求衹是等待一臺或更多的服務器的廣播消息(方式5) ，這取决於設置。 根據客戶端和服務器設置，單播客戶端和廣播服務器通常在從64 給1024 s 的間隔裏發送消息。
單播客戶端初始化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 服務器與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。
[DEE89 ]迪林， S.，" IP 多播 的主機擴展。 標準5， RFC 1112，斯坦福大學， 1989 年8月。
[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月。 |