(Wikipedia Network Time Protocolより)

Network Time Protocol（ネットワーク・タイム・プロトコル、略称NTP（エヌティーピー））は、ネットワークに接続される機器において、機器が持つ時計を正しい時刻へ同期するための通信プロトコルである。

OSI基本参照モデルの第7層（アプリケーション層）に位置し、UDPポートの123番を使用する。

概要

ネットワークに接続され、互いにデータの交換を行う機器において、各機器が持つ時計（以下、各機器が持つ時計を「RTC」として説明する）の時刻が機器間で異なると、時刻に依存した機器間のデータ交換、例えば電子メールやファイルの送受信、ログの配信などに異常をきたすおそれがある。よって、RTCの時刻は機器間で互いに同期していることが望ましい。

ネットワークに接続される機器のRTCを正しい時刻に合わせる古典的な方法としてTime Protocolがある。Time Protocolは正しい時刻を提供するサーバから各機器が時刻値を取得する方法を定めている。しかし Time Protocol を用いて取得した時刻値にはサーバから機器に時刻値が到達するまでの通信時間が含まれない。よって、取得した時刻値には通信時間に起因する遅れの誤差が含まれてしまいRTCを正しい時刻に同期できない。

NTPは通信時間による時刻値の誤差を小さくする工夫がなされた時刻同期のためのプロトコルである。

2010年6月、最新バージョンのNTP4がRFCのProposed Standardとなった。

時刻同期の仕組み

処理の概略

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

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

階層構造

NTPはstratumと呼ばれる階層構造を持ち、最上位のサーバが正確な時計から標準時を取得し、下位のホストはそれを参照する事で時刻を合わせる。最上位のNTPサーバはstratum 1であり、階層を下りるごとに数字が一つずつ大きくなる。stratum 16が最下位で、stratum 16に同期することは出来ない。NTPでは複数のサーバへ時刻を問い合わせることが可能で、これにより可用性と精度の向上が期待できる。通常サーバは複数の上位サーバを利用して時刻を取得する。一般にstratumの大きさよりも、サーバとのネットワーク的な近さのほうが時刻精度に大きく影響する。

や標準電波、原子時計などの正確な時刻源 (stratum 0) に直結されたNTPサーバはstratum 1となる。これらの時刻源は誤差±1μ秒未満（100万分の1秒未満）の非常に正確な時刻を刻んでいる。また現実には、電波時計やGPSの受信機自体の信号遅延、受信機とstratum 1となる機器の間の遅延が無視できない。GPS衛星には原子時計が搭載されており、その電波にはGPSタイムと呼ばれる時刻情報が含まれている。標準電波は地域の標準時を保持する組織が時刻情報を電波で送出するものであり、日本の場合は独立行政法人情報通信研究機構（NICT、旧・通信総合研究所 (CRL)）が行っている。

代表的なNTPの実装であるntpdでは、上位stratumだけではなく、複数の同位・下位stratumのNTPサーバとも接続できる。ピアとよばれる他のサーバをどれにするかの設定は設定ファイルなどにより行なう。より多くの複数のサーバと時刻の比較・ネットワークの遅延、および遅延のばらつきの計測を行ない、重み付けを行なって最ももっともらしい時刻を現在時刻とする。

通信遅延時間の計測

NTPでは、往復の通信時間を計測することで遅延時間の補正を行っている。具体的には、クライアントがリクエストを送信した時刻を \(t_s\) 、サーバがクライアントのリクエストを受信した時刻を \(T_r\) 、サーバがレスポンスを送信した時刻を \(T_s\) 、クライアントがサーバのレスポンスを受信した時刻を \(t_r\) とすると、通信遅延時間 \(\delta\) は、

$\backslash delta\; =\; (t\_r\; -\; t\_s)\; -\; (T\_s\; -\; T\_r)$

で表される。これは、パケットの往復時間からサーバの処理時間を引いたものである。一方、往路と復路の通信時間に差がないと仮定すれば、クライアントの時計の遅延時間 \(\theta\) は、

$\backslash theta\; =\; \backslash frac\{T\_s\; +\; T\_r\}\{2\}\; -\; \backslash frac\{t\_s\; +\; t\_r\}\{2\}$

で表される。これは、サーバ、クライアントの、パケットの送信時刻、受信時刻の平均の差である。
なお，往路の遅延と復路の遅延に差がある場合には，その差の2分の1は，誤差として残ることになる。

運用

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

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

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

ドリフトの修正

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

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

閏秒の扱い

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 利用環境

下位プロトコル

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

NTPの実装

代表的なNTPの実装として、Unix系オペレーティングシステム用のNTPサーバである ntpd（旧xntpd）、およびNTPクライアントの ntpdate がある。ntpd/ntpdate は多くのオペレーティングシステムで標準的に組み込まれている。

Mac OS X においても、標準でntpd/ntpdateが使用されていて、コマンドを意識せずGUIから設定できる。以前のMac OS 9でもNTPクライアントは標準で組み込まれていた。

X Window Systemのデスクトップ環境でもntpd/ntpdateをGUIより設定するユーティリティが付属するものがある。

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も公開されている。

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

NTPサーバと負荷

前述の通りNTPは階層構造を採用しているため、負荷分散が行えるように工夫されている。しかし、NTPと同じく階層構造を採用するDNSではDHCPやPPPによるDNSサーバアドレス配信の仕組みが普及しているのに対し、NTPではNTPサーバアドレス配信の仕組みが存在しない。よって、エンドユーザーは自ネットワーク内のNTPサーバの存在を知ることができず、エンドユーザーが stratum 1 の公開 NTP サーバを使用する傾向がある。結果的に、一つのNTPサーバにアクセスが集中するためサーバの応答性を下げ、配信される時刻の正確性が失われる。

この問題に対する国際的なプロジェクトとして、 が存在する。これは、世界全体、あるいは国単位でまとめられた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サーバーのどれかがランダムに選ばれる。プールされているサーバーのアドレスは、2012年4月現在、全世界で2960、日本国内については24である。なお、このプロジェクトはエンドユーザーからのアクセスを分散することを主目的としているため、プールされている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年からNTPサーバを公開しているが、ここを参照するように設定された機器やソフトが非常に多いため、アクセス集中による過負荷に悩まされていることが、2005年に報告された。契約しているインターネットサービスプロバイダ (ISP) の公開するサーバを利用するなどでこれらの問題は解消すると考えられるため、福岡大学内部でNTPサーバを利用している場合を除き、ISPや研究機関等が加入者向けにサービスするNTPサーバや公開NTPサーバを利用することが好ましい。

ウィスコンシン大学-ネットギア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サーバの誤用・不正使用問題」を参照のこと。

関連RFC

• RFC 1128
• RFC 1129
• RFC 1305
• RFC 2030
• RFC 4330
• RFC 5905
• RFC 5906
• RFC 5907
• RFC 5908
• RFC 868 - Time Protocol （NTPが登場する前の古典的な時刻同期プロトコル）