Network Time Protocolのソースを表示

{{混同|DAYTIMEプロトコル|TIMEプロトコル|Network News Transfer Protocol}}
{{Infobox networking protocol
|       title = Network Time Protocol
|        logo = 
|    logo alt = 
|       image = 
|   image alt = 
|     caption = 
|    is stack = no
|     purpose = [[時刻同期]]
|   developer = [[デイヴィッド・L・ミルズ]]
|        date = <!-- {{Start date and age|1971|04|16}} -->
|    based on = 
|  influenced = 
|    osilayer = 
|       ports = 123
|        rfcs = {{IETF RFC|1305}}
|    hardware = 
}}
{{IPstack}}
'''Network Time Protocol'''（ネットワーク・タイム・プロトコル、'''NTP'''）は、[[パケット通信|パケット交換]]による[[レイテンシ|遅延時間]]が変動する[[コンピュータネットワーク|ネットワーク]]上のコンピュータシステム間で[[時刻同期]]させるための[[通信プロトコル]]である。1985年以前から運用されており、現在使用されている中で最も古いインターネットプロトコルの1つである。NTPは、[[デラウェア大学]]の[[デイヴィッド・L・ミルズ]]によって設計された。NTPによって提供される数[[ミリ秒]]以下の[[誤差]]の[[クロック同期|時刻同期]]は、[[情報システム]]において[[時刻]]で管理される様々な[[データ]]や[[処理]]の[[整合性]]を保つために必要である。

== 概要 ==
NTPは、全ての参加コンピュータを[[協定世界時]](UTC)の数[[ミリ秒]]以内の時刻に[[同期 (計算機科学)|同期]]させることを目的としている<ref name="Mills2010" />{{rp|3}}。

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

正確な{{仮リンク|タイムサーバ|en|Time server}}を選択するために、{{仮リンク|マルズーロのアルゴリズム|en|Marzullo's algorithm}}の修正版である{{仮リンク|交差アルゴリズム|en|Intersection algorithm}}を使用し、{{仮リンク|ネットワーク遅延|en|Network delay}}の変化の影響を軽減するように設計されている。NTPは通常、インターネット上で数十ミリ秒以内の時間を維持することができ、理想的な条件の下ではLAN上で1ミリ秒以下に誤差を抑えることができる。非対称なルートやネットワークの[[輻輳]]により、100ミリ秒以上のエラーが発生することがある<ref name="summary">{{cite web |url=http://www.eecis.udel.edu/~mills/exec.html |title=Executive Summary: Computer Network Time Synchronization |accessdate=2011-11-21}}</ref><ref name="faq">{{cite web |url=http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK |title=NTP FAQ |publisher=The NTP Project |accessdate=2011-08-27}}</ref>。更に後に追加されたオプション仕様ではNTPインターリーブモードで約5マイクロ秒<ref name=":0" />、ハードウェアタイムスタンプで約100ナノ秒<ref name=":1" />の誤差に抑えることも可能になっている。

このプロトコルは通常、[[クライアントサーバモデル]]で記述されるが、相手側をタイムサーバとみなすことで[[Peer to Peer|ピアツーピア]]ネットワークにおいても使用することができる<ref name="Mills2010" />{{Rp|20}}。実装としては、[[User Datagram Protocol|UDP]]の[[ポート番号]]123を使用する<ref name=":0">{{cite web |url= http://www.iana.org/assignments/port-numbers |title=Port Numbers |publisher= The Internet Assigned Numbers Authority (IANA)|accessdate=2020-06-24}}</ref><ref name=":1">[https://datatracker.ietf.org/doc/html/rfc5905 Page 16]</ref><ref group="注釈">RFC1700のWELL KNOWN PORT NUMBERSではTCPとUDPの2つが指定されているが、NTPの規格を示したRFC1305ではUDPのみとなっている。</ref>。また、[[ブロードキャスト]]や[[マルチキャスト]]を使用することもでき、この場合、クライアントは最初に時刻同期のためにサーバと通信した後、時間の更新を受動的に受信することができる<ref name=faq/>。NTPは、直近の[[閏秒]]の情報は送信するが、[[時刻帯|タイムゾーン]]や[[夏時間]]に関する情報は送信しない<ref name="summary" /><ref name="faq" />。

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

==歴史==
[[File:DL Mills-2.jpg|thumb|upright|NTPを開発した[[デイヴィッド・L・ミルズ]]]]
{{Graphical timeline
|title=NTP関連の[[Request for Comments|RFC]]の履歴
|align=left
|plot-colour=#bbeebb
|from=1977
|to=2023
|scale-increment=5
|width=18
|height=500
|height-unit=px
|bar1-text=<nowiki>RFC&nbsp;958</nowiki><ref name = "RFC958 NTP" />
 |bar1-from=1985 | bar1-to=1988 | bar1-left=0.10 | bar1-right=0.50
|bar2-text=<nowiki>RFC&nbsp;1059</nowiki><ref name = "RFC1059 NTP v1" />
 |bar2-from=1988 | bar2-to=1989 | bar2-left=0.10 | bar2-right=0.50
|bar3-text=<nowiki>RFC&nbsp;1119</nowiki><ref name = "RFC1119 NTP v2" />
 |bar3-from=1989 | bar3-to=1992 | bar3-left=0.10 | bar3-right=0.50
|bar4-text=<nowiki>RFC&nbsp;1305</nowiki><ref name = "RFC1305 NTP v3" />
 |bar4-from=1992 | bar4-to=2010 | bar4-left=0.10 | bar4-right=0.50
|bar5-text=<nowiki>RFC&nbsp;5905</nowiki><ref name = "RFC5905 NTP v4" />
 |bar5-from=2010 | bar5-to=2016 | bar5-left=0.10 | bar5-right=0.50
|bar6-text=<nowiki>RFC&nbsp;7822</nowiki><ref name = "RFC7822 NTP v4" />
 |bar6-from=2016 | bar6-to=2022 | bar6-left=0.10 | bar6-right=0.50
|bar7-text =<nowiki>RFC&nbsp;1361</nowiki><ref name = "RFC1361 SNTP v3" />
 |bar7-from=1992  | bar7-to=1995  | bar7-left=0.60  |bar7-right=0.95
|bar8-text =<nowiki>RFC&nbsp;1769</nowiki><ref name = "RFC1769 SNTP v3" />
 |bar8-from=1995  | bar8-to=1996  | bar8-left=0.60  |bar8-right=0.95
|bar9-text =<nowiki>RFC&nbsp;2030</nowiki><ref name = "RFC2030 SNTP v4" />
 |bar9-from=1996  | bar9-to=2006  | bar9-left=0.60  |bar9-right=0.95
|bar10-text=<nowiki>RFC&nbsp;4330</nowiki><ref name = "RFC4330 SNTP v4" />
 |bar10-from=2006 | bar10-to=2010 | bar10-left=0.60 |bar10-right=0.95
|bar11-text=<nowiki>RFC&nbsp;5905 </nowiki><ref name = "RFC5905 NTP v4" />
 |bar11-from=2010 | bar11-to=2022 | bar11-left=0.60 |bar11-right=0.95
|note1=DCNET Internet Clock Service<ref name = "RFC778" /> | note1-at=1981 | note1-colour=green 
|note2=SNTP | note2-at=1992 | note2-colour=blue
|bar80-text=SNTP
RFCs|bar80-from=1980|bar80-to=1992|bar80-left=.6|bar80-right=.95|bar79-left=.10|bar79-right=.5|bar79-from=1980|bar79-to=1985|bar79-text=NTP
RFCs}}
1979年、ニューヨークで開催された全米コンピュータ会議において、大西洋横断衛星ネットワーク上で動作する[[インターネット]]サービスの最初の公開デモンストレーションが行われ、ここでネットワーク時刻同期技術が使用された。この技術は後に1981年の[[Internet Experiment Note]] (IEN) 173<ref>{{citation |url=http://www.cis.ohio-state.edu/htbin/ien/ien173.html |archive-url=https://web.archive.org/web/19961230073104/http://www.cis.ohio-state.edu/htbin/ien/ien173.html |archive-date=1996-12-30 |title=Time Synchronization in DCNET Hosts |author=D.L. Mills |date=25 February 1981}}</ref>に記述され、公開プロトコルが開発され、{{IETF RFC|778}}で文書化された。この技術は最初、Helloルーティングプロトコルの一部としてLANに展開され、ネットワークプロトタイピングに使用される実験的なオペレーティングシステムである{{仮リンク|ファズボールルータ|en|Fuzzball router}}に実装され、長年にわたって使用された。

その他の関連するネットワークプロトコルは、現在でも使用可能である。その中には、イベントの時刻を記録するための[[DAYTIMEプロトコル]]と[[TIMEプロトコル]]や、[[Internet Control Message Protocol|ICMP]]の[[Internet Control Message Protocol#Timestamp|タイムスタンプ]]、{{IETF RFC|781}}に規定されるIPタイムスタンプがある。より完全な同期システムとしては、UNIXデーモンのtimedがあり、これは[[リーダー選出]]アルゴリズムを使って全てのクライアントのためのサーバを指定する<ref>{{citation |url=http://www.skrenta.com/rt/man/timed.8.html |title=TIMED(8) |work=UNIX System Manager's Manual |access-date=2017-09-12}}</ref>。デジタル時刻同期サービス(DTSS)は、NTPの階層モデルに似たサーバの階層を使用している。

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

1988年、NTPv1プロトコルのより完全な仕様と関連アルゴリズムが{{IETF RFC|1059}}で公開された。この仕様は、実験結果と{{IETF RFC|956}}で文書化されたクロックフィルタアルゴリズムに基づいており、クライアントサーバモードとピアツーピアモードを記述した最初のバージョンだった。1991年、NTPv1のアーキテクチャ、プロトコル、アルゴリズムについての[[デイヴィッド・L・ミルズ]]の論文<ref>{{Cite journal |title=Intern Time Synchronization: The Network Time Protocol |journal=IEEE Transactions on Communications |date=October 1991 |volume=39 |pages=1482–1493 |number=10 |url=http://www3.cs.stonybrook.edu/~jgao/CSE590-spring11/91-ntp.pdf |author=David L. Mills |doi=10.1109/26.103043}}</ref>が''{{仮リンク|IEEE Transactions on Communications|en|IEEE Transactions on Communications}}''に掲載され、エンジニアのコミュニティ内で広く注目を集めた。

1989年に{{IETF RFC|1119}}が発行された。このRFCでは、[[状態機械]]を用いてNTPv2を定義し、その動作を記述するための[[疑似コード]]が含まれている。これは、管理プロトコルと暗号化認証スキームを導入し、アルゴリズムの大部分とともに NTPv4にも引き継がれている。しかし、NTPv2の設計はDTSSのコミュニティから[[正当性 (計算機科学)|正当性]]を欠いていると批判され、クロック選択手順はNTPv3以降で{{仮リンク|マルズーロのアルゴリズム|en|Marzullo's algorithm}}を組み込むように修正された<ref>{{cite web |title=RFC 1305 |url=https://datatracker.ietf.org/doc/html/rfc1305 |website=IETF: Internet Engineering Taskforce |publisher=IETF |accessdate=6 December 2019 |quote=The clock-selection procedure was modified to remove the first of the two sorting/discarding steps and replace with an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service. These changes do not significantly affect the ordinary operation of or compatibility with various versions of NTP, but they do provide the basis for formal statements of correctness.}}</ref>。

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

その後、新しい機能が追加されたり、アルゴリズムが改良されたことにより、新しいプロトコルのバージョンが必要であることが明らかになった<ref name="MillsES">{{cite book|author=David L. Mills|title=Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space, Second Edition|url=https://books.google.com/books?id=BxTOBQAAQBAJ&pg=PA377|date=15 November 2010|publisher=CRC Press|isbn=978-1-4398-1464-2|pages=377}}</ref> 。2010年には、{{IETF RFC|5905}}でNTPv4の仕様案が提示された。その後、プロトコルは大きく前進しているが、2014年現在、更新されたRFCはまだ公開されていない<ref>{{citation| url=https://www.eecis.udel.edu/~mills/ntp.html| title=Network Time Synchronization Research Project| accessdate=24 December 2014 |section=Future Plans}}</ref>。ミルズが大学教授を引退したのに伴い、Harlan Stennが率いる[[オープンソース]]プロジェクトとしてリファレンス実装が維持されている<ref>{{cite web| url=http://www.informationweek.com/cloud/infrastructure-as-a-service/ntp-needs-money-is-a-foundation-the-answer/d/d-id/1319557| title=NTP Needs Money: Is A Foundation The Answer?| work=[[InformationWeek]]| date=March 23, 2015| accessdate=April 4, 2015}}</ref><ref>{{cite web| url=http://www.informationweek.com/it-life/ntps-fate-hinges-on-father-time/d/d-id/1319432?cmp=em-prog-na-na-newsltr_20150313_control&imm_mid=0ce65e&page_number=2| title=NTP's Fate Hinges On 'Father Time'| work=[[InformationWeek]]| date=March 11, 2015| accessdate=April 4, 2015}}</ref>。

== 時刻同期の仕組み ==
=== 処理の概略 ===
{{節スタブ}}
NTPプロトコル上では[[協定世界時]] (UTC) を使って時刻を送受信する。

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

===クロック階層===
[[File:Network Time Protocol servers and clients.svg|thumb|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 1
: 接続されているstratum 0デバイスの数マイクロ秒以内に[[システム時刻]]が同期されているコンピュータである。stratum 1サーバは、[[健全性テスト|サニティーチェック]]やバックアップのために、他のstratum 1サーバとピアすることができる<ref name=cisco>{{cite web| url=http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml| title=Network Time Protocol: Best Practices White Paper| accessdate=15 October 2013}}</ref>。プライマリ・タイムサーバとも呼ばれる<ref name=summary/><ref name=faq/>。
; 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サーバへの累積ラウンドトリップ遅延を最小化する<ref name="Mills2010" />{{rp|20}}。

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

{| class="wikitable sortable"
|+ 共通時間参照識別子(refid)コード
|-
! '''参照識別子''' (refid)<ref>{{cite web|url=https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831|title='ntpq -p' output|website=NLUG.ML1.co.uk|accessdate=2020-06-24}}</ref> !! '''時間源'''
|-
| GOES || [[GOES|Geosynchronous Orbit Environment Satellite]]（アメリカの気象衛星）
|-
| GPS || [[グローバル・ポジショニング・システム]]
|-
| GAL || [[ガリレオ (測位システム)|ガリレオ]]（ヨーロッパの測位システム）
|-
| PPS || 毎秒1パルス(pps)の時間源を表す汎用コード
|-
| IRIG || {{仮リンク|射程間計装グループ|en|Inter-Range Instrumentation Group}}(IRIG)
|-
| WWVB || 長波[[標準電波]] [[WWVB]]（アメリカ合衆国・[[コロラド州]][[フォートコリンズ (コロラド州)|フォートコリンズ]] 60&nbsp;kHz）
|-
| DCF || 長波標準電波 [[DCF77]]（ドイツ・{{仮リンク|マインフリンゲン|de|Mainflingen}} 77.5 kHz）
|-
| HBG || 長波標準電波 {{仮リンク|HBG (標準電波)|en|HBG (time signal)|label=HGB}}（スイス・{{仮リンク|プランジャン|en|Prangins}} 75&nbsp;kHz（運用中止））
|-
| MSF || 長波標準電波 [[MSF (報時)|MSF]]（イギリス・{{仮リンク|アンソーン|en|Anthorn}} 60&nbsp;kHz）
|-
| JJY || 長波標準電波 [[JJY]]（日本・[[福島県]][[田村市]] 40&nbsp;kHz、[[佐賀県]][[佐賀市]] 60&nbsp;kHz）
|-
| LORC || {{仮リンク|ロランC|en|Loran-C|redirect=1}} 100 kHz
|-
| TDF || 中波標準電波 {{仮リンク|TDF (標準電波)|en|TDF time signal|label=TDF}}（フランス・{{仮リンク|アルイ|en|Allouis}} 162 kHz）
|-
| CHU || 短波標準電波 {{仮リンク|CHU (標準電波)|en|CHU (radio station)|label=CHU}}（カナダ・[[オンタリオ州]][[オタワ]]）
|-
| WWV || 短波標準電波 [[WWV (無線局)|WWV]]（アメリカ合衆国・コロラド州フォートコリンズ）
|-
| WWVH || 短波標準電波 WWVH（アメリカ合衆国・ハワイ州カウアイ）
|-
| NIST || [[アメリカ国立標準技術研究所]](NIST)電話報時サービス
|-
| ACTS || NIST電話報時サービス
|-
| USNO || [[アメリカ海軍天文台]](USNO)電話報時サービス
|-
| PTB || {{仮リンク|ドイツ物理工学研究所|en|Physikalisch-Technische Bundesanstalt}}(PTB)電話報時サービス
|-
| MRS || 複数の参照源
|-
| XFAC || インターフェイス連携の変更（IPアドレスの変更または喪失）
|-
| STEP || ステップ時間の変更（オフセットはステップ閾値（125ミリ秒）以上、パニック閾値（1000秒）以下）
|}

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

==={{anchors|2036年問題}}タイムスタンプ===
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秒の次の秒に発生し<ref name="rfc4330">[https://datatracker.ietf.org/doc/html/rfc4330 RFC 4330] 3.  NTP Timestamp Format</ref><ref>{{cite web |url=https://www.eecis.udel.edu/~mills/y2k.html |author=David L. Mills |title=The NTP Era and Era Numbering |date=12 May 2012 |accessdate=24 September 2016}}</ref><ref name="StevensFenner2004">{{cite book |author1=W. Richard Stevens |author2=Bill Fenner |author3=Andrew M. Rudoff |title=UNIX Network Programming |url=https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582 |year=2004 |publisher=Addison-Wesley Professional |isbn=978-0-13-141155-5 |pages=582–}}</ref>、起点と認識されてNTPが誤動作すると予想されている。これを'''2036年問題'''という。[[UNIX]]{{efn|[[Linux]], [[FreeBSD]]等UNIXライクなOSも含む}}にはこの問題が複数の箇所で今後顕在化するとみられるが（例: [[2038年問題]]）、このNTPについても該当する。

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

NTPv4では128ビットのタイムスタンプが導入されており、秒と秒未満にそれぞれ64ビットを割り当てている。秒を表す64ビットのうち、半分の32ビットは現行のNTPと同じであり、残りの32ビットは、桁あふれの回数を表す''Era Number''（時代番号）である<ref>{{cite web |title=How NTP Represents the Time (Computer Network Time Synchronization) |url=http://what-when-how.com/computer-network-time-synchronization/how-ntp-represents-the-time-computer-network-time-synchronization/ |access-date=2018-07-20}}</ref><ref>{{cite web |title=A look at the Year 2036/2038 problems and time proofness in various systems |url=http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/ |access-date=2018-07-20}}</ref>。ミルズによれば、「秒未満の64ビット値は、光子が光速で電子を通過するのにかかる時間を見分けるのに十分な分解能である。もう1つの64ビットの値は、宇宙が薄暗くなる（[[宇宙の終焉]]）までの時間を明確に表現するのに十分である。」<ref>[[デラウェア大学|University of Delaware]] Digital Systems Seminar presentation by David Mills, 2006-04-26</ref>{{efn|2<sup>−64</sup>秒は約54[[ゼプト秒]]で、この時間に光が移動する距離は16.26[[ピコメートル]]、すなわち[[ボーア半径]]の約0.31倍である。2<sup>64</sup>秒は[[1 E19 s 以上|約5,850億年]]である。}}

===クロック同期アルゴリズム===
[[File:NTP-Algorithm.svg|thumb|ラウンドトリップタイム ''δ'']]
一般的な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> は、クライアントがサーバのレスポンスを受信した時刻
である<ref name="Mills2010" />{{rp|19}}。

''θ''と''δ''の値はフィルタを通過し、統計的分析が行われる。[[外れ値]]は破棄され、残りの候補の中で最も優れた3つの候補から時間オフセットの推定値が導出される。その後、オフセットが徐々に減少するようにクロック周波数が調整され、[[フィードバック]]ループを形成する<ref name="Mills2010">{{cite book|author=David L. Mills|title=Computer Network Time Synchronization: The Network Time Protocol|url=https://books.google.com/books?id=pdTcJBfnbq8C&pg=PA12|date=12 December 2010|publisher=Taylor & Francis|isbn=978-0-8493-5805-0|pages=12–}}</ref>{{rp|20}}。

正確な同期化は、往路と復路の通信時間がほぼ等しい場合に達成される。両者に差がある場合は、その差の2分の1が誤差になる可能性がある<ref>{{cite conference |last1=Gotoh |first1=T. |last2=Imamura |first2=K. |last3=Kaneko |first3=A. |title=Improvement of NTP time offset under the asymmetric network with double packets method |conference=Conference on Precision Electromagnetic Measurements |pages=448–449 |year=2002 |doi=10.1109/CPEM.2002.1034915 |isbn=0-7803-7242-5}}</ref>。極端な例では、通信の往復に合計10秒掛かった場合に最大で約5秒の誤差が発生する。

=== 運用 ===
NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている（RFC4330による）<ref>[http://www2.nict.go.jp/aeri/sts/tsp/PubNtp/qa.html#q1-2 日本標準時プロジェクト　公開NTP FAQ ［Q.1-2］ ホスト名ではなく、IPアドレスで設定しても良いですか？]</ref>。

[[Local Area Network|LAN]]内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器<ref group="注釈">もし[[ルーター]]などで提供できなければ、NTPサービス提供専用の古い[[パーソナルコンピュータ|パソコン]]をセットアップしても良いし、またサーバ的な存在になっている既存のパソコン等にNTPサーバをインストールしても良い</ref>を用意し、この機器（内部NTPサーバ）をプロバイダなどの外部NTPサーバに接続し、各クライアントはこの内部NTPサーバに接続する設定を行うと良い。

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

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

なおNTPサーバプログラムを用いてコンピュータの時刻の校正を行う場合、突然『もっともらしい時刻』に校正するのは危険である。サーバ機能を提供しているコンピュータでは、時刻が飛ぶことにより、定時に実行されるサービス（UNIXのcron・atなど）が実行されなくなったり（時計を進める場合）同じサービスが2回実行される（時計を遅らせる場合）ことがあるからである。したがって、ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。

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

警告情報を受け取った側がどう処理するかは、[[コンピュータプログラム]]の実装に任される。しかし、削除された1秒に自動起動するサービスがあるかもしれなかったり、外部要因で日付が変わると無効になるライセンスがありえたりするため注意が必要である<ref name="tokikake">[https://atmarkit.itmedia.co.jp/ait/articles/0901/23/news141.html 安藤幸央のランダウン44 時を欠ける症状-うるう秒から考えるサステナビリティ] アットマーク・アイティ 2011年[[10月4日]]閲覧</ref>。

leap smearingと呼ばれる実装では、一秒挿入するのではなく、閏秒の前後20時間をかけて、ゆっくり一秒分の時間を伸ばすことで問題を回避している<ref>[https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html Making every (leap) second count with our new public NTP servers]</ref>。この実装は、[[Google]]（内部的にも公開NTPサーバー上でも）と[[Amazon Web Services|Amazon AWS]]によって使用されている<ref>{{cite web |url=https://developers.google.com/time/smear |title=Google Developers Leap Smear |accessdate=4 April 2019}}</ref>。

==実装==
[[File:Ntpq -p query.png|thumb|NTP管理プロトコルユーティリティ ntpqで、stratum 2サーバの状態を照会している様子。]]

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

===リファレンス実装===
NTPの[[リファレンス実装]]は、プロトコルとともに20年以上にわたって継続的に開発されてきた。新しい機能が追加されても、後方互換性が維持されてきた。これには、特にクロックを規律するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用しているサーバに同期させると誤動作する可能性がある。このソフトウェアは、パーソナルコンピュータを含むほぼ全てのプラットフォームに移植されている。UNIXでは{{仮リンク|ntpd|en|ntpd}}という[[デーモン (ソフトウェア)|デーモン]]として、Windowsでは[[Windowsサービス|サービス]]として動作する。基準クロックにも対応しており、そのオフセットはリモートサーバと同じようにフィルタリングされ、分析されるが、通常はより頻繁にポーリングされる<ref name="Mills2010" />{{rp|15–19}}。この実装は2017年に検査され、多数の潜在的なセキュリティ問題が発見された<ref>{{cite web | url=https://wiki.mozilla.org/images/e/ea/Ntp-report.pdf | title=Pentest-Report NTP 01.2017 | publisher=Cure53 |date=2017 |accessdate=2019-07-03}}</ref>。

===SNTP===
{{main|Simple Network Time Protocol}}
[[Simple Network Time Protocol]] (SNTP)は、NTPと同じプロトコルを使用するが、長時間の状態の保存を必要としない、NTPのサブセットの実装である<ref>{{cite web | url = https://datatracker.ietf.org/doc/html/rfc5905#section-14 | title = Network Time Protocol Version 4: Protocol and Algorithms Specification | date = June 2010 | page = 54 | quote = Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...] | accessdate = 2012-08-26}}</ref>。[[組み込みシステム]]や、完全なNTP機能が必要とされないアプリケーションで使用される<ref>{{Cite IETF |rfc=4330 |title=Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI}}</ref>。

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

[[Windows 2000]]以降の[[Windows]]には、コンピュータの時計をNTP サーバに同期させる機能を持つWindows Timeサービス (W32Time)が含まれている<ref>{{cite web|url=https://technet.microsoft.com/en-us/library/cc773061%28WS.10%29.aspx |title=Windows Time Service Technical Reference |publisher=technet.microsoft.com |date=2011-08-17 |accessdate=2011-09-19}}</ref>。W32Timeは元々[[ケルベロス認証]]バージョン5のために実装されたものである。ケルベロス認証では、[[反射攻撃]]への対抗として、タイムスタンプに含まれる時間が正確な時間から5分以内である必要があった。

[[Windows 2000]]と[[Windows XP]]ではSNTPのみを実装しており、NTPバージョン3に対してはいくつかの規約に違反している<ref>{{cite web|url=https://support.ntp.org/bin/view/Support/WindowsTimeService |title=Windows Time Service page at NTP.org |website=Support.NTP.org |date=2008-02-25 |accessdate=2017-05-01}}</ref>。[[Windows Server 2003]]と[[Windows Vista]]からは、フルセットのNTPに準拠した実装となり<ref>{{cite web|url=https://technet.microsoft.com/en-us/library/cc773013%28WS.10%29.aspx |title=How the Windows Time Service Works |publisher=technet.microsoft.com |date=2010-03-12 |accessdate=2011-09-19}}</ref>、GUIで時刻同期を設定することができるようになった。また、有志によってビルドされたWindows向けのntpd/ntpdateも公開されている<ref>[http://www.meinbergglobal.com/english/sw/ntp.htm Meinberg NTP Software Downloads]</ref>。

マイクロソフトは、W32Timeは1秒の精度でしか時刻同期を確実に維持できないと声明している<ref name=kb939322>{{cite web | url = https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary | title = Support boundary for high-accuracy time | date = 2018-10-17 | publisher = [[Microsoft]] |accessdate=2020-06-24}}</ref>。より高い精度が必要な場合は、Windowsの新しいバージョンを使用するか、別のNTP実装を使用することを勧めている<ref>{{cite web | url = https://blogs.technet.com/b/askds/archive/2007/10/23/high-accuracy-w32time-requirements.aspx | title = High Accuracy W32time Requirements | date = 2007-10-23 | author = Ned Pyle | publisher = [[Microsoft]] | accessdate = 2012-08-26 }}</ref>。[[Windows 10]]と[[Windows Server 2016]]では、特定の動作条件の下で1ミリ秒の時間精度の同期に対応している<ref>{{Cite web|和書|url=https://learn.microsoft.com/ja-jp/windows-server/networking/windows-time-service/accurate-time?redirectedfrom=MSDN |website=technet.microsoft.com |title=Windows Server 2016 の正確な時刻|accessdate=2020-06-24}}</ref><ref name=kb939322/>。

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

====ntimed====
新しいNTPクライアントであるntimedが、{{仮リンク|ポール＝ヘニング・カンプ|en|Poul-Henning Kamp}}によって2014年に開始された<ref>{{cite web|last1=Poul-Henning|first1=Kamp|title=20140926 – Playing with time again|url=http://phk.freebsd.dk/time/20140926|website=PHK's Bikeshed|accessdate=4 June 2015}}</ref>。この実装は、リファレンス実装の代替として[[Linux Foundation]]がスポンサーとなっている。リファレンス実装を元にするより、新しい実装をゼロから書いた方が簡単であると判断されたためである。公式にはリリースされていないが、ntimedは確実にクロックを同期させることができる<ref>{{cite web|last1=Poul-Henning|first1=Kamp|title=Network time synchronization software, NTPD replacement.|url=https://github.com/bsdphk/Ntimed|website=ntimed git repository README file|publisher=Github|accessdate=4 June 2015}}</ref>。

====NTPsec====
NTPsecは、リファレンス実装を[[フォーク (ソフトウェア開発)|フォーク]]し、体系的に[[ハードニング|セキュリティを強化]]した実装である。フォークポイントは2015年6月で、2014年に発生した危殆化した脆弱性への対応が行われた。最初の正式版は2017年10月にリリースされた<ref>{{cite web|url=https://ntpsec.org |title=The Secure Network Time Protocol (NTPsec) Distribution|accessdate=2019-01-12}}</ref>。安全ではない機能の削除、時代遅れのハードウェアやUNIXバリアントへの対応の削除により、元のソースコードの75%を削除し、残りの部分を検査を受けやすくした<ref name="Liska2016">{{cite book|first=Allan|last=Liska|title=NTP Security: A Quick-Start Guide|url=https://books.google.com/books?id=AB-1DQAAQBAJ&pg=PA80|date=December 10, 2016|publisher=Apress|isbn=978-1-4842-2412-0|pages=80–}}</ref>。2017年のコードの検査では、リファレンス実装にはなかった2つを含む8つのセキュリティ問題が検出されたが、元のリファレンス実装に残っていた他の8つの問題の影響を受けることがなかった<ref>{{cite web| url=  https://wiki.mozilla.org/images/1/10/Ntpsec-report.pdf |title=Pentest-Report NTPsec 01.2017 |publisher=Cure53 |date=2017 |accessdate=2019-07-03}}</ref>。

====chrony====
[[File:Chrony 4.6 screenshot.webp|thumb|chrony 4.6]]
[[chrony]]は、[[Red Hat]]のディストリビューション<ref>
{{cite web
 |url= http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/
 |title= Combining PTP with NTP to Get the Best of Both Worlds
 |access-date = 19 November 2017
 |last= Lichvar
 |first= Miroslav
 |date= 20 July 2016
 |website= Red Hat Enterprise Linux Blog
 |quote= Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package
 |publisher= [[Red Hat]]
 |archive-url= https://web.archive.org/web/20160730091110/http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/
 |archive-date= 30 July 2016
}}
</ref>にデフォルトで搭載されており、[[ubuntu]]のリポジトリでも利用可能である<ref>
{{cite web
 |url= https://packages.ubuntu.com/xenial/chrony
 |title= Package: chrony (2.1.1-1) [universe]
 |access-date = 19 November 2017
 |last= Lichtenheld
 |first= Frank
 |website= Ubuntu Package
 |quote= Versatile implementation of the Network Time Protocol
 |publisher= Ubuntu Package
 |archive-url= https://web.archive.org/web/20171119213641/https://packages.ubuntu.com/xenial/chrony
 |archive-date= 19 November 2017
}}</ref>。chronyは、不安定でスリープモードになったり、インターネットに断続的に接続したりするような一般的なコンピュータを対象としている<ref name="Both2018">{{cite web |last1=Both |first1=David |title=Manage NTP with Chrony |url=https://opensource.com/article/18/12/manage-ntp-chrony |website=Opensource.com |accessdate=29 June 2019 |language=en}}</ref>。また、より不安定な環境である[[仮想マシン]]用にも設計されている。リソース消費量（コスト）が少ないのが特徴で、NTPだけでなく、[[Precision Time Protocol]](PTP)にも対応している。主なコンポーネントは、コンピュータの起動時に実行されるデーモンであるchronydと、その設定のためのコマンドラインインターフェースであるchronycの2つである。

chronycは非常に安全で、数件の事故があっただけだが<ref>
{{cite web
 |url= https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf
 |title= Pentest-Report Chrony 08.2017
 |access-date = 19 November 2017
 |last= Heiderich
 |first= Mario
 |date= August 2017
 |website= Cure53.de Team
 |language = english
 |quote= Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind.
 |publisher= wiki.mozilla.org, AKA MozillaWiki or WikiMO
 |archive-url= https://web.archive.org/web/20171005123643/https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf
 |archive-date= 5 October 2017
}}</ref>、その利点は、不必要な複雑さを避けるためにゼロから書かれたコードの汎用性にある<ref>
{{cite web
 |url= https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time
 |title= Securing Network Time
 |access-date = 19 November 2017
 |date= 27 September 2017
 |website= Core Infrastructure Initiative, a Linux Foundation Collaborative Project
 |quote= In sum, the Chrony NTP software stands solid and can be seen as trustworthy
 |publisher= Core Infrastructure Initiative
 |author-link= [[Linux Foundation]]
 |archive-url= https://web.archive.org/web/20171028123642/https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time
 |archive-date= 28 October 2017
}}</ref>。

chronyは[[GNU General Public License]] version 2で利用可能である。1997年にRichard Curnowによって作成され、現在はMiroslav Lichvarによってメンテナンスされている<ref>
{{cite web
 |url= https://chrony.tuxfamily.org/
 |title= chrony introduction
 |access-date = 19 November 2017
 |website= TuxFamily, a non-profit organization.
 |quote= The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris.
 |publisher= chrony
 |archive-url= https://web.archive.org/web/20091209115945/https://chrony.tuxfamily.org/
 |archive-date= 9 December 2009
}}</ref>。

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

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

== 運用と諸問題 ==
{{See also|en:NTP server misuse and abuse}}
前述の通りNTPは階層構造を採用しているため、[[負荷分散]]が行えるように工夫されている。しかし、NTPと同じく階層構造を採用する[[Domain Name System|DNS]]では[[Dynamic Host Configuration Protocol|DHCP]]や[[Point-to-Point Protocol|PPP]]によるDNSサーバアドレス配信の仕組みが普及しているのに対し、NTPではDHCPではオプション42として<ref>{{Cite web |url=https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options |title=Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters |access-date=2024-03-21 |publisher=[[IANA]]}}</ref><ref>{{Cite web |url=https://datatracker.ietf.org/doc/html/rfc2132#section-8 |title=RFC 2132 - DHCP Options and BOOTP Vendor Extensions |access-date=2024-03-21 |publisher=[[IETF]]}}</ref>、DHCPv6ではオプション56として<ref>{{Cite web |url=https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 |title=Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |access-date=2024-03-21 |publisher=[[IANA]]}}</ref><ref>{{Cite web |url=https://datatracker.ietf.org/doc/html/rfc5908 |title=RFC 5908 - Network Time Protocol (NTP) Server Option for DHCPv6 |access-date=2024-03-21 |publisher=[[IETF]]}}</ref>NTPサーバアドレス配信の仕組みが定義されているものの、2024年3月現在ほとんど利用されていない。よって、[[エンドユーザー]]は自ネットワーク内のNTPサーバの存在を知ることができず、エンドユーザーが stratum 1 の公開 NTP サーバを使用する傾向がある。結果的に、一つのNTPサーバにアクセスが集中するためサーバの応答性を下げ、配信される時刻の正確性が失われる。

この問題に対する国際的なプロジェクトとして、[https://www.pool.ntp.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万リクエスト/秒を扱える新しいシステムでは負荷の問題ではなく知名度の低さが問題としている<ref>日経NETWORK 2006年8月号 「NICTの標準時刻配信サービス」p68</ref>。

=== clock.nc.fukuoka-u.ac.jp問題 ===
日本では、[[福岡大学]]が[[1993年]]（[[平成]]5年）からNTPサーバを公開しているが、ここを参照するように設定された機器や組み込まれたソフトウェアが非常に多いため<ref group="注釈">前述の「桜時計」もそのひとつである。</ref>、アクセス集中による過負荷に悩まされていることが、2005年に報告された<ref>[https://www.itmedia.co.jp/news/articles/0501/21/news059.html 福岡大のNTPサーバがアクセス集中で悲鳴] - ITmediaニュース 2005年01月21日（2014年4月20日閲覧）</ref>。契約している[[インターネットサービスプロバイダ]] (ISP) の公開するサーバを利用することで、この問題は解消するので、ISPや研究機関等が加入者向けにサービスするNTPサーバや公開NTPサーバに、今すぐ設定を変更することである。

2017年現在も、福岡大学NTPサーバへのデータトラフィックは過大な状態が続いており、平均180Mbpsに達している<ref>[http://enog.jp/wp-content/uploads/2017/10/20171027_ENOG47_tanizaki.pdf 公開NTPサーバーの運用と課題] 2017/12/27閲覧</ref>。アクセス過多の原因の一つとして、一部メーカーのネットワーク機器にNTPサーバのアドレスがハードコーティングされていることが挙げられている。

ネットワーク機器にアドレスがハードコーティングされた一例として、[[TP-LINK Technologies|TP-Link]]製の無線LAN中継器がある。この機器は、本来の時刻同期の目的ではなくインターネット回線の接続状態を確認するため、福岡大学を含む複数のNTPサーバへ数秒間隔でアクセスする仕様になっていた。TP-Linkからは管理画面を開いている間のみNTPサーバへアクセスするよう、仕様を変更したファームウェアが公開されている<ref>[http://www.tp-link.jp/news-details-17792.html ＜更新＞TP-Link製無線LAN中継器によるNTPサーバーへのアクセスに関して] 2017/12/27閲覧</ref>。

2017年、福岡大学は同NTPサービスの提供を2018年4月以降に停止する事を発表した<ref>{{Cite web|和書|url=https://www.janog.gr.jp/meeting/janog41/application/files/9815/1692/5488/janog41-sp10ntp-fujimura-03.pdf|title=福岡大学における公開用NTPサービス䛾現状と課題|accessdate=2018-01-30}}</ref>。これは、データトラフィックが多すぎるため、大学ネットワーク運用に無駄な費用がかかっている事や、サービス開始当初の1993年はNTPで時刻同期することが研究対象であったが、現在では様々なアプライアンスが販売されているため、NTPの研究として役目を終えたと理由を挙げている。2019年3月12日に2台あるNTPサーバーのうちの1台を停止した<ref>{{Cite web|和書|title=公開NTPサービス {{!}} 福岡大学情報基盤センター|url=https://www.ipc.fukuoka-u.ac.jp/service/ntp/public_ntp/|website=www.ipc.fukuoka-u.ac.jp|accessdate=2019-03-27}}</ref>。

=== ウィスコンシン大学-ネットギアNTP問題 ===
[[ネットギア]]製の[[ルーター]]が[[ウィスコンシン大学]]のNTPサーバを参照するよう[[ハードコード]]されていたため、負荷が極度に集中した。以下に問題の経緯を記す。

[[2003年]][[5月]]、ウィスコンシン大学に対して平均毎秒4万パケット<ref group="注釈">異常値のようなピーク時で毎秒8万パケット</ref>のNTPサービスへの接続が行われた。

これに対し大学側はNTP用に公開していたポートを閉じ、悪意あるアクセスは数時間のうちに収まるであろうと考えていた。しかしながら1か月後の2003年6月の時点において、大学側の予想に反するどころかさらに状況は悪化し平均毎秒25万パケットを記録。さらなる調査によって、多くの接続元が1秒毎に問い合わせを行っている事に不審を抱くこととなる。接続元となっている2つの大学に協力を要請。調査結果の中で双方ともにネットギア製のルーターを使用していた事が判明、型番もMR814であると特定された。

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

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

なお、これらの事件の詳細は、2003年[[8月21日]]にウィスコンシン大学のDave Plonkaによりまとめられている<ref>{{Cite web|title=Flawed Routers Flood University of Wisconsin Internet Time Server|url=http://www.cs.wisc.edu/~plonka/netgear-sntp/|accessdate=2020-5-7}}</ref>。

他に、[[FreeBSD]]の有力開発者であるPoul-Henning Kamp(phk)が発見した[[Dリンク|D-link]]製ルータの問題や、ダブリンのTardis and Trinity Collegeの問題など、同様の問題が発生している。{{仮リンク|NTPサーバの誤用・不正使用問題|en|NTP server misuse and abuse}}を参照のこと。

==脚注==
{{脚注ヘルプ}}
===注釈===
{{Notelist}}

===出典===
{{Reflist|refs=
<ref name = "RFC958 NTP" >{{IETF RFC|958}} ''Network Time Protocol (NTP)'', september 1985.</ref>
<ref name = "RFC1059 NTP v1" >{{IETF RFC|1059}} ''Network Time Protocol (Version 1) Specification and Implementation'', july 1988.</ref>
<ref name = "RFC1119 NTP v2" >{{IETF RFC|1119}} ''Network Time Protocol (Version 2) Specification and Implementation'', september 1989.</ref>
<ref name = "RFC1305 NTP v3" >{{IETF RFC|1305}} ''Network Time Protocol (Version 3) Specification, Implementation and Analysis'', march 1992.</ref>
<ref name = "RFC5905 NTP v4" >{{IETF RFC|5905}} ''Network Time Protocol Version 4: Protocol and Algorithms Specification'', june 2010.</ref>
<ref name = "RFC7822 NTP v4" >{{IETF RFC|7822}} ''Network Time Protocol Version 4 (NTPv4) Extension Fields'', march 2016.</ref>
<ref name = "RFC1361 SNTP v3" >{{IETF RFC|1361}} ''Simple Network Time Protocol (SNTP)'', august 1992.</ref>
<ref name = "RFC1769 SNTP v3" >{{IETF RFC|1769}} ''Simple Network Time Protocol (SNTP)'', march 1995.</ref>
<ref name = "RFC2030 SNTP v4" >{{IETF RFC|2030}} ''Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI'', october 1996.</ref>
<ref name = "RFC4330 SNTP v4" >{{IETF RFC|4330}} ''Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI'', january 2006</ref>
<ref name = "RFC778" >{{IETF RFC|778}} ''DCNET Internet Clock Service'', april 1981.</ref>
}}

==参考文献==
* {{cite IETF |rfc=5907 |title=Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)}}
* {{cite IETF |rfc=5908 |title=Network Time Protocol (NTP) Server Option for DHCPv6}}

==関連項目==
* [[アラン分散]]
* {{仮リンク|クロック・ネットワーク|en|Clock network}}
* [[国際原子時]]
* {{仮リンク|IRIGタイムコード|en|IRIG timecode}}
* {{仮リンク|Network Identity and Time Zone|en|NITZ}}
* {{仮リンク|NTP pool|en|NTP pool}}
* {{仮リンク|ntpdate|en|ntpdate}}
* [[Precision Time Protocol]] (IEEE 1588 PTP)
* {{仮リンク|White Rabbit Project|en|White Rabbit Project}}

== 外部リンク ==
* [https://www.ntp.org/ NTP Project]
* [https://nts.softros.com/server/ Windows用のNTPサーバーソフトウェア]
* [https://servertest.online/ntp NTP Server Test Online]

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

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

{{年問題}}

{{DEFAULTSORT:ねつとわくたいむふろとこる}}
[[Category:アプリケーション層プロトコル]]
[[Category:インターネット標準]]
[[Category:RFC|1128]]
[[Category:時間に関するネットワークソフト]]