Outils de développement · Générateur UUID
D'Apollo NCS à RFC 9562 : une brève histoire du UUID
· Contexte
uuid cryptographie API du navigateur
L'étrange disposition 8-4-4-4-12 et la taille 128 bits sont héritées de l'informatique distribuée des années 1980. Cet article retrace le UUID du système informatique de réseau d'Apollo via DCE, le GUID de Microsoft et deux normes IETF.
Pourquoi 128 bits et pourquoi ces tirets ? — les questions posées par chaque nouvel arrivant et les réponses de l'histoire
Le format avec trait d'union 8-4-4-4-12 et la taille 128 bits d'un UUID sont des choix de conception que les historiens remettent immédiatement en question. Pourquoi pas 96 bits pour des calculs plus faciles ? Pourquoi cette disposition spécifique des segments ? Pourquoi base-16 avec des tirets au lieu de base-64 ou un encodage plus simple ? Les réponses se trouvent dans le système informatique de réseau Apollo du début des années 1980, une plate-forme informatique distribuée confrontée à un véritable problème : les systèmes d'un réseau devaient attribuer des identifiants uniques sans autorité centrale, et ces identifiants devaient être globalement uniques avec une probabilité écrasante. Apollo NCS a résolu ce problème en combinant un horodatage, une adresse réseau et une séquence d'horloge dans un identifiant 128 bits qui pouvait être généré indépendamment par n'importe quelle machine.
Apollo Network Computing System — l'origine dans les années 1980 d'identifiants uniques construits à partir du temps et d'une adresse réseau
La norme actuelle enregistre une lignée d'Apollo NCS via l'environnement informatique distribué OSF et les plates-formes Microsoft ultérieures. Cette histoire explique pourquoi les systèmes modernes partagent une famille reconnaissable 128-bit tout en préservant les marqueurs de variantes pour les anciennes mises en page. Elle n'établit pas de garantie absolue d'unicité : chaque version possède ses propres règles de génération et modes de défaillance. La réalisation durable est l’interopérabilité sans service central d’enregistrement. Un navigateur, une base de données et un système d'exploitation peuvent échanger la même forme hexadécimale canonique, inspecter ses champs de variante et de version et décider si la recette productrice correspond aux besoins du système récepteur.
OSF DCE et le champ de variante – comment l'environnement informatique distribué a formalisé la disposition et ajouté les bits de variante
La mise en page prend en charge plusieurs stratégies de génération via des champs de version et de variante intégrés dès le début de la conception. La génération basée sur le temps, la génération aléatoire et la génération basée sur le nom peuvent toutes coexister dans le même espace d'identifiant. Les applications modernes ont des exigences différentes de celles des NCS des années 1980 (bases de données qui veulent des clés triables, systèmes cloud qui veulent de la confidentialité, systèmes distribués qui veulent une résistance aux collisions), mais la même structure 128-bit les prend toujours en charge. Les versions 6 et 7 qui ont été ajoutées dans la RFC 9562 dans 2024 prouvent que les concepteurs d'origine ont laissé de la place pour une évolution future sans rompre la compatibilité ascendante.
GUID de Microsoft — COM, le registre et le style accolades et majuscules qui persiste aujourd'hui
Le système informatique de réseau Apollo était une plate-forme informatique distribuée qui fonctionnait sur les postes de travail Apollo Computer dans les années 1980. Il s'appuyait sur des identifiants uniques au monde pour les appels de procédures à distance, la réplication des données et les services de dénomination. Les nœuds du réseau n'avaient aucun moyen de coordonner l'attribution des identifiants car vous ne pouviez pas contacter un serveur central si le réseau risquait d'être partitionné ou déconnecté. Les concepteurs d'Apollo ont donc créé un format 128 bits combinant un horodatage 60 bits, un identifiant de nœud généralement dérivé de l'adresse MAC de la carte réseau 48 bits et une séquence d'horloge 14 bits pour gérer les changements d'horloge. Cette approche permet aux nœuds de générer des identifiants indépendamment en combinant l'heure, une séquence d'horloge et un champ de nœud ; son comportement dépendait toujours des horloges et de la sélection des nœuds.
RFC 4122 (2005) — la norme IETF qui définit les versions 1 à 5 et l'espace de noms URN, aligné sur ITU-T X.667
Lorsque l'OSF a ensuite standardisé cela pour son environnement informatique distribué autour de 1992, ils ont conservé la même présentation et ont ajouté le champ de variante pour distinguer les différents types UUID. La conception a déjà fait ses preuves dans les systèmes de production. L'IETF a normalisé la RFC 4122 dans 2005, près de vingt ans après Apollo NCS et environ treize ans après la normalisation DCE. RFC 4122 versions codifiées 1 à 5 : version 1 pour la génération basée sur le temps, version 3 pour la génération basée sur le nom avec MD5, version 4 pour la génération aléatoire et version 5 pour la génération basée sur le nom avec SHA-1. La norme était stable et largement adoptée car elle était déjà omniprésente dans Microsoft Windows, l'infrastructure DNS et les systèmes distribués. Au moment où la RFC 4122 a été publiée, la UUID était déjà tellement intégrée dans l'infrastructure que la normalisation était presque académique.
RFC 9562 (2024) — la révision qui a rendu obsolète la RFC 4122, a ajouté les versions 6, 7 et 8 et a écrit des conseils modernes sur le caractère aléatoire
Dans 2024, l'IETF a publié la RFC 9562, qui rend obsolète la RFC 4122 et ajoute les versions 6, 7 et 8. La version 6 réorganise les champs temporels de la version 1 pour une meilleure localité et une meilleure triabilité des arbres B. La version 7 utilise un horodatage Unix moderne et familier au lieu du décompte basé sur 1582, améliorant ainsi la possibilité de tri et répondant aux exigences des bases de données modernes. La version 8 réserve de l'espace pour les implémentations personnalisées et les conceptions expérimentales UUID. Les nouvelles versions répondent à des problèmes apparus au cours de quarante années de déploiement de UUID : les mauvaises performances de la base de données des clés aléatoires, la fuite de confidentialité de la version 1 et le désir d'identifiants triables dans les systèmes cloud. Pourtant, la structure principale 128-bit, les champs de variante et de version ainsi que la présentation générale restent intacts.
Ce que cela ne couvre pas : détails d'implémentation de chaque version, qui ont leurs propres publications
L'adoption par Microsoft des UUID en tant qu'identifiants uniques au monde dans le modèle d'objet de composant les a profondément intégrés dans les systèmes Windows à partir des années 1990. Le GUID est apparu dans le registre, dans les interfaces COM et dans l'infrastructure ActiveDirectory. Microsoft a ajouté une variante mineure : ils ont stocké les GUID dans l'ordre des octets petit-boutiste pour certains composants, s'écartant de la norme d'ordre des octets du réseau. Cette bizarrerie persiste dans certaines API Windows : si vous exportez un GUID depuis Windows et l'importez vers un système Unix, des problèmes d'ordre des octets peuvent provoquer des incohérences apparentes. Mais le format lui-même est le même, et la confusion est une note de bas de page dans la norme, et non une différence fondamentale. Le style accolades et majuscules {3FA85F64-5717-4562-B3FC-2C963F66AFA6} provient des conventions Windows ; d'autres systèmes préfèrent les minuscules et les traits d'union sans accolades.
À retenir : une conception vieille de quarante ans qui fonctionne toujours – le générateur ToolAcre produit les UUID aléatoires (version 4) que la RFC 9562 définit toujours pour les cas où la commande n'est pas nécessaire.
Une chronologie travaillée montre la longévité et la stabilité de la conception : années 1980, Apollo NCS invente le concept ; 1992 Le DCE d'OSF standardise la mise en page ; Années 2000, Microsoft l'intègre dans Windows ; 2005 L'IETF publie la RFC 4122 ; 2024 L'IETF publie la RFC 9562 avec des versions modernes. Il s’agit de l’un des efforts de normalisation les plus longs dans le domaine informatique, non pas à cause de différends, mais parce que la conception originale était si robuste et adaptable. Il a su s'adapter à des vagues de changements architecturaux, des systèmes NFS distribués aux bases de données cloud, de Windows COM aux appareils mobiles, des machines 64 bits des années 1980 aux systèmes modernes, sans refonte fondamentale. L'impact pratique est que les UUID sont omniprésents et stables ; lorsque vous générez un UUID avec le générateur ToolAcre, vous générez un identifiant dont le format a été établi dans les années 1980, standardisé au niveau international dans 2005 et maintenu dans 2024 avec une pertinence durable.