<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                合規國際互聯網加速 OSASE為企業客戶提供高速穩定SD-WAN國際加速解決方案。 廣告
                ## 15.1 關于時區與網絡校時的通訊協議 時間對于現代人來說是很重要的,因為『 Time is money 』。既然時間如此重要,對于因特網來說應該也是很重要吧? 為什么呢?還記得我們在基礎學習篇第三版第十九章、登錄檔分析吧? 如果你架設了一個登錄檔服務器的話,那么總得要分析每個主機所傳來的登錄文件信息吧?如果每一部主機的時間都不相同, 那如何判斷問題發生的時間點?所以啰,『每一部主機的時間同步化』就很重要了。 每一部主機時間同步化的重要性當然不只如此,包括之前談到的 DHCP 客戶端/服務器端所需要的租約時間限制、 網絡偵測時所需要注意的時間點、剛剛談到的登錄文件分析功能、具有相關性的主機彼此之間的錯誤偵測、前一章談到的叢集計算機群等等, 都需要具有相同的時間才能夠捉出問題呢。好了,底下咱們就來聊一聊,如何利用網絡來進行主機的時間同步化吧! * * * ### 15.1.1 什么是時區?全球有多少時區?GMT 在那個時區? 因為地球是圓的,所以同一個時刻,在地球的一邊是白天,一邊是黑夜。而因為人類使用一天 24 小時的制度,所以,在地球對角的兩邊就應該差了 12 個小時才對。由于同一個時間點上面, 整個地球表面的時間應該都不一樣,為了解決這個問題,所以可以想見的,地球就被分成 24 個時區了! 那么這 24 個時區是依據什么來劃分的呢?由于地球被人類以『經緯度』坐標來進行定位, 而經度為零的地點在英國『格林威治』這個城市所在的縱剖面上, (注:所謂的縱剖面就是由南極切到北極的直線,而橫切面就是與赤道平行的切線),如下圖所示: ![](https://box.kancloud.cn/2016-05-13_5735da72d4ad3.gif) 圖 15.1-1、地球的子午線、經緯度與時區的分隔概念 因為繞地球一圈是 360 度角,這 360 度角共分為 24 個時區,當然一個時區就是 15 度角啦! 又由于是以格林威治時間為標準時間 (Greenwich Mean Time, GMT 時間),加上地球自轉的關系,因此,在格林威治以東的區域時間是比較快的(+小時),而以西的地方當然就是較慢啰! 以臺灣為例,因為臺灣所在地約為東經 120 度北緯 25 度左右,又因為臺灣在格林威治的東方 (廢話!因為是東經嘛! ^_^),因此臺灣本地時間 (local time) 會比 GMT 時間快 8 小時 (GMT + 8)。當格林威治時間為零點,臺灣就已經是早上八點了!底下約略列出各個時區的名稱與所在經度,以及與 GMT 時間的時差: | 標準時區 | 經度 | 時差 | | --- | --- | | GMT , Greenwich Mean Time | 0?? W/E | 標準時間 | | CET , Central European | 15? E | +1? 東一區 | | EET , Eastern European | 30? E | +2? 東二區 | | BT? , Baghdad | 45? E | +3? 東三區 | | USSR, Zone 3? | 60? E | +4? 東四區 | | USSR, Zone 4 | 75? E | +5? 東五區 | | Indian, First | 82.3E | +5.5東五半區 | | USSR, Zone 5 | 90? E | +6? 東六區 | | SST , South Sumatra | 105 E | +7? 東七區 | | JT? , Java | 112 E | +7.5東七半區 | | CCT , China Coast **(臺灣所在地)** | 120 E | +8? 東八區 | | JST , Japan | 135 E | +9? 東九區 | | SAST, South Australia | 142 E | +9.5東九半區 | | GST , Guam | 150 E | +10 東十區 | | NZT , New Zealand | 180 E | +12 東十二區 | | Int'l Date Line | 180 E/W | 國際日期變更線 | | BST , Bering | 165 W | -11 西十一區 | | SHST, Alaska/Hawaiian | 150 W | -10 西十區 | | YST , Yukon | 135 W | -9? 西九區 | | PST , Pacific | 120 W | -8? 西八區 | | MST , Mountain | 105 W | -7? 西七區 | | CST , Central | 90? W | -6? 西六區 | | EST , Eastern | 75? W | -5? 西五區 | | AST , Atlantic | 60? W | -4? 西四區 | | Brazil, Zone 2 | 45? W | -3? 西三區 | | AT? , Azores | 30? W | -2? 西二區 | | WAT , West Africa | 15? W | -1? 西一區 | 所以啰,臺灣時間是 GMT + 8 就很容易推算出來了吧!要特別留意的是,很多朋友在安裝 Linux 的時候, 總是會發現目前的時間慢或者快了 8 小時,不要懷疑,絕對與時區有關! 趕緊給他查一下如何調整時區吧! ^_^。 另外,在上表中有個比較有趣的時區,那就是在太平洋上面的國際日期變更線了!我們剛剛說,在格林威治的東邊時間會較快, 而在西邊時間會較慢,但是兩邊各走了 180 度之后就會碰頭啊!那不就剛好差了 24 小時嗎?沒錯啦! 所以才訂定為『國際日期變更線』啊!國際日期變更線剛好在太平洋上面,因此,如果你有坐飛機到美國的經驗應該會發現,咦! 怎么出發的時間是星期六下午,坐了 13 個小時的飛機到了美國還是星期六!因為剛好通過了國際日期變更線, 日期減少了一天喔!如果反過來,由美國到臺灣,日期就會多加一天喔! ^_^ * * * ### 15.1.2 什么是夏季節約時間 (daylight savings)? 時區的概念先建立起來之后,現在再來談一談,那么什么是『夏季節約時間 (或稱日光節約時間)』?既然是『夏季節約時間』當然主要是與夏天有關啦! 因為地球在運行的時候是呈現一個傾斜角在繞太陽運轉的,所以才有春夏秋冬 (這個大家應該都知道啦),在夏天的時候,白天的時間會比較長,所以為了節約用電, 因此在夏天的時候某些地區會將他們的時間定早一小時,也就是說,原本時區是 8 點好了, 但是因為夏天太陽比較早出現,因此把時間向前挪,在原本 8 點的時候,訂定為該天的 9 點 (時間提早一小時)~如此一來, 我們就可以利用陽光照明,省去了花費電力的時間,因此才會稱之為夏季節約時間! 因為臺灣實在是太小了,并沒有橫跨兩個時區,因此,夏季節約時間對我們來說,雖然還是有幫助啦! 不過,似乎沒有特別推行的樣子說~ * * * ### 15.1.3 Coordinated Universal Time (UTC)與系統時間的誤差 了解了一些時區的概念之后,這里要談的是『什么是正確的時間』。 在 1880 年代的時間標準是以 GMT 時間為主的,但是 GMT 時間是以太陽通過格林威治的那一刻來作為計時的標準。 然而我們都知道啊,地球自轉的軌道以及公轉的軌道并非正圓,加上地球的自轉速度好像有逐年遞減的問題, 所以這個 GMT 時間與我們目前計時的時間就有點不一樣了。([注1](#ps1)) 在計算時間的時候,最準確的計算應該是使用『原子震蕩周期』所計算的物理時鐘了 (Atomic Clock, 也被稱為原子鐘),這也被定義為標準時間 (International Atomic Time)。而我們常常看見的 UTC 也就是 Coordinated Universal Time (協和標準時間)就是利用這種 Atomic Clock 為基準所定義出來的正確時間。例如 1999 年在美國啟用的原子鐘 NIST F-1, 他所產生的時間誤差每兩千年才差一秒鐘!真的是很準吶!這個 UTC 標準時間雖然與 GMT 時間放在同一個時區為基準, 不過由于計時的方式不同,UTC 時間與 GMT 時間有差不多 16 分鐘的誤差呢!([注2](#ps2)) 事實上,在我們的身邊就有很多的原子鐘,例如石英表,還有計算機主機上面的 BIOS 內部就含有一個原子鐘在紀錄與計算時間的進行吶!不過由于原子鐘主要是利用計算芯片 (crystal) 的原子震蕩周期去計時的,這是因為每種芯片都有自己的獨特的震蕩周期之故。 然而因為這種芯片的震蕩周期在不同的芯片之間多多少少都會有點差異性,甚至同一批芯片也可能會或多或少有些許的差異 (就連溫度也可能造成這樣的誤差呢),因此也就造成了 BIOS 的時間會經常的給他快了幾秒或者慢了幾秒。 或許你會認為,BIOS 定時器每天快個五秒也沒有什么了不起的,不過如果你再仔細的算一算,會發現,一天快五秒,那么一個月快 2.5 分鐘,一年就快了 75 分鐘了!所以說,呵呵!時間差是真的會存在的!那么如果你的計算機真的有這樣的情況, 那要怎么來重新校正時間呢?那就需要『網絡校時』(Network Time Protocol, NTP) 的功能了!底下我們就談一談那個 NTP 的 daemon 吧! * * * ### 15.1.4 NTP 通訊協議 老實說, Linux 操作系統的計時方式主要是由 1970/01/01 開始計算總秒數,因此,如果你還記得 date 這個指令的話, 會發現它有個 +%s 的參數,可以取得總秒數,這個就是軟件時鐘。但,如同前面說的,計算機硬件主要是以 BIOS 內部的時間為主要的時間依據 (硬件時鐘),而偏偏這個時間可能因為 BIOS 內部芯片本身的問題,而導致 BIOS 時間與標準時間 (UTC) 有一點點的差異存在!所以為了避免主機時間因為長期運作下所導致的時間偏差,進行時間同步 (synchronize) 的工作就顯的很重要了! * 軟件時鐘:由 Linux 操作系統根據 1970/01/01 開始計算的總秒數; * 硬件時鐘:主機硬件系統上面的時鐘,例如 BIOS 記錄的時間; 那么怎么讓時間同步化呢?想一想,如果我們選擇幾部主要主機 (Primary server) 調校時間,讓這些 Primary Servers 的時間同步之后,再開放網絡服務來讓 Client 端聯機,并且提供 Client 端調整自己的時間,不就可以達到全部的計算機時間同步化的運作了嗎!那么什么協議可以達到這樣的功能呢?那就是 Network Time Protocol ,另外還有 Digital Time Synchronization Protocol (DTSS) 也可以達到相同的功能! 不過,到底 NTP 這個 daemon 是如何讓 Server 與 Client 同步他們的時間呢? 1. 首先,主機當然需要啟動這個 daemon ,之后, 2. Client 會向 NTP Server 發送出調校時間的 message , 3. 然后 NTP Server 會送出目前的標準時間給 Client , 4. Client 接收了來自 Server 的時間后,會據以調整自己的時間,就達成了網絡校時咯! 在上面的步驟中你有沒有想到一件事啊,那就是如果 Client 到 Server 的訊息傳送時間過長怎么辦?舉例來說,我在臺灣以 ADSL 的 PC 主機,聯機到美國的 NTP Server 主機進行時間同步化要求,而美國 NTP Server 收到我的要求之后,就發送當時的正確時間給我,不過, 由美國將數據傳送回我的 PC 時,時間可能已經延遲了 10 秒鐘去了!這樣一來,我的 PC 校正的時間是 10 秒鐘前的標準時間喔!此外,如果美國那么 NTP 主機有太多的人喜歡上去進行網絡校時了,所以 loading (負荷) 太重啦!導致訊息的回傳又延遲的更為嚴重!那怎么辦? 為了這些延遲的問題,有一些 program 已經開發了自動計算時間傳送過程的誤差,以更準確的校準自己的時間!當然啦,在 daemon 的部分,也同時以 server/client 及 master/slave 的架構來提供用戶進行網絡校時的動作!所謂的 master/slave 就有點類似 DNS 的系統咯!舉例來說,臺灣的標準時間主機去國際標準時間的主機校時, 然后各大專院校再到臺灣的標準時間校時,然后我們再到各大專院校的標準時間校時!這樣一來,那幾部國際標準時間主機 (Time server) 的 loading 就不至于太大,而我們也可以很快速的達到正確的網絡校時的目的呢!臺灣常見的 Time Server 有 ([注3](#ps3)): * tick.stdtime.gov.tw * tock.stdtime.gov.tw * time.stdtime.gov.tw * clock.stdtime.gov.tw * watch.stdtime.gov.tw 至于 ntp 這個 daemon 是以 port 123 為連結的埠口 (使用 UDP 封包),所以我們要利用 Time server 來進行時間的同步更新時,就得要使用 NTP 軟件提供的 ntpdate 來進行 port 123 的聯機喔!關于網絡校時更多的說明,可以到 NTP 的官方網站 ([注4](#ps4)) 上察看喔! * * * ### 15.1.5 NTP 服務器的階層概念 如前所述,由于 NTP 時間服務器采用類似階層架構 (stratum) 來處理時間的同步化, 所以他使用的是類似一般 server/client 的主從架構。網絡社會上面有提供一些主要與次要的時間服務器, 這些均屬于第一階及第二階的時間服務器 (stratum-1, stratum-2) ,如下所示: * 主要時間服務器: [http://support.ntp.org/bin/view/Servers/StratumOneTimeServers](http://support.ntp.org/bin/view/Servers/StratumOneTimeServers) * 次要時間服務器: [http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers](http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers) 由于這些時間服務器大多在國外,所以我們是否要使用這些服務器來同步化自己的時間呢? 其實如果臺灣地區已經有標準時間服務器的話,用那部即可,不需要聯機到國外啦!浪費帶寬與時間啊! 而如前面提到的,臺灣地區已經有標準的時間服務器了,所以當然我們可以直接選擇臺灣地區的 NTP 主機即可。 如果你評估一下,確定有架設 NTP 的需求時,我們可以直接選擇臺灣地區的上層 NTP 來同步化時間即可。 舉例來說 tock.stdtime.gov.tw 這個國家單位的主機應該是比較適合的。一般來說,我們在進行 NTP 主機的設定時,都會先選擇多部上層的 Time Server 來做為我們這一部 NTP Server 的校正之用,選擇多部的原因是因為可以避免因為某部時間服務器突然掛點時, 其他主機仍然可以提供我們的 NTP 主機來自我更新啊!然后我們的 NTP Server 才提供給自己的 Client 端更新時間。如此一來,國家單位的 tock.stdtime.gov.tw 負載才不會太大,而我們的 Client 也可以很快速的達到校時的動作! **Tips:** 其實 NTP 的階層概念與 DNS 很類似啦,當你架設一部 NTP 主機,這部 NTP 所向上要求同步化的那部主要主機為 stratum-1 時,那么你的 NTP 就是 stratum-2 啰!舉例來說,如果我們的 NTP 是向臺灣的 tock.stdtime.gov.tw 這部 stratum-2 的主機要求時間同步化,那我們的主機即為 stratum-3 ,如果還有其他的 NTP 主機向我們要求時間同步, 那么該部主機則會是 stratum-4 啦!就這樣啊~ 那最多可以有幾個階層?最多可達 15 個階層喔! ![](https://box.kancloud.cn/2016-05-13_5735736501917.gif) * * *
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看