ntp клиент что это
Пишем простой NTP-клиент
Всем привет, сегодня напишем свой простенький NTP клиент. В основном, разговор зайдет о структуре пакета и способе обработки ответа с NTP сервера. Код будет написан на питоне, потому что, как мне кажется, лучшего языка для подобных вещей просто не найти. Знатоки обратят внимание на схожесть кода с кодом ntplib — я «вдохновлялся» именно им.
Итак, что вообще такое NTP? NTP – протокол взаимодействия с серверами точного времени. Этот протокол используется во многих современных машинах. Например, служба w32tm в windows.
Всего существует 5 версий NTP протокола. Первая, 0-я версия (1985 г, RFC958)), в данный момент считается устаревшей. Сейчас используются более новые, 1-я (1988, RFC1059), 2-я(1989, RFC1119), 3-я(1992, RFC1305) и 4-я(1996, RFC2030). 1-4 версии являются совместимыми друг с другом, они отличаются лишь алгоритмами работы серверов.
Формат пакета
Leap indicator (индикатор коррекции) — число, показывающее предупреждение о секунде координации. Значение:
Mode (режим) — режим работы отправителя пакета. Значение от 0 до 7, наиболее частые:
Два последних поля рассматривать не будем.
Чтобы слать (и принимать) пакет на сервер, мы должны уметь превращать его в массив байт.
Для этой (и обратной) операции напишем две функции — pack() и unpack():
Отправка пакета на сервер
На сервер необходимо отправить пакет с заполненными полями Version, Mode и Transmit. В Transmit необходимо указать текущее время на локальной машине (количество секунд с 1 января 1900 г), версия — любая из 1-4, режим — 3 (режим клиента).
Сервер, приняв запрос, заполняет в NTP-пакете все поля, скопировав в поле Originate значение из Transmit, пришедшее в запросе. Для меня является загадкой, почему клиент не может сразу заполнить значение своего времени в поле Originate. В итоге, когда пакет приходит обратно, у клиента есть 4 значения времени – время отправки запроса (Originate), время получения запроса сервером (Receive), время отправки ответа сервером (Transmit) и время получения ответа клиентом – Arrive (нет в пакете). С помощью этих значений мы можем установить корректное время.
Обработка данных с сервера
Обработка данных с сервера аналогична действиям английского джентльмена из старой задачи Рэймонда М. Смаллиана (1978): «У одного человека не было наручных часов, но зато дома висели точные настенные часы, которые он иногда забывал заводить. Однажды, забыв очередной раз завести часы, он отправился в гости к своему другу, провел у того вечер, а вернувшись домой, сумел правильно поставить часы. Каким образом ему удалось это сделать, если время в пути заранее известно не было?» Ответ таков: «Выходя из дома, человек заводит часы и запоминает, в каком положении находятся стрелки. Придя к другу и уходя из гостей, он отмечает время своего прихода и ухода. Это позволяет ему узнать, сколько он находился в гостях. Вернувшись домой и взглянув на часы, человек определяет продолжительность своего отсутствия. Вычитая из этого времени то время, которое он провел в гостях, человек узнает время, затраченное на дорогу туда и обратно. Прибавив ко времени выхода из гостей половину времени, затраченного на дорогу, он получает возможность узнать время прихода домой и перевести соответствующим образом стрелки своих часов.»
Находим время работы сервера над запросом:
Протоколы NTP и SNTP: различия и как они работают
NTP (Cеть Протокол времени) и SNTP (простой протокол сетевого времени) два основных протокола для правильного функционирования Интернета. Оба протокола позволяют всем устройствам в сети, таким как компьютеры, серверы, коммутаторы, маршрутизаторы, Smart TV или любые другие устройства, подключенные к Интернету, иметь возможность иметь правильное время в вашей системе, чтобы не возникало проблем. при просмотре. онлайн или выполнить любую задачу. Сегодня в этой статье мы собираемся подробно объяснить оба временных протокола, различия между NTP и SNTP, а также то, как они настроены на разных устройствах.
Что такое NTP (сетевой протокол времени) и как он работает?
Со временем проблемы безопасности, связанные с протоколом NTP были обнаружены как в реализации в различных операционных системах, в клиентах NTP на разных компьютерах, так и во внутренней безопасности самого протокола, который он не использует. любой тип аутентификации или шифрования данных для обмена сообщениями. Серверы NTP уязвимы для атак Man in the Middle, если пакеты не подписаны криптографически, то же самое касается самих компьютеров, он может выполнять атаки MitM для изменения времени на конечных компьютерах. Протокол NTP отправляет всю информацию в виде обычного текста, он не имеет какого-либо типа шифрования, аутентичность или целостность данных проверяется. Чтобы этого избежать, сетевое время Безопасность (NTS) был разработан протокол, который представляет собой безопасную версию NTP, использующую TLS и AEAD для защиты связи, и что никто не может выдавать себя за сервер NTP для неправильной настройки времени в нашей системе.
Что делать, если в моей системе нет правильного времени?
Как видите, у нас много проблем, когда дело доходит до неправильного времени в определенной компьютерной системе.
Что такое SNTP (простой протокол сетевого времени) и как он работает?
SNTPv4 обеспечивает упрощенный доступ для серверов и клиентов, которые используют текущую и предыдущую версии NTP и сам SNTP, доступ идентичен протоколу UDP / TIME, поэтому адаптация должна быть очень простой. Этот протокол разработан для работы в конфигурации с выделенным сервером, который включает в себя встроенные радиочасы, кроме того, были улучшены и контролировались задержки, точное время можно вводить за несколько микросекунд без каких-либо проблем.
Различия между NTP и SNTP
Основное различие между NTP и SNTP заключается в том, что последний не требует какого-либо типа хранения состояния в течение очень длительных периодов времени, что делает протокол NTP. Очень важным отличием для сетевых администраторов является работа связи, позволяющая или запрещать трафик на межсетевых экранах или создавать списки контроля доступа на управляемых коммутаторах.
Протокол NTP работает с протоколом UDP на порту 123, этот порт 123 UDP используется для связи как в источнике, так и в пункте назначения. Как мы объясняли ранее, если вы активировали «атаку Blat» в коммутаторах, и у вас есть устройство, которое использует чистый протокол NTP, оно наверняка блокирует трафик только от NTP без вашего ведома.
Как вы видели, протоколы NTP и SNTP являются двумя фундаментальными и очень важными протоколами для компьютерных систем, поэтому важно правильно настроить время либо в операционной системе вашего настольного компьютера, либо в другом сетевом оборудовании, которое у вас есть.
Как установить и настроить NTP на сервере
Работа многих служб ОС зависит от того, насколько точны системные часы. Для чего нужна эта точность? Затем, что неточное время на сервере повлечет за собой много неприятностей.
В качестве примера приведем следующий: если в локальной сети часы машин, которые совместно используют файлы, не будут синхронизированы, то нельзя будет установить время изменения файлов. Из-за этого возникнет конфликт версий или перезаписи данных. Без установки точного времени на сервере появятся и сложности с задачами Cron – непонятно, когда они запустятся. Невозможно будет проанализировать журналы системных событий, чтобы понять причины неисправностей и сбоев.
Для того чтобы эти неприятности не возникли, нужно наладить синхронизацию системных часов. Для этого используется протокол NTP (Network Time Protocol).
Как устроен протокол NTP
Протокол NTP основан на иерархической структуре сервера точного времени, где выделены разные уровни. К нулевому уровню, на котором NTP-серверы не работают, относятся так называемые эталонные часы.
С ними синхронизируются NTP серверы уровня 1, являющиеся источниками для серверов уровня 2. Серверы второго уровня синхронизируются с серверами первого уровня, но еще могут синхронизироваться между собой. Точно так же функционируют серверы третьего уровня и ниже. В целом, поддерживается порядка 256 уровней.
Иерархическая структура NTP является отказоустойчивой и избыточной. Так, резервные серверы берут синхронизацию на себя, когда речь идет об отказах соединения с вышестоящими серверами. Для расчета точного времени NTP берет данные ото всех источников, синхронизируясь с несколькими серверами.
Как установить и настроить NTP-сервер
Чтобы синхронизировать время, используют демон ntpd, который может быть как сервером, принимающим время из удаленных хостов, так и клиентом, раздающим время сторонним хостам. Демон ntpd зависит от указанных в файле конфигурации настроек.
Для установки сервера NTP используется стандартный менеджер пакетов $ sudo apt-get install ntp.
После установки все необходимые настройки NTP будут находиться в файле /etc/ntp.conf.
Первая строчка файла конфигурации – driftfile /var/lib/ntp/ntp.drift. В ней указан файл, в котором хранится информация о том, как часто смещается время. В этом же файле содержится и значение, которое было получено из предыдущих изменений времени. Если по каким-то причинам внешние NTP-серверы недоступны, знание берут из этого файла.
После этого нужно указать файл, сохраняющий логи синхронизации – logfile /var/log/ntp.log.
В файле конфигурации нужно указать перечень серверов NTP, с которыми нужно синхронизироваться. По умолчанию этот перечень выглядит вот так:
Эти строки означают группу серверов, которые сообщают серверу верное время. Через опцию iburst можно увеличить точность синхронизации, то есть указать то, что на сервер необходимо отправлять несколько пакетов вместо одного:
Еще можно донести информацию о нужном сервере через опцию prefer:
Ареал использования серверов NTP
Такие серверы есть во всем мире, но обычно синхронизация происходит с NTP-серверами именно того ареала, где физически находится ваш сервер. Таким образом, в файле конфигурации /etc/ntp.conf указывается поддомен ареала (региона) для pool.ntp.org:
Резервный сервер точного времени
NTP-сервер, по какой-либо причине отключенный от интернета, может передавать для синхронизации данные своих системных часов. Для этого в конфигурационный файл нужно добавить следующую строку:
Особые случаи использования NTP
Например, NTP могут использовать, чтобы усилить трафик в DDoS-атаках. А чтобы избежать столкновения с различными злоупотреблениями, следует ограничить доступ для внешних клиентов. Говоря об ограничениях, то по умолчанию в /etc/ntp.conf файле выставлены такие:
Такие опции, как nomodify, notrap, nopeer и noquery, не позволяют внешним клиентам менять конфигурации на сервере. Параметр kod (расшифровывается как kiss of death, «смертельный поцелуй») дает дополнительный уровень защиты: клиент, который часто отправляет запросы, получает сперва kod-пакет, являющийся предупреждением о том, что в обслуживании отказано, а потом отключается от сервера.
Для синхронизации машин из локальной сети с сервером NTP в файл конфигурации добавляется такая строчка:
А для локального хоста устанавливается неограниченный доступ к серверу NTP:
Как проверить синхронизацию
После сохранения всех изменений в файле конфигурации NTP-сервер нужно перезагрузить:
А затем выполнить команду:
На выходе получится таблица, в которой указаны следующие параметры:
Слева от адреса сервера могут быть указаны еще и такие символы:
Как установить локальные дату и время
Чтобы установить локальные дату и время на сервере, нужно использовать команду ntpdate, при этом отправив необходимый запрос к серверу NTP:
Статус ntpd проверяется при помощи команды:
Туннель во времени. Выводим данные с компьютера через Network Time Protocol
Содержание статьи
Пару месяцев назад я гулял по загнивающей Германии, где по каждому удобному и не очень поводу строят туннель. И тут мне пришла идея: а не сделать ли свой туннель? В качестве протокола я выбрал NTP — его использование не требует специальных привилегий, системы защиты не видят в нем никаких проблем, ведь там по определению быть ничего не может, кроме текущего времени, а его формат простой как палка, что позволяет нам использовать его без необходимости закапываться в документацию.
Этот трюк могут использовать и вирусописатели — для вывода данных из зараженных систем, причем незаметно для стандартных средств защиты.
WARNING
Создание и распространение вредоносных программ карается по статье 273 УК РФ. Ни автор, ни редакция «Хакера» не несут ответственности ни за какой вред, принесенный использованием материалов этой статьи.
Что такое NTP
NTP (Network Time Protocol) — протокол, который работает поверх UDP и используется для синхронизации локальных часов с часами на сервере точного времени. При работе в интернете точность синхронизации составляет до 10 мс, а в локальных сетях — до 0,2 мс. При этом NTP нечувствителен к задержкам канала.
Актуальная версия протокола (по данным Википедии) — 4, но мы будем использовать версию 3, которой для наших целей предостаточно.
Для максимальной точности служба обновления времени постоянно должна работать в фоновом режиме, регулярно отправляя запросы на сервер точного времени, то есть генерируя довольно много трафика. Это нам на руку, так как из-за этой особенности IDS давно не обращают внимания на трафик NTP.
За синхронизацию в Windows отвечает служба W32Time, а в Linux — демон ntpd или chronyd. Также существует более простая реализация этого протокола, известная как SNTP (Simple Network Time Protocol) — простой протокол сетевого времени. Применяют его во встраиваемых системах и устройствах, которые не требуют высокой точности, как, например, системы умного дома.
Структура пакета NTP
Структура пакета NTP описана в RFC 958 (v1), 1119 (v2), 1305 (v3) и 5905 (v4). Нас интересует версия 3, как довольно распространенная и простая, хотя ты свободно можешь пользоваться версией 4, она почти не отличается.
Для прожженных программистов на C есть псевдокод:
Теперь немного о назначении этих полей.
В целом процесс крайне прост и понятен, если изучить картинку. Клиент посылает запрос на сервер, запоминая, когда этот запрос был отправлен. Сервер принимает пакет, запоминает и записывает в пакет время приема, заполняет время отправки и отвечает клиенту. Клиент запоминает, когда он получил ответ, и получает нечто вроде RTT (Round-Trip Time, в простонародье — пинг) до сервера. Дальше он определяет, сколько времени понадобилось пакету, чтобы дойти от сервера обратно ему (время между запросом и ответом клиента минус время обработки пакета на сервере, деленное на два).
Чтобы получить текущее время, нужно прибавить полученную задержку канала к времени отправки ответа сервером. Вот только UDP на то и UDP, что задержки могут быть случайные и непредсказуемые, так что замеры повторяются по многу раз в день, вычисляется средняя ошибка, и локальные часы корректируются.
Ограничения на трафик по порту UDP-123
Системы обнаружения вторжений не такие глупые, какими могут показаться, так что просто пустить трафик, например, OpenVPN по 123-му порту UDP мы не сможем, по крайней мере без риска спалиться. Соответствие RFC все же проверяется. Это можно посмотреть на примере Wireshark.
Один из NTP-пакетов, пойманных Wireshark
Концепт
Идея проста: мы составляем собственный «заряженный» пакет NTP и пытаемся синхронизировать время со своим сервером. Чтобы не привлекать лишнего внимания к своей передаче, на каждый запрос должен отправляться внешне валидный ответ, в котором могут быть инструкции для клиента (читай: бота).
Чтобы всякие там системы предотвращения утечек (DLP) не мешали нам, можно, например, поксорить наши данные со статическим ключом. Естественно, в рамках PoC я не буду этого делать, но в качестве простейшего способа сокрытия данных должно сработать.
Реализация
Писать код и дебажить наше творение мы будем в Visual Studio. Я использую версию 2019 Community, благо она бесплатная, а скачать ее можно с сайта Microsoft.
Сервер
Теперь нам нужна структура, описывающая пакет. Обратившись к спецификации NTP, напишем простой класс. В нем также должны быть методы упаковки пакета в массив байтов, пригодный для передачи настоящему серверу и для распаковки пришедшего ответа из массива байтов обратно в пакет.
Весь код, используемый в статье, есть в моем репозитории на GitHub. Он намеренно подпорчен и для промышленного использования не годится, но для демонстрации работы вполне сойдет.
Уже из этого кода видно, что мы будем притворяться сервером Stratum 3. Если бы мы были Stratum 1, то нужно было бы в поле RefID указывать ID атомных часов, которых у нас нет. А список серверов первого уровня общеизвестен, и, если IP нашего псевдосервера не окажется в таких публичных списках, обман быстро будет раскрыт.
Stratum 2 не следует использовать, потому что тогда RefID должен был бы содержать IP сервера первого уровня, список которых опять же известен. А вот третий уровень позволяет указывать в RefID IP сервера второго уровня, полного списка которых нет. То есть мы сможем в RefID передавать еще четыре байта произвольных данных.
Код методов упаковки и распаковки на скриншот не поместился, к тому же нам надо разобрать его отдельно. Вот он:
Тут никаких сложностей: принимаем массив байтов и при помощи BitConverter получаем оттуда данные.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Как сделать недорогую, но надежную систему единого времени на предприятии
Для чего нужно точное время?
Из функций, которые позволяет выполнять сервер времени, можно назвать корректное формирование хронологии событий в системах управления для ведения соответствующих логов, журналов, архивирования информации, построения трендов, графиков и пр.
В системах видеонаблюдения таймсервер обеспечивает привязку отснятых видеозаписей к астрономическому времени. Также устройство позволяет безошибочно сопоставлять информацию от разных информационных систем на предприятии. Например, это могут быть системы видеонаблюдения и системы безопасности, такие как СКУД, системы РЗА и независимые системы телемеханики и пр.
Ряд протоколов информационного обмена используют метки времени напрямую в составе пакетов передаваемых данных. К таким протоколам можно отнести МЭК-101/104, применяемые в современных системах телемеханики.
Одним из важных требований, предъявляемых в ряде промышленных приложений, являются требования информационной безопасности, исключающие выход в Интернет для выполнения функции синхронизации времени.
В силу своей простоты и ряда исторических причин для решения задачи синхронизации времени наибольшее распространение получил протокол NTP. В качестве NTP-клиентов на предприятии, помимо серверов, архивных и операторских станций систем управления, могут выступать контроллеры и HMI-панели, сетевое оборудование систем связи (управляемые коммутаторы, маршрутизаторы и пр).
Протокол NTP
Network time protocol (NTP) — это сетевой протокол для синхронизации часов в компьютерных системах по сетям передачи данных с коммутацией пакетов и переменной задержкой (латентностью). Высокая популярность протокола объясняется активным развитием систем на основе Ethernet. Одним из ключевых преимуществ протокола является возможность передачи меток времени непосредственно по сети передачи данных, что позволяет отказаться от отдельной шины точного времени, как например в системах 1PPS или IRIG–B. Протокол был разработан в 1985 году и является одним из старейших Интернет-протоколов, используемых в настоящее время.
NTP обеспечивает приемлемую точность синхронизации для большинства приложений. Протокол может поддерживать время с точностью до десятков миллисекунд в сети Интернет и до 0,2 мс в локальных сетях при идеальных условиях. Асимметричные маршруты передачи данных и перегрузка сети могут привести к ошибкам в 100 мс и более.
NTP синхронизирует устройства относительно всемирного координированного времени (UTC). При этом протокол учитывает появление високосной секунды в результате неравномерности вращения Земли, но никакой информации о местных часовых поясах или переходе на летнее время не передает.
Структура системы
NTP использует иерархическую систему источников точного времени. Каждый уровень иерархии называется Stratum (стратой, слоем) и ему присваивается номер, начинающийся с 0 для эталонных часов на вершине иерархии. Сервер времени на слое N синхронизируется от серверов на уровне N-1. Число N представляет собой расстояние от эталонных часов и используется для предотвращения цикличности в процессе синхронизации. Stratum не всегда является показателем качества или надежности. Например, можно найти источники времени на слое 3, которые имеют более высокое качество, чем источники времени на слое 2.
В качестве эталонных часов на Stratum 0 выступают системы спутниковой навигации (ГЛОНАСС, GPS и пр.), атомные часы или радиопередатчики. Раз в секунду они генерируют импульсный сигнал (1PPS), который вызывает прерывание и генерирует метку времени на подключенных устройствах. Устройства слоя 0 также известны как опорные часы. Серверы NTP не могут позиционировать себя в системе как Stratum 0. Если в пакете передачи данных в поле Stratum установлен 0, это указывает на неопределенный слой.
Логическая структура системы синхронизации на основе NTP
На этом слое находятся устройства, системное время которых синхронизировано с точностью до нескольких микросекунд от эталонных часов. Серверы времени на этом уровне могут работать в одноранговом режиме с другими серверами Stratum 1 для резервирования и проверки точности. Их также называют первичными серверами времени.
Это устройства, которые синхронизируются по сети от серверов уровня 1. Часто устройства уровня 2 опрашивают несколько серверов уровня 1. Компьютеры Stratum 2 также могут быть одноранговыми с другими компьютерами Stratum 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых узлов.
Максимальное теоретическое число слоев равно 15; Stratum 16 используется для указания того, что устройство не синхронизировано. Механизмы протокола NTP на каждом устройстве системы взаимодействуют таким образом, чтобы построить кратчайший путь к серверам Stratum 1 для всех клиентов. Это позволяет минимизировать накопленную задержку в передаче данных и повысить точность синхронизации. В основе алгоритма построения связующего дерева с минимальной длиной пути лежит алгоритм Беллмана-Форда.
Метки времени
Последняя версия протокола NTPv4 вводит 128-битный формат представления времени: 64 бита для секунд и 64 бита для долей секунды, что дает временную шкалу более 584 млрд лет и разрешение в 0,05 аттосекунд. Дополнительно было введено 32-битное поле номера эры, которое устранило даже ставшей теоретической проблему окончания каждой эпохи.
Алгоритм синхронизации часов
Клиент NTP регулярно опрашивает один или несколько серверов. При этом он вычисляет смещение времени и круговую задержку. Смещение времени θ представляет собой разницу в абсолютном времени между часами сервера и клиента и определяется по формуле:
Круговая задержка δ определяется как время передачи сигнала по линиям связи от клиента к серверу и обратно. Это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен:
где t0 — метка времени клиента для передачи пакета запроса,
t1 — метка времени сервера приема пакета запроса,
t2 — метка времени сервера для передачи ответного пакета,
t3 — метка времени клиента приема ответного пакета.
Алгоритм расчета смещения времени и круговой задержки
Вычисляемые значения θ и δ пропускаются через фильтры и подвергаются статистическому анализу. Выбросы из общей выборки отбрасываются и оценка временного смещения производится на основе оставшихся значений. Зная величины смещения времени и круговую задержку клиент подстраивает собственное время, чтоб добиться θ равного нулю.
Точная синхронизация достигается, когда входящие и исходящие маршруты между клиентом и сервером симметричны, то есть имеют одинаковую задержку. Если маршруты несимметричны, то существует систематическое смещение в половину разницы между временем передачи пакета от клиента к серверу и обратно.
Механизмы передачи
В большинстве случаев протокол NTP использует классическую клиент-серверную модель работы, в которой клиент отправляет запрос и через некоторое время получает ответ от сервера. Однако протокол допускает работу и в одноранговых системах, где два одноранговых узла (peer) рассматривают друг друга как потенциальный источник времени. Этот режим работы также называют симметричным. Для сетевого взаимодействия NTP использует протокол UDP, по умолчанию работая на порту 123. Для передачи данных могут быть использованы различные механизмы – unicast, broadcast, multicast и manycast.
Протокол NTP для передачи данных чаще всего использует режим Unicast. В этом режиме данные передаются от одного устройства сети к другому индивидуально. В Unicast пакетах в качестве IP-адреса назначения используется конкретный адрес устройства, для которого этот пакет предназначен.
Этот режим удобен в тех случаях, когда малое количество NTP-серверов обслуживает большое количество клиентов. В этом режиме сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с ним.
Этот режим имеет ряд особенностей. Во-первых, режим Broadcast обеспечивает меньшую точность синхронизации по сравнению с Unicast. Во-вторых, широковещательные пакеты могут передаваться только в рамках одной подсети. Кроме того, для защиты от злоумышленников желательно использовать методы аутентификации.
Режим Multicast работает аналогично Broadcast. Разница заключается в том, что для доставки пакетов используется не широковещательный адрес подсети, а адрес Multicast-группы. Для клиентов и серверов задается групповой IP-адрес, который они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.
Этот режим является нововведением последней версии (v4) протокола NTP. Режим Manycast функционирует как режим Multicast только с неизвестными IP-адресами серверов NTP. Путем рассылки Multicast-сообщений клиент ищет в сети Manycast-сервера, получает от каждого из них образцы времени и производит выбор трех «лучших», с которыми будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.
Для передачи образцов времени клиенты и серверы, работающие в Manycast-режиме, также используют адреса Multicast-групп. Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых Multicast-адресов.
Версии протокола
С момента своего появления в 1985 года протокол начал активно развиваться и уже к 1992 году сменил четыре версии (от NTPv0 до NTPv3). Каждая новая версия добавляла функционал и оптимизировала его работу, но оставляла неизменным формат данных и сохраняла совместимость различных версий между собой. Последняя четвертая версия протокола датирована 2010 годом. NTP продолжает развитие и в наши дни, ведутся работы по созданию решения, технически схожего с более точным протоколом PTP (Precision Time Protocol).
Одновременно с NTPv3 в 1992 году была представлена более простая версия протокола – SNTP (Simple NTP). В протоколе SNTP используется одинаковый с протоколом NTP формат передачи и представления данных. При этом SNTP не касается алгоритмов работы сервера, а упрощает алгоритмы работы клиентов. Именно поэтому протокол чаще всего используется во встраиваемых системах и устройствах, не требующих высокой точности.
Разница между NTP и SNTP заключается в методах определения оптимальных серверов для синхронизации и методе коррекции времени. Так NTP позволяет клиенту использовать математический алгоритм пересечений (переработанную версию алгоритма Марзулло) для выбора нескольких лучших серверов в сети и плавно корректировать свое время. В SNTP для синхронизации используется один предопределенный NTP сервер, в то время как другие могут являться лишь резервными на случай потери связи с основным устройством. При этом клиент, использующий SNTP, способен корректировать время только скачком по факту получения ответа от сервера.
Типовая схема системы синхронизации и ее недостатки
Традиционно система точного времени на промышленных объектах строится на основе NTP-сервера, состоящего из головного устройства, монтируемого в одном шкафу с сетевым оборудованием, и выносной антенны, которая устанавливается на улице и подключается к серверу при помощи коаксиального кабеля. При этом на головном устройстве имеется несколько сетевых интерфейсов (Ethernet или RS-232/485) для подключения клиентов в одной или нескольких сетях.
Типовая схема системы точного времени
Если посмотреть на это решение более внимательно, то в нем можно выделить несколько недостатков. Во-первых, в такой системе отсутствует полноценное резервирование. Несмотря на то, что головное устройство обладает несколькими сетевыми интерфейсами и способно обеспечивать точное время в нескольких сетях, его сбой или выход из строя приведет к потере источника точного времени на всем объекте. Полное же резервирование головного устройства в подобном решении сделает без того дорогую систему синхронизации еще дороже.
Вторым недостатком можно назвать необходимость установки сервера времени в шкафу. Для больших проектов это не является минусом, но для небольших локальных систем управления это может стать серьезной проблемой.
Также к недостаткам можно отнести необходимость применения выносной антенны и коаксиального кабеля. Почему? Прежде всего, стоимость качественной GPS/ГЛОНАСС антенны с длинным кабелем и защитой от грызунов легко может перевалить за 10 000 руб. в ценах 2020 года. При этом коаксиальные кабели имеют ограниченную длину для передачи сигналов спутниковых систем. При длине более 50 м сигнал будет значительно затухать, что является серьезным ограничивающим фактором в больших зданиях.
Главным же недостатком традиционного подхода в создании систем синхронизации является его высокая стоимость (часто более 150 000 рублей), что существенно сказывается на смете не только небольших проектов, но и вполне крупных.
Как сделать систему дешевле и надежнее
Безусловным трендом современных технологий является создание более компактных и простых для пользователя электронных устройств. В этом плане сервера точного времени не являются исключением.
Всё решение, связанное с системой синхронизации, включая GPS/ГЛОНАСС антенну, может уместиться в небольшую коробочку, как это сделано в
FL TIMESERVER от Phoenix Contact. Устройство выполнено по принципу smart-антенны, то есть совмещает в себе непосредственно функционал сервера времени и антенну GPS/ГЛОНАСС приемника. Конструктивное исполнение – это единственное, что отличает его от привычных решений.
Сервер времени FL TIMESERVER NTP
В плане функционала никаких отличий нет: устройство способно принимать метки времени и данные геолокации от спутниковых систем навигации (ГЛОНАСС, GPS) и транслировать эту информацию для клиентов в сети Ethernet.
Система точного времени на основе решения Phoenix Contact
При использовании подобного решения система синхронизации значительно упрощается и позволяет избавиться от недостатков традиционного подхода. FL TIMESERVER имеет только один порт Ethernet, но при необходимости использовать несколько интерфейсов достаточно подключить его в коммутатор или же использовать несколько smart-антенн. В этом случае мы получим полноценное резервирование серверов времени, а не только его сетевого интерфейса. При этом конечное решение все равно окажется дешевле многих существующих аналогов. FL TIMESERVER можно вынести за пределы сетевого шкафа или шкафа автоматизации, сэкономив место внутри. В этом решении не требуется отдельная антенна, здесь она уже встроена и к сети предприятия мы можем подключаться обычным Ethernet кабелем. В свою очередь это позволяет вынести сервер времени на расстояние до 100 м от основного оборудования без опасения, что сигнал затухнет. Самым главным преимуществом подобного решения является совсем другой порядок цен. Стоимость одного сервера времени менее 300 евро, что делает его удобным в применении как в небольших, так и в крупных проектах.