ufuid和rfuid区别（了解使用RFC标准如何生成UUID）

更多互联网新鲜资讯、工作奇淫技巧关注原创【飞鱼在浪屿】（日更新）

RFC 4122介绍了UUID的现代实现，引入了5种不同的方法来生成这些标识符。本文将逐一介绍一下，稍后将逐步介绍版本1和版本4的实现细节。

https://tools.ietf.org/html/rfc4122

---

背景

UUID（通用唯一IDentifiers）是一个128位数字，用于软件开发中标识唯一的项目。规范文本表示形式是一串32个十六进制字符，这些字符由中划线字符组成，形式为8-4-4-4-12。

例如，

3422b448-2460-4fd2-9183-8000de6f8343

这个看似随机的十六进制字符中的有关UUID实现的信息。

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

M和N位置中的值分别标识唯一UUID版本号和变体

---

版本号：

通过查看M位置值的最高4位来标识版本号。

下表列出了当前定义的版本：

---

变体

N的前1-3个最高有效位来识别变体。

如今，最常见的实现是变体1，其中MSB0固定为1，MSB1固定为0。这意味着，考虑到通配符值（x上面标记的位），唯一可能的值是8、9，A或B 。

快速提示：

1 0 0 0 = 8

1 0 0 1 = 9

1 0 1 0 = A

1 0 1 1 = B

因此，如果看到N位置带有这些值的UUID，它是常见的Variant 1类型。

---

版本1（基于时间 唯一或随机主机标识符）

在此版本中，UUID是通过获取当前时间戳和生成UUID的设备的某些标识属性（最常见的是MAC地址（也称为节点ID））生成的。

通过将48位MAC地址，60位时间戳和14位“唯一化”时钟序列，以及用于版本和变体的6个保留位进行级联以生成唯一的UUID，可以生成此UUID。

时钟序列只是每次修改时钟时都会增加的值。

此版本中使用的时间戳记是自1582年10月15日（公历改制为基督教历法之日）以来的100纳秒时间间隔数。

自大纪元以来，你可能熟悉Unix系统和时间。这只是第0天的不同之处网上有几种算法可将一个时间表示形式转换为另一个时间表示形式。

尽管此实现看起来相当简单和健壮，但由于它可以显示生成它的机器的MAC地址，因此该方法并不适合所有用例。特别是主要问题是安全时。取而代之的是，某些实现将使用来自加密安全随机数生成器的6个随机字节来代替节点ID。

要组装出版本1的UUID，将执行以下步骤：

1. 取当前UTC时间戳的低32位。这将是我们的UUID [TimeLow]的前4个字节/或8个十六进制字符
2. 取当前UTC时间戳的中间16位。这些将是接下来2个字节/或4个十六进制字符。[TimeMid]
3. 4位UUID版本和当前UTC时间戳的其余高12位（共60位），将合并成剩下的2个字节/或4个十六进制字符。[TimeHighAndVersion]
4. 接下来的1-3位将是UUID版本的变体。剩下的其余位包含时钟序列，该时钟序列（实际上是随机数）目的是为该实现提供少量的随机性。这样也可以避免在同一系统上UUID生成器的系统时钟不够快时发生冲突的情况。[ClockSequenceHiAndRes && ClockSequenceLow]
5. 最后的6个字节/或12个十六进制字符/或48位是“节点ID”，通常是设备的MAC地址。[NodeID]

将所有内容放在一起，版本1的UUID是通过以下串联生成的：

TimeLow TimeMid TimeHighAndVersion (ClockSequenceHiAndRes && ClockSequenceLow) NodeID

由于此实现依赖于时钟，因此需要处理一些边缘情况。首先，为了最小化系统之间的相关性，时钟序列默认设置为随机数-这只会在系统生命周期内发生一次。这具有额外的好处，因为时钟序列的初始值完全与节点标识符无关，因此可以支持可能在系统之间移动的节点标识符。

时钟序列的主要目的是在方程中引入一定程度的随机性。为时钟序列分配的位有助于扩展时间戳，并解决在同一处理器时钟生成多个UUID的情况。这避免在时钟倒退设置（设备关闭电源）或节点ID更改时可能产生重复。如果时钟是向后设置的，或者可能是向后设置的（例如，在系统关闭电源时），并且UUID生成器无法确定将来生成的UUID时间戳是否大于设置的时钟值，那么必须更改时钟序列。如果知道时钟序列的前一个值，则可以将其递增；

---

版本2（分布式计算环境安全性）

此版本与版本1之间的主要区别在于，此实现使用特定于系统的某些标识符来代替通过使用时钟序列的最低有效位生成的“随机性”。该值通常是当前用户的ID。此版本不那么常见，并且与版本1的偏差很小。

---

版本3（基于命名空间 MD5哈希）

如果想使用命名空间中的信息或更普遍的“可命名”信息拥有唯一的标识符，则首选UUID版本3和版本5。

任何“可命名”实体（网站，DNS信息，纯文本等）编码为UUID值。这里的主要要注意的是，对于相同的命名空间和文本，生成的UUID将相同。

请注意，命名空间本身是UUID。

let namespace = “digitalbunker.dev” let namespaceUUID = UUID3(.DNS, namespace) // Ex: UUID3(namespaceUUID, “/category/things-you-should-know-1/”) 4896c91b-9e61-3129-87b6-8aa299028058 UUID3(namespaceUUID, “/category/things-you-should-know-2/”) 29be0ee3-fe77-331e-a1bf-9494ec18c0ba UUID3(namespaceUUID, “/category/things-you-should-know-3/”) 33b06619-1ee7-3db5-827d-0dc85df1f759

在此实现中，命名空间的UUID转换为字节串，与输入名称连接在一起，然后用MD5散列，从而为UUID生成128位。然后，覆盖其中的某些位以准确反映版本和变体信息，而其余部分保持不变。

无论是名称空间还是输入的名称都不能从UUID逆向生成。这是单向操作。

对于版本3和版本5，只要使用相同的输入，生成的UUID将是确定性的。

---

版本4（PRNG伪随机）

这可能是最简单的实现。

版本和变体信息保留了6位，然后可以自由决定122位。此版本仅生成所有128个随机位，然后作为第二步骤填写版本和变体信息的值。

这种类型的UUID严重依赖于所用PRNG（伪随机数生成器）算法的质量。如果PRNG缺少复杂的算法或正确的种子和初始化值，则重复的可能性会增加。

第4版是现代编程语言中最常实现的版本。

它的实现相当简单。

1. 产生128个随机位
2. 使用版本和变体信息覆盖其中的某些位。取第7个字节，然后和0x0F进行AND操作以清除高半字节。然后，将其与0x40设置版本号为4。 接下来，取第9个字节，和0x3F进行与运算，或和0x80进行或运输。
3. 将128位转换为十六进制表示，并插入中划线字符以实现规范的文本表示。

---

版本5（基于名称 SHA-1哈希）

此版本与版本3相同，不同之处在于，SHA-1此处使用哈希算法代替MD5。此版本优于版本3（SHA-1> MD5）。

---

在实践中

UUID的显着优势之一是其唯一性不取决于中央机构或不同系统之间的协调。任何人都可以创建UUID，并有合理保证确保不存在重复值，并且可以想象将来不会重复。

这具有额外的好处，即允许将生成的独立UUID写入到单个数据库中，或以很小的重复/冲突概率跨数据库移动。

由于这种唯一性，可以将UUID用作数据库中的主键，将UUID用作上传文件的唯一文件名，对于任何Web资源都使用唯一名称，或者允许供应商创建和注册UUID而不需要中央权限。但是，这是一把双刃剑。由于缺乏中央权威，因此也无法跟踪以前发布的UUID。

还有一些缺点可以解决。尽管这种固有的随机性有助于提高安全性，但它会使调试等问题变得复杂。此外，在某些情况下，UUID可能会占用空间过大。例如，使用128位唯一地标识一些本身可能小于128位的数据是没有意义的。

---

独特性

查看这些实现，似乎有足够的时间，最终会重复一个值。特别是在版本4的情况下，它依赖于随机数。但是，在实践中，为了获得重复的UUID，需要生成的数量和频率是相当大的。

如果在接下来的100年中每秒产生10亿个UUID，假设用于生成UUID的PRNG将足够的熵（“实际随机性”），否则重复计数的可能性会更高。在稍微实际的示例中，如果要生成10,000,000,000,000 [10万亿]个UUID，则两个UUID相同的机会为0.00000006％。

在第1版的情况下，时钟只能在公元3603年翻转。因此，除非打算将服务再运行1,583年，否则在也很安全。

重复的可能性仍然存在，某些系统确实设法解决了这一问题，但是对于绝大多数用例，UUID可以被视为真正唯一。

---

,