NTP (Network Time Protocol) — це мережевий протокол синхронізації часу, що забезпечує точність до мілісекунд у локальних мережах і до десятків мілісекунд у глобальній мережі. Розроблений Девідом Міллсом у 1985 році, протокол використовується в усіх сучасних операційних системах, мобільних пристроях і мережевому обладнанні для узгодження внутрішніх годинників з еталонним часом UTC. За даними NTP Pool Project (2026), понад 4 мільярди пристроїв щодня виконують NTP-запити для синхронізації.
Головне
NTP (Network Time Protocol) — це мережевий протокол, призначений для точного синхронізування внутрішнього годинника комп'ютера з еталонним джерелом часу через мережу з пакетною комутацією. Описаний у RFC 5905 (NTPv4), протокол використовує ієрархічну систему серверів, де кожен рівень називається стратою (stratum). NTP-клієнт надсилає запити на сервер, вимірює час проходження пакета (RTT) і обчислює зміщення власного годинника відносно еталонного часу. Алгоритм корекції враховує не лише одноразове зміщення, а й дрейф тактового генератора, що дозволяє підтримувати точність тривалий час без повторних запитів.
Протокол був розроблений Девідом Міллсом у 1985 році для мережі ARPANET. Перша специфікація (RFC 958) описувала простий алгоритм синхронізації з точністю до 100 мс. NTPv3 (RFC 1305, 1992) додав алгоритм фільтрації та покращену обробку затримок. NTPv4 (RFC 5905, 2010) — поточна версія — включає підтримку IPv6, автоматичне налаштування серверів і захист від атак через Network Time Security (NTS). За 40 років протокол пройшов шлях від наукового проекту до інфраструктурного стандарту, без якого неможлива робота фінансових транзакцій, телекомунікацій і мобільних мереж.
Принцип роботи NTP ґрунтується на вимірюванні часу проходження пакета в мережі. Клієнт надсилає запит з позначкою часу T1 (локальний час відправлення). Сервер отримує запит у момент T2 (серверний час), формує відповідь з позначкою T3 і надсилає її. Клієнт отримує відповідь у момент T4. Знаючи всі чотири часові позначки, клієнт обчислює зміщення offset = ((T2 - T1) + (T3 - T4)) / 2 та затримку delay = (T4 - T1) - (T3 - T2). Якщо затримка більша за 1 секунду, результат вважається недостовірним — це захист від перевантажених або нестабільних каналів.
Просте встановлення точного часу недостатньо — кварцовий генератор на пристрої постійно дрейфує (тікає вперед або назад) через температуру, старіння та напругу. NTP вирішує цю проблему за допомогою алгоритму PLL (Phase-Locked Loop): він не встановлює час примусово, а підлаштовує швидкість ходу годинника. Якщо пристрій поспішає на 0,1 секунди на годину, NTP уповільнює хід системного годинника доти, доки дрейф не буде компенсовано. Такий підхід дозволяє синхронізуватися раз на кілька годин у стабільних мережах, а не кожні 30 секунд.
// Simplified NTP algorithm schema
struct NTPPacket {
uint8_t flags; // LI, VN, Mode
uint8_t stratum; // server stratum level
uint32_t refTimestamp; // reference timestamp
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Calculate offset and delay
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
Вся система NTP організована в ієрархію, де кожен рівень називається стратою (stratum). Stratum 0 — це еталонні годинники: атомні годинники, GPS-приймачі або радіосигнали WWVB. Ці пристрої не підключені до мережі безпосередньо. Stratum 1 — сервери, безпосередньо підключені до еталонних годинників. Stratum 2 отримують час від stratum 1, stratum 3 — від stratum 2, і так далі до stratum 15. Чим вище число страти, тим потенційно нижча точність — кожен рівень додає невелику затримку та похибку. Stratum 16 означає, що час недоступний (не синхронізовано).
| Страта | Опис | Точність |
|---|---|---|
| Stratum 0 | Атомні годинники, GPS, радіосигнали | Наносекунди |
| Stratum 1 | Сервери, прив'язані до еталону | Мікросекунди |
| Stratum 2 | Публічні NTP-сервери | 1–10 мс |
| Stratum 3 | Локальні сервери організацій | 10–50 мс |
| Stratum 4+ | Клієнтські пристрої | до 100 мс |
Для мобільних пристроїв оптимальні сервери stratum 2 — їх достатньо багато і вони забезпечують хороший баланс між точністю та доступністю. Наприклад, pool.ntp.org — пул із тисяч серверів по всьому світу, що автоматично розподіляє навантаження. Для Android-додатків не рекомендується використовувати stratum 1 безпосередньо: по-перше, це створює надмірне навантаження на первинні сервери, а по-друге, мобільному пристрою достатньо точності 10–50 мс, яку забезпечує stratum 2. У корпоративних мережах встановлюють локальний stratum 3-4 сервер, який синхронізується із зовнішнім stratum 2.
SNTP (Simple Network Time Protocol, RFC 4330) — спрощена реалізація NTP для пристроїв з обмеженими ресурсами: мікроконтролерів, IoT-датчиків і мобільних додатків, що не потребують високої точності. На відміну від повного NTP, SNTP не виконує фільтрацію кількох серверів, не аналізує дрейф годинника і не використовує складні алгоритми PLL. SNTP-клієнт надсилає запит, отримує відповідь і одноразово встановлює час. Точність SNTP становить 10–100 мс залежно від мережі — цього достатньо для переважної більшості мобільних сценаріїв, крім фінансових транзакцій.
SNTP підходить для Android-додатків, яким потрібно просто отримати поточний час із сервера, не підтримуючи постійну синхронізацію. Наприклад, додаток показує час із сервера при вході або синхронізується раз на добу. Повний NTP потрібен для серверних систем, телекомунікаційного обладнання, фінансових платформ і розподілених баз даних, де критична постійна точність і моніторинг дрейфу. Для мобільної розробки достатньо SNTP — вбудований Android-сервіс часу використовує його для періодичної синхронізації з серверами Google.
В Android-додатках отримання точного часу через NTP потрібне, коли системний час може бути змінений користувачем або відрізняється від реального через відсутність мережі. На Android немає вбудованого публічного NTP-клієнта — розробники використовують бібліотеку Apache Commons Net SntpClient або сторонні рішення. У 2022 році Google додала внутрішній клас SntpClient в Android API (через Google Play Services), але він потребує налаштування і не задокументований для загального використання. Альтернативний підхід — запит часу через REST API, який повертає серверний timestamp у тілі відповіді.
Базова реалізація SNTP на Android складається з надсилання UDP-пакета на NTP-сервер (наприклад, pool.ntp.org), парсингу відповіді та вилучення часу відправлення (T3 — Transmit Timestamp). Код повинен обробляти таймаути мережі та помилки парсингу — в реальному додатку цю операцію виконують у фоновому потоці, а результат кешують до наступної синхронізації. Бібліотека Apache Commons Net надає готовий клас NTPUDPClient, який можна використовувати в Android з мінімальними доробками, додавши залежність у build.gradle.
// Get NTP time 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
}
}
Точність NTP залежить від кількох факторів: затримки мережі (RTT), стабільності каналу, завантаження сервера та якості локального тактового генератора. У локальній мережі із затримкою менше 1 мс NTP досягає точності 0.1–1 мс. Через інтернет при затримці 10–50 мс точність знижується до 10–50 мс. Важливіше за одноразову точність — стабільність: якщо затримка варіюється (jitter), NTP потрібно більше часу для обчислення достовірного зміщення. Для мобільних пристроїв основний фактор нестабільності — перемикання між Wi-Fi та мобільною мережею, при якому затримка може змінитися на порядок.
Для Android-додатків, критичних до точного часу, рекомендується: використовувати кілька NTP-серверів і вибирати мінімальну затримку; не синхронізуватися в моменти перемикання мережі; кешувати останній отриманий час і коригувати його через System.currentTimeMillis. Для ігор і додатків реального часу (NTP тут не годиться через затримку мережі) — використовуйте серверний час, що передається в кожному запиті. У додатках для фінансових операцій обов'язково перевіряйте розбіжність із сервером — якщо різниця більша за 5 секунд, блокуйте операцію як потенційно небезпечну.
Часті запитання
NTP (Network Time Protocol) — протокол синхронізації годинника через інтернет. Він потрібен для узгодження часу на пристроях з еталонним UTC. Без NTP комп'ютерні годинники тікають на секунди на день через дрейф кварцового генератора, що критично для фінансових транзакцій, логування та безпеки.
Система NTP використовує рівні — страти: stratum 0 (атомні годинники та GPS), stratum 1 (сервери, підключені до еталону), stratum 2 (публічні NTP-сервери), stratum 3–4 (локальні сервери), stratum 5–15 (клієнти). Чим вища страта, тим більша потенційна похибка. Stratum 16 означає, що час не синхронізовано.
SNTP — спрощена версія NTP для пристроїв з обмеженими ресурсами. Він не фільтрує сервери, не аналізує дрейф годинника і не використовує PLL. SNTP підходить для мобільних додатків, де точність 10–100 мс достатня. Повний NTP потрібен серверам, телекомунікаційному обладнанню та фінтех-системам.
Використовуйте бібліотеку Apache Commons Net з класом NTPUDPClient. Надішліть запит на pool.ntp.org, отримайте відповідь і вилучіть Transmit Timestamp. Альтернативно, використовуйте REST API вашого сервера, який повертає серверний час у заголовку Date або в тілі відповіді у форматі Unix Timestamp.
Без синхронізації NTP системний час на пристрої може відрізнятися на хвилини та години. Це порушує роботу push-сповіщень, SSL-сертифікатів (перевірка терміну дії), логів, планувальників завдань і криптографічних протоколів. У додатках з фінансовими операціями розсинхронізація більш ніж на 5 секунд вважається загрозою безпеки.
Підсумки
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також