У меня есть приложение, в котором запущен REST API, и недавно возникла потребность иметь NTP-сервер, связанный с приложением. Мой вопрос в том, имеет ли смысл иметь в API конечную точку, которую пользователи могут запрашивать (т.е. api/ntp/time
), который возвращает пакеты NTP, и каковы последствия такой настройки?
Я пытался подключиться к этой конечной точке с помощью клиентов ntp, например ntpdate
и Python ntplib
, но эти клиенты делают предположение, что на IP-адресе порта 123 будет запущен NTP-сервер, и последние несколько дней исследований показали, что это предположение в значительной степени справедливо для большинства клиентских программ NTP.
Я использую конечную точку для обслуживания этой информации по нескольким причинам:
Как отмечено в комментариях, NTP не подходит для проксирования через HTTP. Из вашего комментария вам нужен NTP-сервер, работающий в сети, с которым синхронизируются устройства, у которых нет встроенных часов. Устройства без встроенных часов часто устанавливают свои часы с сервера NTP при запуске, и многие имеют клиент NTP, который позволяет им оставаться синхронизированными. Встроенные часы имеют тенденцию дрейфовать, поэтому рекомендуется использовать NTP для устройств со встроенными часами.
На вашем сервере должен быть запущен клиент NTP, чтобы время было точным. Затем вы можете использовать время сервера, чтобы ответить временем сервера. Я бы предложил использовать либо UTC, либо смещение UTC, если указывается время в вашем местном часовом поясе. Рассмотрим такой формат, как 2018-10-16T19: 20: 30.45 + 01: 00, который включает доли секунды. Устройства, использующие эти данные для установки своих часов, в конечном итоге будут отставать от правильного времени из-за эффектов задержки. У NTP есть механизмы для коррекции задержки.