RFC 4122

RFC 4122 — это спецификация (Request for Comments), определяющая универсальные уникальные идентификаторы (UUID, Universally Unique Identifier), а также их подмножество — глобально уникальные идентификаторы (GUID, Globally Unique Identifier). RFC 4122 был опубликован в июле 2005 года в статусе «Предложенный стандарт» (Proposed Standard) и является действующим стандартом Интернета (Internet Standard 103). Он описывает структуру, формат представления, алгоритмы генерации и правила использования UUID, которые обеспечивают уникальность идентификаторов без необходимости централизованного управления.

История

Потребность в уникальных идентификаторах, не требующих централизованного реестра, возникла в 1980-х годах в связи с развитием распределённых вычислительных систем. Первым известным аналогом была система Apollo Domain/UUID, разработанная компанией Apollo Computer (позднее поглощена Hewlett-Packard). В 1990-х годах корпорация Microsoft внедрила GUID в свою операционную систему Windows (OLE/COM), что способствовало широкому распространению концепции.

В 1998 году была опубликована спецификация UUID версии 1, основанная на времени и MAC-адресе, в рамках проекта Open Software Foundation (OSF) для распределённой вычислительной среды (DCE). Дальнейшее развитие привело к созданию RFC 4122, который обобщил существующие практики, ввёл новые версии (2, 3, 4, 5) и стандартизировал представление UUID в виде текстовой строки. Авторами документа выступили Пол Дж. Лейч (Paul J. Leach), Майкл Мис (Michael Mealling) и Ричард Сэлз (Richard Salz).

Структура UUID

UUID представляет собой 128-битное (16-байтное) число. В каноническом текстовом представлении он записывается в виде 32 шестнадцатеричных цифр, разделённых четырьмя дефисами на пять групп: 8-4-4-4-12. Например: 550e8400-e29b-41d4-a716-446655440000.

Биты внутри UUID структурированы следующим образом:

• Поле времени (time_low) — 32 бита (4 байта), младшие 32 бита временной метки (для версий 1 и 2).
• Поле времени (time_mid) — 16 бит (2 байта), средние 16 бит временной метки.
• Версия (version) — 4 бита, указывают версию UUID (1, 2, 3, 4 или 5). Располагаются в старших 4 битах поля time_hi_and_version.
• Поле времени (time_hi_and_version) — 12 бит (1,5 байта), старшие 12 бит временной метки (для версий 1 и 2).
• Вариант (variant) — 2-3 бита, указывают на вариант схемы UUID. Большинство современных UUID используют вариант RFC 4122 (битовая последовательность 10xx).
• Поле clock_seq_hi_and_reserved — 6 бит (0,75 байта), старшие 6 бит последовательности часов.
• Поле clock_seq_low — 8 бит (1 байт), младшие 8 бит последовательности часов.
• Узел (node) — 48 бит (6 байт), MAC-адрес сетевого интерфейса (для версий 1 и 2) или случайное/хэшированное значение.

Версии UUID

RFC 4122 определяет пять версий UUID, каждая из которых использует свой алгоритм генерации.

UUID версии 1 (на основе времени и MAC-адреса)

Генерируется на основе текущего времени (100-наносекундные интервалы, начиная с 15 октября 1582 года) и MAC-адреса сетевого интерфейса. Обеспечивает высокую степень уникальности, но раскрывает время создания и MAC-адрес узла, что может быть нежелательно с точки зрения безопасности. Для компенсации ухода времени вперёд используется последовательность часов (clock sequence), которая увеличивается при обнаружении одинаковых временных меток.

UUID версии 2 (DCE Security)

Является расширением версии 1, предназначенным для использования в распределённой вычислительной среде DCE. Вместо MAC-адреса в поле узла может использоваться идентификатор локального домена (например, UID или GID в POSIX-системах). На практике применяется редко.

UUID версии 3 (на основе MD5-хэша)

Генерируется путём хэширования пространства имён (namespace) и имени (name) с помощью алгоритма MD5. Для одного и того же пространства имён и имени всегда даёт один и тот же UUID. Используется для создания детерминированных идентификаторов. Пространства имён определяются UUID-константами (например, DNS, URL, OID, X.500).

UUID версии 4 (случайный)

Генерируется с использованием криптостойкого генератора псевдослучайных чисел. 122 бита из 128 являются случайными (6 бит зарезервированы для версии и варианта). Обеспечивает хорошую уникальность и не раскрывает никакой информации о создателе. Является наиболее распространённой версией UUID в современных приложениях.

UUID версии 5 (на основе SHA-1 хэша)

Аналогичен версии 3, но использует алгоритм SHA-1 вместо MD5. Считается более криптостойким. Также детерминирован.

Применение

UUID широко применяются в информационных системах для идентификации объектов, когда требуется уникальность без централизованного управления. Основные области использования:

• Базы данных: UUID используются в качестве первичных ключей, особенно в распределённых базах данных (например, Cassandra, CockroachDB, PostgreSQL с расширением uuid-ossp). Они позволяют объединять данные из разных источников без конфликтов.
• Распределённые системы: В микросервисной архитектуре, системах управления версиями (Git — объекты идентифицируются SHA-1 хэшами, концептуально близкими к UUID), системах очередей сообщений.
• Веб-технологии: Идентификаторы сессий, токены, идентификаторы ресурсов (URL, URI). Например, UUID используются в спецификации URN (Uniform Resource Name) как urn:uuid:.
• Операционные системы: GUID в Windows используются для идентификации COM-объектов, интерфейсов, реестра, установленных приложений. В Linux UUID используются для идентификации файловых систем (например, в /etc/fstab).
• Программное обеспечение: Идентификаторы пакетов, библиотек, версий. Например, в Java UUID представлен классом java.util.UUID.

Критика и ограничения

Несмотря на широкое распространение, UUID имеют ряд недостатков:

• Размер: 128 бит (16 байт) занимают больше места, чем 32-битные или 64-битные целые числа, что может снижать производительность в базах данных при использовании в качестве первичного ключа (особенно в кластеризованных индексах).
• Случайность: UUID версии 4 не гарантируют монотонного возрастания, что может приводить к фрагментации индексов в B-деревьях.
• Предсказуемость: UUID версии 1 могут быть предсказаны, если известен MAC-адрес и временная метка, что создаёт риски для безопасности.
• Коллизии: Хотя вероятность коллизии UUID версии 4 чрезвычайно мала (около 2^122), теоретически она не равна нулю. Для критически важных систем (например, финансовых) может потребоваться дополнительная проверка уникальности.

Альтернативы

Существуют альтернативные форматы идентификаторов, решающие некоторые недостатки UUID:

• ULID (Universally Unique Lexicographically Sortable Identifier): 128-битный идентификатор, сочетающий временную метку и случайную часть, сортируемый по времени.
• Snowflake ID: 64-битный идентификатор, используемый в Twitter (X), основанный на времени, идентификаторе узла и последовательности.
• NanoID: более короткий (21 символ) и настраиваемый идентификатор, использующий случайные символы из алфавита.
• CUID (Collision-resistant Unique Identifier): идентификатор, устойчивый к коллизиям, с дополнительной проверкой.

Источники

1. Leach, P. J., Mealling, M., & Salz, R. (2005). A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122. Internet Engineering Task Force (IETF).
2. ITU-T Recommendation X.667 (2004) | ISO/IEC 9834-8:2005. Information technology — Open Systems Interconnection — Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components.
3. The Open Group. (1997). DCE 1.1: Remote Procedure Call. Document C706.
4. Microsoft Corporation. (2001). GUID Structure. Windows Platform SDK Documentation.
5. PostgreSQL Global Development Group. (2023). PostgreSQL 16 Documentation: UUID Type.