Протоколы синхронизации времени: NTP, IRIG, AFNOR. NTP – атомные часы на каждом столе Протокол синхронизации времени ntp

В 2005 году была начата работа по изменению стандарта IEEE1588-2002 с целью расширения возможных областей его применения (телекоммуникации, беспроводная связь и в др.). Результатом работы стало новое издание IEEE1588-2008, которое доступно с марта 2008 со следующими новыми особенностями:

  • Усовершенствованные алгоритмы для обеспечения погрешностей в наносекундном диапазоне.
  • Повышенное быстродействие синхронизации времени (возможна более частая передача сообщений синхронизации Sync).
  • Поддержка новых типов сообщений.
  • Ввод однорежимного принципа работы (не требуется передачи сообщений типа FollowUp).
  • Ввод поддержки функции т.н. прозрачных часов для предотвращения накопления погрешностей измерения при каскадной схеме соединения коммутаторов.
  • Ввод профилей, определяющих настройки для новых областей применения.
  • Возможность назначения на такие транспортные механизмы как DeviceNet, PROFInet и IEEE802.3/Ethernet (прямое назначение).
  • Ввод структуры TLV (тип, длина, значение) для расширения возможных областей применения стандарта и удовлетворения будущих потребностей.
  • Ввод дополнительных опциональных расширений стандарта.

Принцип функционирования систем на основе протокола PTP

В системах, где используется протокол PTP, различают два вида часов: ведущие часы и ведомые часы. Ведущие часы, в идеале, контролируются либо радиочасами, либо GPS-приемниками и осуществляют синхронизацию ведомых часов. Часы в конечном устройстве, неважно ведущие ли они или ведомые, считаются обычными часами; часы в составе устройств сети, выполняющих функцию передачи и маршрутизации данных (например, в Ethernet-коммутаторах), считаются граничными часами.

Рис. 1. Согласно протоколу PTP синхронизация устройств по времени осуществляется на основе схемы «ведущий - ведомый».

Процедура синхронизации согласно протоколу PTP подразделяется на два этапа. На первом этапе осуществляется коррекция разницы показаний времени между ведущими и ведомыми часами - то есть осуществляется так называемая коррекция смещения показаний времени. Для этого ведущее устройство осуществляет передачу сообщения для целей синхронизации времени Sync ведомому устройству (сообщение типа Sync). Сообщение содержит в себе текущее показание времени ведущих часов и его передача осуществляется периодически через фиксированные интервалы времени.

Однако поскольку считывание показаний ведущих часов, обработка данных и передача через контроллер Ethernet занимает некоторое время, информация в передаваемом сообщении к моменту его приема оказывается неактуальной. Одновременно с этим осуществляется как можно более точная фиксация момента времени, в который сообщение Sync уходит от отправителя, в составе которого находятся ведущие часы (TM1). Затем ведущее устройство осуществляет передачу зафиксированного момента времени передачи сообщения Sync ведомым устройствам (сообщение FollowUp). Те также как можно точнее осуществляют измерение момента времени приема первого сообщения (TS1) и вычисляют величину, на которую необходимо выполнить коррекцию разницы в показаниях времени между собою и ведущим устройством соответственно (O) (см. рис. 1 и рис. 2). Затем непосредственно осуществляется коррекция показаний часов в составе ведомых устройств на величину смещения. Если задержки в передачи сообщений по сети не было, то можно утверждать, что устройства синхронизированы по времени.

Рис. 3. Вычисление времени задержки сообщений в коммутаторах.

Задержка в передачи сообщения в обоих направлениях будет идентичной в том случае, если устройства соединены между собой по одной линии связи и только. Если в сети между устройствами имеются коммутаторы или маршрутизаторы, то симметричной задержка в передачи сообщения между устройствами не будет, поскольку коммутаторы в сети осуществляют сохранение тех пакетов данных, которые проходят через них, и реализуется определенная очередность их передачи. Эта особенность может, в некоторых случаях, значительным образом влиять на величину задержки в передаче сообщений (возможны значительные отличия во временах передачи данных). При низкой информационной загрузке сети этот эффект оказывает малое влияние, однако при высокой информационной загрузке, указанное может значительным образом повлиять на точность синхронизации времени. Для исключения больших погрешностей был предложен специальный метод и введено понятие граничных часов, которые реализуются в составе коммутаторов сети. Данные граничные часы синхронизируются по времени с часами ведущего устройства. Далее коммутатор по каждому порту является ведущим устройством для всех ведомых устройств, подключенных к его портам, в которых осуществляется соответствующая синхронизация часов. Таким образом, синхронизация всегда осуществляется по схеме точка-точка и характерна практически одинаковая задержка в передаче сообщения в прямом и обратном направлении, а также практическая неизменность этой задержки по величине от одной передачи сообщения к другой.

Хотя принцип, основанный на использовании граничных часов показал свою практическую эффективность, другой механизм был определен во второй версии протокола PTPv2 - механизм использования т. н. прозрачных часов. Данный механизм предотвращает накопление погрешности, обусловленной изменением величины задержек в передаче сообщений синхронизации коммутаторами и предотвращает снижение точности синхронизации в случае наличия сети с большим числом каскадно-соединенных коммутаторов. При использовании такого механизма передача сообщений синхронизации осуществляется от ведущего устройства ведомому, как и передача любого другого сообщения в сети. Однако когда сообщение синхронизации проходит через коммутатор фиксируется задержка его передачи коммутатором. Задержка фиксируется в специальном поле коррекции в составе первого сообщения синхронизации Sync или в составе последующего сообщения FollowUp (см. рис. 2). При передаче сообщений Delay Request и Delay Response также осуществляется фиксация времени задержки их в коммутаторе. Таким образом, реализация поддержки т. н. прозрачных часов в составе коммутаторов позволяет компенсировать задержки, возникающие непосредственно в них.

Реализация протокола PTP

Если необходимо использование протокола PTP в системе, должен быть реализован стек протокола PTP. Это может быть сделано при предъявлении минимальных требований к производительности процессоров устройств и к пропускной способности сети. Это очень важно для реализации стека протокола в простых и дешевых устройствах. Протокол PTP может быть без труда реализован даже в системах, построенных на дешевых контроллерах (32 бита).
Единственное требование, которое необходимо удовлетворить для обеспечения высокой точности синхронизации, - как можно более точное измерение устройствами момента времени, в который осуществляется передача сообщения, и момента времени, когда осуществляется прием сообщения. Измерение должно производиться максимально близко к аппаратной части (например, непосредственно в драйвере) и с максимально возможной точностью. В реализациях исключительно на программном уровне архитектура и производительность системы непосредственно ограничивают максимально допустимую точность.

При использовании дополнительной поддержки аппаратного обеспечения для присвоения меток времени, точность может быть значительным образом повышена и может быть обеспечена ее виртуальная независимость от программного обеспечения. Для этого необходимо использование дополнительной логики, которая может быть реализована в программируемой логической интегральной схеме или специализированной для решения конкретной задачи интегральной схеме на сетевом входе.

Выводы

Протокол PTP во многих областях уже доказал эффективность своего применения. Можно быть уверенным, что он получит более широкое распространение в течение следующих лет и что многие решения при его использовании смогут быть реализованы более просто и эффективно чем при использовании других технологий.

Оборудование KYLAND с поддержкой IEEE 1588v2

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

Высшего профессионального образования

«Национальный исследовательский ядерный университет «МИФИ»

Трехгорный технологический институт - филиал НИЯУ МИФИ

Кафедра ЭВМ

по дисциплине «Интернет-технологии»

на тему: «Протокол RSYNC. Синхронизация времени. Протокол NTP. Протокол SNTP»

Выполнил: студент группы 5ВТ-58

Кольцов Д.А.

Проверил: ст. преп. Долгополова М. О.

Трехгорный 2012

ПРОТОКОЛ RSYNC

СИНХРОНИЗАЦИЯ ВРЕМЕНИ

ПРОТОКОЛ NTP

ПРОТОКОЛ SNTP

СПИСОК ИСПОЛЬЗУЕМЫХ ИНТЕРНЕТ ИСТОЧНИКОВ

ПРИЛОЖЕНИЯ

ПРОТОКОЛ RSYNC

R sync (англ. Remote Synchronization) -- программа для UNIX-подобных систем, которая выполняет синхронизацию файлов и каталогов в двух местах с минимизированием трафика, используя кодирование данных при необходимости. Важным отличием rsync от многих других программ/протоколов является то, что зеркалирование осуществляется одним потоком в каждом направлении (а не по одному или несколько потоков на каждый файл). Rsync может копировать или отображать содержимое каталога и копировать файлы, опционально используя сжатие и рекурсию.

Разработчик - Wayne Davison;

Операционная система - Кроссплатформенное программное обеспечение.

Выпущен под лицензией GNU GPL, rsync является свободным программным обеспечением.

Кроссплатформенное (межплатформенное) программное обеспечение -- программное обеспечение, работающее более чем на одной аппаратной платформе и/или операционной системе. Типичным примером является программное обеспечение, предназначенное для работы в операционных системах Linux и Windows одновременно.

Существует реализация rsync для Winows, а точнее не прямая реализация, а сборка из rsync и cygwin, называемая cwRsync.

Алгоритм

Утилита rsync использует алгоритм, разработанный австралийским программистом Эндрю Триджеллом (приложение C), для эффективной передачи структур (например, файлов) по коммуникационным соединениям в том случае, когда принимающий компьютер уже имеет отличающуюся версию этой структуры.

Принимающий компьютер разделяет свою копию файла на неперекрывающиеся куски фиксированного размера S, и вычисляет контрольную сумму для каждого куска: MD4-хеш (приложение А) и более слабый rolling checksum (приложение B), и отправляет их серверу, с которым синхронизируется.

Сервер, с которым синхронизируются, вычисляет контрольные суммы для каждого кусочка размера S в своей версии файла, в том числе перекрывающиеся куски. Это может быть эффективно подсчитано ввиду особого свойства rolling checksum: если rolling checksum байт от n до n+S-1 равняется R, то rolling checksum байт от n+1 до n+S может быть посчитана исходя из R, байта n и байта n+S без необходимости учитывать байты, лежащие внутри этого интервала. Таким образом, если уже подсчитана rolling checksum байт 1-25, то для подсчета rolling checksum байт 2-26 используется предыдущая контрольная сумма и байты 1 и 26.

Основные преимущества

Скорость: Первоначально rsync реплицирует все содержимое между источником и местом назначения (приемником). Далее rsync передает только изменившиеся блоки или биты в место назначения, что делает синхронизацию действительно быстрой;

Безопасность: rsync включает в себя шифрование данных при передаче с использованием протокола SSH;

rsync использует сжатие и распаковку данных блок за блоком на передающей и принимающей стороне соответственно. Таким образом, используемая rsync пропускная способность ниже по сравнению с другими протоколами передачи файлов.

Синтаксис

$ rsync options source destination, где Source (источник) и Destination (место назначения) могут быть как локальными, так и удаленными. В случае использования с удаленными объектами указывает логин, имя сервера и путь.

Некоторые важные опции:

1) -a, --archive режим архива;

2) -r, --recursive обходить директории (рекурсия);

3) -R, --relative относительные пути;

4) -H, --hard-links сохранять жесткие ссылки (hardlink);

5) -S, --sparse handle sparse files efficiently;

6) -x, --one-file-system не пересекать границы файловой системы;

7) -exclude=PATTERN исключить файлы заданного образца;

8) -delete-during приемник удаляется ПРИ ПЕРЕДАЧЕ;

9) -delete-after приемник удаляется ПОСЛЕ ПЕРЕДАЧИ.

СИНХРОНИЗАЦИЯ ВРЕМЕНИ

Время в эпоху информационных технологий приобрело особое значение для современного человека. Каждый из нас как минимум по нескольку раз в день поглядывает на часы. Многие регулярно синхронизируют свои устройства отчета времени посредством различных источников, в том числе и Интернет. Точное время порой играет порой решающую роль в делах, где важны даже не минуты, а секунды. К примеру, торги на фондовых биржах, могут обернуться крахом для игрока, чьи часы показывали неправильное время.

Технология синхронизации времени

Весь процесс синхронизации времени проводиться посредством специального сетевого протокола называемого NTP (Network Time Protocol) . Данный протокол представляет из себя свод различных правил и математических алгоритмов, благодаря которым происходит точная настройка времени на вашем компьютере с разницей в несколько сотых одной секунды. Существует протокол и для систем, не требующих такой точной синхронизации, который называется SNTP . Разница источника и устройства-приёмника времени по нему может составлять до 1 секунды.

Технология передачи параметров точного времени представляет из себя многослойную структуру, где каждый нижележащий слой электронных устройств синхронизируется с вышележащим. Чем ниже технологический слой, тем менее точным будет полученное от него время. Но это в теории, на практике же все зависит от множества параметров, участвующих в системе синхронизации и получить более точное время можно, к примеру, от четвертого слоя устройств, нежели от третьего.

На нулевом уровне этой цепочки передачи всегда располагаются устройства отчета времени, грубо говоря, часы. Эти часы представляют из себя молекулярные, атомные или квантовые устройства подсчета времени и называются эталонными. Такие устройства не передают параметры времени в Интернет напрямую, обычно они подключены к первичному компьютеру посредством высокоскоростного интерфейса с минимальными задержками. Именно эти компьютеры составляют первый слой в технологической цепочке. На втором слое будут располагаться машины получающие время от первого слоя устройств посредством сетевого соединения, чаще всего через Интернет. Все последующие уровни будут получать информацию о точном времени по тем же сетевым протоколам от вышележащих слоев.

Системы синхронизации времени

В соответствии с федеральным законом «О связи» № 126 от 7 июля 2003 года, Статья 49 - «Учетно-отчетное время в области связи», в технологических процессах передачи и приема сообщений электросвязи и почтовой связи, их обработки в пределах территории Российской Федерации операторами электросвязи и операторами почтовой связи должно применяться единое учетно-отчетное время - московское». Для этого на цифровой сети оператора электросвязи необходимо организовать систему точного времени.

Системой точного времени называется комплекс технических средств обеспечивающих периодическую передачу цифровой информации о значении текущего времени от эталонного источника ко всем сетевым элементам с целью синхронизации их внутренних часов. Это применительно к цифровому оборудованию сетей электросвязи, в котором происходит обработка различных данных в режиме реального времени и должно обеспечиваться одновременное выполнение определенных внутренних технологических процессов.

Актуальность решения задачи организации системы синхронизации единого точного времени или, другими словами, организации временной синхронизации, в телекоммуникационных сетях неразрывно связана с развитием биллинговых систем, систем управления разного назначения, сетевой безопасностью, компьютерных систем, а также совершенствованием методов эксплуатации цифрового оборудования электросвязи и метрологическим обеспечением.

Потребителем сигналов единого точного времени являются: вычислительные комплексы и компьютерные серверы (системы управления и мониторинга сетевым оборудованием), оборудование транспортных сетей SDH, ATM, IP и сетей коммутации, серверы биллинга и баз данных; оборудование передачи данных и пакетной коммутации (маршрутизаторы, коммутаторы) и т.д.

Использование временной синхронизации позволяет синхронизировать моменты времени начала и конца какого-либо процесса в сети одного или разных операторов электросвязи, например, при локализации аварии с помощью внутренней диагностики оборудования и создании записи в журнале о произошедшем событии на сервере в системе управления, соединении разговора абонентов, тарификации информационного трафика в соответствии со временем суток и месторасположением абонента в зоне обслуживания той или иной сети, наконец, проведении процедур, связанных с подтверждением приема/передачи электронной подписи, совершении трансакций и т.д.

Работы по созданию системы точного времени включают в себя:

* выбор источника сигнала точного времени;

* определение способа передачи сигналов точного времени по сети связи;

* выбор сетевых протоколов и сигналов точного времени;

* определение оборудования, требующего синхронизацию по времени;

* выбор варианта решения по обеспечению различных видов оборудования сигналами точного времени.

К числу высокоточных и наиболее доступных средств передачи сигналов времени, не требующих аренды существующих или построения дополнительных линий связи, по праву можно отнести глобальные навигационные спутниковые системы (ГНСС): российскую ГЛОНАСС и американскую GPS . Глобальность систем обеспечивается функционированием на орбитах набора видимых из любой точки Земли спутников, непрерывно передающих высокоточные сигналы, которые можно использовать в системе точного времени.

В настоящее время, например, спутниковая система GPS может использоваться для синхронизации оборудования телекоммуникационных сетей российских операторов электросвязи только в качестве второго приоритета, следовательно, в качестве основного источника сигналов точного времени необходимо применять спутниковую систему ГЛОНАСС .

Чтобы получить шкалу времени от спутниковых систем необходимо использовать специальное оборудование, содержащее в своем составе приемники сигналов ГЛОНАСС и GPS . Такое специализированное оборудование получило название - сервер времени (Time Server ). При передаче сигналов времени от сервера к удаленным сетевым клиентам используются специальные Интернет - протоколы NTP (Network Time Protocol) и PTP (Precision Time Protocol - IEEE1588) . На основе сетевых протоколов систему точного времени целесообразно строить по принципу иерархии.

ПРОТОКОЛ NTP

Протокол NTP (протокол сетевого времени) используется NTP-серверами для распространения между абонентами сети информации о с точном эталонном временем. Он также используется средствами Интернета для обеспечения синхронизации компьютеров и процессов.

NTP используется как Интернет протокол уже более 25 лет. Этот протокол является самым долго использующимся Интернет протоколом. Он появился на свет благодаря необходимости синхронизации времени и процессов в Интернете. Протокол NTP сначала использовался на платформах LINUX и UNIX включая FreeBSD (некоммерческая версия UNIX для PC), но позже стал использоваться и в операционной системе Windows. Специальные NTP системы в основном используют операционную систему LINUX.

Кроме того, помимо протокола NTP, существует протокол SNTP (Simple Network Time Protocol). На уровне пакетов эти два протокола полностью совместимы. Основным отличием между ними является то, что SNTP не имеет сложных систем фильтрации и многоступенчатой корректировки ошибок, имеющихся в NTP. Таким образом, SNTP является упрощенной и более легкой в реализации версией NTP. Он предназначен для использования в тех сетях, где не требуется очень высокая точность времени, и в реализации от корпорации Microsoft обеспечивает точность в пределах 20 секунд в рамках предприятия и не более 2 секунд в пределах одного сайта. Протокол SNTP стандартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).

Основные принципы протокола NTP

Протокол NTP был создан для обеспечения пользователей сети тремя параметрами:

1) установкой сбоя эталона времени;

2) установкой полного цикла задержки времени;

3) установкой разброса параметров по отношению к специализированным часам отсчёта.

Сбой эталона времени - это разница во времени между местными часами и часами отсчёта. Полный цикл задержки времени - это то количество времени, которое необходимо протоколу, чтобы получить ответ от сервера. Разброс параметров - это максимальная ошибка часов местного времени по отношению к эталону.

Сообщения протокола NTP

Протокол NTP использует UDP (протокол передачи дейтаграмм пользователя) NTP-сообщение состоит из нескольких полей:

1) Индикатор скачков;

2) Номер версии;

6) Точность;

7) Дефект в корневой системе;

8) Разброс параметров;

9) Идентификатор эталона;

10) Дата создания;

11) Отметка времени приёма;

12) Отметка времени передачи;

13) Распознавание кода;

14) Дайджест сообщений.

Индикатор скачка предостерегает о надвигающемся скачке суммирования или удаления.

Номер версии отображает номер используемой версии NTP.

Режим помогает задавать режим текущего сообщения NTP.

Декомпозитор - 8-битная система, идентифицирующая иерархический уровень эталонных часов.

Poll определяет максимальный интервал между сообщениями.

Точность устанавливает верность местных часов.

Ошибка в корневой системе указывает номинальную ошибку эталонного времени.

Идентификатор эталона - это 4 символьный ASCII-код, идентифицирующий источник эталона, например: GPS,DCF, MSF. Поле Идентификатора кода используется, когда необходимо установить достоверность кода.

Дата создания эталона устанавливает время, когда NTP запрос пользователя был отправлен NTP серверу.

Отметка времени получения указывает время, когда запрос был получен NTP сервером.

Отметка времени о передачи указывает время, когда ответное сообщение NTP сервера было передано пользователю.

Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code).

Режимы работы NTP сервера

NTP сервер может работать в трёх режимах:

В первых двух режимах пользователь передаёт NTP запрос серверу. Сервер отвечает сообщением, которое пользователь использует для синхронизации времени NTP. В режиме многоадресной рассылки сообщения NTP рассылаются периодически в определённые интервалы времени.

Эталонные часы

Для синхронизации времени NTP серверов могут использоваться различные внешние источники точного времени. Для обеспечения точности времени очень часто используется GPS. Также существуют различные государственные источники эталонного времени, например, радиовещание. Многие радиостанции вещают не только на территории своих государств, но и за их границей, поэтому по ним можно легко устанавливать время.

ПРОТОКОЛ SNTP

протокол программа синхронизация файл

SNTP (англ. Simple Network Time Protocol) -- протокол синхронизации времени по компьютерной сети. Является упрощённой реализацией протокола NTP. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени. В протоколе SNTP используется одинаковый с протоколом NTP формат представления времени -- 64-битное число, состоящее из 32-битного счётчика секунд и 32-битного счётчика долей секунд. Нулевое значение счётчика времени соответствует нулю часов 1 января 1900 г., 6 ч 28 м 16 с 7 февраля 2036 г. и т. д. Для успешного функционирования протокола необходимо, чтобы клиент знал своё время в пределах ±34 года относительно времени сервера.

Формат сообщения

Рисунок 1 - Формат сообщения

Описание полей формата сообщения SNTP, представленного на рисунке 1:

Индикатор коррекции (ИК) показывает предупреждение о будущей вставке или удалении секунды в последней минуте суток;

Номер версии (НВ) -- текущее значение 4;

Интервал опроса -- беззнаковое целое, двоичная экспонента которого показывает максимальный интервал между последовательными сообщениями в секундах. Определено только для сообщений сервера, допустимые значения от 4 (16 с) до 17 (около 36 ч);

Точность -- знаковое целое, двоичная экспонента которого показывает точность системных часов. Определено только для сообщений сервера, типичные значения от?6 до?20;

Задержка -- знаковое число с фиксированной запятой, находящейся между 15 и 16 знаками, показывающее полное время распространения сигнала туда и обратно до источника синхронизации сервера времени. Определено только для сообщений сервера;

Дисперсия -- беззнаковое число с фиксированной запятой, находящейся между 15 и 16 знаками, показывающее максимальную ошибку из-за нестабильности часов. Определено только для сообщений сервера;

Идентификатор источника -- источник синхронизации сервера, строка для страты 0 и 1, IP-адрес для вторичных серверов. Определено только для сообщений сервера;

Время обновления -- время, когда системные часы последний раз были установлены или скорректированы;

Ключ идентификации, дайджест сообщения -- необязательные поля, используемые для аутентификации.

Операции сервера SNTP

Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.

В уникастном и эникастном режимах сервер может реагировать, а может и игнорировать запросы, но предпочтительным поведением является присылка отклика в любом случае, так как позволяет убедиться в достижимости сервера.

Наиболее важным индикатором неисправности сервера является поле LI, в котором код 3 указывает на отсутствие синхронизации. Когда получено именно это значение, клиент должен проигнорировать сообщение сервера вне зависимости от содержимого других полей.

Конфигурация и управление

Исходная конфигурация SNTP серверов и клиентов может быть произведена на основе конфигурационного файла, если такой файл имеется, или через последовательный порт. Предполагается, что SNTP серверы и клиенты практически не требуют какого-то конфигурирования, специфического для данного узла (помимо IP-адреса, маски субсети или адреса OSI NSAP).

Уникастные клиенты должны быть снабжены именем сервера или его адресом. Если используется имя сервера, то необходим один или несколько адресов ближайших DNS-серверов.

Мультикастные серверы и эникастные клиенты должны снабжаться значением TTL, а также местным широковещательным или групповым мультикастным адресом. Эникастные серверы и мультикастные клиенты могут конфигурироваться с привлечением списков пар адрес-маска. Это обеспечивает контроль доступа, так что операции будут производиться только с известными клиентами или серверами. Эти серверы и клиенты должны поддерживать протокол IGMP, а также знать местный широковещательный или групповой мультикастный адрес.

СПИСОК ИСПОЛЬЗУЕМЫХ ИНТЕРНЕТ ИСТОЧНИКОВ

1) https://ru.wikipedia.org/wiki/Rsync;

2) http://greendail.ru/node/487;

3) http://inetedu.ru/articles/19-services/70-synchronization-time.html;

4) http://www.ptime.ru/exec_time.htm;

5) http://www.tenderlib.ru/articles/56;

6) http://docstore.mik.ua/manuals/ru/inet_book/4/44/sntp4416.html;

7) http://www.ixbt.com/mobile/review/billing.shtml.

ПРИЛОЖЕНИЯ

Приложение А

MD4 (Message Digest 4) -- хеш-функция, разработанная профессором Массачусетского университета Рональдом Ривестом в 1990 году, и впервые описанная в RFC 1186. Для произвольного входного сообщения функция генерирует 128-разрядное хеш-значение, называемое дайджестом сообщения. Этот алгоритм используется в протоколе аутентификации MS-CHAP, разработанном корпорацией Майкрософт для выполнения процедур проверки подлинности удаленных рабочих станций Windows. Является предшественником MD5.

Рисунок A - Операция MD4

Одна операция MD4 (рисунок A). Хеширование с MD4 состоит из 48 таких операций, сгруппированных в 3 раунда по 16 операций. F -- нелинейная функция; в каждом раунде функция меняется. M i означает 32-битный блок входного сообщения, а K i -- 32-битная константа, различная для каждой операции.

Приложение B

Rolling checksum

Кольцевой хэш (англ. rolling hash) -- хэш-функция, обрабатывающая вход в рамках некоторого окна. Получение значения хэш-функции для сдвинутого окна (window) в таких функциях является дешевой операцией. Для пересчета значения требуется знать лишь предыдущее значение хэша; значение входных данных, которые остались за пределами окна; и значение данных, которые попали в окно. Процесс сходен с вычислением Скользящей среднего.

Применяется в алгоритме поиска подстроки Рабина -- Карпа, а также в программе rsync для сравнения двоичных файлов (используется кольцевая версия adler-32).

Приложение C

Эндрю Триджелл

Эндрю «Tridge» Триджелл (28 февраля 1967) -- австралийский программист, известный как автор и участник проекта Samba и соавтор алгоритма rsync. Также известен своей работой по анализу сложных закрытых протоколов и алгоритмов, позволившей создать совместимые свободные реализации. Лауреат Free Software Award за 2005.

Free Software Award -- ежегодная премия FSF за вклад в развитие свободного программного обеспечения, основанная в 1998 году.

Рисунок С - Эндрю Триджелл

Размещено на Allbest.ru

Подобные документы

    Анализ основных атак на протокол TLS и определение методов противодействия этим атакам. Разработка метода перехвата и расшифровки трафика, передаваемого по протоколу HTTPS. Расшифровка передаваемых данных в режиме, приближенному к реальному времени.

    статья , добавлен 21.09.2017

    Створення операційної системи UNIX. Історія створення і розвитку протоколів ТСР/ІР. Протокол транспортного рівня. Логічний комунікаційний канал між джерелом і отримувачем даних без встановлення зв’язку. Протокол взаємодії з сервером доменних імен.

    контрольная работа , добавлен 18.05.2009

    Типы корпусов системных блоков. Основные топологии сетей: шина, кольцо, звезда, дерево. FTP как протокол, предназначенный для передачи файлов в компьютерных сетях. Классификация программного обеспечения. Информационно-поисковые системы и их классификация.

    контрольная работа , добавлен 24.12.2010

    Определение IP-протокола, передающего пакеты между сетями без установления соединений. Структура заголовка IP-пакета. Инициализация TCP-соединения, его этапы. Реализация IP на маршрутизаторе. Протокол надежной доставки сообщений ТСР, его сегменты.

    контрольная работа , добавлен 09.11.2014

    Понятие о протоколе Secure Sockets Layer. "Безопасный канал", основные свойства. Использование протокола, его недостатки. Интерфейс программы EtherSnoop. Фазы протокола диалога. Публичные ключи, особенности распространения. Обмен данными в Интернете.

    реферат , добавлен 31.10.2013

    Общие сведения о протоколе передачи данных FTP. Технические процессы осуществления соединения с помощью протокола FTP. Программное обеспечение для осуществления соединения с помощью протокола FTP. Некоторые проблемы FTP-серверов. Команды FTP протокола.

    реферат , добавлен 07.11.2008

    Описание и предназначение протокола DNS. Использование файла host. Особенности и описание способов атак на DNS: ложный DNS-сервер, простой DNS-флуд, фишинг, атака посредством отраженных DNS-запросов. Защита и противодействие атакам на протокол DNS.

    реферат , добавлен 15.12.2014

    Разработка серверной программы, которая позволяет удаленно наблюдать за компьютером, работающим под управлением Linux. Условия, необходимые для решения данной задачи: используемые протоколы передачи данных, программные средства, динамические библиотеки.

    курсовая работа , добавлен 18.06.2009

    Описание основных типов станций протокола HDLC. Нормальный, асинхронный и сбалансированный режимы работы станции в состоянии передачи информации. Методы управления потоком данных. Формат и содержание информационного и управляющего полей протокола HDLC.

    лабораторная работа , добавлен 02.10.2013

    Функция протокола и структура пакета разрабатываемого протокола. Длина полей заголовка. Расчет длины буфера на приеме в зависимости от длины пакета и допустимой задержки. Алгоритмы обработки данных на приеме и передаче. Программная реализация протокола.

т е х н о л о г и и

С.Телегин

Протокол PTP для синхронизации сетей NGN

вопросы применения

В статье рассматривается задача синхронизации сетей передачи данных следующего поколения (NGN). В

качестве альтернативного метода передачи синхронизации автор предлагает использовать протокол PTP. Приведены характеристики систем синхронизации на основе протокола PTP (IEEE 1588) в сравнении с системами, использующими шину PXI, а также протокол NTP.

Проблема синхронизации в сетях NGN

Развитие телекоммуникационных технологий и сетей передачи данных постепенно приводит к построению операторами связи конвергентных сетей следующего поколения (NGN – Next Generation Networks). Основное отличие таких сетей от традиционных сетей с синхронной цифровой иерархией (SDH) – в них для магистральной передачи данных наряду с обычными синхронными каналами используются такие асинхронные технологии, как Ethernet (Gigabit Ethernet, 10Gigabit Ethernet). Главным требованием операторов связи к сетям следующего поколения является одновременная передача голоса, видео и данных по единой сети.

При переходе от традиционных сетей передачи данных, основанных на временном мультиплексировании, к сетям NGN особое внимание уделяется передаче сигналов синхронизации. Синхронизация оборудования необходима в первую очередь для безошибочной передачи данных реального времени – голоса и видеоизображений. Поскольку в сетях Ethernet используется коммутация пакетов, которая в силу статистических свойств распространения пакетов данных по асинхронным каналам передачи разрушает изначально синхронизированный поток данных, передача синхронизации в сетях NGN выделяется в отдельную задачу. Для передачи синхронных данных по сетям с коммутацией пакетов, как правило, используется эмуляция каналов с временным мультиплексированием, заключающаяся в инкапсуляции синхронных данных в UDP-датаграм- мы и последующем их восстановлении на узле назначения .

ПЕРВАЯ МИЛЯ 5–6/2009

Для безошибочного восстановления переданных данных на стыке асинхронного и синхронного каналов оборудование также должно получать синхросигнал. Требования к стабильности синхросигнала варьируются в зависимости от конкретного назначения сети передачи данных. Так, в операторских сетях по предоставлению услуг телефонии и доступа в Интернет требования к синхронизации являются достаточно мягкими – 50 ppm (единиц на миллион), а в сотовых сетях для бесшовного перехода мобильных абонентов от одной базовой станции к другой необходима стабильность 50 ppb (единиц на миллиард).

Способы синхронизации сетей NGN

В рекомендации ITU-T G.8261 рассмотрены три основных способа восстановления синхронизации на границах транспортной среды с коммутацией пакетов при передаче в ней группового сигнала с временным мультиплексированием в виде услуги эмуляции каналов. Для этого в оконечном станционном оборудовании должны быть предусмотрены функции межсетевого взаимодействия. Все абоненты транспортной среды с коммутацией пакетов могут получать тактовую частоту от сети синхронизации посредством обычного централизованного распределения (рис.1). Если абонентское оборудование работает на собственной тактовой частоте (рис.2), то на границе сети с коммутацией пакетов ее восстанавливают различными относительными способами, например, с помощью алгоритма согласования скоростей SRTS. В обоих случаях в узле межсетевого взаимодействия должен быть доступ к стыку с генератором первичной синхрони-

т е х н о л о г и и

зации (PRC). Для этого оператор сети NGN должен либо строить отдельную сеть синхронизации, либо арендовать ее у существующих операторов транспортной сети SDH.

Существует множество примеров локальной синхронизации оборудования. Так, например, в станционном помещении размещают недорогой источник первичной синхронизации (PRS) на основе GPS и распределяют от него тактовую частоту с помощью беспроводных технологий или по обычным выделенным кабелям, в физической среде Ethernet, а также c помощью других оригинальных схем . Если построение сети синхронизации (или использование стыков синхронизации) невозможно или нежелательно, то применяют самый простой, но проблематичный из соображений стабильности адаптивный способ согласования скоростей приема и передачи (рис.3).

Результаты проведенных исследований показывают, что адаптивный способ можно применять, если абонент не предъявляет строгих требований к стабильности своей тактовой частоты, в противном случае необходимо дополнительное аппаратное сглаживание восстановленного синхросигнала. Альтернативой адаптивному методу является использование протокола RTP при инкапсуляции данных с временным мультиплексированием в пакеты асинхронных данных (рис.4). Как показали эксперименты, в данном случае при высокой стабильности восстановленного синхросигнала оборудование оказывается слабочувствительным к изменению частоты на источнике синхронизации, что является необходимым, например, в сотовых сетях при переходе на резервный синхросигнал.

Протокол PTP

Следующей ступенью развития, по-видимому, станет отдельная передача сигналов синхронизации сети с коммутацией пакетов с

помощью специально разработанных протоколов (рис.5). На данный момент таковыми являются протоколы NTP и PTP . Эти протоколы изначально создавались для синхронизации времени в различных устройствах сети, но в случае успешной синхронизации часов также становится возможным реализация алгоритмов синхронизации тактовых частот для восстановления данных реального времени. Протокол NTP (Network Time Protocol) широко используется для синхронизации текущего времени на прикладном уровне. В отличие от него, протокол "точного времени" PTP (Precision Time Protocol) действует на втором уровне модели взаимодействия открытых систем (OSI). Протокол РТР описан в стандарте IEEE 1588. Ожидается, что в дальнейшем РТР может быть использован как для высокоточной синхронизации текущего времени, так и для тактовой синхронизации оборудования. Рассмотрим данный протокол более подробно.

Стандарт IEEE 1588 предполагает, что протокол РТР предоставляет стандартный метод синхронизации устройств в сети с точностью выше 1 мкс (до 10 нс). Данный протокол обеспечивает синхронизацию ведомых устройств от ведущего, удостоверяясь, что события и временные метки на всех устройствах используют одну и ту же временную базу. В протоколе предусмотрены две ступени для синхронизации устройств: определе-

Рис. 3 Адаптивная синхронизация

Рис.4

Передача синхронизации с помощью RTP

Рис.5

Передача синхронизации с помощью PTP

ПЕРВАЯ МИЛЯ 5–6/2009

Рис. 6 Алгоритм работы PTP

ние ведущего устройства (1) и коррекция разбега во времени, вызванного смещением отсчета часов в каждом устройстве и задержками в передаче данных по сети (2). При инициализации системы протокол PTP использует алгоритм "наилучших ведущих часов" для определения самого точного источника синхронизации в сети. Такое устройство становится ведущим, а все остальные устройства в сети – ведомые и подстраивают свои часы по ведущему устройству.

Разница во времени между ведущим и ведомым устройствами является комбинацией смещения отсчета часов и задержки передачи синхронизирующего сообщения. Поэтому коррекция временного сдвига должна выполняться в два этапа: вычисление задержек передачи и сдвига, а затем их коррекция. Рассмотрим последовательность синхронизации часов двух устройств (рис.6).

Ведущее устройство начинает коррекцию сдвига часов, используя сообщения Sync и Follow-up. В сообщении Follow-up указывается время отправления сообщения Sync (ТМ1 ), измеренное наиболее близко к среде передачи для минимизации ошибки во времени опорного источника. После того, как ведомое устройство получает первые сообщения Sync и Follow-up, оно использует свои часы для отметки времени прибытия сообщения Sync (TS1 ) и сравнивает данную отметку с той, что пришла от ведущего устройства в сообщении Follow-up. Разница между этими двумя метками отражает сдвиг часов T0 плюс задержку передачи сообщения от ведущего устройства к ведомому ∆TMS : TS1  – TM1  = T0  + ∆TMS .

Для вычисления времени задержки передачи сообщения и сдвига отсчета часов ведомое устройство отправляет сообщение Delay_request со своим временем TS2 . Ведущее устройство отмечает прибытие данного сообщения и отправляет в ответ сообщение Delay_response меткой TM2 . Разница между двумя метками – это задержка передачи от ведомого устройства к ведущему ∆TSM минус сдвиг в отсчете ведомого устройства: TM2  – TS2  =∆TSM  – T0 .

При вычислении задержки передачи сообщения принимается, что средняя задержка передачи данных в канале рав-

на среднему арифметическому задержек распространения в разные стороны канала:

T MS + T SM

Зная времена TS1 , TM1 , TM2 и TS2 , ведомое устройство вычисляет усредненную задержку распространения в канале передачи данных:

T = (TS1 − TM1 ) + (TM2 − TS2 ) . 2

Финальная синхронизация часов выполняется после отправки ведущим устройством второго набора сообщений Sync (TS3 ) и Follow-up (TM3 ). Ведомое устройство вычисляет сдвиг своих часов по формуле T0  = TS3  – TM3  – ∆T.

После этого ведомое устройство подстраивает свои часы в соответствии с вычисленными значениями. Поскольку опорные источники синхронизации в каждом устройстве нестабильны, а задержки в канале могут меняться со временем, необходимо периодически повторять коррекцию часов ведомого устройства.

Особенности реализации протокола PTP

Большинство реализаций PTP имеют отклонение меньше 1 мкс, однако реальная точность работы зависит от приложения. Протокол PTP в устройствах реализуют тремя способами: программным, программно-аппаратным и аппаратным. Программные реализации РТР позволяют передавать сигналы синхронизации с точностью порядка 100 мкс. Чтобы достичь более высокой точности, необходимо использовать аппаратные средства. Каждый компонент, который обрабатывает пакет PTP после его получения из физической среды передачи, увеличивает ошибку синхронизации. Программная часть вносит наибольшую ошибку, поскольку загрузка процессора и задержка, связанная с обработкой прерывания, влияют на скорость обработки запроса синхронизации.

При программно-аппаратной реализации наиболее чувствительные функции протокола, такие как запись временной метки PTP-пакета, реализуются на физическом уровне Ethernet , например, в отдельной микросхеме программируемой логики. Такие методы сегодня наиболее оптимальны, так как требуют не слишком много ресурсов и времени на разработку устройства, позволяя добиться точности порядка 20 нс. В случае же полной аппаратной реализации протокола PTP достижима точность порядка 10 нс.

Кроме способа реализации на точность работы протокола РТР влияет ряд других факторов. Например, стандарт IEEE 1588 не специфицирует частоту синхронизации ведущего и ведомого устройств. В результате синхросигналы с более низкой частотой будут иметь менее точное временное разрешение, приводящее к менее точным временным меткам в синхронизирующих сообщениях. Стабильность частоты опорных генераторов также влияет на качество реализации протокола. Синхросигналы, полученные при использовании термостатированных и термокомпенсированных кварцевых генераторов, будут более стабильны (от-

ПЕРВАЯ МИЛЯ 5–6/2009

т е х н о л о г и и

клонение в миллиардные доли), нежели кварцевые генераторы

шую альтернативу для синхронизации распределенных сис-

без термостабилизации (отклонение в миллионные доли).

тем с субмикросекундной точностью.

На качество синхронизации устройств влияет также топо-

Таким образом, протокол PTP является альтернативным

логия сети и равномерность трафика. В сети с большим чис-

способом синхронизации сетей, который может получить рас-

лом устройств и высокой загрузкой каналов передачи данных

пространение в сетях NGN. По сравнению с используемыми в

точность трансляции синхронизации будет хуже. Поэтому для

настоящее время средствами синхронизации, данный метод

передачи сигналов синхронизации предпочтительно использо-

обладает рядом преимуществ:

вать отдельную сеть передачи данных.

Не требуется доступ оборудования напрямую к стыку синхро-

низации PRC, что позволит операторам оптимизировать за-

Сравнительные характеристики

траты на построение сети. При этом протокол РТР может обес-

систем синхронизации

печить передачу синхронизации с субмикросекундной точнос-

Рассмотрим характеристики систем синхронизации, использую-

тью, а значит, достижима стабильность лучше, чем 1 ppm;

щих протокол PTP, в сравнении с системами с синхронизацией

В отличие от адаптивного метода, для восстановления синх-

по шине PXI (физическая линия синхронизации) и по протоко-

ронизации необходим высокостабильный опорный генератор

лу NTP (см. таблицу). В отличие от систем с физической линией

только в ведущем устройстве;

синхронизации, где точность событий определяется точностью

Для задач синхронизации можно использовать асинхрон-

синхросигнала, в протоколе PTP определяющим факторов явля-

ный канал со сравнительно небольшой пропускной способ-

ется дрожание фазы (джиттер), связанное со случайным измене-

ностью, что значительно уменьшает стоимость реализации.

нием межпакетных интервалов. Большинство реализаций прото-

Предпочтительно, чтобы этот канал был выделенным.

кола PTP обеспечивает точность менее 1 мкс.

Принимая во внимание простоту развертывания сетей

Еще одна важная величина, отличающая разные способы

Ethernet, субмикросекундную точность и функционирование

синхронизации, – время ожидания синхронизирующего собы-

с минимальными затратами на обработку сообщений, прото-

тия. Это время между отправкой события ведущим устройс-

кол PTP все чаще используется во многих отраслях, особенно

твом и получением его ведомым. Поскольку протоколы PTP и

в промышленной автоматике, в метрологии и т.п. Ожидает-

NTP для передачи синхронизирующих сообщений использу-

ся, что в будущем возможности протокола PTP расширят его

ют пакеты данных, ожидание события определяется временем

применение и в телекоммуникациях для синхронизации уст-

ожидания пакета плюс время передачи и обработки заголовка

ройств по сетям с коммутацией пакетов.

пакета и, как правило, составляет несколько миллисекунд. В

отличие от них системы с физической линией синхронизации

Литература

ожидают синхронизирующего события в течение нескольких

1. Stein Y., Schwartz E. Circuit Extension over IP: The

наносекунд. Время ожидания синхронизирующего события оп-

Evolutionary Approach to Transporting Voice and Legacy

ределяет такую характеристику, как максимально возможная

Data over IP Networks. – RAD Data Communications, 2002.

частота подстройки синхросигнала.

2. ITU-T G.8261/Y.1361 Timing and synchronization

Системы синхронизации с единой шиной синхронизации,

aspects in packet networks. – ITU_T, April 2008.

такие как PXI, идеально подходят для высокоточного и скоро-

3. Rodrigues S. Technology options for sync delivery in

стного восстановления синхронизации и могут быть расши-

Next Generation Networks. – 3rd International Telecom

рены на расстояния до сотен метров с помощью специальных

модулей синхронизации, размещаемых в кассетах. Стандар-

4. Телегин С.А. Применение TDMoIP мультиплекси-

тная синхронизация по сети Ethernet с помощью NTP предо-

рования для передачи данных в транспортных сетях

ставляет миллисекундную синхронизацию, подходящую для

GSM. – Нелинейный мир, 2007, т.5, №5, с. 270–271.

низкоскоростных приложений, не очень критичных к качеству

5. IEEE Std. 1588–2008 IEEE Standard for a Precision

синхронизации. Протокол же PTP представляет собой хоро-

Clock Synchronization Protocol for Networked

Сравнительные характеристики систем синхронизации

Measurement and Control Systems. – IEEE, July 2008.

6. IETF RFC1305 Network Time Protocol (Version 3).

Синхронизирующие

Протокол

Протокол

Specification, Implementation and Analysis. – IETF,

модули на шинах PXI

Временное

<1·107

7. Tan E. IEEE 1588 Precision Time Protocol Time

разрешение

событий, нс

Synchronization Performance. Application Note 1728. –

National Semiconductor, October 2007.

ожидания

8. Hamdi M. Neagoe T. A Hardware IEEE-1588

Implementation with Processor Frequency Control. –

подстройки

Arrow Electronics, August 2006.

ПЕРВАЯ МИЛЯ 5–6/2009

Зачем нужно точное время?

А кому вообще нужно это точное время? Конечно, оно нужно нам, пользователям, для того, чтобы мы меньше опаздывали. Представим себе современный аэропорт – для его работы сотни пилотов и диспетчеров должны пользоваться безошибочно идущими часами. Система регистрации товаров на складах, больничные учреждения, кассы по продаже железнодорожных билетов и многие другие учреждения требуют, чтобы время на всех объектах системы в той или иной степени было одинаково. Тем более компьютеры. На них работает масса служб и программ, для нормальной работы которых необходимо точное время, причем, как правило, более точное, чем это обычно нужно нам, людям. Системные службы, компоненты системы безопасности, да и просто прикладные программы могут быть очень критичны к точности часов. Наиболее ярким примером таких служб является протокол аутентификации Kerberos. Так, для его работы необходимо, чтобы на компьютерах, доступ к которым осуществляется с использованием этого протокола, системное время различалось не более чем на 5 минут. Кроме того, точное время на всех компьютерах значительно облегчает анализ журналов безопасности при расследовании инцидентов в локальной сети.

Протокол NTP

NTP (Network Time Protocol) – это протокол, предназначенный для синхронизации времени в сети. Он представляет собой набор достаточно сложных алгоритмов, призванных обеспечить высокую точность (до нескольких микросекунд) и отказоустойчивость системы синхронизации времени. Так, протокол предполагает одновременную синхронизацию с несколькими серверами.

Существует несколько версий этого протокола, имеющих некоторые отличия. Третья версия этого протокола в 1992 году была стандартизирована как RFC 1305. Четвертая (последняя на данный момент) версия привносит некоторые улучшения (автоматическая конфигурация и аутентификация, улучшение алгоритмов синхронизации) по сравнению с третьей, однако она еще не стандартизирована в RFC.

Кроме того, помимо протокола NTP, существует протокол SNTP (Simple Network Time Protocol). На уровне пакетов эти два протокола полностью совместимы. Основным отличием между ними является то, что SNTP не имеет сложных систем фильтрации и многоступенчатой корректировки ошибок, имеющихся в NTP. Таким образом, SNTP является упрощенной и более легкой в реализации версией NTP. Он предназначен для использования в тех сетях, где не требуется очень высокая точность времени, и в реализации от корпорации Microsoft обеспечивает точность в пределах 20 секунд в рамках предприятия и не более 2 секунд в пределах одного сайта. Протокол SNTP стандартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).

Модель синхронизации NTP предполагает иерархическую структуру. На первом уровне иерархии располагаются так называемые «первичные» серверы времени (First stratum). Они находятся в разных местах по всему миру и располагают самым точным временем. Таких серверов относительно немного, так как точное время на них поддерживается с помощью дорогостоящего специализированного оборудования (радиоканал, спутниковый канал). Серверы второго уровня (Second stratum) синхронизируются с серверами первого уровня, используя протокол NTP. Их уже значительно больше, однако они уже несколько рассинхронизированы (от 1 до 20 миллисекунд) относительно «первичных» серверов. Далее могут идти серверы третьего, четвертого и последующих уровней:

С переходом на каждый уровень немного возрастает погрешность относительно первичного сервера, но зато увеличивается общее число серверов и, следовательно, уменьшается их загрузка. Поэтому в качестве внешнего источника синхронизации вместо использования первичных серверов, обладающих наиболее точным временем, рекомендуется использовать вторичные серверы как менее загруженные.

Для синхронизации времени в ОС Windows 2000/XP/2003 используется протокол SNTP. Поддержка этого протокола реализована в виде системной службы Windows Time, входящей в состав операционной системы MS Windows 2000/XP/2003. Отличительной особенностью этой реализации является то, что служба Windows Time поддерживает доменную аутентификацию при обращении к эталонному серверу времени, что является немаловажным с точки зрения безопасности.

Существует несколько вариантов работы службы SNTP, входящей в Windows:

  • Иерархическая (NT5DS). Используется по умолчанию для всех компьютеров, объединенных в домен. Синхронизация времени на рабочих станциях и серверах домена производится по иерархии. Таким образом, рабочие станции и рядовые серверы синхронизируются с контроллером домена, аутентифицировавшим вход, контроллеры домена – с хозяином операции «эмулятор PDC», который в свою очередь синхронизируется с контроллером домена, стоящим на более высоком уровне иерархии. Следует заметить, что данный порядок синхронизации используется «по умолчанию» и может быть переопределен вручную или с использованием групповых политик. О том, как это сделать, будет рассказано ниже.
  • Принудительная синхронизация с выбранным NTP-сервером (NTP). В данном случае источник эталонного времени для службы Windows Time устанавливается либо вручную, либо с помощью групповых политик.
  • Отключение синхронизации (NoSync). Этот режим необходим для смешанной схемы поддержания времени, в которой для синхронизации с внешним источником используется продукт третьей фирмы, а для поддержания времени в рамках домена используется Windows Time.

Таким образом, в случае рабочей группы синхронизацию времени всё равно придется настраивать вручную. Например, один из компьютеров можно настроить на синхронизацию с внешним сервером по протоколу SNTP, а остальные – на синхронизацию с ним. Необходимые для этого действия будут описаны ниже.

Для домена рекомендуется использовать иерархическую синхронизацию по протоколу SNTP. В большинстве случаев она обеспечивает приемлемую точность системного времени в рамках леса домена. Кроме того, она автоматически обеспечивает безопасность обновления времени, благодаря поддержке аутентификации с Active Directory. Для поддержки «правильного» времени в домене необходимо синхронизировать контроллер домена верхнего уровня, владеющий ролью «эмулятор PDC», с внешним NTP-сервером. В нашем примере в роли такого сервера будет выступать Linux-машина с работающим демоном ntpd.

Настройка SNTP в Windows

Для настройки службы Windows Time используются две утилиты:

  • Net time
  • W32tm

Net time используется главным образом для конфигурирования службы времени, а w32tm – для мониторинга и диагностики работы. Однако в Windows XP/2003 утилита w32tm претерпела существенные изменения и может быть использована для конфигурации службы времени. Настройка NTP далее будет проводиться на примере Windows XP/2003.

Итак, для того чтобы «вручную» указать источник синхронизации с помощью net time, достаточно написать в командной строке:

et time /setsntp:список_серверов_времени_через_пробел

Для получения информации о текущем сервере времени:

net time /querysntp

Узнать время на контроллере домена можно так:

net time /domain:имя_домена

А синхронизировать время с контроллером домена вот так:

Net time /domain:имя_домена /set

Системной утилитой w32tm можно сделать все то же самое и даже больше:

  • w32tm /resync – при помощи этой команды можно заставить локальный или удаленный компьютер синхронизировать показания своих системных часов с используемым им сервером времени.
  • w32tm /config – эта команда используется для конфигурирования службы Windows Time. С ее помощью можно задать список используемых серверов времени и тип синхронизации (иерархическая или выбранная серверами).

Например, для того чтобы переопределить значения по умолчанию и настроить синхронизацию времени с внешним источником, можно воспользоваться командой:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

А для того чтобы Windows Time применила новые настройки, вместо перезапуска службы можно использовать команду:

w32tm /config /update

Кроме того, в w32tm доступны следующие параметры, связанные с мониторингом времени на компьютерах:

  • w32tm /monitor – при помощи этой опции можно узнать, насколько системное время данного компьютера отличается от времени на контроллере домена или других компьютерах.
  • w32tm /stripchart – графически показывает разницу во времени между текущим и удаленным компьютером.
  • w32tm /register – регистрирует службу Windows Time в качестве службы на данном компьютере. Эта опция может быть полезна на компьютерах, не входящих в домен, так как по умолчанию на них служба времени остановлена.

Более подробные сведения о параметрах утилит net time и w32tm можно получить, используя ключ /? или открыв соответствующий раздел справочной системы «Help and Support Center» MS Windows XP/2003.

Нетрудно догадаться, что настройки службы Windows Time хранятся в реестре Windows в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

В корне раздела определяются параметры работы самой службы, в подключе Config – настройки, связанные с работой самого протокола SNTP, режим синхронизации определяется в подключе Parameters. Настройки SNTP клиента и сервера находятся в подключах TimeProviders\NtpClient и TimeProviders\NtpServer соответственно. Рассмотрим основные значения, определяющие настройку NTP клиента и сервера:

  • Type – определяет режим работы NTP-клиента (NTDS5 – иерархическая, NTP – «вручную», NoSync – не синхронизировать, AllSync – доступны все типы синхронизации);
  • Enabled – определяет, включен ли данный компонент (клиент или сервер);
  • CrossSiteSyncFlags – определяет, можно ли синхронизировать время с источником, находящимся за пределами домена, в случае если используется иерархическая синхронизация (0 – нельзя, 1 – только с эмулятором PDC, 2 – со всеми);
  • EventLogFlags – определяет, будут ли сообщения от Windows Time заноситься в журнал или нет (очень полезная функция при отладке работы).

Другой вариант настройки службы времени Windows Time – использование групповых политик. Настройки определяются в объекте групповой политики по следующему адресу: «Computer Configuration –> Administrative Templates –> System –> Windows Time Service».

Если у вас установлен Windows 2000 Server и такой настройки вы не нашли – не отчаивайтесь, вам просто нужно обновить «Административные шаблоны». Для этого скопируйте из системной папки system32\GroupPolicy\Adm любой машины с установленной Windows XP все.adm-файлы на сервер, являющийся контроллером домена. Далее, определяя объект групповой политики, нажмите правой кнопкой на «Administrative templates» и выберите «Add/Remove templates…» Удалите перечисленные там шаблоны и добавьте скопированные. После нажатия кнопки «OK» шаблоны будут обновлены, и вы сможете сконфигурировать службу времени, используя групповые политики:

Нетрудно заметить, что здесь главным образом перечислены все те настройки, которые можно изменять в реестре. Ничего удивительного в этом нет, ведь именно так и работает большинство групповых политик.

В ОС Windows XP появился еще один способ задания сервера времени, который может быть очень удобен для настройки синхронизации на домашнем компьютере или компьютере, входящем в рабочую группу:

NTP-сервер под Linux – внешняя синхронизация для Windows-домена

Как было сказано выше, протокол NTP более устойчив к ошибкам, поэтому в качестве источника эталонного времени для внешней синхронизации лучше использовать NTP-сервер. К тому же не всегда у контроллера домена верхнего уровня есть доступ к Интернету по порту UDP 123, используемого для работы NTP. Доступ вполне может быть закрыт по соображениям безопасности, что является обычной практикой крупных организаций. В таких случаях для решения этой проблемы можно установить в демилитаризированной зоне – DMZ – свой сервер времени, настроенный на синхронизацию с внешним источником, и использовать его в качестве эталонного источника времени для синхронизации контроллера домена верхнего уровня. В качестве такого компьютера вполне подойдет любая, не обязательно современная машина с *nix-подобной ОС, например, Linux, установленной в минимальной конфигурации, без X-сервера и других потенциально уязвимых вещей.

Существует масса программ для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd, входящий в состав Redhat 9, поставляемый в пакете ntp-4.1.2-0.rc1.2.i386.rpm.

В состав пакета входит несколько программ, предназначенных для работы с NTP.

Вот основные из них:

  • Ntpd – демон ntp, поддерживающий точное время в фоновом режиме;
  • Ntpq – утилита, предназначенная для опроса NTP-серверов, поддерживающих стандартный протокол опроса NTP mode 6. С ее помощью можно узнать и изменить текущее состояние сервера, если его настройки это позволяют;
  • Ntptdc – утилита, при помощи которой можно опрашивать демон ntpd и получать статистику его работы;
  • Ntpdate – программа для установки текущего системного времени с использованием протокола NTP.

Стандартной возможностью протокола NTP является возможность проведения аутентификации. При этом могут использоваться как симметричные алгоритмы (DES), появившиеся еще во второй версии протокола, так и несимметричные алгоритмы, с открытым ключом, являющиеся новшеством четвертой версии.

В случае использования симметричной схемы аутентификации клиент и сервер выбирают произвольный идентификатор и один из 65534 ключей, определенных стандартом. При использовании несимметричных алгоритмов, используется так называемая схема Autokey, отличительной особенностью которой является отсутствие необходимости предварительно распределять открытые ключи серверов.

Для настройки аутентификации в ntpd существуют утилиты ntp-genkeys, ntpq и ntpdc.

Вся функциональность NTP, связанная с поддержкой точного времени, реализована в демоне ntpd. Его настройка производится обычным для UNIX способом – путем редактирования конфигурационного файла ntp.conf, находящегося в папке /etc.

Зададим следующие опции для работы NTP-сервера.

Сначала укажем серверы, с которыми будет производиться синхронизация времени:

server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net

restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Здесь маска 255.255.255.255 используется для ограничения доступа к нашему серверу со стороны сервера ntp.nasa.gov. Теперь определим список узлов в нашей локальной сети, которым мы хотим разрешить доступ к нашему NTP-серверу для получения времени:

restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

Также нам требуется, чтобы Linux-машина имела полный доступ к ресурсам своего сервера:

restrict 127.0.0.1

И теперь самое важное: мы должны убедиться в том, что запрет по умолчанию, имеющий более высокий приоритет, закомментирован:

#restrict default ignore

После сохранения файла ntp.conf настройку можно считать оконченной, однако может так получиться, что после запуска демона время все еще не будет синхронизироваться. Дело в том, что протокол NTP изначально разрабатывался как протокол поддержания времени, а не его установки. Поэтому, если разница между показаниями часов достаточно велика (более чем несколько минут), то синхронизация производиться не будет. В этом случае имеет смысл первоначально установить время вручную при помощи команды ntpdate (также можно добавить команду ntpdate в стартовые скрипты машины):

# ntpdate clock.vsu.ru
17 Feb 23:44:54 ntpdate: step time server 198.123.30.132 offset 25.307598 sec

17 Feb 23:45:05 ntpdate: adjust time server 198.123.30.132 offset 0.002181 sec
# ntpdate clock.vsu.ru

Запуск ntp-демона производится через инициализационные скрипты. Если программа устанавливалась из rpm-пакета, то скорее всего все вопросы, связанные с ее автоматическим запуском, уже решены. Для того чтобы в этом убедиться, можно воспользоваться командой:

# chkconfig -list ntpd
ntpd 0:on 1:off 2:off 3:on 4:off 5:on 6:off

Если вы не видите этой строки, значит, автоматический запуск ntpd не настроен. Чтобы это исправить, наберите:

# chkconfig –level 035 ntpd on

Для управления NTP (старт, запуск, перезапуск, статус) используются стандартный инициализационный скрипт:

# /etc/init.d/ntpd start

Для просмотра статистики синхронизации сервера можно воспользоваться следующей командой:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220.00 0.149 7.08
-navobs1.wustl.e .PSC. 1 u 55 64 377 193.47 6.857 4.81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254.88 7.471 9.58
-ntp0.NL.net .GPS. 1 u 144 512 377 122.54 12.515 13.75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133.94 14.594 41.99
+timekeeper.isi. .GPS. 1 u 13 64 377 245.30 3.454 15.08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37.51 -3.239 11.14
LOCAL(0) LOCAL(0) 10 l - 64 377 0.00 0.000 10.01

Режимы работы NTP сервера/клиента

Клиент/сервер

Этот режим на сегодняшний день наиболее часто используется в сети Интернет. Схема работы – классическая. Клиент посылает запрос, на который в течение некоторого времени сервер присылает ответ. Настройка клиента производится с помощью директивы server в конфигурационном файле, где указывается DNS имя сервера времени.

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

Этот режим рекомендуется использовать в тех случаях, когда малое количество серверов обслуживает большое количество клиентов. Работая в этом режиме, сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с сервером. Особенностью этого режима является то, что время доставляется в рамках одной подсети (ограничение broadcast-пакетов). Кроме того, для защиты от злоумышленников необходимо использовать аутентификацию.

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

Этот режим является нововведением четвертой версии протокола NTP. Он подразумевает поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и выбор на основании этих данных трех «лучших» manycast-серверов, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Часто возникающие вопросы

Почему после команды net time /setsntp:server время не синхронизируется?

Убедитесь, что для службы w32time задан тип запуска «Автоматически».
Убедитесь, что порт UDP 123 используемого NTP-сервера доступен.
Убедитесь, что время между клиентом и сервером не отличается слишком сильно.

Может ли SNTP-клиент синхронизироваться с NTP-сервером?

Да, может, так как протокол SNTP является подмножеством NTP и полностью с ним совместим.

Можно ли использовать NTP-сервер от третьих производителей в ОС Windows 2000/XP/2003?

Да, можно воспользоваться любым сервером, платным или бесплатным. Предварительно следует отключить соответствующие компоненты (клиентские или серверные) службы Windows Time.

Почему NTP-клиент не работает на компьютере с установленным MS SQL Server?

Скорее всего проблема заключается в том, что SQL Server каким-либо образом занимает порт UDP 123. В качестве решения можно предложить запуск клиента NTP до MS SQL Server.

Демона ntpd после запуска работает 10-20 минут, после чего останавливается. В чем может быть проблема?

Убедитесь, что время клиента и сервера отличается не слишком сильно (не более 5 минут). В противном случае выполните принудительную синхронизацию при помощи ntpdate.

Можно ли синхронизировать время в OS Windows NT4, 95, 98, Me?

Можно, при помощи программ третьих фирм, например, NetTime, Automacahron, World Time5, ntpd Windows NT port.

При попытке входа в домен Windows появляется сообщение, что время между контроллером домена и рабочей станцией отличается слишком сильно, при том, что синхронизация точно настроена.

Скорее всего проблема в том, что время сбилось очень сильно (сброс CMOS, хакерская диверсия) и службе не удается пройти аутентификацию по протоколу Kerberos. Для решения этой проблемы нужно либо вручную подвести время, либо не использовать этот вид аутентификацию при обновлении времени.

09.07.2012, Пн, 10:07, Мск

Основная проблема в транспортных сетях нового поколения - то, что технология Ethernet изначально проектировалась для локальных вычислительных сетей и никогда не была предназначена для передачи сигналов синхронизации. В сетях с коммутацией каналов в последние десятилетия как транспортная среда доминирует технология синхронной цифровой иерархии (SDH), в ее основу заложена передача синхросигналов. Но даже эта надежная и хорошо себя зарекомендовавшая технология не отвечает требованиям современных приложений.

страницы: предыдущая | | 2

Использование стандарта Sync Ethernet

Изначально технология Ethernet разрабатывалась исключительно для использования в локальных сетях. Методы линейного кодирования информации на физическом уровне выбирались в соответствии с задачами, которые не предполагали передавать синхросигнал. В сетях SDH изначально использовались линейные коды NRZ, которые приспособлены для передачи синхронизации на физическом уровне канала связи. При создании технологии Sync Ethernet физический уровень и методы кодирования были заимствованы у технологии SDH, а второго (канального) уровня изменения практически не коснулись. Структура кадров осталась неизменной, за исключением SSM-байта статуса синхронизации. Его значения также были заимствованы в технологии SDH.


Принцип передачи синхронизации по протоколу Sync Ethernet

К преимуществам технологии Sync Ethernet можно отнести использование SDH-структуры физического уровня, а вместе с этим - огромный и бесценный опыт проектирования и построения сетей тактовой сетевой синхронизации. Идентичность методов сохранила актуальность старых рекомендаций G.803, G.804, G.811, G.812 и G.813 в новой технологии. Дорогие устройства - первичные эталонные генераторы (ПЭГ), вторичные задающие генераторы (ВЗГ) - могут быть задействованы также и в новой транспортной сети, построенной на стандарте Sync Ethernet.


Типовая схема синхронизации с использованием технологии Sync Ethernet

К недостаткам можно отнести то, что во всей сети передачи каждое устройство должно поддерживать новый стандарт, и, если в линии остается устройство, которое не поддерживает Sync Ethernet, то все устройства, которые стоят за этим узлом, не могут работать в синхронном режиме. Следовательно, требуются большие материальные затраты на модернизацию всей сети. Так же к недостаткам следует отнести, что данный метод поддерживает передачу только частотной синхронизации.

Использование протокола PTP (IEEE1588v2)

И последний способ передачи синхронизации, который в последнее время становится все более популярным, - это протокол Precise Time Protocol (PTP). Он описан в рекомендации IEEE 1588. В 2008 году вышла вторая версия этого документа, которая описывает использование протокола в телекоммуникационных сетях. Precise Time Protocol достаточно молодой, но сама технология передачи времени была заимствована у протокола Network Time Portocol (NTP). Протокол NTP в своей последней версии не дает точность, которая необходима для современных приложений, и поэтому он остался хорошим средством для временной синхронизации, которое широко используется в синхронизации серверов, распределенных баз данных и т.д. Но в построении сети тактовой сетевой синхронизации подходит логическое продолжение протокола NTP - это протокол PTP. Сетевыми элементами, которые участвуют во взаимодействии по протоколу PTP, являются следующие устройства: PTP Grand Master и PTP Slave. Обычно Grand Master берет синхронизацию от GNSS приемника и, используя эту информацию, обменивается пакетами с Slave устройством и постоянно корректирует временные расхождения между Grand Master и Slave устройствами. Чем активнее будет этот обмен, тем точность корректировки будет выше. Минусом такого активного обмена является увеличение полосы пропускания, которая выделяется для протокола PTP. Самой главной проблемой в расчете расхождения временных интервалов является то, что между устройствами Grand Master и Slave могут стоять "классические" маршрутизаторы 3 уровня. Термин "классические" в данном случае употреблен для того, чтобы подчеркнуть, что данные устройства ничего не понимают в протоколе PTP 5 уровня.

Задержками в буферах таких маршрутизаторов управлять достаточно сложно, и они носят случайный характер. Для того чтобы осуществлять контроль над этими случайными ошибками, а также чтобы расчет расхождения времени между Grand Master и Slave был точнее, в протоколе PTP был введен специальный параметр - метка времени (Time Stamp). Эта метка указывает на время прохождения пакета через маршрутизатор. Если на всем пути от Grand Master до Slave маршрутизаторы будут обладать функциональностью PTP и выставлять метку времени, то случайную ошибку, связанную с прохождением пакетов PTP через IP сеть, можно будет свести к минимуму.


Пример построения сети синхронизации на протоколе PTP

Сравнение методов передачи синхронизации в пакетных сетях нового поколения

Функциональность PTP на маршрутизаторах не является обязательной, но очень рекомендуется при использовании протокола PTP. Следует отметить, что большинство производителей маршрутизаторов включают эту функциональность в свои устройства. Пример построения схемы синхронизации для мобильного оператора представлен на рисунке ниже. Преимуществом PTP является то, что протокол ориентирован для передачи всех трех видов синхронизации: частотной, фазовой и временной. Основной недостаток протокола - это зависимость от нагрузки. При перегрузках на IP сети, которыми сложно управлять, очень сложно гарантировать строгое выполнение норм передачи синхронизации по сети.

Технология Преимущества Недостатки
GNSS Предоставление частотной, фазовой и временной синхронизации.
Не зависит от нагрузки сети. 		Обязательная установка антенны. Невозможность использования в закрытых помещениях. Возможные помехи от других радиоустройств. Резервирование предоставляется только установкой второго приемника GNSS
Sync Ethernet Не зависит от нагрузки сети. Схожесть с сетью SDH Предоставляет только частотную синхронизацию. Необходима поддержка Sync Ethernet всеми элементами сети
PTP Предоставление частотной, фазовой и временной синхронизации. Зависит от загрузки сети.

Каждый из методов имеет свои преимущества и недостатки, которые приведены в таблице. Чтобы определить правильный подход, рекомендуется учитывать много критериев, которые специфичны для различных сетей.

Михаил Вексельман

страницы: предыдущая | | 2



СХОЖИЕ СТАТЬИ