Network Time Protocol
概要
ネットワークに接続され、互いにデータの交換を行う機器において、各機器が持つ時計（以下、各機器が持つ時計を「RTC」として説明する）の時刻が機器間で異なると、時刻に依存した機器間のデータ交換、例えば電子メールやファイルの送受信、ログの配信などに異常をきたすおそれがある。よって、RTCの時刻は機器間で互いに同期していることが望ましい。
ネットワークに接続される機器のRTCを正しい時刻に合わせる古典的な方法としてTime Protocolがある。Time Protocolは正しい時刻を提供するサーバから各機器が時刻値を取得する方法を定めている。しかし Time Protocol を用いて取得した時刻値にはサーバから機器に時刻値が到達するまでの通信時間が含まれない。よって、取得した時刻値には通信時間に起因する遅れの誤差が含まれてしまいRTCを正しい時刻に同期できない。
NTPは通信時間による時刻値の誤差を小さくする工夫がなされた時刻同期のためのプロトコルである。
2010年6月、最新バージョンのNTP4がRFCのProposed Standardとなった。
階層構造
NTPはstratumと呼ばれる階層構造を持ち、最上位のサーバが正確な時計から標準時を取得し、下位のホストはそれを参照する事で時刻を合わせる。最上位のNTPサーバはstratum 1であり、階層を下りるごとに数字が一つずつ大きくなる。stratum 16が最下位で、stratum 16に同期することは出来ない。NTPでは複数のサーバへ時刻を問い合わせることが可能で、これにより可用性と精度の向上が期待できる。通常サーバは複数の上位サーバを利用して時刻を取得する。一般にstratumの大きさよりも、サーバとのネットワーク的な近さのほうが時刻精度に大きく影響する。
GPSや標準電波、原子時計などの正確な時刻源 (stratum 0) に直結されたNTPサーバはstratum 1となる。これらの時刻源は誤差±1μ秒未満（100万分の1秒未満）の非常に正確な時刻を刻んでいる。また現実には、電波時計やGPSの受信機自体の信号遅延、受信機とstratum 1となる機器の間の遅延が無視できない。GPS衛星には原子時計が搭載されており、その電波にはGPSタイムと呼ばれる時刻情報が含まれている。標準電波は地域の標準時を保持する組織が時刻情報を電波で送出するものであり、日本の場合は独立行政法人情報通信研究機構（NICT、旧・通信総合研究所 (CRL)）が行っている。
代表的なNTPの実装であるntpdでは、上位stratumだけではなく、複数の同位・下位stratumのNTPサーバとも接続できる。ピアとよばれる他のサーバをどれにするかの設定は設定ファイルなどにより行う。より多くの複数のサーバと時刻の比較・ネットワークの遅延、および遅延のばらつきの計測を行ない、重み付けを行なって最ももっともらしい時刻を現在時刻とする。
運用
NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている（RFC4330による）。
LAN内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器を用意し、この機器（内部NTPサーバ）をプロバイダなどの外部NTPサーバに接続し、各クライアントはこの内部NTPサーバに接続する設定を行うと良い。
ルーターやクライアントパソコンなどのネットワーク上の各機器では、前述のようなNTPサーバにアクセスして、機器内部の時計の時刻をNTPサーバの時刻に合わせることで内部時計の誤差が少なくなる。
ドリフトの修正
NTPサーバの実装の多くでは、時刻の校正のみならず、時計の進み遅れの度合いの校正も行う。一般的にコンピュータ内部の時計は、ハードウェアの時計が提供する時刻をそのまま利用する場合と、割り込みなどによりソフトウェア的に時計を進める場合がある。いずれの場合も、設計状態での時計は数ppm以上（1ppmは百万分の一、およそ10日で1秒程度の精度）の狂いがあるため、他のNTPサーバからの時刻と自機の時計を数回比較した後、時計の進み遅れの度合い（ドリフト）も修正する必要がある。さらに気温変動など外乱要因による2次以上のドリフト（上述した進み遅れ度合いの変化）も存在するが、多くのNTPサーバでは一次補正（直線的なドリフトの補正）を行う実装にとどまる。
なおNTPサーバプログラムを用いてコンピュータの時刻の校正を行う場合、突然『もっともらしい時刻』に校正するのは危険である。サーバ機能を提供しているコンピュータでは、時刻が飛ぶことにより、定時に実行されるサービス（UNIXのcron・atなど）が実行されなくなったり（時計を進める場合）同じサービスが2回実行される（時計を遅らせる場合）ことがあるからである。したがって、ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。
閏秒の扱い
NTPプロトコルでは、電波時計の時刻送信フォーマットのように閏秒の扱いも規定されている。閏秒は、原子時 (TAI) と同期して進むUTCが、地球の自転速度の変化によって世界時 (UT1) から長年の間に大きく狂わないように、世界的な協定に基づいてUTCに挿入または削除される1秒である。これは本質的にコンピュータの時計の進み遅れとは異なり、必ず±1秒の差となる。したがって、問合せ先のNTPサーバからうるう秒挿入または削除を警告するパケットが送られてきたときは、自機の時計を1秒ずらす（ドリフトは調整しない）ことになる。
2036年問題
NTPでは、時刻の表現に1900年1月1日 0時0分0秒 (UTC)（この時間を以下では「起点」とする）からの積算秒数を使用している。この値は32ビット符号なし整数で表現されるため、起点から (2³²-1) 秒、すなわち42億9496万7295秒までしか表現できない。
その結果、起点から42億9496万7295秒経過した2036年2月7日 6時28分15秒 (UTC) の次の秒（16秒）が桁あふれによって起点と認識されてしまい、NTPが誤動作すると予想されている。
これが2036年問題である。UNIXにはこの問題が複数の箇所で今後顕在化するとみられるが（例: 2038年問題）、このNTPについても該当する。
なお、RFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒(UTC)を起点として計算することで2036年問題を回避する方法が書かれている。
下位プロトコル
通常、NTPはUDP上で動作する。UDPのポートは123番を使用する。ルータのパケットフィルタの設定でポート123番を通さないようにしている場合は、外部のNTPサーバにアクセスできなくなるので、通すように設定する必要がある
リファレンス実装
代表的なNTPの実装として、Unix系オペレーティングシステム用のNTPサーバであるntpd（旧xntpd）、およびNTPクライアントのntpdateがある。ntpd/ntpdateは多くのオペレーティングシステムで標準的に組み込まれている。
SNTP
Simple Network Time Protocol (SNTP) はNTPのサブセット版である。
UNIXなど
OpenBSDでは、ntpd/ntpdateの代替となるOpenNTPDがサブプロジェクトの一つとして提供されている。
X Window Systemのデスクトップ環境でもntpd/ntpdateをGUIより設定するユーティリティが付属するものがある。
スクラッチから書かれた実装としてchronyがある。Red Hat Enterprise Linux 8とSUSE Linux Enterprise Server 15ではデフォルトのNTPクライアント及びサーバーとしてchronyを採用している。また、多くのLinuxディストリビューションでも利用可能である。
Mac
macOS においても、標準でntpd/ntpdateが使用されていて、コマンドを意識せずGUIから設定できる。以前のMac OS 9でもNTPクライアントは標準で組み込まれていた。
Windows
Microsoft Windowsでは、Active Directoryにおいて時刻同期が必須となったため、Windows TimeサービスとしてNTPの機能が組み込まれている。Windows NTではSMBプロトコルを使ったnet timeコマンドによる時刻同期が可能であったが、これはNTPではなかった。またそれ以前のWindowsでは、サードパーティーのソフトウェアを使用する必要があり、日本では、Windowsが本格的にインターネット対応を開始した1990年代後半に「桜時計」と呼ばれる、サードパーティーによるNTPの実装が有名になった。
Active Directoryが実装されたWindows 2000では、NTPのサブセット版であるSimple Network Time Protocol (SNTP) が採用された。Windows XP / Server 2003からはフルセット版であるNTPが用いられ、GUIで時刻同期を設定することができるようになった。また、有志によってビルドされたWindows向けのntpd/ntpdateも公開されている。
その他
また、ルーターやスイッチングハブなどのネットワーク機器にNTPサーバが搭載される場合がある。もともとは高級なネットワーク機器に搭載される機能であったが、ネットワーク普及に伴う機器の低価格化により、2000年代後半には民生用のネットワーク機器においてもNTPサーバが搭載されている。
運用と諸問題
前述の通りNTPは階層構造を採用しているため、負荷分散が行えるように工夫されている。しかし、NTPと同じく階層構造を採用するDNSではDHCPやPPPによるDNSサーバアドレス配信の仕組みが普及しているのに対し、NTPではNTPサーバアドレス配信の仕組みが存在しない。よって、エンドユーザーは自ネットワーク内のNTPサーバの存在を知ることができず、エンドユーザーが stratum 1 の公開 NTP サーバを使用する傾向がある。結果的に、一つのNTPサーバにアクセスが集中するためサーバの応答性を下げ、配信される時刻の正確性が失われる。
この問題に対する国際的なプロジェクトとして、NTP pool project が存在する。これは、世界全体、あるいは国単位でまとめられたNTPサーバーのリストを用意し、DNSラウンドロビンによってNTPクライアントからのアクセスを振り分けるようにする公開DNSサーバーであり、サーバー名として 0.pool.ntp.org, 1.pool.ntp.org などのように指定すると全世界にあるNTPサーバーからランダムに選ばれたどれかのIPアドレスが返される。大陸別、あるいは国別の地域割りもなされており、たとえば 0.jp.pool.ntp.org や 1.jp.pool.ntp.org を指定すれば、日本国内にあるNTPサーバーのIPアドレスがランダムに返される。0.asia.pool.ntp.org ならアジア地区のNTPサーバーのどれかがランダムに選ばれる。プールされているサーバーのアドレスは、2017年12月現在、全世界で4146、日本国内については50である。なお、このプロジェクトはエンドユーザーからのアクセスを分散することを主目的としているため、プールされているNTPサーバーには、stratum 3や4も含まれている。
Windows XPやMac OSの初期設定サーバは混雑しているため、ISP提供のサーバや、上記のNTPプール、あるいは後述の公開NTPサーバ等に変更すると、より正確な時刻取得が可能になる。
日本では情報通信研究機構 (NICT) が世界最高性能のNTPサーバ (ntp.nict.jp) を2006年6月より一般公開したので、負荷に起因する問題は解決の方向へ向かうと思われる。NICTによれば、世界中のNTPリクエストを合計しても数万リクエスト/秒程度なので、100万リクエスト/秒を扱える新しいシステムでは負荷の問題ではなく知名度の低さが問題としている。
clock.nc.fukuoka-u.ac.jp問題
日本では、福岡大学が1993年（平成5年）からNTPサーバを公開しているが、ここを参照するように設定された機器や組み込まれたソフトウェアが非常に多いため、アクセス集中による過負荷に悩まされていることが、2005年に報告された。契約しているインターネットサービスプロバイダ (ISP) の公開するサーバを利用することで、この問題は解消するので、ISPや研究機関等が加入者向けにサービスするNTPサーバや公開NTPサーバに、今すぐ設定を変更することである。
2017年現在も、福岡大学NTPサーバへのデータトラフィックは過大な状態が続いており、平均180Mbpsに達している。アクセス過多の原因の一つとして、一部メーカーのネットワーク機器にNTPサーバのアドレスがハードコーティングされていることが挙げられている。
ネットワーク機器にアドレスがハードコーティングされた一例として、TP-Link製の無線LAN中継器がある。この機器は、本来の時刻同期の目的ではなくインターネット回線の接続状態を確認するため、福岡大学を含む複数のNTPサーバへ数秒間隔でアクセスする仕様になっていた。TP-Linkからは管理画面を開いている間のみNTPサーバへアクセスするよう、仕様を変更したファームウェアが公開されている。
2017年、福岡大学は同 NTP サービスの提供を2018年4月以降に停止する事を発表した。これは、データトラフィックが多すぎるため、大学ネットワーク運用に無駄な費用がかかっている事や、サービス開始当初の1993年はNTPで時刻同期することが研究対象であったが、現在では様々なアプライアンスが販売されているため、NTPの研究として役目を終えたと理由を挙げている。2019年3月12日に2台あるNTPサーバーのうちの1台を停止した。
ウィスコンシン大学-ネットギアNTP問題
ネットギア製のルーターがウィスコンシン大学のNTPサーバを参照するようハードコードされていたため、負荷が極度に集中した。以下に問題の経緯を記す。
2003年5月、ウィスコンシン大学に対して平均毎秒4万パケットのNTPサービスへの接続が行われた。
これに対し大学側はNTP用に公開していたポートを閉じ、悪意あるアクセスは数時間のうちに収まるであろうと考えていた。しかしながら1ヵ月後の2003年6月の時点において、大学側の予想に反するどころかさらに状況は悪化し平均毎秒25万パケットを記録。さらなる調査によって、多くの接続元が1秒毎に問い合わせを行っている事に不審を抱くこととなる。接続元となっている2つの大学に協力を要請。調査結果の中で双方ともにネットギア製のルーターを使用していた事が判明、型番もMR814であると特定された。
2003年6月16日、大学側はネットギア社のカスタマーサポート宛に電子メールにて状況の報告を行ったが返答がないため直接交渉を行い、2003年6月19日に、ネットギアから「開発者によるデバッグ時の設定値の残骸が引き起こしたもの」との説明が大学側に報告され、協力体制が整備された。
2003年8月の時点において、影響を受けた生産台数70万台から行われる最大毎秒70万パケットに及ぶリスクに対して、大学側はルーター使用者に影響がでないよう配慮し、ネットギアからはファームウェアのバージョンアップが提供された。これによりウィスコンシン大学の転送量の増加傾向は弱くなり、2003年11月からは減少傾向に転じることとなった。
なお、これらの事件の詳細は、2003年8月21日に、ウィスコンシン大学のDave Plonkaによりまとめられている。
他に、FreeBSDの有力開発者であるPoul-Henning Kamp(phk)が発見したD-link製ルータの問題や、ダブリンのTardis and Trinity Collegeの問題など、同様の問題が発生している。NTPサーバの誤用・不正使用問題を参照のこと。