З моменту початку використання комп'ютерів (спершу в спеціалізованих системах, у потім і в повсякденному житті) з'явилося завдання підтримувати точність ходу системних годинників, тобто мати точно синхронізований час із іншими комп'ютерами й системами. Особливо точність часу критична в розподілених системах, які критичні до порядку обчислення завдань, обробки даних і т.п.
Одним із прикладів такої синхронізації, де вперше був застосований популярний протокол синхронізації часу NTP, може бути диспетчерська служба керування польотами.
Також важливо, щоб сама мережа комп'ютерів мала не тільки синхронізований час, але й цей час був точним з іншими системами по всій планеті. Тобто час по всій території планети має бути однаковим (або досить близьким).
Першими протоколами точного часу, що використовувались на комп'ютерах, були DAYTIME (RFC 867) і TIME (RFC 868). Перший призначався для повідомлення дати й часу в зрозумілому людині виді, другий - зрозумілому комп'ютеру виді. Формат відповіді DAYTIME строго не регламентується й не призначений для машинної обробки - передбачається лише, що людині, що прочитала отриманий рядок, стане ясно, який зараз поточний час.
Протокол TIME, навпроти, призначений для обміну часу між машинами. На комп'ютер, що підключився до TIME-серверу, приходить UDP-пакет, що містить єдине 32-бітне беззнакове число, яке відповідає числу минулих з 1 січня 1900 р. секунд по UTC. Оскільки таке число переповнюється через 136 років, цей протокол здатний функціонувати тільки до 2036 г.
Зрозуміло, що ні DAYTIME, а ні TIME не можуть забезпечити необхідну точність синхронізації часу. У зв'язку із цим, в 1985 р. Девідом Л. Миллсом (David L. Mills) з університету Дэлавера був розроблений мережевий протокол синхронізації часу NTP, точніше його початкова, пізніше названа нульовою (NTPv0) версією, описана у RFC 958. Протокол NTP використовує алгоритм Марзулло (запропонований Кейтом Марзулло (Keith Marzullo) з Університету Каліфорнії, Сан-Дієго), що включає таку особливість, як облік часу передачі. У версії 4 він здатний досягати точності 10 мс при роботі через Інтернет, і до 0,2 мс усередині локальної мережі.
Описувати самі протоколи, а тим більше їхню роботу й взаємодію ми не будемо - цьому присвячено багато статей в Інтернеті - починаючи з офіційних документів RFC і закінчуючи оглядами. Відзначимо лише, що NTP для синхронізації використовує протокол UDP і 123 порт, DAYTIME - 13 порт TCP/UDP, TIME - 37 порт TCP/UDP.
Протокол NTP удосконалювався не один раз: NTPv1 (1988 г, RFC 1059), NTPv2 (1989 р., RFC1119), NTPv3 (1992 р., RFC1305), NTPv4 (1996 р., RFC2030).
Для визначення точності або значимості того або іншого NTP-серверу використовують параметр Stratum (стратум) - ціле число від 1 до 15. Стратум 1 відповідає серверам, що мають безпосередньо зв'язок з еталонном часу, стратум 2 - сервер, що отримує відомості про час від серверів першого стратума й т.д. При побудові ланцюжка зв'язків значення стратума збільшується на 1.
Робота алгоритму NTP досить проста й може бути проілюстрованою завданням Рэймонда М. Смаліана (1978 р.):
В однієї людини не було наручних годинників, зате в будинку висіли точні настінні годинники, які він іноді забував заводити. Один раз, забувши черговий раз завести годинники, він відправився в гості до своєго друга, провів у того вечір, а повернувшись додому, зумів правильно поставити годинники. Яким чином йому вдалося це зробити, якщо час у дорозі заздалегідь відомо не було?
Відповідь така: виходячи з будинку, людина заводить годинники й запам'ятовує, у якому положенні перебувають стрілки. По приходу у гості та ідучи з гостей, він відзначає час свого приходу й відходу. Це дозволяє йому довідатися, скільки він перебував у гостях. Повернувшись додому й глянувши на годинник, людина визначає тривалість своєї відсутності. Віднімаючи із цього часу той час, що він провів у гостях, людина довідається час, витрачений на дорогу туди й назад. Додавши вчасно виходу з гостей половину часу, витраченого на дорогу, він одержує можливість довідатися час приходу додому й перевести відповідним чином стрілки свого годинника.
Таким чином, по чотирьох даних: час відправлення запиту (по годинниках клієнта); час одержання запиту сервером (по годинниках сервера); час відправлення відповіді сервером (по годинниках сервера); час одержання відповіді (по годинниках клієнта) можна знайти час пакета в шляху туди й назад, а потім - відкоригувати локальний час.
При цих розрахунках ми користуємося трьома важливими припущеннями:
Насправді всі ці припущення, строго говорячи, не вірні, і одержати точне значення серверного часу за допомогою одного NTP-запиту неможливо. Тому для синхронізації годин звичайно використовується декілька NTP-серверів, на які постійно шлються запити. Накопичуючи статистику за тривалий час, математичними методами можна визначити точність показань кожного з серверів, швидкість ходу годин на кожному з них, і т.п. величини, використовуючи які, можна домогтися математично доказової точності синхронізації. Конкретні використовувані методи описані в RFC і надзвичайно складні. До речі, через третє припущення, використання синхронізації по NTP по несиметричним каналам зв'язку (супутникові й т.п.) не правомірно.
Крім власне обміну показаннями часу, в NTP, починаючи з версії 2, включений механізм обміну метаінформацією у вигляді "керуючих повідомлень" NTP. Формат самих керуючих повідомлень не заданий в RFC, але існуючий стандарт де-факто дозволяє з їхньою допомогою запитувати в NTP-сервера такі параметри, як адреси всіх його клієнтів і вищестоячих серверів, затримку до кожного з них і т.п.
NTP дозволяє домогтися високоточної синхронізації часу в мережі серверів, що синхронізуються, кожний з яких одержує показання з декількох джерел, обробляє їх, і передає далі. Він застосовний тільки усередині невеликих локальних мереж і мереж з малими затримками пакетів; в Інтернеті він практично незастосовний через велику (і, що важливо, випадкової) затримки пакетів, яка на порядки перевершує різниці в показаннях годин клієнта й сервера. Така NTP-мережа характеризується масштабованістю й стійкістю до збоїв - навіть у випадку відмови годин одного із серверів інші негайно це помітять і перестануть використовувати його показання.
Крім NTP, існує спрощена версія цього протоколу - SNTP (Simple Network Time Protocol). Він реалізований для синхронізації часу кінцевим клієнтом, оскільки всі переваги протоколу NTP проявляються саме в мережі серверів, а для одержання показань кінцевим користувачем NTP зайво складний. Тому для синхронізації часу кінцевими комп'ютерами й серверами був запропонований протокол SNTP (SNTPv3: 1992 р., RFC1361 і 1995 р., RFC1769; SNTPv4 включений як подпротокол в NTPv4).
Насправді SNTP - це не новий протокол, а спосіб використання NTP-пакетів і NTP-серверів у додатках, де не потрібний високоточний час, або воно недосяжне. У цьому випадку клієнт використовує тільки частину інформації UDP-пакета NTP-сервера. SNTP-клієнт може працювати з будь-якими версіями NTP-серверів, і крім їх - з особливими SNTP-серверами, які у відгуках заповнюють тільки необхідні дані UDP-пакета.
Таким чином, "полегшений" SNTP утворить не мережу серверів, що синхронізуються, а пари " клієнт-сервер". Будь-який NTP-сервер є одночасно SNTP-сервером. Клієнт, що не передає отриманий час далі, може працювати як NTP- або SNTP-клієнт, у залежності від умов. Для SNTP, як і для NTP, зарезервований 123-й UDP-порт.