用 NTP 把控時間（一）：使用概覽

這系列共三部分，首先，Chirs Binnie 探討了在一個合理的架構中 NTP 服務的重要性。

鮮有互聯網上的服務能如時間服務一樣重要。影響你系統計時的小問題可能需要一兩天才能被發現，而這些不期而遇的問題所帶來的連鎖反應幾乎總是讓人傷腦筋的。

設想你的備份伺服器與網路時間協議（NTP）伺服器斷開連接，過了幾天，引起了幾小時的時間偏差。你的同事照常九點上班，發現需要大量帶寬的備份伺服器消耗了所有網路資源，這也就意味著他們在備份完成之前幾乎不能登錄工作台開始他們的日常工作。

這系列共三部分，首先，我將提供簡要介紹 NTP 來防止這種困境的發生。從郵件的時間戳到記錄你工作的進展，NTP 服務對於一個合理的架構是如此的重要。

可以把如此重要的 NTP 伺服器（其他的伺服器從此獲取時鐘數據）看做是倒置金字塔的底部，它被稱之為 一層 Stratum 1 伺服器（也被稱為「 主 primary 」伺服器）。這些伺服器與國家級時間服務（稱為 零層 Stratum 0 ，通常這些設備是是原子鐘和 GPS 鍾之類的裝置）直接交互。與之安全通訊的方法很多，例如通過衛星或者無線電。

令人驚訝的是，幾乎所有的大型企業都會連接 二層 Stratum 2 伺服器（或「 次級 secondary 」伺服器）而是不是主伺服器。如你所料，二層伺服器和一層直接同步。如果你覺得大公司可能有自己的本地 NTP 伺服器（至少兩個，通常三個，為了災難恢復之用），這些就是三層伺服器。這樣，三層伺服器將連接上層預定義的次級伺服器，負責任地傳遞時間給客戶端和伺服器，精確地反饋當前時間。

由簡單設計而構成的 NTP 可以工作的前提是——多虧了通過互聯網跨越了大範圍的地理距離——在確認時間完全準確之前，來回時間（包什麼時候發出和多少秒後被收到）都會被清楚記錄。設置電腦的時間的背後要比你想像的複雜得多，如果你不相信，那這神奇的網頁值得一看。

再次重提一遍，為了確保你的架構如預期般工作，NTP 是如此的關鍵，你的 NTP 與層次伺服器之間的連接必須是完全可信賴並且能提供額外的冗餘，才能保持你的內部時鐘同步。在 NTP 主站有一個有用的一層伺服器列表。

正如你在列表所見，一些 NTP 一層伺服器以 「ClosedAccount」 狀態運行；這些伺服器需要事先接受才可以使用。但是只要你完全按照他們的使用引導做，「OpenAccess」 伺服器是可以用於輪詢使用的。而 「RestrictedAccess」 伺服器有時候會因為大量客戶端訪問或者輪詢間隙太小而受限。另外有時候也有一些專供某種類型的組織使用，例如學術界。

尊重我的權威

在公共 NTP 伺服器上，你可能發現遵從某些規則的使用規範。現在讓我們看看其中一些。

「iburst」 選項作用是如果在一個標準的輪詢間隔內沒有應答，客戶端會發送一定數量的包（八個包而不是通常的一個）給 NTP 伺服器。如果在短時間內呼叫 NTP 伺服器幾次，沒有出現可辨識的應答，那麼本地時間將不會變化。

不像 「iburst」 ，按照 NTP 伺服器的通用規則， 「burst」 選項一般不允許使用（所以不要用它！）。這個選項不僅在輪詢間隔發送大量包（明顯又是八個），而且也會在伺服器能正常使用時這樣做。如果你在高層伺服器持續發送包，甚至是它們在正常應答時，你可能會因為使用 「burst」 選項而被拉黑。

顯然，你連接伺服器的頻率造成了它的負載差異（和少量的帶寬佔用）。使用 「minpoll」 和 「maxpoll」 選項可以本地設置頻率。然而，根據連接 NTP 伺服器的規則，你不應該分別修改其默認的 64 秒和 1024 秒。

此外，需要提出的是客戶應該重視那些請求時間的伺服器發出的「 親一下就死（死亡之吻） Kiss-Of-Death 」 （KOD）消息。如果 NTP 伺服器不想響應某個特定的請求，就像路由和防火牆技術那樣，那麼它最有可能的就是簡單地遺棄或吞沒任何相關的包。

換句話說，接受到這些數據的伺服器並不需要特別處理這些包，簡單地丟棄這些它認為這不值得回應的包即可。你可以想像，這並不是特別好的做法，有時候禮貌地問客戶是否中止或停止比忽略請求更為有效。因此，這種特別的包類型叫做 KOD 包。如果一個客戶端被發送了這種不受歡迎的 KOD 包，它應該記住這個發回了拒絕訪問標誌的伺服器。

如果從該伺服器收到不止一個 KOD 包，客戶端會猜想伺服器上發生了流量限速的情況（或類似的）。這種情況下，客戶端一般會寫入本地日誌，提示與該伺服器的交流不太順利，以備將來排錯之用。

牢記，出於顯而易見的原因，關鍵在於 NTP 伺服器的架構應該是動態的。因此，不要給你的 NTP 配置硬編碼 IP 地址是非常重要的。通過使用 DNS 域名，個別伺服器斷開網路時服務仍能繼續進行，而 IP 地址空間也能重新分配，並且可引入簡單的負載均衡（具有一定程度的彈性）。

請別忘了我們也需要考慮呈指數增長的物聯網（IoT），這最終將包括數以億萬計的新裝置，意味著這些設備都需要保持正確時間。硬體賣家無意（或有意）設置他們的設備只能與一個提供者的（甚至一個） NTP 伺服器連接終將成為過去，這是一個非常麻煩的問題。

你可能會想像，隨著買入和上線更多的硬體單元，NTP 基礎設施的擁有者大概不會為相關的費用而感到高興，因為他們正被沒有實際收入所困擾。這種情形並非杞人憂天。頭疼的問題多呢 -- 由於 NTP 流量導致基礎架構不堪重負 -- 這在過去幾年裡已發生過多次。

在下面兩篇文章里，我將著重於一些重要的 NTP 安全配置選項和描述伺服器的搭建。

via: https://www.linux.com/learn/arrive-time-ntp-part-1-usage-overview

作者：CHRIS BINNIE 譯者：XYenChi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive