Протокол ntp описание. NTP – атомные часы на каждом столе
NTP (Network Time Protocol - протокол сетевого времени) - сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью. Протокол был разработан Дэвидом Л. Миллсом, профессором Делавэрского университета, в 1985 году. Версия на 2015 год - NTPv4.
NTP, основанный на алгоритме Марзулло, использует для своей работы протокол UDP и учитывает время передачи. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет, и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей.
Наиболее широкое применение протокол NTP находит для синхронизации серверов точного времени. Для достижения максимальной точности предпочтительна постоянная работа программного обеспечения NTP в режиме системной службы. В семействе операционных систем Microsoft Windows - это служба W32Time, Linux - сервис Ntpd.
Более простая реализация этого алгоритма известна как SNTP - простой протокол сетевого времени. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени.
Структура пакета
Структура пакета описана в RFC 5905. Пакет состоит из целого числа 32-битных слов.
Данные в заголовке будут отличаться для различных режимов работы. Например, клиент в поля часовой слой , идентификатор источника , начальное время и время приёма должен записать нули.
Заголовок
| Отступ | Октет | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Октет | Бит | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | ИК | Версия | Режим | Часовой слой | Интервал опроса | Точность | ||||||||||||||||||||||||||
| 4 | 32 | Задержка | |||||||||||||||||||||||||||||||
| 8 | 64 | Дисперсия | |||||||||||||||||||||||||||||||
| 12 | 96 | Идентификатор источника | |||||||||||||||||||||||||||||||
| 16 | 128 | Время обновления | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| 24 | 192 | Начальное время | |||||||||||||||||||||||||||||||
| 28 | 224 | ||||||||||||||||||||||||||||||||
| 32 | 256 | Время приёма | |||||||||||||||||||||||||||||||
| 36 | 288 | ||||||||||||||||||||||||||||||||
| 40 | 320 | Время отправки | |||||||||||||||||||||||||||||||
| 44 | 352 | ||||||||||||||||||||||||||||||||
Индикатор коррекции
Пример синхронизации времени, используя NTP
Длина - 2 бита, от Leap Indicator. Целое число, показывающее предупреждение о секунде координации.
Номер версии
Длина - 3 бита, от Version Number. Целое число, представляющее версию протокола.Режим
Длина - 3 бита, от Mode. Целое число, представляющее режим. Значения представлены в таблице ниже.Часовой слой
Длина - 8 бит, от Stratum. Целое число, представляющее часовой слой.Интервал опроса
Длина - 8 бит, от Poll. Целое число со знаком, представляющее максимальный интервал между последовательными сообщениями. Значение равно двоичному логарифму секунд. Предлагаемые по умолчанию пределы на минимальные и максимальные опросы - 6 и 10, соответственно.Точность
Длина - 8 бит, от Precision. Целое число со знаком, представляющее точность системных часов. Значение равно двоичному логарифму секунд. Например, значению -18 будет соответствовать точность около 1 мкс.Задержка
Длина - 32 бита, от Root Delay. Общее время распространения сигнала в обе стороны в коротком формате NTP.Дисперсия
Длина - 32 бита, от Root Dispersion. Общая дисперсия для источника времени в коротком формате NTP.Идентификатор источника
Длина - 32 бита, от Reference ID. Код источника синхронизации. Зависит от значения в поле Часовой слой. Для слоя 0 - это четыре ASCII символа, называемые «kiss code», используются для отладки и мониторинга. Смотри ниже Для слоя 1 - это четыре октета ASCII символов, дополненные слева нулями, назначенные для опорного времени. В таблице ниже представлен список, поддерживаемый IANA.| ID | Источник |
|---|---|
| GOES | Геостационарный спутник системы экологического мониторинга и наблюдения |
| GPS | Система глобального позиционирования |
| GAL | Система местоопределения «Галилео» |
| PPS | Общий радиосигнал с длительностью импульса, равной 1 секунде |
| IRIG | Группа стандартизации в телеметрии, США |
| WWVB | Низкочастотный радиопередатчик, 60 кГц, Форт Коллинз, Колорадо, США |
| DCF | Низкочастотный радиопередатчик, 77.5 кГц, DCF77, Майнфлинген, ФРГ |
| HBG | Низкочастотный радиопередатчик, 75 кГц, Прангинс, Швейцария |
| MSF | Низкочастотный радиопередатчик, 60 кГц, Антхорн, Великобритания |
| JJY | Низкочастотный радиопередатчик, 40 кГц, Фукушима, 60 кГц, Сага, Япония |
| LORC | Среднечастотный радиопередатчик, 100 кГц, радионавигация, LORAN-C |
| TDF | Среднечастотный радиопередатчик, 162 кГц, Аллоуис, Франция |
| CHU | Высокочастотный радиопередатчик, Оттава, Онтарио, Канада |
| WWV | Высокочастотный радиопередатчик, Форт Коллинз, Колорадо, США |
| WWVH | Высокочастотный радиопередатчик, Кауаи, Гавайи, США |
| NIST | |
| ACTS | Телефонный модем Национального института стандартов и технологий США |
| USNO | Телефонный модем Национальной обсерватории США |
| PTB | Телефонный модем Национального метрологического института Германии |
Время обновления
Длина - 64 бита, от Reference Timestamp. Время, когда система последний раз устанавливала или корректировала время. Формат NTP.Начальное время
Длина - 64 бита, от Origin Timestamp. Время клиента, когда запрос отправляется серверу. Формат NTP.Время приёма
Длина - 64 бита, от Receive Timestamp. Время сервера, когда запрос приходит от клиента. Формат NTP.Время отправки
Длина - 64 бита, от Transmit Timestamp. Время сервера, когда запрос отправляется клиенту. Формат NTP.NTP-сообщение «Kiss-o"-Death»
Для слоя 0 , который считается неопределённым или недопустимым, поле Идентификатор источника может использоваться для доставки сообщений, которые выполняют роль данных о состоянии системы и управления доступом. Такие сообщения называются «Kiss-o"-Death» (KoD), а доставляемые ими ASCII-данные называются «kiss codes» (коды «помощи»). Перечень принятых в настоящее время кодов «помощи» представлен в таблице ниже.
Получатели KoD-сообщений обязаны их проверить и выполнить следующие действия:
- При получении кодовых комбинаций DENY и RSTR клиент обязан разорвать виртуальные соединения с данным сервером времени и прекратить передачу сообщений этому серверу.
- При получении кодовой комбинации RATE клиент обязан незамедлительно снизить свой интервал опроса этого сервера и продолжать его уменьшать каждый раз при получении этой кодовой комбинации.
- При получении кодовой комбинации начинающейся с ASCII-символа Х , предназначенной для проведения экспериментальных исследований и последующих усовершенствований, она должна быть проигнорирована, если она не распознаётся.
- Все другие кодовые комбинации и KoD-сообщения, не определённые данным протоколом, уничтожаются после их поверки.
| Код | Описание |
|---|---|
| ACST | Виртуальное соединение установлено одноадресным сервером |
| AUTH | Аутентификация сервером завершилась отказом |
| AUTO | Autokey-последовательность некорректна |
| BCST | Виртуальное соединение установлено широковещательным сервером |
| CRYP | Криптографическая аутентификация или идентификация завершились отказом |
| DENY | Удалённый сервер отказал в доступе |
| DROP | Потеря удаленного сервера времени в симметричном режиме |
| RSTR | Отказ в доступе вследствие локальной стратегии безопасности |
| INIT | Виртуальное соединение с первого раза не установлено |
| MCST | Виртуальное синхросоединение установлено динамически обнаруженным сервером |
| NKEY | Ключ не найден (либо он никогда ранее не загружался, либо он является ненадёжным) |
| RATE | Скорость превышена. Сервер временно запретил доступ, так как клиент превысил порог скорости |
| RMOT | Изменение виртуального соединения со стороны удалённого IP-узла, использующего NTP-протокол напрямую |
| STEP | Произошла итерация по изменению системного времени, виртуальное синхросоединение не установлено |
Часовые слои
Жёлтые стрелки обозначают аппаратное соединение; красные стрелки обозначают сетевое соединение.
NTP использует иерархическую сеть, где каждый уровень имеет свой номер, называемый слой. Слой 1 - первичные серверы, непосредственно синхронизирующиеся с национальными службами времени через спутник, радио или телефонный модем. Слой 2 - вторичные серверы, синхронизируются с первичными серверами, и т.д. Как правило, клиенты и серверы NTP с относительно небольшим числом клиентов не синхронизируется с первичными серверами. Существует несколько сотен общественных вторичных серверов, работающих на более высоких слоях. Они являются предпочтительным выбором.
Формат времени
Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 −32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учётом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.
| Бит | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Секунды | |||||||||||||||||||||||||||||||
| 4 | Доли секунд | |||||||||||||||||||||||||||||||
| Бит | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Номер эры | |||||||||||||||||||||||||||||||
| 4 | Отступ эры | |||||||||||||||||||||||||||||||
| 8 | Доли | |||||||||||||||||||||||||||||||
| 16 | ||||||||||||||||||||||||||||||||
MSK-IX NTP Server - публичный сервер точного времени, поддерживаемый MSK-IX. Сервер точного времени предназначен для синхронизации с эталонным источником внутренних часов компьютеров и сетевого оборудования (серверов, маршрутизаторов, смартфонов и др.) по протоколу NTP .
MSK-IX NTP server относится к высшему уровню точности (Stratum One Time Servers) в иерархической системе часовых уровней. В качестве эталонного сигнала времени используется сигнал глобальных спутниковых систем навигации ГЛОНАСС (приоритетно) и GPS.
MSK-IX NTP Server реализован в виде группировки серверов, размещенных в Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске. Применение сетевой технологии anycast обеспечивает высокую надежность и быстрый отклик системы на всей территории страны.
Серверы MSK-IX также включены в международный пул NTP-серверов POOL.NTP.ORG, широко используемый в настройках операционных систем.
Как начать пользоваться службой NTP Server?
Используйте следующие параметры при конфигурации оборудования:
| Имя сервера | ntp.msk-ix.ru |
| IPv4-адрес | 194.190.168.1 |
| IPv6-адрес | 2001:6d0:ffd4::1 |
Как установить пиринг с сетью NTP-сервера MSK-IX?
Для сокращения сетевого маршрута до NTP-сервера MSK-IX используйте службу Route Server или установите прямой пиринг с сетью MSK-IX DNS Cloud . Пиринговое взаимодействие устанавливается по дополнительной заявке в рамках договора на подключение к MSK-IX без дополнительной оплаты.
Ответы на вопросы
26.09.2018Сложно представить современный мир без точного времени. Во многих сферах жизни нужно иметь очень точные часы, при этом точность часто должна быть гораздо выше точности часов, применяющихся людьми в обычной жизни. Например, требования к точности часов авиационных диспетчерских, комплексов, управляющих космическими аппаратами, или военных систем находятся на высочайшем уровне. Также часы с высокой точностью необходимы и в системах с более простыми функциями – в системах биллинга и тарификации сотовых операторов и интернет-провайдеров, в системах банковских транзакций, в биржевых системах, в производственных и научных комплексах. В локальных сетях протокол аутентификации пользователей Kerberos также использует сравнение времени контроллера домена с часами пользовательских рабочих станций. В компьютерных сетях синхронизация обычно выполняется с серверами точного времени при помощи протокола NTP или его «облегчённой» разновидности – SNTP . В этой статье мы рассмотрим особенности, отличия и примеры применения этих протоколов.
NTP (англ. Network Time Protocol – протокол сетевого времени) – сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной пропускной способностью. Обеспечивает высокую точность синхронизации времени благодаря специальному алгоритму, который позволяет выбирать наиболее точные источники для оценки точного времени. Этот алгоритм позволяет сводить к минимуму влияние данных от заведомо некорректно настроенных NTP-серверов на общую систему. Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд, и содержит средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию. Протокол NTP использует иерархическую систему уровней, или стратумов. Сервер NTP имеет наиболее высокий уровень (стратум 1), если он получает данные непосредственно от источника точного времени. Сервера, синхронизирующие свои часы с сервером 1-го стратума, находятся на уровне ниже (стратум 2), и т. д.
SNTP (англ. Simple Network Time Protocol – простой протокол сетевого времени) – протокол синхронизации времени по компьютерной сети. Представляет собой упрощённую реализацию протокола NTP, в нём отсутствует сложность алгоритма NTP. SNTP используется для узлов сети, которым не требуется полный набор функций NTP. Общепринятой практикой является синхронизация часов нескольких узлов локальной сети с другими узлами NTP по Интернет и использование этих узлов для временной синхронизации услуг, предоставляемых другим клиентам по локальной сети. В таком варианте использования не требуется высокой точности временной синхронизации. Протокол SNTP обеспечивает механизмы синхронизации с точностью от 1 до 50 мс
Пример использования протокола NTP: банк N предоставляет своим клиентам клиент-серверное приложение для биржевой торговли. Сервера, которые обрабатывают информацию о биржевых котировках, должны иметь часы с высокой точностью синхронизации со шкалой всемирного времени. В таком случае, каждый сервер биржевой торговли банка N синхронизируется с самым точным из серверов точного времени («стратум 1»), который получает данные непосредственно от источника точного времени. Самый точный сервер выбирается по алгоритму, встроенному в протокол NTP. Примерная архитектура такого решения отражена на схеме ниже:
Классический пример использования SNTP – синхронизация времени внутри домена. Контроллер домена получает время из глобальной сети Интернет от общедоступных серверов стратума 1 или стратума 2. Остальные клиенты домена синхронизируют свои часы со временем на контроллере домена. Примерная архитектура отображена на схеме.
Сначала определимся, для чего нам синхронизировать время на оборудовании, таком как: коммутаторы, маршрутизаторы, файрволлы, и так далее.
Делается это в первую очередь для того, чтоб отследить по логам когда произошло то или иное событие. И вы можете себе представить, какая польза будет от логов, если время не синхронизированное.. правильно — никакой.
Протокол NTP работает на основе протокола UDP , через 123 порт.
У данного протокола есть некоторая иерархия для синхронизирующих систем, иными словами уровни.
Уровень 1 присваивается системе, которая синхронизируется с высокоточными часами, например через GPS.
Система, которая будет синхронизировать с Уровня 1, будет иметь Уровень 2, и так далее.
Тем самым мы можем определить насколько точным временем обладает станция, с которой мы синхронизируемся.
В нашей ситуации у нас в сети есть машина с точным временем, у меня она настроена на основе FreeBSD, с этой машины, главное сетевое устройство будет брать время (синхронизировать), и тем самым будет становиться главным для других сетевых устройств (в идеологии cisco будет ntp мастером).
Хочу отметить тот факт, что по NTP передается время только в формате UTC (Гринвич) , каждая тайм зона настраивается не посредственно на железке.
Давайте рассмотрим пример простой настройки NTP.
Для начала синхронизируем время на нашем главном роутере (который будет раздавать другим сетевым устройствам).Для этого заходим в режиме глобальной конфигурации:
ntp server 10.0.100.254
где, 10.0.100.254 в нашем случае это машина с FreeBSD, имеющая точное время.
Этого достаточно для минимальной настройки.
Теперь проверим, смогли ли мы подключиться к серверу времени и получить с него время, для этого используем команду:
должны увидеть нечто подобное:
Звездочка напротив ip нашего ntp сервера, говорит нам, что все хорошо, связь по крайней мере установлена.
Теперь посмотрим, синхронизировалось ли время?
Если все синхронизировалось, то мы должны увидеть следующее:
Время получено, теперь необходимо установить нужную там тайм зону.Так же в режиме глобальной конфигурации делаем:
clock timezone MSK/MSD 3Теперь давайте проверим время:
Все замечательно.
Перейдем к настройке нашего роутера в режим мастера.
Для этой настройки, нам необходимо что данный роутер мастер и указать уровень (в cisco он зовется как stratum number), тот самый, о котором я говорил в начале, я укажу уровень пятый.
Теперь попробуем настроить на другом сеттером устройстве ntp, чтоб оно синхронизировалось с нашего основного роутера, делается это так же как и здесь выше настраивали синхронизацию с FreeBSD сервера.
ntp server 10.0.100.1 prefer
где, 10.0.100.1 это наш головной роутер.
prefer это ключевое слово, которое указывает что данный ntp сервер является приоритетным (тоесть можно прописать, что синхронизировать можно не с одного сервера, а с нескольких, делается это для того, что если один недоступен, или время слишком отличается от других, что говорит о каких-то проблемах, устройство может переключиться на другой сервер времени, а prefer делает этот сервер более предпочтительным, нежели другие.)
так же мы указываем нужную нам таймзону.
clock timezone MSK/MSD 3
Проверяем:
Все замечательно, все работает.
Теперь рассмотрим вопрос безопасности.
Для начала, разберем вопрос по ограничению с помощью ACL, кто может синхронизировать, а кто нет.
Все достаточно стандартно и прозрачно.
На сервере времени создаем соответствующий ACL:
access-list 20 remark ACCESS to NTP Sync access-list 20 permit 10.0.100.3
теперь привяжем этот список доступа к ntp.
ntp access-group serve-only 20
Если все настроено верно, то связь с ntp севером установится и синхронизация пройдет успешно.
Так же дополнительно можно прописать на клиентах список доступа. К каким серверам времени можно обращаться. Делается это похожим способом:
access-list 20 remark ACCESS SYNC to NTP Serv access-list 20 permit 10.0.100.1
Привяжем список доступа к NTP
ntp access-group peer 20
Теперь рассмотрим безопасность на основе аутентификации.
Все также достаточно прозрачно.
В конфигурацию ntp достаточно добавить следующее:
ntp authentication-key 1 md5 15060E1F10243F34 7 ntp authenticate ntp trusted-key 1первой командой мы задаем ключ аутентификации, второй включаем аутентификацию, а третей указываем что аутентификацию проводить по первому ключу.Настраиваем это на каждой из сторон (сервер — клиент).Вот собственно и все. Получилась небольшой вводный курс по настройке NTP на Cisco устройствах.Для отладки используем:
ASW-M#debug ntp ? adjust NTP clock adjustments authentication NTP authentication events NTP events loopfilter NTP loop filter packets NTP packets params NTP clock parameters refclock NTP reference clocks select NTP clock selection sync NTP clock synchronization validity NTP peer clock validity ASW-M#debug ntpВключаем все что нам интересно, например events, sync, auth и смотрим что происходит.Если мы зашли на устройство через ssh/telnet не забываем ter mon 🙂
Синхронизация времени является важной задачей, хотя не многие задумывались об этом. Ну что плохого в убежавшем на сервере времени? А знаете ли вы, что многие проблемы с часами влияют на протоколы, связанные с криптографией? По этой причине в Active Directory разница в часах более 5 минут будет приводить к проблемам аутентификации Kerberos.
Часовые уровни. Strata.
Чтобы понять устройство NTP следует знать про концепцию strata или stratum . Авторитетные источники времени, такие как спутники GPS, цезиевые атомные часы, радио волны WWVB - всё это stratum 0 . Они авторитетны на том основании, что у них есть некоторый способ поддержания высокоточного хронометража. Можно, конечно, воспользоваться обычными кварцевыми часами, но зная, что за месяц с ними легко потерять 15 секунд, то лучше их не использовать в качестве мерила времени. Stratum 0 это когда секунда не потеряется за 300 000 лет!
Компьютеры, которые напрямую (не по сети!) берут время у stratum 0 - это stratum 1 . Так как всегда есть задержки из-за передачи сигнала и затраты на установку времени, то компьютеры stratum 1 не так точны как stratum 0 , но в реальной жизни различие достигает пару микросекунд (1 мкс = 10 -6 с), что вполне допустимое отклонение.
Следующий уровень компьютеров, берущих время по сети у stratum 1 - это... барабанная дробь... интрига... stratum 2 ! Опять таки из-за различных задержек (сетевые точно), stratum 2 чуток отстаёт от stratum 1 и уж точно от stratum 0 . На практике это разница от нескольких микросекунд (1 мкс = 10 -6 с) до нескольких миллисекунд (1 мс = 10 -3 с). Многие хотят синхронизироваться со слоем не дальше stratum 2 .
Как понятно из схемы, stratum 4 берёт время у вышестоящего stratum 3 . stratum 5 у stratum 4 и так далее. stratum 16 считается самым нижним слоем и время там считается несинхронизированным .
Чтобы синхронизировать время с помощью протокола NTP, следует сначала вручную выставить ваше время. Недопустима разница между вашим точным временем и показаниями ваших часов более 1000 секунд. Если используемый вами сервер времени врёт более 1000 миллисекунд (1 секунда), то он будет исключён из списка и будут использоваться другие вместо него. Данный механизм позволяет отсеивать плохие источники времени.
Клиент времени.
В файле /etc/ntp.conf для клиента важны строки Server. Их может быть несколько - до 10 штук!
Сколько добавлять? Следует иметь в виду:
- Если у вас только один сервер (одна строка server), то если данный сервер начнёт врать, то вы будете слепо следовать за ним. Если его время убежит на 5 секунд и вы убежите в след за ним.
- Если добавлено 2 сервера (2 строки server), то NTP пометит их обоих как false tickers . Если один из них будет врать, то NTP не может понять кто врёт, так как нет кворума.
- Если добавлено 3 и более сервера времени, то можно вычислить одного вруна false tickers . Если серверов времени 5 или 6, то можно найти 2 вруна false tickers . Если серверов 7 или 8, то 3 false tickers . Если серверов 9 и 10, то 4 false tickers .
Проект NTP Pool.
Есть такой проект NTP Pool по адресу которого pool.ntp.org/zone/ru/ можно найти рекомендованные для русских пользователей сервера времени.
server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org
Такие операционные системы, как Debian и Ubuntu, предлагают пользователям свои сервера времени.
server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server 3.debian.pool.ntp.org
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org
Если вызвать на вашем Linux компьютере, который использует NTP, команду ntpq -pn
Remote refid st t when poll reach delay offset jitter ============================================================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53.658 -0.877 1.174 +85.21.78.23 193.190.230.65 2 u 1027 1024 377 54.651 0.167 1.531 *62.173.138.130 89.109.251.24 2 u 940 1024 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482
О чём говорят названия столбцов:
- remote - удалённые сервера, с которыми вы синхронизируете время.
- refid - вышестоящий stratum для данного сервера.
- st - уровень stratum. От 0 (нам недоступно) до 16 (нам не желательно). Идеально - 2.
- t - тип соединения. "u " - unicast или manycast, "b " - broadcast или multicast, "l " local reference clock, "s " - симметричный узел, "A " - manycast сервер, "B " - broadcast server, "M " - multicast сервер.
- when - время, когда последний раз сервер ответил нам. Параметр отображает число в секундах, но может в минутах, если число с m или в часах, если h .
- poll - частота опроса. Минимум 16 секунд, максимум 32 часа. Число должно быть 2 n . Обычно в данном параметре наблюдается или 64 секунды или 1024.
- reach - 8 бит октета, показывающий статус общения с удалённым сервером времени: успешный или сбойный. Если биты установлены - то успешно, иначе - сбой. Значение 377 - бинарно это 0000 0000 1111 1111.
- delay - значение в миллисекундах показывает время между отправкой и получения ответа (round trip time - RTT).
- offset - смещение в миллисекундах между вами и серверами времени. Может быть положительным и отрицательным числом.
- jitter - абсолютное значение в миллисекундах с указанием среднеквадратичного отклонения вашего смещения.
Перед IP адресом NTP сервера есть символ - это tally code . Виды tally code :
- " " - отброшен как недопустимый. Например, нет связи с ним или он в оффлайн, он слишком высокого ранга и не обслуживает таких как вы.
- "x" - отброшен алгоритмом "пересечения" (intersection algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них.
- "." - отброшен из-за переполнения таблицы.
- "-" - отброшен алгоритмом кластеризации (cluster algorithm). Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния синхронизации.
- "+" - сервер включён алгоритмом "комбинирования" (combine algorithm). Этот сервер - отличный кандидат если текущий сервер времени начнёт отказывать вам.
- "#" - сервер является отличным альтернативным сервером времени. Сервер с # можно увидеть только если у вас более 10 записей server в /etc/ntp.conf
- "*" - текущий сервер времени. Его показания используются для синхронизации ваших часов.
- "o" - сервер Pulse per second (PPS). Обычно это означает, что данный сервер времени использует источники времени типа GPS спутников и другие сигналы точного времени. Если рисуется о , то другие типы tally code уже отображаться не будут.
В поле refid могут быть следующие значения:
- IP адрес - адрес удалённого сервера времени.
- .ACST.- NTP manycast сервер.
- .ACTS.- Automated Computer Time Service из American National Institute of Standards and Technology.
- .AUTH.- ошибка аутентификации.
- .AUTO.- ошибка в последовательностях Autokey.
- .BCST.- NTP broadcast сервер.
- .CHU.- Shortwave radio receiver от станции CHU в Ottawa, Ontario, Canada.
- .CRYPT.- ошибка протокола Autokey.
- .DCFx.- LF radio receiver от станции DCF77 в Mainflingen, Germany.
- .DENY.- В доступе отказано.
- .GAL.- European Galileo satellite receiver.
- .GOES.- American Geostationary Operational Environmental Satellite receiver.
- .GPS.- American Global Positioning System receiver.
- .HBG.- LF radio receiver от станции HBG в Prangins, Switzerland.
- .INIT.- Peer association initialized.
- .IRIG.- Inter Range Instrumentation Group time code.
- .JJY.- LF radio receiver от станции JJY в Mount Otakadoya, рядом с Fukushima или Mount Hagane на острове Kyushu, Japan.
- .LFx.- Обычный LF radio receiver.
- .LOCL.- локальные часы хоста.
- .LORC.- LF radio receiver от Long Range Navigation (LORAN-C).
- .MCST.- NTP multicast сервер.
- .MSF.- Anthorn Radio Station рядом с Anthorn, Cumbria.
- .NIST.- American National Institute of Standards and Technology.
- .PPS.- часы Pulse per second.
- .PTB.- Physikalisch-Technische Bundesanstalt от Brunswick и Berlin, Germany.
- .RATE.- превышен порог опроса NTP.
- .STEP.- изменение шага NTP. Смещение offset менее 1000 миллисекунд, но более 125 миллисекунд.
- .TDF.- LF radio receiver от станции TéléDiffusion de France в Allouis, France.
- .TIME.- NTP association timeout.
- .USNO.- United States Naval Observatory.
- .WWV.- HF radio receiver от станции WWV в Fort Collins, Colorado, United States.
- .WWVB.- LF radio receiver от станции WWVB в Fort Collins, Colorado, United States.
- .WWVH.- HF radio receiver от станции WWVH в Kekaha, на острове Kauai на Hawaii, United States.
Во-первых, избавьтесь от мысли как бы получить время от stratum 1 , дескать они ближе всех к точному времени. Они то ближе к точнейшему времени на планете, только сами они перегружены и у них высокие задержки RTT для обычных серверов. Лучше найти нормальный stratum 2 и не переживать по этому поводу. Не забывайте, что речь идёт о микросекундах и миллисекундах, что в обычной жизни - вполне достаточно.
Во-вторых, помните, что подключение к ближайшему серверу времени не всегда идеальный вариант. Важнее не территориальная близость, а уровень stratum. Проект NTP Pool публикует список серверов только уровня stratum 1 и stratum 2 и лучше взять до 10 серверов времени из данного списка, что будет просто замечательно.
В-третьих, если вы простой домашний пользователь-клиент, то рекомендованные вам сервера в вашей операционной системе будут идеальным вариантом, не требующим лишних телодвижений.
Для крупных контор, лучшим вариантом будет поднятие своего сервера времени для рабочих компьютеров. Данный сервер будет получать точное время от серверов времени в Интернете и предоставлять его локальным компьютерам. На серверах Debian и Ubuntu достаточно раскомментировать строку
Restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap
в конфигурационном файле демона ntpd - /etc/ntp.conf
Пользователи из сети 192.168/16 будут иметь возможность брать с вашего сервера показания точнейших часов. Для внутренних серверов на базе Linux, которые не являются серверами времени и занимаются своими задачами, вместо запуска демона ntpd в клиентском режиме - вполне достаточно указать в файле /etc/cron.daily/syncntpd. Рекомендуется прочесть различия между ntpdate и ntp и решить для себя вопрос.
#!/bin/sh
/usr/sbin/ntpdate IP.адрес.вашего.сервера > /dev/null 2>&1
exit 0
и раз в сутки, благодаря команде ntpdate, будет произведена синхронизация времени. Во избежании недоразумений, не поленитесь перед внедрением сервера времени и синхронизации всего и вся через протокол NTP - выставите вручную правильное время на всех доступных вам серверах и рабочих станциях. Если ваше несинхронизированное время слишком отличается от правильного, то можно вначале огрести много не нужных проблем.
В-четвёртых, NTP никак не связан, в какой стране и какие часовые пояса используются и как происходит переход на летнее и зимнее время и делается ли в данной стране такой переход. Это обязанность лежит на операционной системе, которую вам нужно обновлять, если в стране происходят изменения в часовых делах. В системах Debian и Ubuntu за это отвечает пакет tzdata, который должен быть актуальным.
В-пятых, лучше не поднимать свой NTP сервер на высоконагруженной системе.