В поисках потерянной микросекунды: как Интернет договаривается о времени

«Тот, кто осознаёт ценность времени, владеет миром» –
Леонардо да Винчи

Современный мир, технологии, которые нас окружают, смартфоны, ноутбуки, планшеты, устройства умного дома и множество всевозможных систем не могут обеспечить полноту и точность данных без точного времени. Однако эта задача, обычно остающаяся в тени, зачастую имеет свою специфику и решается не так просто. Во многих устройствах (например, в часах) используются кварцевые чипы, которые могут «убегать» на несколько секунд в день. Чтобы все системы работали как единое целое, им необходимо постоянно сверять свои часы с общим эталоном.
Всё начинается с физики. Эталонное время почти 60 лет измеряют по цезиевым атомным часам. Они основаны на квантовых переходах атомов. В основе большинства таких часов заложены колебания атома цезия-133, и это с 1967 года используется для определения секунды. Однако в настоящее время существуют оптические атомные часы, которые в 100 раз точнее цезиевых.
Такие часы обеспечивают сверхвысокую точность (например, за 100 миллионов лет они «убегут» меньше, чем на одну секунду), но чтобы построить такие часы, требуются огромные и дорогие установки, поэтому, как правило, эти часы размещаются в научных центрах и лабораториях.

уровень 0 (Stratum 0) – это, как правило, атомные часы или спутники с атомными часами. Они отсутствуют в Интернете;
уровень 1 (Stratum 1) – серверы, обеспечивающие высокую доступность и зачастую спроектированные с учётом высокой нагрузки. Они получают время от нулевого уровня и раздают по сети время дальше. Это самые авторитетные источники времени в сети;
уровень 2 и больше – обычные серверы компаний. Чем выше цифра уровня – тем дальше мы находимся от первоисточника, но для бытовых нужд такой точности более чем достаточно.

Stratum NTP – это не фиксированная настройка, а динамический показатель удалённости от атомных часов. Каждый сервер определяет свой уровень на основе простого правила: уровень выбранного им источника сигнала +1. У серверов, как правило, несколько источников сигнала с разными уровнями — и важно понимать, что уровень может расти, если один источник испортился или вообще исчез для данного сервера, что привело к использованию другого источника. Этот уровень позволяет конечным системам ориентироваться на точность получаемых часов при выборе сервера.

«Человек, имеющий одни часы, твёрдо знает, имеющий несколько часов, ни в чём не уверен» – Закон Сегала

В Интернете существует огромное количество серверов времени, но зачастую не все из них работают идеально. Чтобы конечное устройство работало корректно, применяется алгоритмический отбор достоверных источников. Протокол NTP ведет себя как следователь – опрашивает сразу несколько источников, убирает те, что выдают явные ошибки или имеют большую задержку, и считает среднее арифметическое. Если какой-то из серверов внезапно начнет выдавать ошибочное время – его данные проигнорируют.
Зачастую при настройке устройств требуется указать часовой пояс (TimeZone). При этом все программы и серверы живут по единому стандарту UTC (Всемирное координированное время), а уже пользовательское устройство определяет, где вы находитесь, и в зависимости от места показывает вам эти часы с учётом TimeZone. Это позволяет избежать хаоса при обмене данными между устройствами на разных континентах.

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

Давайте представим себе ситуацию, что на сервере популярного маркетплейса внезапно часы отстали на сутки. Для обывателя это превратится в настоящую проблему:
«Ваше интернет-соединение не защищено». Браузер заблокирует вход, так как SSL-сертификат имеет срок валидности. Может так случиться, что сертификат ещё не начал действовать или уже «протух».
«Несуществующие скидки». Маркетплейс может показать товары по акциям, которые уже закончились, и не показать те, которые начались.
«Платёж не прошёл». Банки могут отклонять транзакции, так как одноразовые пароли (OTP) привязаны к точному времени. Если время в системах не совпадает – код будет не валиден и платежи не пройдут. Это лишь малый пример того, что может произойти, если собьётся время на критичном ресурсе.

«Человек, который осмеливается потратить впустую час времени, ещё не осознал цену жизни» – Чарльз Дарвин

Точное время — это, по сути, возможность соединить всю инфраструктуру воедино. Сетевые устройства, использующие динамические протоколы маршрутизации, такие как BGP4, казалось бы, напрямую не используют точное время для выбора маршрутов, но для защиты от перехвата трафика BGP Hijacking всё чаще используется RPKI (Resource Public Key Infrastructure) – система цифровых сертификатов, подтверждающая право владельца автономной системы на анонсирование IP-адресов. Для проверки валидности маршрутов проверяется сертификат ROA (Route Origin Authorization), который имеет срок действия, и если время на системе некорректно, то маршрут может стать не валидным, и трафик через узел не пойдёт.
Современные серверные системы зачастую имеют распределённую инфраструктуру для повышения надёжности и резервируемости. Именно для них особый статус имеет точное время. Например, распределённые системы хранения данных не смогут собрать корректно работающий кластер без точных синхронизированных часов. В распределённых базах данных могут возникать проблемы конфликтов записи. Давайте рассмотрим ситуацию: пользователи в разных городах редактируют один и тот же документ. Пользователь в Москве внёс правку в 11:00:01, а пользователь во Владивостоке — в 11:00:03. Если сервер во Владивостоке спешит на 5 секунд,
то он примет правку от пользователя со временем 10:59:58. При синхронизации баз данных с Москвой может оказаться, что система примет правку из Владивостока раньше, чем правку из Москвы — и правки пользователя во Владивостоке исчезнут, так как будут записаны поверх правки из Москвы.
Проблема со временем может затронуть и целостность кешей на серверах. Вот простой пример:
Вы сменили свой пароль, информация об этом поступила на главный сервер, однако вторичный сервер (кеш) проверяет и сравнивает время жизни (TTL) своей копии с текущим временем. Если часы отстают, то он будет считать, что старый пароль ещё свежий и годен, что не даст вам возможности зайти на эту систему.
В иерархической системе доменных имён DNS время играет роль срока годности. Это критично для работы DNSSEC (Domain Name System Security Extensions, RFC 9364) – набора расширений, которые защищают DNS от подмены данных.
Для подтверждения подлинности ответов в DNSSEC используются цифровые подписи RRSIG (Resource Recode Signature). Каждая такая подпись имеет фиксированные метки начала и окончания действия (Validity Period). Если системное время на сервере или клиенте выйдет за эти рамки, подпись будет признана невалидной, проверка безопасности будет провалена, а домен станет недоступным для пользователя.
Также сбои часов могут вызвать проблемы с интерпретацией TTL в DNS, что ведёт к преждевременному удалению записей из кеша или их некорректному обновлению. У каждой записи DNS есть свой TTL (время жизни записи, в течение которого она считается верной). Если вы переехали на новый сервер и обновили IP-адрес сайта, а на кеширующем сервере провайдера часы отстали, то он может продолжать отдавать старую запись, несмотря на то, что она должна была уже «протухнуть».
Часы крайне важны для своевременного и грамотного анализа событий в сети. Для правильной корреляции различных событий необходимо, чтобы время совпадало, иначе логи (сетевые журналы) будут показывать неправильный порядок событий, и их будет невозможно анализировать. Это же касается и событий систем мониторинга. Системы визуализации типа Grafana рисуют графики на основе меток времени. При рассинхронизации графики «уплывут», и данные наложатся друг на друга или возникнут временные промежутки. Ошибки во времени могут приводить к дырам в мониторингах уровня сервиса и проблемам с дальнейшим анализом. Для оперативного контроля состояния сети используется BMP (BGP Monitoring Protocol, RFC 7854) – протокол, который в реальном времени транслирует данные о состоянии BGP-маршрутов с роутеров на серверы мониторинга. Однако при его работе критически важна синхронизация: если BMP-события приходят с некорректными временными метками, системы автоматизации и управления могут ошибочно решить, что информация устарела, и проигнорировать важные обновления.
Когда на маршрутизаторах сбито время, анализ инцидентов (например, DDoS-атак) превращается в детектив, где все улики перепутаны, а свидетели указывают разное время и даты. В контексте анализа трафика (Netflow) это критичная проблема. Если на маршрутизаторе часы уходят вперёд, то Flow-коллектор получит данные об атаке, которая случилась в будущем. В итоге система мониторинга не сможет сопоставить этот всплеск трафика с реальным временем, и инженеры не смогут корректно проанализировать и составить корреляцию с событиями на других системах. Аналитики видят рваный график и не могут понять реальную мощность DDoS-атаки, так как данные могут размазаться по разным интервалам. Сбой часов может негативно повлиять и на работу BGP FlowSpec (BGP Flow Specification, RFC5575). Этот механизм позволяет динамически передавать на роутеры правила фильтрации трафика (по портам, протоколам или размерам пакетов), работая в связке с системами защиты от DDoS. Аномалия в статистике приводит к формированию FlowSpec-правил DDoS-защиты для маршрутизаторов, что позволяет оперативно блокировать вредоносный трафик на определённое время. Если часы на роутере и системе защиты не совпадают, то блокировка может закончиться раньше времени или затянуться на часы, блокируя легитимный трафик.
В системном администрировании часы тоже играют ключевую роль. Помимо корреляции с другими устройствами, часто запускаются различные события по Cron, что может приводить к непредсказуемым последствиям. Например, сервер собирает логи с устройств, и он запускает ротацию логов и удаление старых данных раньше положенного времени.
В итоге ценная информация может быть утеряна. На ряде серверов к сбоям может приводить повышенная нагрузка на систему в те моменты времени, когда она не ожидается. Например, большинство системных архивных процессов проходит ночью, при малой нагрузке, а если время смещено на несколько часов, то эти события могут произойти в разгар рабочего дня и привести к существенным проблемам.

«Точность — вежливость королей» – Людовик XVIII

Мы уже разобрались, что время передаётся по иерархической модели (стратум), но кто именно владеет этими серверами и как конечное устройство находит путь к атомным часам?

Самый известный проект в этой области – NTP Pool Project (pool.ntp.org). Это система контроля, мониторинга, связи мирового кластера NTP-серверов в единый каталог, который поддерживается сообществом волонтёров по всему миру.
Как это работает: вместо того, чтобы миллиарды устройств обращались к одному конкретному серверу (который может и не справиться с нагрузкой), запрос отправляется на DNS-адрес вроде 0.pool.ntp.org или ru.pool.ntp.org для устройств из РФ. Система сама выбирает серверы из пула и отдает их IP-адреса для доступа по протоколу NTP.
Этим пулом пользуются почти все дистрибутивы Unix, домашние роутеры, умные гаджеты, смартфоны. Это абсолютно бесплатно и доступно, но никто не даст 100% гарантии точности и корректности работы сервера. Справедливости ради отметим, что если сервер начинает отдавать некорректные данные, то через некоторое время pool.ntp.org это замечает и исключает его из выдаваемого списка.
Крупные компании не полагаются на публичные доступные серверы. Они, как правило, строят свои собственные системы точного времени. Основная цель обусловлена не только недоверием к публичным ресурсам, но и содержанием внутри своей инфраструктуры единого центра времени, который не создаст внутри проблем с синхронизацией данных. Схожая картина и у финансовых компаний, где зачастую требуется сверхвысокая точность часов с целью участия в биржевых сделках.
В последнее время с появлением облачных решений возникла новая модель — TaaS (Time as a Service). Пользователям в облаке зачастую не нужно ходить в Интернет за временем, если его можно раздать внутри прямо в облаке.
Если говорить о российском сегменте Интернета, то одним из часто используемых является MSK-IX NTP Server. Это не просто очередной сервер в сети, а распределённая инфраструктура по технологии Anycast для раздачи точного времени, результат работы многоуровневой иерархической системы технических средств. Ключевыми особенностями этого решения является резервируемость, синхронизация со спутниковыми группировками ГЛОНАСС и географическое распределение (Москва, Санкт-Петербург, Новосибирск, Екатеринбург). Это обеспечивает минимальные задержки для пользователей в разных частях страны, а также даёт возможность участникам MSK-IX получать данные сервера с минимальной сетевой задержкой. NTP-сервис в сети MSK-IX эксплуатируется уже более 15 лет. Многие тезисы этой статьи являются результатом этого опыта.

«Каждая секунда имеет бесконечную ценность» – Иоганн Вольфганг Гёте

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

Рассмотрим два ключевых протокола – NTP и SNTP. Хотя оба протокола используют один и тот же формат пакетов UDP и работают на 123 порту, между ними есть принципиальная разница в логике.
NTP (Network Time Protocol) – это полноценный аналитический протокол. Он опрашивает несколько серверов, анализирует сетевые задержки, отсеивает «лживые» источники и плавно подстраивает ход системных часов. NTP умеет компенсировать дрейф кварцевого резонатора конечного устройства, даже если связь временно пропала.
SNTP (Simple NTP) – это упрощённая версия для ленивых устройств (устройств Интернета вещей, дешёвых камер, микроконтроллеров). Он не делает сложных вычислений, а просто запрашивает время у одного сервера и выдаёт результат. Очевидный минус заключается в том, что если пакет задержится или сервер ошибётся, то SNTP примет некорректное время.
Очевидна область применения этих протоколов. Для серверов и критичных систем нужен полноценный NTP, а для бытовых устройств, Интернета вещей достаточно SNTP.
За счёт чего же обеспечивается точность часов при использовании NTP? Магия протокола заключается в том, что он не просто принимает на веру пришедшее время, а вычисляет, сколько секунд пакет проходил через Интернет. Для этого протокол использует математическую формулу:

Когда клиент (устройство) запрашивает время у сервера, фиксируются четыре временных метки:

T1 – время на устройстве в момент отправки запроса;
T2 – время сервера при получении запроса;
T3 — время сервера в момент отправки ответа;
T4 – время получения ответа клиентским устройством.

Далее клиент считает две величины: RTT и Offset по формулам:

RTT = (T4 – T1) — (T3 — T2)

Это время, которое пакет провёл в сети, исключая время, пока сервер готовил ответ.
Offset = ((T2 – T1) + (T3 – T4))/2

Это разница между часами клиента и часами сервера.

Учитывая, что задержки на сети могут варьироваться, применяется алгоритм Марзулло, благодаря которому делается серия запросов и выбираются те, где задержка была минимальной и самой стабильной. Дополнительно накапливается статистика – отбрасываются пакеты, которые слишком надолго задержались в пути, и строится средневзвешенное значение.
Когда точности в миллисекунды (как у NTP) становится мало, используется протокол PTPv2 (Precision Time Protocol, стандарт IEEE 1588). Этот протокол появился из мира промышленной автоматизации и систем телефонии. PTP использует аппаратные метки времени. Пакет помечается на аппаратном уровне прямо сетевым чипом устройства перед выходом в сеть. Ключевое отличие от NTP заключается в высокой точности протокола. Если NTP дает точность 1-50 мс, то PTP позволяет добиться наносекундной точности. Однако для PTP требуется специальное сетевое оборудование (коммутаторы и сетевые карты), которые умеют обрабатывать такие пакеты с приоритетом. Кроме оборудования необходимо ещё учитывать и профили PTP, которые применяются для различных отраслей и классов устройств – таких как энергетика, радиовещание, автоматизация, телекоммуникации. Одно из ключевых отличий в этих протоколах – специфика всех промежуточных устройств, а не только конечного оборудования. Для PTP необходима поддержка протокола всеми промежуточными устройствами, что делает этот протокол узкоспециализированным и не позволяет широко распространять по сети.
В PTP-протоколе используется сообщение Sync, которое, по сути, является сердцем прокола PTP. В отличие от NTP, этот протокол начинает работу с рассылкой сообщения Sync от Master-часов. Дочерние устройства получают пакет Sync, фиксируют время прихода и, сравнивая его с меткой внутри пакета, вычисляют задержку с точностью до наносекунд.
Разумный компромисс в современных реалиях: применение NTP везде, а PTP — там, где есть особые запросы. Этот гибридный подход позволяет закрыть основные требования по времени для большинства устройств Интернета и создать особые условия для проектов, которым требуется высокая точность – таким как финансовые биржи, энергетические подстанции, вышки сотовой связи 5G.

«Время — сотворенная вещь. Сказать: «У меня нет времени» — все-равно что сказать: «Я не хочу» — китайский философ Лао-цзы

Выбор режима работы NTP – это не просто настройка конфигурационного файла, а проектирование надёжности сети. В зависимости от поставленной задачи инженер выбирает один из четырёх основных методов.

1. Клиент-Сервер (Unicast)

Самый распространённый и очевидный режим. Клиентское устройство инициирует запрос к конкретному IP-адресу сервера или пулу адресов сервера. Идеально подходит для связи через Интернет между разными сегментами сети.
Плюсом здесь является максимальная точность, так как NTP вычисляет задержку индивидуально для конкретной пары клиент-сервер. Однако есть и минус – если у вас в сети 100 тысяч клиентов, то каждый будет отсылать запросы, создавая лишний трафик.

2. Симметричный активный/пассивный режим (Peering) (устаревший)

Этот режим ранее использовался для связи между серверами одного уровня (например, между Stratum 1). Ключевое отличие этого режима от других заключено в том, что серверы обмениваются данными о своём состоянии на одном уровне. Если один из серверов потеряет связь с атомными часами (спутником), он сможет брать время у соседа по пирингу. Плюсом здесь является высокая отказоустойчивость инфраструктуры. Однако в последние годы после появления атак типа NTP DDoS Amplification от этого режима было решено отказаться в пользу модели клиент-сервер, так как протокол NTP использует UDP, и злоумышленники могут подделать адреса пиров и вынудить сервер отправлять огромное количество пакетов жертве.

3. Broadcast/Multicast в локальных сегментах

Режим для экономных и ленивых администраторов. Сервер раз в несколько секунд сообщает в локальную сеть точное время, а клиенты просто слушают эфир и подстраивают часы по этим объявлениям. Плюсом тут является минимум трафика – одним пакетом можно обслужить сколь угодно много устройств в одном сетевом сегменте. Из минусов — низкая точность, так как нет возможности точно вычислить задержку передачи по сети, и поэтому погрешность чуть выше. Ну и ключевой недостаток – это вопрос информационной безопасности: можно поднять поддельный NTP-сервер, выдать с него некорректное время и сломать всю сеть.

4. Anycast NTP

Это современное решение, на базе которого построены современные публичные высоконагруженные NTP-серверы. Как и в типовом Anycast, настраивается несколько географически распределённых серверов (например, в Москве, Санкт-Петербурге, Екатеринбурге, Новосибирске) с единым публичным адресом. Далее протокол динамической маршрутизации направляет входящие пакеты от клиентов в сторону доступного сервера. Так работает и наш ntp.msk-ix.ru. Достоинство такой модели в том, что получается высокая отказоустойчивость и масштабирование сервиса. Помним, что серверы размещаются на точках обмена трафиком, и таким образом обеспечивается минимальная задержка для участников платформы обмена, что положительно сказывается на точности определения времени.
Протоколу NTP уже больше 40 лет, и конечно, за эти годы протокол претерпевал изменения. Протокол использует UDP, и поэтому он оказался уязвим для различного вида атак. В течение последних нескольких лет выходили расширения протокола с целью закрыть возможные уязвимости, но многие из них оказались сложны в настройке и не были приняты сообществом. Ключевыми в публичном пространстве остались две технологии: клиент-сервер и anycast.
Точность в NTP – это не только качество атомных часов, но и умение протокола выживать в условиях зашумлённой среды передачи данных.
В стандартной реализации NTP использует программные метки времени (software timestamping). Пакет, содержащий метку, проходит через драйверы сетевой карты, стоит в очереди прерываний процессора и только потом попадает к приложению NTP.
Пока процессор занят другими задачами, проходит несколько микросекунд (возможно миллисекунд). Информации об этой задержке у NTP нет, и он считает, что пакет шёл дольше по сети, чем на самом деле. Из-за этих погрешностей внутри операционной системы NTP редко даёт точность выше 1-10 мс. Для анализа логов это вполне достаточно, но, например, для синхронизации электрооборудования этого может быть недостаточно.
Протокол NTP оптимистичен. Он считает, что пакет идёт до сервера столько же времени, сколько идёт обратно. Однако очень часто в сети бывает асимметричная маршрутизация, что может приводить к разному времени приёма-передачи пакетов. В этом случае входящий пакет приходит через одного провайдера, а ответ может идти по совершенно другому маршруту. Дополнительным фактором задержек могут служить перегрузки на каком-нибудь из элементов цепи передачи данных. В итоге NTP увидит, что RTT (Round Trip Time) вырос, поделит задержку пополам и неправильно вычислит смещение времени (offset). Например, путь для входящего пакета занял 10 мс, а обратный — 100 мс, NTP посчитает, что часы на сервере спешат на 45 мс. В итоге, корректировка времени будет с ошибкой. По сути, асимметричный роутинг – это один из главных врагов протокола.
Рассмотрим алгоритм фильтрации, или как NTP выявляет «лжецов»? В отличие от протокола PTP (IEEE 1588), который выбирает лучшего мастера (Best Master Clock Algorithm) и безоговорочно ему доверяет, NTP полагается на статистический анализ:

NTP собирает выборку измерений и отсеивает результаты с аномальной дисперсией.

Также применяется алгоритм пересечения (Intersection Algorithm). Если в конфигурации присутствуют несколько серверов и один, например, утверждает, что сейчас 12:00, а три других говорят – что 12:05, то NTP пометит первый сервер как falseticker (неточный сервер) и исключит его из расчёта, даже если его Stratum высокий. Это помогает NTP быть устойчивым к сбоям отдельных узлов, в то время как PTP более уязвим к ошибке одного выбранного мастера. Поэтому NTP оказывается гораздо более живучим в хаосе мирового Интернета.
Для сетевого инженера критически важно не только настроить синхронизацию времени, но и иметь инструменты для проверки точности и стабильности. Ошибки NTP часто бывают малозаметными: процесс запущен, но время постепенно деградирует из-за сетевых задержек или отказа тех или иных источников.
Для проверки применяются, как правило, утилиты командной строки Unix: ntpq, ntpdate. Это, по сути, базовый набор инструментов, доступный практически в любой Unix-системе.

Ntpq (NTP Query): ключевой инструмент мониторинга работающего процесса. Команда ntpq -p (peers) выводит табличку:

$ ntpq -p

remote refid st t when poll reach delay offset jitter

================================================================

*ntp.ix.ru. GLN. 1 u 14 64 17 1.303 +0.222 0.038
time.cloudflare .INIT. 16 u 64 — 0 0.000 +0.000 0.000
+ntp2.vniiftri.r .FTRI. 1 u 16 64 17 4.283 +0.503 0.166

Этот вывод – пример стабилизации системы после недавнего запуска. Для сетевого инженера тут есть несколько важных маркеров:

1. Состояние разогрева (reach 17). Значение reach 17 в восьмеричной системе соответствует 00010001. Это значит, что было получено два успешных ответа, но между ними был пропуск (запрос не ушёл или ответ потерялся). Система работает несколько минут. До полной достоверности (когда reach станет 377) алгоритм продолжает набирать статистику, чтобы отфильтровать сбойные серверы.
2. Идеальный jitter (0.038). У ntp.ix.ru jitter 0,038 (38 микросекунд) – это великолепный показатель для NTP, говорит о том, что канал до MSK-IX стабилен, нет очередей и заторов. Именно такой низкий jitter позволил выбрать ix.ru основным (*), несмотря на то, что reach ещё не полный.
3. Смещение (offset +0.222 vs +0.503). ntp.ix.ru считает, что наши часы отстают на 0,222 мс, в то время как ntp2.vniiftri.ru считает, что отстают сильнее – на 0,503 мс. Разница около 280 микросекунд. Для синхронизации через Интернет это ничтожно малая величина, которая подтверждает, что оба источника надёжны.
4. Проблема с Cloudflare (.INIT./Stratum 16). Сервер time.cloudflare находится в состоянии «INIT: Stratum 16» — по сути, недостижимость. Для NTP этот сервер не существует. Вероятные причины — в блокировке доступа к этому серверу.
В итоге система выбрала ntp.ix.ru в качестве мастера из-за кратчайшей задержки (1,3 мс) и идеальной стабильности сигнала. Сервер ВНИИФТРИ выступает в роли «запасного игрока» (знак «+»), готового подхватить синхронизацию в любой момент.
Кроме типового процесса ntpd возможно построить синхронизацию с помощью chronyc (Chrony). Chronyc лучше справляется с мониторингом в условиях нестабильных соединений, и с помощью ряда опций можно получать консолидированный отчёт о состоянии системы. Например, с помощью команды chronyc sources -v можно получить более детальное представление о погрешности (ошибки измерения):

$ chronyc sources -v

210 Number of sources = 3
.— Source mode ‘^’ = server, ‘=’ = peer, ‘#’ = local clock.
.— Source state ‘*’ = current synced, ‘+’ = combined, ‘-’ = not combined,
‘?’ = unreachable, ‘x’ = time may be error, ‘~’ = time too variable.
.- xxxx [ [delta] ] +/- [err]
Name/IP address Stratum Poll Reach LastRx Last sample
==========================================================
^* ntp.ix.ru 1 6 17 14 +222us[+222us]+/-150us
^? time.cloudflare 16 6 0 — +0ns[+0ns]+/-0ns
^+ ntp2.vniiftri.ru 1 6 17 16 +503us[+503us]+/-450us

Тут сразу видно статус Cloudflare (знак вопроса – говорит об отсутствии ответов от сервера), видно смещение в микросекундах (+222us) и доверительный интервал (+- 150us). По сути, киллер-фича Chrony, показывающая погрешность измерения, где видно, что ntp.ix.ru имеет малую погрешность и высокую достоверность, в отличие от ntp2.vniiftri.ru, что обусловлено сетевыми задержками. В квадратных скобках отражается отклонение от предыдущего измерения.

Кроме Ntpd и Chrony системные администраторы часто применяют NTPsec. По сути, это глубоко переработанная реализация классического Ntpd, из которого удалено огромное количество строк устаревшего кода и добавлен новый функционал. Ключевое преимущество NTPsec – поддержка стандарта NTS (Network Time Security, RFC 8915). Это достаточно современный протокол (2020 год), использует TLS для первоначального обмена ключами и эффективно противодействует спуфингу, атакам типа отказ в обслуживании через усиление (Amplification) и перехвату данных (MITM), хотя он всё ещё недостаточно широко распространён в массовых системах и сервисах. Сетевым инженерам важно учитывать, что для реализации NTS потребуется дополнительно разрешать трафик по TCP-порту 4460 (NTS Key Establishment) для аутентификации, кроме стандартного UDP 123 для NTP.
Кроме команд анализа состояния NTP-сервиса часто применяются команды для разовой синхронизации. Много лет во FreeBSD, например, использовалась команда ntpdate, которая и сейчас весьма популярна, однако в современных системах она считается устаревшей и заменяется на ntp -gq, но в скриптах эта команда по-прежнему ещё фигурирует.

Когда парк серверов исчисляется сотнями, то ручной проверки через CLI явно недостаточно, поэтому применяются комплексные решения, такие как Zabbix/Prometheus + Exporters. Данные из NTP-демонов собираются экспортёрами. Это позволяет строить графики смещения времени (offset) в динамике. Резкий скачок offset на графике может сигнализировать о проблемах с маршрутизацией и перегрузкой канала. Для глубокого анализа логов полезен инструмент ntpviz. Он генерирует графические отчёты, где можно визуализировать стабильность локального осциллятора и точность внешних серверов за длительный период. Это очень полезно для тонкой настройки серверов Stratum 1.

Вообще, интересен факт, что для сетевого инженера мониторинг NTP через Zabbix это классическая проблема «курицы и яйца». Если время «убежит» на самом сервере мониторинга, он может перестать адекватно оценивать состояние всей сети. Zabbix-сервер и целевые узлы могут синхронизироваться от одного и того же неисправного источника времени, который может начать «врать», и в этом случае Zabbix может не увидеть проблему, так как offset между ним и целевыми узлами будет близок к нулю, хотя все системы будут показывать отстающее время. Чтобы такого избежать, необходимо анализировать не только разницу во времени, но и внутренние параметры на каждом узле (ntp discovery, stratum, max jitter, root dispersion). Для выхода из замкнутого круга опытные инженеры настраивают Zabbix на синхронизацию с независимым от остальной сети источником.

Завершающим инструментом в арсенале сетевого инженера является глубокий анализ пакетов. Ntpd и Chronyc показывают результат алгоритма, в то время как Wireshark позволяет увидеть сам процесс обмена данными и найти скрытые аномалии. Зачастую это полезно, когда консольные утилиты показывают статус REJECT или INIT или имеются проблемы с сетевыми задержками. Wireshark позволяет увидеть и проблему аутентификации (если используются ключи, которые не совпадают), в то время как NTP может молча игнорировать пакеты. Также Wireshark позволяет вычислить время обработки пакета внутри самого сервера, что позволяет проводить более точную диагностику и отделить проблему сети от проблемы самого сервера.
Ещё одним немаловажным подспорьем для системного администратора является анализ поля Leap Indicator (LI) в Wireshark. Это поле позволяет увидеть, когда вышестоящий сервер потерял связь со своими эталонами и его время стало недостоверным. В то время как NTP просто отбросит такой сервер, Wireshark покажет, что сервер отвечает, но время его не достоверно.
Безусловно, анализатор необходим для обнаружения DDoS-атак. Это тема отдельной и большой дискуссии. В качестве примера можно посмотреть, когда Wireshark показывает огромное количество мелких запросов monlist с одного IP. Это явный признак того, что сервер пытаются использовать для DDoS Amplification атаки на другие системы.

«Малая ошибка в начале становится большой в конце» – Фома Аквинский, «О сущем и сущности»

На практике довольно часто бывают ситуации, связанные не только с атаками на NTP-серверы, но и с ошибками конфигурации. Хотелось бы рассмотреть один интересный случай, с которым нам довелось столкнуться чуть больше года назад. Этот случай вошёл в историю как пример того, что бывает, когда масштабируемость облачного сервиса сталкивается с хрупкостью волонтёрского проекта. Один из производителей умных колонок во время создания своей системы не уделил должного внимания вопросу NTP, и в качестве серверов времени по умолчанию были прописаны адреса пула 0.ru.pool.ntp.org, 1.ru.pool.ntp.org. Количество устройств (и продаж) неуклонно росло и в какой-то момент перевалило за критическую массу. С нашей стороны (как администраторов NTP-серверов) это выглядело как планомерный рост нагрузки, который потребовал от нас умощнения систем, выстраивания новых NTP-узлов в Anycast NTP.IX.RU, так как нагрузка не была похожа на атаку. Главный враг NTP-сервера – это плохо написанный алгоритм повторов (Retry). Если колонка не получала ответ от сервера (из-за задержек в сети), она начинала слать запросы каждую секунду (или даже чаще). Миллионы устройств начинали одновременно стучаться в один и тот же список IP-адресов (адреса pool), и это выглядело как всплеск нагрузки. У многих участников NTP Pool сервис построен «на энтузиазме», зачастую серверы стоят в небольших ЦОДах или даже используют домашние каналы связи (!). Трафик вырос настолько, что участники ntp.pool.org стали выходить из проекта по разным причинам, что, в свою очередь, приводило к ещё большей нагрузке на оставшиеся системы. В итоге сообщество обнаружило причину проблемы, и специалисты обратились к производителю умных устройств за исправлением ситуации.
Как в итоге эту проблему можно решить? Обычно для вендоров, которые строят большие распределённые системы, рекомендуется использовать выделенную именную зону (vendor zone) в pool.ntp.org. Например, такие зоны есть у Ubuntu, FreeBSD, Amazon и т.д. Использование выделенных зон позволяет отделить трафик такого проекта от общего пула. Но в случае, описанном выше, производитель пошёл иным путем и сделал свои собственные адреса NTP. Дополнительно производитель переписал прошивку, добавив туда алгоритм Exponential Backoff, при котором устройство после неудачной попытки ждёт всё дольше и дольше, прежде чем спросить снова.
Какие выводы можно сделать из подобной ситуации? При построении подобных систем, где может быть миллион устройств, не используйте публичные ресурсы и всегда ограничивайте частоту запросов (poll), если сервер не отвечает.
Говоря о проблемах NTP, нельзя не затронуть несколько критических моментов, хотя это и тема для отдельной публикации. Если раньше главной проблемой сетевого инженера были перегруженные каналы, то сегодня на первый план выходят атаки на «физику» процесса – спутниковые сигналы, на которых часто держатся серверы Stratum 1.
Например, Jamming (заглушение сигнала), по сути, создаёт радиопомехи на частоте спутниковой навигации. Для инженера это выглядит как антенна, переставшая видеть спутники. В итоге сервер уходит в режим holdover и держится на внутреннем осцилляторе. Если на сервере нет дорогого рубидиевого чипа, то время может постепенно начать «уплывать», и сервер станет выдавать ошибку.
Гораздо опаснее выглядит Spoofing (подмена данных). В этом случае сервер видит искажённый сигнал и принимает его за основу. Это гораздо сложнее определить и требует вдумчивого подхода к мониторингу.
В целом, главный правильный подход к защите от подобных ситуаций – это построение резервируемой системы: георазнесение точек, использование нескольких антенн, задействование разных спутниковых группировок (GPS/GLONASS/BeiDoo) и наземных эталонов.
В заключение хотелось бы рассмотреть ещё две практические проблемы NTP. Проблема прыжка секунды (Leap Second) – это настоящий кошмар для баз данных, а вопрос часовых поясов часто путают с работой самого протокола.
Известно, что Земля вращается неравномерно, и когда разница между астрономическим и эталонным временем UTC приближается к одной секунде, Международная служба вращения Земли объявляет о добавлении «високосной секунды». Как это работает на практике: в пакете NTP есть поле Leap Indicator (LI). За сутки до этого события серверы Stratum 1 выставляют значение в Li=1. Когда наступает полночь, системные часы показывают 23:59:60 вместо 00:00:00. Это настоящий кошмар для программистов, который в прошлом приводил даже к падениям систем, а в базах данных возникает путаница в последовательности транзакций. В результате, чтобы не прыгать резко, крупные компании (Amazon, Google, Yandex) применяют leap smearing, когда они вместо прыжка в одну секунду замедляют ход NTP-серверов на миллисекунды. В результате процесс выглядит плавнее и лишняя секунда не так заметна.
Один из самых распространенных мифов: «NTP неправильно перевёл время на сервере». Однако хочется напомнить, что NTP всегда передает время в UTC и ничего не знает о часовых поясах. Эти изменения выполняются на самой системе. Кстати, многие, думаю, помнят, как в России отменили переход на летнее время. Это стало проблемой для целого ряда программного и аппаратного обеспечения, в которых этот переход уже был вшит заранее.
Что нас ждёт в будущем? В 2036 году протокол NTPv4 столкнётся с аналогом проблемы 2000 года (Rollover NTP Era 0). Формат времени в NTP представляет собой 64-битное число. Из них 32 бита отведены под целое количество секунд с начала эпохи (1 января 1900 года 00:00:00 UTC). Нетрудно подсчитать, что это количество секунд истечёт 7 февраля 2036 года. Хотя «Время Ч» наступит в 2036 году, подготовка и первые сбои ожидаются значительно раньше. Производители оборудования и ПО уже сейчас находятся у черты: устройства, выпускаемые сегодня, должны иметь запас эксплуатации 10-15 лет, а значит, обязаны уметь работать в новой эпохе «из коробки».

Для решения проблемы переполнения 32-битного счётчика NTP индустрия использует несколько подходов:

Переход на 64-битные метки. Это самое фундаментальное решение – расширение формата времени. В новых реализациях протокола под секунды отведено уже 64 бита (вместо 32), а под дробные доли секунды — ещё 64. Этого объёма хватит на время, сопоставимое с жизнью Вселенной, что навсегда снимет вопрос конца эпох.
Механизм эпох (Era Number). Это решение для сохранения совместимости со старыми системами. Вводится номер эпохи, и системы считают, что после достижения максимума счётчик обнуляется, но это уже эпоха 1. Однако это требует поддержки на уровне ОС, устройство должно понимать, что ноль на часах — это 2036 год, а не 1900-й.
Использование 64-битных типов данных внутри ОС. Современные ядра (Linux, BSD) перешли на 64-битное представление времени (time_t). Это позволит на уровне операционной системы корректно отрабатывать даты далеко за пределами 2036 года во внутренних вычислениях.
Метод коррекции. Некоторые системы могут считать, что если метка времени меньше определённого порога, то это уже следующая эпоха. Это, по сути, временная мера, позволяющая не потерять старые устройства после наступления новой эпохи.

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

Так откуда всё-таки берётся время в Интернете?

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

«У каждых часов своё точное время» ;))))

Список литературы:

[1] Mills D., Martin J., Burbank J., Kasch W.// Network Time Protocol Version 4: Protocol and Algorithms Specification // RFC 5905, Internet Engineering Task Force (IETF), 2010. URL: https://datatracker.ietf.org/
[2] IEEE Standard Association// IEEE 1588-2019 — IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Control Systems // IEEE, 2019. 499 p. URL: https://standards.ieee.org/
[3] Mills D.// Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI // RFC 4330, 2006. URL: https://datatracker.ietf.org/
[4] Mills D. L.// Network Time Synchronization: the Network Time Protocol on Earth and in Space, Second Edition // CRC Press, 2011. 495 p.
[5] Lichvar M. et al.// Chrony Documentation // Chrony Project, 2024.
URL: https://chrony-project.org/
[6] Sullivan N.// Roughtime: Securing Time with Digital Signatures //
Cloudflare Blog, 2018. URL: https://blog.cloudflare.com/roughtime/

Об авторе: