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 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 rozwijana w ramach NTP Project, niezależnie napisany oraz utwardzony pod kątem bezpieczeństwa fork ; 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 mały|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.
t0 – czas wysłania zapytania przez klienta. t1 – czas odebrania zapytania przez serwer. t2 – czas wysłania odpowiedzi przez serwer. t3 – 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:
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 , 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 mały|Schemat hierarchii serwerów i klientów NTP; żółte strzałki oznaczają połączenia bezpośrednie, czerwone – połączenia sieciowe. mały|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 232 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