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を使用するPage 16RFC1700のWELL KNOWN PORT NUMBERSではTCPとUDPの2つが指定されているが、NTPの規格を示したRFC1305ではUDPのみとなっている。。また、ブロードキャストやマルチキャストを使用することもでき、この場合、クライアントは最初に時刻同期のためにサーバと通信した後、時間の更新を受動的に受信することができる。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に定められているもの。
+ 共通時間参照識別子(refid)コード 参照識別子 (refid) 時間源 GOES Geosynchronous Orbit Environment Satellite（アメリカの気象衛星） GPS グローバル・ポジショニング・システム GLN GLONASS (ロシアの測位システム。ntp.ix.ruなどの時間源) GAL ガリレオ（ヨーロッパの測位システム） PPS 毎秒1パルス(pps)の時間源を表す汎用コード IRIG 射程間計装グループ(IRIG) WWVB 長波標準電波 WWVB（アメリカ合衆国・コロラド州フォートコリンズ 60 kHz） DCF 長波標準電波 DCF77（ドイツ・ 77.5 kHz） HBG 長波標準電波 （スイス・ 75 kHz（運用中止）） MSF 長波標準電波 MSF（イギリス・ 60 kHz） JJY 長波標準電波 JJY（日本・福島県田村市 40 kHz、佐賀県佐賀市 60 kHz） LORC 100 kHz TDF 中波標準電波 （フランス・ 162 kHz） CHU 短波標準電波 （カナダ・オンタリオ州オタワ） WWV 短波標準電波 WWV（アメリカ合衆国・コロラド州フォートコリンズ） WWVH 短波標準電波 WWVH（アメリカ合衆国・ハワイ州カウアイ） NIST アメリカ国立標準技術研究所(NIST)電話報時サービス ACTS NIST電話報時サービス USNO アメリカ海軍天文台(USNO)電話報時サービス PTB (PTB)電話報時サービス MRS 複数の参照源
Stratum 2以上(階層としては下層)のサーバは、同期先のNTPサーバのIPアドレスをrefidに記述する。この情報は、NTPサーバ同士で同期先がループするのを防ぐ目的で使用される。IPv4アドレスはそのまま記述するが、IPv6アドレスの場合はそのmd5ハッシュを計算した上で、ハッシュ値の最初の4オクテットを使用する。
パケットがstratum 0、すなわちKiss-o'-Deathである場合は、その理由をrefidに記述する。以下は特記されているものを除き、RFC5905に定められているもの。
+ Kiss-o'-Deathパケットの共通時間参照識別子(refid)コード 参照識別子 (refid) 理由 ACST ユニキャスト用サーバに、ユニキャスト以外の手段で接続しようとした。 AUTH 接続認証に失敗。 AUTO Autokey の実行に失敗。 BCST ブロードキャスト用サーバに、ブロードキャスト以外の手段で接続しようとした。 CRYP 暗号を用いた認証処理に失敗。 DENY アクセス拒否。 DROP ピアリング接続を失った。 RSTR ポリシー違反に基づくアクセス拒否。 INIT サーバが起動直後で、自身がまだ他のNTPサーバ等に同期していない。 MCST 動的サーバ発見用のマルチキャスト用サーバに、マルチキャスト以外の手段で接続しようとした。 NKEY 認証用の鍵が設定されていない、ないしはこれを信頼していない。 RATE レート制限を超えるNTPパケットを受信した。 RMOT サーバの設定変更により接続できなくなった。RFC5905ではこのコードの説明にコマンド名ntpdcが含まれており、リファレンス実装に依存した説明になってしまっている。 STEP サーバの時刻がステップ的に変更され、まだ再同期していない。（オフセットはステップ閾値（125ミリ秒）以上、パニック閾値（1000秒）以下） X*** 実験用。*は任意の文字。 XFAC インターフェイス連携が変更された（IPアドレスの変更または喪失）。実験用コードの一部であり、RFC5909では定義されていない。
Kiss-o'-Deathパケットのうち以下のコードを受信した場合は、受信したホストはコードに応じて以下の対応を執らなければならない。（MUST） DENY, RSTR そのサーバへの接続を直ちに停止し、パケットの送信を禁止する。 RATE 当該パケットを受信する度に、そのサーバへのポーリング周期を直ちに増加させてパケットのレートを落とす。 X*** NTP実装がコードを解釈できない場合、そのパケットを無視する。 上記以外 そのパケットを無視する。
サーバやピアとしての運用を目的としたNTP実装では、接続先から返されたstratumやrefidを確認することにより接続や接続先の同期状況を把握することができるものが多い。この場合、プロトコル上は無視すべきKiss-o'-Deathパケットについても接続状況把握のためにrefidを記録する。
タイムスタンプ NTPで使用される64ビットのタイムスタンプは、秒を表す32ビット部分と、秒未満の時間を表す32ビット部分で構成されている。秒未満の時間は、2-32秒（233ピコ秒）の理論的な分解能を持っている。秒を表す部分は32ビット符号なし整数であり、起点（エポック）としている1900年1月1日 0時0分0秒(UTC)からの経過秒数を表す。この値は、起点からから232-1秒、すなわち42億9496万7295秒（約136年）で桁あふれする。最初の桁あふれは2036年2月7日 6時28分15秒の次の秒に発生し 3. NTP Timestamp Format、起点と認識されて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ビットの値は、宇宙が薄暗くなる（宇宙の終焉）までの時間を明確に表現するのに十分である。」University of Delaware Digital Systems Seminar presentation by David Mills, 2006-04-26
クロック同期アルゴリズム
一般的なNTPクライアントは、1つ以上のNTPサーバに対してポーリングを行う。クライアントは、タイムオフセットとラウンドトリップタイムを計算する。
タイムオフセット θ は、クライアントとサーバのクロック間の絶対時間の差であり、次式で計算される。
ラウンドトリップタイム δ は、パケットの往復時間からサーバの処理時間を引いたものであり、次式で計算される。
ここで、 t0 は、クライアントがサーバへリクエストを送信した時刻 t1 は、サーバがクライアントのリクエストを受信した時刻 t2 は、サーバがクライアントへレスポンスを送信した時刻 t3 は、クライアントがサーバのレスポンスを受信した時刻 である。
θとδの値はフィルタを通過し、統計的分析が行われる。外れ値は破棄され、残りの候補の中で最も優れた3つの候補から時間オフセットの推定値が導出される。その後、オフセットが徐々に減少するようにクロック周波数が調整され、フィードバックループを形成する。
正確な同期化は、往路と復路の通信時間がほぼ等しい場合に達成される。両者に差がある場合は、その差の2分の1が誤差になる可能性がある。極端な例では、通信の往復に合計10秒掛かった場合に最大で約5秒の誤差が発生する。
運用 NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている（RFC4330による）。
LAN内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器もしルーターなどで提供できなければ、NTPサービス提供専用の古いパソコンをセットアップしても良いし、またサーバ的な存在になっている既存のパソコン等に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秒に自動起動するサービスがあるかもしれなかったり、外部要因で日付が変わると無効になるライセンスがありえたりするため注意が必要である安藤幸央のランダウン44 時を欠ける症状-うるう秒から考えるサステナビリティ アットマーク・アイティ 2011年10月4日閲覧。
leap smearingと呼ばれる実装では、一秒挿入するのではなく、閏秒の前後20時間をかけて、ゆっくり一秒分の時間を伸ばすことで問題を回避しているMaking every (leap) second count with our new public NTP servers。この実装は、Google（内部的にも公開NTPサーバー上でも）とAmazon AWSによって使用されている。
実装
下位プロトコル 通常、NTPはUDP上で動作する。UDPのポートは123番を使用する。ルータのパケットフィルタの設定でポート123番を通さないようにしている場合は、外部のNTPサーバにアクセスできなくなるので、通すように設定する必要がある
リファレンス実装 NTPのリファレンス実装は、プロトコルとともに20年以上にわたって継続的に開発されてきた。新しい機能が追加されても、後方互換性が維持されてきた。これには、特にクロックを規律するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用しているサーバに同期させると誤動作する可能性がある。このソフトウェアは、パーソナルコンピュータを含むほぼ全てのプラットフォームに移植されている。UNIXではというデーモンとして、Windowsではサービスとして動作する。基準クロックにも対応しており、そのオフセットはリモートサーバと同じようにフィルタリングされ、分析されるが、通常はより頻繁にポーリングされる。この実装は2017年に検査され、多数の潜在的なセキュリティ問題が発見された。
SNTP
Simple Network Time Protocol (SNTP)は、NTPと同じプロトコルを使用するが、長時間の状態の保存を必要としない、NTPのサブセットの実装である。組み込みシステムや、完全なNTP機能が必要とされないアプリケーションで使用される。
Windows Windows NTでは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も公開されているMeinberg NTP Software Downloads。
マイクロソフトは、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