NTP (Network Time Protocol) — un protocol de rețea pentru sincronizarea ceasului, care asigură o precizie a timpului de până la milisecunde în rețelele locale și până la zeci de milisecunde în rețeaua globală. Protocolul, dezvoltat de David Mills în 1985, este utilizat în toate sistemele de operare moderne, dispozitivele mobile și echipamentele de rețea pentru sincronizarea ceasurilor interne cu timpul de referință UTC. Conform NTP Pool Project (2026), peste 4 miliarde de dispozitive efectuează zilnic cereri NTP pentru sincronizare.
Principalele puncte
NTP (Network Time Protocol) — este un protocol de rețea destinat sincronizării precise a ceasului intern al computerului cu o sursă de timp de referință printr-o rețea cu comutare de pachete. Protocolul, descris în RFC 5905 (NTPv4), utilizează un sistem ierarhic de servere, unde fiecare nivel se numește strat (stratum). Clientul NTP trimite cereri către server, măsoară timpul de călătorie al pachetului (RTT, round-trip time) și calculează decalajul propriului ceas față de timpul de referință. Algoritmul de corecție ia în considerare nu doar decalajul unic, ci și derivarea generatorului de tact, ceea ce permite menținerea preciziei pentru o perioadă lungă fără cereri repetate.
Protocolul a fost dezvoltat de David Mills în 1985 pentru rețeaua ARPANET. Prima specificație (RFC 958) descria un algoritm simplu de sincronizare cu o precizie de până la 100 ms. NTPv3 (RFC 1305, 1992) a adăugat algoritmul de filtrare și procesarea îmbunătățită a întârzierilor. NTPv4 (RFC 5905, 2010) — versiunea curentă — include suport pentru IPv6, configurarea automată a serverelor și protecția împotriva atacurilor prin Network Time Security (NTS). În 40 de ani, protocolul a trecut de la un proiect științific la un standard de infrastructură, fără de care funcționarea tranzacțiilor financiare, telecomunicațiilor și rețelelor mobile este imposibilă.
Principiul de funcționare al NTP se bazează pe măsurarea timpului de călătorie al pachetului în rețea. Clientul trimite o cerere cu marcajul temporal T1 (timpul local de trimitere). Serverul primește cererea în momentul T2 (timpul serverului), creează un răspuns cu marcajul T3 și îl trimite. Clientul primește răspunsul în momentul T4. Cunoscând toate cele patru marcaje temporale, clientul calculează decalajul offset = ((T2 - T1) + (T3 - T4)) / 2 și întârzierea delay = (T4 - T1) - (T3 - T2). Dacă întârzierea este mai mare de 1 secundă, rezultatul este considerat neveridic — aceasta este o protecție împotriva canalelor suprasolicitate sau instabile.
Simpla setare a timpului exact nu este suficientă — generatorul de cuarț de pe dispozitiv derivă constant (avansează sau întârzie) din cauza temperaturii, îmbătrânirii și tensiunii. NTP rezolvă această problemă cu algoritmul PLL (Phase-Locked Loop): nu setează timpul forțat, ci ajustează viteza de mers a ceasului. Dacă dispozitivul avansează cu 0,1 secunde pe oră, NTP încetinește mersul ceasului de sistem până când derivarea este compensată. Această abordare permite sincronizarea o dată la câteva ore în rețele stabile, nu la fiecare 30 de secunde.
// Schema simplificată a algoritmului NTP
struct NTPPacket {
uint8_t flags; // LI, VN, Mod
uint8_t stratum; // nivelul stratului serverului
uint32_t refTimestamp; // marcaj temporal de referință
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Calculați decalajul și întârzierea
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
Întregul sistem NTP este organizat într-o ierarhie, unde fiecare nivel se numește strat (stratum). Stratum 0 — ceasuri de referință: ceasuri atomice, receptoare GPS sau semnale radio WWVB. Aceste dispozitive nu sunt conectate direct la rețea. Stratum 1 — servere conectate direct la ceasurile de referință. Stratum 2 primesc timpul de la stratum 1, stratum 3 — de la stratum 2 și așa mai departe până la stratum 15. Cu cât numărul stratului este mai mare, cu atât precizia este potențial mai mică — fiecare nivel adaugă o mică întârziere și eroare. Stratum 16 înseamnă că timpul este indisponibil (nesincronizat).
| Strat | Descriere | Precizie |
|---|---|---|
| Stratum 0 | Ceasuri atomice, GPS, semnale radio | Nanosecunde |
| Stratum 1 | Servere conectate la referință | Microsecunde |
| Stratum 2 | Servere publice NTP | 1–10 ms |
| Stratum 3 | Servere locale ale organizațiilor | 10–50 ms |
| Stratum 4+ | Dispozitive client | până la 100 ms |
Pentru dispozitivele mobile, serverele stratum 2 sunt optime — sunt suficiente și asigură un echilibru bun între precizie și disponibilitate. De exemplu, pool.ntp.org — un pool de mii de servere din întreaga lume, care distribuie automat încărcarea. Pentru aplicațiile Android, nu se recomandă utilizarea directă a stratum 1: în primul rând, creează o sarcină excesivă asupra serverelor primare, iar în al doilea rând, dispozitivul mobil are nevoie de o precizie de 10–50 ms, pe care o asigură stratum 2. În rețelele corporative, se instalează un server local stratum 3-4, care se sincronizează cu un stratum 2 extern.
SNTP (Simple Network Time Protocol, RFC 4330) — o implementare simplificată a NTP pentru dispozitive cu resurse limitate: microcontrolere, senzori IoT și aplicații mobile care nu necesită precizie ridicată. Spre deosebire de NTP complet, SNTP nu efectuează filtrarea mai multor servere, nu analizează derivarea ceasului și nu utilizează algoritmi complecși PLL. Clientul SNTP trimite o cerere, primește un răspuns și setează timpul o singură dată. Precizia SNTP este de 10–100 ms în funcție de rețea — acest lucru este suficient pentru marea majoritate a scenariilor mobile, cu excepția tranzacțiilor financiare.
SNTP este potrivit pentru aplicațiile Android care au nevoie doar să obțină timpul curent de la server, fără a menține o sincronizare constantă. De exemplu, aplicația afișează timpul de la server la autentificare sau se sincronizează o dată pe zi. NTP complet este necesar pentru sistemele server, echipamentele de telecomunicații, platformele financiare și bazele de date distribuite, unde precizia constantă și monitorizarea derivării sunt critice. Pentru dezvoltarea mobilă, SNTP este suficient — serviciul de timp încorporat al Android îl utilizează pentru sincronizarea periodică cu serverele Google.
În aplicațiile Android, obținerea timpului exact prin NTP este necesară atunci când timpul de sistem poate fi modificat de utilizator sau diferă de cel real din cauza lipsei rețelei. Android nu are un client NTP public încorporat — dezvoltatorii utilizează biblioteca Apache Commons Net SntpClient sau soluții terțe. În 2022, Google a adăugat clasa internă SntpClient în Android API (prin Google Play Services), dar aceasta necesită configurare și nu este documentată pentru uz general. O abordare alternativă — cererea de timp prin REST API, care returnează timestamp-ul serverului în corpul răspunsului.
Implementarea de bază a SNTP pe Android constă în trimiterea unui pachet UDP către un server NTP (de exemplu, pool.ntp.org), parsarea răspunsului și extragerea timpului de trimitere (T3 — Transmit Timestamp). Codul trebuie să gestioneze timeout-urile de rețea și erorile de parsare — într-o aplicație reală, această operație se execută într-un fir de execuție în fundal, iar rezultatul este stocat în cache până la următoarea sincronizare. Biblioteca Apache Commons Net oferă clasa gata făcută NTPUDPClient, care poate fi utilizată în Android cu modificări minime, adăugând dependența în build.gradle.
// Obțineți timpul NTP prin 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
}
}
Precizia NTP depinde de mai mulți factori: întârzierea rețelei (RTT), stabilitatea canalului, încărcarea serverului și calitatea generatorului local de tact. În rețeaua locală cu o întârziere mai mică de 1 ms, NTP atinge o precizie de 0.1–1 ms. Prin internet, cu o întârziere de 10–50 ms, precizia scade la 10–50 ms. Mai importantă decât precizia unică este stabilitatea: dacă întârzierea variază (jitter), NTP are nevoie de mai mult timp pentru a calcula un decalaj fiabil. Pentru dispozitivele mobile, factorul principal de instabilitate este comutarea între Wi-Fi și rețeaua mobilă, când întârzierea se poate modifica cu un ordin de mărime.
Pentru aplicațiile Android sensibile la timpul exact, se recomandă: utilizați mai multe servere NTP și alegeți întârzierea minimă; nu sincronizați în momentele de comutare a rețelei; stocați în cache ultimul timp primit și corectați-l prin System.currentTimeMillis. Pentru jocuri și aplicații în timp real (NTP nu este potrivit din cauza întârzierii de rețea) — utilizați timpul serverului transmis în fiecare cerere. În aplicațiile pentru tranzacții financiare, verificați obligatoriu diferența cu serverul — dacă diferența este mai mare de 5 secunde, blocați operațiunea ca potențial nesigură.
Întrebări frecvente
NTP (Network Time Protocol) — protocol de sincronizare a ceasului prin internet. Este necesar pentru sincronizarea timpului pe dispozitive cu UTC de referință. Fără NTP, ceasurile computerelor deviază cu secunde pe zi din cauza derivării generatorului de cuarț, ceea ce este critic pentru tranzacțiile financiare, logare și securitate.
Sistemul NTP utilizează niveluri — strați: stratum 0 (ceasuri atomice și GPS), stratum 1 (servere conectate la referință), stratum 2 (servere NTP publice), stratum 3–4 (servere locale), stratum 5–15 (clienți). Cu cât stratul este mai mare, cu atât eroarea potențială este mai mare. Stratum 16 înseamnă că timpul nu este sincronizat.
SNTP — versiune simplificată a NTP pentru dispozitive cu resurse limitate. Nu filtrează servere, nu analizează derivarea ceasului și nu utilizează PLL. SNTP este potrivit pentru aplicații mobile unde precizia de 10–100 ms este suficientă. NTP complet este necesar serverelor, echipamentelor de telecomunicații și sistemelor fintech.
Utilizați biblioteca Apache Commons Net cu clasa NTPUDPClient. Trimiteți o cerere la pool.ntp.org, primiți răspunsul și extrageți Transmit Timestamp. Alternativ, utilizați REST API propriului server, care returnează timpul serverului în antetul Date sau în corpul răspunsului în format Unix Timestamp.
Fără sincronizarea NTP, timpul de sistem pe dispozitiv poate diferi cu minute și ore. Acest lucru afectează funcționarea notificărilor push, certificatelor SSL (verificarea valabilității), logurilor, planificatoarelor de sarcini și protocoalelor criptografice. În aplicațiile cu tranzacții financiare, desincronizarea de peste 5 secunde este considerată o amenințare de securitate.
Concluzii
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și