NTP (Network Time Protocol) — sieciowy protokół synchronizacji zegara, zapewniający dokładność czasu do milisekund w sieciach lokalnych i do dziesiątek milisekund w sieci globalnej. Protokół opracowany przez Davida Millsa w 1985 roku jest używany we wszystkich nowoczesnych systemach operacyjnych, urządzeniach mobilnych i sprzęcie sieciowym do uzgadniania wewnętrznych zegarów z referencyjnym czasem UTC. Według NTP Pool Project (2026) ponad 4 miliardy urządzeń codziennie wykonuje zapytania NTP w celu synchronizacji.
Najważniejsze
NTP (Network Time Protocol) — to sieciowy protokół przeznaczony do precyzyjnej synchronizacji wewnętrznego zegara komputera z referencyjnym źródłem czasu przez sieć z komutacją pakietów. Protokół opisany w RFC 5905 (NTPv4) wykorzystuje hierarchiczny system serwerów, gdzie każdy poziom nazywany jest stratą (stratum). Klient NTP wysyła zapytania do serwera, mierzy czas przejścia pakietu (RTT, round-trip time) i oblicza przesunięcie własnego zegara względem czasu referencyjnego. Algorytm korekcji uwzględnia nie tylko jednorazowe przesunięcie, ale także dryf generatora taktowania, co pozwala utrzymać dokładność przez długi czas bez ponownych zapytań.
Protokół został opracowany przez Davida Millsa w 1985 roku dla sieci ARPANET. Pierwsza specyfikacja (RFC 958) opisywała prosty algorytm synchronizacji z dokładnością do 100 ms. NTPv3 (RFC 1305, 1992) dodał algorytm filtracji i ulepszone przetwarzanie opóźnień. NTPv4 (RFC 5905, 2010) — bieżąca wersja — zawiera obsługę IPv6, automatyczną konfigurację serwerów i ochronę przed atakami przez Network Time Security (NTS). Przez 40 lat protokół przeszedł drogę od projektu naukowego do standardu infrastrukturalnego, bez którego niemożliwa jest praca transakcji finansowych, telekomunikacji i sieci mobilnych.
Zasada działania NTP opiera się na pomiarze czasu przejścia pakietu w sieci. Klient wysyła zapytanie z oznaczeniem czasu T1 (lokalny czas wysłania). Serwer odbiera zapytanie w momencie T2 (czas serwera), tworzy odpowiedź z oznaczeniem T3 i wysyła ją. Klient odbiera odpowiedź w momencie T4. Znając wszystkie cztery znaczniki czasu, klient oblicza przesunięcie offset = ((T2 - T1) + (T3 - T4)) / 2 i opóźnienie delay = (T4 - T1) - (T3 - T2). Jeśli opóźnienie jest większe niż 1 sekunda, wynik uważa się za niewiarygodny — to ochrona przed przeciążonymi lub niestabilnymi kanałami.
Proste ustawienie dokładnego czasu jest niewystarczające — generator kwarcowy na urządzeniu stale dryfuje (spieszy się lub opóźnia) z powodu temperatury, starzenia i napięcia. NTP rozwiązuje ten problem za pomocą algorytmu PLL (Phase-Locked Loop): nie ustawia czasu siłą, ale dostraja prędkość chodu zegara. Jeśli urządzenie spieszy się o 0,1 sekundy na godzinę, NTP zwalnia chód zegara systemowego, aż dryf zostanie skompensowany. Takie podejście pozwala synchronizować się raz na kilka godzin w stabilnych sieciach, a nie co 30 sekund.
// Uproszczony schemat algorytmu NTP
struct NTPPacket {
uint8_t flags; // LI, VN, Tryb
uint8_t stratum; // poziom straty serwera
uint32_t refTimestamp; // znacznik czasu referencyjnego
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Oblicz przesunięcie i opóźnienie
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
Cały system NTP jest zorganizowany w hierarchię, gdzie każdy poziom nazywany jest stratą (stratum). Stratum 0 — to referencyjne zegary: zegary atomowe, odbiorniki GPS lub sygnały radiowe WWVB. Te urządzenia nie są podłączone bezpośrednio do sieci. Stratum 1 — serwery bezpośrednio podłączone do zegarów referencyjnych. Stratum 2 otrzymują czas od stratum 1, stratum 3 — od stratum 2, i tak dalej aż do stratum 15. Im wyższy numer straty, tym potencjalnie niższa dokładność — każdy poziom dodaje niewielkie opóźnienie i niedokładność. Stratum 16 oznacza, że czas jest niedostępny (niezsynchronizowany).
| Strata | Opis | Dokładność |
|---|---|---|
| Stratum 0 | Zegary atomowe, GPS, sygnały radiowe | Nanosekundy |
| Stratum 1 | Serwery podłączone do wzorca | Mikrosekundy |
| Stratum 2 | Publiczne serwery NTP | 1–10 ms |
| Stratum 3 | Lokalne serwery organizacji | 10–50 ms |
| Stratum 4+ | Urządzenia klienckie | do 100 ms |
Dla urządzeń mobilnych optymalne są serwery stratum 2 — jest ich wystarczająco dużo i zapewniają dobry balans między dokładnością a dostępnością. Na przykład pool.ntp.org — pula tysięcy serwerów na całym świecie, automatycznie rozkładająca obciążenie. W aplikacjach Android nie zaleca się bezpośredniego używania stratum 1: po pierwsze, powoduje to nadmierne obciążenie podstawowych serwerów, a po drugie, urządzenie mobilne potrzebuje dokładności 10–50 ms, którą zapewnia stratum 2. W sieciach korporacyjnych instaluje się lokalny serwer stratum 3-4, który synchronizuje się z zewnętrznym stratum 2.
SNTP (Simple Network Time Protocol, RFC 4330) — uproszczona implementacja NTP dla urządzeń z ograniczonymi zasobami: mikrokontrolerów, czujników IoT i aplikacji mobilnych, które nie wymagają wysokiej dokładności. W przeciwieństwie do pełnego NTP, SNTP nie wykonuje filtracji wielu serwerów, nie analizuje dryfu zegara i nie używa złożonych algorytmów PLL. Klient SNTP wysyła zapytanie, otrzymuje odpowiedź i jednorazowo ustawia czas. Dokładność SNTP wynosi 10–100 ms w zależności od sieci — to wystarcza dla zdecydowanej większości scenariuszy mobilnych, z wyjątkiem transakcji finansowych.
SNTP nadaje się do aplikacji Android, które potrzebują po prostu pobrać bieżący czas z serwera, nie utrzymując stałej synchronizacji. Na przykład aplikacja pokazuje czas z serwera przy logowaniu lub synchronizuje się raz na dobę. Pełny NTP jest wymagany dla systemów serwerowych, sprzętu telekomunikacyjnego, platform finansowych i rozproszonych baz danych, gdzie krytyczna jest stała dokładność i monitoring dryfu. Do programowania mobilnego wystarczy SNTP — wbudowany serwis czasu Androida używa go do okresowej synchronizacji z serwerami Google.
W aplikacjach Android pobieranie dokładnego czasu przez NTP jest wymagane, gdy czas systemowy może zostać zmieniony przez użytkownika lub różni się od rzeczywistego z powodu braku sieci. W Androidzie nie ma wbudowanego publicznego klienta NTP — programiści używają biblioteki Apache Commons Net SntpClient lub rozwiązań zewnętrznych. W 2022 roku Google dodała wewnętrzną klasę SntpClient do Android API (przez Google Play Services), ale wymaga ona konfiguracji i nie jest udokumentowana do ogólnego użytku. Alternatywne podejście — zapytanie o czas przez REST API, które zwraca znacznik czasu serwera w treści odpowiedzi.
Podstawowa implementacja SNTP na Androidzie polega na wysłaniu pakietu UDP na serwer NTP (np. pool.ntp.org), parsowaniu odpowiedzi i wyodrębnieniu czasu wysłania (T3 — Transmit Timestamp). Kod powinien obsługiwać przekroczenia czasu sieci i błędy parsowania — w rzeczywistej aplikacji tę operację wykonuje się w tle, a wynik jest buforowany do następnej synchronizacji. Biblioteka Apache Commons Net udostępnia gotową klasę NTPUDPClient, którą można użyć w Androidzie z minimalnymi modyfikacjami, dodając zależność w build.gradle.
// Pobierz czas NTP przez Apache Commons Net
fun getNtpTime(server: String = "pool.ntp.org"): Date? {
return try {
val client = NTPUDPClient()
client.setDefaultTimeout(5000)
val info = client.getTime(InetAddress.getByName(server))
client.close()
Date(info.getMessage().getTransmitTimeStamp().getTime())
} catch (e: Exception) {
null
}
}
Dokładność NTP zależy od kilku czynników: opóźnienia sieci (RTT), stabilności kanału, obciążenia serwera i jakości lokalnego generatora taktowania. W sieci lokalnej z opóźnieniem poniżej 1 ms NTP osiąga dokładność 0.1–1 ms. Przez internet przy opóźnieniu 10–50 ms dokładność spada do 10–50 ms. Ważniejsza niż jednorazowa dokładność jest stabilność: jeśli opóźnienie się zmienia (jitter), NTP potrzebuje więcej czasu na obliczenie wiarygodnego przesunięcia. Dla urządzeń mobilnych głównym czynnikiem niestabilności jest przełączanie między Wi-Fi a siecią komórkową, podczas którego opóźnienie może zmienić się o rząd wielkości.
W aplikacjach Android wrażliwych na dokładny czas zaleca się: używać kilku serwerów NTP i wybierać minimalne opóźnienie; nie synchronizować się w momentach przełączania sieci; buforować ostatni otrzymany czas i korygować go przez System.currentTimeMillis. Dla gier i aplikacji czasu rzeczywistego (NTP nie nadaje się ze względu na opóźnienie sieci) — używaj czasu serwerowego przekazywanego w każdym zapytaniu. W aplikacjach do operacji finansowych koniecznie sprawdzaj rozbieżność z serwerem — jeśli różnica jest większa niż 5 sekund, blokuj operację jako potencjalnie niebezpieczną.
Często zadawane pytania
NTP (Network Time Protocol) — protokół synchronizacji zegara przez internet. Służy do uzgadniania czasu na urządzeniach z referencyjnym UTC. Bez NTP zegary komputerowe rozchodzą się o sekundy dziennie z powodu dryfu generatora kwarcowego, co jest krytyczne dla transakcji finansowych, logowania i bezpieczeństwa.
System NTP używa poziomów — strat: stratum 0 (zegary atomowe i GPS), stratum 1 (serwery podłączone do wzorca), stratum 2 (publiczne serwery NTP), stratum 3–4 (serwery lokalne), stratum 5–15 (klienci). Im wyższa strata, tym większy potencjalny błąd. Stratum 16 oznacza, że czas nie jest zsynchronizowany.
SNTP — uproszczona wersja NTP dla urządzeń z ograniczonymi zasobami. Nie filtruje serwerów, nie analizuje dryfu zegara i nie używa PLL. SNTP nadaje się do aplikacji mobilnych, gdzie dokładność 10–100 ms jest wystarczająca. Pełny NTP jest potrzebny serwerom, sprzętowi telekomunikacyjnemu i systemom fintech.
Użyj biblioteki Apache Commons Net z klasą NTPUDPClient. Wyślij zapytanie na pool.ntp.org, otrzymaj odpowiedź i wyodrębnij Transmit Timestamp. Alternatywnie, użyj REST API swojego serwera, który zwraca czas serwerowy w nagłówku Date lub w treści odpowiedzi w formacie Unix Timestamp.
Bez synchronizacji NTP czas systemowy na urządzeniu może różnić się o minuty i godziny. Zaburza to działanie powiadomień push, certyfikatów SSL (sprawdzanie ważności), logów, harmonogramów zadań i protokołów kryptograficznych. W aplikacjach z operacjami finansowymi desynchronizacja powyżej 5 sekund jest uważana za zagrożenie bezpieczeństwa.
Podsumowanie
Opracujemy aplikację mobilną pod klucz
IT Sectr tworzy aplikacje na iOS i Androida dla startupów i firm od 2017 roku. Doradzimy Ci i zaproponujemy najlepsze rozwiązanie.
Przeczytaj również