NTP (Network Time Protocol) — ett nätverksprotokoll för klocksynkronisering som ger tidsnoggrannhet till millisekunder i lokala nätverk och till tiotals millisekunder i det globala nätverket. Protokollet, utvecklat av David Mills 1985, används i alla moderna operativsystem, mobila enheter och nätverksutrustning för att justera interna klockor med referenstiden UTC. Enligt NTP Pool Project (2026) utför över 4 miljarder enheter dagligen NTP-förfrågningar för synkronisering.
Huvudpunkter
NTP (Network Time Protocol) — är ett nätverksprotokoll utformat för exakt synkronisering av datorns interna klocka med en referenstidskälla via ett paketförmedlat nätverk. Protokollet, beskrivet i RFC 5905 (NTPv4), använder ett hierarkiskt system av servrar, där varje nivå kallas stratum. NTP-klienten skickar förfrågningar till servern, mäter paketets rundtur (RTT) och beräknar den egna klockans avvikelse i förhållande till referenstiden. Korrigeringsalgoritmen tar inte bara hänsyn till engångsavvikelsen utan även till klockgeneratorns drift, vilket gör det möjligt att bibehålla noggrannhet under lång tid utan upprepade förfrågningar.
Protokollet utvecklades av David Mills 1985 för ARPANET-nätverket. Den första specifikationen (RFC 958) beskrev en enkel synkroniseringsalgoritm med noggrannhet upp till 100 ms. NTPv3 (RFC 1305, 1992) lade till en filtreringsalgoritm och förbättrad hantering av fördröjningar. NTPv4 (RFC 5905, 2010) — den aktuella versionen — inkluderar stöd för IPv6, automatisk konfiguration av servrar och skydd mot attacker via Network Time Security (NTS). Under 40 år har protokollet gått från ett vetenskapligt projekt till en infrastrukturstandard, utan vilken finansiella transaktioner, telekommunikation och mobila nätverk är omöjliga.
Funktionsprincipen för NTP baseras på mätning av paketets restid i nätverket. Klienten skickar en förfrågan med tidsstämpel T1 (lokal sändningstid). Servern tar emot förfrågan vid tidpunkten T2 (servertid), skapar ett svar med tidsstämpel T3 och skickar det. Klienten tar emot svaret vid tidpunkten T4. Med kännedom om alla fyra tidsstämplarna beräknar klienten avvikelsen offset = ((T2 - T1) + (T3 - T4)) / 2 och fördröjningen delay = (T4 - T1) - (T3 - T2). Om fördröjningen är större än 1 sekund anses resultatet opålitligt — detta är skydd mot överbelastade eller instabila kanaler.
Att bara ställa in rätt tid är inte tillräckligt — kvartsgeneratorn på enheten driver ständigt (går framåt eller bakåt) på grund av temperatur, åldring och spänning. NTP löser detta problem med PLL (Phase-Locked Loop)-algoritmen: den ställer inte in tiden med tvång, utan justerar klockans hastighet. Om enheten går 0,1 sekund före per timme saktar NTP systemklockan tills driften är kompenserad. Detta tillvägagångssätt möjliggör synkronisering en gång varannan timme i stabila nätverk, istället för var 30:e sekund.
// Förenklat schema för NTP-algoritm
struct NTPPacket {
uint8_t flags; // LI, VN, Läge
uint8_t stratum; // serverns stratumnivå
uint32_t refTimestamp; // referens tidsstämpel
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Beräkna avvikelse och fördröjning
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
Hela NTP-systemet är organiserat i en hierarki, där varje nivå kallas stratum. Stratum 0 — referensklockor: atomklockor, GPS-mottagare eller WWVB-radiosignaler. Dessa enheter är inte direkt anslutna till nätverket. Stratum 1 — servrar direkt anslutna till referensklockor. Stratum 2 får tid från stratum 1, stratum 3 från stratum 2, och så vidare upp till stratum 15. Ju högre stratumnummer, desto lägre potentiell noggrannhet — varje nivå lägger till en liten fördröjning och fel. Stratum 16 betyder att tiden inte är tillgänglig (inte synkroniserad).
| Stratum | Beskrivning | Noggrannhet |
|---|---|---|
| Stratum 0 | Atomklockor, GPS, radiosignaler | Nanosekunder |
| Stratum 1 | Servrar anslutna till referens | Mikrosekunder |
| Stratum 2 | Offentliga NTP-servrar | 1–10 ms |
| Stratum 3 | Lokala servrar för organisationer | 10–50 ms |
| Stratum 4+ | Klientenheter | upp till 100 ms |
För mobila enheter är stratum 2-servrar optimala — de finns i tillräckligt antal och ger en bra balans mellan noggrannhet och tillgänglighet. Till exempel pool.ntp.org — en pool av tusentals servrar världen över som automatiskt fördelar belastningen. För Android-applikationer rekommenderas inte direkt användning av stratum 1: för det första skapar det överdriven belastning på primära servrar, och för det andra behöver en mobil enhet noggrannheten på 10–50 ms som stratum 2 tillhandahåller. I företagsnätverk installeras en lokal stratum 3-4-server som synkroniseras med en extern stratum 2.
SNTP (Simple Network Time Protocol, RFC 4330) — en förenklad implementering av NTP för enheter med begränsade resurser: mikrokontroller, IoT-sensorer och mobila applikationer som inte kräver hög noggrannhet. Till skillnad från full NTP utför SNTP inte filtrering av flera servrar, analyserar inte klockdrift och använder inte komplexa PLL-algoritmer. SNTP-klienten skickar en förfrågan, får ett svar och ställer in tiden en gång. Noggrannheten för SNTP är 10–100 ms beroende på nätverket — detta är tillräckligt för de allra flesta mobila scenarier, förutom finansiella transaktioner.
SNTP är lämpligt för Android-applikationer som helt enkelt behöver få den aktuella tiden från servern utan att upprätthålla konstant synkronisering. Till exempel visar applikationen tiden från servern vid inloggning eller synkroniseras en gång om dagen. Full NTP krävs för serversystem, telekommunikationsutrustning, finansiella plattformar och distribuerade databaser, där konstant noggrannhet och driftövervakning är kritiska. För mobil utveckling räcker SNTP — Android inbyggda tidstjänst använder det för periodisk synkronisering med Googles servrar.
I Android-applikationer krävs det att få exakt tid via NTP när systemtiden kan ändras av användaren eller avviker från den verkliga tiden på grund av nätverksbrist. Android har ingen inbyggd offentlig NTP-klient — utvecklare använder Apache Commons Net SntpClient-biblioteket eller tredjepartslösningar. 2022 lade Google till den interna klassen SntpClient i Android API (via Google Play Services), men den kräver konfiguration och är inte dokumenterad för allmän användning. Ett alternativt tillvägagångssätt — tidsförfrågan via REST API, som returnerar serverns tidsstämpel i svarstexten.
Grundimplementeringen av SNTP i Android består av att skicka ett UDP-paket till en NTP-server (t.ex. pool.ntp.org), tolka svaret och extrahera sändningstiden (T3 — Transmit Timestamp). Kod måste hantera nätverkstimeouts och tolkningsfel — i en verklig applikation utförs denna operation i bakgrunden och resultatet cachelagras till nästa synkronisering. Apache Commons Net-biblioteket tillhandahåller den färdiga klassen NTPUDPClient som kan användas i Android med minimala ändringar, genom att lägga till ett beroende i build.gradle.
// Hämta NTP-tid via 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
}
}
Noggrannheten hos NTP beror på flera faktorer: nätverksfördröjning (RTT), kanalstabilitet, serverbelastning och kvaliteten på den lokala klockgeneratorn. I ett lokalt nätverk med en fördröjning på mindre än 1 ms uppnår NTP en noggrannhet på 0.1–1 ms. Via internet med en fördröjning på 10–50 ms sjunker noggrannheten till 10–50 ms. Viktigare än engångsnoggrannhet är stabilitet: om fördröjningen varierar (jitter) behöver NTP mer tid för att beräkna en tillförlitlig avvikelse. För mobila enheter är den främsta instabilitetsfaktorn växling mellan Wi-Fi och mobilnät, där fördröjningen kan ändras med en storleksordning.
För Android-applikationer som är känsliga för exakt tid rekommenderas: använd flera NTP-servrar och välj minimal fördröjning; synkronisera inte vid tidpunkter för nätverksväxling; cachelagra den senast mottagna tiden och korrigera den via System.currentTimeMillis. För spel och realtidsapplikationer (NTP är inte lämpligt på grund av nätverksfördröjning) — använd servertiden som skickas med i varje förfrågan. I applikationer för finansiella transaktioner, kontrollera alltid avvikelsen från servern — om skillnaden är större än 5 sekunder, blockera operationen som potentiellt osäker.
Vanliga frågor
NTP (Network Time Protocol) — ett protokoll för klocksynkronisering via internet. Det behövs för att justera tiden på enheter med referens-UTC. Utan NTP avviker datorers klockor sekunder per dag på grund av kvartsgeneratorns drift, vilket är kritiskt för finansiella transaktioner, loggning och säkerhet.
NTP-systemet använder nivåer — stratum: stratum 0 (atomklockor och GPS), stratum 1 (servrar anslutna till referens), stratum 2 (offentliga NTP-servrar), stratum 3–4 (lokala servrar), stratum 5–15 (klienter). Ju högre stratum, desto större potentiellt fel. Stratum 16 betyder att tiden inte är synkroniserad.
SNTP — förenklad version av NTP för enheter med begränsade resurser. Den filtrerar inte servrar, analyserar inte klockdrift och använder inte PLL. SNTP är lämplig för mobila applikationer där noggrannheten 10–100 ms är tillräcklig. Full NTP behövs för servrar, telekommunikationsutrustning och fintech-system.
Använd biblioteket Apache Commons Net med klassen NTPUDPClient. Skicka en förfrågan till pool.ntp.org, ta emot svaret och extrahera Transmit Timestamp. Alternativt, använd REST API för din egen server som returnerar servertiden i Date-huvudet eller i svarstexten i Unix Timestamp-format.
Utan NTP-synkronisering kan systemtiden på enheten avvika med minuter och timmar. Detta stör push-notiser, SSL-certifikat (giltighetskontroll), loggar, uppgiftsplanerare och kryptografiska protokoll. I applikationer med finansiella transaktioner anses en avvikelse på mer än 5 sekunder vara ett säkerhetshot.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också