SNTP是簡單網絡時間協議（Simple Network Time protocol）的簡稱，它是目前Internet網上實現時間同步的一種重要工程化方法。本文對SNTP協議的工作原理、工作模式、時間戳格式、信息幀格式進行了研究，最後對SNTP協議的應用提出一些有益的建議。
關鍵詞:SNTP;時間同步;時間戳格式;報文格式
中圖法分類號:TP393.04 文獻標識碼: A
Title Analysis for SNTP protocol
LIN Xiaofan , LI Chao , CHEN Gaoyun
（Department of software engineering, Chengdu university of information technology, chengdu 610225）
Abstract:
SNTP is abbreviation for simple network time protocol. At present it is an important engineering method for time synchronization in Internet. This paper describe principle,mode,timestamp format,message format of SNTP, finally we give some advice for application.
Key words: SNTP; time synchronization ; ,timestamp format ; message format
0引言
在一些需要精確時間同步的場合，如電力通訊、通信計費、分佈式網絡計算、氣象預報等，僅靠計算機本身提供的時鐘信號是遠遠不夠的。據統計，計算機時間與國際標準時間偏差在1分鐘以上的佔到90%以上，這是因爲計算機的時鐘信號來源於自帶的簡單晶體振盪器，而這種晶體振盪器守時性很差，調整好時間後，一般每天都有都有幾秒鐘的時間漂移。上面提及的應用對時間準確度的要求均是需要秒級的，NTP協議就是提供精確網絡時間服務的一種重要方法。NTP協議是網絡時間協議的簡稱（Network Time Protocol），目前它被廣泛用於在Internet上進行計算機時鐘同步，它通過提供完全的機制來訪問國際標準時間，在大多數情況下，NTP根據同步源和網絡路徑的不同，能夠提供1-50MS的時間精確度。
NTP協議爲了保證高度的精確性，需要很複雜算法，但是在實際很多應用中，秒級的精確度就足夠了，在這種情況下，SNTP協議出現了，它通過簡化原來的訪問協議，在保證時間精確度的前提下，使得對網絡時間的開發和應用變得容易。SNTP主要對NTP協議涉及有關訪問安全、服務器自動遷移部分進行了縮減。
SNTP協議目前的版本號是SNTP V4，它能與以前的版本兼容，更重要的是SNTP能夠與NTP協議具有互操作性，即SNTP客戶可以與NTP服務器協同工作，同樣NTP客戶也可以接收SNTP服務器發出的授時信息。這是因爲NTP和SNTP的數據包格式是一樣的，計算客戶時間、時間偏差以及包往返時延的算法也是一樣的。因此NTP和SNTP實際上是無法分割的。
本文主要對SNTP協議進行分析，主要涉及協議工作原理、工作模式、時間戳格式、報文格式，最後對SNTP協議的應用提出一些建議。
1 SNTP協議工作原理
SNTP協議採用客戶/服務器工作方式，服務器通過接收GPS信號或自帶的原子鐘作爲系統的時間基準，客戶機通過定期訪問服務器提供的時間服務獲得準確的時間信息，並調整自己的系統時鐘，達到網絡時間同步的目的。客戶和服務器通訊採用UDP協議，端口爲123。授時原理可以用下面的圖作一個描述：
圖1：授時原理圖
T1:客戶方發送查詢請求時間(以客戶方時間系統爲參照)，標記爲Originate Timestamp；
T2:服務器收到查詢請求時間(以服務器時間系統爲參照)，標記爲Receive Timestamp；
T3:服務器回覆時間信息包時間(以服務器時間系統爲參照)，標記爲Transmit Timestamp；
T4:客戶方收到時間信息包時間(以客戶方時間系統爲參照)，標記爲Destination Timestamp；
D1：請求信息在網上傳播所消耗的時間
D2：回覆信息在網上傳播所消耗的時間
現已知T1 、T2、T3、T4，希望求得 以調整客戶方時鐘有：
(1)
假設請求和回覆在網上傳播的時間相同，即D1=D2，則可解得：
(2)
可以看到， 、D只與T2T1差值、T3T4差值相關，而與T2T3差值無關，即最終的結果與服務器處理請求所需的時間無關。據此，客戶方A即可通過T1、T2、T3、T4計算出時差θ去調整本地時鐘。
2 SNTP協議工作模式
SNTP協議可以使用單播、廣播或多播模式進行工作。單播模式是指一個客戶發送請求到預先指定的一個服務器地址，然後從服務器獲得準確的時間、來回時延和與服務器時間的偏差。廣播模式是指一個廣播服務器週期地向指定廣播地址發送時間信息，在這組地址內的服務器偵聽廣播並且不發送請求。多播模式是對廣播模式的一種擴展，它設計的目的是對地址未知的一組服務器進行協調。在這種模式下，多播客戶發送一個普通的NTP請求給指定的廣播地址，多個多播服務器在此地址上進行偵聽。一旦收到一個請求信息，一個多播服務器就對客戶返回一個普通的NTP服務器應答，然後客戶依此對廣播地址內剩下的所有服務器作同樣的操作，最後利用NTP遷移算法篩選出最好的三臺服務器使用。
客戶和服務器地址可以採用通常的IPV4或IPV6。IANA保留IPV4地址224.0.1.1，保留IPV6以：101結束的地址作爲NTP廣播或多播的地址。用戶也可以根據具體情況，建立自己的地址空間，只要不與已經使用的地址空間衝突。
爲了侷限廣播或多播服務佔用太多的網絡資源，調節多播信息IP頭中的TTL值到一個合理的水平非常重要。只有在地址範圍內的多播客戶能接收到多播信息，只有在地址範圍內的服務器組能夠對客戶的響應進行應答。在Internet上，SNTP廣播或多播客戶極易受到來自其它SNTP服務器的攻擊，因此在Internet上使用該服務時，一定要採用訪問控制和加密的措施。
3 SNTP數據格式
SNTP協議同其它的網絡應用層協議一樣，都具有一定的數據格式，它主要涉及時間的表示，即時間戳的格式，數據如何組幀在網絡上傳輸，即信息幀格式。
3.1 SNTP時間戳格式
SNTP時間戳是該協議的重要產品，用來對時間進行精確表示。它由一個64位無符號浮點數組成，整數部分爲頭32位，小數部分爲後32位；單位爲秒，時間相對於1900年1月零點。它能表示的最大數字爲4，294，967，295秒，同時具有232PS的精確性，這能滿足最苛刻的時間要求。值得注意的是在1968年的某一個時間（2，147，483，648秒）時間戳的最高位已被設置爲1，在2036年的某一個時間（4，294，967，295秒）64位字段將會溢出，所有位將會被置爲零，此時的時間戳將會被視爲無效。爲了解決這一問題，儘量延長SNTP時間戳的使用時間，一種可能的辦法爲：如果最高位設置爲1，UTC時間範圍爲1968-2036之間，時間計算起點從1900年1月0點0分0秒開始計算；如果最高位設置爲0，UTC時間範圍爲2036-2104之間，時間計算起點從2036年2月7日6點28分16秒開始計算；
3.2 SNTP信息幀格式
SNTP協議是UDP協議的客戶，它利用UDP的123端口提供服務，SNTP客戶在設置請求信息時要把UDP目的端口設置爲該值，源端口可以爲任何非零值，服務器在響應信息中對這些值進行交換。同其它應用層協議一樣，SNTP協議的數據通信也是按數據幀的格式進行，下圖是對SNTP信息幀格式的描述：
圖2：SNTP信息幀格式
LI：當前時間閏秒標誌。字段長度爲2位整數，只在服務器端有效。取值定義爲：
LI=0：無警告；
LI=1：最後一分鐘是61秒；
LI=2：最後一分鐘是59秒；
LI=3：警告（時鐘沒有同步）
服務器在開始時，LI設置爲3，一旦與主鍾取得同步後就設置成其它值。
VN：版本號。字段長度爲3位整數，當前版本號爲4。
Mode：指示協議模式。字段長度爲3位，取值定義爲：
Mode=0：保留
Mode=1：對稱主動；
Mode=2：對稱被動；
Mode=3：客戶；
Mode=4：服務器；
Mode=5：廣播；
Mode=6：保留爲NTP控制信息；
Mode=7：保留爲用戶定義；
在單播和多播模式，客戶在請求時把這個字段設置爲3，服務器在響應時把這個字段設置爲4。在廣播模式下，服務器把這個字段設置爲5。
Stratum：指示服務器工作的級別，該字段只在服務器端有效，字段長度爲8位整數。取值定義爲：
Stratum=0：故障信息；
Stratum=1：一級服務器；
Stratum=2-15：二級服務器；
Stratum=16-255：保留；
Poll Interval：指示數據包的最大時間間隔，以秒爲單位，作爲2的指數方的指數部分，該字段只在服務器端有效。字段長度爲8位整數，取值範圍從4-17，即16秒到131,072秒。
Precision：指示系統時鐘的精確性，以秒爲單位，作爲2的指數方的指數部分，該字段只在服務器端有效。字段長度爲8位符號整數，取值範圍從-6到-20。
Root Delay：指示與主時鐘參考源的總共往返延遲，以秒爲單位，該字段只在服務器端有效。字段長度爲32位浮點數，小數部分在16位以後，取值範圍從負幾毫秒到正幾百毫秒。
Root Dispersion：指示與主時鐘參考源的誤差，以秒爲單位，該字段只在服務器端有效。字段長度爲32位浮點數，小數部分在16位以後，取值範圍從零毫秒到正幾百毫秒。
Reference Identifier：指示時鐘參考源的標記，該字段只在服務器端有效。對於一級服務器，字段長度爲4字節ASCII字符串，左對齊不足添零。對於二級服務器，在IPV4環境下，取值爲一級服務器的IP地址，在IPV6環境下，是一級服務器的NSAP地址。
Reference Timestamp：指示系統時鐘最後一次校準的時間，該字段只在服務器端有效，以前面所述64位時間戳格式表示。
Originate Timestamp：指示客戶向服務器發起請求的時間，以前面所述64位時間戳格式表示。
Transmit Timestamp：指示服務器向客戶發時間戳的時間，以前面所述64位時間戳格式表示。
Authenticator（可選）：當需要進行SNTP認證時，該字段包含密鑰和信息加密碼。
4 SNTP服務器的基本工作過程
下面以最常用的SNTP工作模式-單播模式，來說明SNTP服務器的工作過程：
SNTP服務器在初始化時，Stratum字段設置爲0，LI字段設置爲3，Mode 字段設置爲3，Reference Identifier字段設置爲ASCII字符“INIT”，所有時間戳信息設置爲0；
一旦SNTP服務器與外部時鐘源取得同步後，進入工作狀態，Stratum字段設置爲1，LI字段設置爲0，Reference Identifier字段設置爲外部時鐘源的ASCII字符，如“GPS”，Precision字段設置爲-6到-20之間的一個數值，通常設置爲-16。VN字段設置爲客戶端請求信息包的VN字段值，Root Delay和Root Dispersion字段通常設置爲0，Reference Timestamp字段設置爲從外部時鐘源最新取得的時間，Originate Timestamp字段設置爲客戶請求包的Transmit Timestamp字段值，Transmit Timestamp字段設置爲服務器發出時間戳給客戶的時間。
SNTP服務器在工作過程中，如果與外部時鐘源失去同步，Stratum字段設置爲0，Reference Identifier字段設置爲故障原因的ASCII字符，如：“LOST”，此時客戶收到這個信息時，要丟棄服務器發給它的時間戳信息。
5 SNTP應用的建議
爲了使SNTP更好地在網絡中進行應用，尤其是在設計和管理有大量計算機需要授時的情況下，有以下建議：
1. 儘量在本地局域網內部部署SNTP服務器，而不要採用Internet網上的公用SNTP服務器，因爲Internet網絡的時延不確定性，服務質量得得不到保證，會對授時的精度產生很大影響；
2. 客戶端對服務器的授時請求週期要大於1分鐘，以免造成SNTP服務器資源迅速消耗，而不能及時響應客戶的請求；
3. 當網絡中客戶機數目大於500臺時，應該配置多臺SNTP服務器，以達到要求的授時精度。SNTP最多每秒種能同時響應500個請求，一旦超過這一數目，授時的精確度就得不到保證；
4. 在需要高可靠授時的應用，最好配備多臺SNTP服務器，利用DNS系統實現負載均衡和集羣；
5. 客戶端應該能夠識別服務器端的故障，一旦發現Stratum字段爲0，應該立刻丟棄服務器發來的時間戳，轉向其它服務器取時間，以避免授時錯誤；
6 結論
SNTP協議是目前網絡上提供精確時間服務的一種有效手段，但是很少有人對它進行詳細的分析，我們所作的工作對於開發者和網絡管理人員來說都是非常有益的，對於開發者來說，能夠根據協議開發自己的SNTP服務器，同時對SNTP協議的不足之處進行改進；對於網絡管理者來說，在理解SNTP工作原理和方式的基礎上，通過網絡的優化，使SNTP服務發揮最佳的效能。
致謝：
在此，我們要感謝西南電信技術研究所的丘明高工提供的幫助，讓我們順利完成該項目的研究。
參考文獻：
[1] Postel, J. Time protocol[R]. DARPA Working Group Report RFC-868, USC Information Sciences Institute, May 1983.
[2]Mills, D.L. NTP Clock Discipline Principles[R]. DARPA Working Group Report RFC-1305, USC Information Sciences Institute, March 1992.
[3] 謝希仁，計算機網絡（第四版）［M］.北京：電子工業出版社，2003.
作者簡介
林曉帆(1968年-)、男、四川成都、講師、碩士、主要研究方向：計算機網絡、軟件工程；李超（1964年-）男、四川成都、教授、碩士生導師、主要研究方向：計算機網絡、軟件工程；陳高雲(1963年-)、女、、副教授、碩士生導師、主要研究方向：計算機網絡、軟件工程；
發表評論評論 (3 個評論)
組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[email protected]
譯者：陳華鵬(shenmusic [email protected])
譯文發佈時間：2001-7-14
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。
Network Working Group
Request for Comments: 1769
Obsoletes: 1361
Category: Informational
D. Mills
University of Delaware
March 1995
本備忘錄的狀態
本備忘錄爲Internet community提供了信息，但不規定任何一種類型的 Internet 標準。 本備忘錄的分發沒有限制。
摘要
本備忘錄描述簡單網絡時間協議(SNTP)，這是網絡時間協議(NTP) 的一個改寫本，NTP協議適用於同步因特網上的計算機時鐘。當不須要實現RFC 1305 所描述的NTP完全功能的情況下，可以使用SNTP。它能用單播方式(點對點)和廣播方式(點對多點)操作。它也能在IP 多播方式下操作（可提供這種服務的地方）。SNTP與當前及以前的NTP版本並沒有大的不同。但它是更簡單，是一個無狀態的遠程過程調用(RPC)，其準確和可靠性相似於UDP/TIME 協議在RFC868描述中所預期的。
本備忘錄淘汰相同的標題的RFC 1361。它的目的是解釋用廣播方式操作的協議模式，提供某些地方的進一步說明並且改正一些印刷上的錯誤。在NTP版本3 RFC 1305中說明的工作機理對SNTP的實現不是完全需要的。本備忘錄的分發沒有限制。
1. 介紹
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的使用。
2. 工作模式與地址分配
象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 多播地址才被使用。
3. NTP時間戳格式
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，這應該足以滿足最高的要求了。
注意，從1968 年起，最高有效位(整數部分的0 bit位) 已經被確定，64 位比特字段在2036 年將溢出。 如果NTP或者SNTP在2036 年還在使用的話，一些外部方法將有必要用來調整與1900年及2036 年有關的時間 (136 年的其它倍數也一樣)。 用這樣的限制使時間戳數據變得很講究(要求合適的方法可容易地被找到)。從今以後每136 年，就會有200picosecond 的間隔，會被忽略掉，64 個比特字段將全部置爲0 ，按照慣列它將被解釋爲一個無效的或者不可獲得的時間戳。
4. NTP 報文格式
NTP 和SNTP 是用戶數據報協議( UDP) 的客戶端 [POS80 ]，而UDP自己是網際協議( IP) [DAR81 ] 的客戶端. IP 和UDP 報頭的結構在被引用的指定資料裏描述，這裏就不更進一步描述了。UDP的端口是123，UDP頭中的源斷口和目的斷口都是一樣的，保留的UDP頭如規範中所述。以下是SNTP 報文格式的描述，它緊跟在IP 和UDP 報頭之後。SNTP的消息格式與RFC-1305中所描述的NTP格式是一致的，不同的地方是：
一些SNTP的數據域已被風裝，也就是說已初始化爲一些預定的值。NTP 消息的格式被顯示如下。
如下一部分描述，在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中本字段一般被來報輸入消息所忽略，也不用在輸出消息中。
5. 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 (不使用) 忽略
6. 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 的值表明一種非同步的狀態。當這值被出現時，客戶端應該丟掉該條服務器消息，而不管其它字段的內容。
7. 參考資料
[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月。
8. 安全考慮
安全問題沒在這個備忘錄裏討論。
9. 作者的地址
David L. Mills
電工程處
特拉華大學
紐瓦克， DE 19716
電話呼叫： ( 302) 831-8247
電子郵件： [email protected].
//計算校驗和
USHORT checksum(USHORT *buffer,int size)
{
unsigned long cksum=0;
while(size>1)
{
cksum+=*buffer++;
size-=sizeof(USHORT);
}
if(size)
{
cksum+=*(UCHAR *)buffer;
}
//將32位數轉換成16
while (cksum>>16)
cksum=(cksum>>16)+(cksum & 0xffff);
return (USHORT) (~cksum);
}
UDP/TCP報頭中的校驗和的計算比較複雜的，要用到 UDP/TCP僞首部：先要填充僞首部各個字段，然後再將UDP/TCP報頭以後（包括報頭）的數據附加到僞首部的後面，再對位首部使用上述校驗和計算，所得到的值纔是UDP/TCP報頭部分的校驗和。
位首部可以用如下的結構體表示：
typedef struct{
ULONG sourceip; //源IP地址
ULONG destip; //目的IP地址
BYTE mbz; //置空(0)
BYTE ptcl; //協議類型
USHORT plen; //TCP/UDP數據包的長度(即從TCP/UDP報頭算起到數據包結束的長度 單位:字節)
}Psd_Header;
這個過程是一個很繁瑣的過程，計算過幾次後再也忍受不了做這樣重複的工作，於是寫了一個通用的計算函數。這個函數使用起來我感覺非常方便：先封裝好你的數據包（完整的，包括以太頭），然後將數據包的首地址作爲參數，調用該函數即可。函數將幫你完成IP報頭以及UDP/TCP報頭部分校驗和的計算。
//-------------------------------------------------------------------------
// PacketCheckSum
// 計算數據包的校驗和
// 參數:packet-待處理數據(將封裝好的數據包的指針)
//-------------------------------------------------------------------------
void PacketCheckSum(unsigned char packet[])
{
Dlc_Header *pdlc_header=NULL; //以太頭指針
Ip_Header *pip_header=NULL; //IP頭指針
unsigned short attachsize=0; //傳輸層協議頭以及附加數據的總長度
pdlc_header=(Dlc_Header *)packet;
//判斷ethertype,如果不是IP包則不予處理
if(ntohs(pdlc_header->ethertype)!=0x0800) return;
pip_header=(Ip_Header *)(packet+14);
//TCP包
if(0x06==pip_header->proto)
{
Tcp_Header *ptcp_header=NULL; //TCP頭指針
Tcp_Psd_Header *ptcp_psd_header=NULL;
ptcp_header=(Tcp_Header *)(packet+14+((pip_header->ver_len)&15)*4);
attachsize=ntohs(pip_header->total_len)-((pip_header->ver_len)&15)*4;
ptcp_psd_header=(Tcp_Psd_Header *)malloc(attachsize+sizeof(Tcp_Psd_Header));
if(!ptcp_psd_header) return;
memset(ptcp_psd_header,0,attachsize+sizeof(Tcp_Psd_Header));
//填充僞TCP頭
ptcp_psd_header->destip=pip_header->destIP;
ptcp_psd_header->sourceip=pip_header->sourceIP;
ptcp_psd_header->mbz=0;
ptcp_psd_header->ptcl=0x06;
ptcp_psd_header->tcpl=htons(attachsize);
//計算TCP校驗和
ptcp_header->chksum=0;
memcpy((unsigned char *)ptcp_psd_header+sizeof(Tcp_Psd_Header),
(unsigned char *)ptcp_header,attachsize);
ptcp_header->chksum=checksum((unsigned short *)ptcp_psd_header,
attachsize+sizeof(Tcp_Psd_Header));
//計算ip頭的校驗和
pip_header->checksum=0;
pip_header->checksum=checksum((unsigned short *)pip_header,20);
return;
}
//UDP包
if(0x11==pip_header->proto)
{
Udp_Header *pudp_header=NULL; //UDP頭指針
Udp_Psd_Header *pudp_psd_header=NULL;
pudp_header=(Udp_Header *)(packet+14+((pip_header->ver_len)&15)*4);
attachsize=ntohs(pip_header->total_len)-((pip_header->ver_len)&15)*4;
pudp_psd_header=(Udp_Psd_Header *)malloc(attachsize+sizeof(Udp_Psd_Header));
if(!pudp_psd_header) return;
memset(pudp_psd_header,0,attachsize+sizeof(Udp_Psd_Header));
//填充僞UDP頭
pudp_psd_header->destip=pip_header->destIP;
pudp_psd_header->sourceip=pip_header->sourceIP;
pudp_psd_header->mbz=0;
pudp_psd_header->ptcl=0x11;
pudp_psd_header->udpl=htons(attachsize);
//計算UDP校驗和
pudp_header->chksum=0;
memcpy((unsigned char *)pudp_psd_header+sizeof(Udp_Psd_Header),
(unsigned char *)pudp_header,attachsize);
pudp_header->chksum=checksum((unsigned short *)pudp_psd_header,
attachsize+sizeof(Udp_Psd_Header));
//計算ip頭的校驗和
pip_header->checksum=0;
pip_header->checksum=checksum((unsigned short *)pip_header,20);
return;
}
return;
}
需要幾個頭文件，以及庫：
#include <winsock2.h>
#include <windows.h>
#include "packet.h"
#pragma comment(lib,"ws2_32.lib")
最後附上我使用的數據包的結構體（比較多）：
//數據包結構體
#pragma pack(1)
/*物理幀頭結構*/
typedef struct {
BYTE desmac[6]; //目的MAC地址
BYTE srcmac[6]; //源MAC地址
USHORT ethertype; //幀類型
}Dlc_Header;
/*Arp幀結構*/
typedef struct {
USHORT hw_type; //硬件類型Ethernet:0x1
USHORT prot_type; //上層協議類型IP:0x0800
BYTE hw_addr_len; //硬件地址長度:6
BYTE prot_addr_len; //協議地址(IP地址)的長度:4
USHORT flag; //1表示請求,2表示應答
BYTE send_hw_addr[6]; //源MAC地址
UINT send_prot_addr; //源IP地址
BYTE targ_hw_addr[6]; //目的MAC地址
UINT targ_prot_addr; //目的IP地址
BYTE padding[18]; //填充數據
}Arp_Frame;
/*ARP包=DLC頭+ARP幀*/
typedef struct {
Dlc_Header dlcheader;//DLC頭
Arp_Frame arpframe; //ARP幀
}ARP_Packet;
/*IP報頭結構*/
typedef struct {
BYTE ver_len; //IP包頭部長度,單位：4字節
BYTE tos; //服務類型TOS
USHORT total_len; //IP包總長度
USHORT ident; //標識
USHORT frag_and_flags; //標誌位
BYTE ttl; //生存時間
BYTE proto; //協議
USHORT checksum; //IP首部校驗和
UINT sourceIP; //源IP地址(32位)
UINT destIP; //目的IP地址(32位)
}Ip_Header;
/*TCP報頭結構*/
typedef struct {
USHORT srcport; // 源端口
USHORT dstport; // 目的端口
UINT seqnum; // 順序號
UINT acknum; // 確認號
BYTE dataoff; // TCP頭長
BYTE flags; // 標誌（URG、ACK等）
USHORT window; // 窗口大小
USHORT chksum; // 校驗和
USHORT urgptr; // 緊急指針
}Tcp_Header;
//TCP僞首部 用於進行TCP校驗和的計算,保證TCP效驗的有效性
typedef struct{
ULONG sourceip; //源IP地址
ULONG destip; //目的IP地址
BYTE mbz; //置空(0)
BYTE ptcl; //協議類型(IPPROTO_TCP)
USHORT tcpl; //TCP包的總長度(單位:字節)
}Tcp_Psd_Header;
/*UDP報頭*/
typedef struct {
USHORT srcport; // 源端口
USHORT dstport; // 目的端口
USHORT total_len; // 包括UDP報頭及UDP數據的長度(單位:字節)
USHORT chksum; // 校驗和
}Udp_Header;
/*UDP僞首部-僅用於計算校驗和*/
typedef struct tsd_hdr
{
ULONG sourceip; //源IP地址
ULONG destip; //目的IP地址
BYTE mbz; //置空(0)
BYTE ptcl; //協議類型(IPPROTO_UDP)
USHORT udpl; //UDP包總長度(單位:字節)
}Udp_Psd_Header;
/*ICMP報頭*/
typedef struct{
BYTE i_type; //類型 類型是關鍵:0->回送應答(Ping應答) 8->回送請求(Ping請求)
BYTE i_code; //代碼 這個與類型有關 當類型爲0或8時這裏都是0
USHORT i_cksum; //ICMP包校驗和
USHORT i_id; //識別號(一般用進程ID作爲標識號)
USHORT i_seq; //報文序列號(一般設置爲0)
//UINT timestamp; //時間戳
BYTE padding[32];//填充數據
}Icmp_Header;
/*ICMP數據包*/
typedef struct
{
Dlc_Header dlc_header; //以太幀
Ip_Header ip_header; //IP頭
Icmp_Header icmp_header;//ICMP幀
}Icmp_Packet;
/*攻擊信息*/
typedef struct
{
unsigned char flag; //攻擊數據包類型1-arp,2-tcp,3-udp
unsigned int srcip; //攻擊者IP
unsigned char code[33]; //攻擊特徵碼
}Attack_Infor;
#pragma pack()
（RFC1769 ——Simple Network Time Protocol）
本備忘錄的狀況：
本備忘錄爲Internet community提供了信息，但不規定任何一種類型的 Internet 標準。 本備
忘錄的分發沒有限制。
概要
本備忘錄描述簡單網絡時間協議(SNTP)，這是網絡時間協議(NTP) 的一個改寫本，NTP協議
適用於同步因特網上的計算機時鐘。當不須要實現RFC 1305 所描述的NTP完全功能的情況下，
可以使用SNTP。它能用單播方式(點對點)和廣播方式(點對多點)操作。它也能在IP 多播方式下
操作（可提供這種服務的地方）。SNTP與當前及以前的NTP版本並沒有大的不同。但它是更簡單，
是一個無狀態的遠程過程調用(RPC)，其準確和可靠性相似於UDP/TIME 協議在RFC868描述中所
預期的。
本備忘錄淘汰相同的標題的RFC 1361。它的目的是解釋用廣播方式操作的協議模式，提供
某些地方的進一步說明並且改正一些印刷上的錯誤。在NTP版本3 RFC 1305中說明的工作機理對
SNTP的實現不是完全需要的。本備忘錄的分發沒有限制。
目錄
1. 介紹 2
2. 工作模式與地址分配 2
3. NTP時間戳格式 3
4. NTP 報文格式 4
5. SNTP 客戶端操作 6
6. SNTP 服務器操作 7
7. 參考資料 8
8. 安全考慮 9
9. 作者的地址 9
1. 介紹
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的使用。
2. 工作模式與地址分配
象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 多播地址才被使用。
3. NTP時間戳格式
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 ，按照慣列它將被解釋爲一個無效的或者不可獲得的時間
戳。
4. NTP 報文格式
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中本字段一般被來報輸入消息所忽略，也不用在輸出消息中。
5. 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. (不使用) 忽略
6. 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 的值表明一種
非同步的狀態。當這值被出現時，客戶端應該丟掉該條服務器消息，而不管其它字段的內容。
7. 參考資料
[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月。
8. 安全考慮
安全問題沒在這個備忘錄裏討論。
9. 作者的地址
David L. Mills