Was ist NTP-Zeitsynchronisation und wie hält sie deine Uhren genau?

NTP-Zeitsynchronisationsdiagramm mit vernetzten Zeitservern und Uhren in einem globalen Netzwerk

NTP-Zeitsynchronisation ist der Prozess, durch den Computer, Server und Netzwerkgeräte automatisch genaue Uhren einstellen und beibehalten, indem sie über das Internet oder ein lokales Netzwerk mit dedizierten Zeitservern kommunizieren. Das Network Time Protocol (NTP) erfüllt diese Aufgabe bereits seit 1985 und gehört damit zu den ältesten Internetprotokollen, die noch heute weit verbreitet sind. Ohne NTP würde jedes Gerät in deinem Netzwerk langsam zu seiner eigenen Version von "jetzt" abdriften, was zu Authentifizierungsfehlern, beschädigten Logs und äußerst verwirrenden Debugging-Sitzungen führt.

Was ist NTP und warum gibt es das?

NTP steht für Network Time Protocol. Es wurde von Dr. David L. Mills an der University of Delaware entwickelt und ist in RFC 5905 definiert. Die aktuelle Version ist NTPv4. Seine einzige Aufgabe besteht darin, die Uhren von Netzwerkgeräten auf wenige Millisekunden genau mit der Koordinierten Universalzeit (UTC) zu synchronisieren.

Vor NTP gab es keine standardisierte Möglichkeit für einen Computer, über ein Netzwerk zu fragen: "Wie spät ist es?" Jedes System behielt die Zeit unabhängig mit seiner internen Hardware-Uhr, und diese Uhren drifteten ständig auseinander. Mit dem Wachstum von Netzwerken wurde dies zu einem echten Problem: Verteilte Systeme brauchen alle Teilnehmer, die sich auf die Zeit einigen, sonst funktionieren Dinge wie Dateiordnung, Datenbanktransaktionen und Sicherheits-Token nicht mehr richtig.

Uhrenabweichung: Warum Computer bei der Zeit lügen

Jeder Computer hat eine Hardware-Uhr namens Real-Time Clock (RTC), die von einer kleinen Batterie auf dem Motherboard mit Strom versorgt wird. Sie tickt mit einem Quarzoszillator. Das Problem ist, dass Quarzoszillatoren nicht perfekt genau sind. Je nach Temperatur, Alter und Fertigungsvarianz gewinnen oder verlieren sie einige Millisekunden pro Tag.

Diese kleine Abweichung summiert sich mit der Zeit:

  • Eine Uhr, die 10 ms pro Tag abdriftet, ist nach einem Monat um 300 ms falsch.
  • Nach einem Jahr könnte die Abweichung 3,6 Sekunden oder mehr betragen.
  • In einem Cluster von 50 Servern, die alle unabhängig abdriften, können sich Knoten zu jedem gegebenen Zeitpunkt um mehrere Sekunden unterscheiden.

NTP löst dieses Problem, indem es regelmäßig die Differenz zwischen der lokalen Uhr und einer Referenzzeitquelle misst und dann die Uhr gleitet (die Geschwindigkeit graduell anpasst), um diese Differenz zu schließen, ohne einen plötzlichen Sprung zu verursachen. Ein plötzlicher zeitlicher Rücksprung kann laufende Prozesse verwirren, daher verlangsamt oder beschleunigt NTP die Uhr fast immer sanft, anstatt sie abrupt zurückzusetzen.

Gleiten vs. Springen: NTP gleitet die Uhr (beschleunigt oder verlangsamt sie leicht), wenn die Abweichung unter 128 ms liegt. Wenn die Abweichung größer ist, "springt" sie die Uhr, das heißt, sie setzt die Zeit direkt. Die meisten NTP-daemons weigern sich, eine Uhr, die um mehr als 1000 Sekunden falsch ist, ohne manuelle Intervention zu springen, als Plausibilitätsprüfung.

So synchronisiert NTP eine Uhr wirklich

Das Protokoll funktioniert über einen Request-Response-Austausch über UDP-Port 123. So läuft ein einzelner Synchronisierungszyklus ab:

  1. Dein NTP-Client sendet ein Anforderungspaket an einen Zeitserver. Das Paket enthält einen Zeitstempel des Sendezeitpunkts (T1).
  2. Der Server empfängt das Paket und notiert die Ankunftszeit (T2).
  3. Der Server sendet eine Antwort, die T1, T2 und die Zeit enthält, zu der er die Antwort gesendet hat (T3).
  4. Dein Client notiert, wann die Antwort angekommen ist (T4).

Mit diesen vier Zeitstempeln berechnet NTP zwei Werte:

  • Roundtrip-Verzögerung: (T4 - T1) - (T3 - T2)
  • Uhrenabweichung: ((T2 - T1) + (T3 - T4)) / 2

Die Abweichung sagt dem Client, wie weit seine Uhr von der Serveruhr entfernt ist. NTP passt dann die lokale Uhr um diese Abweichung an und berücksichtigt dabei die Netzwerkverzögerung. Über mehrere Polling-Zyklen (typischerweise alle 64 bis 1024 Sekunden) erstellt NTP ein statistisches Modell der Netzwerkverzögerung und Uhrenabweichung und wird dabei schrittweise genauer.

Stratum-Ebenen erklärt

NTP organisiert Zeitquellen in einer Hierarchie namens Stratum-Ebenen, nummeriert von 0 bis 15. Die Stratum-Nummer sagt dir, wie viele Sprünge ein Gerät von einer primären Referenzuhr entfernt ist.

Stratum Was es ist Typische Genauigkeit
0 Primäres Referenzgerät (GPS-Empfänger, Atomuhr, Funksignal). Nicht direkt im Netzwerk. Nanosekunden
1 Server direkt mit einem Stratum-0-Gerät verbunden. Dies ist die Spitze des NTP-Netzwerks. Mikrosekunden
2 Server, der mit einem Stratum-1-Server synchronisiert. Die meisten öffentlichen NTP-Server sind hier. 1-10 ms
3 Server, der mit einem Stratum-2-Server synchronisiert. Häufig für unternehmenseigene interne NTP-Server. 10-50 ms
4-15 Weitere nachgelagerte Clients und Server. Nimmt mit jedem Sprung ab
16 Nicht synchronisiert. Ein Gerät, das Stratum 16 ankündigt, hat keine gültige Zeitquelle. Unbekannt / unzuverlässig

Eine wichtige Regel: Ein Server kündigt sich immer eine Stratum-Ebene höher an als seine Upstream-Quelle. Wenn dein interner NTP-Server mit einem öffentlichen Stratum-2-Server synchronisiert, wird er zu einem Stratum-3-Server für deine Clients. Dies verhindert Zirkelbezüge und hält die Hierarchie sauber.

Zeitserver: Woher kommt die genaue Zeit?

Die am weitesten verbreitete öffentliche NTP-Infrastruktur ist das NTP Pool Project, ein von Freiwilligen betriebener Pool aus Tausenden von Servern weltweit. Wenn du ein Gerät so konfigurierst, dass es pool.ntp.org verwendet, wird es automatisch zu einem geografisch nahen Server weitergeleitet.

Weitere bekannte öffentliche Zeitserver:

  • time.cloudflare.com (Cloudflare, nutzt GPS + Atomuhren)
  • time.google.com (Google, nutzt GPS-Empfänger in ihren Rechenzentren)
  • time.windows.com (Microsoft, von Windows standardmäßig verwendet)
  • time.apple.com (Apple, von macOS und iOS verwendet)
  • ntp.ubuntu.com (Ubuntu/Canonical)

Für Unternehmensumgebungen wird empfohlen, einen oder zwei interne NTP-Server zu haben, die mit öffentlichen Stratum-1- oder Stratum-2-Quellen synchronisieren, und dann alle internen Geräte mit diesen internen Servern synchronisieren zu lassen. Dies reduziert die Last auf öffentliche Pools und hält alle deine Maschinen auf einer konsistenten internen Referenz.

NTP vs SNTP vs PTP: Was ist der Unterschied?

Du wirst diese drei Begriffe gelegentlich synonym verwendet sehen, aber sie sind nicht dasselbe:

  • NTP (Network Time Protocol): Das vollständige Protokoll. Nutzt einen ausgefeilten Algorithmus mit Filterung, Gewichtung und mehrfachem Server-Polling. Erreicht über das Internet eine Genauigkeit von 1-10 ms.
  • SNTP (Simple NTP): Eine vereinfachte, zustandslose Teilmenge von NTP. Nutzt das gleiche Paketformat, überspringt aber die erweiterten Uhr-Disziplin-Algorithmen. Ausreichend für End-User-Geräte, die nur "ungefähr richtige" Zeit brauchen. Die meisten IoT-Geräte verwenden SNTP.
  • PTP (Precision Time Protocol, IEEE 1588): Entworfen für lokale Netzwerke, in denen Submikrosekunden-Genauigkeit erforderlich ist, wie Finanzhandelssysteme, Industrieautomation und Telekommunikationsnetzwerke. PTP nutzt Hardware-Zeitstempel auf der Netzwerkschnittstelle, was NTP nicht kann.

Für die meisten Entwickler und Systemadministratoren ist NTP die richtige Wahl. PTP ist nur notwendig, wenn du eine höhere Genauigkeit brauchst, als NTP über ein lokales Netzwerk bieten kann.

Praktische Beispiele für Entwickler und Systemadministratoren

NTP-Status unter Linux prüfen

Auf Systemen, die systemd-timesyncd verwenden (Ubuntu 16.04+, Debian 8+):

timedatectl show-timesync --all

Auf Systemen, die den vollständigen ntpd daemon ausführen:

ntpq -p

Die Ausgabe zeigt jeden konfigurierten Server, seine Stratum, die Roundtrip-Verzögerung und die aktuelle Abweichung. Ein Sternchen (*) neben einem Server bedeutet, dass es die aktuell ausgewählte Quelle ist.

NTP-Server unter Linux konfigurieren (chrony)

chrony ist der empfohlene NTP-Client auf modernem RHEL/CentOS/Fedora und ist auch auf Debian/Ubuntu verfügbar. Bearbeite /etc/chrony.conf :

# Use the NTP Pool for your region
pool 2.pool.ntp.org iburst

# Or use a specific provider
server time.cloudflare.com iburst
server time.google.com iburst

# Allow clients on your local network to sync from this machine
allow 192.168.0.0/24

Zeitsynchronisation unter Windows prüfen

w32tm /query /status

Warum das speziell für Entwickler wichtig ist

Wenn du mit Authentifizierungs-Token arbeitest, bist du mit ziemlicher Sicherheit schon auf zeitbezogene Fehler gestoßen. JWT-Token verwenden iat (ausgestellt um) und exp (Ablauf) Claims, die Unix-Zeitstempel sind. Wenn die Uhr auf dem Server, der den Token ausstellt, und dem Server, der ihn validiert, um mehr als wenige Sekunden auseinander liegen, werden perfekt gültige Token abgelehnt. Du kannst mehr über die Funktionsweise dieser Zeitstempel-Claims in unserem Artikel über JWT-Ablauf- und Ausgestellt-Bei-Claims erfahren.

Genauso verlassen sich verteilte Datenbanken wie Cassandra, CockroachDB und Spanner auf Zeitgenauigkeit für Konfliktauflösung und Transaktionsordnung. Googles Spanner nutzt beispielsweise absichtlich GPS und Atomuhren in jedem Rechenzentrum, weil NTP allein nicht präzise genug für seine Konsistenzgarantien ist.

Log-Korrelation ist ein weiterer häufiger Schmerzpunkt. Wenn zwei Server um 5 Sekunden auseinander liegen, wird das Nachverfolgen einer Anfrage über beide Systeme zu einem Rätsel, weil die Zeitstempel nicht übereinstimmen. NTP-synchronisierte Uhren machen verteiltes Tracing und Log-Aggregation dramatisch einfacher.

Warum Zeitgenauigkeit wichtiger ist als du denkst

NTP-Zeitsynchronisation ist nicht nur eine Hintergrund-Housekeeping-Aufgabe. Sie ist eine grundlegende Abhängigkeit für überraschend viele Systeme:

  • TLS/SSL-Zertifikate: Die Zertifikatsgültigkeit wird gegen die aktuelle Zeit geprüft. Eine Uhr, die um mehr als das Gültigkeitsfenster des Zertifikats falsch ist, führt zu fehlgeschlagenen HTTPS-Verbindungen.
  • Kerberos-Authentifizierung: Kerberos lehnt standardmäßig Tickets ab, wenn die Uhrenabweichung zwischen Client und Server 5 Minuten überschreitet. Active-Directory-Umgebungen sind besonders empfindlich dafür.
  • Datenbankreplikation: Viele Replikationssysteme verwenden Zeitstempel, um zu bestimmen, welcher Schreibvorgang neuer ist. Uhrenabweichung kann dazu führen, dass Daten mit älteren Werten überschrieben werden.
  • Finanzsysteme: Regulatorische Anforderungen (zum Beispiel MiFID II in der EU) schreiben vor, dass Handelssysteme die Uhrengenauigkeit auf 1 ms genau zu UTC einhalten müssen.
  • Unix-Zeitstempel: Jeder Unix-Zeitstempel, den deine Anwendung generiert, ist nur so genau wie die Systemuhr. Wenn du die Grundlagen verstehen möchtest, auf denen diese Zeitstempel aufgebaut sind, erklärt unser Leitfaden zu Epoch-Zeit und Unix-Zeitstempeln die Grundlagen ausführlich.
Virtuelle Maschinen brauchen besondere Aufmerksamkeit. VMs haben keine dedizierten Hardware-Uhren. Wenn eine VM pausiert, migriert oder aus einem Snapshot wiederhergestellt wird, kann ihre Uhr wild springen. Konfiguriere immer NTP (oder verwende VMware Tools / Hyper-V Integration Services) auf jeder VM, und stelle sicher, dass auch der Hypervisor-Host selbst NTP-synchronisiert ist.

Für die meisten Anwendungen gibt dir NTP über das öffentliche Internet eine Genauigkeit von 10-50 ms, was mehr als ausreichend ist. Für strengere Anforderungen kann das Betreiben deines eigenen Stratum-1-Servers mit einem GPS-Empfänger (ein Raspberry Pi mit GPS-Erweiterung kostet unter 50 Euro) dir Submillisekunden-Genauigkeit in deinem lokalen Netzwerk geben. Und für alles, das Mikrosekunden-Präzision erfordert, ist PTP mit Hardware-Zeitstempel der Weg nach vorne.

Das Fazit: NTP ist stille Infrastruktur, die du nur bemerkst, wenn sie kaputt geht. Ein gut konfiguriertes NTP-Setup bedeutet, dass deine Logs Sinn ergeben, deine Token funktionieren, deine Zertifikate validieren und deine verteilten Systeme sich auf eine gemeinsame Definition von "jetzt" einigen.

Unix-Zeitstempel-Konvertierungstool mit NTP-synchronisierter Zeitkonvertierung

Konvertiere NTP-synchronisierte Unix-Zeitstempel sofort

Wenn NTP-Zeitsynchronisation einen Unix-Zeitstempel produziert und du wissen möchtest, was er in menschenlesbarer Form bedeutet, verarbeitet unser kostenloser Konverter das sofort. Füge einen 10-stelligen oder 13-stelligen Zeitstempel ein und erhalte das vollständige Datum, die Zeit, das ISO-8601-Format und die relative Zeit in einem Klick.

Kostenlose Zeitstempel-Konvertierung ausprobieren →

Über eine typische Breitbandverbindung erreicht NTP eine Genauigkeit von 10 bis 50 Millisekunden relativ zu UTC. In einem gut eingestellten lokalen Netzwerk, das mit einem nahen Stratum-1- oder Stratum-2-Server synchronisiert, kannst du auf 1 bis 5 ms herunterkommen. Der Hauptbegrenzungsfaktor ist variable Netzwerkverzögerung, die NTP-Algorithmus statistisch über mehrere Polling-Zyklen berücksichtigt.

Ohne NTP driftet die Serveruhr frei basierend auf ihrem Hardware-Oszillator. Je nach Hardware kann das bedeuten, dass pro Tag mehrere Sekunden gewonnen oder verloren gehen. Über Wochen oder Monate kann die Abweichung groß genug werden, um TLS-Zertifikatvalidierung zu brechen, Kerberos-Authentifizierungsfehler zu verursachen, Zeitstempel in Logs zu beschädigen und Token-Ablauf-Fehler in Anwendungen auszulösen, die sich auf Unix-Zeitstempel verlassen.

ntpd ist der ursprüngliche NTP-daemon aus der NTP-Referenzimplementierung. chronyd (aus dem chrony-Projekt) ist eine neuere Implementierung, die intermittierende Netzwerkverbindungen besser handhabt, nach einem Neustart schneller synchronisiert und in Umgebungen mit variabler Latenz genauer ist. Die meisten modernen Linux-Distributionen (RHEL 7+, Ubuntu 18.04+) verwenden standardmäßig chrony. Beide implementieren das gleiche NTPv4-Protokoll und sind interoperabel.

Ja, aber es erfordert Sorgfalt. NTP-Server geben kommende Schaltsekunden über ein Flag im Protokollpaket an. Clients können dann die zusätzliche Sekunde entweder direkt einfügen (was einen Rücksprung um eine Sekunde verursachen kann) oder "Leap Smearing" verwenden, wobei die zusätzliche Sekunde über ein 24-Stunden-Fenster verteilt wird. Google und Cloudflare verwenden beide Leap Smearing auf ihren öffentlichen NTP-Servern, um den Sprung vollständig zu vermeiden.

Konfiguriere mindestens vier Server. NTP nutzt einen Voting-Algorithmus namens "Intersection Algorithm", um Ausreißer zu erkennen und zu verwerfen. Mit nur einem oder zwei Servern kann NTP nicht bestimmen, welcher falsch ist, wenn sie sich widersprechen. Mit vier oder mehr kann es einen fehlerhaften Server identifizieren und ignorieren, während es dennoch Genauigkeit beibehält. Das NTP Pool Project macht das einfach, indem es regionale Pool-Adressen wie 0.pool.ntp.org bis 3.pool.ntp.org bereitstellt.

NTP synchronisiert Uhren immer zu UTC. Zeitzonen sind eine Anzeige-Angelegenheit, die vom Betriebssystem separat von NTP behandelt wird. Ein Server in Tokio und ein Server in New York synchronisieren beide zu UTC, und jeder wendet seinen eigenen lokalen Zeitzonen-Offset nur für Anzeigezwecke an. Genau deshalb werden Unix-Zeitstempel in UTC gespeichert und nur bei Anzeige für Benutzer in lokale Zeit konvertiert. Unser Leitfaden zu Unix-Zeitstempeln und UTC erklärt die Beziehung ausführlicher.