NTP(Network Time Protocol)は、ローカルネットワークではミリ秒、グローバルネットワークでは数十ミリ秒の精度で時刻を同期するネットワークプロトコルです。1985年にDavid Millsによって開発されたこのプロトコルは、すべての最新オペレーティングシステム、モバイルデバイス、ネットワーク機器で内部クロックをUTC基準時刻に同期するために使用されています。NTP Pool Project(2026年)によると、毎日40億以上のデバイスが同期のためにNTPリクエストを実行しています。
重要なポイント
NTP(Network Time Protocol)は、パケット交換ネットワークを介してコンピュータの内部クロックを基準時刻ソースに正確に同期するために設計されたネットワークプロトコルです。RFC 5905(NTPv4)で説明されているこのプロトコルは、各レベルがストラタムと呼ばれるサーバーの階層システムを使用します。NTPクライアントはサーバーにリクエストを送信し、パケットのラウンドトリップ時間(RTT)を測定し、基準時刻に対する自身のクロックのオフセットを計算します。補正アルゴリズムは、単一のオフセットだけでなくクロックジェネレータのドリフトも考慮するため、繰り返しリクエストなしで長期間精度を維持できます。
このプロトコルはDavid Millsによって1985年にARPANETネットワーク向けに開発されました。最初の仕様(RFC 958)は、最大100 msの精度を持つ単純な同期アルゴリズムを記述していました。NTPv3(RFC 1305、1992)はフィルタリングアルゴリズムと遅延処理の改善を追加しました。NTPv4(RFC 5905、2010)は現在のバージョンで、IPv6サポート、自動サーバー設定、Network Time Security(NTS)による攻撃保護を含んでいます。40年の間に、このプロトコルは研究プロジェクトからインフラストラクチャ標準へと進化し、金融取引、通信、モバイルネットワークに不可欠なものになりました。
NTPの動作原理は、ネットワーク上のパケットの移動時間の測定に基づいています。クライアントはタイムスタンプT1(ローカル送信時刻)とともにリクエストを送信します。サーバーは時刻T2(サーバー時刻)でリクエストを受信し、タイムスタンプT3とともに応答を生成して送信します。クライアントは時刻T4で応答を受信します。4つのタイムスタンプすべてを使用して、クライアントはオフセット= ((T2 - T1) + (T3 - T4)) / 2と遅延= (T4 - T1) - (T3 - T2)を計算します。遅延が1秒を超える場合、結果は信頼できないと見なされます。これは過負荷または不安定なチャネルから保護します。
正確な時刻を設定するだけでは十分ではありません。デバイスの水晶発振器は、温度、経年劣化、電圧により常にドリフト(進みまたは遅れ)します。NTPはPLL(Phase-Locked Loop)アルゴリズムを使用してこの問題を解決します。強制的に時刻を設定するのではなく、クロック速度を調整します。デバイスが1時間あたり0.1秒進んでいる場合、NTPはドリフトが補正されるまでシステムクロックを遅くします。このアプローチにより、安定したネットワークでは30秒ごとではなく数時間ごとに同期できます。
// Simplified NTP algorithm schema
struct NTPPacket {
uint8_t flags; // LI, VN, Mode
uint8_t stratum; // server stratum level
uint32_t refTimestamp; // reference timestamp
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Calculate offset and delay
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
NTPシステム全体は階層的に構成され、各レベルはストラタムと呼ばれます。ストラタム0は基準クロックです。原子時計、GPS受信機、WWVB無線信号などです。これらのデバイスはネットワークに直接接続されていません。ストラタム1は基準クロックに直接接続されたサーバーです。ストラタム2はストラタム1から時刻を受け取り、ストラタム3はストラタム2から、というようにストラタム15まで続きます。ストラタム番号が大きいほど、精度は低くなる可能性があります。各レベルはわずかな遅延と誤差を追加します。ストラタム16は時刻が利用できない(同期されていない)ことを意味します。
| ストラタム | 説明 | 精度 |
|---|---|---|
| Stratum 0 | 原子時計、GPS、無線信号 | ナノ秒 |
| Stratum 1 | 基準に接続されたサーバー | マイクロ秒 |
| Stratum 2 | 公開NTPサーバー | 1–10 ms |
| Stratum 3 | 組織のローカルサーバー | 10–50 ms |
| Stratum 4+ | クライアントデバイス | 最大100 ms |
モバイルデバイスには、ストラタム2サーバーが最適です。十分な数があり、精度と可用性のバランスが取れています。例えば、pool.ntp.orgは世界中の何千ものサーバーのプールで、自動的に負荷を分散します。Androidアプリケーションでは、ストラタム1を直接使用することは推奨されません。第一に、プライマリサーバーに過剰な負荷がかかり、第二に、モバイルデバイスにはストラタム2が提供する10~50 msの精度で十分です。企業ネットワークでは、外部のストラタム2と同期するローカルのストラタム3-4サーバーが設置されます。
SNTP(Simple Network Time Protocol、RFC 4330)は、リソースに制約のあるデバイス向けのNTPの簡略化された実装です。マイクロコントローラ、IoTセンサー、高精度を必要としないモバイルアプリケーションなどです。完全なNTPとは異なり、SNTPは複数サーバーのフィルタリングを実行せず、クロックドリフトを分析せず、複雑なPLLアルゴリズムも使用しません。SNTPクライアントはリクエストを送信し、応答を受信し、一度だけ時刻を設定します。SNTPの精度はネットワークに応じて10~100 msで、金融取引を除くほとんどのモバイルシナリオに十分です。
SNTPは、継続的な同期を維持せずにサーバーから現在時刻を取得するだけでよいAndroidアプリケーションに適しています。例えば、アプリがログイン時にサーバー時刻を表示したり、1日に1回同期したりする場合です。完全なNTPは、一定の精度とドリフト監視が重要なサーバーシステム、通信機器、金融プラットフォーム、分散データベースに必要です。モバイル開発にはSNTPで十分です。Androidの組み込み時刻サービスは、Googleサーバーとの定期的な同期にこれを使用しています。
AndroidアプリケーションでNTPを介して正確な時刻を取得する必要があるのは、システム時刻がユーザーによって変更される可能性がある場合や、ネットワークがないために実際の時刻と異なる場合です。Androidには組み込みの公開NTPクライアントがありません。開発者はApache Commons Net SntpClientライブラリまたはサードパーティのソリューションを使用します。2022年、GoogleはAndroid APIに(Google Play Servicesを介して)内部的なSntpClientクラスを追加しましたが、設定が必要で一般的な使用は文書化されていません。別の方法として、応答本文にサーバータイムスタンプを返すREST APIを介して時刻を要求する方法があります。
Androidでの基本的なSNTP実装は、NTPサーバー(pool.ntp.orgなど)にUDPパケットを送信し、応答を解析し、送信タイムスタンプ(T3)を抽出することで構成されます。コードはネットワークタイムアウトと解析エラーを処理する必要があります。実際のアプリケーションでは、この操作はバックグラウンドスレッドで実行され、結果は次の同期までキャッシュされます。Apache Commons Netライブラリは、build.gradleに依存関係を追加するだけで最小限の変更でAndroidで使用できる既製のNTPUDPClientクラスを提供します。
// Get NTP time via Apache Commons Net
fun getNtpTime(server: String = "pool.ntp.org"): Date? {
return try {
val client = NTPUDPClient()
client.setDefaultTimeout(5000)
val info = client.getTime(InetAddress.getByName(server))
client.close()
Date(info.getMessage().getTransmitTimeStamp().getTime())
} catch (e: Exception) {
null
}
}
NTPの精度は、ネットワーク遅延(RTT)、チャネル安定性、サーバー負荷、ローカルクロックジェネレータの品質など、いくつかの要因に依存します。1 ms未満の遅延のローカルネットワークでは、NTPは0.1~1 msの精度を達成します。10~50 msの遅延のインターネットでは、精度は10~50 msに低下します。単発の精度よりも重要なのは安定性です。遅延が変動する(ジッター)場合、NTPは信頼できるオフセットを計算するためにより多くの時間を必要とします。モバイルデバイスの場合、主な不安定性要因はWi-Fiとモバイルネットワーク間の切り替えであり、遅延が桁違いに変化する可能性があります。
正確な時刻に敏感なAndroidアプリケーションでは、複数のNTPサーバーを使用して最も遅延の少ないものを選択し、ネットワーク切り替え時の同期を避け、最後に取得した時刻をキャッシュしてSystem.currentTimeMillisで調整することをお勧めします。ゲームやリアルタイムアプリケーション(ネットワークレイテンシのためNTPは適していません)では、各リクエストで渡されるサーバー時刻を使用してください。金融アプリケーションでは、常にサーバーとの差異を確認し、差が5秒を超える場合は、操作を潜在的に安全でないとしてブロックしてください。
よくある質問
NTP(Network Time Protocol)は、インターネット経由のクロック同期プロトコルです。UTC基準とデバイスの時刻を合わせるために必要です。NTPがないと、水晶発振器のドリフトによりコンピュータのクロックは1日に数秒ずれ、金融取引、ログ記録、セキュリティに重大な影響を与えます。
NTPシステムはレベル(ストラタ)を使用します。ストラタム0(原子時計とGPS)、ストラタム1(基準に接続されたサーバー)、ストラタム2(公開NTPサーバー)、ストラタム3~4(ローカルサーバー)、ストラタム5~15(クライアント)。ストラタムが高いほど、潜在的な誤差が大きくなります。ストラタム16は時刻が同期されていないことを意味します。
SNTPは、リソースに制約のあるデバイス向けのNTPの簡略版です。サーバーのフィルタリング、クロックドリフトの分析、PLLの使用は行いません。SNTPは10~100 msの精度で十分なモバイルアプリケーションに適しています。完全なNTPはサーバー、通信機器、フィンテックシステムに必要です。
Apache Commons NetライブラリをNTPUDPClientクラスとともに使用します。pool.ntp.orgにリクエストを送信し、応答を取得して送信タイムスタンプを抽出します。別の方法として、サーバーのREST APIを使用し、DateヘッダーまたはUnix Timestamp形式の応答本文でサーバー時刻を返す方法もあります。
NTP同期がないと、デバイスのシステム時刻が数分から数時間ずれる可能性があります。これにより、プッシュ通知、SSL証明書検証、ログ、タスクスケジューラ、暗号化プロトコルが disrupted されます。金融アプリケーションでは、5秒以上の差はセキュリティ上の脅威と見なされます。
まとめ
ターンキー方式のモバイルアプリケーションを開発します
IT Sectrは2017年からスタートアップや企業向けにiOS・Androidアプリケーションを開発しています。私たちがご相談に乗り、最適なソリューションをご提案します。