Универсальный уникальный идентификатор - Universally unique identifier

UUID / GUID, используемый переменными UEFI

Универсальный уникальный идентификатор ( UUID ) представляет собой 128-битный этикетка используется для информации в компьютерных системах. Термин глобальный уникальный идентификатор ( GUID ) также используется, часто в программном обеспечении, созданном Microsoft .

При генерации стандартными методами UUID для практических целей уникальны. Их уникальность не зависит от центрального регистрирующего органа или координации между сторонами, их генерирующими, в отличие от большинства других схем нумерации. Хотя вероятность того, что UUID будет дублироваться, не равна нулю, она достаточно близка к нулю, чтобы ею можно было пренебречь.

Таким образом, любой может создать UUID и использовать его для идентификации чего-либо с почти уверенностью, что идентификатор не дублирует идентификатор, который уже был или будет создан для идентификации чего-то еще. Информация, помеченная UUID независимыми сторонами, может быть позже объединена в единую базу данных или передана по тому же каналу с незначительной вероятностью дублирования.

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

История

В 1980-х годах Apollo Computer первоначально использовала UUID в сетевой вычислительной системе (NCS), а затем в распределенной вычислительной среде (DCE) Open Software Foundation (OSF ). Первоначальный дизайн DCE UUID был основан на NCS UUID, дизайн которого, в свою очередь, был вдохновлен ( 64-битными ) уникальными идентификаторами, определенными и широко используемыми в Domain / OS , операционной системе, разработанной Apollo Computer. Позже платформы Microsoft Windows приняли дизайн DCE как «глобальные уникальные идентификаторы» (GUID). RFC 4122 зарегистрировал пространство имен URN для UUID и резюмировал более ранние спецификации с тем же техническим содержанием. Когда в июле 2005 года RFC 4122 был опубликован в качестве предлагаемого стандарта IETF , ITU также стандартизировал UUID на основе предыдущих стандартов и ранних версий RFC 4122.

Стандарты

UUID стандартизированы Open Software Foundation (OSF) как часть распределенной вычислительной среды (DCE).

UUID задокументированы как часть ISO / IEC 11578: 1996 « Информационные технологии  - Взаимодействие открытых систем - Удаленный вызов процедур (RPC)», а недавно - в Рек. МСЭ-Т Rec. X.667 | ИСО / МЭК 9834-8: 2005.

Engineering Task Force Интернет (IETF) опубликовала стандарты-Track RFC 4122, технически эквивалент ITU-T Rec. X.667 | ИСО / МЭК 9834-8.

Формат

В каноническом текстовом представлении 16 октетов UUID представлены в виде 32 шестнадцатеричных (base-16) цифр, отображаемых в пяти группах, разделенных дефисами, в форме 8-4-4-4-12, всего 36 символов. (32 шестнадцатеричных символа и 4 дефиса). Например:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Четырехбитовые поля M и 1-3-битные поля N кодируют формат самого UUID.

Четыре бита цифры M- это версия UUID, а от 1 до 3 наиболее значимых битов цифрового Nкода - вариант UUID. (См. Ниже. ) В этом примере M равно 1, а N равно a(10xx 2 ), что означает, что это UUID версии 1, варианта 1; то есть основанный на времени UUID DCE / RFC 4122.

Строка канонического формата 8-4-4-4-12 основана на структуре записи для 16 байтов UUID:

Макет записи UUID
Имя Длина (байты) Длина (шестнадцатеричные цифры) Длина (бит) СОДЕРЖАНИЕ
time_low 4 8 32 целое число, дающее младшие 32 бита времени
time_mid 2 4 16 целое число, дающее средние 16 бит времени
time_hi_and_version 2 4 16 4-битная «версия» в старших разрядах, за которыми следуют старшие 12 бит времени
clock_seq_hi_and_res clock_seq_low 2 4 16 1–3-разрядный «вариант» в наиболее значимых битах, за которым следует 13–15-разрядная тактовая последовательность.
узел 6 12 48 48-битный идентификатор узла

Эти поля соответствуют полям UUID версий 1 и 2 (то есть UUID на основе времени), но одно и то же представление 8-4-4-4-12 используется для всех UUID, даже для UUID, построенных по-разному.

RFC 4122 Раздел 3 требует, чтобы символы создавались в нижнем регистре, при этом регистр не учитывался при вводе.

Идентификаторы GUID Microsoft иногда обозначаются фигурными скобками:

{123e4567-e89b-12d3-a456-426652340000}

Этот формат не следует путать с « реестром Windows форматом», который относится к формату в фигурных скобках.

RFC 4122 определяет пространство имен Uniform Resource Name (URN) для UUID. UUID, представленный как URN, выглядит следующим образом:

urn:uuid:123e4567-e89b-12d3-a456-426655440000

Кодирование

Двоичное кодирование UUID зависит от системы. UUID варианта 1, в настоящее время наиболее распространенный вариант, закодированы в формате с прямым порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeffкодируется в байтах 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

UUID варианта 2, исторически использовавшиеся в библиотеках Microsoft COM / OLE , используют формат с прямым порядком байтов , при этом первые три компонента UUID являются прямым порядком байтов , а последние два - прямым порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeffкодируется в байтах 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Варианты

Поле «вариант» UUID или позиция N указывают их формат и кодировку. RFC 4122 определяет четыре варианта длины от 1 до 3 бит:

  • Вариант 0 (обозначенный однобитовым шаблоном 0xxx 2 , N  =  0..7) предназначен для обратной совместимости с уже устаревшим форматом UUID Apollo Network Computing System 1.5, разработанным примерно в 1988 году. Первые 6 октетов UUID представляют собой 48-битную метку времени ( количество единиц времени в 4 микросекунды с 1 января 1980 года по всемирному координированному времени); следующие 2 октета зарезервированы; следующий октет - это «семейство адресов»; а последние 7 октетов - это 56-битный идентификатор хоста в форме, заданной семейством адресов. Хотя они отличаются в деталях, сходство с современными UUID версии 1 очевидно. Вариантные биты в текущей спецификации UUID совпадают со старшими битами октета семейства адресов в NCS UUID. Хотя семейство адресов могло содержать значения в диапазоне 0..255, когда-либо определялись только значения 0..13. Соответственно, битовый шаблон варианта 0 0xxxпозволяет избежать конфликтов с историческими UUID NCS, если они все еще существуют в базах данных.
  • Вариант 1 (10xx 2 , N  =  8..b, 2 бита) упоминается как UUID RFC 4122 / DCE 1.1, или UUID «Leach – Salz», в честь авторов исходного Интернет-проекта .
  • Вариант 2 (110x 2 , N  =  c..d, 3 бита) охарактеризован в RFC как «зарезервированный, обратная совместимость Microsoft Corporation» и использовался для ранних GUID на платформе Microsoft Windows . Он отличается от варианта 1 только порядком байтов в двоичном хранении или передаче: UUID варианта 1 используют "сетевой" (big-endian) порядок байтов, тогда как GUID варианта 2 используют "собственный" (little-endian) порядок байтов для некоторых подполей. UUID.
  • Зарезервировано определяется как 3-битовая вариантная битовая комбинация 111x 2 ( N  =  e..f).

Варианты 1 и 2 используются текущей спецификацией UUID. В текстовом представлении варианты 1 и 2 одинаковы, за исключением битов варианта. В двоичном представлении существует разница в порядке байтов. Когда для преобразования между прямым порядком байтов варианта 1 и прямым порядком байтов варианта 2 требуется перестановка байтов, поля выше определяют перестановку. Первые три поля представляют собой 32- и 16-разрядные целые числа без знака и подлежат замене местами, в то время как последние два поля состоят из неинтерпретируемых байтов и не подлежат замене местами. Эта перестановка байтов применяется даже для версий 3, 4 и 5, где канонические поля не соответствуют содержимому UUID.

Хотя некоторые важные идентификаторы GUID, такие как идентификатор интерфейса IUnknown модели компонентных объектов , номинально являются UUID варианта 2, многие идентификаторы, генерируемые и используемые в программном обеспечении Microsoft Windows и называемые «идентификаторами GUID», являются стандартным вариантом 1 RFC 4122 / DCE 1.1. UUID сетевого порядка байтов, а не UUID варианта 2 с прямым порядком байтов. Текущая версия средства Microsoft создает стандартные UUID варианта 1. В некоторой документации Microsoft указано, что «GUID» является синонимом «UUID», как это стандартизовано в RFC 4122. В самом RFC 4122 говорится, что UUID «также известны как GUID». Все это говорит о том, что «GUID», изначально относящийся к варианту UUID, используемому Microsoft, стал просто альтернативным именем для UUID, при этом сохранились идентификаторы GUID варианта 1 и варианта 2. guidgen

Версии

Для обоих вариантов 1 и 2 в стандартах определены пять «версий», и каждая версия может быть более подходящей, чем другие, в конкретных случаях использования. Версия указывается Mв строковом представлении.

UUID версии 1 генерируются из времени и идентификатора узла (обычно MAC-адреса ); UUID версии 2 генерируются из идентификатора (обычно идентификатора группы или пользователя), времени и идентификатора узла; версии 3 и 5 производят детерминированные UUID, генерируемые хешированием идентификатора и имени пространства имен ; и UUID версии 4 генерируются с использованием случайного или псевдослучайного числа.

Nil UUID

Нулевой UUID, особый случай, - это UUID 00000000-0000-0000-0000-000000000000; то есть все биты установлены в ноль.

Версия 1 (дата, время и MAC-адрес)

Версия 1 объединяет 48-битный MAC-адрес «узла» (то есть компьютера, генерирующего UUID) с 60-битной меткой времени, которая представляет собой количество 100- наносекундных интервалов с полуночи 15 октября 1582 года по всемирному координированному времени (UTC ), дата, когда впервые был принят григорианский календарь . RFC 4122 утверждает, что значение времени колеблется около 3400 AD, в зависимости от используемого алгоритма, что подразумевает, что 60-битная временная метка является величиной со знаком. Однако некоторые программы, такие как библиотека libuuid, обрабатывают метку времени как неподписанную, помещая время пролонгации в 5236 г. н.э. Время пролонгации, определенное Рек. МСЭ-Т G. X.667 - это 3603 год нашей эры.

13-битная или 14-битная «уникальная» тактовая последовательность расширяет временную метку для обработки случаев, когда тактовая частота процессора не продвигается достаточно быстро или когда имеется несколько процессоров и генераторов UUID на узел. Когда UUID генерируются быстрее, чем могут продвигаться системные часы, младшие биты полей временной метки могут быть сгенерированы путем увеличения их каждый раз, когда создается UUID, для имитации временной метки с высоким разрешением. Поскольку каждый UUID версии 1 соответствует одной точке в пространстве (узлу) и времени (интервалы и последовательность часов), вероятность того, что два правильно сгенерированных UUID версии 1 будут непреднамеренно одинаковыми, практически равна нулю. Поскольку время и последовательность часов составляют 74 бита, 2 74 (1,8 × 10 22 , или 18 секстиллионов) UUID версии 1 могут быть сгенерированы для каждого идентификатора узла с максимальной средней скоростью 163 миллиарда в секунду для каждого идентификатора узла.

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

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

RFC 4122 позволяет заменять MAC-адрес в UUID версии 1 (или 2) случайным 48-битным идентификатором узла либо потому, что у узла нет MAC-адреса, либо потому, что его нежелательно раскрывать. В этом случае RFC требует, чтобы младший бит первого октета идентификатора узла был установлен в 1. Это соответствует биту многоадресной рассылки в MAC-адресах, и его установка служит для различения UUID, где идентификатор узла генерируется случайным образом. из UUID на основе MAC-адресов сетевых карт, которые обычно имеют одноадресные MAC-адреса.

Версия 2 (дата, время и MAC-адрес, версия безопасности DCE)

RFC 4122 резервирует версию 2 для UUID "безопасности DCE"; но не содержит подробностей. По этой причине во многих реализациях UUID не используется версия 2. Однако спецификация UUID версии 2 обеспечивается спецификацией служб аутентификации и безопасности DCE 1.1.

UUID версии 2 похожи на версию 1, за исключением того, что 8 младших битов тактовой последовательности заменяются номером "локального домена", а младшие 32 бита метки времени заменяются целочисленным идентификатором, имеющим значение в пределах указанного локальный домен. В системах POSIX номера локальных доменов 0 и 1 предназначены для идентификаторов пользователей ( UID ) и групп ( GID ) соответственно, а другие номера локальных доменов определяются сайтом. В системах, отличных от POSIX, все номера локальных доменов определяются сайтом.

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

Версии 3 и 5 (на основе имен пространств имен)

Версия-3 и версия-5 UUID , порождены хэширования в пространстве имен идентификатор и имя. Версия 3 использует MD5 в качестве алгоритма хеширования, а версия 5 использует SHA-1 .

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

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

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

UUID версии 3 и версии 5 обладают тем свойством, что одно и то же пространство имен и имя будут сопоставляться с одним и тем же UUID. Однако ни пространство имен, ни имя не могут быть определены из UUID, даже если один из них указан, кроме как методом перебора. RFC 4122 рекомендует версию 5 (SHA-1) вместо версии 3 (MD5) и предостерегает от использования UUID любой версии в качестве учетных данных безопасности.

Версия 4 (случайная)

UUID версии 4 генерируется случайным образом. Как и в других UUID, 4 бита используются для обозначения версии 4 и 2 или 3 бита для обозначения варианта (10 2 или 110 2 для вариантов 1 и 2 соответственно). Таким образом, для варианта 1 (то есть для большинства UUID) случайный UUID версии 4 будет иметь 6 заранее определенных битов варианта и версии, оставляя 122 бита для случайно сгенерированной части, всего 2122 или 5,3 × 10 36 (5,3  × 10). undecillion ) возможные UUID версии 4 варианта 1. Существует вдвое меньше возможных UUID версии 4 варианта 2 (устаревших идентификаторов GUID), потому что доступно на один случайный бит меньше, а для варианта используется 3 бита.

Столкновения

Конфликт возникает, когда один и тот же UUID генерируется более одного раза и назначается разным референтам. В случае стандартных UUID версии 1 и версии 2, использующих уникальные MAC-адреса от сетевых карт, коллизии маловероятны, с повышенной вероятностью только тогда, когда реализация отличается от стандартов, случайно или намеренно.

В отличие от UUID версии 1 и версии 2, сгенерированных с использованием MAC-адресов, с UUID версии 1 и -2, которые используют случайно сгенерированные идентификаторы узлов, UUID версии 3 и версии 5 на основе хэша и случайные UUID версии 4, коллизии могут происходить даже без проблем с реализацией, хотя и с такой малой вероятностью, что ее обычно можно игнорировать. Эта вероятность может быть точно вычислена на основе анализа проблемы дня рождения .

Например, количество случайных UUID версии 4, которые необходимо сгенерировать, чтобы иметь 50% -ную вероятность хотя бы одного столкновения, составляет 2,71 квинтиллион, вычисляемый следующим образом:

Это число эквивалентно генерации 1 миллиарда UUID в секунду в течение примерно 85 лет. Файл, содержащий такое количество UUID, по 16 байтов на UUID, будет около 45  эксабайт .

Наименьшее количество UUID версии 4, которое должно быть сгенерировано, чтобы вероятность обнаружения коллизии была p , аппроксимируется формулой

Таким образом, вероятность найти дубликат в 103 триллионах UUID версии 4 составляет один на миллиард.

Использует

Значительное использование включает инструменты пользовательского пространства файловой системы ext2 / ext3 / ext4 ( e2fsprogs использует libuuid, предоставляемый util-linux ), LVM , зашифрованные разделы LUKS , GNOME , KDE и macOS , большинство из которых являются производными от исходной реализации Теодора Ц'о .

Одно из применений UUID в Solaris (с использованием реализации Open Software Foundation) - это идентификация работающего экземпляра операционной системы с целью связывания данных аварийного дампа с событием управления сбоями в случае паники ядра.

Обычно используется в протоколах Bluetooth для определения служб и общего профиля Bluetooth.

В COM

Существует несколько разновидностей идентификаторов GUID, используемых в объектной модели компонентов (COM) Microsoft :

  • IID - идентификатор интерфейса; (Те, которые зарегистрированы в системе, хранятся в реестре Windows по адресу [HKEY_CLASSES_ROOT\Interface])
  • CLSID - идентификатор класса; (Хранится в [HKEY_CLASSES_ROOT\CLSID])
  • LIBID - идентификатор библиотеки типов; (Хранится в [HKEY_CLASSES_ROOT\TypeLib])
  • CATID - идентификатор категории; (его присутствие в классе идентифицирует его как принадлежащее к определенным категориям классов, перечисленным в [HKEY_CLASSES_ROOT\Component Categories])

Как ключи базы данных

UUID обычно используются в качестве уникального ключа в таблицах базы данных. Функция NEWID в Microsoft SQL Server версии 4 Transact-SQL возвращает стандартные случайные UUID версии 4, в то время как функция NEWSEQUENTIALID возвращает 128-битные идентификаторы, аналогичные UUID, для которых установлено последовательное возрастание до следующей перезагрузки системы. Функция Oracle Database SYS_GUID не возвращает стандартный GUID, несмотря на название. Вместо этого он возвращает 16-байтовое 128-битное значение RAW на основе идентификатора хоста и идентификатора процесса или потока, чем-то похожего на GUID. PostgreSQL содержит тип данных UUID и может генерировать большинство версий UUID с помощью функций из модулей. MySQL предоставляет функцию UUID , которая генерирует стандартные UUID версии 1.

Случайный характер стандартных UUID версий 3, 4 и 5 и порядок полей в стандартных версиях 1 и 2 могут создавать проблемы с локализацией базы данных или производительностью, когда UUID используются в качестве первичных ключей . Например, в 2002 году Джимми Нильссон сообщил о значительном улучшении производительности Microsoft SQL Server, когда UUID версии 4, используемые в качестве ключей, были изменены для включения неслучайного суффикса, основанного на системном времени. Этот так называемый подход «COMB» (комбинированный идентификатор времени-GUID) сделал UUID нестандартными и, как признал Нильссон, с большей вероятностью дублировался, но Нильссон требовал только уникальности в приложении. Путем переупорядочивания и кодирования UUID версий 1 и 2 так, чтобы метка времени была первой, можно предотвратить потерю производительности при вставке.

Некоторые веб-фреймворки, такие как Laravel, поддерживают UUID «сначала временная метка», которые могут эффективно храниться в индексируемом столбце базы данных. Это делает COMB UUID с использованием формата версии 4, но где первые 48 бит составляют метку времени, выложенную, как в UUIDv1. Более определенные форматы, основанные на идее COMB UUID, включают:

  • «ULID», который отбрасывает 4 бита, используемые для обозначения версии 4, по умолчанию использует кодировку base32 и требует полной монотонности за счет сохранения состояния.
  • UUID версий с 6 по 8, формальное предложение трех форматов COMB UUID.

Смотрите также

использованная литература

внешние ссылки

Стандарты

Генератор UUID ITU-T

Технические статьи

Разное

Реализация на разных языках