Network Time Protocol (w skrócie: NTP) – protokół synchronizacji czasu, którego czwarta wersja jest zdefiniowana w RFC 5905 ↓.
Wprowadzenie
NTP – Protokół komunikacyjny umożliwiający precyzyjną synchronizację czasu pomiędzy komputerami. Wzorcowy czas UTC może pochodzić bezpośrednio z zegarów atomowych lub pośrednio ze specjalizowanych serwerów czasu (ang. Time Server NTP). Protokół NTP jest coraz powszechniej uznawany za światowy standard synchronizacji czasu w urządzeniach teleinformatycznych i telekomunikacyjnych. Ma swoją implementację dla większości współczesnych systemów operacyjnych, z Microsoft Windows włącznie.
Implementacja protokołu NTP dla konkretnych systemów operacyjnych wymaga sprzęgnięcia na niskim poziomie jądra systemu operacyjnego. Czas lokalny tworzony jest przez system poprzez dodanie stosownego przesunięcia uwzględniającego lokalną strefę czasową. Dla systemów operacyjnych Linux i FreeBSD istnieją specjalne nakładki na jądro systemowe umożliwiające obsługę biegu zegarów ze zwiększoną precyzją. Nakładki umożliwiają płynną regulację czasu systemowego poprzez przyspieszenie lub spowolnienie programowego zegara systemowego.
Historia
Badania nad protokołem prowadzone są na Uniwersytecie w Delaware od 1988 roku pod kierunkiem prof. Davida L. Millsa i są nieustannie rozwijane w ramach projektu NTP.
Początkowo protokół NTP został zaprojektowany dla wybranych systemów operacyjnych rodziny Unix i rozwijany był w kierunku zastosowań do synchronizacji czasu przez Internet. Jednak obecnie NTP jest z powodzeniem wykorzystywany również poza Internetem i to zarówno w małych sieciach lokalnych (LAN), jak i w dużych sieciach korporacyjnych (WAN).
Rozwój protokołu ilustrują dokumenty RFC 778 ↓, RFC 891 ↓, RFC 956 ↓, RFC 958 ↓, RFC 1305 ↓, RFC 5905 ↓, RFC 5906 ↓, RFC 5907 ↓, RFC 5908 ↓, RFC 5909 ↓. Obecnie mimo zmian i uzupełnień RFC dostępna jest nadal wersja 4 protokołu. Wersja stabilna to 4.2.6, wersja deweloperska oznaczona jest jako 4.2.7. Precyzyjnie ujmując jest to już 5 generacja protokołu NTP (wersja pierwsza oznaczona była numerem 0).
SNTP
Istnieje również uproszczona wersja protokołu NTP znana pod nazwą SNTP (ang. Simple Network Time Protocol – RFC 4330 ↓). Wersja ta znajduje powszechne zastosowanie w prostych systemach operacyjnych i rozwiązaniach, w urządzeniach przenośnych i w telefonach komórkowych.
Zalety synchronizacji za pomocą protokołu NTP
NTP pozwala na synchronizację czasu z bardzo dużą precyzją, jest rozwiązaniem bardzo stabilnym i bezpiecznym. NTP kalibruje czas płynnie – bez skoków czasu i konieczności przestawiania zegara (wykorzystuje technikę przyspieszania i spowalniania). Już przy zastosowaniu standardowego sprzętu komputerowego klasy PC, precyzja ta może wynosić kilka milisekund. Obecnie protokół ma swoje implementacje dla większości współczesnych systemów operacyjnych i urządzeń sieciowych. Stosowanie wielu źródeł czasu jednocześnie znacząco poprawia precyzję synchronizacji, dostarcza wielopoziomową redundancję oraz pozwala wychwytywać i eliminować dostawców fałszywego czasu (ang. falsetickers).
Zaletą protokołu NTP jest możliwość jednoczesnej synchronizacji bardzo dużej liczby komputerów (rzędu dziesiątek tysięcy) bez przeciążenia łączy i procesorów. Implementacja protokołu nie wymaga wydajnych komputerów, procesorów ani szybkich łączy transmisyjnych.
Ogólnie dostępny kod źródłowy napisany w języku C pozwala rozszerzać NTP dla kolejnych nowych systemów operacyjnych i powstających nowych urządzeń. Protokół NTP przerwał wieloletnią rywalizację między producentami sprzętu komputerowego i oprogramowania, lansującymi własne standardy na rynku IT.
Czas wzorcowy UTC
W protokole NTP do synchronizacji czasu wykorzystywany jest czas uniwersalny UTC. Wzorcowy czas powinien pochodzić z atomowych zegarów cezowych. Jednak w związku z rozwojem technologii zezwala się na stosowanie czasu referencyjnego pochodzącego ze wzorców STRATUM 0 takich jak:
- cezowe zegary atomowe
- masery wodorowe
- zegary wykorzystujące generatory rubidowe
- czasowe wzorce laserowe
- satelitarne wzorce radiowe GPS, GLONASS, EGNOS, WAAS, Beidou, Galileo i w przyszłości system Compass (Beidou-2)
- naziemne nadajniki radiowe AM (np. niemiecki DCF77)
- wysokiej jakości zegary kwarcowe wykorzystujące oscylatory OCXO, TCXO, VCXO
Powyższe zegary dołączane są do komputera pełniącego dalej funkcję serwera NTP dla innych urządzeń. Dostawa czasu UTC odbywa się przez łącza:
- RS-232 (dostarcza stempel czasu UTC i może również dostarczać wzorzec częstotliwości)
- 1PPS (dostarcza wyłącznie wzorzec częstotliwości)
- IRIG-B (dostarcza stempel czasu i wzorzec częstotliwości)
- SYSPLEX (dostarcza stempel czasu)
- IEEE1588 PTPv1 Ethernet (dostarcza tylko stempel czasu)
- IEEE1588 PTPv2 Ethernet (dostarcza stempel czasu i wzorzec częstotliwości)
- WR White Rabbit (dostarcza wzorzec częstotliwości)
Istnieje również możliwość uzyskiwania referencyjnego czasu wzorcowego łącząc się do serwisu zegarynki (tzw. serwis „dial-up”), co w wielu krajach, w tym w Polsce nadal jest rekomendowanym źródłem oficjalnego czasu urzędowego.
Struktura warstw STRATUM 0-15
Wszystkie komputery uczestniczące w procesie synchronizacji NTP można uporządkować w strukturze gałęziowej STRATUM. Zasada przekazywania informacji o czasie jest następująca: komputery warstwy STRATUM N mogą być serwerami czasu dla warstwy STRATUM N+1, ale nie na odwrót. Komputery STRATUM N mogą być jednocześnie klientami komputerów warstwy STRATUM N-1 itd. Wielowarstwowa struktura STRATUM ma na celu uporządkowanie i wprowadzenie pewnej hierarchii ważności komputerów, zgodnie z ich rzeczywistym przeznaczeniem i funkcją. Aby ograniczyć dodatkowe opóźnienia w propagacji czasu, wynikające z rozgałęzionej struktury NTP, wprowadzono ograniczenie łącznej liczby warstw do 16 (STRATUM 0-15).
Niektórym warstwom przypisano specjalne znaczenie. Warstwa STRATUM 0 jest zarezerwowana wyłącznie dla pierwotnych wzorców czasu, którymi są bezpośrednio zegary czasu UTC.
Warstwy STRATUM 1 i STRATUM 2 stanowią wierzchołek drzewa NTP i powinny być zarezerwowane dla dużych serwerów korporacyjnych, wysokiej jakości serwerów, superkomputerów lub dedykowanych sprzętowych serwerów czasu.
Warstwy STRATUM 3 i kolejne są przeznaczone dla lokalnych serwerów i komputerów komunikujących się z nimi.
Numer STRATUM informuje nas o tym, jak bardzo odległy jest synchronizowany komputer od zegara wzorcowego w strukturze synchronizacji NTP. W sieci o bardzo dużej liczbie komputerów poziom STRATUM nie ma znaczącego wpływu na jakość synchronizacji i precyzję uzyskiwanego czasu.
Zasada synchronizacji NTP
Implementacja protokołu NTP dla konkretnego systemu operacyjnego wymaga sprzęgnięcia go na niskim poziomie z jądrem systemu operacyjnego.
NTP jest protokołem znacznie różniącym się od typowych protokołów komunikacyjnych. Nie dotyczy on bowiem transmisji absolutnej wartości czasu, lecz regularnie przekazuje pełne statystyki opóźnień i korelacji czasowych, jakie zachodzą w sieci TCP/IP. W prostych konfiguracjach z 1-2 serwerami NTP nie oferuje specjalnie żadnej przewagi w porównaniu do innych protokołów. Technologia NTP nabiera dopiero szczególnego znaczenia przy stosowaniu wielu źródeł czasu jednocześnie. Uruchamiany jest wtenczas specjalny algorytm analizy statystycznej czasu oparty na metodzie DTS opracowanej pod koniec lat 70. na Uniwersytecie w Delaware dla potrzeb obronnych USA i NASA. Algorytm ten pozwala na statystyczne obliczenie czasu wypadkowego pochodzącego z wielu źródeł i uwzględnia asymetrię łączy telekomunikacyjnych i związanego z tym czasu transportu protokołu TCP/IP. W latach 90. metoda ta została rozszerzona i nazwana metodą NTP, wprowadzając funkcjonalność automatycznego wykrywania i eliminowania dostawców tzw. fałszywego czasu (ang. falsetickers).
Do wymiany statystyk stosowane są pakiety UDP o długości 72 bajtów wymieniane okresowo co 2^tau sekund gdzie tau wynosi od 4 (16s) do 17 (36h) (zwykle okres wymiany wynosi 64 sekundy). Protokół NTP używa w tym celu portu 123. Przesyłane dane pozwalają każdemu z komputerów, tzw. klientów NTP, samodzielnie wyliczyć własne opóźnienie względem idealnego czasu UTC. Znając bieżące opóźnienie względem czasu UTC, każdy klient NTP sam kalibruje wskazania własnego, lokalnego zegara systemowego. Kalibracja polega na płynnym przyspieszaniu lub spowalnianiu pracy lokalnego zegara programowego. Przy dużych różnicach czasu, większych od 128ms, NTP stosuje jednorazową synchronizację skokową. W ten sposób każdy z klientów NTP asymptotycznie zmierza ku wskazaniom wzorcowego zegara czasu UTC.
Pierwotne wzorcowe wskazania czasu UTC powinny zawsze pochodzić z wzorców STRATUM 0. Komputery bezpośrednio synchronizujące czas własny z wymienionymi wzorcami stają się serwerami NTP STRATUM 1. Kolejne komputery synchronizują swój czas korzystając z protokołu TCP/IP i stają się klientami NTP warstwy N-1, pełniąc zarazem funkcję serwerów warstwy N dla kolejnych komputerów uczestniczących w synchronizacji NTP.
NTP – format komunikatu
LI | VN | Mode | Stratum | Poll interval |
Precision | |||||||
Root Delay | ||||||||||||
Root Dispersion | ||||||||||||
Reference Identifier | ||||||||||||
Reference Timestamp | ||||||||||||
Originate Timestamp | ||||||||||||
Receive Timestamp | ||||||||||||
Transmit Timestamp | ||||||||||||
Authenticator |
- LI – wskaźnik sekund przestępnych
- VN – (Version Number) numer wersji protokołu
- Mode – tryb pracy (m.in. tryb klienta, serwera, symetryczny pasywny, symetryczny aktywny, rozgłoszeniowy – serwer czasu okresowo rozsyła do wszystkich podległych klientów komunikat o czasie)
- Stratum – warstwa, w której funkcjonuje komputer będący nadawcą komunikatu
- Poll interval – okres pomiędzy kolejnymi aktualizacjami czasu
- Precision – określenie dokładności zegara komputera wysyłającego dany komunikat
- Root Delay – opóźnienie pomiędzy nadawcą a serwerem warstwy 1
- Root Dispersion – maksymalny błąd pomiędzy zegarem lokalnym a serwera warstwy 1
- Reference Identifier – identyfikator źródła czasu, względem którego następuje synchronizacja
- Reference Timestamp – pole zawierające pomocnicze informacje o czasie poprzedniej synchronizacji
- Originate Timestamp – pole zawierające czas wysłania żądania przez klienta
- Receive Timestamp – czas odebrania komunikatu od klienta (ustawiane przez serwer odpowiadający na żądanie klienta)
- Transmit Timestamp – czas wysłania odpowiedzi do klienta (ustawiane przez serwer odpowiadający na żądanie klienta)
- Authenticator – informacje uwierzytelniające zarówno klienta, jak i serwer czasu
Zobacz też
Linki zewnętrzne
- oficjalna strona projektu NTP
- Test serwera NTP w trybie online
- D.L. Mills , DCNET Internet Clock Service, RFC 778, IETF, kwiecień 1981, DOI: 10.17487/RFC0778, ISSN 2070-1721, OCLC 943595667 (ang.).
- D.L. Mills , DCN Local-Network Protocols, STD 44, RFC 891, IETF, grudzień 1983, DOI: 10.17487/RFC0891, ISSN 2070-1721, OCLC 943595667 (ang.).
- D.L. Mills , Algorithms for synchronizing network clocks, RFC 956, IETF, wrzesień 1985, DOI: 10.17487/RFC0956, ISSN 2070-1721, OCLC 943595667 (ang.).
- D.L. Mills , Network Time Protocol (NTP), RFC 958, IETF, wrzesień 1985, DOI: 10.17487/RFC0958, ISSN 2070-1721, OCLC 943595667 (ang.).
- D. Mills , Network Time Protocol (Version 3) Specification, Implementation and Analysis, RFC 1305, IETF, marzec 1992, DOI: 10.17487/RFC1305, ISSN 2070-1721, OCLC 943595667 (ang.).
- D. Mills , Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 4330, IETF, styczeń 2006, DOI: 10.17487/RFC4330, ISSN 2070-1721, OCLC 943595667 (ang.).
- D. Mills i inni, Network Time Protocol Version 4: Protocol and Algorithms Specification, RFC 5905, IETF, czerwiec 2010, DOI: 10.17487/RFC5905, ISSN 2070-1721, OCLC 943595667 (ang.).
- B. Haberman , D. Mills , Network Time Protocol Version 4: Autokey Specification, RFC 5906, IETF, czerwiec 2010, DOI: 10.17487/RFC5906, ISSN 2070-1721, OCLC 943595667 (ang.).
- H. Gerstung , C. Elliott , B. Haberman , Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4), RFC 5907, IETF, czerwiec 2010, DOI: 10.17487/RFC5907, ISSN 2070-1721, OCLC 943595667 (ang.).
- R. Gayraud , B. Lourdelet , Network Time Protocol (NTP) Server Option for DHCPv6, RFC 5908, IETF, czerwiec 2010, DOI: 10.17487/RFC5908, ISSN 2070-1721, OCLC 943595667 (ang.).
- J-M. Combes , S. Krishnan , G. Daley , Securing Neighbor Discovery Proxy: Problem Statement, RFC 5909, IETF, lipiec 2010, DOI: 10.17487/RFC5909, ISSN 2070-1721, OCLC 943595667 (ang.).