「Simple Network Time Protocol」の版間の差分

削除された内容 追加された内容
Sgs00127 (会話 | 投稿記録)
編集の要約なし
Claw of Slime (会話 | 投稿記録)
記述の劣化が見られるため差し戻し
1行目:
{{出典の明記|date=2018年2月}}
'''Simple Network Time Protocol'''(シンプルネットワークタイムプロトコル、'''SNTP'''と略記)は、[[Network Time Protocol|NTP]][[パケットワークに接続される機器において]]を利用した機器が持つ簡単な[[時計]]補しい時刻へ同期するための通信[[プロトコル]]である。
 
 SNTPは、先行して登録されたRFC1305(NTP)の仕様が複雑であったため、「バケット仕様」,「同期の改造構造」,「一部の送受信仕様」のみを継承してまとめられた。
 
== 処理概要 ==
SNTPのパケットは、[http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt RFC-2030(Simple Network Time Protocol Version 4)]にて定義される。このパケットを使用し、上位時計[[サーバ]]との通信にて、[[オフセット]]を演算する。なお、時計反映処理はNTPも同様で定義されていないためプログラマーに依存する。その理由は、時計構成にはそのまま反映してよいものと、徐々に時計を近づける方法があり、運用されるシステムによって選択する必要があるためである。
処理は、2種類の処理仕様が継承され定義されている。<br>
ただし、サーバ時計の審査機能は定義されていない。<br>
=== サーバ・クライアントモード ===
サーバとなるホストを基準時計とし、クライアントとの時刻差を算出するパラメータを取得するモードである。<br>
具体的なパラメータは、以下項目である。<br>
T1:クライアントの問合せ時刻<br>
T2:サーバの受信時刻<br>
T3:サーバの応答時刻<br>
T4:クライアントの受信時刻<br>
<br>
上記パラメータより下記が算出できる。<br>
往復遅延時間:d = (T4 - T1) - (T3 - T2)<br>
システムクロックオフセット:t = ((T2 - T1) + (T3 - T4)) / 2<br>
考え方として、サーバ時計とクライアント時計の差を算出し、クライアントの時計を校正する方式である。<br>
この方式のため、閏秒が存在しても特別な処理もなく校正が可能になる。<br>
<br>
このモードは、正確な時計入手する一般的方法である。
=== 放送モード ===
放送モードは、サーバより一方的にNTPフレームをブロードキャストまたはマルチキャストで送信を行う。<br>
クライアントは、サーバ送信したNTPフレームを受信して、その時刻で校正を行う方式である。<br>
クライアントが使用する時刻は、「T3:サーバの応答時刻」を採用する。<br>
このモードの特徴は、ネットワーク遅延などは算出はできない。正確な時刻より、同一タイミングで動作されるシステムで適用を考えた仕様である。<br>
SNTP/NTPのマルチキャストアドレスは、以下が予約されている。<br>
IPv4=224.0.1.1(RFC1700)<br>
IPv6=FF0X:0:0:0:0:0:0:101(RFC2375)<br>
 
== 時計精度と上限 ==
45 ⟶ 19行目:
上記より使用できる時計精度は200ピコ秒まで処理可能。
 
=== 解消された将来の問題点 ===
このパケットは[[協定世界時]](UTC)の[[1970年]][[1月1日]]0時からの経過秒数で送られている。データサイズは符号無し4バイト整数であるため最大経過秒数は4294967295秒までとなり、協定世界時の2036年2月6日午前6時28分16秒(日本時間では同日午後3時28分16秒)までとなる。<br>そのため、[[オーバーフロー]]が発生するより前に継続を行うための何らかの対処が必要となる。
 
RFC4330で以下の改善案が提示された。<br>
== 時計サーバとの伝送モードと同期について ==
最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなす。<br>
=== 送モード ===
2036年2月7日6時28分16秒(UTC)を起点として計算することで2036年問題を回避する方法である。<br>
SNTPおよびNTPを使用するには伝送モードの種類がある。NTPパケットには「Mode」と言われる3ビットのフィールドがある。多くのSNTPソフトは、サーバ・クライアントモードを使用して同期処理を行う。
<br>
{| border="1" width="100%"
|-
|mode値||内容
|-
|1,2||本来は時計サーバ同士の同期に使用。UNIX系OSのNTPサーバではpeer設定にて動作するモードである。
|-
|3,4||時計サーバと時計クライアントの組合せで同期に使用。
UNIX系OSのNTPサーバではServer設定にて動作するモードである。
SNTPに使用するNTPDATEコマンドで使用される。
多くのSNTPクライアントではこの仕様が採用されている。
|-
|5||放送モードは、サーバより一方的にNTPフレームをで[[ブロードキャスト]]または[[マルチキャスト]]による同期方式送信を行うある<br>
このモードは時計サーバより一方的にNTPパケット送信する。SNTPクライアント、NTPクライアントはこれを受信し、かつ推定遅延値を加算して時計を反映する。マルチキャストで使用可能なように[[IPv4]]はRFC-1700、[[IPv6]]はRFC-2375にマルチキャストアドレスが割り当てられている。
:IPv4=224.0.1.1
:IPv6=FF0X:0:0:0:0:0:0:101
|-
|6,7||NTPの状態の参照、設定等に使用する伝送モードである。ntpq、ntpdcコマンドで使用する。RFC-1305のオプション機能として記述されるが、SNTPはこの機能を実装する必要はない。
|}
NTPは基本的にすべてのモードをサポートする必要があるが、SNTPはどれを利用してもよく、どれか1つサポートすれば基本的にSNTPといえる。SNTPには規定がないのである。
 
=== 同期 ===
SNTPは1回の通信で時計反映処理に移行できる。一般的ソフトはstratum値が正常であること、閏秒指示子(Leap Indicator値)が正常であれば時計信用する。
同期に関する、RFCとしての仕様は未定義である。そのため実装者にゆだねられる。<br>
 
一般的ソフトでは、閏秒指示子(Leap Indicator値)が正常であれば同期を行うようになっている。<br>
<!-- NTPと重複
== 関連RFC ==
== 時計構成 ==
RFC1361 SNTP<br>
[[グローバル・ポジショニング・システム|GPS]]や[[電波時計]]、[[原子時計]]などの正確な時刻源 (stratum0) に直結されたサーバルートとする、階層構造をもつ。stratumとは時計の階層値であり以下のようになっている。
RFC1769 SNTP<br>
{| border="1" width="100%"
RFC2030 SNTP Version 4 for IPv4, IPv6 and OSI<br>
|-
RFC4330 SNTP Version 4 for IPv4, IPv6 and OSI<br>
|stratum値||内容
|-
| align="center"|0||正確な時刻源。ただしこれは直結された装置内処理で表にはでない。
ネットワーク上の時計サーバでこの値は無効な時計として処理される。
|-
| align="center"|1||直結された時計サーバである。これは、NTPサーバでもSNTPサーバでも良い。
|-
| align="center"|2~15||直接時刻源を持たず、ネットワーク上の時計サーバにSNTPまたはNTPにて接続された時計サーバであることを示す。時計として有効な値は1 - 15であり、それ以外の時計とは同期しないのが一般的時計処理とされている。
stratum=15で接続された時計サーバをクライアントとして接続すると、stratum=0としてパケットが送出される。よって、ネットワーク上でのstratum=0は同期してはいけない時計である。
|-
| align="center"|16~255||仕様上未定義あり用途が決められていない。
|}
-->
 
==関連項目==
*[[NTP]]