PR

時刻を問い合わせる

 ネットワークを使ってシステムの時刻を合わせるためには、どこかに正確な時計が必要になります。正確な時刻を持つホストがあれば、そこに現在時刻を問い合わせ、自身の時刻を修正すればいいわけです。

 このために最初に作られたのが、Timeプロトコル(RFC0868)です。これは、サーバーに対して問い合わせを行うと、32ビットで表現された現在時刻(UTC1900年1月1日0時0分0秒からの経過秒数)が返されるものです。TCP(伝送制御プロトコル)とUDP(ユーザー・データグラム・プロトコル)の両方で定義され、ウェルノウン・ポートとして37番を使います。

 TCPの場合、クライアントが正確な時刻を持っているサーバーに対して37番ポートに接続すれば、サーバーから32ビットで表現された時刻データが送られてきます。クライアントは受信したら、TCPセッションを終了させます。

 UDPを使う場合には、クライアントがサーバーの37番ポートに対して、中身がない(つまりIPとUDPヘッダーのみ)のパケットを送ります。サーバーは、これを受信したら、送信元のIPアドレス、ポート番号に対して、32ビットの時刻データを送信し、プロトコルが終了します。

 このTimeプロトコルが作られたのは、1983年のことです。最近のパソコンなどの時計は、バッテリでバックアップされ、電源スイッチを切っても、時計だけは動いているような構成になっています。しかしかつては、こうした機構がなく、電源を入れるたびに日付や時刻を設定する必要がありました。このTimeプロトコルを使えば、起動後に時刻を入手できるため、手動で設定する必要がなくなります。

 しかし、このプロトコルには、少し問題があります。まず、ネットワークの遅延を考慮していないので、イーサーネットなどで直接つながった、ローカル環境でしか利用できないことです。インターネットを流れるパケットは、いくつものルーターを経由し、その際受信したパケットをメモリーなどに記録してから送出するため、遅延が発生します。送出先のネットワークとの接続経路があまり速くない場合には、そこを通過するときにも時間がかかります。このため、たとえ正確な時刻をサーバー側が教えてくれたとしても、受け取ったときには、かなり時間が先に進んでいる可能性があります。これが1秒を超えると大きな誤差となります。

 もう1つの問題は、サーバー・マシンの負荷などが考慮されていないことです。Webでページを見ているときなどでも、リンクをクリックしてからページ・データが送られてくるまでに時間がかかることがあります。これには、ネットワークの遅延のほか、サーバーの負荷が高いという理由が考えられます。リクエストを受け付けてからデータの送出を始めるまでに、ほかの処理などに時間を取られて反応が遅れてしまうからです。

 Timeプロトコルでは、もし、サーバーが過負荷の状態になったとしたら、サーバーが時刻データを用意してから送出が始まるまでに、ある程度の時間がかかってしまうかもしれません。