Network Time Protocol

**Network Time Protocol**（ネットワーク・タイム・プロトコル、**NTP**）は、パケット交換型ネットワークで接続されたコンピュータや通信機器の時刻を同期させるための通信プロトコルである。

1980年代にデラウェア大学のデイヴィッド・L・ミルズが設計したインターネット標準の一つであり、現在も広く運用されている。

分散システムの制御、ログや取引記録の整合性確保など、正確な時刻を必要とする情報システムで利用される。往復通信時間の測定による遅延補正と階層化された時刻源への段階的同期により、誤差数ミリ秒以下の時刻同期が可能となる。

## 概要
NTPは、全ての参加コンピュータを協定世界時(UTC)の数ミリ秒以内の時刻に同期させることを目的としている。

ネットワークに接続され、互いにデータの交換を行う機器において、各機器が持つ時計（以下、各機器が持つ時計を「RTC」として説明する）の時刻が機器間で異なると、時刻に依存した機器間のデータ交換、例えば電子メールやファイルの送受信、ログの配信などに異常をきたすおそれがある。よって、RTCの時刻は機器間で互いに同期していることが望ましい。ネットワークに接続される機器のRTCを正しい時刻に合わせる古典的な方法としてTime Protocolがある。Time Protocolは正しい時刻を提供するサーバから各機器が時刻値を取得する方法を定めている。しかし Time Protocol を用いて取得した時刻値にはサーバから機器に時刻値が到達するまでの通信時間が含まれない。よって、取得した時刻値には通信時間に起因する遅れの誤差が含まれてしまいRTCを正しい時刻に同期できない。NTPは通信時間による時刻値の誤差を小さくする工夫がなされた時刻同期のためのプロトコルである。

正確なを選択するために、の修正版であるを使用し、の変化の影響を軽減するように設計されている。NTPは通常、インターネット上で数十ミリ秒以内の時間を維持することができ、理想的な条件の下ではLAN上で1ミリ秒以下に誤差を抑えることができる。非対称なルートやネットワークの輻輳により、100ミリ秒以上のエラーが発生することがある。更に後に追加されたオプション仕様ではNTPインターリーブモードで約5マイクロ秒、ハードウェアタイムスタンプで約100ナノ秒の誤差に抑えることも可能になっている。

このプロトコルは通常、クライアントサーバモデルで記述されるが、相手側をタイムサーバとみなすことでピアツーピアネットワークにおいても使用することができる。実装としては、UDPのポート番号123を使用する。また、ブロードキャストやマルチキャストを使用することもでき、この場合、クライアントは最初に時刻同期のためにサーバと通信した後、時間の更新を受動的に受信することができる。NTPは、直近の閏秒の情報は送信するが、タイムゾーンや夏時間に関する情報は送信しない。

最新のプロトコルバージョンはバージョン4(NTP v4)で、で文書化されている。これはで規定されているバージョン3との後方互換性があり  (SNTP v4) の置き換えでもある。その後も が発行されているが NTP v4 の拡張フィールドとメッセージ認証コードについての補足、認証コードの推奨アルゴリズム変更、ソースポートのランダマイゼーションの推奨と実質的な変更はない。(SNTP v4 については全く触れられていない)

## 歴史

1979年、ニューヨークで開催された全米コンピュータ会議において、大西洋横断衛星ネットワーク上で動作するインターネットサービスの最初の公開デモンストレーションが行われ、ここでネットワーク時刻同期技術が使用された。この技術は後に1981年のInternet Experiment Note (IEN) 173に記述され、公開プロトコルが開発され、で文書化された。この技術は最初、Helloルーティングプロトコルの一部としてLANに展開され、ネットワークプロトタイピングに使用される実験的なオペレーティングシステムであるに実装され、長年にわたって使用された。

その他の関連するネットワークプロトコルは、現在でも使用可能である。その中には、イベントの時刻を記録するためのDAYTIMEプロトコルとTIMEプロトコルや、ICMPのタイムスタンプ、に規定されるIPタイムスタンプがある。より完全な同期システムとしては、UNIXデーモンのtimedがあり、これはリーダー選出アルゴリズムを使って全てのクライアントのためのサーバを指定する。デジタル時刻同期サービス(DTSS)は、NTPの階層モデルに似たサーバの階層を使用している。

1985年、NTPバージョン0(NTPv0)がファズボールとUNIXの両方に実装され、NTPパケットヘッダとラウンドトリップ遅延とオフセットの計算がで文書化された。当時は比較的遅いコンピュータとネットワークしか利用できなかったにもかかわらず、大西洋のスパニングリンクでは通常100ミリ秒以上、イーサネットネットワークでは数十ミリ秒の精度が得られた。

1988年、NTPv1プロトコルのより完全な仕様と関連アルゴリズムがで公開された。この仕様は、実験結果とで文書化されたクロックフィルタアルゴリズムに基づいており、クライアントサーバモードとピアツーピアモードを記述した最初のバージョンだった。1991年、NTPv1のアーキテクチャ、プロトコル、アルゴリズムについてのデイヴィッド・L・ミルズの論文が**'に掲載され、エンジニアのコミュニティ内で広く注目を集めた。

1989年にが発行された。このRFCでは、[[状態機械]]を用いてNTPv2を定義し、その動作を記述するための[[疑似コード]]が含まれている。これは、管理プロトコルと暗号化認証スキームを導入し、アルゴリズムの大部分とともに NTPv4にも引き継がれている。しかし、NTPv2の設計はDTSSのコミュニティから[[正当性 (計算機科学)|正当性]]を欠いていると批判され、クロック選択手順はNTPv3以降でを組み込むように修正された。

1992年にでNTPv3が定義された。このRFCでは、参照クロックから最終的なクライアントに至るまでの全てのエラー発生源の分析が含まれており、これにより、複数の候補の間で一致しないように見える場合に、最適なサーバを選択するのに役立つメトリックの計算が可能になった。また、ブロードキャストモードが導入された。

その後、新しい機能が追加されたり、アルゴリズムが改良されたことにより、新しいプロトコルのバージョンが必要であることが明らかになった 。2010年には、でNTPv4の仕様案が提示された。その後、プロトコルは大きく前進しているが、2014年現在、更新されたRFCはまだ公開されていない。ミルズが大学教授を引退したのに伴い、Harlan Stennが率いる[[オープンソース]]プロジェクトとしてリファレンス実装が維持されている。

== 時刻同期の仕組み ==
=== 処理の概略 ===

NTPプロトコル上では[[協定世界時]] (UTC) を使って時刻を送受信する。

NTPサーバプログラムが他のNTPサーバに接続すると、上位NTPサーバとのネットワーク通信の遅延を継続的に計測し、受け取った時刻情報を補正して自動的にミリ秒単位の精度で自機・OSの時計を校正する。このほか後述するように自機・OSの時計の進み遅れ度合いも校正したり、他のNTPサーバからの問い合わせに応えて時刻も提供する機能が実装されることがある。

===クロック階層===

NTPでは、時間源の階層的システムを使用している。階層の各レベルは''stratum''と呼ばれる。最上位の基準クロックをstratum 0とし、stratum 0に同期しているサーバをstratum 1とする。以降、stratum ''n''に同期しているサーバをstratum ''n''+1とする。この番号は、基準クロックからの距離を表し、階層内での依存関係のループを防ぐために使用される。stratumの値は必ずしも品質や信頼性を示すものではなく、あるstratum 2サーバとstratum 3サーバを比較して、stratum 3サーバの方が高品質ということもあり得る。

以下に、stratum0、1、2、3について簡単に説明する。
; stratum 0
: これは一般に[[原子時計]]やGPS、[[電波時計]]などの高精度の計時装置である。これらのデバイスは、接続されたコンピュータに対し割り込みやタイムスタンプをトリガする非常に正確な毎秒1回のパルスを生成する。stratum 0のデバイスは、リファレンスクロックともいう。
: 重要な仕様として、stratum 0の機器はNTPパケットを自ら送信しない。（詳細は後述）
; Stratum 1
: 接続されているstratum 0デバイスの数マイクロ秒以内に[[システム時刻]]が同期されているコンピュータである。stratum 1サーバは、[[健全性テスト|サニティーチェック]]やバックアップのために、他のstratum 1サーバとピアすることができる。プライマリ・タイムサーバとも呼ばれる。
; Stratum 2
: ネットワークを介してstratum 1サーバに同期しているコンピュータである。多くの場合、stratum 2コンピュータは複数のstratum 1サーバに問い合わせを行う。また、stratum 2コンピュータは、ピアグループ内の他のデバイスに対してより安定した[[ロバストネス|ロバスト]]な時間を提供するために、他のstratum 2コンピュータとピアすることもある。
; Stratum 3
: stratum 2のサーバに同期しているコンピュータである。これらのコンピュータは、ピアリングやデータサンプリングにstratum 2と同じアルゴリズムを採用しており、stratum 4のコンピュータのサーバとして機能することができる。

Stratumの上限は15で、stratum 16はデバイスが非同期であることを示すために使用される。各コンピュータ上のNTPアルゴリズムは、[[ベルマン–フォード法|ベルマン・フォード]]最短経路[[全域木|スパニングツリー]]を構築するために相互に作用し、全てのクライアントからstratum 1サーバへの累積ラウンドトリップ遅延を最小化する。

NTPでは送信元コンピュータのstratumをパケットのヘッダに記述するが、通常の運用ではここに0が記述されることはない。Stratumを0としたNTPパケットは、同期を要求してきたコンピュータに対し、過剰な負荷や運用ポリシー違反、受信側がまだ未同期などの理由によりそれが受け入れられないことを示す目的でパケットを返送する場合に限り用いる。このようなパケットは''Kiss-o'-Death''と呼ばれる。

NTPプロトコルは、stratumのほか、参照識別子(refid、4オクテット)を使用して、各サーバの同期化元を特定することができる。Stratum 1のサーバは、同期しているstratum 0サーバの具体的な実装を最長4文字のASCIIコードにて表現する。以下はRFC5905に定められているもの。



Stratum 2以上(階層としては下層)のサーバは、同期先のNTPサーバのIPアドレスをrefidに記述する。この情報は、NTPサーバ同士で同期先がループするのを防ぐ目的で使用される。IPv4アドレスはそのまま記述するが、IPv6アドレスの場合はそのmd5ハッシュを計算した上で、ハッシュ値の最初の4オクテットを使用する。

パケットがstratum 0、すなわち''Kiss-o'-Death''である場合は、その理由をrefidに記述する。以下は特記されているものを除き、RFC5905に定められているもの。



''Kiss-o'-Death''パケットのうち以下のコードを受信した場合は、受信したホストはコードに応じて以下の対応を執らなければならない。（MUST）
; DENY, RSTR
: そのサーバへの接続を直ちに停止し、パケットの送信を禁止する。
; RATE
: 当該パケットを受信する度に、そのサーバへのポーリング周期を直ちに増加させてパケットのレートを落とす。
; X***
: NTP実装がコードを解釈できない場合、そのパケットを無視する。
; 上記以外
: そのパケットを無視する。

サーバやピアとしての運用を目的としたNTP実装では、接続先から返されたstratumやrefidを確認することにより接続や接続先の同期状況を把握することができるものが多い。この場合、プロトコル上は無視すべき''Kiss-o'-Death''パケットについても接続状況把握のためにrefidを記録する。

===タイムスタンプ===
NTPで使用される64ビットのタイムスタンプは、秒を表す32ビット部分と、秒未満の時間を表す32ビット部分で構成されている。秒未満の時間は、2<sup>-32</sup>秒（233ピコ秒）の理論的な分解能を持っている。秒を表す部分は32ビット符号なし[[整数]]であり、起点（[[紀元|エポック]]）としている[[1900年]][[1月1日]] 0時0分0秒([[協定世界時|UTC]])からの経過秒数を表す。この値は、起点からから2<sup>32</sup>-1秒、すなわち42億9496万7295秒（約136年）で桁あふれする。最初の桁あふれは[[2036年]][[2月7日]] 6時28分15秒の次の秒に発生し、起点と認識されてNTPが誤動作すると予想されている。これを**2036年問題*'という。[[UNIX]]にはこの問題が複数の箇所で今後顕在化するとみられるが（例: [[2038年問題]]）、このNTPについても該当する。

には、最上位ビットが0の場合は時刻が2036年から[[2104年]]の間であるとみなして、2036年2月7日6時28分16秒(UTC)を起点として計算することで2036年問題を回避する方法が書かれている。

NTPv4では128ビットのタイムスタンプが導入されており、秒と秒未満にそれぞれ64ビットを割り当てている。秒を表す64ビットのうち、半分の32ビットは現行のNTPと同じであり、残りの32ビットは、桁あふれの回数を表す*Era Number*（時代番号）である。ミルズによれば、「秒未満の64ビット値は、光子が光速で電子を通過するのにかかる時間を見分けるのに十分な分解能である。もう1つの64ビットの値は、宇宙が薄暗くなる（[[宇宙の終焉]]）までの時間を明確に表現するのに十分である。」

===クロック同期アルゴリズム===

一般的なNTPクライアントは、1つ以上のNTPサーバに対して[[ポーリング (情報)|ポーリング]]を行う。クライアントは、タイムオフセットと[[ラウンドトリップタイム]]を計算する。

タイムオフセット *θ* は、クライアントとサーバのクロック間の絶対時間の差であり、次式で計算される。
:<math>\theta = {(t_1 - t_0) + (t_2 - t_3 ) \over 2}</math>

ラウンドトリップタイム *δ* は、パケットの往復時間からサーバの処理時間を引いたものであり、次式で計算される。
:<math>\delta = {(t_3 - t_0 ) - ( t_2- t_1 )}</math>

ここで、
:*t*<sub>0</sub> は、クライアントがサーバへリクエストを送信した時刻
:*t*<sub>1</sub> は、サーバがクライアントのリクエストを受信した時刻
:*t*<sub>2</sub> は、サーバがクライアントへレスポンスを送信した時刻
:*t*<sub>3</sub> は、クライアントがサーバのレスポンスを受信した時刻
である。

*θ*と*δ*の値はフィルタを通過し、統計的分析が行われる。[[外れ値]]は破棄され、残りの候補の中で最も優れた3つの候補から時間オフセットの推定値が導出される。その後、オフセットが徐々に減少するようにクロック周波数が調整され、[[フィードバック]]ループを形成する。

正確な同期化は、往路と復路の通信時間がほぼ等しい場合に達成される。両者に差がある場合は、その差の2分の1が誤差になる可能性がある。極端な例では、通信の往復に合計10秒掛かった場合に最大で約5秒の誤差が発生する。

=== 運用 ===
NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている（RFC4330による）。

[[Local Area Network|LAN]]内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器を用意し、この機器（内部NTPサーバ）をプロバイダなどの外部NTPサーバに接続し、各クライアントはこの内部NTPサーバに接続する設定を行うと良い。

ルーターやクライアントパソコンなどのネットワーク上の各機器では、前述のようなNTPサーバにアクセスして、機器内部の時計の時刻をNTPサーバの時刻に合わせることで内部時計の誤差が少なくなる。

=== 周波数ドリフトの修正 ===
NTPサーバの実装の多くでは、時刻の校正のみならず、長期的な時計の進み遅れの原因となるクロック周波数ドリフトの校正も行う。周波数ドリフトの校正は、原理的には[[位相同期回路|PLL]]やと同じ動作により実施する。

一般的にコンピュータ内部の時計は、ハードウェアの時計が提供する時刻をそのまま利用する場合と、割り込みなどによりソフトウェア的に時計を進める場合がある。いずれの場合も、設計状態での時計は数ppm以上（1ppmは百万分の一、およそ10日で1秒程度の精度）の狂いがあるため、他のNTPサーバからの時刻と自機の時計を数回比較した後、時計の進み遅れの度合い（ドリフト）も修正する必要がある。さらに気温変動など外乱要因による2次以上のドリフト（上述した進み遅れ度合いの変化）も存在するが、多くのNTPサーバでは一次補正（直線的なドリフトの補正）を行う実装にとどまる。

求まった周波数ドリフトの修正値は、ファイルなどの永続的なストレージに記録し、NTPサーバを再起動した際にすぐに再利用できるようにする。MHzオーダの周波数にて動作し、マイクロ秒やミリ秒オーダで周波数が同期できるPLLやDLLと異なり、NTPにおける周波数ドリフトの校正には数十秒から数千秒程度の時間を要するため、安定した校正を短時間で実現する手法として修正値の保存が必要となる。

周波数ドリフトの修正が必要となる重要な理由として、NTPサーバプログラムを用いてコンピュータの時刻の校正を行う場合、突然『もっともらしい時刻』に校正すると予期せぬ挙動が生じる恐れがあることがある。サーバ機能を提供しているコンピュータでは、時刻が飛ぶことにより、定時に実行されるサービス（UNIXのcron・atなど）が実行されなくなったり（時計を進める場合）同じサービスが2回実行される（時計を遅らせる場合）ことがあるからである。したがって、ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。また、周波数ドリフトを校正することにより上流サーバへの時刻同期周期を増やし、上流サーバやネットワークへの負荷を軽減する効果もある。

=== 閏秒の扱い ===
NTPプロトコルでは、電波時計の時刻送信フォーマットのように[[閏秒]]の扱いも規定されている。閏秒の挿入または削除が行われるという通知は、設定ファイル、参照クロック、リモートサーバのいずれかから受け取る。参照クロックやリモートサーバから受け取る場合は、NTPパケット内の閏秒の警告情報のフィールドが使用される。

警告情報を受け取った側がどう処理するかは、[[コンピュータプログラム]]の実装に任される。しかし、削除された1秒に自動起動するサービスがあるかもしれなかったり、外部要因で日付が変わると無効になるライセンスがありえたりするため注意が必要である。

leap smearingと呼ばれる実装では、一秒挿入するのではなく、閏秒の前後20時間をかけて、ゆっくり一秒分の時間を伸ばすことで問題を回避している。この実装は、[[Google]]（内部的にも公開NTPサーバー上でも）と[[Amazon Web Services|Amazon AWS]]によって使用されている。

==実装==


=== 下位プロトコル ===
通常、NTPは[[User Datagram Protocol|UDP]]上で動作する。UDPのポートは123番を使用する。ルータのパケットフィルタの設定でポート123番を通さないようにしている場合は、外部のNTPサーバにアクセスできなくなるので、通すように設定する必要がある

===リファレンス実装===
NTPの[[リファレンス実装]]は、プロトコルとともに20年以上にわたって継続的に開発されてきた。新しい機能が追加されても、後方互換性が維持されてきた。これには、特にクロックを規律するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用しているサーバに同期させると誤動作する可能性がある。このソフトウェアは、パーソナルコンピュータを含むほぼ全てのプラットフォームに移植されている。UNIXではという[[デーモン (ソフトウェア)|デーモン]]として、Windowsでは[[Windowsサービス|サービス]]として動作する。基準クロックにも対応しており、そのオフセットはリモートサーバと同じようにフィルタリングされ、分析されるが、通常はより頻繁にポーリングされる。この実装は2017年に検査され、多数の潜在的なセキュリティ問題が発見された。

===SNTP===

[[Simple Network Time Protocol]] (SNTP)は、NTPと同じプロトコルを使用するが、長時間の状態の保存を必要としない、NTPのサブセットの実装である。[[組み込みシステム]]や、完全なNTP機能が必要とされないアプリケーションで使用される。

===Windows===
[[Windows NT]]では[[Server Message Block|SMB]]プロトコルを使ったnet timeコマンドによる時刻同期が可能であったが、これはNTPではなかった。またそれ以前のWindowsでは、[[サードパーティー]]のソフトウェアを使用する必要があり、日本では、Windowsが本格的にインターネット対応を開始した1990年代後半に「[[桜時計]]」と呼ばれる、サードパーティーによるNTPの実装が有名になった。

[[Windows 2000]]以降の[[Windows]]には、コンピュータの時計をNTP サーバに同期させる機能を持つWindows Timeサービス (W32Time)が含まれている。W32Timeは元々[[ケルベロス認証]]バージョン5のために実装されたものである。ケルベロス認証では、[[反射攻撃]]への対抗として、タイムスタンプに含まれる時間が正確な時間から5分以内である必要があった。

[[Windows 2000]]と[[Windows XP]]ではSNTPのみを実装しており、NTPバージョン3に対してはいくつかの規約に違反している。[[Windows Server 2003]]と[[Windows Vista]]からは、フルセットのNTPに準拠した実装となり、GUIで時刻同期を設定することができるようになった。また、有志によってビルドされたWindows向けのntpd/ntpdateも公開されている。

マイクロソフトは、W32Timeは1秒の精度でしか時刻同期を確実に維持できないと声明している。より高い精度が必要な場合は、Windowsの新しいバージョンを使用するか、別のNTP実装を使用することを勧めている。[[Windows 10]]と[[Windows Server 2016]]では、特定の動作条件の下で1ミリ秒の時間精度の同期に対応している。

=== UNIXなど ===
====OpenNTPD====
2004年、Henning Brauerは、セキュリティに焦点を当てて特権分離設計としたNTPの実装である[[OpenNTPD]]を発表した。これは、[[OpenBSD]]ユーザのニーズに密着したものである一方で、 既存のNTPサーバとの互換性を保ちつつ、いくつかのプロトコルセキュリティの改善も含まれている。移植版は、[[Linux]]のパッケージリポジトリで入手可能である。

====ntimed====
新しいNTPクライアントであるntimedが、によって2014年に開始された。この実装は、リファレンス実装の代替として[[Linux Foundation]]がスポンサーとなっている。リファレンス実装を元にするより、新しい実装をゼロから書いた方が簡単であると判断されたためである。公式にはリリースされていないが、ntimedは確実にクロックを同期させることができる。

====NTPsec====
NTPsecは、リファレンス実装を[[フォーク (ソフトウェア開発)|フォーク]]し、体系的に[[ハードニング|セキュリティを強化]]した実装である。フォークポイントは2015年6月で、2014年に発生した危殆化した脆弱性への対応が行われた。最初の正式版は2017年10月にリリースされた。安全ではない機能の削除、時代遅れのハードウェアやUNIXバリアントへの対応の削除により、元のソースコードの75%を削除し、残りの部分を検査を受けやすくした。2017年のコードの検査では、リファレンス実装にはなかった2つを含む8つのセキュリティ問題が検出されたが、元のリファレンス実装に残っていた他の8つの問題の影響を受けることがなかった。

====chrony====

[[chrony]]は、[[Red Hat]]のディストリビューションにデフォルトで搭載されており、[[ubuntu]]のリポジトリでも利用可能である。chronyは、不安定でスリープモードになったり、インターネットに断続的に接続したりするような一般的なコンピュータを対象としている。また、より不安定な環境である[[仮想マシン]]用にも設計されている。リソース消費量（コスト）が少ないのが特徴で、NTPだけでなく、[[Precision Time Protocol]](PTP)にも対応している。主なコンポーネントは、コンピュータの起動時に実行されるデーモンであるchronydと、その設定のためのコマンドラインインターフェースであるchronycの2つである。

chronycは非常に安全で、数件の事故があっただけだが、その利点は、不必要な複雑さを避けるためにゼロから書かれたコードの汎用性にある。

chronyは[[GNU General Public License]] version 2で利用可能である。1997年にRichard Curnowによって作成され、現在はMiroslav Lichvarによってメンテナンスされている。

=== Mac ===
[[macOS]] においても、標準でntpd/ntpdateが使用されていて、コマンドを意識せず[[グラフィカルユーザインタフェース|GUI]]から設定できる。以前の[[Classic Mac OS#Mac OS 9|Mac OS 9]]でもNTPクライアントは標準で組み込まれていた。

=== その他 ===
また、[[ルーター]]や[[スイッチングハブ]]などのネットワーク機器にNTPサーバが搭載される場合がある。もともとは高級なネットワーク機器に搭載される機能であったが、ネットワーク普及に伴う機器の低価格化により、[[2000年代]]後半には民生用のネットワーク機器においてもNTPサーバが搭載されている。

== 運用と諸問題 ==

前述の通りNTPは階層構造を採用しているため、[[負荷分散]]が行えるように工夫されている。しかし、NTPと同じく階層構造を採用する[[Domain Name System|DNS]]では[[Dynamic Host Configuration Protocol|DHCP]]や[[Point-to-Point Protocol|PPP]]によるDNSサーバアドレス配信の仕組みが普及しているのに対し、NTPではDHCPではオプション42として、DHCPv6ではオプション56としてNTPサーバアドレス配信の仕組みが定義されているものの、2024年3月現在ほとんど利用されていない。よって、[[エンドユーザー]]は自ネットワーク内のNTPサーバの存在を知ることができず、エンドユーザーが stratum 1 の公開 NTP サーバを使用する傾向がある。結果的に、一つのNTPサーバにアクセスが集中するためサーバの応答性を下げ、配信される時刻の正確性が失われる。

この問題に対する国際的なプロジェクトとして、[https://www.ntppool.org/ja/ 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サーバーのどれかがランダムに選ばれる。プールされているサーバーのアドレスは、2022年10月現在、全世界で4665、日本国内については44である。なお、このプロジェクトはエンドユーザーからのアクセスを分散することを主目的としているため、プールされているNTPサーバーには、stratum 3や4も含まれている。

Windows や macOS の初期設定サーバは混雑しているため、[[インターネットサービスプロバイダ|ISP]]提供のサーバや、上記のNTPプール、あるいは後述の[[#公開NTPサーバ|公開NTPサーバ]]等に変更すると、より正確な時刻取得が可能になる。

日本では情報通信研究機構 ([[NICT]]) が世界最高性能のNTPサーバ (ntp.nict.jp) を2006年6月より一般公開したので、負荷に起因する問題は解決の方向へ向かうと思われる。NICTによれば、世界中のNTPリクエストを合計しても数万リクエスト/秒程度なので、100万リクエスト/秒を扱える新しいシステムでは負荷の問題ではなく知名度の低さが問題としている。

*Kiss-o'-Death''パケットの運用は、受信側がそれを仕様通りに処理することに依存している。実装ミス、意図的を問わず、これを仕様通りに処理しない実装に対してNTPは無防備であり、パケットフィルタリングなど別の手段を用いた検出や対応が必要となることがある。

### clock.nc.fukuoka-u.ac.jp問題
日本では、福岡大学が1993年（平成5年）からNTPサーバを公開しているが、ここを参照するように設定された機器や組み込まれたソフトウェアが非常に多いため、アクセス集中による過負荷に悩まされていることが、2005年に報告された。

2017年現在も、福岡大学NTPサーバへのデータトラフィックは過大な状態が続いており、平均180Mbpsに達している。アクセス過多の原因の一つとして、一部メーカーのネットワーク機器のファームウェアに福岡大学NTPサーバのIPアドレスが埋め込まれていることが挙げられている。一例として、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であると特定された。

同年6月16日、大学側はネットギアのカスタマーサポート宛に電子メールにて状況の報告を行ったが返答がないため直接交渉を行い、19日にネットギアから「開発者によるデバッグ時の設定値の残骸が引き起こしたもの」との説明が大学側に報告され、協力体制が整備された。

2003年8月の時点において、影響を受けた生産台数70万台から行われる最大毎秒70万パケットに及ぶリスクに対して、大学側はルーター使用者に影響がでないよう配慮し、ネットギアからはファームウェアのバージョンアップが提供された。これによりウィスコンシン大学の転送量の増加傾向は弱くなり、同年11月からは減少傾向に転じることとなった。

なお、これらの事件の詳細は、2003年8月21日にウィスコンシン大学のDave Plonkaによりまとめられている。

他に、FreeBSDの有力開発者であるPoul-Henning Kamp(phk)が発見したD-link製ルータの問題や、ダブリンのTardis and Trinity Collegeの問題など、同様の問題が発生している。を参照のこと。

## 脚注

### 注釈

### 出典

## 参考文献
* 
* 

## 関連項目
* アラン分散
* 
* 国際原子時
* 
* 
* 
* 
* Precision Time Protocol (IEEE 1588 PTP)
* 

## 外部リンク
* NTP Project
* Windows用のNTPサーバーソフトウェア
* NTP Server Test Online

### 公開NTPサーバ
* Public NTP Time Server Lists ntp.orgによる公開サーバリスト
** Stratum One Time Servers stratum 1サーバ
** Stratum Two Time Servers stratum 2サーバ
** NTP Pool Time Servers ntp.orgによるプールサーバリスト。全世界共通のものの他に、大陸毎、国毎のプールサーバが存在する。

#### 日本国内
* 時刻情報提供サービス for Public -  インターネットマルチフィード(MFEED)による、stratum 2のNTPサービス。国内の多くのISPと直接接続されているためネットワーク的に近い。
* NICT 公開NTPサービス  - 日本標準時に直結されたstratum 1のNTPサービス。国内の多くのISPからはホップ数やpingの応答の面で不利。
* NTP service : ntp.ring.gr.jp -  Ring Server Project参加組織提供によるプールサーバ。stratumは2から4。
* NTP - wiki@nothing - 日本国内のISPや研究機関等のNTPサーバおよび公開NTPサーバの情報をまとめている。