Entwicklertools · UUID Generator
Von Apollo NCS zu RFC 9562: Eine kurze Geschichte des UUID
· Hintergrund
UUID Kryptographie Browser-APIs
Das seltsame 8-4-4-4-12-Layout und die 128-Bit-Größe sind vom verteilten Rechnen der 1980er Jahre übernommen. Dieser Beitrag verfolgt den UUID von Apollos Network Computing System über DCE, Microsofts GUID und zwei IETF-Standards.
Warum 128 Bits und warum diese Bindestriche? – die Fragen, die jeder Neuling stellt und die Antworten der Geschichte
Das 8-4-4-4-12 mit Bindestrich und die 128-Bit-Größe eines UUID sind Designentscheidungen, die Historiker sofort in Frage stellen. Warum nicht 96 Bits für eine einfachere Mathematik? Warum dieses spezielle Segmentlayout? Warum base-16 mit Bindestrichen statt base-64 oder eine einfachere Kodierung? Die Antworten liegen im Apollo Network Computing System der frühen 1980er Jahre, einer verteilten Computerplattform, die vor einem echten Problem stand: Systeme in einem Netzwerk mussten eindeutige Kennungen ohne zentrale Autorität zuweisen, und diese Kennungen mussten mit überwältigender Wahrscheinlichkeit weltweit eindeutig sein. Apollo NCS löste dieses Problem, indem es einen Zeitstempel, eine Netzwerkadresse und eine Taktsequenz zu einer 128-Bit-Kennung kombinierte, die von jeder Maschine unabhängig generiert werden konnte.
Apollo Network Computing System – der Ursprung eindeutiger Kennungen aus den 1980er Jahren, die aus der Zeit und einer Netzwerkadresse erstellt wurden
Der aktuelle Standard zeichnet eine Abstammung von Apollo NCS über die OSF Distributed Computing Environment und spätere Microsoft-Plattformen auf. Diese Geschichte erklärt, warum moderne Systeme eine erkennbare 128-Bit-Familie teilen und gleichzeitig Variantenmarkierungen für ältere Layouts beibehalten. Es wird keine absolute Einzigartigkeitsgarantie geschaffen: Jede Version hat ihre eigenen Generierungsregeln und Fehlermodi. Die dauerhafte Errungenschaft ist die Interoperabilität ohne einen zentralen Registrierungsdienst. Ein Browser, eine Datenbank und ein Betriebssystem können dieselbe kanonische Hexadezimalform austauschen, ihre Varianten- und Versionsfelder prüfen und entscheiden, ob das produzierende Rezept den Anforderungen des empfangenden Systems entspricht.
OSF DCE und das Variantenfeld – wie die Distributed Computing Environment das Layout formalisierte und die Variantenbits hinzufügte
Das Layout berücksichtigt mehrere Generierungsstrategien durch Versions- und Variantenfelder, die von Beginn des Designs an eingebettet wurden. Zeitbasierte Generierung, Zufallsgenerierung und namensbasierte Generierung können alle im selben Bezeichnerraum nebeneinander existieren. Moderne Anwendungen haben andere Anforderungen als NCS der 1980er Jahre – Datenbanken, die sortierbare Schlüssel wünschen, Cloud-Systeme, die Datenschutz wünschen, verteilte Systeme, die Kollisionsresistenz wünschen – und doch wird ihnen immer noch die gleiche 128-Bit-Struktur gerecht. Die Versionen 6 und 7, die in RFC 9562 in 2024 hinzugefügt wurden, beweisen, dass die ursprünglichen Designer Raum für zukünftige Weiterentwicklungen gelassen haben, ohne die Abwärtskompatibilität zu beeinträchtigen.
Microsofts GUID – COM, die Registrierung und der Stil mit Klammern und Großbuchstaben, der bis heute erhalten bleibt
Das Apollo Network Computing System war eine verteilte Computerplattform, die in den 1980er Jahren auf Apollo Computer-Workstations lief. Es stützte sich auf global eindeutige Kennungen für Remote-Prozeduraufrufe, Datenreplikation und Benennungsdienste. Die Knoten im Netzwerk hatten keine Möglichkeit, die ID-Zuweisung zu koordinieren, da Sie keinen Kontakt zu einem zentralen Server herstellen konnten, wenn das Netzwerk möglicherweise partitioniert oder nicht verbunden war. Deshalb haben die Apollo-Designer ein 128-Bit-Format erstellt, das einen Zeitstempel von 60 Bits, eine Knotenkennung, die normalerweise aus der MAC-Adresse der Netzwerkkarte abgeleitet wird, von 48 Bits und eine Taktsequenz von 14 Bits zur Verarbeitung von Taktänderungen kombiniert. Mit diesem Ansatz können Knoten unabhängig voneinander Identifikatoren generieren, indem sie Zeit, eine Taktsequenz und ein Knotenfeld kombinieren. sein Verhalten hing immer noch von den Uhren und der Knotenauswahl ab.
RFC 4122 (2005) – der IETF-Standard, der die Versionen 1 bis 5 und den URN-Namespace definiert, abgestimmt auf ITU-T X.667
Als die OSF dies später für ihre verteilte Computerumgebung um 1992 herum standardisierte, behielten sie das gleiche Layout bei und fügten das Variantenfeld hinzu, um verschiedene UUID-Typen zu unterscheiden. Das Design hat sich bereits in Produktionsanlagen bewährt. Die IETF standardisierte RFC 4122 in 2005, fast zwanzig Jahre nach Apollo NCS und etwa dreizehn Jahre nach der DCE-Standardisierung. RFC 4122 kodifizierte die Versionen 1 bis 5: Version 1 für zeitbasierte Generierung, Version 3 für namensbasierte mit MD5, Version 4 für zufällige und Version 5 für namensbasierte mit SHA-1. Der Standard war stabil und weit verbreitet, da er in Microsoft Windows, der DNS-Infrastruktur und verteilten Systemen bereits allgegenwärtig war. Als RFC 4122 veröffentlicht wurde, war UUID bereits so stark in die Infrastruktur eingebettet, dass die Standardisierung fast akademisch war.
RFC 9562 (2024) – die Revision, die RFC 4122 veraltete, Versionen 6, 7 und 8 hinzufügte und moderne Ratschläge zur Zufälligkeit niederschrieb
In 2024 veröffentlichte die IETF RFC 9562, der RFC 4122 veraltet und die Versionen 6, 7 und 8 hinzufügt. Version 6 ordnet die Zeitfelder der Version 1 für eine bessere B-Tree-Lokalität und Sortierbarkeit neu an. Version 7 verwendet einen modernen und vertrauten Unix-Zeitstempel anstelle der auf 1582 basierenden Anzahl, wodurch die Sortierbarkeit verbessert und moderne Datenbankanforderungen erfüllt werden. Version 8 reserviert Platz für benutzerdefinierte Implementierungen und experimentelle UUID Designs. Die neuen Versionen adressieren Probleme, die im Laufe von vierzig Jahren der UUID-Bereitstellung aufgetreten sind: die schlechte Datenbankleistung von Zufallsschlüsseln, das Datenschutzleck der Version 1 und der Wunsch nach sortierbaren Identifikatoren in Cloud-Systemen. Die Kernstruktur 128-Bit, die Varianten- und Versionsfelder sowie das Gesamtlayout bleiben jedoch erhalten.
Was dies nicht abdeckt – Implementierungsdetails jeder Version, die ihre eigenen Beiträge haben
Durch die Einführung von UUIDs als global eindeutige GUIDs im Komponentenobjektmodell durch Microsoft wurden diese ab den 1990er Jahren tief in Windows-Systeme integriert. GUID erschien in der Registrierung, in COM-Schnittstellen und in der ActiveDirectory-Infrastruktur. Microsoft hat eine geringfügige Variante hinzugefügt: Sie haben GUIDs für einige Komponenten in Little-Endian-Bytereihenfolge gespeichert und weichen damit vom Standard der Netzwerk-Bytereihenfolge ab. Diese Eigenart bleibt bei einigen Windows-APIs bestehen: Wenn Sie eine GUID aus Windows exportieren und in ein Unix-System importieren, können Probleme mit der Bytereihenfolge zu scheinbaren Nichtübereinstimmungen führen. Aber das Format selbst ist dasselbe und die Verwirrung ist eine Fußnote im Standard und kein grundlegender Unterschied. Der Stil mit geschweiften Klammern und Großbuchstaben {3FA85F64-5717-4562-B3FC-2C963F66AFA6} stammt aus Windows-Konventionen; andere Systeme bevorzugen Kleinbuchstaben und Bindestriche ohne geschweifte Klammern.
Imbiss: ein vierzig Jahre altes Design, das immer noch funktioniert – der ToolAcre-Generator erzeugt die zufälligen (Version 4) UUIDs, die RFC 9562 immer noch für Fälle definiert, in denen keine Bestellung erforderlich ist
Eine ausgearbeitete Zeitleiste zeigt die Langlebigkeit und Stabilität des Designs: Apollo NCS der 1980er Jahre erfindet das Konzept; 1992 OSFs DCE standardisiert das Layout; 2000er Jahre Microsoft bettet es in Windows ein; 2005 IETF veröffentlicht RFC 4122; 2024 IETF veröffentlicht RFC 9562 mit modernen Versionen. Das ist eine der längsten Standardisierungsbemühungen im Computerbereich, nicht wegen Streitigkeiten, sondern weil das ursprüngliche Design so robust und anpassungsfähig war. Es hat Wellen architektonischer Veränderungen – von verteilten NFS-Systemen zu Cloud-Datenbanken, von Windows COM zu mobilen Geräten, von 64-Bit-Maschinen der 1980er Jahre zu modernen Systemen – ohne grundlegende Neugestaltung bewältigt. Die praktische Auswirkung besteht darin, dass UUIDs allgegenwärtig und stabil sind. Wenn Sie mit dem ToolAcre-Generator einen UUID generieren, generieren Sie einen Identifikator, dessen Format in den 1980er Jahren etabliert, in 2005 international standardisiert und in 2024 mit bleibender Relevanz beibehalten wurde.