Network Time Protocol

Network Time Protocolの最新ニュースをまとめて検索!

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

OSI基本参照モデルの第7層に位置し、UDPポートの123番を使用する。

丁度、ネットワークを利用したコンピュータ向け時報のようなものである。

目次

[編集] 概要

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

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

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

2007年9月現在、最新のNTPのバージョンは4だが、RFCが公開されていないため、一般的にはNTP v3が使用されている[1]

[編集] 時刻同期の仕組み

[編集] 処理の概略

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

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

[編集] 階層構造

NTPの階層構造の概略図

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

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

代表的なNTPの実装であるntpdでは、上位stratumだけではなく、複数の同位・下位stratumのNTPサーバとも接続できる(したがってこの項でNTPサーバとよんでいるプログラムは、サービスを提供しているという意味であり、通常のネットワークのサーバ・クライアントモデルからいうとNTPクライアントにあたる場合もある)。ピアとよばれる他のサーバをどれにするかの設定は設定ファイルなどにより行なう。より多くの複数のサーバと時刻の比較・ネットワークの遅延(および遅延のばらつき)の計測を行ない、重み付けを行なって最ももっともらしい時刻を現在時刻とする。

[編集] 通信遅延時間の計測

NTPでは、往復の通信時間を計測することで遅延時間の補正を行っている。具体的には、クライアントがリクエストを送信した時刻をts、サーバがクライアントのリクエストを受信した時刻をTr、サーバがレスポンスを送信した時刻をTs、クライアントがサーバのレスポンスを受信した時刻をtrとすると、通信遅延時間δは、

δ = (trts) − (TsTr)

で表される。これは、パケットの往復時間からサーバの処理時間を引いたものである。またクライアントの時計の遅延時間θは、


\theta = \frac{T_s + T_r}{2} - \frac{t_s + t_r}{2}

で表される。

[編集] 運用

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

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

※「桜時計」他の時刻合わせソフトウェアやNTPクライアント機能組込ルータなどでは、製作当時に使われていた福岡大学などの大学や外国のNTPサーバのアドレスが初期設定されたままになっているので、接続先NTPサーバのアドレス設定は、前述の契約先ISPや情報通信研究機構などのNTPサーバに修正する必要がある。

[編集] ドリフトの修正

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

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

[編集] 閏秒の扱い

NTPプロトコルでは、電波時計の時刻送信フォーマットのように閏秒の扱いも規定されている。閏秒は、原子時(TAI)と同期して進むUTCが、地球の自転速度の変化によって世界時(UTC1)から長年の間に大きく狂わないように、世界的な協定に基づいてUTCに挿入または削除される1秒である。これは本質的にコンピュータの時計の進み遅れとは異なり、必ず±1秒の差となる。したがって、問合せ先のNTPサーバからうるう秒挿入または削除を警告するパケットが送られてきたときは、自機の時計を1秒ずらす(ドリフトは調整しない)ことになる。

[編集] 2036年問題

NTPでは、時刻の表現に1900年1月1日 0時0分0秒 (UTC) (この時間を以下では「起点」とする)からの積算を使用している。この値は32ビット符号なしで表現されるため、起点から(232-1)秒、すなわち42億9496万7295秒までしか表現できない。

その結果、起点から42億9496万7295秒経過した2036年2月6日 6時28分15秒 (UTC) の次の秒(16秒)が桁あふれによって起点と認識されてしまい、NTPが誤動作すると予想されている。

これが2036年問題である。UNIXLinux, FreeBSD等UNIXライクなOSも含む)にはこの問題が複数の箇所で今後顕在するとみられるが(例:2038年問題)、このNTPについても該当する。

[編集] 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 2000からNTPの機能が標準で組み込まれた。Windows XP からはGUIで時刻同期を設定することができるようになった。 また、Windows NTではリソースキットの追加でNTPの機能が使用できた。それ以前のWindowsでは、サードパーティのソフトウェアを使用する必要があった。日本では、Windowsが本格的にインターネット対応を開始した1990年代後半に「桜時計」と呼ばれるNTPの実装が有名になった。

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

[編集] NTPサーバと負荷

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

Windows XPMac OSの初期設定サーバは混雑しているため、ISP提供のサーバや後述の公開NTPサーバ等に変更すると、より正確な時刻取得が可能になる。

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

[編集] clock.nc.fukuoka-u.ac.jp問題

日本では福岡大学が1993年からNTPサーバを公開しているが、ここを参照するように設定された機器やソフトが非常に多いため、アクセス集中による過負荷に悩まされている。契約しているインターネットサービスプロバイダ(ISP)の公開するサーバを利用するなどで、これらの問題は解消すると考えられるため、福岡大学内部でNTPサーバを利用している場合を除き、ISPや研究機関等が加入者向けにサービスするNTPサーバや公開NTPサーバを利用することが好ましい。

[編集] ウィスコンシン大学-ネットギアNTP問題

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

2003年5月、ウィスコンシン大学に対して平均毎秒4万パケット(異常値のようなピーク時で毎秒8万パケット)の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によりまとめられている。[1]

他にFreeBSDの有力開発者であるPoul-Henning Kamp (phk) とD link製のルータやダブリンのTardis and Trinity Collegeでも同様の問題が起きた。英語版の「NTPサーバの誤用・不正使用問題」を参照。

[編集] 参考

  1. ^ NTP.ORG - What is NTP (Network Time Protocol) ?
  2. ^ 日経NETWORK 2006年8月号 「NICTの標準時刻配信サービス」p68

[編集] 関連RFC

[編集] 関連項目

[編集] 外部リンク

[編集] 公開NTPサーバ

[編集] 日本国内

最終更新 2009年11月10日 (火) 10:53 (日時は個人設定で未設定ならばUTC)。
【Network Time Protocol】変更履歴

ご利用上の注意