В статье описывается высокоточный протокол синхронизации времени NTP
(Network Time Protocol),
его реализация в Unix (Linux) и Cisco,
приводятся ссылки на списки публичных NTP серверов,
которые можно использовать для синхронизации.
Назначение протокола состоит в синхронизации клиента или
сервера с сервером или источником точного времени
(радио, атомные часы или еще что). Стандартизована (Draft Standard)
версия 3 протокола NTP (RFC-1305), но текущая
реализация поддерживает как 3-ю, так и 4-ю версии.
Синхронизируется не только текущее
значение времени, но и частота отсчета таймера. Обеспечивает точность до
милисекунды в пределах LAN и десятков милисекунд посредством WAN. Предусмотрена
криптографическая защита (шифрование контрольной суммы), одновременное
подключение к нескольким серверам на случай аварии, алгоритмы усреднения и т.д.
Поддерживает самонастраиваемую иерархическую архитектуру сети синхронизации
(симметричный механизм обмена пакетами). Главные сервера (напрямую
присоединенные к источнику точного времени) образуют первый слой (stratum),
присоединенные непосредственно к ним - второй слой, и т.д.
Для обмена информацией между используется протокол UDP (порт 123).
Используется довольно сложные алгоритмы фильтрации, селекции и
комбинации пакетов на принципах максимальной вероятности. Протокол
обеспечивает поддержку множества
резервных серверов и путей передачи (выбор лучшего на основе алгоритма
взвешенного голосования). Достигаемая точность первичного сервера -
милисекунды. Типичный интервал опроса - от 1
минуты (в начале работы) до 17 минут (если все хорошо).
Сервер непрерывно корректирует ход локальных часов, используя вычисленную
информацию об отклонениях их частоты от истинной. Это позволяет уменьшить
частоту опроса и удерживать отклонения показаний часов от истинных при
временных сбоях сети. Подстройка частоты обеспечивает приличную точность
часов даже при модемном соединении с Интернет.
При больших отклонениях (более 128 мс) местного
времени от времени выбранного сервера коррекция производится скачком,
иначе путем подстройки частоты местных часов.
В качестве значения времени используется беззнаковое 64-битовое число с
фиксированной точкой, число секунд в UTC.
Первые 32 бита - число секунд, вторые 32 бита - дробная часть. Точность 232
пикосекунды. Старший бит взведен где-то в 1968 году,
переполнение наступит в 2036 году. 0 означает неопределенное время.
Возможные классы обслуживания:
multicast: для использования в быстрой локальной сети с
множеством клиентов и без необходимости в высокой точности, один или более
NTP-серверов рассылают broadcast, клиенты определяют время исходя из
предположения, что задержка составляет несколько милисекунд; сервер не
принимает ответных NTP сообщений
procedure-call: в условиях когда нужна высокая точность, а multicast
недоступен; NTP-клиент посылает NTP-запрос на сервер, который
обрабатывает его и немедленно посылает ответ; сервер не
синхронизируется с клиентом
symmetric: динамически реконфигурируемая иерархия серверов, каждый сервер
синхронизирует и синхронизируется своими соседями в
соответствии с правилами выбора соседей; активный режим
используется серверами низшего уровня (большой номер страта) с
преконфигурированными адресами соседей, пассивный режим
используется серверами близкими к корню и
взаимодействующими с соседями с заранее
неизвестными адресами; для каждой пары серверов, обменивающися
сообщениями, создается ассоциация.
Типичная конфигурация в небольшой организации включает 3 местных сервера,
каждый из которых подключен к трем внешним серверам
(9 различных внешних серверов!), местные сервера соединены между собой.
Не рекомендуется соединять между собой более 10 серверов.
Клиенты подключены к каждому из трех местных серверов.
При описании алгоритма используются следующие термины
стабильность
способность удерживать постоянную частоту
точность (аккуратность?)
совпадение с национальным стандартом
разрешение
точность измерения
смещение часов
разница во времени между ними
skew (расхождение?)
разница в частоте между ними
надежность
доля времени, в которое часы доступны
синхронизация часов
синхронизация частоты и времени
первичный (primary) источник
синхронизированный с национальным стандартом (провод, радио,
атомные часы)
Формат NTP-пакета:
LI (leap indicator) - в конце суток должна быть вставлена секунда для
синхронизации атомных (TAI) и астрономических часов (GMT)
VN - номер версии (3 или 4)
mode - режим работы
stratum - слой
precision - разрешение местных часов (log2)
poll interval - интервал запросов (используется минимальный из своего и
соседского, log2)
synchronization distance - полный цикл обмена
сообщениями (roundtrip delay) до первичного источника
synchronization dispersion - дисперсия этих задержек
reference clock identifier - тип опорных часов
reference timestamp - время последнего изменения опорных часов
(используется для управления)
originate timestamp - время соседа, когда последнее NTP-сообщение было
отправлено (копировано по прибытии из transmit timestamp)
receive timestamp - местное время получения этого последнего NTP-сообщения
transmit timestamp - местное время отправки текущего сообщения
authenticator (96 bit) - опция - ключ и шифрованная контрольная сумма
сообщения
Хотя для обмена информацией используется протокол UDP
(connectionless), сервера хранят информацию о соседях в переменных
состояния:
32-битные IP-адреса и 16-битные номера портов сервера и соседа,
определяющие ассоциацию
регистр фильтра: измеренные задержка/смещение и отдельный экземпляр
задержки/смещения
задержка, смещение, дисперсия
источник синхронизации: сосед, определенный алгоритмом выбора
местные часы
Для защиты от помех и ошибок передачи (UDP!) используются
следующие методы:
Если в течении 8 последовательных интервалов опроса от соседа не было
сообщений, то он считается недостижимым.
Делается проверка времен: если время передачи совпадает с
предыдущим сообщением, то это несомненно дубль; если originate timestamp в
сообщении не совпадает со значением передачи в переменных данной
ассоциации, то нас пытаются обмануть.
Делаются дополнительные защиты от очень старых сообщений и не полностью
синхронизованных ассоциаций.
Аутентификатор состоит из ключа и шифрованной
контрольной суммы - деляется с помощью алгоритма DES и
DES cipher block-chaning (CBC),
обеспечивает непрерывную цепочку сообщений между узлами, в которую
невозможно влезть (необходима компенсация времени шифровки).
Используются алгоритмы, время работы которых не зависит от ключа и шифруемого текста.
Версия 4 (непринятая, но уже реализованная) обеспечивает
большую
точность за счет учета дрожания (jitter) источника и скорости работы сети,
улучшенных алгоритмов обработки и подстройки локальных часов,
более быстрой "сходимости" при запуске (минуты вместо дней).
Это позволяет уменьшить частоту опроса клиентом серверов.
Добавлены возможности наносекундного разрешения локальных часов (Linux?),
управления с помощью SNMP и
автоматической конфигурации клиентов (multicast) с обеспечением безопасности
методами криптографии. В дополнение к алгоритмам симметричного шифрования
(к DES CBC добавлен MD5) используется алгоритм с открытым ключом (autokey,
работы не завершены).
сервера слоя 1, используемые NIST для обслуживания клиентов
(умер?; NIST - это американский институт стандартов;
рекомендуется использовать IP адреса вместо DNS имен;
насколько я понял, доступны всем желающим - "The NIST Internet Time Service
(ITS) allows users to synchronize computer clocks via the Internet.
The service responds to time requests from any Internet client.")
сервера слоя 1 обсерватории США (доступ разрешается только для серверов слоя 2, принадлежащих ISP;
не более 3 для каждой организации, находящейся в том же часовом поясе;
для серверов из другого часового пояса требуется соглашение;
ntp2.usno.navy.mil и tock.usno.navy.mil заявлены как "open access")
список публичных серверов слоев 1 и 2 от разработчиков NTP (рекомендуется пользоваться
серверами слоя 1 только, если ваш сервер обслуживает более 100 клиентов и
имеет не менее 2 соседей; из-за перегрузки они плохо доступны, проверяйте
перед использованием;
Россия представлена гг. Пущино и Черноголовка ;)
московские сервера (не знаю - будут ли хозяевы рады вам):
bgm.rosprint.net. (2)
crocus.gamma.ru. (3)
news.gamma.ru. (3)
mail.gamma.ru (2)
ntp0.zenon.net (2)
news.demos.su. (2)
В любом случае для надежной работы рекомендуется
организовать от 3 до 5 локальных серверов NTP, объединенных "соседскими"
связями и каждый из которых синхронизуется не менее чем с 3 внешними серверами
желательно с использованием различных маршрутов доступа. Крайне нежелательно
использовать несимметричные маршруты (туда по модему, обратно по спутниковому
каналу).
draft-ietf-stime-ntpauth-04.txt (предложения по стандартизации протокола аутентификации autokey для NTP 4)
RFC 1708 D. Gowin, "NTP PICS PROFORMA For the Network Time Protocol Version 3", 10/26/1994. (бланк, заполняемый владельцем сервиса NTP)
RFC 1589 D. Mills, "A Kernel Model for Precision Timekeeping", 03/03/1994. (как реализовать управление временем (в частности, в SunOS), чтобы можно было стыковаться с NTP; наверное, для разработчиков ядра Unix это интересно ;)
RFC 1305 D. Mills, "Network Time Protocol (v3)", 04/09/1992.
(отменил RFC-1119, RFC-1059, RFC-958)
RFC 1165 J. Crowcroft, J. Onions, "Network Time Protocol (NTP) over the OSI Remote Operations Service", 06/25/1990. (работа NTP в условиях сервиса, ориентированного на соединение - не наш случай)
RFC 1129 D. Mills, "Internet time synchronization: The Network Time Protocol", 10/01/1989. (более свежая версия текста)
RFC 1128 D. Mills, "Measured performance of the Network Time Protocol in the Internet system", 10/01/1989. (итог исследования: 1% хостов поддерживает NTP, 30% из них дает точность 30мс, 99% дает точность 10 секунд, NTP дает точность в 1000 раз выше, чем TIME или ICMP Timestamp)
RFC 1119 D. Mills, "Network Time Protocol version 2 specification and implementation", 09/01/1989. (Obsoletes RFC1059) (STD 12) (Obsoleted by RFC1305)
RFC 1059 D. Mills, "Network Time Protocol version 1 specification and implementation", 07/01/1988. (Obsoletes RFC0958) (Obsoleted by RFC1119)
RFC 958 D. Mills, "Network Time Protocol NTP", 09/01/1985. (Obsoleted by RFC1059)