UUID

Один из вариантов, определенных в RFC 4122, вариант 0 (обозначается одним битом 0xxx₂, N = 0..7), присутствует ради обратной совместимости с устаревшим форматом UUID Apollo Network Computing System 1.5, разработанным примерно в 1988 году. В этом формате первые 6 октетов UUID представляют собой 48-битную метку времени (количество единиц времени в 4 микросекунды, прошедших с 1 января 1980 года UTC); следующие 2 октета зарезервированы; следующий октет — это «address family»; последние 7 октетов являются 56-битным идентификатором хоста в форме, определенной address family. Несмотря на различие в деталях, можно видеть сходство с современным UUID версии 1. Биты варианта в текущей спецификации UUID совпадают с старшими битами октета семейства адресов в UUID NCS. Хотя семейство адресов может содержать значения в диапазоне 0..255, были определены только значения 0..13. Таким образом, обозначение варианта 0 как 0xxx позволяет избежать конфликтов с историческими UUID NCS, если они всё ещё существуют в базах данных.

Эти варианты используются в текущих спецификациях UUID. Вариант 1 (обозначается двумя битами 10xx₂ N = 8..b) является основным и описан в RFC 4122. Вариант 2 (обозначается тремя битами 110x₂ N = c..d) описан в RFC как зарезервированный для обратной совместимости с ранними GUID из Microsoft Windows.

Помимо битов, обозначающих вариант, во всём остальном эти два варианта UUID одинаковы, за исключением того, что при кодировании в бинарную форму для хранения или передачи UUID варианта 1 используют сетевой порядок байтов (big-endian), а GUID варианта 2 используют «нативный» (little-endian) порядок байтов. В каноническом текстовом представлении варианты 1 и 2 одинаковы, за исключением битов вариантов.

Хотя некоторые важные идентификаторы GUID, такие как идентификатор интерфейса IUnknown для COM, являются UUID варианта 2, многие идентификаторы, созданные и используемые в ПО Microsoft Windows и называемые «GUID», по факту являются стандартными UUID варианта 1 с сетевым порядком байтов. Текущая версия утилиты Microsoft guidgen создает стандартные UUID варианта 1. В некоторой документации Microsoft говорится, что «GUID» является синонимом «UUID»,[1] как это стандартизировано в RFC 4122. Сам RFC 4122 утверждает, что UUID также известны как GUID («are also known as GUIDs»). Все это говорит о том, что «GUID», хоть и был изначально отдельным вариантом UUID, используемым в Microsoft, сейчас стал просто альтернативным названием для стандартного UUID.

В RFC 4122 вариант 111x₂ (N = e..f) зарезервирован для использования в будущем.

Особый случай, в котором все биты UUID выставлены в ноль: 00000000-0000-0000-0000-000000000000.

Версия 1 включает в себя 48-битный MAC-адрес узла («node»), на котором сгенерирован UUID, и 60-битную метку времени (timestamp), которая обозначает число 100-наносекундных интервалов, прошедших с полуночи 15 октября 1582 года по UTC — даты начала применения григорианского календаря. RFC 4122 указывает максимально возможное время около 3400 года н. э., и это означает, что 60-битная метка времени является знаковой. Однако некоторые программы, например библиотека libuuid, считают timestamp беззнаковым[2], и для них максимальным временем является примерно 5236 год н. э.

13- или 14-битный clock sequence дополняет метку времени в случаях, когда системные часы обновляются недостаточно быстро, или на многопроцессорных системах. В таких случаях метка времени у разных UUID может оказаться одинаковой. Чтобы избежать генерации одинаковых UUID, используют clock sequence, который обновляется каждый раз при создании нового UUID и который будет разным у разных UUID даже при совпадении меток времени. Поскольку UUID версии 1 соответствует одной точке в пространстве (узел) и времени (метка времени и clock sequence), вероятность совпадения двух правильно сгенерированных UUID практически равна нулю. Поскольку метка времени и clock sequence вместе составляют 74 бита, всего может быть сгенерировано 2⁷⁴ (1.8⋅10²², или 18 секстиллионов) уникальных UUID версии 1 на одном узле с максимальной средней скоростью 163 миллиарда UUID в секунду.

В отличие от других версий UUID, уникальность UUID версий 1 и 2, основанных на MAC-адресах сетевых карт, частично зависит от идентификатора, выданного центральным регистрирующим органом, а именно от части уникального идентификатора организации (OUI) MAC-адреса, который выдаётся в IEEE производителям сетевого оборудования.[3] Уникальность также зависит от правильного назначения уникальных MAC-адресов сетевых карт производителями, что, как и другие производственные процессы, подвержено ошибкам.

Использование MAC-адреса означает, что всегда можно отследить компьютер, который создал UUID. Иногда возможно найти компьютер, на котором был создан или отредактирован какой-либо документ, если используемый текстовый процессор встроил UUID в файл. Эта дыра в конфиденциальности использовалась для поиска автора вируса Melissa.[4]

RFC 4122 резервирует версию 2 «DCE security», но не предоставляет никаких подробностей о ней. По этой причине во многих реализациях UUID версия 2 отсутствует. Однако описание UUID версии 2 есть в спецификации DCE 1.1 Authentication and Security Services.[5]

Версия 2 похожа на версию 1, но младшие 8 бит clock sequence заменены на номер «локального домена» («local domain» number), а младшие 32 бита метки времени (timestamp) заменены целочисленным идентификатором, значимым в пределах указанного локального домена.

Возможность включить 40-битный домен/идентификатор является компромиссом. С одной стороны, 40 битов допускают около 1 триллиона значений доменов/идентификаторов для одного узла. С другой стороны, с урезанным значением метки времени до 28 старших значащих бит по сравнению с 60 битами в версии 1 время в UUID версии 2 будет «тикать» лишь раз в 429,49 секунды (чуть больше 7 минут) в отличие от 100 наносекунд в версии 1. И с шестибитным clock sequence, в отличие от 14 бит в версии 1, могут быть сгенерированы лишь 64 уникальных UUID для одного узла/домена/идентификатора в течение этих 7 минут. Таким образом UUID версии 2 не подходит, если требуется генерировать UUID чаще чем раз в 7 минут.

UUID версий 3 и 5 образуются путём хеширования идентификатора пространства имён и имени. Версия 3 использует алгоритм хеширования MD5, версия 5 — SHA-1.

Спецификация предоставляет UUID для представления пространств имён URL, FQDN, OID и отличительных имён X.500, но любой желаемый UUID может использоваться в качестве идентификатора пространства имен.

Для вычисления UUID версии 3, соответствующего данному пространству имен и имени, UUID пространства имен преобразуется в байтовую, конкатенируется с именем и хешируется алгоритмом MD5, что дает 128 битов. Затем 6 или 7 битов заменяются фиксированными значениями: 4-битной версией (например, 0011₂ для версии 3) и 2- или 3-битным вариантом («variant») UUID (например, 10₂, обозначающим RFC 4122 UUID, или 110₂, обозначающим legacy Microsoft GUID). Поскольку 6 или 7 битов таким образом предопределены, лишь 121 или 122 бита вносят вклад в уникальность UUID.

UUID версии 5 похож, но использует SHA-1 вместо MD5. Так как SHA-1 даёт 160-битный хеш, он предварительно обрезается до 128 бит.

Суть UUID версий 3 и 5 в том, что одна и та же пара из пространства имён и имени будет отображаться в один и тот же UUID. При этом ни пространство имён, ни имя не могут быть обратно получены из UUID, кроме как методом перебора.

RFC 4122 рекомендует использовать версию 5 вместо версии 3 и не рекомендует использовать ни одну из этих версий в качестве учетных данных для безопасности.

UUID версии 4 генерируется случайным образом. Как и в других версиях UUID, 4 бита используются для указания версии, 2 или 3 бита указывают на вариант. Так что для варианта 1 (который используется большинством UUID) на случайно сгенерированную часть приходится 122 бита, что даёт 2¹²², или 5.3⋅10³⁶ (5.3 ундециллиона) возможных вариантов UUID версии 4 варианта 1. UUID версии 4 варианта 2 имеет вдвое меньше возможных вариантов, так как ещё один бит используется для обозначения варианта.