Blog-Seite

Jeder Beitrag auf dieser Blogseite soll den Umgang mit dem Network Time Protocol vereinfachen.

alle Artikel
2 min Lesezeit

Schon früh in der Geschichte des Internet kam die Frage auf, wie man zwischen vernetzten Rechnern die Zeit übermitteln könne. Die ersten Ansätze waren simpel: Ein Server kann über Port 13 (RFC867) seine Zeit als ASCII-Klartext zur Verfügung stellen. Alternativ gibt er über Port 37 (RFC868) die Zahl der seit 1.1.1900 Uhr verstrichenen Sekunden als 32-Bit-Binärwert aus. Feiner als eine Sekunde kann man die Zeit mit diesen Services nicht auflösen.

Hinzu kommt, dass einfache Methoden wie Tageszeit und Uhrzeit nur innerhalb eines LAN einigermaßen genau sind, weil IP-Pakete mit einer Verzögerung von wenigen Millisekunden übertragen werden. Beim Zugriff auf das Internet mit seinen unvorhersehbaren Latenzen kann es zu größeren und vor allem zeitlich schwankenden Abweichungen (Jitter) kommen. Erschwerend kommt hinzu, wenn viele Clients häufig auf diese Dienste zugreifen, steigt die Systemlast auf diesen Servern übermäßig an. Schon aus diesem Grund soll die Synchronisation der Zeit über das Internet im geschäftlichen Umfeld nur in Ausnahmefällen genutzt werden.

Zwar läuft der time-Zähler erst anno 2036 über, aber die Genauigkeit hängt, genauso wie bei daytime, hauptsächlich von der internen Uhr des Servers ab. Stellt der Administrator diese nicht regelmäßig nach, kann sie im Laufe der Zeit erheblich abweichen. David L. Mills, Chefentwickler von NTP, fand 1988 heraus, dass damals sechzig Prozent von 1158 überprüften Servern mehr als eine Minute von der wahren Zeit abwichen, zehn Prozent sogar mehr als 13 Minuten.

Die Mängel von daytime und time führten zur Entwicklung des hierarchischen Network Time Protocol (Port 123, RFC1035 und andere). Darüber können Server untereinander eine gemeinsame Zeit ermitteln. Die Paketlaufzeiten im Netz misst und kompensiert NTP dabei weitgehend. Der NTP-Prozess eines Servers arbeitet zugleich selbst als Uhr, er verlässt sich nicht auf die Systemuhr.