Identificador único universal

Un identificador único universal (UUID) es una etiqueta de 128 bits utilizada para la información en los sistemas informáticos. También se utiliza el término identificador único global (GUID).

Cuando se generan de acuerdo con los métodos estándar, los UUID son, a efectos prácticos, únicos. Su singularidad no depende de una autoridad de registro central ni de la coordinación entre las partes que los generan, a diferencia de la mayoría de los otros esquemas de numeración. Si bien la probabilidad de que un UUID se duplique no es cero, generalmente se considera lo suficientemente cercana a cero como para ser insignificante.

Por lo tanto, cualquiera puede crear un UUID y usarlo para identificar algo con casi certeza de que el identificador no duplica uno que ya se creó o se creará para identificar otra cosa. Por lo tanto, la información etiquetada con UUID por partes independientes puede combinarse posteriormente en una sola base de datos o transmitirse en el mismo canal, con una probabilidad insignificante de duplicación.

La adopción de UUID está muy extendida, con muchas plataformas informáticas que brindan soporte para generarlos y analizar su representación textual.

Historia

En la década de 1980, Apollo Computer usó originalmente UUID en Network Computing System (NCS) y más tarde en el entorno de computación distribuida (DCE) de Open Software Foundation (OSF). El diseño inicial de los UUID de DCE se basó en los UUID de NCS, cuyo diseño a su vez se inspiró en los identificadores únicos (64 bits) definidos y utilizados de forma generalizada en Domain/OS, un sistema operativo diseñado por Apollo Computer. Posteriormente, las plataformas de Microsoft Windows adoptaron el diseño DCE como "identificadores únicos globales" (GUID). RFC 4122 registró un espacio de nombres URN para UUID y recapituló las especificaciones anteriores, con el mismo contenido técnico. Cuando en julio de 2005 se publicó RFC 4122 como un estándar IETF propuesto, la UIT también había estandarizado los UUID, basándose en los estándares anteriores y las primeras versiones de RFC 4122.

Estándares

Los UUID están estandarizados por Open Software Foundation (OSF) como parte del entorno informático distribuido (DCE).

Los UUID están documentados como parte de ISO/IEC 11578:1996 "Tecnología de la información - Interconexión de sistemas abiertos - Llamada a procedimiento remoto (RPC)" y más recientemente en la Rec. UIT-T. X.667 | ISO/CEI 9834-8:2014.

El Grupo de trabajo de ingeniería de Internet (IETF) publicó Standards-Track RFC 4122, técnicamente equivalente a la Rec. ITU-T. X.667 | ISO/CEI 9834-8.

Formato

En su representación textual canónica, los 16 octetos de un UUID se representan como 32 dígitos hexadecimales (base 16), que se muestran en cinco grupos separados por guiones, en la forma 8-4-4-4-12 para un total de 36 caracteres (32 caracteres hexadecimales y 4 guiones). Por ejemplo:

123e4567-e89b-12d3-a456-426614174000

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

La M de cuatro bits y la N de 1 a 3 bits > los campos codifican el formato del propio UUID.

Los cuatro bits del dígito M son la versión UUID, y los 1 a 3 bits más significativos del dígito N codifican la variante UUID. (Consulte a continuación). En el ejemplo anterior, M es 1, y N es a (10xx₂), lo que significa que se trata de un UUID versión 1, variante 1; es decir, un UUID DCE/RFC 4122 basado en el tiempo.

La cadena de formato canónico 8-4-4-4-12 se basa en el diseño de registro para los 16 bytes del UUID:

Estos campos corresponden a los de las versiones 1 y 2 de los UUID (es decir, los UUID basados en el tiempo), pero se usa la misma representación 8-4-4-4-12 para todos los UUID, incluso para los UUID construidos de manera diferente.

RFC 4122 Sección 3 requiere que los caracteres se generen en minúsculas, sin distinguir entre mayúsculas y minúsculas en la entrada.

Los GUID de Microsoft a veces se representan con llaves alrededor:

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

Este formato no debe confundirse con el "formato de registro de Windows", que hace referencia al formato dentro de las llaves.

RFC 4122 define un espacio de nombres de nombre de recurso uniforme (URN) para UUID. Un UUID presentado como URN aparece de la siguiente manera:

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

Codificación

La codificación binaria de los UUID varía entre sistemas. Los UUID de la variante 1, actualmente la variante más común, están codificados en un formato big-endian. Por ejemplo, 00112233-4455-6677-8899-aabbccddeeff se codifica como bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

Los UUID de la variante 2, utilizados históricamente en las bibliotecas COM/OLE de Microsoft, usan un formato little-endian, pero aparecen como mixtos con los tres primeros componentes del UUID como little-endian y los dos últimos big-endian, debido a los guiones de bytes que faltan cuando se formatea como una cadena. Por ejemplo, 00112233-4455-6677-8899-aabbccddeeff se codifica como bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Variantes

La "variante" campo de UUID, o la posición N indican su formato y codificación. RFC 4122 define cuatro variantes de longitudes de 1 a 3 bits:

• Variante 0 (indicado por el patrón de un solo bit 0xxx₂, N=0..7) es para la compatibilidad atrasada con el sistema de computación de red Apolo ahora obsoleto 1.5 formato UUID desarrollado alrededor de 1988. Los primeros 6 octets del UUID son un timetamp de 48 bits (el número de unidades de 4 microsegundos de tiempo desde el 1 de enero de 1980 UTC); los siguientes 2 octets están reservados; el siguiente octeto es la "familia de dirección"; y los 7 octets finales son un ID de acogida de 56 bits en el formulario especificado por la familia de dirección. Aunque es diferente en detalle, la similitud con la versión moderna-1 UUIDs es evidente. Los bits variantes de la especificación UUID actual coinciden con los pedazos altos de la dirección octet familiar en NCS UUIDs. Aunque la familia de direcciones podría tener valores en el rango 0..255, sólo los valores 0..13 fueron definidos. En consecuencia, el patrón de bits variante-0 0xxx evita conflictos con NCS UUIDs históricos, si todavía existen en bases de datos.
• Variante 1 (10xx₂, N=8..b, 2 bits) se denominan RFC 4122/DCE 1.1 UUIDs, o "Leach-Salz" UUIDs, después de los autores del borrador original de Internet.
• Variante 2 (110x₂, N=c..d, 3 bits) se caracteriza en el RFC como "reservado, compatibilidad con Microsoft Corporation atrasada" y fue utilizado para los GUID tempranos en la plataforma Microsoft Windows. Se diferencia de la variante 1 sólo por el endianness en almacenamiento binario o transmisión: la variante-1 UUIDs utilizan el orden de byte "network" (big-endian), mientras que los GUIDs variante-2 utilizan el orden de byte "native" (little-endian) para algunos subcampos del UUID.
• Se define como el patrón de bits de 3 bits 111x₂ ()N=e..f).

Las variantes 1 y 2 son utilizadas por la especificación UUID actual. En sus representaciones textuales, las variantes 1 y 2 son iguales, excepto por los bits variantes. En la representación binaria, hay una diferencia de endianidad. Cuando se requiere el intercambio de bytes para convertir entre el orden de bytes big-endian de la variante 1 y el orden de bytes little-endian de la variante 2, los campos anteriores definen el intercambio. Los primeros tres campos son enteros de 32 y 16 bits sin signo y están sujetos a intercambio, mientras que los dos últimos campos consisten en bytes sin interpretar, no sujetos a intercambio. Este intercambio de bytes se aplica incluso para las versiones 3, 4 y 5, donde los campos canónicos no se corresponden con el contenido del UUID.

Si bien algunos GUID importantes, como el identificador de la interfaz IUnknown del modelo de objetos componentes, son nominalmente UUID de la variante 2, muchos identificadores generados y utilizados en el software de Microsoft Windows se denominan "GUID" son UUID de orden de bytes de red estándar variante 1 RFC 4122/DCE 1.1, en lugar de UUID variante 2 little-endian. La versión actual de la herramienta guidgen de Microsoft produce UUID de variante 1 estándar. Parte de la documentación de Microsoft indica que "GUID" es un sinónimo de "UUID", según lo estandarizado en RFC 4122. RFC 4122 establece que los UUID "también se conocen como GUID". Todo esto sugiere que "GUID", aunque originalmente se refería a una variante de UUID utilizada por Microsoft, se ha convertido simplemente en un nombre alternativo para UUID, con los GUID variantes 1 y 2 existentes.

Versiones

Para ambas variantes 1 y 2, cinco "versiones" se definen en los estándares, y cada versión puede ser más apropiada que las demás en casos de uso específicos. La versión se indica mediante M en la representación de cadena.

Los UUID de la versión 1 se generan a partir de una hora y un ID de nodo (generalmente la dirección MAC); los UUID de la versión 2 se generan a partir de un identificador (normalmente un ID de grupo o de usuario), hora y un ID de nodo; las versiones 3 y 5 producen UUID deterministas generados mediante el hash de un identificador de espacio de nombres y un nombre; y los UUID de la versión 4 se generan utilizando un número aleatorio o pseudoaleatorio.

UUID nulo

El "cero" UUID, un caso especial, es el UUID 00000000-0000-0000-0000-000000000000; es decir, todos los bits puestos a cero.

Versión 1 (fecha, hora y dirección MAC)

La versión 1 concatena la dirección MAC de 48 bits del "nodo" (es decir, la computadora que genera el UUID), con una marca de tiempo de 60 bits, siendo el número de intervalos de 100 nanosegundos desde la medianoche del 15 de octubre de 1582, hora universal coordinada (UTC), la fecha en que se adoptó por primera vez el calendario gregoriano fuera del Iglesia Católica y Estados Pontificios. RFC 4122 establece que el valor de tiempo se acumula alrededor de 3400 d. C., según el algoritmo utilizado, lo que implica que la marca de tiempo de 60 bits es una cantidad con signo. Sin embargo, algún software, como la biblioteca libuuid, trata la marca de tiempo como si no estuviera firmada, lo que coloca el tiempo de transferencia en 5623 AD. El tiempo de renovación definido por la Rec. UIT-T. X.667 es 3603 dC.

Un dispositivo "uniquificante" de 13 o 14 bits La secuencia del reloj extiende la marca de tiempo para manejar los casos en los que el reloj del procesador no avanza lo suficientemente rápido, o donde hay varios procesadores y generadores de UUID por nodo. Cuando los UUID se generan más rápido de lo que podría avanzar el reloj del sistema, los bits más bajos de los campos de marca de tiempo se pueden generar incrementándolos cada vez que se genera un UUID, para simular una marca de tiempo de alta resolución. Con cada UUID de la versión 1 correspondiente a un solo punto en el espacio (el nodo) y el tiempo (intervalos y secuencia de reloj), la posibilidad de que dos UUID de la versión 1 generados correctamente sean los mismos sin querer es prácticamente nula. Dado que la secuencia de tiempo y reloj totaliza 74 bits, 2⁷⁴ (1,8×10²², o 18 sextillones) UUID de la versión 1 se pueden generar por ID de nodo, a una tasa promedio máxima de 163 mil millones por segundo por ID de nodo.

A diferencia de otras versiones de UUID, los UUID de las versiones 1 y 2 basados en direcciones MAC de tarjetas de red dependen en parte de su singularidad en un identificador emitido por una autoridad de registro central, a saber, el Identificador único organizativo (OUI) parte de la dirección MAC, que es emitida por el IEEE a los fabricantes de equipos de red. La singularidad de los UUID de la versión 1 y la versión 2 basados en direcciones MAC de tarjetas de red también depende de que los fabricantes de tarjetas de red asignen correctamente direcciones MAC únicas a sus tarjetas, que al igual que otros procesos de fabricación están sujetos a errores. Además, algunos sistemas operativos permiten al usuario final personalizar la dirección MAC, en particular OpenWRT.

El uso de la dirección MAC de la tarjeta de red del nodo para el ID del nodo significa que se puede rastrear un UUID de la versión 1 hasta la computadora que lo creó. A veces, los documentos se pueden rastrear hasta las computadoras donde se crearon o editaron a través de UUID integrados en ellos mediante un software de procesamiento de texto. Este agujero de privacidad se utilizó para localizar al creador del virus Melissa.

RFC 4122 permite que la dirección MAC en un UUID versión 1 (o 2) se reemplace por una ID de nodo aleatoria de 48 bits, ya sea porque el nodo no tiene una dirección MAC o porque no es deseable exponerlo. En ese caso, el RFC requiere que el bit menos significativo del primer octeto de la ID del nodo se establezca en 1. Esto corresponde al bit de multidifusión en las direcciones MAC, y su configuración sirve para diferenciar los UUID donde la ID del nodo se genera aleatoriamente. de UUID basados en direcciones MAC de tarjetas de red, que normalmente tienen direcciones MAC de unidifusión.

Versión 2 (fecha-hora y dirección MAC, versión de seguridad DCE)

RFC 4122 reserva la versión 2 para "seguridad DCE" UUID; pero no proporciona ningún detalle. Por este motivo, muchas implementaciones de UUID omiten la versión 2. Sin embargo, la especificación de los servicios de seguridad y autenticación DCE 1.1 proporciona la especificación de los UUID de la versión 2.

Los UUID de la versión 2 son similares a la versión 1, excepto que los 8 bits menos significativos de la secuencia de reloj se reemplazan por un "dominio local" y los 32 bits menos significativos de la marca de tiempo se reemplazan por un identificador entero significativo dentro del dominio local especificado. En los sistemas POSIX, los números de dominio local 0 y 1 son para ID de usuario (UID) e ID de grupo (GID) respectivamente, y otros números de dominio local están definidos por el sitio. En los sistemas que no son POSIX, todos los números de dominio locales están definidos por el sitio.

La capacidad de incluir un dominio/identificador de 40 bits en el UUID viene con una compensación. Por un lado, 40 bits permiten alrededor de 1 billón de valores de dominio/identificador por ID de nodo. Por otro lado, con el valor del reloj truncado a los 28 bits más significativos, en comparación con los 60 bits de la versión 1, el reloj en un UUID de la versión 2 hará "tictac" solo una vez cada 429,49 segundos, un poco más de 7 minutos, a diferencia de cada 100 nanosegundos de la versión 1. Y con una secuencia de reloj de solo 6 bits, en comparación con los 14 bits de la versión 1, solo 64 UUID únicos por nodo/dominio/ El identificador se puede generar por pulso de reloj de 7 minutos, en comparación con los 16 384 valores de secuencia de reloj para la versión 1. Por lo tanto, la versión 2 puede no ser adecuada para los casos en los que se requieren UUID, por nodo/dominio/identificador, a una velocidad superior a uno cada siete minutos.

Versiones 3 y 5 (espacio de nombres basado en el nombre)

Los UUID de la versión 3 y la versión 5 se generan al codificar un identificador de espacio de nombres y un nombre. La versión 3 usa MD5 como algoritmo hash y la versión 5 usa SHA-1.

El identificador del espacio de nombres es en sí mismo un UUID. La especificación proporciona UUID para representar los espacios de nombres para URL, nombres de dominio completos, identificadores de objetos y nombres distinguidos X.500; pero cualquier UUID deseado puede usarse como un designador de espacio de nombres.

Para determinar el UUID de la versión 3 correspondiente a un espacio de nombres y un nombre determinados, el UUID del espacio de nombres se transforma en una cadena de bytes, se concatena con el nombre de entrada y luego se codifica con MD5, lo que genera 128 bits. Luego, 6 o 7 bits se reemplazan por valores fijos, la versión de 4 bits (por ejemplo, 0011₂ para la versión 3) y el UUID de 2 o 3 bits "variante" (por ejemplo, 10₂ indica un UUID RFC 4122 o 110₂ indica un GUID de Microsoft heredado). Dado que 6 o 7 bits están predeterminados, solo 121 o 122 bits contribuyen a la unicidad del UUID.

Los UUID de la versión 5 son similares, pero se usa SHA-1 en lugar de MD5. Dado que SHA-1 genera resúmenes de 160 bits, el resumen se trunca a 128 bits antes de que se reemplacen los bits de versión y variante.

Los UUID de la versión 3 y la versión 5 tienen la propiedad de que el mismo espacio de nombres y el mismo nombre se asignarán al mismo UUID. Sin embargo, ni el espacio de nombres ni el nombre se pueden determinar a partir del UUID, incluso si se especifica uno de ellos, excepto mediante una búsqueda de fuerza bruta. RFC 4122 recomienda la versión 5 (SHA-1) sobre la versión 3 (MD5) y advierte contra el uso de UUID de cualquiera de las versiones como credenciales de seguridad.

Versión 4 (aleatorio)

Se genera aleatoriamente un UUID de la versión 4. Como en otros UUID, se utilizan 4 bits para indicar la versión 4, y 2 o 3 bits para indicar la variante (10₂ o 110₂ para las variantes 1 y 2 respectivamente). Por lo tanto, para la variante 1 (es decir, la mayoría de los UUID), un UUID de versión 4 aleatorio tendrá 6 bits predeterminados de variante y versión, dejando 122 bits para la parte generada aleatoriamente, para un total de 2¹²², o 5.3×10³⁶ (5,3 undecillones) posibles UUID versión 4 variante 1. Hay la mitad de los posibles UUID versión 4 variante 2 (GUID heredados) porque hay un bit aleatorio menos disponible, 3 bits se consumen para la variante.

Colisiones

La colisión ocurre cuando el mismo UUID se genera más de una vez y se asigna a distintos referentes. En el caso de los UUID estándar de la versión 1 y la versión 2 que usan direcciones MAC únicas de las tarjetas de red, es poco probable que ocurran colisiones, con una mayor posibilidad solo cuando una implementación difiere de los estándares, ya sea sin darse cuenta o intencionalmente.

A diferencia de los UUID de la versión 1 y la versión 2 generados con direcciones MAC, con los UUID de la versión 1 y -2 que usan ID de nodo generados aleatoriamente, los UUID de la versión 3 y la versión 5 basados en hash, y la versión aleatoria- 4 UUID, las colisiones pueden ocurrir incluso sin problemas de implementación, aunque con una probabilidad tan pequeña que normalmente puede ignorarse. Esta probabilidad se puede calcular con precisión en función del análisis del problema del cumpleaños.

Por ejemplo, la cantidad de UUID aleatorios de la versión 4 que deben generarse para tener un 50 % de probabilidad de al menos una colisión es 2,71 quintillones, calculados de la siguiente manera:

n.. 12+14+2× × In⁡ ⁡ ()2)× × 2122.. 2.71× × 1018.{displaystyle napprox {frac {1}{2}+{sqrt {{frac {1}{4}+2times ln(2)times 2^{122}}}approx 2.71times 10^{18}

Este número equivale a generar mil millones de UUID por segundo durante aproximadamente 86 años. Un archivo que contenga tantos UUID, a 16 bytes por UUID, ocuparía unos 45 exabytes.

El número más pequeño de UUID versión 4 que se debe generar para que la probabilidad de encontrar una colisión sea p se aproxima mediante la fórmula

2× × 2122× × In⁡ ⁡ 11− − p.{displaystyle {sqrt {2times 2^{122}times ln {frac {1} {1-p}}}}

Por lo tanto, la probabilidad de encontrar un duplicado dentro de los 103 billones de UUID de la versión 4 es de una entre mil millones.

Usos

Sistemas de archivos

Los usos significativos incluyen herramientas de espacio de usuario del sistema de archivos ext2/ext3/ext4 (e2fsprogs usa libuuid proporcionado por util-linux), LVM, particiones encriptadas LUKS, GNOME, KDE y macOS, la mayoría de los cuales se derivan de la implementación original de Theodore Ts& #39;s.

Uno de los usos de los UUID en Solaris (usando la implementación de Open Software Foundation) es la identificación de una instancia de sistema operativo en ejecución con el fin de vincular datos de volcado de bloqueo con eventos de administración de fallas en caso de pánico del kernel.

La "etiqueta de partición" y el "partición UUID" ambos se almacenan en la supermanzana. Ambos son parte del sistema de archivos en lugar de la partición. Por ejemplo, ext2–4 contienen un UUID, mientras que NTFS o FAT32 no.

El superbloque es una parte del sistema de archivos, por lo que está completamente contenido dentro de la partición, por lo que dd if=/dev/sda1 of=/dev/sdb1 deja sda1 y sdb1 con la misma etiqueta y UUID.

En COM

Hay varios tipos de GUID que se utilizan en el modelo de objetos componentes (COM) de Microsoft:

• IID – identificador de interfaz; (Los que están registrados en un sistema se almacenan en el Registro de Windows en [HKEY_CLASSES_ROOTInterface])
• CLSID – identificador de clase; [HKEY_CLASSES_ROOTCLSID])
• LIBID – identificador de biblioteca tipo; [HKEY_CLASSES_ROOTTypeLib])
• CATID – identificador de categoría; (su presencia en una clase lo identifica como perteneciente a ciertas categorías de clase, enumeradas en [HKEY_CLASSES_ROOTComponent Categories])

Como claves de base de datos

Los UUID se usan comúnmente como una clave única en las tablas de bases de datos. La función NEWID en Microsoft SQL Server versión 4 Transact-SQL devuelve UUID aleatorios estándar de la versión 4, mientras que la función NEWSEQUENTIALID devuelve 128 -identificadores de bits similares a los UUID que se comprometen a ascender en secuencia hasta el próximo reinicio del sistema. La función Oracle Database SYS_GUID no devuelve un GUID estándar, a pesar del nombre. En su lugar, devuelve un valor RAW de 128 bits y 16 bytes basado en un identificador de host y un identificador de proceso o subproceso, algo similar a un GUID. PostgreSQL contiene un tipo de datos UUID y puede generar la mayoría de las versiones de UUID mediante el uso de funciones de módulos. MySQL proporciona una función UUID, que genera UUID versión 1 estándar.

La naturaleza aleatoria de los UUID estándar de las versiones 3, 4 y 5, y el orden de los campos dentro de las versiones estándar 1 y 2 pueden crear problemas con la ubicación o el rendimiento de la base de datos cuando los UUID se usan como claves principales. Por ejemplo, en 2002, Jimmy Nilsson informó una mejora significativa en el rendimiento con Microsoft SQL Server cuando los UUID de la versión 4 que se usaban como claves se modificaron para incluir un sufijo no aleatorio basado en la hora del sistema. Este llamado "PEINE" (GUID de tiempo combinado) hizo que los UUID no fueran estándar y considerablemente más propensos a duplicarse, como reconoció Nilsson, pero Nilsson solo requería unicidad dentro de la aplicación. Al reordenar y codificar los UUID de las versiones 1 y 2 para que la marca de tiempo aparezca primero, se puede evitar la pérdida de rendimiento de la inserción.

Algunos marcos web, como Laravel, son compatibles con "marca de tiempo primero" UUID que pueden almacenarse de manera eficiente en una columna de base de datos indexada. Esto crea un COMB UUID con el formato de la versión 4, pero donde los primeros 48 bits forman una marca de tiempo dispuesta como en UUIDv1. Los formatos más específicos basados en la idea COMB UUID incluyen:

• "ULID", que pica los 4 bits utilizados para indicar la versión 4, y utiliza una codificación base32 por defecto.
• UUID versiones 6 a 8, una propuesta formal de tres formatos COMB UUID.