ВРЕМЯ и протокол сетевого времени

Джефф Хьюстон

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

Земное время

Использование шестидесятеричной системы счисления для обозначения секунд и минут восходит к древним шумерам в III тысячелетии до нашей эры. Этот подход к измерению времени переняли вавилоняне, затем греки, за ними древние римляне, а от них его унаследовали и мы с вами. В применяемой нами системе измерения мы делим время, которое требуется Земле для осуществления одного оборота вокруг своей оси, на 86 400 интервалов – секунд.
Шли века. Механические часы становились всё более совершенными, проделав путь от элементарных солнечных часов до водяных, песочных и огненных. Затем человечество переключилось на колебания маятника – появились маятниковые механизмы и регуляторы хода. Такие часы широко применялись в разных сферах жизни. Однако стимулом для существенного повышения точности измерения времени в XVIII веке стали практические потребности морской навигации, а именно расчёт координат местонахождения судна. В 1761 году появился морской хронометр Джона Гаррисона модели H4. За 81 день плавания погрешность хода этого механизма составила всего 216 секунд, или 2,6 секунды в день. Но процесс совершенствования механических хронометров на этом не остановился. Эти устройства ещё более века использовались для измерения времени вплоть до появления генератора колебаний с кварцевым резонатором в начале ХХ века.

Кварцевые генераторы характеризуются исключительной стабильностью. Если не подвергать их резким перепадам температуры, то погрешность кварцевых часов составляет менее полсекунды в сутки. Применение блока из нескольких генераторов, а также регулирование температуры цифрового счётчика позволяет ещё больше снизить погрешность часов – до менее 15 миллисекунд в день. Кварцевые часы использовались Национальным бюро стандартов США для установления стандартного времени с 1929 по 1960-е годы.

В своём стремлении добиться ещё большей точности в измерении времени мы стали опираться на колебания на уровне атомов. Погрешность колебаний изотопа цезий-133 составляет менее 2 наносекунд в день. Таким образом, атомные часы не только являются стандартом определения хода времени, но и выполняют функцию определения самого времени.

Следующая задача заключалась в том, чтобы соотнести такой точный метод измерения единицы времени со скоростью оборота планеты вокруг своей оси. В этом отношении добиться такого же уровня точности просто невозможно! Дело в том, что под влиянием вызванных Луной приливных сил скорость вращения Земли замедляется, так что продолжительность дня увеличивается за сто лет на 2,3 миллисекунды. Но дело не только в изменении скорости вращения Земли вокруг своей оси. Другим существенным фактором выступают периодические изменения климата и вызванные им ледниковые периоды. Свою роль играет и распределение континентальных плит на поверхности земли. Плиты подвижны, что сказывается на скорости вращения Земли. По мере повышения точности астрономических наблюдений и устройств измерения времени мы получили возможность измерять эти, хоть и совершенно небольшие, отклонения в угловой скорости.

Рис. 1. Динамика изменения продолжительности суток в секундах, Стив Аллен.

На рис. 1 приведены данные по годовым колебаниям продолжительности суток в миллисекундах с 1730 года.

Стандарты всемирного времени

Если скорость вращения Земли постоянно меняется, можно ли считать секунду постоянной величиной? Впервые этим вопросом задались астрономы, а затем физики.
В настоящее время всеобщим стандартом продолжительности секунды выступает определение Международного бюро мер и весов, согласно которому секунда в Международной системе единиц составляет по длительности 9 192 631 770 периодов излучения, которые соответствуют переходу между двумя сверхтонкими уровнями атома цезий-133 в состоянии покоя при температуре 0К– это называется «Международным атомным временем» (TAI, фр. Temps Atomique International).
Проблема заключается в том, чтобы соотнести такое определение времени со скоростью вращения Земли и другими доступными нашему восприятию феноменами. Существует несколько версий стандарта всемирного времени, но для целей измерения времени особый интерес представляют два стандарта.
UT1 – основная версия всемирного времени. По идее, UT1 представляет собой среднее солнечное время (среднее значение периода, когда Солнце находится на одном и том же уровне несколько дней подряд) на нулевой параллели, но точно измерить среднее солнечное время путём наблюдения за Солнцем представляется затруднительным. UT1 вычисляется пропорционально углу вращения Земли относительно квазаров согласно Международной небесной системе координат с использованием радиоинтерферометрии с длинными базами. Время UT1 определяется с точностью до 15 микросекунд.
UTC (всемирное координированное время) представляет собой атомную шкалу времени, которая связана с временем по UT1, но обеспечивает гораздо более высокую степень точности. Именно время по UTC стало международным стандартом для определения времени в гражданских целях. В UTC в качестве единицы времени используется секунда по Международной системе единиц, поэтому UTC идёт синхронно с международным атомным временем (TAI). Поскольку в основе UTC лежит международное атомное время, этот стандарт лишён непосредственной
привязки к скорости вращения Земли вокруг своей оси. Тем не менее, согласно UTC сутки также состоят из 86 400 стандартных секунд.

Дополнительные секунды

Итак, продолжительность суток при определении продолжительности на основе скорости вращения Земли вокруг своей оси представляет собой непостоянную величину. Как же соотнести этот показатель с равномерным ходом атомных часов, обусловленным излучением атома цезия? Можно отдать приоритет стандартным атомным часам, и тогда продолжительность суток будет составлять 86 400 стандартных секунд. В таком случае расхождение между стандартным атомным временем и временем, определённым в зависимости от скорости вращения Земли, может составить целый час за тысячу лет, если предположить, что скорость вращения Земли вокруг своей оси будет постепенно снижаться. Можно также периодически корректировать атомное время согласно UTC, чтобы синхронизировать его со скоростью вращения. Сделать это можно за счёт добавления так называемой дополнительной секунды или «секунды координации». Практика введения «дополнительных секунд» действует с 1972 года.
Службы времени пришли к соглашению о возможности добавить такую секунду в два определённых времени года, а именно в последнюю минуту июня и декабря каждого года с продлением последней минуты на 1 секунду. Такие дополнительные секунды добавляются ко времени по UTC по мере необходимости таким образом, чтобы отклонение UTC от UT1 не превышало 0,9 секунды. По состоянию на сегодняшний день, с 1972 года ко времени по UTC было добавлено 27 секунд. График добавления дополнительных секунд приведен на рис. 2.

Рис. 2. Добавление дополнительных секунд к всемирному координированному времени (UTC).

Возможно также вычитание секунд из времени по UTC в случае ускорения вращения Земли, чтобы, опять же, расхождение со временем по версии UT1 не превышало 0,9 секунды. Если наблюдаемая в настоящее время тенденция к ускорению скорости вращения планеты сохранится на протяжении следующих 40 лет, потребуется вычесть секунду из времени по версии UTC.
Введение дополнительных секунд приводит к повсеместным сбоям в работе информационных систем. Из-за введения дополнительной секунды 30 июня 2012 года вышли из строя несколько важных систем, включая программу бронирования и оформления билетов крупной авиакомпании. Компьютерной отрасли пришлось разработать специальное решение для того, чтобы предотвращать сбои, вызванные корректировкой времени на целую секунду. Эта секунда «размазывается», то есть заблаговременно добавляется по несколько миллисекунд за раз до запланированного срока добавления секунды корректировки. Однако это не решает саму проблему скачков в потоке времени.
Потратив несколько лет на изучение этого вопроса, Международный союз электросвязи (МСЭ) в 2015 году передал полномочия по дальнейшему использованию дополнительных секунд в пользу Генеральной конференции по мерам и весам; 18 ноября 2022 года в рамках Генеральной конференции по мерам и весам была принята резолюция о том, чтобы призвать МСЭ отказаться от практики добавления «секунд координации» с 2035 года. Предполагается, что этот отказ будет действовать как минимум 100 лет, хотя это решение может быть изменено по итогам дальнейших консультаций с другими международными ведомствами. Однако МСЭ сохранил за собой контроль над распространением сигнала точного времени по версии UTC и ещё может отказаться от исполнения принятой резолюции.

Передача времени

Как осуществляется синхронизация времени? Если у вас есть доступ к цезиевым часам, то это ваш источник точного времени. Вы также можете использовать водородный мазер или чуть более мобильные рубидиевые атомные часы. Ведутся активные исследования по возможности применения источников света на основе стронция и иттербия, которые позволяют на два порядка повысить точность измерения времени по сравнению с существующими моделями цезиевых атомных часов.
Эксплуатация источника атомных часов, в действительности, целого ряда источников, осуществляется Военно-морской обсерваторией США (https://www.cnmoc.usff.navy.mil/usno/). В её ведении находятся атомные часы, которые работают в условиях неизменной температуры и
влажности. Сигнал времени корректируется путём введения «дополнительных секунд» по графику, который раз в полугодие распространяется в Бюллетене «С» Международной службы вращения Земли (IERS, https://www.iers.org/). Есть аналогичные источники времени и в других
странах.
В случае с США сигнал UTC передаётся на космическую базу Шривер в Колорадо, которая, помимо прочего, управляет спутниковой группировкой, передающей сигнал времени для глобальной системы позиционирования (GPS).
В компьютерах с датчиком GPS можно обеспечить синхронизацию их внутренних часов по сигналу GPS.
С этого момента за установление времени в Интернете отвечает протокол сетевого времени (NTP).

Протокол сетевого времени

Если одни протоколы связи по IP появились сравнительно недавно, то другие уже имеют достаточно долгую и богатую историю, которую ведут со времён появления Интернета. Сеть ARPANET перешла на протокол TCP/IP в январе 1983 года, а с 1985 года в сети действует протокол сетевого времени. Некоторые даже утверждают, что NTP стал самым старым постоянно действующим распределённым приложением Интернета.
Цель протокола сетевого времени проста: дать возможность клиенту синхронизировать часы по времени UTC, обеспечив высокий уровень точности и стабильности. Протокол сетевого времени обеспечивает точность времени с погрешностью всего несколько миллисекунд в пределах глобальной вычислительной сети (WAN). Чем компактнее сеть, тем точнее работа протокола NTP. В рамках локальных вычислительных сетей (LAN) достигается точность с погрешностью менее миллисекунды, а при использовании таких высокоточных
источников времени, как приёмник сигнала GPS или цезиевые часы, погрешность не превышает микросекунду.
Если несколько клиентов используют протокол NTP, то они могут работать с синхронизированным сигналом времени. Одним из примеров применения протокола сетевого времени в сетевом контексте является единая модель данных, для которой изменение временных параметров данных имеет очень большое значение. (Я использовал протокол сетевого времени для обеспечения точности измерения времени до
микросекунды при комбинировании различных источников дискретных данных – например, веб-логов с сервера в сочетании с логом запросов системы доменных имён с использованием DNS-преобразователей и трассировки пакетов.)
Чтобы понять работу протокола NTP, нужно затронуть саму проблему измерения времени. В этой связи важно обозначить ряд терминов, связанных с этой тематикой.

Протокол сетевого времени создан для того, чтобы компьютер мог принимать в расчёт три основные показателя времени: отклонение внутренних часов от выбранных эталонных часов, двусторонняя задержка сетевого трафика между компьютером и сервером используемого источника опорного времени, а также дисперсия внутренних часов, то есть показатель максимальной погрешности внутренних часов по отношению к источнику опорного времени. Каждый из этих компонентов отражается в протоколе NTP по отдельности. Это позволяет не только точно измерить показатели отклонения и задержки, что обеспечивает возможность синхронизации внутренних часов по сигналу опорного времени, но и учитывать максимальную погрешность при синхронизации. За счёт этого можно не только определить время, но и оценить его точность в рамках пользовательского интерфейса.
В качестве эталонного источника времени в протоколе сетевого времени применяется стандарт UTC, а не среднее время по гринвичскому меридиану (GMT). Версия UTC, в свою очередь, основана на международном атомном времени, что подразумевает добавление «дополнительных секунд» по мере необходимости. Таким образом, время по протоколу сетевого времени приходится периодически корректировать путём добавления дополнительных секунд.
Протокол NTP является протоколом «абсолютного» времени. Это означает, что в его непосредственные функции не входит перевод абсолютного значения времени в конкретные дату и время для определённого места на поверхности Земли. Функция преобразования значений по UTC в показания обычных часов, а именно функция определения локальных даты и времени, возлагается на локальный сервер.

Серверы, клиенты, слои

В основе функционирования протокола сетевого времени лежат понятия сервера и клиента. Сервер выступает источником информации о времени, а клиент действует в качестве системы, пытающейся синхронизировать свои часы с сервером.
Среди серверов выделяются первичные и вторичные серверы. Первичный сервер также иногда называют сервером слоя 1 (stratum 1), если заимствовать терминологию архитектуры обозначения времени в телефонных сетях. Этот сервер получает сигнал времени по UTC непосредственно от официального источника времени – например, от настроенных атомных часов или источника сигнала GPS. Вторичный сервер получает сигнал времени от одного из вышестоящих серверов. На него возложена задача по передаче сигнала времени одному или нескольким нижестоящим серверам и клиентам. Вторичные серверы, по сути, занимаются воспроизведением сигнала времени. Их задача заключается в том, чтобы разгрузить первичные серверы, взяв на себя обработку поступающих от клиентов запросов, при этом обеспечивая клиентам доступ к сигналу времени сопоставимого качества. Вторичные серверы выстраиваются по чёткой иерархической системе и делятся на вышестоящие и нижестоящие. Нередко для оптимизации этого процесса применяется система слоёв (strata).
Сервер слоя 2 получает сигнал времени от сервера слоя 1, а сервер слоя 3 — от сервера слоя 2, и так далее. Сервер слоя n может взаимодействовать со множеством серверов слоя n-1 для стабильного получения сигнала времени. Архитектура слоёв используется для того, чтобы избежать петли синхронизации при обращении к нескольким серверам времени. (См. инфографику «Иерархия временной синхронизации NTP» — ред.)
Для синхронизации своих внутренних часов с сигналом времени по протоколу NTP клиенты взаимодействуют с серверами.

Протокол сетевого времени

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

Протокол NTP использует для своей работы протокол UDP (протокол пользовательских датаграмм). Сервер протокола NTP принимает пакеты данных клиента посредством порта 123. Сервер не сохраняет данные о запросах и отвечает на каждое поступление пакета от клиента по протоколу NTP простой операцией: он добавляет поля к полученному пакету данных и отправляет пакет обратно отправителю без какой-либо отсылки к предшествующим транзакциям.

Получив пакет данных NTP от клиента, сервер оперативно фиксирует время получения запроса, следуя алгоритму формирования пакетов данных на сервере. Затем пакет поступает в обработку процессом NTP. Обработка включает замену полей адреса и порта заголовка пакета, перезапись различных полей в пакете с их заменой на показания внутренних часов, проставку времени отправки пакета обратно, перерасчёт сигнатуры и отправку пакета обратно клиенту.
Пакеты, отправленные клиентом по протоколу сетевого времени, и ответы сервера клиента оформляются согласно единому формату, который приведён на рис. 3.

Рис. 3. Формат сообщения по протоколу сетевого времени.

Заголовок сообщения по протоколу сетевого времени составляется следующим образом:

ИК	Индикатор коррекции (2 бит). В данном поле указывается сообщение о добавлении секунды координации к последней минуте текущего дня. Используются следующие значения: 0: нет добавления секунды коррекции; 1: последняя минута дня содержит 61 секунду; 2: последняя минута дня содержит 59 секунд; 3: время не синхронизировано.
Номер версии	Номер версии протокола (3 бит) (номер текущей версии – 4).
Режим	Режим пакета по протоколу NTP (3 бит). Значения поля «Режим»: 0: зарезервировано; 1: симметричный активный режим; 2: симметричный пассивный режим; 3: клиент; 4: сервер; 5: широковещательный режим; 6: контрольное сообщение NTP; 7: зарезервировано для частного использования.
Часовой слой	<Слой источника времени (8 бит). Значения поля «Часовой слой»: 0: не определено или недопустимо; 1: первичный сервер; 2–15: вторичный сервер, использующий протокол NTP; 16: не синхронизировано; 17–255: зарезервировано.
Интервал опроса	Интервал опроса (8 бит, целое число со знаком). Максимальный интервал между последовательными сообщениями NTP, в секундах.
Точность	Точность часов (8 бит, целое число со знаком).Точность системных часов. Значение равно двоичному логарифму секунд.
Задержка	Общее время циклической задержки от сервера к первичному эталонному источнику. Значение выражается числом с фиксированной запятой длиной 32 бит в секундах с запятой между 15-м и 16-м битом. Данное поле имеет значение только для сообщений сервера.
Дисперсия	Максимальная допустимая погрешность тактовой частоты. Значение выражается числом с фиксированной запятой длиной 32 бит в секундах с запятой между 15-м и 16-м битом. Данное поле имеет значение только для сообщений сервера.
Идентификатор источника	Для серверов слоя 1 значением является код из четырёх символов ASCII, назначенных для опорного времени (см. рис. 4). Для вторичных серверов данное значение выражается адресом IPv4 источника синхронизации (32 бит) или первыми 32 битами хэша MD5 IPv6-адреса источника синхронизации.

Рис. 4. Основные коды идентификации (Из «Параметров протокола сетевого времени NTP»).

Для следующих четырёх полей используется отметка времени длиной 64 бит, состоящая из обозначения целых секунд длиной 32 бит и дробной части длиной 32 бит. При такой системе обозначения значение «2,5» было бы представлено в формате 64 бит следующим образом:
0000|0000|0000|0000|0000|0000|0000|0010 . |1000|0000|0000|0000|0000|0000|0000|0000
Целая часть | Дробная часть (десятичная)

Единица времени – секунда, а дата – 1 января 1900 года. Соответственно, 32-битный счётчик обнулится в 2036 году, а через два года, в 2038 году, обнулится счётчик по 32-битному Unix.
Минимальное значение в данном формате – 232 пикосекунды.

Время обновления Данное поле отражает время, когда система последний раз устанавливала или корректировала время. Длина – 64 бит.

Начальное время Данное поле отражает время клиента, когда запрос отправляется серверу. Длина – 64 бит.

Время приёма Данное поле отражает время сервера, когда запрос приходит от клиента. Длина – 64 бит.

Время отправки Данное поле отражает время сервера, когда запрос отправляется клиенту. Длина – 64 бит.

Как работает протокол? Клиент отправляет пакет на сервер и фиксирует время отправки пакета в поле «Начальное время» (Т1). Сервер фиксирует время получения пакета (Т2). После этого формируется пакет отклика с указанием первоначального значения «Начальное время» и времени приёма, когда пакет получен сервером, а затем к пакету добавляется значение «Время отправки», то есть время передачи пакета клиенту (Т3). После этого клиент фиксирует время получения пакета (Т4). Таким образом, в распоряжении клиента оказывается четыре временных показателя, приведённых на рис. 5.

Рис. 5. Временные метки по протоколу NTP (Спецификация RFC 4330).

Эти четыре параметра загружаются во внутренние часы клиента для обеспечения их синхронизации. Описание данного алгоритма приведено в следующем разделе.
Необязательные поля «Ключ» и «Профиль сообщения» обеспечивают возможность обмена секретным 128-битным ключом между клиентом и сервером. Секретный ключ используется для формирования полей хеша MD5 ключа и сообщения по протоколу NTP длиной 128 бит. За счёт этого клиент получает возможность выявлять попытки включить в передаваемую информацию ложные ответы за счёт атаки через посредника.

В завершение обзора функционирования протокола приведём описание алгоритма интервала опроса. Клиент NTP отправляет сообщения на NTP-сервер с одинаковой периодичностью. Как правило, интервал между запросами составляет 16 секунд. Если сервер недоступен, протокол NTP увеличивает интервал опроса – с каждым неудачным запросом интервал увеличивается вдвое до достижения минимальной частоты, которая составляет один запрос каждые 36 часов. При попытке возобновить синхронизацию с сервером протокол NTP сокращает продолжительность интервалов опроса и отправляет блоки из восьми пакетов с интервалом 2 секунды.
Если отклонение часов клиента от часов сервера достаточно мало, протокол NTP увеличивает интервал опроса путём отправки блоков из восьми пакетов с интервалом от 4 до 8 секунд (от 256 до 512 секунд).

Отсчёт времени клиентом

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

δ = (T4 – T1) – (T3 – T2)
Рассчитать отклонение часов клиента по отношению к часам сервера можно также следующим образом:
Θ = ½ [(T2 – T1) + (T3 – T4)]
Необходимо отметить, что при осуществлении данных расчётов предполагается, что задержка при передаче сообщениямежду клиентом и сервером одинакова в обоих направлениях.
Для расчётов показателя δ0 протокол NTP использует минимальное значение последних восьми замеров времени задержки. В качестве величины отклонения выбирается значение, измеренное при наименьшей задержке. Значения (Θ0,δ0) становятся обновлёнными значениями NTP.
Если в конфигурации клиента только один сервер, показания часов клиента корректируются путём их сдвига таким образом, чтобы нивелировать отклонение относительно часов сервера, при условии, что отклонение по отношению к серверу находится в допустимых пределах.
При включении нескольких серверов в конфигурацию клиента им применяется выборный алгоритм для назначения приоритетного сервера синхронизации из числа серверов-кандидатов. Для исключения серверов с нерелевантными показаниями осуществляется группировка сигналов
времени. Затем алгоритм выбирает сервер самого низкого слоя с минимальными значениями отклонения и помех. Алгоритм для этой операции в рамках протокола NTP называется алгоритмом Марзулло.

Включённый в конфигурацию клиента, протокол NTP пытается обеспечить синхронизацию часов клиента с опорным временем. Для этого NTP по мере необходимости корректирует показания внутренних часов в несколько заходов, каждый раз сокращая отклонение на небольшую величину, поскольку существенное изменение показателей может негативно сказаться на работе запущенных приложений, подтверждением чему служит ситуация с добавлением секунд корректировки. Поэтапная подстройка времени осуществляется за счёт вызова системной функции adjtime(), которая позволяет менять показания часов путём изменения частоты программных часов до полной коррекции. При высоких показателях отклонения изменение показаний часов становится достаточно длительным процессом. Как правило, темп составляет 0,5 миллисекунд в секунду.
Разумеется, это довольно схематичное описание общих принципов работы достаточно сложного алгоритма и задействованных в нём сложных математических формул. Если вы хотите более подробно погрузиться в суть работы протокола NTP, советуем ознакомиться с приведённым далее по тексту списком литературы. В ней представлено гораздо более глубокое описание алгоритмов и лежащих в их основе моделей
выбора часов и синхронизации.
В последние годы ведётся активная работа по обеспечению безопасности протокола сетевого времени. Итогом этих усилий стала публикация стандарта RFC8915, в котором приводится описание взаимодействия клиента и сервера по протоколу NTP с использованием протокола TLS (безопасность транспортного уровня), а не UDP. В рамках IETF также ведётся работа по описанию протокола NTP через протокол QUIC, чтобы обеспечить поддержку протокола сетевого времени в режиме пакетной обработки или датаграммном режиме.
По сути, протокол NTP представляет собой необычайно простой протокол взаимодействия между клиентом и сервером без сохранения информации о состоянии клиента на сервере. Однако он позволяет добиться удивительных результатов. Регулярно обмениваясь с сервером показаниями времени, клиент получает возможность настроить свои часы таким образом, чтобы обеспечивать высокую степень точности, несмотря на потенциальные проблемы со стабильностью и точностью внутренних часов, также несмотря на то, что синхронизация осуществляется по сети и может сопровождаться помехами в виде изменчивости задержки при обмене пакетами между клиентом и сервером. Большая часть современной распределённой инфраструктуры интернет-сервисов опирается на общую временную базу, и эта база обеспечивается общим использованием протокола сетевого времени (NTP).

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

[1] David L. Mills, “A Brief History of NTP Time: Confessions of an Internet Timekeeper”, ACM SIGCOMM, Computer Communication Review, Vol.33, No. 2, pp. 9–12, April 2003, http://www.eecis.udel.edu/~mills/database/papers/history.pdf
[2] K . A. Marzullo, “Maintaining the Time in a Distributed System: An Example of a Loosely-Coupled Distributed Service”, Ph.D. dissertation, Stanford University, Department of Electrical Engineering, February 1984, http://en.wikipedia.org/wiki/Marzullo%27s_algorithm
[3] David L. Mills, “NTP Architecture, Protocol and Algorithms”, University of Delaware, www.eecis.udel.edu/~mills/database/brief/arch/arch.ppt
[4] Jack Burbank, William Kasch, and David Mills, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, June 2010.
[5] David L. Mills, “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI”, RFC 4330, January 2006.
[6] http://www.ntp.org
[7] http://www.eecis.udel.edu/~mills/ntp.html
[8] David Mills, Computer Network Time Synchronization: the Network Time Protocol on Earth and in Space, Second Edition, CRC Press, 2011.
[9] http://en.wikipedia.org/wiki/Universal_Time
[10] RFC 5905: Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, https://www.rfc-editor.org/info/rfc5905
[11] RFC 8915: Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, «Network Time Security for the Network Time Protocol», RFC 8915, DOI 10.17487/RFC8915, September 2020, https://www.rfc-editor.org/info/rfc8915

Правовая оговорка

Изложенные в данной статье взгляды могут не совпадать с позицией или точкой зрения Азиатско-Тихоокеанского сетевого информационного центра.

Об авторе

Джефф Хьюстон имеет степени бакалавра и магистра наук. Занимает должность ведущего научного сотрудника АзиатскоТихоокеанского сетевого информационного центра, региональной интернет-регистратуры Азиатско-Тихоокеанского региона. Он посвятил многие годы развитию Интернета, в особенности в Австралии, где от лица научного-исследовательского сообщества отвечает за формирование инфраструктуры Интернета. Автор книг по связанным с Интернетом темам. Входил в Совет по архитектуре Интернета с 1999 по 2005 год, а с 1992 по 2001 год был членом Попечительского совета общества «Интернет» www.potaroo.net