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 без дополнительной оплаты.
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 | ||||||||||||||||||||||||||||||||
Задача узнать точное время с некоторых пор стоит не только перед человеком. Множеству систем, созданных им, для правильного функционирования необходимо постоянно иметь в своём распоряжении очень точные часы, причём их точность должна быть значительно выше часов, используемых людьми в обычной жизни. Помимо собственно точности часов, не менее важной является их синхронизация со шкалой всемирного времени. Ведь даже в шкалу UTC (всемирное координированное время, является основой гражданского времени) периодически вносятся изменения в виде дополнительной секунды из-за расхождений с атомным временем (например, во времена, когда нашу планету населяли ещё первые динозавры, продолжительность суток была около 22 часов).
В качестве ярких примеров систем, использующих очень точные и надёжные методы вычисления текущего времени, вовсе необязательно представлять себе комплексы, управляющие движением космических аппаратов или авиационных диспетчерских служб – хотя, безусловно, требования к точности часов всех элементов подобных систем находятся на высочайшем уровне. Стабильные и синхронизированные со всемирным временем часы нужны и в системах, выполняющих более простые задачи. К ним, например, можно отнести научные и производственные комплексы, осуществляющие обработку данных в режиме реального времени различными устройствами. Добавьте ещё всё, что связано с финансами – это проведение банковских транзакций, системы биллинга операторов сотовой связи и Интернет-провайдеров, осуществляющие тарификацию обслуживаемого ими трафика. Всё это – примеры систем, реализация которых невозможна без использования часов, синхронизированных и согласованных с универсальным временем. В вычислительных сетях протокол аутентификации клиентов также использует сравнение времени сервера с часами клиентов.
Развитие коммуникаций в наше время значительно упростило задачу получения точного времени. Сейчас у нас «над головой» (точнее, на орбитах вокруг Земли) находится несколько десятков спутников систем глобального позиционирования, бортовые часы которых практически являются эталонами времени. Сигналы, посылаемые ими, могут использоваться для очень точной синхронизации часов. В вычислительных сетях синхронизация обычно выполняется с серверами точного времени при помощи протокола NTP (Network Time Protocol) или его «облегчённой» разновидности - SNTP (Simple Network Time Protocol) в тех случаях, когда максимальная функциональность применения полного NTP не является необходимой.
Протокол NTP использует иерархическую систему уровней, или стратумов. Сервер NTP имеет наиболее высокий уровень (стратум 1 ), если он получает данные непосредственно от источника точного времени. Сервера, синхронизирующие свои часы с сервером 1-го стратума, в этой модели находятся на уровень ниже (стратум 2), и т. д. Протокол NTP, в отличие от SNTP, обеспечивает более высокую точность синхронизации, используя сложные алгоритмы расчёта времени передачи пакетов в сети, и может осуществлять контроль ошибок и фильтрацию UDP-пакетов.
В общих чертах работает SNTP-протокол довольно просто и обычно происходит в три этапа:
- Клиент, которому необходимо получить время, отправляет UDP-пакет, содержащий SNTP-запрос на общепринятый порт 123 NTP-сервера, и переходит в режим ожидания ответа. В этом запросе он проставляет метку времени собственных часов.
- При получении запроса сервер отвечает UDP-пакетом, содержащим SNTP-сообщение, отправляя его клиенту с 123 порта. В пакете записывается полученная метка времени клиента и метка времени самого сервера.
- При получении ответа клиент может использовать отметку времени, созданную им самим при отправке запроса, для подтверждения правильности ответа, пытаясь убедиться, что он отправлен именно на запрос этого клиента (если пакет отправлен на запрос из другого источника, вероятность того, что он содержит такую же отметку времени создания, крайне низка). Затем он извлекает значение отметки времени передачи, преобразуя его в соответствии с предполагаемым временем задержки, вызванной прохождением пакета по сети, и использует результат для установки времени своих системных часов.
Форматы пакетов для обоих протоколов одинаковы, что позволяет NTP-серверу работать как с клиентами NTP, так и с клиентами SNTP.
Структура кадра NTP
Сервера NTP, как правило, имеют лишь один открытый «наружу» порт – UDP 123. В такой конфигурации администратору не приходится особо заботиться о безопасности сервера, поскольку он практически неуязвим для атак злонамеренных программ. Тем не менее, очень важно обеспечить доступность сервера 1-го стратума для клиентов, ведь иначе теряется сам смысл его эксплуатации. Основной проблемой становится количество запросов, которые в состоянии обслужить NTP-сервер. Впрочем, и сами запросы могут генерироваться по весьма любопытным причинам.
Наиболее известные случаи NTP-вандализма
В середине мая 2003 года сотрудники университета Мэдисона обнаружили стремительно возросший Интернет-трафик, который был направлен на публичные NTP-сервера университета. Трафик представлял собой запросы протокола NTP, состоящие из пакетов в 76 байт, передаваемых на 123 порт UDP. Однако эти пакеты имели необычное свойство: несмотря на то, что они исходили из различных источников, все они были отправлены с порта номер 23457.
Для защиты серверов была изменена конфигурация роутеров, блокировавшая только эту часть входящих запросов к NTP-серверам, обычные запросы продолжали нормально обслуживаться. Был заблокирован лишь весь UDP-трафик, содержащий запросы к NTP-серверу, отправленные с порта 23457 на порт 123. В тот момент персонал просто подумал, что столкнулся с атакой типа «распределённый отказ в обслуживании» (DDoS-атака , от англ. Distributed Denial of Service, отказ в обслуживании), организованной с множества случайных адресов, и остановился на этом, предполагая, что флуд затихнет в течение нескольких часов, как это обычно и бывает в случае атак низкого профессионального уровня.
Месяц спустя выяснилось, что поток входящего NTP-трафика значительно увеличился, достигнув огромных значений - 250 тысяч пакетов в секунду, с объёмом свыше 150 МБит/с. Аккуратно отменяя блокирование доступа для некоторых интерфейсов, персонал начал изучать UDP-пакеты, включая их содержимое. Они выглядели правильными запросами формата SNTP версии 1, хотя их высокая интенсивность с каждого хоста была непонятна. Например, в течение одного периода отслеживания, множество клиентов производило примерно один запрос в секунду. Это было бы крайне странным для нормально функционирующего SNTP-клиента. Приложения, использующие SNTP, лишь устанавливают собственные системные часы с необходимой точностью, так, чтобы хост имел некое достаточное представление о текущем времени.
Запрос времени каждую секунду является просто нелепым, и достаточно далёк от обычного поведения клиента NTP. Если у вас на улице случайный прохожий спрашивает время – это нормально. Но если он начнёт интересоваться временем каждый раз сразу же после того, как вы ответите, и к нему присоединится ещё какое-то количество людей? Если это будет продолжаться неделями? Стало ясно, что необходимо разбираться с причинами происходящего.
Ни один из источников запросов не находился в локальной сети комплекса зданий университета. Это означало, что для расследования причин инцидента потребуется помощь администраторов удалённых серверов. Из наиболее активных IP-адресов были выбраны два клиента, расположенных в сетях других университетах. Сетевым администраторам отослали письмо с описанием проблемы и просьбой выяснить, какие ОС и SNTP-клиенты могут быть запущены на этих хостах, и какие службы могут отправлять с них запросы, используя 23457 порт UDP.
Полученные ответы содержали сведения о том, что источником трафика являлись роутеры производства Netgear (в частности, один из них был идентифицирован как модель MR814). Теперь события начали приобретать некий смысл. Большое количество хостов, использующих один и тот же порт, могло быть объяснено встроенным SNTP-клиентом с запрограммированным номером порта. Сотрудники университета Мэдисона стали собирать информацию о продуктах Netgear, в которых была заявлена поддержка NTP. После исследования кода выяснилось, что в некоторые из них производитель просто программно «зашил» сведения о NTP-серверах. Кроме IP-адресов из диапазонов, зарезервированных для локальных сетей, в них содержались IP-адреса глобальной маршрутизации, среди которых был и публичный сервер NTP университета Мэдисона. Проблема усугублялась ещё и тем, что из указанных в коде глобальных IP-адресов реальным NTP-сервером оказался лишь университетский, а встроенный клиент роутера, не получив ответа на SNTP-запрос, начинал генерировать новые запросы каждую секунду.
Выявив, наконец, причины NTP-флуда, сотрудники университета обратились к производителю роутеров. Netgear пришлось признать свою ошибку. Выяснилось, что к тому моменту уже было продано свыше семисот тысяч подобных устройств. Несложные расчёты показывают, что потенциально они были способны генерировать трафик 426Мбит/с (700000 пакетов UDP в секунду, каждый длиной 76 байт), направленный на один и тот же NTP-сервер.
Для решения проблемы была создана группа с участием представителей университета, производителя и независимых экспертов. Были довольно быстро выпущены исправленные версии программного обеспечения для устройств, содержащих ошибки в коде. Конечно, это не решило всех проблем – ведь выпуск новой версии прошивки производителем не значит её замену всеми пользователями, большая часть которых и не подозревала о подобных проблемах. Тем не менее, университет решил продолжить обслуживание дефектных устройств Netgear, предоставляя им возможность синхронизации системных часов (связано ли это решение с суммой $375,000, которая была выплачена Netgear университету Мэдисона, как говорят, «для повышения безопасности беспроводной сети и развитие сети комплекса зданий университета», автору доподлинно неизвестно).
В том же году подобный инцидент произошел в Австралии. На этот раз его участниками стали лаборатория национальных измерений организации по научным и производственным исследованиям Австралии (Commonwealth Scientific and Research Organisation, CSIRO ) и калифорнийский производитель сетевого оборудования SMC Networks . Предельная загрузка NTP-серверов CSIRO (1-й стратум, источник – цезиевые часы, иначе называемые «атомными ») оценивалась в 200кБит/с. Блокирование трафика, основная часть которого приходила из-за океана, приводило к тому, что устройства SMC при отсутствии ответа от NTP-сервера начинали отсылать запросы дважды в минуту. В конце концов, CSIRO приняла решение изменить адреса своих серверов точного времени (предварительно известив об этом своих партнёров), а провайдеры просто стали блокировать запросы от источников, расположенных вне Австралии.
Последняя наиболее известная проблема подобного рода произошла в 2005 году и впервые получила название «NTP-вандализм », закрепившееся впоследствии как общий термин для обозначения случаев злоупотребления NTP-серверами. Тогда «чёрная метка» досталась датскому серверу 1-го стратума, подключенному к национальной сети Danish Internet Exchange (DIX). Сервер принадлежал одному из разработчиков FreeBSD - Полу-Хёнингу Кампу (Poul-Henning Kamp), и хотя не принадлежал государственным или научным учреждениям, существовал на некоммерческой основе. В правилах использования прямо указывалось, что использовать его для синхронизации времени могут только NTP-серверы второго стратума, расположенные на территории Дании и приложения, работа которых требует чрезвычайно точного времени.
В роли вандала выступил концерн D-Link . По оценке владельца NTP-сервера, от 75% до 90% запросов генерировались роутерами, произведёнными D-Link. Когда количество таких пакетов превысило три миллиона в день, провайдер потребовал от Кампа оплатить расходы, вызванные значительным увеличением трафика в размере DKK 54,000 (примерно $8,800 USD) в год.
Так же, как и в случае с университетом Мэдисона, Камп обратился в D-Link, надеясь на решение проблемы и возмещение своих финансовых затрат, ею вызванных. В отличие от Netgear, D-Link стала отрицать наличие проблемы вообще, в ответ обвиняя Кампа в вымогательстве. Противостояние длилось почти полгода, пока Камп не предал широкой огласке все детали инцидента. Наконец, в апреле 2006 года стороны пришли к мирному соглашению. Было заявлено, что уже существующие продукты D-Link получат авторизованный доступ к NTP-серверу Кампа, а последующие – перестанут его использовать (финансовая сторона соглашения неизвестна, но по некоторым оценкам, содержание собственных серверов времени, способных обслуживать такой трафик, обходилась бы D-Link’у около $1000 в месяц).
Технические решения
Все эти случаи заставили задуматься разработчиков сетевых протоколов над тем, какими способами, кроме применения различных политик доступа, можно избежать подобных проблем в будущем. Одним из решений стали изменения, внесённые в четвертую версию протокола NTP, появившиеся в начале 2006 года и описанные в RFC 4330. Они включают в себя расширение семантики полей пакета NTP для возможности посылки сервером специального управляющего пакета с романтичным названием «поцелуй смерти » (Kiss-o"-Death, KoD). В таком пакете заголовки заполняются специальным образом – поле дополнительной секунды содержит значение 3, поле, указывающее стратум сервера, устанавливается в 0, а идентификатор ссылки содержит 4-х байтовый код, указывающий причину его посылки (на практике пока применяется лишь код RATE - превышение частоты запросов).
Отправка такого пакета клиенту означает, что сервер обнаружил нарушение клиентом правил доступа к нему, и обслуживание клиента будет прекращено. Клиент при его получении должен прекратить отсылку запросов и попытаться, если необходимо, найти другой NTP-сервер. Если клиент не сможет обнаружить другой доступный NTP-сервер, он должен уменьшить частоту запросов к прежнему серверу в соответствии с экспоненциально убывающим алгоритмом.
В документе также представлены рекомендованные принципы, в соответствии с которыми «правильным» NTP-клиентом должны формироваться интервалы времени, определяющие частоту запросов к серверу, использоваться элементы сетевой инфраструктуры (включая DNS и DHCP). Если во встроенном коде устройства планируется указание прямых адресов NTP-серверов, настоятельно рекомендуется делать это лишь после согласования с их владельцами.
В принципе, такие нововведения вполне разумны, однако сколько-нибудь ощутимая польза от них возможна будет лишь тогда, когда подавляющее количество NTP-серверов и клиентов в глобальной сети будут полностью соответствовать требованиям четвёртой версии протокола NTP. Увы, в ближайшее время надеяться на развитие событий таким образом не приходится (к слову, одним из «следов», благодаря которым Камп пришёл к выводу, что источником атак являются роутеры производства D-Link, было использование ими всеми протокола SNTP версии 1).
В качестве технического решения, позволяющего значительно уменьшить пиковую нагрузку на сервера точного времени, можно отметить проект pool.ntp.org . Он представляет собой большой виртуальный кластер географически распределённых ntp-серверов (на момент написания статьи в него входят 1742 сервера со всех континентов). Сам проект был запущен в 2003 году, явившись плодом дискуссии о значительных затратах, необходимых для содержания и эксплуатации надёжных серверов точного времени, способных постоянно обслуживать значительное количество запросов. Идея, положенная в его основу, очень напоминает рекурсивный механизм функционирования серверов DNS. Если в качестве сервера-поставщика точного времени будет указан просто сервер вида 0.pool.ntp.org , то реальный сервер, с которым будет осуществляться синхронизация времени, будет выбираться случайным образом при каждом запросе клиента из списка серверов, входящих в пул. Однако, пользователи пула могут самостоятельно выбирать региональные сервера точного времени, уточняя континентальную зону, или даже зону конкретной страны (как правило, чем ближе сервер, тем точнее выполняется синхронизация), например - 0.ru.pool.ntp.org для России. При этом необходимо помнить, что некоторые страны не представлены в пуле, а некоторые представлены одним - двумя серверами (например, Малайзия). Использование пула осуществляется бесплатно, кроме обслуживания компаний, производящих оборудование и программные продукты, NTP-запросы которых планируется обслуживать при помощи ресурсов pool.ntp.org .
Сама идея запуска публичного сервиса синхронизации с точными часами без обеспечения его стабильности и надёжности в условиях экстремальных нагрузок вряд ли имеет какой-либо смысл. История знает немало примеров почивших NTP-серверов с заявленным 1-м стратумом, "сообщавших" время, отличающееся от реального на десятки (!) секунд, или просто ставших недоступными для запросов. Сервис, позволяющий синхронизировать часы с точным источником времени - это именно тот случай, когда понятие надёжности является таким же важным, как и точность предоставляемых данных. Вот иллюстрация реальной работы NTP-сервера Mobatime Systems:
Статистика запросов NTP-сервера Mobatime Systems
Это достаточно яркий пример NTP-вандализма - 1 апреля 2009 года было заблокировано 75 хостов, отославших более 12 миллионов запросов в сутки. Схожая интенсивность атаки продолжалась в течение 3 суток, и её природу вряд ли можно объяснить банальными ошибками в коде устройств, или их неправильным конфигурированием. Для защиты от подобных атак на NTP-сервере Mobatime используются алгоритмы фильтрации входящего трафика. Такой механизм защиты позволяет отсечь лавинообразный поток "мусора", способный привести систему к полному отказу за короткое время.
Тем не менее, подобная защита станет практически бесполезной, в случае, если объем данных в канале передачи приблизится к его пропускной способности. При такой нагрузке отправка данных легитимным, незаблокированным клиентам станет просто невозможной из-за исчерпания ресурсов каналов связи. Единственным выходом из ситуации, гарантирующим почти полное исключение случаев NTP-вандализма, пожалуй, является создание непубличного сервера точного времени с ограничением доступа. Имея в своём распоряжении надёжный источник времени (например, приёмник данных, передаваемых системой GPS), такой NTP-сервер будет являться стабильным поставщиком сервиса точного времени.
Список материалов, использовавшихся при подготовке публикации (на английском языке):
- RFC 4330, описание протокола SNTP v4
- Flawed Routers Flood University of Wisconsin Internet Time Server - отчёт о инциденте в университете Мэдисона, опубликованный его сотрудником Dave Plonka.
- Network Devices Almost Take Down Atomic Clock - статья о инциденте в CSIRO
- When firmware attacks! (DDoS by D-Link) - статья Ричарда Клейтона, принимавшего участие в выяснении обстоятельств атаки на NTP-сервер Пола-Хёнинга Кампа
- Материалы веб-сайта организации pool.ntp.org
- Help save the endangered time servers - статья Энди Лестера о pool.ntp.org
Я не знаю! Я просто хочу,чтобы у меня не сбивалось время! Подскажите,пожалуйста,что делать?
Может быть, правильно выставить часовой пояс и вовремя получать обновления (в том числе, касающиеся времени)? Ну и батарейку на маме поменять, если старая... на всякий...
научиться задавать вопросы.
До вопроса дело так и не дошло:D
NTP использует для своей работы протокол UDP . Система NTP чрезвычайно устойчива к изменениям латентности среды передачи .
NTP использует алгоритм Марзулло (предложен Кейтом Марзулло (Keith Marzullo) из Университета Калифорнии, Сан-Диего), включая такую особенность, как учёт времени передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет , и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей.
NTP - один из старейших используемых протоколов. NTP разработан Дэвидом Л. Миллсом (David L. Mills) из университета Дэлавера в 1985 году и в настоящее время продолжает совершенствоваться. Текущая версия - NTP 4.
NTP использует иерархическую систему «часовых уровней» (stratum). Уровень 1 синхронизирован с высокоточными часами, например, с системой GPS , ГЛОНАСС (Единая Государственная шкала времени РФ) или атомным эталоном времени. Уровень 2 синхронизируется с одной из машин уровня 1, и так далее.
Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 −32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 50 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учётом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.
Наиболее широкое применение протокол NTP находит для реализации серверов точного времени. Для достижения максимальной точности предпочтительна постоянная работа программного обеспечения NTP в режиме системной службы . В семействе операционных систем Microsoft Windows , - это служба W32Time (модуль w32time.dll, выполняющийся в svchost.exe), Linux - сервис Ntpd .
Более простая реализация этого алгоритма известна как SNTP - простой синхронизирующий сетевой протокол. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени.
Подробная реализация протокола и системы в целом описана в:
NTP не следует путать с daytime protocol RFC 867 или time protocol RFC 868 (win программа FG Time Sync).
Часовые слои
NTP использует иерархическую, многоуровневую систему источников времени. Каждый уровень этой иерархии называется слоем, каждому слою присваивается номер, начиная с 0 (ноль) в верхней части. Уровень слоя определяет расстояние от эталонных часов и существует, чтобы предотвратить циклические зависимости в иерархии. Важно отметить, что слой не является показателем качества и надежности, это значит, что источник слоя 3 может дать сигнал более высокого качества, чем некоторые источники слоя 2 . В основном, слои служат для распределения нагрузки и обеспечения большей площади покрытия. Это определение слоя также отличается от понятия часовых слоёв, используемых в телекоммуникационных системах.
Слой 0
Слой 0 - это высокоточные приборы служащие эталоном времени, такие как атомные (молекулярные, квантовые) часы , радиочасы или их аналоги. Обычно эти устройства не подключены к сети; вместо этого они подключены к локальному компьютеру (например, через интерфейс RS-232) и передают сигналы PPS для синхронизации.
Слой 1
Это компьютер, к которому напрямую подключены эталонные часы. Он выступает в качестве сетевого сервера времени и отвечает на NTP-запросы посылаемые компьютерами слоя 2.
Слой 2
Это компьютеры, которые получают время от серверов первого слоя, используя для этого протокол NTP. Обычно, компьютеры второго слоя обращаются к нескольким серверам первого слоя, и используя NTP-алгоритм, получают наилучший образец данных, отсеивая сервера с очевидно неверным временем. Компьютеры могут сравнивать свои данные с другими компьютерами своего слоя для получения стабильных и непротиворечивых данных на всех компьютерах слоя. Компьютеры второго слоя в свою очередь выступают в качестве серверов для компьютеров третьего слоя и отвечают на NTP-запросы.
Слой 3
Компьютеры третьего слоя работают точно так же как и компьютеры второго слоя, с той лишь разницей, что серверами для них являются компьютеры вышележащего второго слоя. Они так же могут выступать в качестве серверов для нижележащего слоя. NTP (в зависимости от версии) поддерживает до 256 слоев.
См. также
Ссылки
- - список серверов NTP Государственного эталона времени и частоты (ГЭВЧ) Российской Федерации
- Network Time Protocol project - общественный проект по развитию протокола и служб NTP
- NTP Public Services Project - проект публичных серверов NTP и рабочей группы IETF по протоколу NTP
- pool.ntp.org - ресурс, представляющий большой виртуальный кластер NTP-серверов для миллионов пользователей. По состоянию на 29 декабря 2010 в pool.ntp.org зарегистрированно 2078 серверов. Есть возможность выбрать региональные сервера.
- ntp.mobatime.ru - с 2005 года публичный бесплатный NTP-сервер Mobatime первого стратума (Россия, Санкт-Петербург).
- time.bakulev.ru - публичный бесплатный NTP сервер первого стратума (Россия, Москва).
| Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP) | |
|---|---|
| Физический | |
| Канальный | |
| Сетевой | |
| Транспортный | |
| Сеансовый | |
| Представления | |
| Прикладной | |
| Другие прикладные | |
Wikimedia Foundation . 2010 .
Смотреть что такое "NTP" в других словарях:
NTP - is a three letter initialism which may stand for: Contents 1 Computing 2 Politics 3 Science 3.1 Chemistry 3.2 Medicin … Wikipedia
NTP - abbrev. normal temperature and air pressure: former term for STP * * * NTP abbr. normal temperature and pressure. * * * … Universalium
NTP - NTP, Abk. für Network Time Protocol … Universal-Lexikon
NTP - (Network Time Protocol) (Internet) protocol that schedules the computer s internal clock with the atomic clocks or radio clocks on the Internet … English contemporary dictionary
NTP - abbrev. normal temperature and air pressure: former term for STP … English World dictionary
NTP - Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
NTP
Ntp - Die Abkürzung NTP steht für: Network Time Protocol, ein Protokoll zur Zeitsynchronisation zwischen Computern Normal Temperature and Pressure, die englische Bezeichnung für die physikalischen Normalbedingungen Nukleosidtriphosphat in der… … Deutsch Wikipedia
NTP - Abbreviation for nucleoside 5′ triphosphate. * * * narcotic treatment program; National Toxicology Program; nitroprusside; nonthrombopenic purpura; normal temperature and pressure; 5´ nucleotidase; sodium nitroprusside * * * NTP abbr normal… … Medical dictionary
Ответы на вопросы
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. Остальные клиенты домена синхронизируют свои часы со временем на контроллере домена. Примерная архитектура отображена на схеме.
