アカウント名:
パスワード:
NTPは地味ながらも、今のインターネットの基幹として非常に需要なサービスだと思います。
ですが、NTPそのものの問題ではないんですが、そのNTPサーバ指定を自動できないのが運用上最大の難点だと思ってます。
本来のNTPの思想としては、・ネットワークトポロジーに合わせて随所にNTPサーバを立てて、・末端のクライアントは近場の(LAN内の)NTPサーバに時刻を問い合わせるという形になるべきなんでしょうけど、DHCPはオプションでNTPサーバ通知できるけど、Windowsは対応してないし、PPPoE(IPCP)は、NTPサーバ通知機能がない。
なので、ローカルにNTPサーバ立てても、それを使うのに
>本来のNTPの思想としては、
それは、NTPの思想というより、精度や広域トラフィックを想定しての構築ノウハウの話です。ネットワーク上の複数ノード間で高精度に時刻を相互同期させる(配る、ではない)動作を目的として頻繁に時間情報を投げ合う様な場合を想定しての話であり、その場合にどのサーバをどういう信用関係で連携させるかは管理者が高度な判断をして設定するもので自動設定とかはありえないんです。
後半仰っているような例だと、AD使っている組織のWindows PCなんかは普通に起動時に単発で組織のサーバに時刻合わせするのですが、それでは不足なんでしょうか？個人のPCでは初期設定こそ必要ですが、ntp.microsoft.comへの時間合わせの通信なんかも単発で問い合わせするだけなんで、ゴミですやん。MSがWindows updateのサービスにどのくらいデータのトラフィックを裁いているかとか、ちょっと考えればわかりますよね。
NTPにブロードキャストが規定されてるんですから、NTPのプロトコル設計としてはサーバだけのものではなく、最終的には末端のクライアントまで時刻を届けるのが想定されたものでしょ。
ただ本来の想定は、ブロードキャストで届けるからクライアントはNTPサーバ設定不要、のはずだったんでしょう。「いつでもどこでもNTPブロードキャスト環境」ならそれでもいけたんでしょうけど、NTPブロードキャストが確実にあると言えるとこまで普及しなかったからクライアントが確実に時計合わせしたかったら、ユニキャストでサーバ決め打ち問い合わせするようになっちゃった、という認識です。
> 単発で問い合わせするだけなんで、ゴミですやん。
チリも積もりますよ。私は15年ぐらい前からpool.ntp.org に参加してましたが、5年ほど前に、トラィック増大に耐えきれずに参加をやめました。(Androidは pool.ntp.org を使ってるらしい?)
なんか論点ずらしてるよね。
当初はブロードキャストのことは知らなかったようだけど、ツッコミを受けてからブロードキャストと言い出してたり、とにかく主張がブレてる。
主張がブレるのは当然で、福岡大学の問題とNTPの問題だけを取り上げて、NTPのプロトコルの問題だと言い張るのがそもそも無理筋なんだよ。
まずNTPのプロトコルと、時刻サーバーとしてどのIPと通信するかつまりクライアントの設定の話は、全く別の話。
クライアント側の設定なんて、例えばDHCPで配るとか、いくらでも対処策がある。ネットワーク側でも対処方法はあって、DNSのラウンドロビンで負荷分散するとか、別コ
「NTPのプロトコルの問題だと言い張」ってなんていませんよ。
私は一番最初のコメントで「NTPそのものの問題ではないんですが」と述べてます。見当違いも甚だしい。
「友達の話なんだけど」って話しているのに自分の話と思われたってぐらい無理筋。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
NTPサーバ設定が自動できないのがネック (スコア:3, 興味深い)
NTPは地味ながらも、今のインターネットの基幹として非常に需要なサービスだと思います。
ですが、NTPそのものの問題ではないんですが、そのNTPサーバ指定を自動できないのが運用上最大の難点だと思ってます。
本来のNTPの思想としては、
・ネットワークトポロジーに合わせて随所にNTPサーバを立てて、
・末端のクライアントは近場の(LAN内の)NTPサーバに時刻を問い合わせる
という形になるべきなんでしょうけど、
DHCPはオプションでNTPサーバ通知できるけど、Windowsは対応してないし、
PPPoE(IPCP)は、NTPサーバ通知機能がない。
なので、ローカルにNTPサーバ立てても、それを使うのに
Re: (スコア:0)
>本来のNTPの思想としては、
それは、NTPの思想というより、精度や広域トラフィックを想定しての構築ノウハウの話です。
ネットワーク上の複数ノード間で高精度に時刻を相互同期させる(配る、ではない)動作を目的として頻繁に時間情報を投げ合う様な場合を想定しての話であり、その場合にどのサーバをどういう信用関係で連携させるかは管理者が高度な判断をして設定するもので自動設定とかはありえないんです。
後半仰っているような例だと、AD使っている組織のWindows PCなんかは普通に起動時に単発で組織のサーバに時刻合わせするのですが、それでは不足なんでしょうか？
個人のPCでは初期設定こそ必要ですが、ntp.microsoft.comへの時間合わせの通信なんかも単発で問い合わせするだけなんで、ゴミですやん。
MSがWindows updateのサービスにどのくらいデータのトラフィックを裁いているかとか、ちょっと考えればわかりますよね。
Re: (スコア:2)
NTPにブロードキャストが規定されてるんですから、NTPのプロトコル設計としては
サーバだけのものではなく、最終的には末端のクライアントまで時刻を届けるのが想定されたものでしょ。
ただ本来の想定は、ブロードキャストで届けるからクライアントはNTPサーバ設定不要、のはずだったんでしょう。
「いつでもどこでもNTPブロードキャスト環境」ならそれでもいけたんでしょうけど、
NTPブロードキャストが確実にあると言えるとこまで普及しなかったから
クライアントが確実に時計合わせしたかったら、ユニキャストでサーバ決め打ち問い合わせするようになっちゃった、という認識です。
> 単発で問い合わせするだけなんで、ゴミですやん。
チリも積もりますよ。
私は15年ぐらい前からpool.ntp.org に参加してましたが、
5年ほど前に、トラィック増大に耐えきれずに参加をやめました。
(Androidは pool.ntp.org を使ってるらしい?)
Re: (スコア:0)
なんか論点ずらしてるよね。
当初はブロードキャストのことは知らなかったようだけど、ツッコミを受けてからブロードキャストと言い出してたり、とにかく主張がブレてる。
主張がブレるのは当然で、福岡大学の問題とNTPの問題だけを取り上げて、NTPのプロトコルの問題だと言い張るのがそもそも無理筋なんだよ。
まずNTPのプロトコルと、時刻サーバーとしてどのIPと通信するかつまりクライアントの設定の話は、全く別の話。
クライアント側の設定なんて、例えばDHCPで配るとか、いくらでも対処策がある。
ネットワーク側でも対処方法はあって、DNSのラウンドロビンで負荷分散するとか、別コ
Re:NTPサーバ設定が自動できないのがネック (スコア:1)
「NTPのプロトコルの問題だと言い張」ってなんていませんよ。
私は一番最初のコメントで「NTPそのものの問題ではないんですが」と述べてます。見当違いも甚だしい。
Re: (スコア:0)
「友達の話なんだけど」って話しているのに自分の話と思われたってぐらい無理筋。