Zusammenfassung

  • Vier Zeitstempel liefern Schätzungen für Offset und Rundlaufzeit. NTP filtert viele Messungen, vergleicht Quellen und diszipliniert erst dann die lokale Uhr.
  • Stratum beschreibt Referenzabstand und verhindert Schleifen; es ist kein Güte-, Eigentums- oder Rangzertifikat. Auswahl kann scheitern, und scheinbar verschiedene Quellen können gemeinsam ausfallen.
  • NTS authentifiziert den Client-Server-Austausch, nicht die Richtigkeit der vorgeschalteten Uhr. Vielfalt, Erlaubnis, Überwachung und Stellpolitik bleiben Betreiberaufgaben.

Eine präzise Antwort kann grob falsch sein

RFC 1129 berichtete 1989 über Anfragen an 94.260 Hosts und Gateways mit drei Zeitprotokollen. 20.758 antworteten. Etwa die Hälfte lag mehr als zwei Minuten neben der Referenz, ungefähr zehn Prozent mehr als vier Stunden; einzelne Uhren irrten um über zwei Wochen.

Die Erhebung war keine Vollzählung des Internets. Sie beschrieb die erreichbaren Antwortenden. Gerade darin lag die Warnung: Erreichbarkeit beglaubigt weder Oszillator noch Upstream noch Betreiber. Viele Nachkommastellen können eine stabile Fehlanzeige schmücken.

NTP ersetzte diesen Mangel nicht durch einen unfehlbaren Sprecher. Es machte Aussagen vergleichbar und gab dem Client ein Verfahren, einer Quelle nicht zu folgen.

Vier Momente um einen unsicheren Weg

Der DCNET Internet Clock Service von 1981 zeigte bereits die Grundfigur. RFC 778 verband eine WWV-Funkuhr bei COMSAT mit Netzfrequenzuhren, deren Offset und Drift abwichen. ICMP-Zeitstempel markierten Anfrage und Rückkehr.

In heutiger Schreibweise sendet der Client bei t1, der Server empfängt bei t2, sendet bei t3, der Client empfängt bei t4. Der Offset wird als [(t2 - t1) + (t3 - t4)] / 2 geschätzt, die Rundlaufzeit als (t4 - t1) - (t3 - t2).

Die beiden Einweglaufzeiten werden nicht getrennt gemessen. Asymmetrie gelangt deshalb als Uhrenfehler in die Schätzung. Numerische Auflösung beseitigt diese Unsicherheit nicht.

Ein verlorenes Paket durfte bedeutungslos bleiben

RFC 958 spezifizierte NTP im September 1985. RFC 1059 beschrieb 1988 Version 1 nach rund zwei Jahren Prototypbetrieb: mehrere Primärreferenzen, eine selbstorganisierende hierarchische Serverstruktur und keine weltweite Wahl eines einzigen Masters.

Ein verlorenes Datagramm musste nicht zuverlässig nachgeliefert werden. Die nächste Messung ersetzte es. Das passte zu einem Internet mit mehreren Gateways, wechselnden Warteschlangen und Paketverlust. Schon Version 1 filterte Proben, glättete Sprünge, kompensierte Drift und verstellte die Uhr schrittweise. Die dort genannten Ergebnisse im Bereich einiger zehn Millisekunden gelten für das dokumentierte Umfeld, nicht universell.

Auswahl ohne Wahrheitsmaschine

Jede Quelle liefert Folgen von Offset, Laufzeit und Unsicherheit. Der Filter bevorzugt brauchbare, oft niedrig verzögerte Proben, damit eine kurze Warteschlange nicht die Uhr regiert. Die Auswahl vergleicht anschließend mögliche Korrekturintervalle und verwirft unvereinbare Kandidaten als Falseticker.

RFC 1305 verfeinerte Filter und Auswahl für NTPv3. RFC 5905 beschreibt für NTPv4 Auswahl, Clusterbildung und Kombination. Der Algorithmus der University of Delaware kennt aber auch das Ergebnis „keine Auswahl“: Fehlt eine ausreichende Schnittmenge, gibt es keinen Sieger.

Mehr Stimmen garantieren nichts. Verschiedene Namen können denselben GPS-Empfänger, Hypervisor, Betreiber oder Leap-Smear teilen. Korrelation verwandelt vermeintliche Vielfalt in einen gemeinsamen Fehler.

Stratum ist Entfernung, kein Adelstitel

Stratum 1 ist direkt mit einer Primärreferenz verbunden, 2 bis 15 folgen in der Synchronisationskette, 16 bedeutet unsynchronisiert. So kann eine Uhr nicht von ihrem Nachfahren lernen und einen Zeitfehler im Kreis führen.

Eine kleine Zahl garantiert keine bessere Quelle. Ein schlecht betriebener Stratum-1-Server kann einem stabilen Stratum 3 unterlegen sein. Der Wert sagt nichts über Eigentum oder Mandat. NTP besitzt Hierarchie und Primärquellen, zugleich aber Client-Server-, Broadcast- und symmetrische Peer-Modi. Es ist weder eine souveräne Pyramide noch ein vertrauensfreies Flachland.

Betrieb bleibt Teil der Genauigkeit

RFC 8633 empfiehlt mehrere wirklich unabhängige Quellen und laufende Überwachung. Vier oder mehr verbessern Robustheit nur bei unabhängigen Fehlern. Verschiedene Netze können eine Referenz teilen; Leap-Smear- und nicht geschmierte UTC-Quellen können während eines Schaltsekundenereignisses absichtlich auseinanderlaufen.

Auch Erlaubnis gehört dazu. Hersteller dürfen fremde öffentliche Server nicht ohne Vereinbarung in Millionen Geräte einprogrammieren. Ein Default kann jahrelang Kosten und Angriffsverkehr erzeugen. UDP-Exposition, Ratenbegrenzung und Missbrauchsbeobachtung sind keine Nebensachen.

Authentische Nachricht, fehlbare Zeit

RFC 8915 standardisierte 2020 Network Time Security für den Client-Server-Modus. NTS-KE verwendet TLS für Schlüsselmaterial und geschützte Cookies; spätere NTP-Pakete tragen authentifizierte Erweiterungen, während der Server nach der Einrichtung zustandslos bleiben kann.

NTS schützt Herkunft und Integrität. Es beweist nicht, dass die vorgeschaltete Referenz stimmt oder die Quellen unabhängig sind. Ein authentischer Fehler bleibt ein Fehler. Symmetrische und Kontrollmodi liegen außerhalb des Standards.

Gemeinsame Zeit als widerrufbare Evidenz

Logs, Zertifikate, Datenbanken und physische Steuerungen brauchen eine Reihenfolge. Das macht einen bekannten Zeitdienst als Ersatz für Gewissheit verführerisch. NTP bietet die robustere Zumutung: fehlbare Aussagen sammeln, Wege einrechnen, Unvereinbares verwerfen, Überlebende verbinden und die lokale Uhr unter eigener Kontrolle halten.

Vertrauen verschwindet nicht. Es wird plural, messbar und widerrufbar. Referenzbetreiber pflegen den Bezug zur bürgerlichen Zeit, Serverbetreiber ihre Quellen und Zugänge, Netze prägen Verzögerung, Clients treffen die letzte Uhrenentscheidung. Aus Widerspruch entsteht Konvergenz, ohne einen Server zum dauerhaften Herrscher aller Uhren zu machen.

Quellen und Beweisgrenzen

Der Vorläufer steht in RFC 778, die erste NTP-Spezifikation in RFC 958, Version 1 in RFC 1059, die Erhebung in RFC 1129. NTPv3 beschreibt RFC 1305. Das reife Modell liefern RFC 5905 und Clock Select Algorithm. Betriebspraxis folgt RFC 8633, NTS RFC 8915.

Die Erhebungszahlen gelten für Antwortende; spätere Versionsmerkmale werden nicht auf 1985 zurückprojiziert.