二台のコンピューターの時計を合わせるとき、相手が送ってきた時刻をそのまま採用すると、メッセージが届くまでの時間だけ遅れてしまいます。NTP（Network Time Protocol）は、要求と応答に関わる四つの時刻から、時計のずれと往復の遅延を推定します。ただし、往復時間が分かっても、その時間が往路と復路にどう分かれているかまでは分かりません。ここに、推定値を読むときの大切な条件があります。
簡単にまとめると？
- NTPの基本計算は、クライアントの送信・受信と、サーバーの受信・送信の四時刻を使います。サーバー内で応答を待った時間は、往復遅延から差し引きます。
- 時計のずれの推定には、往路と復路の遅延差の半分が混ざります。往復時間が同じでも、二方向の内訳が変わると推定が変わります。
- これは一回の交換を切り出した説明です。実際の時刻同期では、複数回の観測や時計の変動、時刻を記録する位置も考える必要があります。
四つの時刻を、どちらの時計が記録したか
クライアントをA、時刻を問い合わせるサーバーをBとします。T1はAが要求を送る時刻、T2はBが要求を受け取る時刻、T3はBが応答を送る時刻、T4はAが応答を受け取る時刻です。T1とT4はAの時計、T2とT3はBの時計で測ります。RFC 5905の第8節は、この四時刻を使う交換と計算を記述しています。[1]
違う時計の値を引くと、通信時間だけでなく時計のずれも入ります。そこで、まず同じ時計で測った差を考えます。T4−T1はAが往復を待った時間、T3−T2はBが受信してから応答を送るまでの時間です。その差を取れば、Bの中で待った分を除けます。
往復遅延の推定 δ = (T4 − T1) − (T3 − T2)
一方、Bの時計がAよりどれだけ進んでいるかを表すオフセットの推定は、次の式です。プラスならBが進んでいる向きです。[1]
オフセットの推定 θ̂ = ((T2 − T1) + (T3 − T4)) ÷ 2
ここではθ̂の印で「推定したずれ」を示し、説明のために設定する真のずれθと区別します。また、一回の交換の間は二台の時計が同じ速さで進み、途中の時刻修正もなく、時刻の記録に丸めや揺らぎがない理想化したモデルを使います。
往路と復路を別々に書くと、誤差の正体が見える
往路の遅延をf、復路の遅延をrと置きます。BがAよりθだけ進んでいれば、T2−T1は「往路f＋時計のずれθ」です。T3−T4は、Bの送信後に復路rが経過してAが受け取るので「時計のずれθ−復路r」になります。
先ほどの推定式に入れると、θ̂ = θ + (f − r) ÷ 2です。往路と復路が同じなら後半がゼロになります。往路のほうが長ければBがより進んでいるように、復路のほうが長ければBがより遅れているように見えます。この式は四時刻の定義から、このモデルの条件の下で導いたものです。
サーバー内での待ち時間を差し引くことと、二方向の遅延差を知ることは別です。T3−T2が正確に分かっても、それだけではfとrの差を取り出せません。RFC 7679も、行き帰りが異なる経路を通る場合に加え、経路が対称でもキューでの待ち時間が非対称になり得ることを説明しています。[2]
往復40ミリ秒の二つのケース
具体的に、Bの時計がAより5ミリ秒進み、Bが要求を受けてから応答を送るまで2ミリ秒待つ場合を作ります。Aが送った瞬間をT1＝0とし、以下はすべて同じ基準付近のミリ秒表示です。実際のネットワークで測った値ではなく、式の意味を見るために選んだ入力です。
ケースAは往路20、復路20です。要求が届いたとき、A基準では20が経過し、Bの時計にはさらに5のずれがあるのでT2＝25。2待ってT3＝27、応答がAへ届くのはT4＝42です。δ＝42−2＝40、θ̂＝(25＋27−42)÷2＝5となり、設定した真のずれと一致します。
ケースBは往路12、復路28に変えます。時計の真のずれとサーバー内の待ちはそのままです。T2＝17、T3＝19、T4＝42になるので、往復遅延はやはり40です。しかしθ̂＝(17＋19−42)÷2＝−3。実際にはBが5進んでいるのに、推定は3遅れている向きになりました。誤差は−8で、(12−28)÷2と一致します。
同じ四時刻から、違う状況を説明できてしまう
さらに、ケースBで得た四時刻「0、17、19、42」だけを渡された場面を考えます。実は、この四つは、往路20・復路20で、Bの時計がAより3遅れている場合にも得られます。20−3＝17、そこから2待って19、往復を終えると42だからです。
つまり「本当は＋5だが経路が非対称」と「本当は−3で経路が対称」が、同じ観測を作ります。計算の桁数を増やしても、この二つを四時刻だけで区別できるようにはなりません。時刻情報の精密さと、未知の遅延を分離できることは異なります。
この理想モデルでfとrがともにゼロ以上と分かるだけなら、δ＝f＋rに対して、非対称性による誤差の絶対値は最大δ÷2です。δ＝40なら、θ̂＝−3を中心として真のθは−23から＋17まで取り得ます。これはモデルから導いた可能範囲であり、実測データに対する信頼区間でも、NTP製品の精度保証でもありません。時計の揺らぎや記録誤差を加えると、別の不確かさも必要になります。
同期結果を比較するときに、何を一緒に見るか
まず、往復遅延とオフセットを別の量として読みます。「往復が40だから片道は必ず20」「ずれの表示が−3だから真の差も−3」と読み替えると、上の二ケースを取り違えます。短い往復遅延は、この理想モデルで非対称性が作れる誤差の幅を狭めますが、幅の中のどこが真値かまでは教えてくれません。
次に、同じ条件で何回も測ったときの揺れと、一定して残る偏りを分けます。説明用モデルで毎回f＝12、r＝28なら、何回平均してもこの部分の偏り−8は消えません。実際のNTPには観測を選別するフィルターなどがあり、この一回の式だけで同期処理全体を表しているわけではありません。[1]
最後に、タイムスタンプをどこで記録したかも確認します。アプリケーションが時刻を読む瞬間と、ネットワークインターフェースをパケットが通る瞬間には差があり得ます。RFC 7679は、時計どうしの同期誤差と、ホスト側の時刻と回線上の時刻の違いを分けて不確かさとして扱っています。[2]
このため、異なる機器や方式の「同期精度」を比べるなら、観測期間、時計の基準、時刻を記録する位置、経路の対称性に置いた条件がそろっているかが判断材料になります。四時刻の式は、その条件を整理する出発点です。出てきた数値だけでなく、その数値にどんな遅延差が混ざり得るかまで読めると、時刻合わせの結果をより正確に解釈できます。
出典
[1] RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification（2010年6月、第8節・図15、第10節）。ここでは2010年版の基本計算を参照。後続更新を含む実装全体の解説ではありません。
[2] RFC 7679, A One-Way Delay Metric for IP Performance Metrics (IPPM)（2016年1月、第1.1節、第2節、第3.7.1–3.7.2節）。