目前網絡時間服務有哪些協議？

杭州元帥是中科院國家授時中心，使用北京時間。

時間格式:2004年7月26日星期壹09時58分57秒

Time.nist.gov是美國標準與技術協會，使用格林威治時間。

時間格式:5321204-07-2602:00:125000488.3 UTC(NIST)*

私有聲明子睡眠庫“kernel 32”(ByVal dw milliseconds壹樣長)

Dim NoSrv為布爾值

Dim TimeFromNet

私有子窗體_Load()

Winsock 1。“protocol = scktcpprotocol”采用TCP協議。

NetTime "www.time.ac.cn " '首先取中科院國家授時中心的時間。

如果NoSrv或TimeFromNet = " "那麽

如果沒有中科院國家授時中心的時間，則取美國標準技術研究所的時間。

NetTime "time.nist.gov "

如果NoSrv或TimeFromNet = " "那麽

如果不能采用美國標準技術協會的時間，將會報錯。

MsgBox“檢測不到網絡標準時間服務器time.nist.gov！”

其他

為了減少網絡傳輸誤差，第二次采用美國標準技術研究所的時間。

NetTime "time.nist.gov "

如果TimeFromNet = " "那麽

MsgBox“time . NIST . gov，網絡標準時間服務器，超時！”

其他

TimeFromNet = Mid(TimeFromNet，17，8)

TimeFromNet = TimeSerial((小時(TimeFromNet) + 8) Mod 24，分鐘(TimeFromNet)，秒(TimeFromNet))

Time = TimeFromNet '設置系統時間。

如果…就會結束

其他

為了減少網絡傳輸的誤差，對中科院國家授時中心的時間進行了二次取準。

NetTime "www.time.ac.cn "

如果TimeFromNet = " "那麽

MsgBox“www . time . AC . cn，網絡標準時間服務器，超時！”

其他

Time = mid (timefromnet，12，8)'設置系統時間。

如果…就會結束

結束

末端接頭

關閉Winsock子程序。

私有Sub Winsock1_Close()

如果Winsock1。狀態& lt& gt那時關閉了

Winsock1。關閉

如果…就會結束

末端接頭

Winsock接收數據事件。

私有Sub Winsock 1 _ data arrival(ByVal bytes total As Long)

TimeFromNet = String(bytesTotal，" ")

Winsock1。GetData TimeFromNet，vbString，bytesTotal

末端接頭

Winsock錯誤事件

private Sub Winsock 1 _ Error(ByVal Number為整數，Description為字符串，ByVal Scode為Long，ByVal Source為字符串，ByVal HelpFile為字符串，ByVal HelpContext為Long，CancelDisplay為Boolean)

NoSrv = True

末端接頭

從互聯網上提供標準時間的網站獲取標準時間。

私有Sub NetTime(TimeSrv作為字符串)

NoSrv = False

TimeFromNet = " "

如果Winsock1。狀態& lt& gtsckClosed Then Winsock1。關閉

Winsock 1 . remote host = timesrv“www . time . AC . cn”或“time.nist.gov”。

Winsock1。遠程端口= 13

Winsock1。本地端口= 0

Winsock1。連接

Do While TimeFromNet = " " '等待標準時間網站返回時間數據。

如果NoSrv則退出Do，如果Winsock出錯，則跳出循環並等待。

睡眠55

多項活動

環

如果Winsock1。狀態& lt& gtsckClosed Then Winsock1。關閉

末端接頭

搜索更多相關主題的帖子:互聯網標準。

上面介紹了RFC-867標準和VB例程。很明顯，RFC-867標準返回當前時間和日期使用的格式是字符串格式並且沒有針對日間的特定格式(比如中科院國家授時中心是“Mon Jul 26 09:58:57 2004”，而美國標準技術研究所是“5321204-07-2602:00:125000488.3 UTC(NIST)”)，這兩個事實上，RFC在制定RFC-867標準時就已經考慮到了。

RFC868時間協議

(RFC868時間協議)

該RFC規定了ARPA互聯網社區的標準。ARPA互聯網上的所有主機都應采用並執行該標準。

該協議提供了獨立於站點且機器可讀的日期和時間信息。時間服務以秒為單位返回，即1900 65438+10月1午夜到現在的秒數。天啊，不小了。

設計此協議的壹個重要目的是網絡上的許多主機沒有時間概念。在分布式系統上，我們可以考慮如何劃分北京和東京的時間。主機的時間往往可以人為更改，因為機器時鐘的誤差而變得不壹致。所以需要使用時間服務器通過選舉獲得網絡時間，讓服務器有壹個準確的時間概念。不要小看時間，對於壹些簡單的基於時間的分布式程序來說，時間太重要了。

該協議可以在TCP和UDP協議下工作。下面是時間協議通過TCP協議工作的工作流程:這裏s代表服務器，u代表客戶端。

檢測端口37

u:連接到端口37

s:發送時間，32位二進制數。

u:接收時間

u:關閉連接

關閉連接

服務器監聽端口37上的連接。當連接建立後，服務器返回壹個32位時間值，然後關閉連接。這個過程也不難。如果服務器不能決定現在是什麽時間，服務器會拒絕連接或者直接關閉連接，不發送任何數據。

我們來看看UDP協議的用法:這裏s代表服務器，u代表客戶。

檢測端口37

u:向端口37發送空數據報告。

接收這個空數據報。

s:發送壹個包含32位二進制數的數據報(用來表示時間)。

u:接收時間數據報

服務器監聽端口37上的數據包。當壹個數據包到來時，服務器返回壹個包含32位時間的數據包。這個過程也不難。如果服務器不能決定現在是什麽時間，它將丟棄收到的數據報，而不作任何答復。

*時間

時間用32位表示，是從6月1900 65438+10月1的0: 00開始的秒數。我們可以算出，這個協議只能用到2036年。但我們也知道，計算機發展如此之快，可能會有更好的協議來取代這個協議，或者已經制定出有效的解決方案。)

以下是壹些例子:

時間2，208，988，800對應於00:00 1 1月1970 GMT，

2，398，291，200對應00:00 1 Jan 1976 GMT，

2，524，521，600對應00:00 1 Jan 1980 GMT，

2，629，584，000對應00:00 1 5月1983 GMT，

以及-1，297，728，000至00:00 17 11月1858 GMT的信函。

接下來，我們使用VB程序通過RFC868協議設置自己的計算機系統時間。為了簡化程序，程序不修正日期，只修正時間。不過這個套路比上面的程序完美多了。首先，它可以讀取全球20個標準時間服務器的時間數據。第二，它利用了網絡延遲的補償。第三，過濾網絡延遲超過3秒的標準時間服務器。將1 Winsock控件添加到FORM1中，並將以下代碼剪切並粘貼到FORM1的代碼表單中:

選項顯式

時間協議(RFC-868)提供了壹個32位數字來表示1900 1+0之間的秒數。

時間是UTC(不考慮字母順序，代表世界時間坐標)，

它類似於所謂的GreenwichMeanTime或GMT -格林威治標準時間。

使用TCP獲取準確時間的程序應該具有以下步驟:

1連接到提供此服務的端口37；

2次接收32位；

3關閉鏈接。

私有聲明子睡眠庫“kernel 32”(ByVal dw milliseconds壹樣長)

Dim NoSrv為布爾值

Dim TimeFromNet存儲從時間網站讀取的秒數。

Dimtime URL (19)作為字符串' 20次來提供網站的URL。

節目入口

私有子窗體_Load()

我像單身壹樣長久

Dimhh為整數，mm為整數，ss為整數'時、分、秒。

我。顯示

CDec (TimeFromNet)'轉換為十進制子類型，28位整數。

TimeURL(0) = "www.time.ac.cn " '首先取中科院國家授時中心的時間。

timeurl(1)= " time . NIST . gov " '美國標準與技術協會。

TimeURL(2)= " time-a . time freq . blrddoc . gov "

time URL(3)= " NIST 1 . datum . com "

TimeURL(4)= " NIST 1-DC . glassey . com "

TimeURL(5)= " NIST 1-ny . glassey . com "

TimeURL(6)= " NIST 1-SJ . glassey . com "

TimeURL(7)= " utc NIST . Colorado . edu "

TimeURL(8)= " time-b . time freq . blrddoc . gov "

TimeURL(9)= " time-c . time freq . blrddoc . gov "

TimeURL(10)= " time-a . NIST . gov "

time URL(11)= " time-b . NIST . gov "

TimeURL(12)= " NIST 1 . AOL-va . truetime . com "

TimeURL(13)= " NIST 1 . AOL-ca . truetime . com "

TimeURL(14)= " time-NW . NIST . gov "

TimeURL(15)= " Time-b . Time freq . blrdoc . gov "

TimeURL(16)= " Time-c . Time freq . blrdoc . gov "

TimeURL(17)= " ptbtime 1 . PTB . de "

TimeURL(18)= " clock . CMC . EC . GC . ca "

TimeURL(19)= " chronos . CSR . net "

對於i = 0到19

我。Caption = "正在連接-" &；時間鏈接(壹)

首次讀取服務中心的時間。

If(非NoSrv)和TimeFromNet & gt如果時間讀取成功，則為0。

為了減少網絡傳輸誤差，再次占用服務中心時間。

T0 = Timer '為了減少網絡延遲引起的誤差，首先讀取當前時間。

NetTime TimeURL(i)'輔助閱讀時間服務中心時間

If(非NoSrv)和TimeFromNet & gt如果第二次讀取成功，則為0。

timefromnet = timefromnet+int((timer-t0)/2+0.5)'加上網絡延遲補償(delay/2為延遲補償)。

time from net = time from net-86400 * int(time from net/86400)'取以天為單位的模數(86400秒)。

SS = TimeFromNet Mod 60 '耗時秒。

TimeFromNet = TimeFromNet 60

MM = TimeFromNet Mod 60 '分數

HH = ((TimeFromNet 60) +8) Mod 24 '小時(北京時間+8)

“MsgBox”網絡延遲:“&；(定時器- T0)

Time = TimeSerial(HH，MM，SS)'設置系統時間。

Exit For '計時結束後退出循環。

如果…就會結束

接下來我

如果我& gt那麽19

MsgBox "無法獲取網絡時間！"

如果…就會結束

結束

末端接頭

關閉Winsock事件。

私有Sub Winsock1_Close()

如果Winsock1。狀態& lt& gt那時關閉了

Winsock1。關閉

如果…就會結束

末端接頭

Winsock接收數據事件。

私有Sub Winsock 1 _ data arrival(ByVal bytes total As Long)

Dim TmpData

Winsock1。GetData TmpData

time from net = TmpData(3)+TmpData(2)* 256+TmpData(1)* 256 * 256+TmpData(0)* 256 * 256 * 256

末端接頭

Winsock錯誤事件

NoSrv = True

末端接頭

從互聯網上提供標準時間的網站獲取標準時間。

私有Sub NetTime(TimeSrv作為字符串)

“Dim i As Integer”超時計數器

i = 0

NoSrv = False

TimeFromNet = 0

如果Winsock1。狀態& lt& gtsckClosed Then Winsock1。關閉

Winsock 1。“remotehost = timesrv”時間提供網站的URL。

Winsock1。“遠程端口= 37”時間協議(RFC-868)指定端口。

Winsock1。本地端口= 0

Winsock1。連接

Do While TimeFromNet & lt= 0

i = i + 1

如果NoSrv或i & gt如果Winsock出錯或超時約3秒，時間獲取失敗。

睡眠55

多項活動

環

如果Winsock1。狀態& lt& gtsckClosed Then Winsock1。關閉

末端接頭

編輯:杭州元帥

最精確的網絡時間協議應該是RFC 1305-NTP(網絡時間協議)，可以達到1-50 ms的時間精度，但是協議非常復雜，很抱歉我手頭沒有RFC 1305的中文翻譯資料。但是後來又推出了新的RFC，RFC 1769-SNTP(簡單網絡時間協議)，簡化了RFC 1305要求的操作和應用範圍。以下是對RFC 1769-SNTP的介紹:

網絡工作組d .米爾斯

征求意見:1769特拉華大學

過時信息:1361 3月1995

類別:信息

(RFC 1769——簡單網絡時間協議)

本備忘錄的狀態:

本備忘錄為互聯網社區提供信息，但不規定任何類型的互聯網標準。本備忘錄的分發沒有任何限制。

概述

本備忘錄描述了簡單網絡時間協議(SNTP)，它是網絡時間協議(NTP)的改編，適用於在互聯網上同步計算機時鐘。當不需要實現RFC 1305中描述的NTP的全部功能時，可以使用SNTP。它可以在單播模式(點對點)和廣播模式(點對多點)下工作。它也可以在IP多播模式下工作(在這種模式下可以提供這種服務)。SNTP與當前和以前的NTP版本沒有太大的不同。但它更簡單，壹個無狀態的遠程過程調用(RPC)，其準確性和可靠性類似於RFC868描述中UDP/TIME協議所期望的。

本備忘錄刪除了標題相同的RFC 1361。其目的是解釋廣播操作的協議模式，在某些地方提供進壹步的解釋並糾正壹些打印錯誤。NTP版本3 RFC 1305中描述的工作機制對於SNTP的實現並不完全必要。本備忘錄的分發沒有任何限制。

2.工作模式和地址分配

3.NTP時間戳格式

4.NTP消息格式

5.SNTP客戶運營

6.SNTP服務器操作

7.參考資料

8.安全考慮

9.作者的地址

RFC 1305 [MIL92]指定了網絡時間協議(NTP)來同步互聯網上的計算機時鐘。它提供對國家時間和頻率傳播服務機制的全面訪問，組織時間同步子網並調整參與子網中每個本地時鐘的時間。在當今互聯網的大部分地區，NTP提供了1-50毫秒的精度，這取決於同步源和網絡路徑的特性。

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實現中使用冗余的同步源、不同的子網路徑和精心制作的算法，才能達到主服務器通常所期望的可靠性。當無線電時鐘通信失敗或傳遞錯誤時間時，這種方法使主同步源能夠使用幾個其他無線電時鐘和到其他主服務器的備用路徑。因此，我們應該仔細考慮在客戶端使用SNTP，而不是在主服務器上使用NTP。

2.工作模式和地址分配

像NTP壹樣，SNTP可以在單播(點對點)或廣播(點對多點)模式下運行。單播客戶機向服務器發送壹個請求，並期望從它那裏得到壹個答復，並且(可選地)獲得關於服務器的往返傳播延遲和本地時鐘補償。廣播服務器定期向指定的IP廣播地址或IP多播地址發送消息，通常不會收到客戶端的請求。廣播客戶端監聽地址，但通常不向服務器發送請求。壹些廣播服務器可能選擇響應客戶端請求並發送未經請求的廣播消息；同時，壹些廣播客戶端可能僅發送請求來確定服務器和客戶端之間的網絡傳播延遲。

在單播模式下，客戶端和服務器的IP地址照常分配。在廣播模式下，服務器使用指定的IP廣播地址或IP組播地址和指定的媒體訪問廣播地址，客戶端將在這些地址監聽幀。因此，IP廣播地址將限於單個IP子網，因為路由器不會傳播IP廣播數據報。就以太網而言，例如，以太網媒體訪問廣播地址(所有主機都是1)用於表示IP廣播地址。

另壹方面，IP多播地址將廣播的潛在有效範圍擴展到整個互聯網。它的實際範圍、組成員和路由由互聯網組管理協議(IGMP) [DEE89]決定，各種路由協議不在本文討論範圍之內。就以太網而言，例如，以太網媒體訪問廣播地址(全部為1)應與分配的IP組播地址224.0.1.1共享。除了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子網和局域網(指功能完整的NTP服務器和SNTP客戶端在同壹子網的局域網)中會使用IP廣播地址，而IP組播地址只會在為達到相同目的而設計的特殊情況下使用。特別是SNTP服務器中的IP組播地址，只有在服務器實現RFC 1305中描述的NTP認證(包括支持MD5消息位的算法)時才使用。

3.NTP時間戳格式

Sntp使用RFC 1305及其早期版本中描述的標準ntp時間戳格式。與互聯網標準壹致，NTP數據被指定為整數或定點小數，並且以大端方式從左0或高位開始計數。除非未指定，否則所有數量都將設置為無符號類型，並且整個字段寬度可以在bit0之前用隱含的0填充。

因為SNTP時間戳是重要的數據，用於描述協議的主要產品，所以建立了特殊的時間戳格式。NTP表示為帶時間戳的64位無符號定點，以秒為單位從1900 65438+10月1的0: 0: 0開始計數。在整數部分的前32位中，後32位(秒的分數)用於表示秒以下的部分。在秒分數部分，無意義的低位應設置為0。這種格式使用方便的多精度算法和轉換進行UDP/TIME表示(單位:秒)，但是它使將其轉換為ICMP時間戳消息表示(單位:毫秒)的過程變得復雜。它所代表的精度在200皮秒左右，應該足以滿足最高要求。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|秒鐘|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|秒部分(0填充)|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

註意，從1968開始，最高有效位(整數部分的0位)已經確定，64位字段將在2036溢出。如果2036年仍使用NTP或SNTP，則需要壹些外部方法來調整與1900和2036相關的時間(其他136的倍數也是如此)。有了這些限制，時間戳數據就變得非常特殊(需要適當的方法才能容易找到)。從現在開始，每隔136年會有壹個200皮秒的間隔，該間隔將被忽略，所有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 |模式|地層|輪詢|精度|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

根延遲

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|根差|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+