時刻プロトコル (RFC 868)

動作

時刻は、接続型またはコネクションレス型のどちらのトランスポートでも運べます。両者の違いはフレーミングと配送方法だけで、時刻の表現は同じです。

• TCPモード: クライアントは、ポート37で待ち受けるサーバーへTCP接続を確立します。サーバーは4バイトの値（1900年起点からの秒数）を書き込み、その後接続を閉じます。クライアントはこの4バイトを読み取り、ビッグエンディアンの符号なし整数をローカル時刻値へ変換します。手順の詳細は RFC 868 を参照してください。
• UDPモード: クライアントは、サーバーのポート37へ（しばしば空の）UDPデータグラムを送信します。サーバーは、同じ32ビット値を含む4バイトのデータグラムを1つ返します。UDPはコネクションレスであるため、ハンドシェイクも配信保証もなく、クライアントは再送したりTCPへ切り替えたりできます。

使用されるトランスポートは一般的なインターネット・トランスポートで、信頼性のあるバイトストリームとしての TCP と、単純なデータグラム用の UDP です。数値はネットワークバイトオーダー（ビッグエンディアン）で符号化され、分解能は1秒単位に限られます。

表現、制限、相違点

このプロトコルの起点は 1900-01-01 00:00:00 GMT です。形式が32ビットの符号なし秒カウントであるため、ラップするまでにおよそ136年分の秒を表せます。この有限の範囲は、21世紀半ばに注目すべきロールオーバー問題を生みます。32ビットの時刻カウンタに依存するシステムは、巻き戻りが正確さに影響する前に更新または置き換える必要があります。時刻プロトコルにはタイムゾーン情報、サブ秒精度、うるう秒の明示的な対応は含まれません。クライアントは返されたGMT値を解釈し、必要に応じてローカルのオフセットを適用します。

歴史と他プロトコルとの関係

時刻プロトコルは、時計の同期を粗いレベルで合わせるだけでよいホスト向けの、単純明快な方法として、ARPANETとインターネットの初期開発の中で生まれました。やがて、より高精度で連続的な同期、階層的な時刻配信、ネットワーク遅延やジッタを補正する仕組みを備えた Network Time Protocol（NTP）に、ほとんど置き換えられました。それでも時刻プロトコルは、旧互換性や、1秒精度で十分な単純な用途のために文書化されたまま残っています。

用途、例、実用上の注意

時刻プロトコルの典型的な用途には、システム時計の初期設定、簡単な診断、そして完全なNTPスタックを実装する必要のない軽量デバイスやサービスへの組み込みが含まれてきました。歴史的には、一般的なユーティリティがポート37のサービスを使ってローカルのシステム時刻を設定していました。認証がなく分解能も低いため、セキュリティが重要な用途や高精度が必要な用途には適していません。

実運用では、管理者はより現代的な時刻同期手段を優先すべきです。ネットワーク上で時刻プロトコルを見かけた場合は、レガシーサービスとして扱ってください。簡易確認や制約のある環境では役立つことがありますが、完全性、認証、ネットワーク遅延の補正は提供しません。公式のプロトコル詳細や動作は RFC 868 を参照し、TCP と UDP については各トランスポート標準を参照してください。

特筆すべき点として、このプロトコルの単純さは初期のハードウェアでも実装しやすかったことが挙げられます。4バイトのビッグエンディアン形式は、今日でも一部の組み込みシステムで使われています。ただし、起点の制限と現代的機能の欠如により、精度や堅牢性が必要な場合、現在の導入先の多くはNTPやPrecision Time Protocol（PTP）へ移行します。