tévék. Konzolok. Projektorok és tartozékok. Technológiák. Digitális TV

Az NTP egy atomóra minden asztalon. Nézze meg, mi az "NTP" más szótárakban Milyen módokat támogat az ntp protokoll?


Az időszinkronizálás fontos feladat, bár nem sokan gondoltak rá. Nos, mi a baj azzal, ha elszalad az idő egy szerveren? Tudta, hogy sok óraprobléma érinti a kriptográfiával kapcsolatos protokollokat? Emiatt be Active Directory Az 5 percnél nagyobb óraeltérés Kerberos hitelesítési problémákat okoz.

Óránkénti szintek. Strata.

Megérteni NTP eszköz tudnia kell a koncepcióról rétegek vagy réteg. Hiteles időforrások, mint például GPS műholdak, cézium atomórák, WWVB rádióhullámok – mindez réteg 0. Azon az alapon mérvadóak, hogy van valamilyen módjuk a rendkívül pontos időmérésre. Természetesen használhatja a szokásosat kvarc óra, de tudván, hogy egy hónap alatt könnyen veszíthet velük 15 másodpercet, jobb, ha nem használja őket időmérőként. 0. réteg Ilyenkor egy másodperc sem vész el 300 000 év alatt!

Olyan számítógépek, amelyek közvetlenül (nem a hálózaton keresztül!) időt vesznek igénybe réteg 0- Ezt réteg 1. Mivel mindig vannak késések a jelátvitel és az időbeállítás költségei miatt, a számítógépek réteg 1 nem olyan pontos, mint réteg 0, hanem benne igazi életet a különbség eléri a pár mikroszekundumot (1 μs = 10 -6 s), ami teljesen elfogadható eltérés.

A számítógépek következő szintje, amelytől a hálózaton keresztül időt vesz igénybe réteg 1- ez... dobpergés... intrika... réteg 2! Ismét a különböző késések miatt (hálózati késések biztosan), réteg 2 kicsit lemaradva réteg 1és minden bizonnyal attól réteg 0. A gyakorlatban ez néhány mikroszekundum (1 μs = 10 -6 s) és több milliszekundum (1 ms = 10 -3 s) közötti eltérést jelent. Sokan nem akarnak tovább szinkronizálni a réteggel réteg 2.

Amint a diagramból kiderül, réteg 4 időt vesz igénybe egy felettesétől 3. réteg. 5. réteg at réteg 4és így tovább. réteg 16 a legtöbbet tartották alsó rétegés ott az idő számít szinkronizálatlan.

Az idő NTP használatával történő szinkronizálásához először manuálisan kell beállítania az időt. Nem lehet 1000 másodpercnél nagyobb különbség a pontos idő és az óra között. Ha az Ön által használt időszerver több mint 1000 ezredmásodpercig (1 másodperc) hazudik, akkor a rendszer kizárja a listáról, és helyette másokat használ. Ez a mechanizmus lehetővé teszi a rossz időforrások kiszűrését.

Idő ügyfél.

Az /etc/ntp.conf fájlban a Server sorok fontosak az ügyfél számára. Több is lehet - akár 10 darab!

Mennyit kell hozzá? Kérjük, tartsa szem előtt:

  • Ha csak egy szervered van (egysoros szervered), akkor ha ez a szerver elkezd hazudni, akkor vakon követed. Ha az ideje letelik 5 másodperccel és te rohansz utána.
  • Ha 2 szervert ad hozzá (2 szerversor), akkor az NTP mindkettőt megjelöli hamis tickerek. Ha egyikük hazudik, akkor az NTP nem tudja megérteni, hogy ki hazudik, mivel nincs határozatképesség.
  • Ha 3 vagy több időszervert adunk hozzá, akkor egy hazug azonosítható hamis tickerek. Ha 5 vagy 6 időszerver van, akkor 2 hazudozót találhat hamis tickerek. Ha 7 vagy 8 szerver van, akkor 3 hamis tickerek. Ha 9 és 10 szerver van, akkor 4 hamis tickerek.

NTP Pool projekt.

Van egy NTP Pool nevű projekt, amelyen a pool.ntp.org/zone/ru/ címen orosz felhasználóknak ajánlott időszervereket találhat.

szerver 0.ru.pool.ntp.org
szerver 1.ru.pool.ntp.org
szerver 2.ru.pool.ntp.org
szerver 3.ru.pool.ntp.org

Az olyan operációs rendszerek, mint a Debian és az Ubuntu, saját időszervereket kínálnak a felhasználóknak.

szerver 0.debian.pool.ntp.org
szerver 1.debian.pool.ntp.org
szerver 2.debian.pool.ntp.org
server3.debian.pool.ntp.org

szerver 0.ubuntu.pool.ntp.org
szerver 1.ubuntu.pool.ntp.org
szerver 2.ubuntu.pool.ntp.org
szerver 3.ubuntu.pool.ntp.org

Ha az ntpq -pn parancsot futtatja az NTP-t használó Linux számítógépen

Távoli újrajavítás, amikor a lekérdezés elérési késleltetése eltolása jitter ========================================== ========================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53,658 -0,877 1,174 +85 21,78,23 193 190 230,65 2 u 1027 1024 377 54,651 0,108 317 * 61589317 51.24 2 u 940 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482

Mit mondanak az oszlopok nevei:

  • távoli- távoli szerverek, amelyekkel szinkronizálja az időt.
  • refid- kiváló réteg ehhez a szerverhez.
  • st- rétegszint. 0-tól (számunkra nem elérhető) 16-ig (számunkra nem kívánatos). Ideális - 2.
  • t- kapcsolat típusa. " u" - unicast vagy manycast, " b" - broadcast vagy multicast, " l"helyi referenciaóra", s" - szimmetrikus csomó," A" - manycast szerver, " B" - broadcast szerver, " M" - multicast szerver.
  • amikor- az idő, amikor a szerver utoljára válaszolt nekünk. A paraméter másodpercben jeleníti meg a számot, de percben is megjelenhet, ha a szám m vagy órákban ha h.
  • szavazás- lekérdezési gyakoriság. Minimum 16 másodperc, maximum 32 óra. A számnak 2n-nek kell lennie. Ez a paraméter általában 64 másodpercet vagy 1024-et jelenít meg.
  • elérheti- 8 bites oktett, amely a távoli időszerverrel folytatott kommunikáció állapotát jelzi: sikeres vagy sikertelen. Ha a bitek be vannak állítva, akkor sikeres, ellenkező esetben kudarc. A 377 bináris érték: 0000 0000 1111 1111.
  • késleltetés- az ezredmásodpercben megadott érték a válasz küldése és fogadása között eltelt időt mutatja (oda-vissza út - RTT).
  • beszámítás- az Ön és az időkiszolgálók közötti eltolás ezredmásodpercben. Lehet pozitív vagy negatív szám.
  • izgalom- az abszolút érték ezredmásodpercben, amely az eltolás szórását jelzi.

Az NTP-szerver IP-címe előtt egy szimbólum található – ez az egyezik kód. Faj egyezik kód:

  • " " - érvénytelennek nyilvánították. Például nincs vele kapcsolat, vagy offline állapotban van, túl magas rangú, és nem olyan embereket szolgál ki, mint te.
  • "x"- a metszéspont algoritmusa elutasította. A metszésponti algoritmus elkészíti a jelölt partnerek listáját, amelyek szinkronizálási forrásokká válhatnak, és mindegyikhez kiszámítja a konfidencia intervallumot.
  • "." - az asztal túlcsordulása miatt eldobva.
  • "-" - a klaszteralgoritmus elvetette. A klaszterező algoritmus rétegek és szinkronizációs távolság kódok szerint rendezi a jelöltek listáját.
  • "+" - a szervert a „kombinációs algoritmus” kapcsolja be. Ez a szerver kiváló jelölt, ha az aktuális időszerver hibázni kezd.
  • "#" - a szerver kiváló alternatív időszerver. A # jelű szerver csak akkor látható, ha 10-nél több szerverbejegyzése van az /etc/ntp.conf fájlban
  • "*" - aktuális idő szerver. Leolvasásait az óra szinkronizálására használják.
  • "o"- Pulse per second (PPS) szerver. Ez általában azt jelenti, hogy a kérdéses időszerver időforrásokat használ, például GPS műholdakat és más pontos időjeleket. Ha lehúzzák O, akkor a többi típusú mérőkód többé nem jelenik meg.

A mezőn refid a következő értékekkel rendelkezhet:

  • IP-cím - a távoli időszerver címe.
  • .ACST.- NTP manycast szerver.
  • .ACTS. – Automatizált számítógépes időszolgáltatás az Amerikai Nemzeti Szabványügyi és Technológiai Intézettől.
  • .AUTH - hitelesítési hiba.
  • .AUTO - hiba az Autokey sorozatokban.
  • .BCST.- NTP broadcast szerver.
  • .CHU.- Rövidhullámú rádióvevő a CHU állomásról Ottawában, Ontario, Kanada.
  • .CRYPT - Autokey protokoll hiba.
  • .DCFx.- LF rádióvevő a DCF77 állomásról Mainflingenben, Németországban.
  • .DENY.- Hozzáférés megtagadva.
  • .GAL.- Európai Galileo műholdvevő.
  • .GOES.- Amerikai geostacionárius működési környezeti műholdvevő.
  • .GPS.- Amerikai Global Positioning System vevő.
  • .HBG.- LF rádióvevő a svájci Prangins-i HBG állomásról.
  • .INIT.- A társtársítás inicializálva.
  • .IRIG.- Inter Range Instrumentation Group időkód.
  • .JJY.- LF rádióvevő a JJY állomásról a Mount Otakadoya-ban, Fukushima vagy a Hagane-hegy közelében a Kyushu-szigeten, Japánban.
  • .LFx.- Szokásos LF rádióvevő.
  • .LOCL – helyi gazdagép óra.
  • .LORC.- LF rádióvevő a nagy hatótávolságú navigációtól (LORAN-C).
  • .MCST.- NTP multicast szerver.
  • .MSF.- Anthorn rádióállomás Anthorn közelében, Cumbria.
  • .NIST.- Amerikai Nemzeti Szabványügyi és Technológiai Intézet.
  • .PPS.- Impulzus másodpercenként.
  • .PTB.- Physikalisch-Technische Bundesanstalt Brunswickből és Berlinből, Németországból.
  • .RATE – NTP lekérdezési küszöb túllépve.
  • .STEP - módosítsa az NTP lépést. Elfogultság beszámítás kevesebb, mint 1000 ezredmásodperc, de több mint 125 ezredmásodperc.
  • .TDF.- LF rádióvevő a TéléDiffusion de France állomásról Allouis-ban, Franciaországban.
  • .TIME.- NTP társítási időtúllépés.
  • .USNO.- Egyesült Államok Haditengerészeti Obszervatóriuma.
  • .WWV.- HF rádióvevő a WWV állomástól Fort Collinsban, Colorado államban, Egyesült Államokban.
  • .WWVB.- LF rádióvevő a WWVB állomásról Fort Collinsban, Colorado, Egyesült Államok.
  • .WWVH.- HF rádióvevő a WWVH állomásról Kekaha-ban, Kauai szigetén Hawaii-on, Egyesült Államokban.

Először is szabadulj meg attól a gondolattól, hogy hogyan húzz időt réteg 1, azt mondják, ők vannak a legközelebb a pontos időhöz. Közelebb vannak a bolygó legpontosabb időpontjához, de maguk túlterheltek, és nagy az RTT-késésük a normál szervereknél. Inkább keress egy normálisat réteg 2és ne törődj vele. Ne felejtsük el, hogy mikroszekundumokról és ezredmásodpercekről beszélünk, ami a hétköznapi életben elég.

Másodszor, ne feledje, hogy a legközelebbi időszerverhez való csatlakozás nem mindig ideális. Nem a területi közelség a fontosabb, hanem a rétegszint. Az NTP Pool projekt közzéteszi a csak szintű kiszolgálók listáját réteg 1És réteg 2és jobb, ha akár 10 időszervert is elvisz innen ezt a listát ami egyszerűen csodálatos lesz.

Harmadszor, ha Ön egyszerű otthoni felhasználó-kliens, akkor az operációs rendszerében az Ön számára ajánlott szerverek ideális választási lehetőséget jelentenek, amelyek nem igényelnek felesleges mozdulatokat.

Nagy irodák számára a legjobb megoldás az lenne, ha saját időszervert állítanának be a munkahelyi számítógépekhez. Ez a szerver fog kapni pontos időt időkiszolgálókról az interneten, és biztosítsa azt a helyi számítógépeknek. Debian és Ubuntu szervereken egyszerűen törölje a megjegyzést

192.168.0.0 maszk korlátozása 255.255.0.0 nomodify notrap

az ntpd démon konfigurációs fájljában - /etc/ntp.conf

A 192.168/16-os hálózat felhasználói pontosan leolvashatják az órát a szerverről. Belső Linux alapú szervereknél, amelyek nem időszerverek és saját feladataikkal foglalkoznak, ahelyett, hogy kliens módban futtatnák az ntpd démont, elég az /etc/cron.daily/syncntpd fájlban megadni. Javasoljuk, hogy olvassa el az ntpdate és az ntp közötti különbségeket, és döntse el maga.
#!/bin/sh
/usr/sbin/ntpdate A.szerver IP.címe > /dev/null 2>&1
kilépés 0

és az ntpdate parancsnak köszönhetően naponta egyszer megtörténik az időszinkronizálás. A félreértések elkerülése érdekében ne legyen lusta az időkiszolgáló megvalósítása és az NTP protokollon keresztüli szinkronizálás előtt – állítsa be manuálisan a megfelelő időt az összes elérhető szerveren és munkaállomáson. Ha a nem szinkronizált idő túlságosan eltér a helyestől, akkor az elején sok szükségtelen problémához vezethet.

Negyedszer, az NTP-nek semmi köze ahhoz, hogy melyik országot és mely időzónákat használják, hogyan történik a nyári és téli időszámításra való áttérés, és hogy egy adott országban történik-e ilyen átállás. Ez a felelősség az operációs rendszert terheli, amelyet frissítenie kell, ha változás történik az országban az óragyártásban. Debian és Ubuntu rendszereken a tzdata csomag felelős ezért, és naprakésznek kell lennie.

Ötödször, jobb, ha nem futtatja az NTP-kiszolgálót erősen terhelt rendszeren.

A Network Time Protocol egy hálózati protokoll a számítógép belső órájának szinkronizálására változó késleltetésű hálózatok használatával, csomagváltáson alapulóan.

Bár az NTP hagyományosan UDP-t használ működéséhez, képes TCP-n keresztül is futni. Az NTP rendszer rendkívül ellenálló az adathordozó késleltetésének változásaival szemben.

Az időt az NTP rendszerben 64 bites számként ábrázolják, amely egy 32 bites másodpercszámlálóból és egy 32 bites tört másodpercszámlálóból áll, és lehetővé teszi az idő átvitelét 2-32 másodperces tartományban, elméleti pontossággal 2-32 másodperc. Mivel az NTP-ben az időskála 232 másodpercenként ismétlődik (136 év), a címzettnek legalább megközelítőleg ismernie kell az aktuális időt (68 éves pontossággal). Vegye figyelembe azt is, hogy az időt 1900. január 1-jén éjféltől mérik, nem pedig 1970-ben, ezért csaknem 70 évet (beleértve a szökőéveket is) le kell vonni az NTP-időből, hogy helyesen illessze az időt a Windows vagy Unix rendszerekkel.

Ez hogy működik

Az NTP szerverek hierarchikus hálózatban működnek, a hierarchia minden szintjét rétegnek nevezzük. A 0. szintet a referencia órajel képviseli. A szabvány a GPS (Global Positioning System) jelből vagy az ACTS (Automated Computer Time Service) szolgáltatásból származik. A nulladik szinten az NTP-kiszolgálók nem működnek.

Az 1. szintű NTP-kiszolgálók egy referencia órától szerzik be az időinformációkat. A 2. szintű NTP-kiszolgálók szinkronizálva vannak az 1. szintű szerverekkel. Összesen legfeljebb 15 szint lehet.

Az NTP-szerverek és az NTP-kliensek az 1-es szintű szerverektől kapják az időadatokat, bár a gyakorlatban az NTP-kliensek ezt nem teszik meg, mert a több ezer egyedi kliens kérés túl nagy terhet jelentene az 1-es szintű szerverek számára ügyfelei időinformációk megszerzésére fogják használni.

Az NTP protokoll hierarchikus felépítése hibatűrő és redundáns. Nézzünk egy példát a munkásságára. Két Tier 2 NTP szerver hat különböző Tier 1 szerverrel szinkronizál, mindegyik független csatornán. A belső csomópontok szinkronizálva vannak a belső NTP-kiszolgálókkal. Két Tier 2 NTP szerver koordinálja egymással az időt. Ha az 1. szintű kiszolgálóhoz vagy a 2. szintű kiszolgálók egyikéhez fűződő kapcsolat meghiúsul, a redundáns 2. szintű kiszolgáló veszi át a szinkronizálási folyamatot.

Hasonlóképpen, a 3. szintű csomópontok és eszközök bármelyik 2. szintű kiszolgálót használhatják, ami még fontosabb, hogy az NTP-kiszolgálók redundáns hálózata biztosítja, hogy az időkiszolgálók mindig elérhetők legyenek. A több időszerverrel való szinkronizálás révén az NTP minden forrásból származó adatokat felhasznál a legpontosabb idő kiszámításához.

Érdemes megjegyezni, hogy az NTP protokoll tiszta formájában nem állítja be az időt. Időeltolás segítségével állítja be a helyi órát, az NTP-szerveren lévő idő és a helyi óra közötti különbséget. Az NTP szerverek és kliensek beállítják óráikat, fokozatosan vagy egyszerre szinkronizálva az aktuális időt.

Az NTP az UDP protokollt használja a működéshez. Az NTP rendszer rendkívül ellenálló a média késleltetésének változásaival szemben.

Az NTP a Marzullo algoritmust használja (Keith Marzullo, a Kaliforniai Egyetem munkatársa, San Diego), beleértve az átviteli időzítési funkciót. A 4-es verzióban 10 ms (1/100 s) pontosság elérésére képes az interneten keresztül történő munkavégzés során, és akár 0,2 ms (1/5000 s) pontosság elérésére is képes belsőleg helyi hálózatok.

Az NTP az egyik legrégebbi használt protokoll. Az NTP-t David L. Mills, a Delaware Egyetem munkatársa fejlesztette ki 1985-ben, és jelenleg fejlesztés alatt áll. A jelenlegi verzió az NTP 4.

Az NTP az "óraszintek" (rétegek) hierarchikus rendszerét használja. Az 1. szint szinkronizálva van egy nagy pontosságú órával, például egy GPS-rendszerrel, a GLONASS-szal (az Orosz Föderáció egységes állami időskálájával) vagy egy atomi időszabvánnyal. A 2. szint szinkronizálódik az 1. szintű gépek egyikével, és így tovább.

Az időt az NTP rendszerben 64 bites számként (8 bájt) ábrázolják, amely egy 32 bites másodpercszámlálóból és egy 32 bites tört másodpercszámlálóból áll, lehetővé téve az idő átvitelét 2-32 másodperc tartományban. 2-32 másodperces elméleti pontosság. Mivel az NTP-ben az időskála 232 másodpercenként ismétlődik (136 év), a címzettnek legalább megközelítőleg ismernie kell az aktuális időt (50 éves pontossággal). Azt is vegye figyelembe, hogy az időt 1900. január 1-jén éjféltől mérik, nem pedig 1970-ben, ezért csaknem 70 évet (beleértve a szökőéveket is) le kell vonni az NTP-időből, hogy helyesen illessze az időt a Windows vagy Unix rendszerekkel.

Legtöbb széles körű alkalmazás Az NTP protokoll megtalálja a pontos időkiszolgálók megvalósítását. A maximális pontosság elérése érdekében a folyamatos működést részesítjük előnyben szoftver NTP rendszer szerviz módban. A családban operációs rendszerek A Microsoft Windows a W32Time szolgáltatás (a w32time.dll modul az svchost.exe fájlban fut), a Linux pedig az Ntpd szolgáltatás.

Ennek az algoritmusnak egy egyszerűbb megvalósítása az SNTP – Simple Network Synchronization Protocol néven ismert. Olyan beágyazott rendszerekben és eszközökben használják, amelyek nem igényelnek nagy pontosságú, valamint egyedi időprogramokban.

A protokoll és a rendszer egészének részletes megvalósítását az alábbiakban ismertetjük:

Az NTP-t nem szabad összetéveszteni az RFC 867 nappali protokollal vagy az RFC 868 időprotokollal (win program FG Time Sync).

Óra rétegek

Az NTP az időforrások hierarchikus, többszintű rendszerét használja. Ennek a hierarchiának minden szintjét rétegnek nevezzük, minden réteghez hozzá van rendelve egy szám, amely 0-val (nullával) kezdődik a tetején. A rétegszint határozza meg a referenciaórától való távolságot, és azért létezik, hogy megakadályozza a ciklikus függőségeket a hierarchiában. Fontos megjegyezni, hogy a réteg nem a minőség és a megbízhatóság mutatója, hanem azt jelenti, hogy a forrás 3. réteg több jelet adhat kiváló minőségű mint egyes források rétegek 2. Alapvetően a rétegek a terhelés elosztását és nagyobb lefedettségi területet biztosítanak. A rétegnek ez a meghatározása is eltér a távközlési rendszerekben használt órarétegek fogalmától.

0. réteg

A Layer 0 egy nagy pontosságú eszköz, amely időszabványként szolgál, például atom (molekuláris, kvantum) órák, rádióórák vagy analógjaik. Ezek az eszközök általában nem csatlakoznak hálózathoz; ehelyett hozzá vannak kötve helyi számítógép(például RS-232 interfészen keresztül), és szinkronizálás céljából PPS jeleket továbbít.

1. réteg

Ez egy számítógép, amelyhez a referencia óra közvetlenül csatlakozik. Úgy viselkedik, mint hálózati szerver időt, és válaszol a 2. rétegű számítógépek által küldött NTP-kérésekre.

2. réteg

Ezek olyan számítógépek, amelyek az első réteg szervereitől kapnak időt az NTP protokoll használatával. A második réteg számítógépei jellemzően az első réteg több szerverével lépnek kapcsolatba, és az NTP-algoritmus használatával a legjobb adatmintát kapják, kiküszöbölve a nyilvánvalóan helytelen időkkel rendelkező szervereket. A számítógépek összehasonlíthatják adataikat a rétegükben lévő más számítógépekkel, hogy stabil és konzisztens adatokat kapjanak a réteg összes számítógépéről. A második réteg számítógépei viszont a harmadik rétegben lévő számítógépek szervereiként működnek, és válaszolnak az NTP-kérésekre.

3. réteg

A harmadik réteg számítógépei pontosan ugyanúgy működnek, mint a második réteg számítógépei, azzal a különbséggel, hogy a számukra szolgáló szerverek a rájuk eső második réteg számítógépei. Az alatta lévő réteg szervereiként is működhetnek. Az NTP (verziótól függően) legfeljebb 256 réteget támogat.

Lásd még

Linkek

  • - az Orosz Föderáció Állami Idő- és Frekvencia Szabványa (STSE) NTP-kiszolgálóinak listája
  • Network Time Protocol projekt – nyilvános projekt az NTP protokoll és szolgáltatások fejlesztésére
  • NTP Public Services Project - nyilvános NTP szerverek projektje és munkacsoport IETF NTP-n keresztül
  • A pool.ntp.org egy olyan erőforrás, amely NTP-kiszolgálók nagy virtuális fürtjét képviseli több millió felhasználó számára. 2010. december 29-én 2078 szerver van regisztrálva a pool.ntp.org oldalon. Lehetőség van regionális szerverek kiválasztására.
  • ntp.mobatime.ru - 2005 óta az első réteg Mobatime nyilvános ingyenes NTP-kiszolgálója (Oroszország, Szentpétervár).
  • time.bakulev.ru - az első réteg nyilvános ingyenes NTP-kiszolgálója (Oroszország, Moszkva).

Wikimédia Alapítvány.

Nézze meg, mi az "NTP" más szótárakban:

    NTP- egy hárombetűs inicializmus, amely a következőket jelentheti: Tartalom 1 Számítástechnika 2 Politika 3 Tudomány 3.1 Kémia 3.2 Orvostudomány … Wikipédia

    NTP-rövidítés. normál hőmérséklet és légnyomás: az STP korábbi kifejezése * * * NTP röv. normál hőmérséklet és nyomás. * * * …Universalium

    NTP- NTP, Abk. für Network Time Protocol…Universal-Lexikon

    NTP- (Network Time Protocol) (Internet) protokoll, amely ütemezi a számítógép belső óráját az atomórákkal vagy rádióórákkal az interneten... Angol kortárs szótár

    NTP-rövidítés. normál hőmérséklet és légnyomás: az STP korábbi kifejezése … Angol Világszótár

    NTP- Cette page d'homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français

    NTP

    Ntp- Die Abkürzung NTP steht für: Network Time Protocol, ein Protokoll zur Zeitsynchronization zwischen Computern Normal Temperature and Pressure, die englische Bezeichnung für die physikalischen Normalbedingungen Nukleosidtriphosphat in der… … Deutsch Wikipedia

    NTP- A nukleozid 5′-trifoszfát rövidítése. * * * kábítószer-kezelési program; Országos Toxikológiai Program; nitroprusszid; nem trombopéniás purpura; normál hőmérséklet és nyomás; 5' nukleotidáz; sodium nitroprusside * * * NTP rövidítés normál… … Orvosi szótár

A pontos idő megállapításának feladatával már egy ideje nem csak az emberek szembesülnek. Számos általa létrehozott rendszer számára a megfelelő működéshez folyamatosan rendelkezésre kell állnia nagyon pontos óráknak, amelyek pontossága lényegesen nagyobb kell legyen, mint a mindennapi életben használt óráké. Az óra tényleges pontossága mellett nem kevésbé fontos az univerzális időskálával való szinkronizálása. Hiszen még mérlegen is UTC(A koordinált egyetemes idő a polgári idő alapja) időszakonként egy további másodperc formájában változások történnek az atomi idővel való eltérések miatt (például abban az időben, amikor bolygónkat az első dinoszauruszok lakták, a nap hossza körülbelül 22 óra volt).

Az aktuális idő kiszámításához nagyon pontos és megbízható módszereket alkalmazó rendszerek szembetűnő példáiként egyáltalán nem szükséges elképzelni az űrjárművek vagy a légiforgalmi irányító szolgálatok mozgását irányító komplexumokat - bár természetesen a pontosság követelményei az összes elem óráinak hasonló rendszerek legmagasabb szinten vannak. Az univerzális idővel szinkronizált stabil órákra is szükség van a jobban teljesítő rendszerekben egyszerű feladatokat. Ide tartoznak például a valós időben adatokat feldolgozó tudományos és ipari komplexumok különféle eszközök. Adjon hozzá mindent, ami a pénzügyekkel kapcsolatos - banki tranzakciók, szolgáltatói számlázási rendszerek sejtes kommunikációés az általuk kiszolgált forgalomért felszámító internetszolgáltatók. Mindezek példák olyan rendszerekre, amelyek megvalósítása lehetetlen az egyetemes idővel szinkronizált és konzisztens órák használata nélkül. IN számítógépes hálózatok A kliens hitelesítési protokoll a szerver idejét az ügyfelek órájával is összehasonlítja.

A kommunikáció fejlődése korunkban nagyban leegyszerűsítette a pontos idő megszerzésének feladatát. Ma már több tucat globális helymeghatározó rendszer műholdja van „fejünk fölött” (pontosabban Föld körüli pályán), amelyek fedélzeti órái gyakorlatilag időszabványok. Az általuk küldött jelek segítségével nagyon pontosan szinkronizálhatók az órák. Számítógépes hálózatokban a szinkronizálást általában pontos időszerverekkel végzik a protokoll segítségével NTP(Network Time Protocol) vagy annak „könnyű” változata - SNTP(Simple Network Time Protocol) olyan esetekben, amikor a teljes NTP használatának maximális funkcionalitása nem szükséges.

Az NTP protokoll hierarchikus szintrendszert vagy réteget használ. Az NTP szerver rendelkezik a legtöbbvel magas szintű (réteg 1), ha közvetlenül egy időforrásból kap adatokat. Az órájukat az 1. réteg szerverével szinkronizáló szerverek ennél a modellnél alacsonyabb szinten helyezkednek el (2. réteg stb.). Az NTP protokoll az SNTP-vel ellentétben nagyobb szinkronizálási pontosságot biztosít komplex algoritmusok segítségével a csomagküldés idejének kiszámítására. a hálózaton, és képes hibaellenőrzést végezni és UDP-csomagokat szűrni.

Általánosságban elmondható, hogy az SNTP protokoll meglehetősen egyszerűen működik, és általában három szakaszból áll:

  • A kliens, amelynek meg kell kapnia az időt, egy SNTP-kérést tartalmazó UDP-csomagot küld az NTP-kiszolgáló általánosan elfogadott 123-as portjára, és módba lép, hogy válaszra várjon. Ebben a kérésben saját óráját időbélyegzi.
  • Amikor egy kérés érkezik, a szerver egy SNTP-üzenetet tartalmazó UDP-csomaggal válaszol, és elküldi azt a kliensnek a 123-as portról. A csomag rögzíti a kliens fogadott időbélyegét és magának a szervernek az időbélyegét.
  • Amikor egy ügyfél választ kap, a kérés elküldésekor létrehozott időbélyeg segítségével megerősítheti a válasz helyességét, és megpróbálja meggyőződni arról, hogy azt kifejezetten az adott ügyfél kérésére küldték el (ha a csomagot egy másik kérésére küldték el forrásból, valószínű, hogy ugyanazt a létrehozási időbélyeget tartalmazza, rendkívül alacsony). Ezután kivonja az átviteli időbélyeg értékét, átalakítva azt a hálózaton áthaladó csomag által okozott becsült késleltetés szerint, és az eredmény alapján beállítja a rendszer órájának idejét.

Mindkét protokoll csomagformátuma megegyezik, ami lehetővé teszi, hogy az NTP-kiszolgáló NTP- és SNTP-kliensekkel is működjön.

NTP keretszerkezet

Az NTP-szerverek általában csak egy porttal rendelkeznek kifelé - az UDP 123. Ebben a konfigurációban a rendszergazdának nem kell sokat aggódnia a szerver biztonsága miatt, mivel gyakorlatilag sebezhetetlen a rosszindulatú programok támadásaival szemben. Ennek ellenére nagyon fontos, hogy az 1. Stratum szerver elérhetőségét biztosítsuk a kliensek számára, mert különben a működésének lényege elvész. A fő probléma az NTP-kiszolgáló által kiszolgálni tudó kérések száma. Maguk a kérések azonban nagyon érdekes okokból generálhatók.

Az NTP vandalizmus leghíresebb esetei

2003. május közepén a University of Madison alkalmazottai gyorsan növekvő internetes forgalmat fedeztek fel, amelyet az egyetem nyilvános NTP-szervereire irányítottak. A forgalom NTP protokoll kérésekből állt, amelyek a 123-as UDP portra továbbított 76 bájtos csomagokból álltak. Ezeknek a csomagoknak azonban volt egy szokatlan tulajdonságuk: annak ellenére, hogy különböző forrásokból érkeztek, mindegyik a 23457-es portról érkezett.

A szerverek védelme érdekében az útválasztók konfigurációja megváltozott, és az NTP-szerverekre érkező kéréseknek csak ezt a részét blokkolták, továbbra is a normál kiszolgálásban. Csak az összes UDP-forgalom, amely a 23457-es portról a 123-as portra küldött kéréseket tartalmaz az NTP-kiszolgálóhoz, abban a pillanatban a személyzet egyszerűen azt hitte, hogy elosztott szolgáltatásmegtagadási támadással kell szembenézniük (. DDoS támadás, angolból Elosztott szolgáltatásmegtagadás, szolgáltatásmegtagadás), sok véletlenszerű címről szervezve, és ott megállt, feltételezve, hogy az árvíz néhány órán belül alábbhagy, mint általában az alacsony szakmai szintű támadásoknál.

Egy hónappal később kiderült, hogy a bejövő NTP-forgalom áramlása jelentősen megnőtt, és óriási értékeket ért el - 250 ezer csomag másodpercenként, 150 Mbit/s-ot meghaladó mennyiséggel. Óvatosan feloldva egyes interfészek hozzáférését, a személyzet megvizsgálta az UDP-csomagokat, beleértve azok tartalmát is. Megnézték helyes lekérdezések SNTP 1-es verziójú formátum, bár ezek nagy intenzitása az egyes gazdagépektől nem volt egyértelmű. Például egy követési periódus során sok ügyfél körülbelül egy kérést tett másodpercenként. Ez rendkívül furcsa lenne egy normálisan működő SNTP-kliens számára. Az SNTP-t használó alkalmazások egyszerűen beállítják a saját rendszerórájukat a kívánt pontosságra, hogy a gazdagépnek ésszerű elképzelése legyen az aktuális időről.

Az idő másodpercenkénti lekérdezése egyszerűen nevetséges, és meglehetősen távol áll a normál NTP-kliens viselkedéstől. Ha egy véletlenszerű járókelő megkérdezi az időt az utcán, az normális. De mi van akkor, ha minden alkalommal, amikor Ön válaszol, elkezd kérdezni az időpontról, és még néhány ember csatlakozik hozzá? Mi van, ha ez hetekig megy? Világossá vált, hogy meg kell érteni a történtek okait.

Az egyetemi épületegyüttes helyi hálózatán egyik kérési forrás sem található. Ez azt jelentette, hogy a távoli kiszolgáló rendszergazdáinak segítségére lesz szükség az incidens okainak kivizsgálásához. A legaktívabb IP-címek közül két, más egyetemek hálózatán található klienst választottak ki. Levelet küldtek a hálózati rendszergazdáknak, amelyben leírják a problémát, és arra kérték őket, hogy derítsék ki, milyen operációs rendszer és SNTP-kliensek futhatnak ezeken a gazdagépeken, és milyen szolgáltatások küldhetnek kéréseket tőlük a 23457-es UDP-porton keresztül.

A kapott válaszok olyan információkat tartalmaztak, amelyek szerint a forgalom forrása az éles útválasztók Netgear(Egyet különösen MR814-es modellként azonosítottak). Az események most kezdtek némi értelmet nyerni. Az azonos portot használó gazdagépek nagy száma a beépített SNTP-kliens programozott portszámmal magyarázható. A Madison Egyetem alkalmazottai információkat gyűjtöttek azokról a Netgear termékekről, amelyek állításuk szerint támogatják az NTP-t. A kód vizsgálata után kiderült, hogy a gyártó egyszerűen csak az NTP-szerverekre vonatkozó információkat programozott be néhányba. A helyi hálózatok számára fenntartott tartományokból származó IP-címek mellett globális útválasztási IP-címeket is tartalmaztak, beleértve a Madison Egyetem nyilvános NTP-szerverét. A problémát súlyosbította, hogy a kódban megadott globális IP címek közül csak az egyetemi bizonyult valódi NTP szervernek, a router beépített kliense pedig nem kapott választ az SNTP kérésre. , minden másodpercben új kéréseket kezdett generálni.

Miután végre azonosították az NTP-áradás okait, az egyetem munkatársai a router gyártójához fordultak. A Netgearnek be kellett ismernie a hibáját. Kiderült, hogy addigra már több mint hétszázezer ilyen készüléket adtak el. Néhány egyszerű számítás azt mutatja, hogy potenciálisan képesek voltak 426 Mb/s-os forgalmat generálni (másodpercenként 700 000 UDP-csomag, egyenként 76 bájt hosszúak), amely ugyanarra az NTP-kiszolgálóra irányul.

A probléma megoldására egy csoportot hoztak létre az egyetem képviselőinek, a gyártó és független szakértők részvételével. Gyorsan megjelentek a szoftver javított verziói a kódhibákat tartalmazó eszközökre. Ez persze nem oldott meg minden problémát – elvégre a kiadás új verzió A gyártó firmware-je nem jelenti azt, hogy minden felhasználó lecseréli, akiknek többsége nem volt tudatában az ilyen problémáknak. Az egyetem azonban úgy döntött, hogy folytatja a hibás Netgear-eszközök szervizelését, lehetővé téve számukra a rendszerórák szinkronizálását (ez a döntés a Madisoni Egyetemnek fizetett 375 000 dolláros Netgear-hez kapcsolódik, amely állítólag a „biztonság javítása” volt? vezeték nélküli hálózatés az egyetemi épületegyüttes hálózatának fejlesztése” – a szerző nem tudja biztosan).

Ugyanebben az évben hasonló eset történt Ausztráliában. A résztvevők ezúttal az Ausztrál Nemzetközösségi Tudományos és Kutatási Szervezet Nemzeti Mérésügyi Laboratóriuma voltak. CSIRO) és a kaliforniai székhelyű hálózati berendezések gyártója SMC hálózatok. A CSIRO NTP szerverek maximális terhelése (1. réteg, forrás - céziumórák, más néven " atom") 200 kBit/s-ra becsülték. A forgalom blokkolása, amelynek nagy része a tengerentúlról érkezett, oda vezetett, hogy az SMC-eszközök az NTP-szerver válaszának hiányában percenként kétszer küldtek kéréseket. A CSIRO végül úgy döntött, hogy megváltoztatja időszervereinek címét (miután értesítette erről partnereit), és a szolgáltatók egyszerűen blokkolni kezdték az Ausztrálián kívüli forrásokból érkező kéréseket.

Az utolsó a legtöbb ismert probléma az ilyesmi 2005-ben történt, és először „ NTP vandalizmus", amely később az NTP-szerverekkel való visszaélés eseteinek általános kifejezésévé vált. Ezután a „fekete jel” az 1. réteg dán szerverére került, amely a Danish Internet Exchange (DIX) országos hálózatához csatlakozott. A szerver az egyik FreeBSD fejlesztőé volt - Félig Hoening Kamp(Poul-Henning Kamp), és bár nem állami vagy tudományos intézmények tulajdonában volt, non-profit alapon létezett. A használati szabályok egyenesen kimondták, hogy időszinkronizálásra csak a második réteg Dániában található NTP-szerverei és olyan alkalmazások használhatják, amelyek működése rendkívül pontos időt igényel.

A konszern vandálként lépett fel D-Link. Az NTP-szerver tulajdonosa becslése szerint a kérések 75-90%-át a D-Link által gyártott routerek generálták. Amikor az ilyen csomagok száma meghaladta a napi hárommilliót, a szolgáltató évi 54 000 DKK (körülbelül 8 800 USD) összegben követelte a Kampától a jelentős forgalomnövekedés okozta költségek megfizetését.

Akárcsak a Madisoni Egyetem esetében, Kamp felvette a kapcsolatot a D-Link-kel, abban a reményben, hogy megoldja a problémát és megtéríti az általa okozott pénzügyi költségeket. A Netgearrel ellentétben a D-Link tagadni kezdte a probléma létezését, válaszul Kamp zsarolással vádolta. A konfrontáció csaknem hat hónapig tartott, amíg Kamp az incidens minden részletét széles körben nyilvánosságra hozta. Végül 2006 áprilisában a felek békemegállapodást kötöttek. Elhangzott, hogy a meglévő D-Link termékek engedélyezett hozzáférést kapnak a Kampa NTP szerverhez, a későbbiek pedig leállítják a használatát (a megállapodás pénzügyi oldala nem ismert, de egyes becslések szerint a tartalom saját szerverek az ilyen forgalom kiszolgálására képes idő körülbelül havi 1000 dollárba kerülne a D-Linknek).

Műszaki megoldások

Mindezek az esetek arra kényszerítették a hálózati protokoll-fejlesztőket, hogy elgondolkodjanak azon, hogy a különböző hozzáférési szabályzatok alkalmazása mellett milyen módokon lehet elkerülni a hasonló problémákat a jövőben. Az egyik megoldás az NTP protokoll negyedik, 2006 elején megjelent és RFC 4330-ban leírt változatának módosítása volt. Ezek között szerepel az NTP csomagmezők szemantikájának kiterjesztése, hogy a szerver speciális vezérlőcsomagot küldhessen a romantikus név" halál csókja"(Kiss-o"-Death, KoD) Egy ilyen csomagban a fejlécek speciális módon vannak kitöltve - az ugrás második mezője a 3-as értéket tartalmazza, a kiszolgáló réteget jelző mező 0-ra, és a hivatkozás azonosítója. 4 bájtos kódot tartalmaz, amely jelzi a csomagok okát (a gyakorlatban eddig csak a RATE kódot használjuk - a kérések gyakoriságát meghaladóan).

Egy ilyen csomag kliensnek történő elküldése azt jelenti, hogy a szerver észlelte, hogy a kliens megsértette a hozzáférési szabályokat, és a kliens szolgáltatása megszűnik. A kliensnek, miután megkapta, le kell állítania a kérések küldését, és szükség esetén meg kell próbálnia másik NTP-kiszolgálót keresni. Ha az ügyfél nem talál másik elérhető NTP-kiszolgálót, csökkentenie kell az előző kiszolgálóhoz intézett kérések arányát az exponenciális lecsengési algoritmus szerint.

A dokumentum ismerteti az ajánlott alapelveket is, amelyek szerint a „helyes” NTP kliensnek olyan időintervallumokat kell kialakítania, amelyek meghatározzák a szerver felé irányuló kérések gyakoriságát, és a hálózati infrastruktúra elemeit (ideértve a DNS-t és a DHCP-t is) használja. Ha az NTP-kiszolgálók közvetlen címét tervezi megadni az eszköz beépített kódjában, sürgősen Ezt csak a tulajdonosaikkal történt egyeztetés után javasolt megtenni.

Elvileg az ilyen újítások meglehetősen ésszerűek, de kézzelfogható hasznuk csak akkor lesz lehetséges túlnyomó a globális hálózatban található NTP szerverek és kliensek száma teljes mértékben megfelel az NTP protokoll negyedik verziójának követelményeinek. Sajnos nincs remény arra, hogy a közeljövőben ilyen módon alakuljanak az események (egyébként az egyik „nyom”, aminek köszönhetően Kamp arra jutott, hogy a támadások forrása a D-Link által gyártott routerek mindegyikük az SNTP protokoll 1-es verzióját használja).

Technikai megoldásként, amellyel jelentősen csökkenthető az időszerverek csúcsterhelése, megjegyezhetjük a pool.ntp.org projektet. Ez egy földrajzilag elosztott NTP-kiszolgálók nagy virtuális fürtje (a cikk írásakor 1742 szervert tartalmaz minden kontinensről). Maga a projekt 2003-ban indult, annak a vitának a gyümölcse, amely arról szólt, hogy jelentős költségekkel kell számolni a jelentős számú kérést folyamatosan kiszolgálni képes, megbízható időszerverek fenntartása és üzemeltetése miatt. A mögöttes ötlet nagyon hasonló a rekurzív működési mechanizmushoz DNS szerverek. Ha egy szerver, mint például a 0.pool.ntp.org, egyszerűen megadva a pontos időt biztosító szerverként, akkor a rendszer minden klienskéréssel véletlenszerűen kiválasztja a valódi szervert, amellyel az időszinkronizálás történik. medence. A pool felhasználók azonban önállóan választhatnak regionális pontos időszervereket, megadva a kontinentális zónát, vagy akár egy adott ország zónáját (általában minél közelebb van a szerver, annál pontosabb a szinkronizálás), például - 0.ru. pool.ntp.org Oroszország számára. Nem szabad megfeledkezni arról, hogy néhány ország nem képviselteti magát a készletben, és néhányat egy vagy két szerver képvisel (például Malajzia). A medence használata díjmentes, kivéve a berendezéseket gyártó szerviz- és szoftver termékek, amelynek NTP-kéréseit a pool.ntp.org erőforrások segítségével kívánják kiszolgálni.

Az a gondolat, hogy egy nyilvános szinkronizálási szolgáltatást indítsanak el pontos órával anélkül, hogy biztosítanák annak stabilitását és megbízhatóságát extrém terhelési körülmények között, aligha van értelme. A történelem számos példát tud arra, hogy a bejelentett 1. réteggel rendelkező, megszűnt NTP-kiszolgálók több tíz(!) másodperccel eltérnek a valóditól, vagy egyszerűen elérhetetlenné válnak a kérések számára. Az a szolgáltatás, amely lehetővé teszi az óra pontos időforrással történő szinkronizálását, pontosan az az eset, amikor a megbízhatóság fogalma ugyanolyan fontos, mint a megadott adatok pontossága. Itt egy illusztráció igazi munka Mobatime Systems NTP szerverek:


A Mobatime Systems NTP-szerver kérési statisztikái

Ez az NTP vandalizmus meglehetősen szembetűnő példája – 2009. április 1-jén 75 olyan hostot blokkoltak, amelyek több mint 12 millió kérések naponta. Hasonló intenzitású támadás 3 napig tartott, és természete aligha magyarázható egyszerű eszközkód-hibákkal, vagy azok helytelen konfigurációjával. Az ilyen támadások elleni védelem érdekében a Mobatime NTP szerver bejövő forgalom szűrő algoritmusokat használ. Ez a védelmi mechanizmus lehetővé teszi a „szemét” lavinaszerű áramlásának megszakítását, amely a rendszer rövid időn belüli teljes meghibásodásához vezethet.

Ez a védelem azonban gyakorlatilag használhatatlanná válik, ha az adatmennyiség az átviteli csatornában megközelíti az adatmennyiséget sávszélesség. Ilyen terhelés mellett a kommunikációs csatorna erőforrásainak kimerülése miatt egyszerűen lehetetlenné válik az adatok küldése legitim, blokkolatlan ügyfeleknek. Az egyetlen kiút a helyzetből, amely garantálja az NTP vandalizmusok szinte teljes kiküszöbölését, talán egy nem nyilvános pontos időszerver létrehozása, hozzáférési korlátozásokkal. Megbízható időforrással (például a GPS-rendszer által továbbított adatok vevőjével) rendelkező NTP-szerver a pontos időszolgáltatás stabil szolgáltatója lesz.

A kiadvány elkészítéséhez felhasznált anyagok listája (angol nyelven):

  • RFC 4330, SNTP v4 protokoll leírása
  • Hibás útválasztók elárasztják a Wisconsini Egyetem internetes időkiszolgálóját – a Madisoni Egyetemen történt incidensről szóló jelentés, amelyet Dave Plonka alkalmazottja tett közzé.
  • A hálózati eszközök majdnem letörik az atomórát – cikk az incidensről a CSIRO-ban
  • Amikor firmware támad! (DDoS a D-Linktől) - Richard Clayton cikke, aki részt vett a Paul-Heuning Kamp NTP szervere elleni támadás körülményeinek tisztázásában
  • Anyagok a szervezet pool.ntp.org webhelyéről
  • Segítsen megmenteni a veszélyeztetett időszervereket – Andy Lester cikke a pool.ntp.org oldalon

Nem tudom! Csak azt akarom, hogy az időm a pályán maradjon! Kérem, mondja meg, mit tegyek?


Talán jobb lenne helyesen beállítani az időzónát, és időben megkapni a frissítéseket (beleértve az időre vonatkozókat is)? Nos, cserélje ki az akkumulátort anyunak, ha régi... hátha...
tanulj meg kérdéseket feltenni.
Fel sem merült a kérdés :D

NTP(Network Time Protocol) egy hálózati protokoll a számítógép belső órájának szinkronizálására változó késleltetésű hálózatok használatával. A protokollt David L. Mills, a Delaware Egyetem professzora dolgozta ki 1985-ben. A 2015-ös verzió az NTPv4.

A Marzullo algoritmuson alapuló NTP az UDP protokollt használja a működéséhez, és figyelembe veszi az átviteli időt. Az NTP rendszer rendkívül ellenálló az adathordozó késleltetésének változásaival szemben. A 4-es verzióban 10 ms (1/100 s) pontosság elérésére képes az interneten keresztüli munkavégzés során, illetve 0,2 ms (1/5000 s) és még jobb pontosság elérésére helyi hálózatokon belül.

Az NTP protokollt legszélesebb körben használják időszerverek szinkronizálására. A maximális pontosság elérése érdekében célszerű az NTP szoftvert mindig rendszerszolgáltatási módban futtatni. Az operációs rendszer családban Microsoft Windows a W32Time szolgáltatás, a Linux pedig az Ntpd szolgáltatás.

Ennek az algoritmusnak egy egyszerűbb megvalósítása az SNTP – Simple Network Time Protocol néven ismert. Használható beágyazott rendszerekben és eszközökben, amelyek nem igényelnek nagy pontosságot, valamint egyedi időprogramokban.

A csomag szerkezete

A csomagszerkezetet az RFC 5905 írja le. A csomag 32 bites szavak egész számából áll.

A fejléc információk eltérőek lehetnek a különböző üzemmódokban. Például egy ügyfél a mezőkön óra réteg, forrásazonosító, kezdési időpontÉs időpont egyeztetés nullákat kell írni.

Cím

NTP fejléc
Behúzás Oktett 0 1 2 3
Oktett Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IR Változat Mód Óra réteg Lekérdezési intervallum Pontosság
4 32 Késleltetés
8 64 Diszperzió
12 96 Forrásazonosító
16 128 Frissítés ideje
20 160
24 192 Kezdési idő
28 224
32 256 Időpont egyeztetés
36 288
40 320 Kiszállítási idő
44 352

Korrekciós jelző

Példa időszinkronizálásra NTP használatával

Hossz - 2 bit, az ugrásjelzőből.

A ugrómásodperces figyelmeztetést jelző egész szám.

Verziószám

Mód

Hossz - 3 bit, a verziószámtól.

Óra réteg

A protokoll verzióját reprezentáló egész szám.

Lekérdezési intervallum

Hossz - 3 bit, módból.

Pontosság

A módot jelző egész szám. Az értékeket az alábbi táblázat tartalmazza.

Késleltetés

Hossz - 8 bit, a Stratumtól. Az óra réteget képviselő egész szám. Hossz - 8 bit, szavazásból.

Diszperzió

Előjeles egész szám, amely az egymást követő üzenetek közötti maximális intervallumot jelenti. Az érték megegyezik a másodpercek bináris logaritmusával. A minimális és maximális felmérések alapértelmezett javasolt határértéke 6, illetve 10.

Forrásazonosító

Hossz - 32 bit, a referenciaazonosítóból. Szinkronizálási forráskód. Az Óra réteg mező értékétől függ. Mert réteg 0- Ez a négy ASCII karakter, úgynevezett "kiss code", hibakeresésre és figyelésre használható. Lásd alább
1. réteg négy oktett ASCII-karakter, bal oldalon nullákkal kitömve, az időreferenciához hozzárendelve. Az alábbi táblázat az IANA által vezetett listát mutatja.
ID Forrás
MEGY Geostacionárius műhold környezeti megfigyelő és felügyeleti rendszerhez
GPS Globális helymeghatározó rendszer
GAL Galileo helymeghatározó rendszer
P.P.S. Általános rádiójel, impulzus időtartama 1 másodperc
IRIG Telemetriai szabványosítási csoport, USA
WWVB Alacsony frekvenciájú rádióadó, 60 kHz, Fort Collins, Colorado, USA
DCF Alacsony frekvenciájú rádióadó, 77,5 kHz, DCF77, Mainflingen, Németország
HBG Alacsony frekvenciájú rádióadó, 75 kHz, Prangins, Svájc
MSF Alacsony frekvenciájú rádióadó, 60 kHz, Anthorn, Egyesült Királyság
JJY Alacsony frekvenciájú rádióadó, 40 kHz, Fukushima, 60 kHz, Saga, Japán
LORC Középfrekvenciás rádióadó, 100 kHz, rádiónavigáció, LORAN-C
TDF Középfrekvenciás rádióadó, 162 kHz, Allouis, Franciaország
CHU Nagyfrekvenciás rádióadó, Ottawa, Ontario, Kanada
WWV Nagyfrekvenciás rádióadó, Fort Collins, Colorado, USA
WWVH
Nagyfrekvenciás rádióadó, Kauai, Hawaii, USA NIST
ACTS NIST telefon modem
USNO US National Observatory telefonos modem
PTB rétegek 2 A Német Nemzeti Metrológiai Intézet telefonmodemje

Frissítés ideje

Mert

Kezdési idő

és fent a szerver azonosítója, és időhurkok rögzítésére használható. IPv4 használata esetén az azonosító az IP-cím négy oktettje. Ha IPv6-ot használunk, akkor ez a cím MD5-kivonatának első négy oktettje. Érdemes megjegyezni, hogy ha IPv6-címeket használ egy NTPv4-es szerverhez és egy NTPv3-as klienshez, az azonosító véletlenszerű értéket vehet fel, ezért előfordulhat, hogy az időhurkok nem rögzíthetők.

Időpont egyeztetés

Hossz - 64 bit, a referencia időbélyegből.

Kiszállítási idő

Az az idő, amikor a rendszer utoljára beállította vagy beállította az időt. NTP formátum.

Hossz - 64 bit, az Origin Timestamp-ből.

Az ügyfél időpontja, amikor a kérést elküldik a szervernek. NTP formátum. Szinkronizálási forráskód. Az Óra réteg mező értékétől függ., amely meghatározatlannak vagy érvénytelennek minősül, mezőben Forrásazonosító rendszerállapot-információként és hozzáférés-vezérlésként szolgáló üzenetek kézbesítésére használható. Az ilyen üzeneteket "Kiss-o"-Death"-nek (KoD), az általuk továbbított ASCII-adatokat pedig "csókkódoknak" nevezik. A jelenleg elfogadott "súgó" kódok listája az alábbi táblázatban látható.

A KoD-üzenetek címzettjei kötelesek ellenőrizni őket, és a következő műveleteket végrehajtani:

  • Kódkombinációk fogadásakor TAGADÁSÉs RSTR a kliens köteles megszakítani a virtuális kapcsolatokat ezzel az időszerverrel, és leállítani az üzenetek küldését erre a szerverre.
  • A kódkombináció kézhezvételekor ARÁNY a kliensnek azonnal csökkentenie kell a lekérdezési időközt ehhez a kiszolgálóhoz, és minden alkalommal csökkentenie kell azt, amikor megkapja ezt a kódkombinációt.
  • ASCII karakterrel kezdődő kódkombináció fogadásakor X, kísérleti kutatásra és későbbi fejlesztésekre szánták, figyelmen kívül kell hagyni, ha nem ismerik fel.
  • Minden más kódkombináció és KoD üzenet, amelyet nem definiál ez a protokoll, az ellenőrzést követően megsemmisül.
Súgó kódok
Kód Leírás
ACST Unicast szerver által létrehozott virtuális kapcsolat
AUTH A szerver hitelesítés sikertelen
AUTO Az automatikus billentyűk sorrendje hibás
BCST A broadcast szerver által létrehozott virtuális kapcsolat
CRYP A kriptográfiai hitelesítés vagy azonosítás nem sikerült
TAGADÁS A távoli szerver megtagadta a hozzáférést
CSEPP Veszteség távoli szerver szimmetrikus módban
RSTR A hozzáférés megtagadva a helyi biztonsági szabályzat miatt
INIT A virtuális kapcsolat nem jött létre először
MCST A dinamikusan felfedezett szerver virtuális szinkronizációs kapcsolatot hozott létre
NKEY A kulcs nem található (vagy még soha nem töltötték be, vagy megbízhatatlan)
ARÁNY Túllépték a sebességet. A szerver ideiglenesen megtagadta a hozzáférést, mert az ügyfél túllépte a sebességküszöböt
RMOT A virtuális kapcsolat módosítása távoli IP-állomásról közvetlenül az NTP-protokoll használatával
LÉPÉS Iteráció történt a rendszeridő módosítására, a virtuális szinkronizálási kapcsolat nem jön létre

Óra rétegek

A sárga nyilak a hardvercsatlakozást jelzik; piros nyilak jelzik a hálózati kapcsolatot.

Az NTP hierarchikus hálózatot használ, ahol minden szintnek megvan a maga száma, úgynevezett réteg. 1. réteg- elsődleges szerverek, amelyek közvetlenül szinkronizálnak a nemzeti időszolgáltatásokkal műholdas, rádiós vagy telefonos modemen keresztül. 2. réteg- másodlagos szerverek, szinkronizálva az elsődleges szerverekkel stb. Az NTP-kliensek és a viszonylag kis számú ügyféllel rendelkező szerverek általában nincsenek szinkronizálva az elsődleges szerverekkel. Több száz nyilvános másodlagos szerver fut magasabb rétegeken. Ők a preferált választás.

Időformátum

Az időt az NTP rendszerben 64 bites számként (8 bájt) ábrázolják, amely egy 32 bites másodpercszámlálóból és egy 32 bites tört másodpercszámlálóból áll, lehetővé téve az idő átvitelét 2-32 másodperc tartományban. 2-32 másodperces elméleti pontosság. Mivel az NTP-ben az időskála 232 másodpercenként ismétlődik (136 év), a címzettnek legalább megközelítőleg ismernie kell az aktuális időt (68 éves pontossággal). Azt is vegye figyelembe, hogy az időt 1900. január 1-jén éjféltől mérik, nem pedig 1970-ben, ezért csaknem 70 évet (beleértve a szökőéveket is) le kell vonni az NTP-időből, hogy helyesen illessze az időt a Windows vagy Unix rendszerekkel.

Normál formátum idő
Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Másodpercek
4 Másodpercek töredéke
Dátum formátum
Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Korszakszám
4 Korszak behúzás
8 Részvények
16


Kapcsolódó kiadványok