开发者工具 · UUID 生成器
从 Apollo NCS 到 RFC 9562：UUID 的简史
· 背景
uuid 密码学 浏览器 API
奇数 8-4-4-4-12 布局和 128 位大小继承自 1980 年代的分布式计算。这篇文章通过 DCE、Microsoft 的 GUID 和两个 IETF 标准追踪来自 Apollo 网络计算系统的 UUID。
为什么是 128 位以及为什么是那些连字符？ ——每个新人都会提出的问题和历史的答案
8-4-4-4-12 连字符格式和 UUID 的 128 位大小是历史学家立即质疑的设计选择。为什么不使用 96 位来简化数学运算？为什么要采用特定的分段布局？为什么使用带有连字符的 base-16 而不是 base-64 或更简单的编码？答案在于 20 世纪 80 年代初的阿波罗网络计算系统，这是一个分布式计算平台，它面临着一个真正的问题：网络中的系统需要在没有中央权威的情况下分配唯一标识符，并且这些标识符必须以压倒性的概率在全球范围内唯一。 Apollo NCS 通过将时间戳、网络地址和时钟序列组合成 128 位标识符来解决这个问题，该标识符可以由任何机器独立生成。
Apollo 网络计算系统 — 20 世纪 80 年代根据时间和网络地址构建的唯一标识符的起源
当前标准记录了从 Apollo NCS 到 OSF 分布式计算环境以及后来的 Microsoft 平台的沿袭。这段历史解释了为什么现代系统共享可识别的 128 位系列，同时保留旧布局的变体标记。它没有建立绝对的唯一性保证：每个版本都有自己的生成规则和故障模式。持久的成就是无需中央注册服务的互操作性。浏览器、数据库和操作系统可以交换相同的规范十六进制形式，检查其变体和版本字段，并确定生产配方是否适合接收系统的需求。
OSF DCE 和变体字段 — 分布式计算环境如何形式化布局并添加变体位
布局通过从设计一开始就嵌入的版本和变体字段来适应多种生成策略。基于时间的生成、随机生成和基于名称的生成都可以共存于同一标识符空间中。现代应用程序与 20 世纪 80 年代的 NCS 有着不同的要求——数据库需要可排序的密钥、云系统需要隐私、分布式系统需要防碰撞——但相同的 128 位结构仍然可以满足它们。在 2024 的 RFC 9562 中添加的版本 6 和 7 证明原始设计者在不破坏向后兼容性的情况下为未来的演进留下了空间。
Microsoft 的 GUID — COM、注册表以及至今仍然存在的大括号和大写样式
Apollo 网络计算系统是 20 世纪 80 年代在 Apollo 计算机工作站上运行的分布式计算平台。它依赖于远程过程调用、数据复制和命名服务的全局唯一标识符。网络中的节点无法协调 ID 分配，因为如果网络可能分区或断开连接，您将无法联系中央服务器。因此，Apollo 设计者创建了一种 128 位格式，结合了时间戳 60 位、通常源自网卡 MAC 地址 48 位的节点标识符以及用于处理时钟更改的时钟序列 14 位。这种方法让节点通过组合时间、时钟序列和节点字段来独立生成标识符；它的行为仍然取决于时钟和节点选择。
RFC 4122 (2005) — 定义版本 1 到 5 和 URN 命名空间的 IETF 标准，与 ITU-T X.667 保持一致
当 OSF 后来围绕 1992 对其分布式计算环境进行标准化时，他们保留了相同的布局并添加了变体字段以区分不同的 UUID 类型。该设计已在生产系统中得到验证。 IETF 在 2005 中对 RFC 4122 进行标准化，距 Apollo NCS 近二十年，距 DCE 标准化约十三年。 RFC 4122 编码版本 1 到 5：版本 1 用于基于时间的生成，版本 3 用于基于名称的 MD5，版本 4 用于随机，版本 5 用于基于名称的 MD5 SHA-1。该标准非常稳定并被广泛采用，因为它在 Microsoft Windows、DNS 基础设施和分布式系统中已经无处不在。当 RFC 4122 发布时，UUID 已经深深嵌入基础设施中，以至于标准化几乎是学术性的。
RFC 9562 (2024) — 该修订版废弃了 RFC 4122，添加了版本 6、7 和 8，并写下了有关随机性的现代建议
在 2024 中，IETF 发布了 RFC 9562，它废弃了 RFC 4122 并添加了版本 6、7 和 8。版本 6 对版本 1 的时间字段重新排序，以获得更好的 B 树局部性和可排序性。版本 7 使用现代且熟悉的 Unix 时间戳，而不是基于 1582 的计数，提高可排序性并满足现代数据库要求。版本 8 为自定义实现和实验性 UUID 设计保留空间。新版本解决了 UUID 部署四十年来出现的问题：随机密钥的数据库性能不佳、版本 1 的隐私泄漏以及云系统中对可排序标识符的需求。然而，核心 128 位结构、变体和版本字段以及整体布局保持不变。
这不包括什么 - 每个版本的实现细节，都有自己的帖子
从 20 世纪 90 年代开始，Microsoft 在组件对象模型中采用 UUID 作为 GUID 全局唯一标识符，并将其深深嵌入到 Windows 系统中。 GUID 出现在注册表、COM 接口和 ActiveDirectory 基础结构中。 Microsoft 添加了一个细微的变化：他们以小端字节顺序存储某些组件的 GUID，这与网络字节顺序标准不同。这种怪癖在某些 Windows API 中仍然存在：如果从 Windows 导出 GUID 并将其导入 Unix 系统，字节顺序问题可能会导致明显的不匹配。但格式本身是一样的，混乱只是标准中的一个脚注，并不是根本的区别。大括号和大写样式 {3FA85F64-5717-4562-B3FC-2C963F66AFA6} 来自 Windows 约定；其他系统更喜欢小写字母和不带大括号的连字符。
要点：四十年的设计仍然有效 - ToolAcre 生成器生成随机（版本 4）UUID，RFC 9562 仍然为不需要排序的情况定义这些 UUID
有效的时间表显示了设计的长久性和稳定性：20 世纪 80 年代 Apollo NCS 发明了这个概念； 1992 OSF 的 DCE 标准化了布局； 2000年代微软将其嵌入Windows； 2005 IETF 发布 RFC 4122； 2024 IETF 发布了具有现代版本的 RFC 9562。这是计算领域最长的标准化工作之一，不是因为争议，而是因为最初的设计是如此强大和适应性强。它适应了架构变革的浪潮——从分布式 NFS 系统到云数据库，从 Windows COM 到移动设备，从 20 世纪 80 年代的 64 位机器到现代系统，而无需进行根本性的重新设计。实际影响是 UUID 无处不在且稳定；当您使用 ToolAcre 生成器生成 UUID 时，您将生成一个标识符，其格式建立于 20 世纪 80 年代，在 2005 中进行国际标准化，并在 2024 中维护，具有持久的相关性。