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

редактировать
128-битное число, используемое для идентификации информации в компьютерных системах

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

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

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

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

Содержание

  • 1 История
  • 2 Стандарты
  • 3 Формат
  • 4 Кодирование
  • 5 Вариантов
  • 6 Версии
    • 6.1 Нулевой UUID
    • 6.2 Версия 1 (дата-время и MAC-адрес)
    • 6.3 Версия 2 (дата, время и MAC-адрес, версия защиты DCE)
    • 6.4 Версии 3 и 5 (на основе имени пространства имен)
    • 6.5 Версия 4 (случайная)
  • 7 Коллизии
  • 8 Использует
    • 8.1 в COM
    • 8.2 В качестве ключей базы данных
  • 9 См. Также
  • 10 Ссылки
  • 11 Внешние ссылки

История

В 1980-е годы Apollo Computer первоначально использовал UUID в Network Computing System (NCS), а затем в Open Software Foundation (OSF) Distributed Computing Environment (DCE). Первоначальный дизайн UUID DCE был основан на UUID NCS, дизайн которого, в свою очередь, был вдохновлен (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) как часть Distributed Computing Environment (DCE).

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

Инженерная группа Интернета (IETF) опубликовала стандарт RFC 4122, технически эквивалент Рек. МСЭ-Т Рек. 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; то есть основанный на времени DCE / RFC 4122 UUID.

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

макет записи UUID
ИмяДлина (байты)Длина (шестнадцатеричные цифры)Содержимое
time_low48целое число, дающее младшие 32 бита времени
time_mid24целое число, дающее средние 16 бит времени
time_hi_and_version244-битная «версия» в старших битах, за которыми следуют старшие 12 бит времени
clock_seq_hi_and_res clock_seq_low241–3-битный «вариант» в большинстве значимые биты, за которыми следует 13-15-битная тактовая последовательность
узел61248-битный идентификатор узла

Эти поля соответствуют полям в версиях 1 и 2 UUID (то есть, основанные на времени 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, который в настоящее время является наиболее распространенным вариантом, закодированы в формате big-endian. Например, 00112233-4455-6677-8899-aabbccddeeffкодируется как байты 00 11 22 3344 5566 7788 99aa bb cc dd ee ff.

UUID варианта 2, исторически использовавшиеся в библиотеках COM / OLE Microsoft, используют формат смешанный порядок байтов, при этом первые три компонента UUID - это с прямым порядком байтов, а последние два - с обратным порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeffкодируется как байты 33 22 11 0055 4477 6688 99aa 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 совпадают со старшими битами октета семейства адресов в UUID NCS. Хотя семейство адресов могло содержать значения в диапазоне 0..255, когда-либо определялись только значения 0..13. Соответственно, битовая комбинация варианта 0 0xxxпозволяет избежать конфликтов с историческими UUID NCS, если они все еще существуют в базах данных.
  • Вариант 1 (10xx 2, N = 8..b, 2 бита) упоминаются как UUID RFC 4122 / DCE 1.1 или UUID "Leach – Salz" по имени авторов исходного Internet Draft.
  • Variant 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, такие как идентификатор для интерфейса Component Object Model IUnknown, номинально являются UUID варианта 2, многие идентификаторы генерируются и используемые в программном обеспечении Microsoft Windows и называемые «GUID», являются стандартными UUID с порядком байтов в сети RFC 4122 / DCE 1.1, а не с прямым порядком байтов UUID варианта 2. Текущая версия инструмента Microsoft guidgenсоздает стандартные UUID варианта 1. В некоторой документации Microsoft указано, что «GUID» является синонимом «UUID», как это стандартизовано в RFC 4122. В самом RFC 4122 говорится, что UUID «также известны как GUID». Все это говорит о том, что «GUID», первоначально относившийся к варианту UUID, используемому Microsoft, стал просто альтернативным именем для UUID, при этом сохранились идентификаторы GUID варианта 1 и варианта 2.

Версии

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

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

Nil UUID

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

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

Версия 1 объединяет 48-битный MAC-адрес узла " "(то есть компьютер, генерирующий UUID), с 60-битной меткой времени, представляющей количество интервалов 100- наносекунд с полуночи 15 октября 1582 г. всемирное координированное время (UTC), дата, когда впервые был принят григорианский календарь. RFC 4122 утверждает, что значение времени колеблется около 3400 г. н.э., в зависимости от используемого алгоритма, что подразумевает, что 60-битная временная метка является величиной со знаком. Однако некоторые программы, такие как библиотека libuuid, обрабатывают временную метку как беззнаковую, помещая время пролонгации в 5236 г. н.э.

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

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

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

. RFC 4122 позволяет заменять MAC-адрес в UUID версии 1 (или 2) случайным 48- бит ID узла либо потому, что у узла нет MAC-адреса, либо потому, что раскрывать его нежелательно. В этом случае RFC требует, чтобы младший бит первого октета идентификатора узла был установлен в 1. Это соответствует биту multicast в 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 (на основе имен пространств имен)

UUID версий 3 и 5 генерируются с помощью хеширования идентификатора пространства имен и название. Версия 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, указывающий на UUID RFC 4122, или 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 бита для случайно сгенерированной части, всего 2, или 5,3 × 10 (5,3 ундециллион ) возможные 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 квинтиллион, вычисляемый следующим образом:

n ≈ 1 2 + 1 4 + 2 × ln ⁡ (2) × 2 122 ≈ 2,71 × 10 18. {\ displaystyle n \ приблизительно {\ frac {1} {2}} + {\ sqrt {{\ frac {1} {4}} + 2 \ times \ ln (2) \ times 2 ^ {122}}} \ примерно 2,71 \ 10 ^ {18}.}{\ displaystyle n \ приблизительно {\ frac {1} {2}} + {\ sqrt {{\ frac {1} {4}} + 2 \ times \ ln (2) \ times 2 ^ {122}}} \ приблизительно 2,71 \ times 10 ^ {18}.}

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

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

2 × 2 122 × ln ⁡ 1 1 - p. {\ displaystyle {\ sqrt {2 \ times 2 ^ {122} \ times \ ln {\ frac {1} {1-p}}}}.}{\ displaystyle {\ sqrt {2 \ times 2 ^ {122} \ times \ ln {\ frac {1} {1-p}}}}.}

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

Использует

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

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

В COM

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

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

В качестве ключей базы данных

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 могут создавать проблемы с базой данных locality или производительностью, когда UUID используются в качестве первичных ключей. Например, в 2002 году Джимми Нильссон сообщил о значительном улучшении производительности с Microsoft SQL Server, когда UUID версии 4, используемые в качестве ключей, были изменены для включения неслучайного суффикса, основанного на системном времени. Этот так называемый подход «COMB» (комбинированный идентификатор времени-GUID) сделал UUID нестандартными и значительно более вероятным для дублирования, как признал Нильссон, но Нильссон требовал уникальности только внутри приложения.

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

См. Также

Ссылки

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

Последняя правка сделана 2021-06-20 13:32:51
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте