NTP (Network Time Protocol) — сетевой протокол синхронизации часов, обеспечивающий точность времени до миллисекунд в локальных сетях и до десятков миллисекунд в глобальной сети. Протокол, разработанный Дэвидом Миллсом в 1985 году, используется во всех современных операционных системах, мобильных устройствах и сетевом оборудовании для согласования внутренних часов с эталонным временем UTC. По данным NTP Pool Project (2026), более 4 миллиардов устройств ежедневно выполняют NTP-запросы для синхронизации.
Главное
NTP (Network Time Protocol) — это сетевой протокол, предназначенный для точной синхронизации внутренних часов компьютера с эталонным источником времени через сеть с пакетной коммутацией. Протокол, описанный в RFC 5905 (NTPv4), использует иерархическую систему серверов, где каждый уровень называется стратой (stratum). NTP-клиент отправляет запросы на сервер, измеряет время прохождения пакета (RTT, round-trip time) и вычисляет смещение собственных часов относительно эталонного времени. Алгоритм коррекции учитывает не только однократное смещение, но и дрейф тактового генератора, что позволяет поддерживать точность длительное время без повторных запросов.
Протокол был разработан Дэвидом Миллсом в 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 года. Мы проконсультируем вас и предложим наилучшее решение.
Читайте также