Das Problem vor NTP
Bevor das Internet lernte, die Uhrzeit zu bestimmen, war jeder Computer auf sich allein gestellt. Ein Server in New York konnte innerhalb einer Woche um drei Minuten vorgehen. Eine Datenbank-Replik in San Francisco lief vielleicht zwei Minuten nach. Ein Handelsterminal in Chicago stimmte mit keinem von beiden überein. Solange Maschinen isoliert arbeiteten, fiel das niemandem auf. Doch sobald sie anfingen, miteinander zu kommunizieren, ließ sich das Chaos nicht mehr ignorieren.
Zeit ist wichtiger, als die meisten Menschen ahnen. Finanzbörsen müssen wissen, welcher Handel zuerst kam. Wenn zwei Datenbankserver Daten untereinander replizieren, entscheiden Zeitstempel darüber, welcher Schreibvorgang gewinnt. Logdateien verschiedener Maschinen müssen in chronologischer Reihenfolge zusammengeführt werden, damit Ingenieure Ausfälle nachvollziehen können. Flugsicherungssysteme, Medikamentenausgabeautomaten in Krankenhäusern, Synchronisierungssysteme im Stromnetz, Zertifizierungsstellen, die die Verschlüsselungsschlüssel hinter jeder HTTPS-Verbindung ausstellen — sie alle sind auf Uhren angewiesen, die übereinstimmen.
In den frühen 1980er-Jahren war das Internet noch eine Ansammlung von Universitäts- und Regierungsnetzwerken, doch das Problem war bereits akut. Maschinen synchronisierten ihre Uhren, indem sie Zeitdienste über Modemverbindungen anriefen — ein Verfahren, das langsam, teuer und äußerst ungenau war. Manche Administratoren stellten die Uhr per Hand, warfen einen Blick auf ihre Armbanduhr und tippten die Zeit ein. Die Abweichung konnte Sekunden, Minuten oder Schlimmeres betragen. Was das wachsende Netzwerk brauchte, war ein Protokoll — ein automatischer, selbstkorrigierender Weg, damit jede Maschine im Internet sich darauf einigen konnte, wie spät es war.
David Mills und die Geburt von NTP
Der Mann, der dieses Problem löste, war David L. Mills, Professor für Informatik an der University of Delaware. Mills hatte sich seit den späten 1970er-Jahren mit Netzwerk-Zeitsynchronisation beschäftigt, und 1985 veröffentlichte er RFC 958 — die erste formale Spezifikation des Network Time Protocol. Es war nicht sein erster Versuch, das Problem zu lösen — zuvor hatte er frühere Protokolle namens DCNET und Internet Clock Service entworfen — doch NTP war dasjenige, das Bestand hatte.
RFC 958 beschrieb eine Architektur, die zugleich elegant und praxistauglich war. Anstatt zu verlangen, dass jeder Computer direkt auf eine Atomuhr zugreifen muss, organisierte NTP Zeitquellen in einer Hierarchie. Es verwendete geschickte Mathematik, um unvorhersehbare Netzwerkverzögerungen auszugleichen. Und es war auf Robustheit ausgelegt: Wenn eine Zeitquelle ausfiel, wechselten die Clients automatisch zu einer anderen. Das Protokoll konnte Uhren über das chaotische, unzuverlässige Internet der 1980er-Jahre hinweg auf wenige zehn Millisekunden genau synchronisieren — eine Leistung, die damals fast wie Magie wirkte.
Mills wartete und entwickelte NTP fast drei Jahrzehnte lang weiter, beinahe im Alleingang. Er schrieb die Referenzimplementierung. Er beantwortete Fragen auf Mailinglisten. Er veröffentlichte aktualisierte RFCs, als das Protokoll die Versionen 2, 3 und 4 durchlief. Als er in den Ruhestand ging, war NTP eines der ältesten Internetprotokolle, die noch täglich aktiv genutzt werden — älter als HTTP, älter als SSL, älter als DNS in seiner heutigen Form. Mills verstarb im Januar 2024 im Alter von 85 Jahren und hinterließ ein Protokoll, das täglich stillschweigend Milliarden von Geräten synchronisiert. Die meisten Menschen, die von seiner Arbeit abhängen, haben seinen Namen nie gehört.
Wie das Stratum-System funktioniert
NTP ordnet Zeitquellen in Schichten an, die Strata genannt werden. Ganz oben steht Stratum 0: die eigentliche Zeitmess-Hardware. Das sind Cäsium-Atomuhren, Wasserstoff-Maser, GPS-Empfänger und andere Präzisionsinstrumente, die ein Zeitsignal mit einer Genauigkeit von Milliardstel Sekunden erzeugen. Sie können sich nicht über das Netzwerk mit einem Stratum-0-Gerät verbinden — es handelt sich um physische Instrumente, die oft in Racks nationaler Laboratorien verschraubt oder auf Satelliten montiert sind, die in 20.200 Kilometern Höhe die Erde umkreisen.
Stratum-1-Server sind Computer, die direkt mit Stratum-0-Hardware verbunden sind, typischerweise über ein serielles Kabel, eine dedizierte GPS-Antenne auf dem Dach oder eine Direktverbindung zu einer Cäsium-Uhr im Nebenraum. Diese Maschinen lesen das Atomzeitsignal aus und stellen es über das Netzwerk bereit. Weltweit gibt es etwa tausend öffentliche Stratum-1-Server, betrieben von nationalen Metrologie-Instituten, Universitäten und Technologieunternehmen.
Stratum-2-Server synchronisieren sich mit Stratum 1. Stratum 3 mit Stratum 2. Jede Schicht fügt eine geringe Fehlermarge und eine geringe Verzögerung hinzu. Die Hierarchie setzt sich bis Stratum 15 fort. Stratum 16 ist ein Sonderwert mit der Bedeutung „nicht synchronisiert" — ein Server auf Stratum 16 signalisiert, dass er keine zuverlässige Zeitquelle hat und nicht vertrauenswürdig ist.
Das Geniale an diesem Schichtdesign ist die Lastverteilung. Es gibt Milliarden von Geräten im Internet, die eine genaue Uhrzeit benötigen, aber nur einige hundert Atomuhren. Wenn jedes Smartphone der Welt versuchen würde, sich direkt von einer Cäsium-Fontänenuhr am National Institute of Standards and Technology in Boulder, Colorado, zu synchronisieren, würde das System sofort zusammenbrechen. Stattdessen synchronisiert sich Ihr Telefon mit einem Stratum-2- oder Stratum-3-Server, dieser wiederum mit einem Stratum-1-Server, und der mit der Atomuhr. Die Last verteilt sich über Millionen von Zwischenservern, und die Atomuhren bleiben unbehelligt.
Die geschickte Mathematik hinter NTP
Die grundlegende Herausforderung der Netzwerk-Zeitsynchronisation besteht darin, dass Sie einen Server nicht einfach fragen können „Wie spät ist es?" und die Antwort verwenden können. Die Frage braucht Zeit, um durch das Netzwerk zu reisen. Die Antwort braucht Zeit für den Rückweg. Und diese beiden Laufzeiten sind nicht notwendigerweise gleich — ein Paket könnte 20 Millisekunden brauchen, um den Atlantik westwärts zu überqueren, und 35 Millisekunden für den Rückweg ostwärts, abhängig von Routing, Netzauslastung und der Mondphase.
NTP löst dies mit einem Vier-Zeitstempel-Austausch. Der Client notiert die Zeit, zu der er eine Anfrage sendet (T1). Der Server notiert die Zeit, zu der er diese Anfrage empfängt (T2). Der Server notiert die Zeit, zu der er seine Antwort sendet (T3). Und der Client notiert die Zeit, zu der er diese Antwort empfängt (T4). Aus diesen vier Zahlen berechnet NTP zwei entscheidende Werte.
Die Umlaufverzögerung beträgt (T4 - T1) - (T3 - T2). Diese Zahl gibt an, wie lange das Paket unterwegs war, abzüglich der Verarbeitungszeit des Servers. Der Uhrenversatz beträgt ((T2 - T1) + (T3 - T4)) / 2. Dies ist die geschätzte Differenz zwischen der Uhr des Clients und der Uhr des Servers, unter der Annahme, dass die Netzwerkverzögerung in beiden Richtungen ungefähr symmetrisch ist.
Diese Symmetrieannahme trifft nicht immer zu, und NTP weiß das. Das Protokoll verlässt sich nicht auf einen einzelnen Austausch. Es befragt mehrere Server, sammelt über die Zeit viele Stichproben, wendet statistische Filter an, um Ausreißer zu verwerfen, und nutzt Algorithmen mit Namen wie „Clock Selection Algorithm" und „Clock Clustering Algorithm", um die besten Quellen auszuwählen und zu kombinieren. Das Ergebnis ist über das öffentliche Internet mit all seiner Unberechenbarkeit eine Synchronisationsgenauigkeit von wenigen Millisekunden. In einem lokalen Netzwerk, wo Verzögerungen kurz und stabil sind, erreicht NTP regelmäßig Genauigkeiten unter 100 Mikrosekunden.
Woher die Zeit tatsächlich kommt
Am Fundament der Zeitmess-Pyramide stehen die nationalen Metrologie-Laboratorien der Welt. Das National Institute of Standards and Technology (NIST) in Boulder, Colorado, betreibt eine Reihe von Cäsium-Fontänenuhren — Geräte, die Wolken von Cäsium-Atomen durch eine Mikrowellenkavität nach oben schleudern und ihre Quantenzustandsübergänge beim Herabfallen messen. Die Oszillationsfrequenz von Cäsium-133, exakt 9.192.631.770 Schwingungen pro Sekunde, definiert seit 1967 die SI-Sekunde.
Die Physikalisch-Technische Bundesanstalt (PTB) in Braunschweig — Deutschlands nationales Metrologie-Institut und eine der renommiertesten Zeitgeber-Institutionen der Welt — betreibt unter anderem die Cäsium-Fontänenuhr CSF2, die zu den genauesten Uhren weltweit gehört. Die PTB liefert die gesetzliche Zeit für Deutschland und strahlt das Zeitsignal DCF77 aus, das Funkuhren in ganz Mitteleuropa synchronisiert. Das britische National Physical Laboratory (NPL) in Teddington, das französische LNE-SYRTE in Paris und rund 80 weitere nationale Laboratorien weltweit unterhalten ihre eigenen Atomuhren. Jedes Labor erzeugt seine eigene Realisierung der Sekunde, und diese Realisierungen stimmen nicht perfekt überein. Eine Cäsium-Uhr in Boulder kann sich von einer in Braunschweig über einen Monat um einige Nanosekunden unterscheiden.
Hier kommt das Bureau International des Poids et Mesures (BIPM) in Paris ins Spiel. Das BIPM betreibt selbst keine Uhr. Stattdessen sammelt es Zeitdaten von rund 450 Atomuhren in etwa 80 Laboratorien weltweit, wendet einen gewichteten Mittelungsalgorithmus an und veröffentlicht eine berechnete Zeitskala namens Koordinierte Weltzeit, kurz UTC. Dieser Mittelungsprozess geschieht im Nachhinein — das BIPM veröffentlicht Korrekturen erst Wochen später — sodass UTC nicht in Echtzeit verfügbar ist. Was Sie tatsächlich über NTP synchronisieren, ist die Echtzeit-Annäherung jedes Laboratoriums an UTC, etwa UTC(NIST), UTC(PTB) und so weiter. Die Rolle des BIPM ist es, zu verhindern, dass diese Annäherungen auseinanderdriften.
Dann gibt es die GPS-Satelliten. Jeder der 31 aktiven GPS-Satelliten trägt mehrere Atomuhren — Rubidium und Cäsium — und sendet Zeitsignale als Teil seiner Navigationsnachricht. Die GPS-Zeit ist nicht identisch mit UTC (sie wich 1980 ab und berücksichtigt keine Schaltsekunden), aber der Versatz wird in der Navigationsnachricht mitgesendet, sodass ein GPS-Empfänger UTC berechnen kann. Viele Stratum-1-NTP-Server nutzen GPS als Referenzuhr, weil ein 50-Dollar-Empfänger und eine Dachantenne eine Zeitgenauigkeit von 10 Nanosekunden liefern können — weit günstiger als der Kauf einer Cäsium-Uhr.
NTP im großen Maßstab
Das NTP-Pool-Projekt unter pool.ntp.org ist eine der großen Geschichten freiwilliger Infrastruktur im Internet. 2003 von Adrian von Bidder gegründet, ist der Pool eine Sammlung tausender von Freiwilligen betriebener NTP-Server, die über den gesamten Globus verteilt sind. Wenn Ihr Computer für die Nutzung von pool.ntp.org konfiguriert ist, gibt das DNS-System jedes Mal einen anderen Satz von Serveradressen zurück und verteilt die Last über den freiwilligen Pool. Stand 2025 bedient der Pool geschätzte 50 Millionen Clients pro Sekunde und deckt den Zeitsynchronisationsbedarf der meisten Linux-Distributionen, vieler IoT-Geräte und unzähliger anderer Systeme, die pool.ntp.org als Standard-NTP-Quelle verwenden.
Große Technologieunternehmen betreiben ihre eigene Zeitinfrastruktur in enormem Umfang. Google betreibt eine Flotte von Servern, die mit Atomuhren und GPS-Empfängern in seinen Rechenzentren synchronisiert sind. Googles Zeitdienst ist öffentlich unter time.google.com verfügbar und implementiert eine interessante Besonderheit: Statt Schaltsekunden abrupt einzufügen, verwendet Google eine Technik namens „Leap Smear", die die zusätzliche Sekunde über ein 24-Stunden-Fenster verteilt. Dies vermeidet die Software-Abstürze, die abrupte Schaltsekundeneinfügungen in der Vergangenheit verursacht haben, bedeutet aber, dass Googles Zeit während eines Leap-Smear-Ereignisses bewusst um bis zu einer halben Sekunde von UTC abweicht.
Meta (ehemals Facebook) betreibt einen ähnlichen internen Zeitdienst und hat detaillierte technische Blogbeiträge über seine Nutzung des Precision Time Protocol (PTP) innerhalb seiner Rechenzentren veröffentlicht, aufgesetzt auf GPS-disziplinierte Grandmaster-Uhren. Amazon betreibt den Amazon Time Sync Service, der allen AWS-Instanzen zur Verfügung steht. Cloudflare bietet einen öffentlichen NTP-Dienst an und setzt sich für Roughtime ein — ein von Google entwickeltes Protokoll, das Zeitantworten um kryptografische Nachweise ergänzt, damit Clients überprüfen können, dass sie nicht getäuscht werden.
Wenn NTP schiefgeht
Am 30. Juni 2012 wurde um Mitternacht eine Schaltsekunde in UTC eingefügt. Die zusätzliche Sekunde — 23:59:60 — löste einen Fehler im Zeitmessungscode des Linux-Kernels aus, der den hochauflösenden Timer des Systems durcheinanderbrachte. Prozesse, die auf diese Timer angewiesen waren, verbrauchten plötzlich 100 Prozent ihrer CPU-Kerne und drehten sich in engen Schleifen. Reddit fiel aus. Mozilla fiel aus. Gawker fiel aus. Das Check-in-System von Qantas Airlines stürzte ab und ließ Passagiere stranden. StumbleUpon, FourSquare, Yelp und LinkedIn meldeten allesamt Störungen. Die Lösung war entweder ein Neustart der betroffenen Systeme oder das manuelle Setzen der Uhr — was sich ironisch anfühlte, wenn man bedenkt, dass das Problem mit dem Versuch begann, Uhren genau zu halten.
GPS-Spoofing stellt eine heimtückischere Bedrohung dar. Da GPS-Signale mit extrem geringer Leistung ankommen — etwa 10^-16 Watt an der Erdoberfläche — können sie von einem relativ preiswerten Sender mit gefälschten Signalen überlagert werden. Ein gefälschtes GPS-Signal kann jedem Stratum-1-NTP-Server, der GPS als Referenz nutzt, eine falsche Zeit unterjubeln. 2013 demonstrierten Forscher der University of Texas in Austin, dass sie einen GPS-Empfänger aus einem Kilometer Entfernung mit Equipment im Wert von etwa 3.000 Dollar spoofen konnten, wobei sie die angezeigte Zeit schrittweise verschoben, ohne irgendwelche Alarme auszulösen.
2016 erlebte Cloudflare einen weithin berichteten Vorfall, bei dem einige seiner Server Clients aufgrund eines Fehlers in der NTP-Verarbeitung kurzzeitig Daten aus dem Jahr 2026 oder 1970 lieferten. Subtilere Fehler treten ständig auf. Falsch konfigurierte NTP-Server, die sich als Stratum 1 ausgeben, obwohl sie tatsächlich freilaufend sind, verursachen kaskadenartige Ungenauigkeiten bei jedem Client, der ihnen vertraut. Firewalls, die NTP-Verkehr blockieren, lassen Maschinen stillschweigend abdriften. Virtuelle Maschinen in Cloud-Umgebungen sind berüchtigt für Uhrenabweichungen, weil das CPU-Scheduling des Hypervisors unvorhersehbare Verzögerungen in der Zeitmessung des Gastbetriebssystems verursacht.
Diese Fehlermodi erklären, warum NTP-Authentifizierung wichtig ist. Das ursprüngliche NTP-Protokoll hatte keine Möglichkeit für einen Client zu überprüfen, ob eine Zeitantwort tatsächlich vom angegebenen Server stammte. Ein Angreifer auf dem Netzwerkpfad konnte Zeitantworten während der Übertragung manipulieren. Network Time Security (NTS), spezifiziert in RFC 8915 und veröffentlicht im Jahr 2020, fügt NTP eine TLS-basierte Authentifizierung hinzu. Die Verbreitung war bisher langsam — der größte Teil des NTP-Verkehrs im Internet ist nach wie vor unauthentifiziert — aber große Anbieter wie Cloudflare unterstützen NTS inzwischen, und die Entwicklung geht in Richtung einer universellen Einführung.
GPS-Zeit vs. NTP
Ihr Smartphone verwendet mit ziemlicher Sicherheit nicht NTP als primäre Zeitquelle. Stattdessen nutzt es die vom Mobilfunknetz übermittelte Zeit, die ihrerseits von GPS abgeleitet ist. GPS-Satelliten tragen Atomuhren an Bord und senden ihre aktuelle Zeit als Teil jedes Navigationssignals. Der Empfänger in Ihrem Telefon berechnet neben Breiten- und Längengrad auch die Zeit aus den Satellitensignalen und stellt damit die Uhr des Telefons.
GPS-Zeit und UTC sind nicht dasselbe. Als GPS 1980 gestartet wurde, war es mit UTC synchronisiert. Doch UTC fügt gelegentlich Schaltsekunden ein, um mit der sich verlangsamenden Erdrotation Schritt zu halten, und GPS tut das nicht. Stand 2025 geht GPS-Zeit 18 Sekunden vor gegenüber UTC. Die GPS-Navigationsnachricht enthält den aktuellen Versatz, sodass Empfänger zwischen beiden umrechnen können, aber die Unterscheidung ist für Ingenieure, die mit rohen GPS-Daten arbeiten, von Bedeutung.
Moderne Smartphones verwenden einen hybriden Ansatz. Das GPS- oder Mobilfunkzeitsignal liefert eine grobe Synchronisation, typischerweise auf wenige zehn Nanosekunden genau. Doch der GPS-Empfang ist unregelmäßig — das Telefon kann sich in einem Gebäude befinden, in einer U-Bahn oder im Flugmodus. NTP füllt die Lücken. Apple, Google und die meisten Telefonhersteller konfigurieren ihre Geräte so, dass sie zusätzlich NTP-Server abfragen (Apple nutzt time.apple.com, Android-Geräte time.android.com), um die Genauigkeit aufrechtzuerhalten, wenn Satellitensignale nicht verfügbar sind. Die beiden Systeme ergänzen sich: GPS liefert absolute Genauigkeit bei freiem Himmel, und NTP sorgt für kontinuierliche Korrektur, wenn kein Satellitenempfang möglich ist.
Das Y2038-Problem
Unix-Zeit, das System, das von praktisch jedem Server, Telefon und eingebetteten Gerät auf dem Planeten verwendet wird, zählt die Anzahl der seit Mitternacht UTC am 1. Januar 1970 vergangenen Sekunden. Jahrzehntelang wurde dieser Zähler als vorzeichenbehaftete 32-Bit-Ganzzahl gespeichert, die Werte bis 2.147.483.647 aufnehmen kann. Diese Anzahl Sekunden nach dem Unix-Epoch entspricht dem 19. Januar 2038 um 03:14:07 UTC. Eine Sekunde später läuft der Zähler über, und Systeme, die noch 32-Bit-Zeitstempel verwenden, werden das Datum als 13. Dezember 1901 interpretieren.
NTP hat seine eigene Version dieses Problems. Das NTP-Zeitstempelformat verwendet einen 64-Bit-Wert: 32 Bit für die Sekunden seit dem 1. Januar 1900 und 32 Bit für den Sekundenbruchteil. Das Sekundenfeld läuft am 7. Februar 2036 über — zwei Jahre vor der Unix-Y2038-Deadline. NTPv4, die aktuelle Version des Protokolls, handhabt dies durch die Definition von „Era Numbers", die disambiguieren, zu welchem 136-Jahre-Zyklus ein Zeitstempel gehört, aber beide Endpunkte müssen die Era-Logik korrekt implementieren.
Die meisten modernen Server, Desktop-Rechner und Telefone verwenden bereits 64-Bit-Betriebssysteme mit 64-Bit-Zeitdarstellungen, die erst in etwa 292 Milliarden Jahren überlaufen. Die Gefahr liegt im langen Schweif eingebetteter Systeme: Industriesteuerungen, Gebäudeautomationssysteme, medizinische Geräte, Automobil-ECUs und die Milliarden von IoT-Geräten, die auf 32-Bit-Firmware laufen und möglicherweise nie ein Update erhalten. Viele dieser Geräte nutzen NTP, um ihre Uhren zu stellen. Die stille, unspektakuläre Arbeit, verwundbare Systeme zu identifizieren und aufzurüsten, ist im Gange, doch anders als beim Y2K-Problem gibt es keinen einzelnen Stichtag, der die öffentliche Aufmerksamkeit bündelt. Der NTP-Rollover 2036 und der Unix-Rollover 2038 werden eintreten, unabhängig davon, ob jeder letzte eingebettete Thermostat und Ampelcontroller gepatcht worden ist.
Vier Jahrzehnte und kein Ende in Sicht
NTP synchronisiert die Uhren des Internets seit vier Jahrzehnten. Es hat den Übergang vom ARPANET zum kommerziellen Internet überlebt, von der Einwahlverbindung zur Glasfaser, vom Großrechner zum Smartphone. David Mills entwarf ein Protokoll, das so robust und so gut für seine Aufgabe geeignet war, dass es fast alles überdauert hat, wofür es ursprünglich gebaut wurde. Die Maschinen haben sich verändert, die Netzwerke haben sich verändert, die Geschwindigkeiten haben sich um den Faktor eine Million erhöht — und NTP funktioniert immer noch.
Doch die Anforderungen an die Zeitmessung wachsen. 5G-Mobilfunknetze erfordern eine Synchronisation mit einer Genauigkeit von wenigen zehn Nanosekunden zwischen Basisstationen. Autonome Fahrzeuge brauchen präzises Timing, um Daten von Lidar, Radar und Kameras zu fusionieren. Hochfrequenz-Handelsfirmen messen Latenz in Nanosekunden und zahlen Millionen für einen Vorteil von wenigen Mikrosekunden. Für diese Anwendungen reicht NTPs Genauigkeit im Millisekundenbereich nicht aus. Das Precision Time Protocol (PTP), definiert in IEEE 1588, kann Synchronisation auf Nanosekundenebene mit dedizierter Netzwerk-Hardware erreichen. PTP ist bereits Standard in der Telekommunikation, im Rundfunk und in Finanznetzwerken.
Doch für die Milliarden alltäglicher Geräte — den Laptop auf Ihrem Schreibtisch, den Server im Rechenzentrum, den Thermostat an Ihrer Wand, die Kamera in Ihrer Türklingel — bleibt NTP das unsichtbare Rückgrat der synchronisierten Zeit. Es ist eines dieser grundlegenden Internetprotokolle, das so gut funktioniert, dass fast niemand darüber nachdenkt. Jedes Mal, wenn Sie auf die Uhr Ihres Telefons schauen und sie mit der Uhr Ihres Laptops übereinstimmt, die wiederum mit der Uhr an der Flughafenwand übereinstimmt, die wiederum mit der Abflugzeit auf der Fluginformationstafel übereinstimmt, sehen Sie das Werk eines Protokolls, das vor vier Jahrzehnten von einem Professor in Delaware entworfen wurde — es tickt ohne Klagen weiter und hält die Welt synchron.