- Понятие времени
- Цели и задачи NTP
- NTP (Network Time Protocol)
- SNTP (Simple Network Time Protocol)
- Серверы точного времени
- Использование NTP
- Глобальная NTP-сеть
1. Понятие времени
Пусть у нас есть два события – А и Б. Будем говорить, что Б произошло позже А, если Б произошло вследствие А. Таким образом, все события можно выстроить в одну цепочку так, чтобы каждое предшествовало всем своим следствиям (возможно, не единственным способом – это связано с относительностью одновременности и выходит за рамки темы). В получившейся цепочке события можно перенумеровать, и число, сопоставленное событию А, назвать временем события А. Так определённое время задаёт лишь последовательность событий – по времени двух событий можно установить, какое из них произошло раньше и поэтому могло быть причиной другого. (Более раннее событие может и не быть причиной более позднего, но оно с уверенностью не является его следствием.) Сам способ сопоставления числа событию выбирается произвольно – как мы увидим, на протяжении истории этот способ много раз менялся.
Легче всего измерять время – т.е. сопоставлять событиям численное значение времени – с помощью некого периодического процесса, приняв за основу то, что каждый период его занимает равное время. Безусловно, на шкале времени, выбранной по какому-то одному периодическому событию, какое-то другое может происходить неравномерно, и один его период будет занимать больше времени, чем другой. Другими словами, не все шкалы времени равноправны – какие-то из них, в которых большее число периодических процессов происходит равномерно, в силу этого удобнее в применении. На протяжении истории шкала времени совершенствовалась именно в том направлении, чтобы наиболее важные для науки периодические процессы происходили равномерно. Далее всюду современная шкала времени будет считаться абсолютно точной – не потому, что её невозможно усовершенствовать, а для удобства изложения.
Самый простой для наблюдения периодический процесс – вращение Земли и связанная с этим смена дня и ночи. В древнем Риме для измерения времени были выбраны контрольные точки рассвета и заката, принятые за 0 и 12 часов соответственно. Несовершенство этой схемы очевидно: зимой дни короче, чем летом, и поэтому в один час в июне можно успеть сделать существенно больше, чем в один час в декабре. Поэтому следующим шагом в совершенствовании измерения времени по солнцу было использование видимого солнечного времени, когда полдень – время наивысшего положения солнца над горизонтом – принято за 12 часов, а интервал между полуднями – видимый солнечный день – поделён на 24 часа. Однако и эта мера недостаточно совершенна: из-за неравномерности движения Земли по орбите (связанной с отклонением её формы от окружности) и из-за наклона земной оси, приводящей к вертикальным перемещениям солнца в течение года, длина видимого солнечного дня в течение года колеблется на 30 сек. – короче всего в декабре, длиннее – в сентябре. Окончательно за меру времени было принято среднее солнечное время, выбранное так, чтобы «неподвижные» звёзды оказывались в одинаковом положении каждые сутки в одно и то же время. Среднее солнечное время отражает только вращение Земли, и вопреки своему названию уже не связано с солнцем. Расхождение его с видимым солнечным временем может составлять до 16 минут, т.к. более длинные или более короткие чем 24 часа видимые солнечные дни следуют друг за другом месяцами, и ошибка накапливается. Так, если бы мы зафиксировали фотоаппарат на штативе и каждый день в полдень местного времени фотографировали солнце, то оно описало бы на фотографии восьмёрку – аналемму (
http://www.analemma.com/
). Это связано именно с расхождением видимого и среднего солнечного времени.
Цезиевый эталон частоты (1955)
За «астрономический» стандарт времени принято среднее гринвичское время – GMT, Greenwich Mean Time, – среднее солнечное время, наблюдаемое в Королевской Гринвичской обсерватории (http://www.rog.nmm.ac.uk/) на нулевом меридиане. Но и это время недостаточно точно: из-за приливов и отливов Земля замедляет своё вращение на 1,7 мс/век, «неподвижность» звёзд спорна, а точность астрономических наблюдений недостаточна для тех применений, где важны милли- и микросекунды. На протяжении истории применялось много «неастрономических» способов измерения времени: по сгоранию свечи, истечению воды из сосуда, колебанию маятника и т.п. В 1955 г. в английской национальной физической лаборатории (NPL, National Physical Laboratory, https://www.npl.co.uk/time/csfreq_standard.html) для точного измерения времени впервые были применены атомные часы, основанные на собственных колебаниях атома, связанных с его внутренней структурой.
Шкафы с цезиевыми часами в USNO
С 1967 г. они приняты международным бюро мер и весов (BIPM, Bureau International des Poids et Mesures, https://www.bipm.org/en/home) за эталон времени: секундой называется интервал между 9 192 631 770 межуровневыми переходами атома цезия-133 (число переходов выбрано для соответствия со средним солнечным временем). Эталонные часы, хранимые в BIPM, постоянно сверяются с около двумястами атомными часами в национальных лабораториях на всех континентах, что гарантирует сохранение эталонного точного времени даже в случае каких-либо глобальных катастроф. Это эталонное время называют международным атомным временем – TAI, Temps Atomique International. Именно с этим временем скоординированы спутники, например спутники глобальной системы позиционирования (GPS, Global Positioning System), передающие сигналы точного времени во все точки планеты.
Миниатюрные цезиевые часы (NIST)
Атомные часы не обязательно используют цезий-133: другим удобным в использовании веществом оказался рубидий-87. Более компактные, но менее точные атомные часы используют водород или аммиак.
С 1884 г. за международный стандарт времени было принято GMT с поправкой на целое число часов, отвечающее «часовому поясу», или меридиану ближайшего к наблюдателю административного центра. Этот стандарт был назван UT (Universal Time), или UT0, т.к. позже были приняты «уточняющие» его стандарты UT1 и UT2, всё ещё опирающиеся на астрономические наблюдения. С 1 января 1958 г. за эталон международного времени также было принято атомное время; международное время в нулевом часовом поясе совпадало с TAI. К 1972 г. было замечено, что GMT и TAI расходятся на 10 сек. из-за неточной пропорциональности суточного и годового периода вращения Земли, а также неравномерности её суточного вращения. В результате для согласования международного времени с солнечным были введены «високосные секунды» (leap seconds), добавляемые или вычитаемые из UTC по решению международной службы вращения земли (IERS, International Earth Rotation Service, http://www.iers.org/iers/) для поддержания разницы между UT и GMT менее 0,9 сек. Новый стандарт был назван UTC (Coordinated Universal Time, Temps Universel Coordonné) для обозначения его скоординированности с солнечным временем. Название UTC не является аббревиатурой ни на английском, ни на французском языках, вопреки расхожему заблуждению.
Обзор истории часов и времени доступен на сайте американского национального института стандартов и технологии (NIST, National Institute of Standards and Technology):
https://www.nist.gov/pml/time-and-frequency-division/popular-links/walk-through-time
По решению IERS «високосные секунды» могут добавляться (или вычитаться) в ночь на 1 июля или 1 января; 1 июля 1972 г. было добавлено сразу 10 секунд, с тех пор изредка добавлялось по секунде (вычитания не производилось ни разу). На октябрь 2004 г. было добавлено 32 «високосные секунды», т.е. TAI–UTC = 32 сек. Последняя «високосная секунда» добавлялась 1 января 1999 г. В таких случаях после 23:59:59 31 декабря следует дополнительная секунда – 23:59:60, и только затем – 0:00:00 1 января. Если потребуется вычесть «високосную секунду», то после 23:59:58 сразу произойдёт переход на 0:00:00 следующего дня.
Поскольку время в компьютерах обычно хранится в виде числа секунд с некоторой опорной даты – 1 января 1970 г., 1 января 1900 г., 1 января 1600 г., или какой-либо ещё – то одним из недостатков стандарта UTC является нетривиальность (для дат в прошлом) и невозможность (для дат в будущем) точного перевода хранимого времени в привычную человеку форму (например, «19 декабря 2004 г., 16:27:47») из-за того, что в каждом году своё (и неизвестное заранее) количество секунд. В частности, невозможно точно перевести в «компьютерное время» дату в будущем, например полночь 1 января 4000 г., поскольку неизвестно даже приблизительно, сколько «високосных секунд» будет внесено в UTC к тому времени. В реальности компьютеры обычно не делают поправку на «високосные секунды» между датами, так что если я запланирую какое-то событие на вышеуказанное время и буду держать системные часы постоянно синхронизированными с эталонными, то оно вполне может произойти не в полночь, а в полдень.
Во-первых, в компьютерных системах часто требуется иметь точно синхронизированное время (при этом не важно, какая именно величина времени будет использоваться). Примером может быть распределённая система, где есть несколько компьютеров, принимающих запросы и передающих их на центральный сервер для обработки. Чтобы запросы выполнялись точно в том порядке, в котором они были приняты, принимающие компьютеры добавляют в них отметку о времени приёма. Если часы у разных компьютеров в такой системе выставлены по-разному, то может возникнуть ситуация, когда позднее пришедшему запросу будет выставлена меньшая отметка о времени, чем пришедшему ранее, и сервер обработает их в неправильном порядке.
Привязываясь к определению времени, данному ранее, в этом примере требуется сохранять информацию о том, какое из событий – причина и какое – следствие.
Первым из применений NTP на практике действительно была синхронизация часов в центре управления полётами, где было критично, чтобы все диспетчеры имели совершенно одинаковые показания времени.
Во-вторых, в компьютерных системах часто требуется точно знать текущее время. Примером может быть обсерватория, которая должна наблюдать какие-то события точно в тот момент, когда Земля будет проходить конкретную точку своей орбиты. Здесь задействовано не определение времени, а именно его привязка к астрономическим событиям (движению Земли по орбите и вокруг своей оси).
В-третьих, есть потребность и в централизованных службах точного времени, т.е. недостаточно было бы просто поставить на каждый компьютер цезиевые часы, даже если бы это было возможно. Централизованная служба может быть достоверной, тогда как системные часы отдельных компьютеров могут показывать неверное время из-за поломки, преднамеренного повреждения и т.п.
Одним из применений такой централизованной службы могло бы стать «патентное бюро будущего», куда любой может послать проект, бюро автоматически выставит на проекте точное время его принятия и свою цифровую подпись, и отошлёт назад автору. В таких условиях любой конфликт относительно приоритета в каком-нибудь изобретении будет разрешаться простым предъявлением подписанных в бюро проектов.
Кроме того, для поддержания всех часов внутри такого бюро достоверными, оно само должно пользоваться системой синхронизации времени, описанной в первом примере.
В соответствии с тремя приведёнными примерами, области применения NTP можно разделить на три категории: -синхронизация системных часов внутри организации; -синхронизация системных часов с эталонными; -получение точного времени из достоверной службы.
д) Первые протоколы точного времени
Первые протоколы для передачи показаний времени по сети появились в 1983 г. (RFC867 и RFC868). Эти протоколы – DAYTIME и TIME – предназначались для сообщения времени человеку и компьютеру соответственно. Протокол DAYTIME крайне прост: на подключившийся к DAYTIME-серверу компьютер приходит строка наподобие «19 декабря 2004 г., 16:27:47». Формат не регламентируется строго и не предназначен для машинной обработки; предполагается лишь, что человеку, прочитавшему полученную строку, станет ясно текущее время. Оно может включать день недели, миллисекунды, фазу луны или любую другую информацию, которую сервер считает относящейся к делу. Для DAYTIME зарезервирован 13-й TCP-порт. Один из действующих DAYTIME-серверов – atomictime.net – передаёт строку в виде «Fri Dec 24 10:17:58 2004»
Протокол TIME, напротив, предназначен для обмена времени между машинами. На подключившийся к TIME-серверу компьютер приходит UDP-пакет, содержащий единственное 32-битное беззнаковое число, соответствующее числу прошедших с 1 января 1900 г. секунд по UTC. Поскольку такое число переполняется через 136 лет, этот протокол способен функционировать только до 2036 г. Для TIME зарезервирован 37-й UDP-порт.
3. NTP (Network Time Protocol)
Первая версия NTP (позже названная NTPv0) появилась в 1985 г. (RFC958). Идея состояла в «расширении» протокола TIME для передачи дополнительной информации, достаточной для любых мыслимых нужд. NTP-серверы и NTP-клиенты обмениваются однотипными UDP-пакетами следующего формата:
| LI (2) | Status (6) | Type (8) | Precision (16) |
| Error (16.16) | |||
| Drift (0.32) | |||
| RefId (32) | |||
| Reference (32.32) | |||
| Originate (32.32) | |||
| Receive (32.32) | |||
| Transmit (32.32) | |||
Время здесь передаётся в виде 64-битного числа секунд с фиксированной точкой (посередине, т.е. между 31 и 32 битом). Такой формат позволяет передавать время с точностью до 0,2 нс, что должно превосходить реально достижимую точность измерения времени ещё много лет. С другой стороны, как и при использовании 32-битного целого числа секунд, через 136 лет происходит переполнение, и поэтому NTP, как и TIME, применим лишь до 2036 г.
Поля NTP-пакета определены следующим образом:
LI (leap indicator): указывает на необходимость введения високосной секунды в ночь с текущего дня на следующий. Это поле, когда BIPM вводит високосную секунду, задаётся вручную оператором на одном из главных NTP-серверов, и распространяется по всей NTP-сети. 4 возможных значения поля соответствуют отсутствию поправки, добавляемой или вычитаемой секунде, или неисправности сервера (соответствующей сообщению «сервер вообще работает, но сообщаемое время неверно».)
Status: указывает на «самооценку» сервера, и позволяет неисправному NTP-серверу доложить о виде своей неисправности остальным серверам. В более поздних версиях NTP это поле было заменено полями VN и Mode.
Type: указывает на тип часов, показания которых сообщает NTP-сервер. Стандартом было определено несколько стандартных значений, соответствующих атомным часам, радиочасам, наручным часам оператора и т.д. В более поздних версиях NTP это поле было заменено полем Stratum.
Precision: знаковое целое число, указывающее оценочную точность часов сервера как двоичный логарифм. Так, часам IBM PC, обновляемым каждые 55 мс, соответствовало бы значение -4 (т.е. ~16 Гц), а более точным часам, обновляемым 1000 раз в секунду – значение -10. В более поздних версиях NTP это поле было сокращено до 8 бит.
Error: «самооценка» точности показаний сервера как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом), соответствующее максимальной возможной ошибке. В более поздних версиях NTP это поле было заменено полем Root Delay.
Drift: «самооценка» точности часов сервера как число с фиксированной точкой (в начале, т.е. перед 31 битом), соответствующее накапливаемой ошибке в секундах за секунду. Это число знаковое, и отставанию на секунду каждый час соответствует значение -1/3600 ≈ -0.0002778. В более поздних версиях NTP это поле было заменено полем Root Dispersion.
RefId: идентификатор часов, показания которых сообщает NTP-сервер. Если он непосредственно связан с эталонными часами, то это – название данных эталонных часов (до 4 букв в ASCII, дополненных нулями справа до 32 бит), например – «USNO» (военно-морская обсерватория США, US Naval Observatory, http://tycho.usno.navy.mil/), «WWV » (NIST, http://www.boulder.nist.gov/timefreq/stations/wwv.html), «MSF » (NPL, https://www.npl.co.uk/time/msf.html) «PPS » (собственные атомные часы), «GPS » (GPS-приёмник). Если же данный NTP-сервер получает показания времени от другого NTP-сервера, то в этом поле указывается IP-адрес сервера-источника показаний времени. Поскольку поле ограничено 32 битами, то NTP не способен работать с 128-битными IPv6-адресами.
Остальные 4 поля – Reference, Originate, Receive и Transmit – составляют само тело NTP-пакета. В поле Reference сервер указывает показания часов, когда он последний раз их считывал; в поле Originate – копирует содержимое этого поля из запроса; в поле Receive указывает время получения запроса по своим часам; в поле Transmit – время отправки ответа по своим часам. Таким образом, разница Transmit – Receive соответствует времени обработки запроса сервером (и для сильно загруженного сервера может быть большой).
Описанный здесь протокол NTPv0 сейчас считается устаревшим и не применяется. Вместо него применяются более поздние версии: NTPv1 (1988, RFC1059), NTPv2 (1989, RFC1119), NTPv3 (1992, RFC1305), NTPv4 (1996, RFC2030). Все эти версии полностью совместимы между собой; в новых RFC только уточнялись математические процедуры, которые должен выполнять NTP-сервер для фильтрации и объединения показаний других NTP-серверов. Другими словами, NTPv0-сервер не может работать с более новыми серверами, тогда как NTP-серверы версий 1–4 могут работать вместе. Формат NTP-пакета более новых версий несколько отличается от формата NTPv0-пакета:
| LI (2) | VN (3) | Mode(3) | Stratum (8) | Poll (8) | Precision (8) |
| Root Delay (16.16) | |||||
| Root Dispersion (16.16) | |||||
| RefId (32) | |||||
| Reference (32.32) | |||||
| Originate (32.32) | |||||
| Receive (32.32) | |||||
| Transmit (32.32) | |||||
| Authenticator (до 160) | |||||
Новые поля определены следующим образом:
VN: номер версии используемого протокола (от 1 до 4, NTPv0-серверы в этом поле (верхняя часть поля Status) указывают значение 0).
Mode: режим работы отправителя пакета («чистый» сервер, широковещающий сервер, симметричный сервер (т.е. одновременно и клиент), «чистый» клиент и т.д.)
Stratum: уровень «наслоения» показаний времени. NTP-сервер, связанный с эталонными часами напрямую, имеет стратум 1; NTP-сервер, получающий показания только от NTP-серверов первого стратума, имеет стратум 2; NTP-сервер, получающий показания от серверов второго стратума, имеет стратум 3, и т.д. Номера стратумов от 16 до 255 зарезервированы, т.е. показания серверов 15 стратума уже не должны передаваться дальше.
Poll: знаковое целое число, указывающее интервал между сообщениями как двоичный логарифм числа секунд. NTP-клиент указывает здесь интервал, с которым он предполагает опрашивать сервер, а NTP-сервер – интервал, с которым он предполагает чтобы его опрашивали. Допустимыми значениями по RFC2030 являются от 4 (16 сек.) до 14 (4,5 часа).
Root Delay: «самооценка» времени, за которое показания часов доходят до NTP-сервера, как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом).
Root Dispersion: «самооценка» разброса показаний часов NTP-сервера как число секунд с фиксированной точкой (посередине, т.е. между 15 и 16 битом).
Для NTP зарезервирован 123-й UDP-порт.
Когда NTP-клиент отправляет запрос на сервер, он указывает в поле VN свою версию, в поле Mode – тип своей работы, а в поле Originate – время отправления этого запроса (по своим часам). Сервер, примяв запрос, заполняет в NTP-пакете все поля, скопировав в поле Originate значение, пришедшее в запросе. Таким образом, у клиента, когда к нему приходит ответ от сервера, имеются четыре значения времени: org (время отправки запроса), rec (время получения запроса сервером), xmt (время отправки ответа сервером) – из NTP-пакета и loc (время получения ответа) – по показаниям локальных часов в момент прихода ответа. При этом значения org и loc соответствуют показаниям часов локальной машины, а rec и xmt – показаниям часов сервера.
Выполняемая затем обработка этих значений аналогична действиям английского джентльмена из старой задачи Рэймонда М. Смаллиана (1978): «У одного человека не было наручных часов, но зато дома висели точные настенные часы, которые он иногда забывал заводить. Однажды, забыв в очередной раз завести часы, он отправился в гости к своему другу, провел у того вечер, а вернувшись домой, сумел правильно поставить часы. Каким образом ему удалось это сделать, если время в пути заранее известно не было?» Ответ таков: «Выходя из дома, человек заводит часы и запоминает, в каком положении находятся стрелки. Придя к другу и уходя из гостей, он отмечает время своего прихода и ухода. Это позволяет ему узнать, сколько он находился в гостях. Вернувшись домой и взглянув на часы, человек определяет продолжительность своего отсутствия. Вычитая из этого времени то время, которое он провел в гостях, человек узнает время, затраченное на дорогу туда и обратно. Прибавив ко времени выхода из гостей половину времени, затраченного на дорогу, он получает возможность узнать время прихода домой и перевести соответствующим образом стрелки своих часов.» (http://ntl.narod.ru/logic/smullyan/name/p2.html#13)
Таким образом, по четырём данным мы находим время пакета в пути туда и обратно (loc – org), время его обработки (xmt – rec), а из них – чистое время пути пакета от локальной машины до сервера (loc – org – xmt + rec)/2. Значит, пакет пришёл на сервер в rec серверного времени и org + (loc – org – xmt + rec)/2 локального времени, и разница между серверным временем и локальным – (rec – org) – (loc – org – xmt + rec)/2 = (rec – org – loc + xmt)/2. Эта величина добавляется к локальному времени, и получается «истинное» время получения ответа.
Здесь мы пользуемся тремя предположениями: 1) пакет проходит путь от клиента до сервера и обратно за равное время; 2) скорость хода часов клиента и сервера равна; 3) на вычисление нового локального времени не уходит дополнительное время. На самом деле все эти предположения, строго говоря, не верны, и получить точное значение серверного времени с помощью одного NTP-запроса невозможно. Поэтому для синхронизации часов обычно используется несколько NTP-серверов, на которые постоянно шлются запросы. Накапливая статистику за длительное время, математическими методами можно определить точность показаний каждого из серверов, скорость хода часов на каждом из них, и т.п. величины, используя которые, можно добиться математически доказуемой точности синхронизации. Конкретные используемые методы описаны в RFC и чрезвычайно сложны.
Кроме собственно обмена показаниями времени, в NTP начиная с версии 2 включён механизм обмена метаинформацией в виде «управляющих сообщений» NTP, которые имеют особое значение поля Mode. Формат самих управляющих сообщений не задан в RFC, но существующий стандарт де-факто позволяет с их помощью запрашивать у NTP-сервера такие параметры, как адреса всех его клиентов и вышестоящих серверов, задержку до каждого из них и т.п.
Подводя итог, NTP позволяет добиться высокоточной синхронизации времени в сети синхронизирующихся серверов, каждый из которых получает показания из нескольких источников, обрабатывает их, и передаёт дальше. Он применим только внутри небольших локальных сетей; в Интернете он практически неприменим из-за большой (и, что важно, случайной) задержки пакетов, которая на порядки превосходит разницы в показаниях часов клиента и сервера. Такая NTP-сеть характеризуется масштабируемостью и устойчивостью к сбоям – даже в случае отказа часов одного из серверов остальные немедленно это заметят и перестанут использовать его показания. Интересно, что выпускаются настенные часы со встроенным NTP-клиентом – для использования в предприятиях, где уже развёрнута NTP-сеть, и цезиевые часы со встроенным NTP-сервером (с нулевым Root Delay).
Ещё можно упомянуть, что поскольку каждый NTP-сервер в процессе работы определяет задержку до всех соседних серверов, то можно построить систему динамической маршрутизации NTP-сети, где время прохождения пакета по сети будет минимальным. Такая сеть была практически реализована под названием Fuzzball/Hellospeak
4. SNTP (Simple Network Time Protocol)
Как уже было отмечено, все преимущества NTP проявляются именно в сети серверов, т.е. для получения показаний конечным пользователем он излишне сложен. Поэтому для замены протоколов TIME (неспособного передавать время с точностью выше 1 сек.) и DAYTIME (неудобного для машинного разбора) был предложен SNTP (SNTPv3: 1992, RFC1361 и 1995, RFC1769; SNTPv4 включён как подпротокол в NTPv4). Это не новый протокол, а способ использования NTP-пакетов и NTP-серверов в приложениях, где не требуется высокоточное время, либо оно недостижимо. В этом случае клиент использует только поле Reference из NTP-пакета. SNTP-клиент может работать с любыми версиями NTP-серверов, и кроме них – с особыми SNTP-серверами, которые в откликах заполняют только поле Reference, а в остальных полях оставляют нули. Собственно, единственным видимым клиенту отличием NTP-сервера от SNTP-сервера является заполнение полей Receive и Transmit. Если SNTP-клиент хочет обеспечить подобную NTP синхронизацию, он может запоминать время отправки запроса и приёма ответа, накапливать статистику и т.д.; однако в тех условиях, когда применяется SNTP, это бессмысленно.
RFC запрещает клиентам, получившим время по SNTP, передавать его дальше по NTP. Однако нужда в этом возникает, например, в организациях, где один сервер получает время по Интернету от SNTP-сервера точного времени и затем по локальной сети устанавливает время на всех компьютерах в организации. По-видимому, именно для этого используется «стратум 16», зарезервированный в RFC.
Итак, SNTP образует не сеть синхронизирующихся серверов, а пары «клиент-сервер». Любой NTP-сервер является одновременно SNTP-сервером, однако бывают и «чисто-SNTP»-серверы. Клиент, который не передаёт полученное время дальше, может работать как NTP- или SNTP-клиент, в зависимости от условий. Для SNTP, как и для NTP, зарезервирован 123-й UDP-порт.
Ещё один интересный момент – что для DAYTIME-клиентов институтом NIST был предложен протокол DAYTIME-ACTS (Automated Computer Time Service, см. http://www.boulder.nist.gov/timefreq/service/its.htm), содержащий аналогичную SNTP-пакету информацию: время с точностью до миллисекунд, информацию о високосных секундах, статус сервера и т.п. – в строго определённом и лёгком для машинного разбора формате. Например, их сервер time.nist.gov передал мне такую строку: «53363 04-12-24 15:28:59 00 0 0 635.1 UTC(NIST) *»
Точное время можно получить множеством способов:
— от высокоточных цезиевых часов, установленных поблизости; (Такие часы могут занимать шкаф, помещаться на столе, или быть размером со спичечную коробку – в зависимости от времени выпуска.)
— по радиосигналу, передаваемому службами точного времени: сразу на многих радиочастотах, чтобы минимизировать атмосферные помехи, передаётся сигнал заранее установленной частоты. Так можно получить сигналы точного времени от уже упомянутых USNO и NIST – двух наиболее известных служб точного времени в США, имеющих совместным проектом сервис «Официальное время США» (http://time.gov/about.html);
(Интересное замечание: выпускаются будильники и наручные часы со встроенным радиоприёмником, которые синхронизируются с сигналами точного времени какой-либо из таких служб. Вне зоны приёма их сигнала, например вне США для часов, принимающих сигнал NIST, такие часы совершенно бесполезны.)
— по телефону, позвонив на такую службу точного времени (опять же, в линию выдастся звуковой сигнал заранее установленной частоты);
— по модему, позвонив терминальной программой на службу точного времени (ответом будут показания времени в виде строки);
— от GPS- либо подобного ему спутника (они также передают радиосигнал заранее установленной частоты)
— наконец, по сети от компьютера, получившего его одним из перечисленных способов.
В России, насколько я понимаю, единственными доступными способами являются два последних.
б) NTP-серверы низких стратумов
Официальный список NTP-серверов первого стратума, т.е. непосредственно связанных с высокоточными часами, публикуется на http://ntp.isc.org/bin/view/Servers/StratumOneTimeServers. Наиболее известные из них – tick.usno.navy.mil и tock.usno.navy.mil в USNO (http://tycho.usno.navy.mil/ntp.html) – сильно перегружены, и рассчитывать на них не стоит. В основном, как легко видеть из этих списков, NTP-серверы находятся в США в государственных и академических сайтах (домены .gov и .edu); серверы, расположенные в домене .mil, также многочисленны, но доступ к ним чаще всего ограничен (т.е. нужно писать письмо администратору NTP-сервера, объяснить ему цель своего использования его сервера, и тогда он, если захочет, откроет доступ).
В России, согласно списку, располагалось два сервера второго стратума – в Пушкино и Черноголовке, и нет серверов первого стратума. Как я проверил, эти два сервера уже не отвечают на запросы. Для своих экспериментов я использовал сервер первого стратума (с RefId = «PPS », т.е. связанного с атомными часами) в Borowiec, Польше; он удивил меня крайне малыми задержками (около 100 мс). Как выяснилось, системные часы моего компьютера спешат на 10 мс/мин.
В некоторых UNIX-системах поддержка NTP реализована на уровне ядра, способного хранить время с точностью до 1 мкс. В сети таких систем для синхронизации времени на всех компьютерах не нужно предпринимать никаких дополнительных мер.
В WinNT есть служба синхронизации часов в домене (синхронизация осуществляется в рамках протокола NetBEUI) При этом часы контроллера домена можно с помощью этой же службы синхронизировать с внешним сервером посредством SNTP. Далее, эту службу можно настроить как SNTP-клиент и SNTP-сервер на любом компьютере с ОС WinNT. (Служба называется w32time, и вне домена она по умолчанию остановлена; для её запуска нужно выполнить команду “net start w32time”; для задания списка NTP-серверов, с которыми будет производиться синхронизация помимо контроллера домена, нужно выполнить команду “net time /setsntp:список_серверов”.) Для управления этой службой можно использовать программу w32tm.
Красивый и лёгкий в использовании SNTP-клиент для ОС Windows – Automachron от One Guy Coding (
http://oneguycoding.com/automachron/) – показывает содержимое приходящих NTP-пакетов и потому весьма полезен при изучении SNTP. Именно его я использовал для своих экспериментов. Есть и множество других NTP- и SNTP-клиентов для различных ОС.
Средства очень широкого профиля предлагает компания Galleon (https://www.ntp-time-server.com): NTP-клиенты и серверы, GPS-приёмники и радио-часы, подключаемые к компьютеру, и т.д.
В декабре 1999 г. сотрудник Google Нельсон Минар опубликовал работу, посвящённую исследованию глобальной NTP-сети: http://xenia.media.mit.edu/~nelson/research/ntp-survey99/
Он рассылал NTP-запросы по всем IP-адресам и анализировал приходящие ответы. Им сделаны следующие важные выводы о глобальной NTP-сети:
— обнаружено 175 тыс. общедоступных NTP-серверов (создатель NTP, Дэвид Л. Миллс из университета Делавэра, проводил похожие исследования и нашёл 990 серверов в 1989 г. и 39 тыс. – в 1997 г.);
— из этих серверов половина относятся к третьему стратуму, пятая часть – к четвёртому, 15% — ко второму, 4% — к пятому, и только 957 (0,5%) – первому. Минар даёт обоснование такого результата: серверы первого стратума расположены в правительственных учреждениях, второго – у входа в организацию и третьего – на каждом компьютере в организации, поэтому их и больше всего.
— средняя задержка до сервера высшего стратума – 29 мс для второго стратума, 15 мс для третьего, и убывает дальше; По сравнению с исследованием 1994 г. (42 мс для второго стратума и 36 – для третьего), Интернет стал в несколько раз быстрее.
— среднее число клиентов – 28 для серверов первого стратума, 3 – для второго, 0.5 – для третьего (у Миллса в 1997 г. – 20, 1.5 и 0.3 соответственно, т.е. NTP-сеть стала ветвиться сильнее);
Таким образом, картина глобальной NTP-сети такова: несколько перегруженных серверов первого стратума, окружённых большим облаком серверов второго стратума, и ещё большим облаком серверов третьего стратума. Вокруг них есть чуть-чуть серверов четвёртого и пятого стратумов, и остальные уже незаметны на их фоне.
а) NTP-серверы первого стратума
Далее, Минар исследует эти несколько перегруженных серверов первого стратума. Из них две трети не имеют доступа к точным часам (!) Из оставшихся две пятых получают время от GPS-приёмника, 8% — от атомных часов, остальные — от радио-часов.
Две пятых всех серверов первого стратума имели неправильны показания (разница с правильными – более 10 сек). Из этих серверов 95% не имели доступа к точным часам; другими словами, они вводили в заблуждение пользователей, объявляя себя сервером первого стратума. Почему неправильные показания у остальных 5% серверов первого стратума, можно только догадываться; скорее всего, из-за неправильной настройки, т.к. один из серверов выдавал время с ошибкой на шесть с половиной лет (!)
К счастью, успокаивает Минар, из всех NTP-серверов высоких стратумов с неправильными часами первого стратума синхронизировано только 729 (0,4%), и даже из них 572 получают время также и от правильные часов. Т.е. нельзя заключать, что все часы в Интернете сбиты из-за плохих NTP-серверов; большинство часов синхронизировано именно с точными NTP-серверами, ещё больше их перегружая (30% всех серверов первого стратумов имеют более 10 клиентов, 15% – более 100, 5% – более 500, у tick.usno.navy.mil – около 2500).
В результате исследования Минар нашёл 363 NTP-серверы с точным временем и достоверным источником. В 1997 г. Миллс нашёл 220 таких серверов. Другими словами, хотя число NTP-серверов в Интернете выросло очень значительно, точное время выставлено лишь на небольшой их части, численность которой выросла не так значительно. Серверы первого стратума с верным временем и надёжным источником по-прежнему очень редки (меньше сотни).