Network Time Protocol

Network Time Protocol (NTP) – protokół komunikacyjny służący do synchronizacji zegarów komputerów i innych urządzeń w sieciach komputerowych o zmiennych opóźnieniach transmisji. NTP rozprowadza czas odniesiony do UTC, używa zwykle UDP na porcie 123 i jest jednym z najstarszych protokołów internetowych pozostających w powszechnym użyciu. Protokół został zaprojektowany przez Davida L. Millsa i jest rozwijany od pierwszej połowy lat 80. XX wieku; aktualną podstawową specyfikacją jest NTPv4 opisana w RFC nr 5905.

NTP nie przesyła informacji o lokalnej strefie czasowej ani o zasadach czasu letniego; jego zadaniem jest utrzymanie zgodnego czasu systemowego, a przeliczenie UTC na czas lokalny pozostaje funkcją systemu operacyjnego albo aplikacji. W dobrze zaprojektowanych sieciach lokalnych NTP może osiągać dokładność lepszą niż milisekunda, natomiast w publicznym Internecie wynik zależy od tras pakietów, asymetrii opóźnień, przeciążenia i jakości źródeł czasu.

Sam protokół NTP należy odróżniać od konkretnych implementacji – serwerów i klientów, które realizują jego algorytmy. Do szeroko stosowanych implementacji należą klasyczna referencyjna usługa ntpd rozwijana w ramach NTP Project, niezależnie napisany chrony oraz utwardzony pod kątem bezpieczeństwa fork NTPsec; uproszczonymi klientami SNTP są m.in. usługa Windows Time w systemach Microsoft Windows oraz wbudowany w systemd komponent systemd-timesyncd.

Historia i wersje

Prace, z których wywodzi się NTP, rozpoczęły się przed formalną specyfikacją protokołu w badaniach Davida L. Millsa nad synchronizacją zegarów w sieciach pakietowych. Wczesne rozwiązania zostały opisane między innymi w IEN 173 oraz w RFC nr 778 dotyczącym DCNET Internet Clock Service. Pierwsza specyfikacja Network Time Protocol, oznaczana później jako NTPv0, ukazała się w RFC nr 958 w 1985 roku i zawierała format pakietu oraz wzory na opóźnienie i przesunięcie zegarów używane także w późniejszych wersjach.

NTPv1 został opisany w RFC nr 1059 z 1988 roku, NTPv2 w RFC nr 1119 z 1989 roku, a szeroko stosowana wersja NTPv3 w RFC nr 1305 z 1992 roku. Wersja trzecia wprowadziła bardziej rozwinięte procedury wyboru zegara i analizy błędów, a specyfikacja NTPv4 z 2010 roku zastąpiła wcześniejsze dokumenty podstawowe i zintegrowała w jednym standardzie także uproszczony wariant SNTPv4.

Po RFC nr 5905 publikowano dalsze rozszerzenia i zalecenia, między innymi dotyczące pól rozszerzeń, zmian w kodzie uwierzytelniania wiadomości, najlepszych praktyk operacyjnych, losowania portu źródłowego klienta, rejestrów IANA i trybów z przeplatanymi znacznikami czasu. Nadal jednak za podstawowy protokół produkcyjny uznaje się NTPv4, a kolejne prace rozwojowe są prowadzone w ramach dokumentów aktualizujących i projektów roboczych IETF.

Zasada działania

Uproszczony schemat filtrów i algorytmów wyboru źródeł czasu w implementacji NTP.

NTP jest zwykle opisywany w modelu klient–serwer: klient okresowo odpytuje jeden lub kilka serwerów czasu, oblicza przesunięcie swojego zegara i stopniowo koryguje częstotliwość zegara systemowego. Ten sam protokół może jednak pracować także w trybach symetrycznych między równorzędnymi węzłami, a w sieciach lokalnych dopuszcza również rozgłaszanie lub multicast, w których klienci nasłuchują ogłoszeń czasu po wcześniejszym oszacowaniu opóźnienia ścieżki.

Pomiar opóźnienia i przesunięcia

Podstawowa wymiana klienta z serwerem wykorzystuje cztery znaczniki czasu: chwilę wysłania zapytania przez klienta, chwilę odebrania zapytania przez serwer, chwilę wysłania odpowiedzi przez serwer oraz chwilę odebrania odpowiedzi przez klienta. Na ich podstawie klient oblicza opóźnienie w obie strony oraz przesunięcie zegara względem serwera, a następnie przekazuje próbki do filtrów i algorytmów wyboru źródeł czasu.

• t₀ – czas wysłania zapytania przez klienta.
• t₁ – czas odebrania zapytania przez serwer.
• t₂ – czas wysłania odpowiedzi przez serwer.
• t₃ – czas odebrania odpowiedzi przez klienta.

Przy założeniu w przybliżeniu symetrycznej ścieżki sieciowej przesunięcie czasu θ i opóźnienie rundy δ są obliczane ze wzorów stosowanych w specyfikacji NTPv4:

$\theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}}$

$\delta =(t_{3}-t_{0})-(t_{2}-t_{1})$

Wartości te nie są zwykle stosowane bezpośrednio jako pojedyncza korekta. Implementacja porównuje próbki z wielu zapytań i, jeśli korzysta z wielu serwerów, odrzuca źródła odstające, wybiera najlepszych kandydatów oraz dyscyplinuje zegar lokalny przez zmianę jego częstotliwości lub – przy dużym błędzie początkowym – przez skokowe ustawienie czasu.

Skokowa zmiana czasu a dyscyplinowanie zegara

NTP rozróżnia dwa sposoby korekcji zegara systemowego. Skokowe ustawienie czasu, czyli operacja typu step, polega na bezpośrednim przesunięciu wartości zegara do nowej chwili. Jest stosowane zwykle przy starcie usługi i przy bardzo dużym błędzie zegara, ponieważ skokowy ruch w czasie może zaburzyć działanie aplikacji wrażliwych na monotoniczność znaczników czasu, w tym mechanizmów kryptograficznych i niektórych baz danych. Dyscyplinowanie zegara, czyli operacja typu slew albo strojenie częstotliwości, polega na delikatnym przyspieszaniu lub spowalnianiu zegara systemowego, dzięki czemu czas pozostaje monotoniczny, a różnica względem źródła jest stopniowo niwelowana.

W typowych implementacjach próg między tymi dwoma trybami można konfigurować, a po długim okresie odłączenia od sieci czas bywa najpierw ustawiany skokowo, a następnie utrzymywany przez dyscyplinowanie. W referencyjnej implementacji ntpd domyślnym progiem skoku jest błąd zegara o 128 ms; mniejsze różnice są niwelowane przez dyscyplinowanie zegara, a dopiero większe powodują skokowe ustawienie czasu. Część implementacji potrafi też dostroić częstotliwość zegara sprzętowego komputera, co poprawia stabilność czasu w okresach bez kontaktu z serwerami.

Interwał zapytań klient–serwer w NTP jest opisywany wykładniczo jako 2^τ sekund. Protokół dopuszcza wartości τ od 4 (16 s) do 17 (około 36 h), a typowy klient korzysta z interwału rzędu kilkudziesięciu sekund do kilkunastu minut; sugerowane przez RFC nr 5905 domyślne granice minimalnego i maksymalnego interwału odpytywania wynoszą odpowiednio 6 i 10, czyli 64 s i 1024 s.

Algorytmy wyboru i kombinacji źródeł

Specyfikacja NTPv4 opisuje wieloetapowy proces decydujący o tym, którym serwerom warto zaufać i jaki jest wynikowy ofset zegara. Algorytm selection wykorzystuje wariant algorytmu przedziałów pewności znanego jako algorytm Marzullo, aby z deklarowanych przedziałów dokładności kandydatów wybrać największy zbiór wzajemnie zgodnych truechimers i odrzucić wyraźnie odstające falsetickers. Następujący po nim algorytm grupowania (clustering) zacieśnia ten zbiór, a algorytm łączenia (combine) wylicza wynikowe przesunięcie jako średnią ważoną z najlepszych źródeł.

Wybrane próbki czasu trafiają do filtru, który dla każdego skojarzenia wybiera najlepsze próbki z ostatniego okna i ogranicza wpływ chwilowych skoków opóźnienia w sieci. Wynikowe przesunięcie i częstotliwość są podawane na clock discipline – pętlę sterującą zegarem systemowym, opisaną w specyfikacji jako rozszerzenie klasycznej pętli fazowo-częstotliwościowej. Dzięki takiej strukturze NTP może utrzymać stabilny czas także wtedy, gdy jedno ze źródeł chwilowo zawiedzie albo zacznie zgłaszać oczywiście nieprawdziwy czas.

Hierarchia stratum

Schemat hierarchii serwerów i klientów NTP; żółte strzałki oznaczają połączenia bezpośrednie, czerwone – połączenia sieciowe.

Zegar główny United States Naval Observatory jako przykład infrastruktury wzorca czasu, z której pośrednio mogą korzystać serwery NTP.

NTP używa półhierarchicznego modelu źródeł czasu. Odległość logiczna od zegara odniesienia jest określana numerem stratum, ale numer ten nie jest sam w sobie gwarancją jakości: dobry serwer stratum 3 może w praktyce dawać stabilniejszy czas niż przeciążony lub źle skonfigurowany serwer stratum 1 albo 2.

• Stratum 0 obejmuje bezpośrednie wzorce czasu i częstotliwości, na przykład zegary atomowe, masery wodorowe, odbiorniki systemów GNSS takich jak GPS lub naziemne odbiorniki sygnałów czasu typu DCF77; urządzenia takie nie ogłaszają się jako serwery NTP w sieci, lecz są podłączane do hostów stratum 1.
• Stratum 1 to komputery lub serwery czasu bezpośrednio podłączone do źródła stratum 0, na przykład przez odbiornik GNSS, sygnał 1PPS, łącze szeregowe RS-232 przekazujące znacznik czasu albo przemysłowy kod czasu, taki jak IRIG-B.
• Stratum 2 i kolejne tworzą warstwy serwerów synchronizowanych przez sieć z serwerami wyższej warstwy; mogą one jednocześnie służyć jako klienci i jako źródła czasu dla kolejnych hostów.
• Stratum 16 oznacza w protokole stan niesynchronizowany, a wartości od 1 do 15 są używane do budowania drzewa zależności i unikania pętli synchronizacji.

Oprócz numeru stratum pakiet NTP zawiera identyfikator źródła odniesienia, czyli reference identifier lub refid. Dla serwerów bezpośrednio związanych ze źródłem odniesienia refid może wskazywać typ źródła, na przykład GPS, PPS albo DCF77; dla dalszych warstw może być kodowaną informacją o serwerze nadrzędnym. Specjalne wartości pola refid są używane także w komunikatach kiss-o'-death, którymi serwer może poprosić klienta o ograniczenie albo wstrzymanie zapytań.

Format komunikatu i znaczniki czasu

Podstawowy nagłówek NTPv4 ma 48 bajtów, po których mogą wystąpić pola rozszerzeń oraz dane uwierzytelniające. Pierwsze pola określają między innymi ostrzeżenie o sekundzie przestępnej, wersję protokołu, tryb pracy, stratum, interwał odpytywania i precyzję lokalnego zegara, a dalsze pola przenoszą informacje o opóźnieniu do źródła odniesienia, dyspersji, identyfikatorze źródła oraz cztery 64-bitowe znaczniki czasu.

Pole	Długość	Znaczenie
LI, VN, Mode	2 + 3 + 3 bity	wskaźnik sekundy przestępnej, numer wersji i tryb asocjacji
Stratum	8 bitów	odległość od źródła odniesienia albo stan niesynchronizowany
Poll, Precision	po 8 bitów	interwał zapytań i deklarowana precyzja zegara lokalnego
Root Delay	32 bity	całkowite opóźnienie rundy do źródła odniesienia
Root Dispersion	32 bity	oszacowana dyspersja względem źródła odniesienia
Reference ID	32 bity	identyfikator źródła synchronizacji albo kod stanu
Reference, Origin, Receive, Transmit Timestamp	po 64 bity	znaczniki czasu używane do wyliczenia przesunięcia i opóźnienia

Znacznik czasu NTP ma postać liczby stałoprzecinkowej: 32 bity opisują sekundy, a 32 bity ułamek sekundy. Epoka tej skali zaczyna się 1 stycznia 1900 roku, co powoduje przepełnienie 32-bitowego pola sekund po 2³² sekundach, czyli 7 lutego 2036 roku. Pojęcie ery wprowadzone w NTPv4 oraz 128-bitowy format daty mają służyć rozróżnianiu kolejnych okresów po przepełnieniu, choć standardowy pakiet w sieci pozostaje oparty na 64-bitowych znacznikach.

NTP potrafi rozgłaszać ostrzeżenie o nadchodzącej sekundzie przestępnej, ale samo wykonanie korekty zależy od implementacji systemu i konfiguracji. Niektóre infrastruktury zamiast skokowego wstawienia sekundy stosują rozsmarowanie sekundy przestępnej w dłuższym przedziale czasu, co opisano osobno w sekcji poświęconej sekundom przestępnym.

SNTP

Simple Network Time Protocol (SNTP) jest uproszczonym sposobem używania tego samego formatu pakietu i tego samego portu, a nie odrębnym, niezgodnym protokołem. Wczesne SNTPv3 opisano w RFC nr 1361, a SNTPv4 w RFC nr 2030 i RFC nr 4330; w RFC nr 5905 uproszczony wariant został włączony do głównej specyfikacji NTPv4 jako profil dla prostych serwerów i klientów.

SNTP może pomijać stałe przechowywanie stanu, zaawansowane filtrowanie, korelowanie wielu źródeł i dyscyplinowanie częstotliwości zegara typowe dla pełnych implementacji NTP. Dzięki temu nadaje się do prostych urządzeń lub środowisk, w których wymagana jest tylko podstawowa zgodność czasu, ale nie zastępuje pełnego NTP tam, gdzie potrzebna jest redundancja, wykrywanie błędnych serwerów i stabilna praca przez długi czas.

Implementacje

Sam protokół NTP nie jest tym samym co konkretna usługa systemowa go realizująca. W obiegu pozostaje równolegle kilka niezależnych implementacji o różnym zakresie funkcji, modelu bezpieczeństwa i typowych zastosowaniach.

ntpd – implementacja referencyjna

Klasyczna implementacja referencyjna NTP Project działa jako usługa systemowa o nazwie ntpd. Jest rozwijana od początku lat 90. XX wieku, była portowana na większość rodzin systemów operacyjnych, w tym Linux, FreeBSD i inne warianty uniksowe oraz Microsoft Windows, i obsługuje zarówno zdalne serwery czasu, jak i lokalne zegary odniesienia. Jej algorytmy dyscyplinowania zegara i selekcji źródeł stały się punktem odniesienia dla większości opisów protokołu, dlatego dokumentacja ntpd bywa traktowana jako uzupełnienie specyfikacji.

chrony

chrony jest niezależną implementacją NTP rozwijaną od 1997 roku, sponsorowaną głównie przez firmę Red Hat i ustawioną jako domyślny demon czasu w jej dystrybucjach Linuxa. Napisany od zera kod bazowy jest mniejszy niż w referencyjnej implementacji, co według raportów bezpieczeństwa firmy Cure53 oraz inicjatywy Core Infrastructure Initiative ułatwia audyt i poprawia odporność na błędy. Chrony szybko synchronizuje się także w środowiskach, w których referencyjna implementacja zachowuje się gorzej: na hostach z niestabilnym zegarem, na maszynach wirtualnych oraz przy przerywanej łączności internetowej, a od wersji 4.0 obsługuje Network Time Security i sprzętowe znaczniki czasu na kartach sieciowych.

NTPsec

NTPsec jest odgałęzieniem referencyjnej implementacji powstałym w 2015 roku jako odpowiedź na serię podatności wykrytych w 2014 roku, a pierwsze wydanie produkcyjne opublikowano w 2017 roku. Projekt systematycznie usuwał z bazy kodu wsparcie dla przestarzałego sprzętu, niewspieranych wariantów systemów uniksowych oraz uznane za niebezpieczne funkcje historyczne, co pozwoliło ograniczyć rozmiar kodu o około trzy czwarte i ułatwiło audyt bezpieczeństwa. Niezależny audyt Cure53 z 2017 roku wykazał, że część dawnych problemów zniknęła, choć pojawiła się też wąska klasa podatności niewystępujących w wersji referencyjnej.

ntpd-rs

ntpd-rs jest implementacją NTP w języku Rust, rozwijaną w ramach inicjatywy Prossimo prowadzonej przez Internet Security Research Group. Główne cele projektu to bezpieczeństwo pamięci i zmniejszenie powierzchni ataku w infrastrukturze synchronizacji czasu; ntpd-rs obsługuje Network Time Security i jest wdrażane między innymi przez urząd certyfikacji Let’s Encrypt. Częścią projektu Pendulum jest również implementacja Precision Time Protocol o nazwie statime.

OpenNTPD

OpenNTPD wywodzi się z projektu OpenBSD i powstał w 2004 roku z myślą o prostocie kodu, rozdzieleniu uprawnień oraz odpornym domyślnym profilu bezpieczeństwa. Świadomie rezygnuje z części złożoności pełnego ntpd kosztem dokładności, którą uznano za nadmierną dla typowych zastosowań użytkowników OpenBSD. Wersja przenośna jest dostępna w wielu dystrybucjach Linuksa.

systemd-timesyncd

systemd-timesyncd jest wbudowanym w systemd klientem SNTP – nie pełną implementacją NTP. Ogranicza się do synchronizacji zegara komputera z grupą serwerów wskazanych w konfiguracji i nie udostępnia usług NTP innym hostom. Bywa preferowany na stacjach roboczych i urządzeniach o ograniczonych zasobach; w dystrybucji Debian bywa używany jako lekka usługa synchronizacji czasu w instalacjach domyślnych, gdy nie jest wymagana pełna funkcjonalność osobnego demona NTP. Z założenia ustępuje pełnym demonom NTP pod względem precyzji i zaawansowania algorytmów.

Windows Time

W systemach Microsoft Windows synchronizację czasu zapewnia usługa Windows Time, początkowo zaprojektowana z myślą o obsłudze Kerberosa w środowisku domenowym, gdzie wymagana jest zgodność czasu w granicach kilku minut. Od wersji Windows Server 2003 i Windows Vista usługa obsługuje znaczący podzbiór NTPv3, a od Windows 10 1607 i Windows Server 2016 producent dokumentuje konfiguracje pozwalające osiągnąć dokładność rzędu 1 s, 50 ms lub nawet 1 ms w określonych warunkach. Microsoft jednoznacznie zaznacza, że dla wyższej dokładności należy rozważyć inną implementację NTP.

Wybór implementacji

W praktyce wybór implementacji zależy od celu wdrożenia. Serwery publiczne i infrastruktura przedsiębiorstwa wymagają zwykle kilku niezależnych źródeł czasu, kontroli obciążenia oraz monitorowania jakości synchronizacji, dlatego sięga się po pełne demony NTP, takie jak ntpd, chrony, NTPsec albo ntpd-rs. Stacje robocze i urządzenia wbudowane mogą korzystać z lżejszych klientów, w tym SNTP albo usług systemowych jak Windows Time lub systemd-timesyncd, ale ich możliwości w zakresie redundancji i dokładności są ograniczone.

Publiczne serwery i pula NTP

Większość użytkowników korzysta z czasu udostępnianego przez publicznie dostępne serwery NTP, którymi opiekują się instytucje metrologiczne, dostawcy usług internetowych albo wolontariusze. W Polsce szczególne znaczenie ma usługa Głównego Urzędu Miar, która przez Internet udostępnia synchronizację systemów komputerowych z czasem urzędowym obowiązującym w kraju. Według informacji GUM serwery e-CzasPL znajdują się w Laboratorium Czasu i Częstotliwości, są synchronizowane z państwowego wzorca jednostek miar czasu i częstotliwości, używają NTP, a usługa jest dostępna całodobowo i bezpłatnie.

Nazwa DNS	Adres IPv4 podany przez GUM	Charakterystyka
tempus1.gum.gov.pl	194.146.251.100	publiczny serwer czasu urzędowego GUM
tempus2.gum.gov.pl	194.146.251.101	publiczny serwer czasu urzędowego GUM

Największą i najpowszechniej używaną publiczną pulą serwerów NTP jest projekt NTP Pool, dostępny pod domeną pool.ntp.org. System DNS rozprowadza zapytania klientów między dużą liczbą serwerów wolontariuszy, dzięki czemu pojedyncze hosty nie są obciążane całością ruchu, a klienci nie muszą sami szukać dobrych źródeł czasu.

Pula udostępnia także podzbiory regionalne, na przykład europe.pool.ntp.org, oraz strefy krajowe takie jak pl.pool.ntp.org, co pozwala ograniczyć opóźnienia związane z trasami międzykontynentalnymi. W typowej konfiguracji klienta wskazuje się kilka nazw z prefiksami 0–3, co dla każdej domeny daje inną listę losowo wybranych serwerów; w dokumentacji projektu zaleca się używanie nie więcej niż czterech adresów oraz unikanie agresywnych opcji takich jak burst czy bardzo krótkich interwałów odpytywania.

NTP Pool prowadzi oddzielny program dla producentów urządzeń, tzw. vendor zone. Producent rejestruje własną nazwę domeny, na przykład 0.vendor.pool.ntp.org, i powinien wpisać ją w domyślną konfigurację swoich urządzeń zamiast głównych nazw puli. Twardo wpisywanie adresów pool.ntp.org albo konkretnych serwerów stratum 1 w masowo produkowanych urządzeniach jest uznawane za nadużycie serwerów NTP; historyczne incydenty, w których pojedynczy producent zalał ruchem serwery wolontariuszy, doprowadziły do powstania właśnie programu vendorów.

Projekt publikuje bieżące statystyki aktywnych serwerów według regionów i stref krajowych; wartości te zmieniają się w czasie wraz z dołączaniem i odłączaniem się wolontariuszy. Polska strefa puli pl.pool.ntp.org utrzymywała w 2026 roku kilkadziesiąt aktywnych serwerów IPv4 oraz mniejszą liczbę serwerów IPv6.

Projekt nie udziela gwarancji jakości ani dostępności; regulamin używania puli wprost zaznacza, że usługa jest świadczona przez wolontariuszy bez żadnych gwarancji, może w pojedynczych przypadkach dostarczyć całkowicie błędny czas i nie powinna być używana w zastosowaniach, w których błędny czas mógłby zaszkodzić życiu, działalności albo społeczności użytkownika – w takich scenariuszach zaleca się własne serwery stratum 1 albo wyspecjalizowane usługi metrologiczne. Mimo tego zastrzeżenia NTP Pool jest ważnym źródłem czasu dla wielu systemów i urządzeń sieciowych; według strony projektu korzystają z niego setki milionów systemów. Badanie Beverly'ego i Rye'a z 2026 roku zebrało dziewięć miesięcy danych o puli, odnalazło ponad 15 tys. serwerów aktywnych i nieaktywnych oraz wskazało, że tylko 19,7% aktywnych serwerów było w pełni niezależnych po uwzględnieniu kont, aliasów adresowych i powiązań sieciowych, co ma znaczenie dla odporności puli na przejęcie dużej części ruchu przez jeden podmiot.

Sekundy przestępne i leap smear

NTP sygnalizuje sekundy przestępne w nagłówku pakietu w polu Leap Indicator. Wartości tego pola informują klienta, że ostatnia minuta bieżącego dnia trwa 61 sekund (dodatnia sekunda przestępna) albo 59 sekund (ujemna sekunda przestępna), pozwalają też sygnalizować stan niesynchronizowany. To, jak system operacyjny i aplikacje obsłużą tę informację, zależy od ich implementacji – wymóg ścisłej monotoniczności znaczników czasu sprawia, że niektóre systemy zatrzymują, powtarzają albo lekko spowalniają zegar w okolicy sekundy przestępnej.

Alternatywą wobec skokowej obsługi sekundy przestępnej jest leap smear, czyli rozsmarowanie korekty na dłuższy okres. Klasyczne wdrożenie Google Public NTP rozkłada dodatkową sekundę liniowo w oknie 24 godzin, od południa do południa czasu UTC: w tym okresie zegar serwerów puli Google biegnie o około 11,6 µs na sekundę wolniej niż czas referencyjny, a po zakończeniu okna czas znów pokrywa się z UTC. Z podobnego podejścia korzystają między innymi usługi Amazon AWS i Meta (dawniej Facebook), które samodzielnie publikują dokumentację swoich okien rozsmarowania.

Rozsmarowanie sekundy przestępnej nie jest częścią standardu NTP i nie jest jedną, uniwersalną skalą czasu – różni operatorzy mogą stosować różne okna i tempo korekty. Z tego powodu dokumentacja zarówno NTP Project, jak i implementacji chrony przestrzega przed mieszaniem w jednej konfiguracji serwerów stosujących leap smear z serwerami publicznej puli NTP, które stosują klasyczną obsługę sekund przestępnych: klient otrzymuje wówczas wewnętrznie sprzeczne wskazania czasu i jego algorytm wyboru źródeł może wprowadzić błąd zamiast go zmniejszyć.

Bezpieczeństwo

Poprawny czas systemowy jest elementem bezpieczeństwa wielu usług, ponieważ wpływa na ważność certyfikatów, mechanizmy uwierzytelniania, dzienniki zdarzeń, odtwarzanie kolejności incydentów, TLS, DNSSEC, usługi katalogowe i protokoły routingu takie jak Border Gateway Protocol. Fałszywe lub zmanipulowane odpowiedzi NTP mogą pośrednio osłabiać systemy zależne od poprawnej chronologii i terminów ważności kluczy.

Klasyczne mechanizmy uwierzytelniania

Klasyczne mechanizmy uwierzytelniania NTP obejmowały tryby z kluczami współdzielonymi oraz system Autokey opisany dla NTPv4 (RFC nr 5906), wzorowany na rozwiązaniach z IPsec. Późniejsze analizy wykazały jednak istotne wady projektowe Autokey, a w aktualnych zaleceniach najlepszych praktyk wprost nie poleca się go do nowych wdrożeń. Tryb z kluczami współdzielonymi pozostaje praktyczny w sieciach lokalnych, w których strony i tak ustalają wspólną tajemnicę, ale słabo skaluje się do publicznego Internetu.

Microsoft opracował dodatkowo własne rozszerzenie MS-SNTP, w którym klient i serwer wykorzystują tożsamość z domeny Windows Server do uwierzytelnienia pakietów NTP. Mechanizm działa w implementacji referencyjnej ntpd i w chrony przy współpracy z usługą Samba i jest stosowany głównie w środowiskach Active Directory.

Network Time Security (NTS)

Network Time Security (NTS), zdefiniowane w RFC nr 8915, jest aktualnie podstawową nowoczesną metodą ochrony klienta przed podszyciem się pod serwer. Mechanizm rozdziela kosztowne uzgodnienie kluczy od bieżącej wymiany pakietów czasu: klient najpierw nawiązuje połączenie TLS z usługą NTS-KE (klucz: Key Establishment) zwykle na porcie 4460, negocjuje parametry kryptograficzne i otrzymuje pulę krótkotrwałych cookies wraz z materiałem kluczowym. W kolejnych krokach klient przesyła zwykłe pakiety NTP, ale opatruje je polami rozszerzeń zawierającymi unikalny identyfikator zapytania, jeden ze świeżych cookies oraz pole uwierzytelniające z wynikiem działania szyfrowania uwierzytelnianego (AEAD).

Dzięki tej konstrukcji serwer NTP może pozostać bezstanowy, a koszt operacji asymetrycznych przenoszony jest na osobną usługę NTS-KE i ponoszony rzadziej niż przy każdej wymianie czasu. Projekt NTS świadomie dobiera wielkości pól rozszerzeń tak, aby odpowiedź serwera nie była istotnie większa niż zapytanie, co przeciwdziała wykorzystywaniu serwerów NTP w atakach wzmacniających. NTS nie eliminuje fizycznego problemu opóźniania pakietów przez napastnika, ale skutecznie utrudnia podszywanie się pod źródło czasu i modyfikowanie odpowiedzi w locie. Publiczne usługi NTP z obsługą NTS udostępniają między innymi Cloudflare i Netnod, a po stronie klienta NTS obsługują chrony, NTPsec i ntpd-rs.

Ataki wzmacniające i nadużycia

Serwery NTP bywały wykorzystywane w atakach odbiciowych i wzmacniających typu DRDoS, zwłaszcza gdy publicznie dostępne implementacje odpowiadały na kosztowne zapytania administracyjne, takie jak komenda monlist w starszych wersjach ntpd. W 2014 roku tego rodzaju ataki wygenerowały rekordowe wówczas wolumeny ruchu rzędu setek gigabitów na sekundę i doprowadziły do wyłączenia niektórych usług ofiar. Ograniczanie takich nadużyć wymaga aktualizacji oprogramowania, wyłączenia historycznie problematycznych poleceń monitorujących, filtrowania ruchu z fałszowanym adresem źródłowym (BCP 38), rate limitingu oraz właściwej konfiguracji serwerów publicznych i prywatnych.

W 2017 roku Linux Foundation w ramach Core Infrastructure Initiative zleciła równoległy audyt trzech głównych implementacji NTP. Raport wskazywał mniej istotnych problemów bezpieczeństwa w chrony niż w klasycznym ntpd i w NTPsec; chrony jest też domyślnym demonem czasu w części dystrybucji systemów linuksowych. Spójność czasu pozostaje krytyczna także dla aplikacji odległych od tradycyjnej administracji systemów – atak Malhotry i in. (2015) pokazał na przykład, jak przesunięcie czasu o godziny lub doby może zostać użyte przeciwko mechanizmom HSTS, DNSSEC i nawet BGP.

Dokładność i ograniczenia

Dokładność NTP jest ograniczona przede wszystkim przez zmienność opóźnień sieciowych, asymetrię tras w obu kierunkach oraz jakość lokalnego zegara. Jeśli pakiety klient–serwer i serwer–klient nie pokonują ścieżek o podobnym opóźnieniu, połowa różnicy między tymi opóźnieniami pojawia się jako błąd systematyczny oszacowania czasu. Z tego powodu protokół wymaga zwykle wielu kolejnych próbek i wielu niezależnych źródeł, aby błąd systematyczny mógł zostać uśredniony albo wykryty.

W publicznym Internecie NTP jest projektowany raczej do stabilnej synchronizacji rzędu milisekund niż do ekstremalnej precyzji pomiarowej, a praktyczna dokładność zależy od trasy do serwera, przeciążenia łączy oraz konfiguracji firewall i NAT na drodze pakietów. W kontrolowanej sieci lokalnej, przy dobrych serwerach i niewielkiej zmienności opóźnień, NTP osiąga zwykle dokładności submilisekundowe, a wraz z dyscyplinowaniem sprzętowym i znacznikowaniem czasu na karcie sieciowej – nawet poniżej kilkunastu mikrosekund.

Osobnym wyzwaniem jest synchronizacja w środowiskach wirtualizacji. Maszyny wirtualne mogą doświadczać dryfu zegara wynikającego z planowania pracy hosta, zatrzymywania i wznawiania maszyn oraz migracji między hostami; w takich środowiskach demony NTP wymagają zazwyczaj specjalnej konfiguracji, a niektóre implementacje – jak chrony – świadomie projektowano z myślą o tego rodzaju niestabilnych zegarach.

Rozwój i przyszłość

W ramach grupy roboczej NTP w IETF prowadzone są prace nad NTPv5. Wersja opisana w marcu 2026 roku jako aktywny Internet-Draft draft-ietf-ntp-ntpv5-08 nie była jeszcze standardem produkcyjnym, lecz roboczym projektem, który zgodnie z zasadami IETF mógł zostać zmieniony, zastąpiony albo wygasnąć. Projekt definiuje przede wszystkim format protokołu przesyłanego w sieci, a nie konkretne algorytmy filtrowania pomiarów, wyboru źródeł czasu ani dyscyplinowania zegara.

Najważniejsze kierunki zmian w projekcie NTPv5 można traktować jako odpowiedź na wieloletnie problemy NTPv4: historyczne tryby pracy trudne do zabezpieczenia, niejednoznaczności pól rozszerzeń, ograniczenia identyfikatorów źródeł i 64-bitowych znaczników czasu oraz słabą prywatność części informacji wysyłanych przez klienta. Projekt przewiduje zachowanie kompatybilności przez negocjację wersji: serwer obsługujący wiele wersji odpowiada wersją wskazaną przez klienta, jeśli ją wspiera.

Obszar zmian w NTPv5	Kierunek projektowy
tryby pracy	pozostają tylko tryby klienta i serwera; usunięto tryby symetryczne, broadcast, control i private
zakres specyfikacji	dokument opisuje protokół „na drucie”, a algorytmy klienta pozostawia implementacjom
format i rozszerzenia	nowy format komunikatu, pola rozszerzeń jako jedyny mechanizm opcjonalnych danych, MAC przeniesiony do pola rozszerzenia
skale czasu i era	obsługa UTC, TAI, UT1 i UTC z leap smear; przesyłanie numeru ery wydłuża jednoznaczny przedział czasu z 136 lat do około 35 tys. lat
dokładność	pole korekty pozwalające przenosić zmienne opóźnienia wprowadzane przez urządzenia pośrednie, a rozdzielczość pól root delay/root dispersion ma wzrosnąć z około 15 µs do około 4 ns
bezpieczeństwo i prywatność	jawniejsze użycie NTS i MAC oraz ograniczenie wycieku informacji o zegarze klienta, takich jak lokalne znaczniki czasu lub szacowana dokładność

Równolegle rozwija się infrastruktura dystrybucji czasu, a nie tylko sam protokół. W Polsce projekt e-CzasPL2, zaplanowany przez Główny Urząd Miar na lata 2025–2028, ma rozbudować kanały dostarczania czasu urzędowego m.in. o zapasowe centrum utrzymania czasu, co najmniej dwa fizycznie niezależne klastry serwerów pl.ntppool.org, bazę i monitoring krajowych źródeł czasu oraz autoryzowany sygnał czasu nadawany drogą radiową. Projekt jest uzasadniany między innymi zależnością systemów IT i OT od wiarygodnych źródeł czasu oraz ryzykiem ataków destabilizujących synchronizację.

Relacja do innych metod synchronizacji

NTP jest projektowany jako protokół ogólnego przeznaczenia dla heterogenicznych sieci, w tym publicznego Internetu. W zastosowaniach wymagających większej precyzji albo silniejszych gwarancji synchronizacji uzupełnia się go innymi technikami, a w niektórych obszarach zastępuje protokołami wyspecjalizowanymi.

• Precision Time Protocol (IEEE 1588) działa zwykle w kontrolowanej domenie sieciowej i wykorzystuje sprzętowe znacznikowanie czasu w przełącznikach oraz kartach sieciowych. Pozwala osiągać dokładności rzędu pojedynczych mikrosekund lub lepszej, ale wymaga współpracy infrastruktury sieciowej, co czyni go raczej uzupełnieniem niż prostym zastępnikiem NTP w sieci internetowej.
• Sygnał 1PPS (ang. pulse per second) dostarcza dokładny impuls raz na sekundę, używany do dyscyplinowania zegara o znacznie wyższej rozdzielczości niż osiąga sam NTP. Sygnał PPS bywa łączony z odbiornikiem GNSS lub innym wzorcem, a NTP używany jest wtedy do rozpropagowania czasu w sieci.
• Systemy GNSS, takie jak GPS, są w praktyce najpowszechniejszym źródłem stratum 0 dla serwerów stratum 1 na całym świecie; udostępniają zarówno znacznik czasu, jak i sygnał 1PPS. Wymagają jednak niezakłóconej widoczności anteny i są narażone na celowe zakłócanie albo spoofing sygnału satelitarnego.
• White Rabbit jest specjalistycznym rozszerzeniem PTP, dostarczającym synchronizację o dokładności rzędu pojedynczych nanosekund poprzez precyzyjny pomiar opóźnień włókna światłowodowego. Jest używany m.in. w fizyce wysokich energii i w infrastrukturach metrologicznych; w sieciach ogólnego przeznaczenia takie poziomy precyzji nie są potrzebne, a NTP pozostaje wystarczający.
• Klasyczne lokalne zegary referencyjne, na przykład odbiorniki sygnału DCF77 albo masery wodorowe, są używane jako stratum 0 tam, gdzie GNSS jest niedostępne albo niewystarczająco wiarygodne; NTP udostępnia czas z takich źródeł komputerom w sieci.

Z punktu widzenia czytelnika encyklopedycznego znaczenie ma zwłaszcza odróżnienie NTP od dwóch sąsiednich światów. Z jednej strony rośnie znaczenie skal czasu o rygorystycznie zdefiniowanej jednostce, takich jak Międzynarodowy czas atomowy (TAI), które nie zawierają sekund przestępnych – NTP rozprowadza standardowo UTC, więc wszelkie problemy z sekundami przestępnymi i leap smear dotyczą tej skali, nie samej fizyki pomiaru czasu. Z drugiej strony należy odróżniać czas systemowy od zegara monotonicznego używanego przez aplikacje do pomiaru upływu czasu między zdarzeniami – NTP odpowiada za pierwszy, ale nie zmienia drugiego.

Pokrewne standardy synchronizacji

Oprócz NTP i samego protokołu PTP istnieją profile i normy dostosowane do konkretnych zastosowań. Podstawową specyfikacją PTP jest IEEE 1588; aktywną wersją standardu jest IEEE 1588-2019, która zastąpiła IEEE 1588-2008, choć część starszych profili nadal odwołuje się do wersji z 2008 roku. IEEE 802.1AS-2025 opisuje synchronizację czasu w sieciach lokalnych i metropolitalnych dla zastosowań wrażliwych czasowo z rodziny Time-Sensitive Networking. Sektor telekomunikacyjny korzysta z profili PTP opisanych w zaleceniach ITU-T serii G.8275 – wariant G.8275.1 jest stosowany przy pełnym wsparciu sieci dla precyzyjnego znacznikowania czasu, a G.8275.2 w sieciach z częściowym wsparciem. W energetyce profil IEEE C37.238 opisuje użycie IEEE 1588/PTP w aplikacjach ochrony, sterowania, automatyki i komunikacji systemów elektroenergetycznych. NTP nie jest profilowany w ten sam sposób; pozostaje ogólnym mechanizmem synchronizacji o szerokim zastosowaniu w sieciach pakietowych.

Zastosowania

NTP jest używany w serwerach, stacjach roboczych, urządzeniach sieciowych, systemach wirtualizacji, klastrach obliczeniowych, usługach monitoringu i infrastrukturze internetowej. Spójny czas jest potrzebny do korelacji logów, poprawnej pracy mechanizmów kryptograficznych, harmonogramów zadań, replikacji baz danych, rozliczania transakcji oraz diagnozowania awarii w systemach rozproszonych.

Poza środowiskiem klasycznych centrów danych NTP jest typowym mechanizmem synchronizacji w urządzeniach Internetu rzeczy, sprzęcie telekomunikacyjnym, infrastrukturach przemysłowych, monitoringu energetyki i sieciach telekomunikacji mobilnej. W bardziej wymagających scenariuszach, jak telekomunikacja 5G, energetyka czy systemy transakcyjne, NTP zwykle współpracuje z PTP, GNSS albo dedykowanymi wzorcami czasu, dystrybuując mniej precyzyjny, ale szerzej dostępny czas do systemów ogólnego przeznaczenia.

W sieciach zarządzanych źródła czasu mogą być ustawiane ręcznie, przez konfigurację systemową, przez usługę katalogową albo automatycznie przez mechanizmy konfiguracji sieci. DHCPv4 przewiduje osobną opcję przekazującą klientom listę serwerów NTP, natomiast same dane strefy czasowej są zagadnieniem oddzielnym od synchronizacji zegara do UTC.

Najbardziej niezawodne wdrożenia nie opierają się na pojedynczym serwerze czasu. Typowa dobra praktyka polega na użyciu kilku niezależnych źródeł, kontrolowaniu obciążenia publicznych serwerów, monitorowaniu odchylenia i stratum, odróżnieniu wewnętrznych serwerów czasu od klientów końcowych oraz unikaniu konfiguracji, które tworzą pętle synchronizacji albo zależność od jednego dostawcy czasu.

Zobacz też

• serwer czasu
• Precision Time Protocol
• sygnał PPS
• uniwersalny czas koordynowany
• sekunda przestępna
• międzynarodowy czas atomowy
• DCF77

Linki zewnętrzne

• The NTP Project
• NTP Pool Project – wersja polska
• Dokumenty grupy roboczej NTP w IETF
• D.L.D.L. Mills D.L.D.L., DCNET Internet Clock Service, RFC 778, IETF, kwiecień 1981, DOI: 10.17487/RFC0778, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.L.D.L. Mills D.L.D.L., DCN Local-Network Protocols, STD 44, RFC 891, IETF, grudzień 1983, DOI: 10.17487/RFC0891, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.L.D.L. Mills D.L.D.L., Algorithms for synchronizing network clocks, RFC 956, IETF, wrzesień 1985, DOI: 10.17487/RFC0956, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.L.D.L. Mills D.L.D.L., Network Time Protocol (NTP), RFC 958, IETF, wrzesień 1985, DOI: 10.17487/RFC0958, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Mills D.D., 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.D. Mills D.D., 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.D. Mills D.D., J.J. Martin J.J., J.J. Burbank J.J., W.W. Kasch W.W., 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.B. Haberman B.B., D.D. Mills D.D., Network Time Protocol Version 4: Autokey Specification, RFC 5906, IETF, czerwiec 2010, DOI: 10.17487/RFC5906, ISSN 2070-1721, OCLC 943595667  (ang.).
• H.H. Gerstung H.H., C.C. Elliott C.C., B.B. Haberman B.B., 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.R. Gayraud R.R., B.B. Lourdelet B.B., 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.J.M. Combes J-M.J.M., S.S. Krishnan S.S., G.G. Daley G.G., Securing Neighbor Discovery Proxy: Problem Statement, RFC 5909, IETF, lipiec 2010, DOI: 10.17487/RFC5909, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Reilly D.D., H.H. Stenn H.H., D.D. Sibold D.D., Network Time Protocol Best Current Practices, BCP 223, RFC 8633, IETF, lipiec 2019, DOI: 10.17487/RFC8633, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Franke D.D., D.D. Sibold D.D., K.K. Teichel K.K., M.M. Dansarie M.M., R.R. Sundblad R.R., Network Time Security for the Network Time Protocol, RFC 8915, IETF, wrzesień 2020, DOI: 10.17487/RFC8915, ISSN 2070-1721, OCLC 943595667  (ang.).