Инструменты разработчика · Генератор UUID
От Аполлона NCS до RFC 9562: Краткая история UUID
· Фон
uuid криптография API-интерфейс браузера
Нечетный макет 8-4-4-4-12 и размер 128 унаследованы от распределенных вычислений 1980-х годов. В этом посте прослеживается UUID от сетевой вычислительной системы Apollo через DCE, GUID Microsoft и два стандарта IETF.
Почему 128 bits и почему эти дефисы? — вопросы, которые задает каждый новичок и на которые отвечает история
Формат 8-4-4-4-12 через дефис и размер 128 бит UUID — это конструктивные решения, которые историки сразу же подвергают сомнению. Почему бы не 96 bits для упрощения вычислений? Почему именно такое расположение сегментов? Почему base-16 с дефисами вместо base-64 или более простой кодировки? Ответы кроются в сетевой вычислительной системе Apollo начала 1980-х годов, распределенной вычислительной платформе, которая столкнулась с реальной проблемой: системам в сети необходимо было выделять уникальные идентификаторы без центрального органа, и эти идентификаторы должны были быть глобально уникальными с подавляющей вероятностью. Apollo NCS решил эту проблему, объединив временную метку, сетевой адрес и тактовую последовательность в 128-битный идентификатор, который мог быть сгенерирован независимо любой машиной.
Сетевая вычислительная система Apollo - появление в 1980-х годах уникальных идентификаторов, построенных на основе времени и сетевого адреса.
В текущем стандарте записана линия от Apollo NCS до OSF Distributed Computing Environment и более поздних платформ Microsoft. Эта история объясняет, почему современные системы используют узнаваемое семейство 128-бит, сохраняя при этом маркеры вариантов для старых макетов. Он не дает абсолютной гарантии уникальности: каждая версия имеет свои правила генерации и режимы сбоя. Долгосрочным достижением является совместимость без центральной службы регистрации. Браузер, база данных и операционная система могут обмениваться одной и той же канонической шестнадцатеричной формой, проверять ее поля варианта и версии и решать, соответствует ли рецепт производства потребностям принимающей системы.
OSF DCE и поле варианта — как распределенная вычислительная среда формализовала макет и добавила биты варианта
Макет поддерживает несколько стратегий генерации с помощью полей версий и вариантов, которые были встроены с самого начала проекта. Генерация на основе времени, случайная генерация и генерация на основе имени могут сосуществовать в одном пространстве идентификаторов. Современные приложения предъявляют другие требования, чем NCS 1980-х годов — базы данных, которым нужны сортируемые ключи, облачные системы, которым нужна конфиденциальность, распределенные системы, которым нужна устойчивость к коллизиям, — однако та же 128-битная структура по-прежнему их удовлетворяет. Версии 6 и 7, добавленные в RFC и 9562 в 2024, доказывают, что первоначальные разработчики оставили место для будущей эволюции, не нарушая обратной совместимости.
Microsoft GUID — COM, реестр и стиль фигурных скобок и прописных букв, который сохраняется и сегодня.
Сетевая вычислительная система Apollo представляла собой распределенную вычислительную платформу, которая работала на компьютерных рабочих станциях Apollo в 1980-х годах. Он полагался на глобальные уникальные идентификаторы для удаленных вызовов процедур, репликации данных и служб именования. Узлы в сети не имели возможности координировать назначение идентификаторов, поскольку вы не могли связаться с центральным сервером, если сеть могла быть разделена или отключена. Поэтому разработчики Apollo создали 128-битный формат, сочетающий метку времени 60 bits, идентификатор узла, обычно получаемый из адреса сетевой карты MAC 48 bits, и последовательность часов 14 bits для обработки изменений часов. Этот подход позволяет узлам генерировать идентификаторы независимо, комбинируя время, последовательность часов и поле узла; его поведение по-прежнему зависело от часов и выбора узла.
RFC 4122 (2005) — стандарт IETF, определяющий версии от 1 до 5 и пространство имен URN, согласованное с ITU-T X.667
Когда OSF позже стандартизировали это для своей распределенной вычислительной среды на основе 1992, они сохранили тот же макет и добавили поле варианта, чтобы различать разные типы UUID. Конструкция уже апробирована в производственных системах. IETF стандартизировал RFC 4122 в 2005, почти через двадцать лет после Аполлона NCS и примерно через тринадцать лет после стандартизации DCE. RFC 4122 кодифицированные версии с 1 по 5: версия 1 для генерации по времени, версия 3 для генерации по имени с MD5, версия 4 для случайным образом и версия 5 для имени на основе SHA-1. Стандарт был стабильным и широко распространенным, поскольку он уже был повсеместно распространен в Microsoft Windows, DNS инфраструктуре и распределенных системах. К моменту публикации RFC 4122 UUID уже настолько был встроен в инфраструктуру, что стандартизация носила почти академический характер.
RFC 9562 (2024) — редакция, которая устарела RFC 4122, добавила версии 6, 7 и 8 и записала современные советы по случайности
В 2024 IETF опубликован RFC 9562, который устарел RFC 4122 и добавляет версии 6, 7 и 8. Версия 6 изменяет порядок полей времени версии 1 для лучшей локальности и сортировки B-дерева. Версия 7 использует современную и знакомую временную метку Unix вместо счетчика на основе 1582, что улучшает сортировку и соответствует современным требованиям к базам данных. Версия 8 оставляет место для пользовательских реализаций и экспериментальных проектов UUID. В новых версиях решаются проблемы, возникшие за сорок лет развертывания UUID: низкая производительность базы данных со случайными ключами, утечка конфиденциальности версии 1 и стремление к сортируемым идентификаторам в облачных системах. Тем не менее, основная 128-битная структура, поля варианта и версии, а также общий макет остаются неизменными.
Чего это не касается — подробности реализации каждой версии, о которых есть отдельные публикации.
Принятие Microsoft UUID в качестве глобальных уникальных идентификаторов GUID в объектной модели компонентов глубоко внедрило их в системы Windows, начиная с 1990-х годов. GUID появился в реестре, в интерфейсах COM и в инфраструктуре ActiveDirectory. Microsoft добавила небольшое изменение: для некоторых компонентов они хранили GUID в порядке байтов с прямым порядком байтов, что отклоняется от стандарта сетевого порядка байтов. Эта особенность сохраняется в некоторых API-интерфейсах Windows: если вы экспортируете GUID из Windows и импортируете его в систему Unix, проблемы с порядком байтов могут вызвать очевидные несоответствия. Но сам формат тот же, и путаница — это сноска в стандарте, а не принципиальная разница. Стиль фигурных скобок и прописных букв {3FA85F64-5717-4562-B3FC-2C963F66AFA6} взят из соглашений Windows; другие системы предпочитают строчные буквы и дефисы без фигурных скобок.
Вывод: сорокалетняя разработка, которая до сих пор работает — генератор ToolAcre создает случайные (версия 4) UUID, которые RFC 9562 все еще определяет для случаев, когда упорядочение не требуется.
Проработанный график показывает долговечность и стабильность конструкции: Аполлон NCS 1980-х годов изобретает концепцию; 1992 OSF DCE стандартизирует макет; Microsoft 2000-х встраивает его в Windows; 2005 IETF публикует RFC 4122; 2024 IETF публикует RFC 9562 с современными версиями. Это одна из самых длительных попыток стандартизации вычислительной техники, и не из-за споров, а потому, что первоначальная конструкция была настолько надежной и адаптируемой. Он выдержал волны архитектурных изменений — от распределенных NFS систем до облачных баз данных, от Windows COM до мобильных устройств, от 64-битных машин 1980-х годов до современных систем — без фундаментальной переработки. Практическое значение заключается в том, что UUID являются повсеместными и стабильными; когда вы создаете UUID с помощью генератора ToolAcre, вы генерируете идентификатор, формат которого был установлен в 1980-х годах, стандартизирован на международном уровне в 2005 и поддерживается в 2024 с постоянной актуальностью.