Un identificador universalmente único ( UUID ) es una etiqueta de 128 bits que se utiliza para información en sistemas informáticos. El término Identificador único global ( GUID ) también se utiliza, principalmente en los sistemas de Microsoft. [1]
Cuando se generan según 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. [2] [3]
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 ha creado o se creará para identificar otra cosa. Por lo tanto, la información etiquetada con UUID por partes independientes puede combinarse posteriormente en una única base de datos o transmitirse por el mismo canal, con una probabilidad insignificante de duplicación.
La adopción de UUID está generalizada y muchas plataformas informáticas brindan soporte para generarlos y analizar su representación textual.
En la década de 1980, Apollo Computer utilizó originalmente UUID en el Network Computing System (NCS). Más tarde, la Open Software Foundation (OSF) utilizó UUID para su entorno informático distribuido (DCE). El diseño de los UUID DCE se basó en parte en los UUID NCS, [4] cuyo diseño se inspiró a su vez en los identificadores únicos ( 64 bits ) definidos y utilizados de forma generalizada en Domain/OS , un sistema operativo diseñado por Apollo Computer. [ cita necesaria ] Más tarde, [ ¿cuándo? ] las plataformas Microsoft Windows adoptaron el diseño DCE como "identificadores globalmente únicos" (GUID).
RFC 4122 registró un espacio de nombres URN para UUID y recapituló las especificaciones anteriores, con el mismo contenido técnico. [1] Cuando en julio de 2005 se publicó el RFC 4122 como estándar propuesto por el IETF , la UIT también había estandarizado los UUID, basándose en los estándares anteriores y las primeras versiones del RFC 4122.
Los UUID están estandarizados por la Open Software Foundation (OSF) como parte del Entorno de Computación Distribuida (DCE). [5] [6]
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 / IEC 9834-8:2014. [7]
El Grupo de Trabajo de Ingeniería de Internet (IETF) publicó el Standards-Track RFC 4122, [1] técnicamente equivalente a la Rec. UIT-T. X.667 | ISO/CEI 9834-8. El "Grupo de trabajo para revisar las definiciones de identificadores universalmente únicos" está trabajando en una actualización que introducirá versiones adicionales. [8]
Un UUID es una etiqueta de 128 bits. Inicialmente, Apollo Computer diseñó el UUID con el siguiente formato de cable: [4] [9]
Posteriormente, el UUID se amplió combinando el campo de familia heredado con el nuevo campo de variante. Debido a que el campo de familia solo había usado valores entre 0 y 13 en el pasado, se decidió que un UUID con el bit más significativo establecido en 0 era un UUID heredado. Esto da la siguiente tabla para el grupo familiar:
El UUID Apollo NCS heredado tiene el formato descrito en la tabla anterior. La variante OSF DCE UUID se describe en RFC 4122. El UUID COM/DCOM de Microsoft tiene su variante descrita en la documentación de Microsoft.
Para ayudar a la lectura humana, los grupos generalmente se presentan en formato hexadecimal donde los grupos están separados por el símbolo de guión ( - ).
Como un UUID es una etiqueta de 128 bits, se puede representar en diferentes formatos.
En la mayoría de los casos, los UUID se representan como valores hexadecimales. El formato más utilizado es el formato 8-4-4-4-12, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxdonde cada xrepresenta 4 bits. Otros formatos conocidos son el formato 8-4-4-4-12 con llaves, {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}como en los sistemas de Microsoft, por ejemplo Windows, o xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, donde se eliminan todos los guiones. En algunos casos, también es posible contar xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcon el prefijo "0x" o el sufijo "h" para indicar valores hexadecimales. El formato con guiones se introdujo con el sistema de variantes más nuevo. Antes de eso, el formato Apollo heredado usaba un formato ligeramente diferente: 34dc23469000.0d.00.00.7c.5f.00.00.00. La primera parte es el tiempo (time_high y time_low combinados). Se omite el campo reservado. El campo de familia viene directamente después del primer punto, por lo que en este caso 0d(13 en decimal) para DDS (Servicio de distribución de datos) . Las partes restantes, cada una separada por un punto, son los bytes del nodo.
La forma minúscula de los valores hexadecimales es el formato generalmente preferido. Específicamente en algunos contextos como los definidos en la Rec. UIT-T. X.667, se requieren minúsculas cuando se genera el texto, pero también se debe aceptar la versión en mayúsculas.
Un UUID se puede representar como un número entero de 128 bits. Por ejemplo, el UUID 550e8400-e29b-41d4-a716-446655440000también se puede representar como 113059749145936325402354257176981405696. Tenga en cuenta que es posible tener valores con y sin signo si el primer bit del UUID se establece en 1.
Un UUID se puede representar como un número binario de 128 bits . Por ejemplo, el UUID 550e8400-e29b-41d4-a716-446655440000también se puede representar como 0101010100001110100001000000000011100010100110110100000111010100101001110001011001000100011001100101010101000100. 0000000000000000.
RFC 4122 registró el espacio de nombres "uuid". Esto hace posible crear URN a partir de UUID, como urn:uuid:550e8400-e29b-41d4-a716-446655440000. Para ello se utiliza el formato normal 8-4-4-4-12. También es posible crear una URN OID a partir de UUID, como urn:oid:2.25.113059749145936325402354257176981405696. En ese caso, se utiliza el formato decimal sin signo. Se recomienda la URN "uuid" sobre la URN "oid".
El campo variante indica el formato del UUID (y en el caso del UUID heredado también la familia de direcciones utilizada para el campo de nodo). Se definen las siguientes variantes:
0xxxevita conflictos con los UUID NCS históricos, en caso de que aún existan en las bases de datos. [9] Esta variante define "familias" como subtipo.La variante OSF DCE define cinco "versiones" en el estándar, 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 el valor del cuarteto más alto (4 bits más altos o dígito hexadecimal más alto) del séptimo byte del UUID. En hexadecimal, este es el personaje después del segundo guión. Por ejemplo, el UUID es la versión 4, debido a que el dígito después del segundo guión es 4 en .9c5b94b1-35ad-49bb-b118-8e8fc24abf80...-49bb-...
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). ), fecha en la que se adoptó por primera vez el calendario gregoriano fuera de la Iglesia católica y los Estados Pontificios. RFC 4122 establece que el valor de tiempo se desplaza alrededor del 3400 d. C., [1] : 3 dependiendo del algoritmo utilizado, lo que implica que la marca de tiempo de 60 bits es una cantidad con signo. Sin embargo, algunos programas, como la biblioteca libuuid, tratan la marca de tiempo como sin firmar, lo que sitúa el tiempo de renovación en 5623 d.C. [10] El tiempo de renovación definido en la Rec. UIT-T. X.667 es 3603 d.C. [11] : v
Una secuencia de reloj "uniquificadora" de 13 o 14 bits extiende la marca de tiempo para manejar casos en los que el reloj del procesador no avanza lo suficientemente rápido o en los que 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 inferiores 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. Dado que cada UUID de la versión 1 corresponde a un único 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 involuntariamente iguales es prácticamente nula. Dado que la secuencia de tiempo y reloj tiene un total de 74 bits, 2 74 (1,8 × 10Se pueden generar 22 (o 18 sextillones) de UUID versión 1 por ID de nodo, a una velocidad promedio máxima de 163 mil millones por segundo por ID de nodo. [1]
A diferencia de otras versiones de UUID, los UUID de las versiones 1 y 2 basados en direcciones MAC de tarjetas de red dependen, para su unicidad, en parte de un identificador emitido por una autoridad de registro central, es decir, la parte del identificador único organizacional (OUI) de la dirección MAC. , que emite el IEEE para los fabricantes de equipos de red. [12] La singularidad de los UUID de las versiones 1 y 2 basados en las direcciones MAC de las tarjetas de red también depende de que los fabricantes de tarjetas de red asignen adecuadamente direcciones MAC únicas a sus tarjetas, lo que, al igual que otros procesos de fabricación, está sujeto a errores. Además, algunos sistemas operativos permiten al usuario final personalizar la dirección MAC, en particular OpenWRT . [13]
El uso de la dirección MAC de la tarjeta de red del nodo para la ID del nodo significa que se puede rastrear un UUID versión 1 hasta la computadora que lo creó. A veces, los documentos pueden rastrearse hasta las computadoras donde fueron creados o editados a través de UUID integrados en ellos mediante un software de procesamiento de textos . Este agujero de privacidad se aprovechó para localizar al creador del virus Melissa . [14]
RFC 4122 permite que la dirección MAC en un UUID versión 1 (o 2) sea reemplazada 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 del ID del nodo se establezca en 1. [1] Esto corresponde al bit de multidifusión en las direcciones MAC, y su configuración sirve para diferenciar los UUID donde el ID del nodo se genera aleatoriamente a partir de UUID basados en direcciones MAC de tarjetas de red, que normalmente tienen direcciones MAC de unidifusión . [1]
RFC 4122 reserva la versión 2 para los UUID de "seguridad DCE"; 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 UUID de la versión 2 la proporciona la especificación de servicios de seguridad y autenticación DCE 1.1. [6]
Los UUID de la versión 2 son similares a los de la versión 1, excepto que los 8 bits menos significativos de la secuencia de reloj se reemplazan por un número de "dominio local" y los 32 bits menos significativos de la marca de tiempo se reemplazan por un identificador entero significativo dentro del rango especificado. dominio local. En los sistemas POSIX , los números de dominio local 0 y 1 son para identificadores de usuario ( UID ) e identificadores de grupo ( GID ), respectivamente, y otros números de dominio local están definidos por el sitio. [6] En sistemas que no son POSIX, todos los números de dominio local están definidos por el sitio.
La capacidad de incluir un dominio/identificador de 40 bits en el UUID tiene una desventaja. Por un lado, 40 bits permiten aproximadamente 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 "marcará" sólo una vez cada 429,49 segundos, un poco más de 7 minutos, como a diferencia de cada 100 nanosegundos para 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 se pueden generar 64 UUID únicos por nodo/dominio/identificador por cada tic de reloj de 7 minutos, en comparación con 16,384 valores de secuencia de reloj para la versión 1. [15] Por lo tanto, la versión 2 puede no ser adecuada para casos en los que se requieren UUID, por nodo/dominio/identificador, a una velocidad que exceda aproximadamente uno cada siete minutos.
Los UUID de las versiones 3 y 5 se generan aplicando hash a un identificador y un nombre de espacio de nombres. La versión 3 usa MD5 como algoritmo hash y la versión 5 usa SHA-1 . [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 se puede utilizar cualquier UUID que se desee como 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 aplica un hash con MD5, lo que produce 128 bits. Luego, 6 o 7 bits se reemplazan por valores fijos, la versión de 4 bits (por ejemplo, 0011 2 para la versión 3) y la "variante" de UUID de 2 o 3 bits (por ejemplo, 10 2 indica un UUID RFC 4122, o 110 2 indicando un GUID de Microsoft heredado). Dado que, por lo tanto, están predeterminados 6 o 7 bits, sólo 121 o 122 bits contribuyen a la unicidad del UUID.
Los UUID de la versión 5 son similares, pero se utiliza 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 reemplazar los bits de versión y variante.
Los UUID de las versiones 3 y 5 tienen la propiedad de que el mismo espacio de nombres y nombre se asignarán al mismo UUID. Sin embargo, ni el espacio de nombres ni el nombre pueden determinarse a partir del UUID, incluso si se especifica uno de ellos, excepto mediante 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. [1]
Se genera aleatoriamente un UUID 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 2 o 110 2 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 de variante y versión predeterminados, dejando 122 bits para la parte generada aleatoriamente, para un total de 2 122 , o 5,3 × 1036 (5,3 undecillones ) posibles UUID versión 4 variante 1. Hay la mitad de UUID (GUID heredados) de la variante 2 de la versión 4 posible porque hay un bit aleatorio menos disponible y se consumen 3 bits para la variante.
El UUID "nulo", un caso especial, es el UUID 00000000-0000-0000-0000-000000000000; es decir, todos los bits puestos a cero. [1]
El UUID "máximo", un caso especial, es el UUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF; es decir, todos los bits puestos a uno.
La codificación binaria de los UUID varía según el sistema. Los UUID de la variante 1, hoy en día la variante más común, están codificados en formato big-endian . Por ejemplo, 00112233-4455-6677-8899-aabbccddeeffestá codificado como bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff. [16] [17]
Los UUID de la variante 2, utilizados históricamente en las bibliotecas COM/OLE de Microsoft , usan un formato little-endian , pero aparecen endian mixto con los primeros tres 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. [18] Por ejemplo, 00112233-4455-6677-8899-aabbccddeeffestá codificado como bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff. [19] [20]
La colisión ocurre cuando el mismo UUID se genera más de una vez y se asigna a diferentes referentes. En el caso de los UUID estándar versión 1 y versión 2 que utilizan direcciones MAC únicas de tarjetas de red, es poco probable que se produzcan colisiones, y la posibilidad aumenta solo cuando una implementación varía de los estándares, ya sea de forma inadvertida o intencionada.
A diferencia de los UUID de las versiones 1 y 2 generados mediante direcciones MAC, con los UUID de las versiones 1 y 2 que utilizan ID de nodo generados aleatoriamente, los UUID de las versiones 3 y 5 basados en hash y los UUID aleatorios de la versión 4, 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 basándose en el análisis del problema del cumpleaños . [21]
Por ejemplo, el número de UUID aleatorios de la versión 4 que deben generarse para tener una probabilidad del 50% de al menos una colisión es 2,71 quintillones, calculado de la siguiente manera: [22]
Esta cifra equivale a generar mil millones de UUID por segundo durante unos 86 años. Un archivo que contenga esta cantidad de UUID, a 16 bytes por UUID, ocuparía aproximadamente 45 exabytes .
El número más pequeño de UUID de la versión 4 que se deben generar para que la probabilidad de encontrar una colisión sea p se aproxima mediante la fórmula
Por lo tanto, la probabilidad de encontrar un duplicado dentro de 103 billones de UUID de la versión 4 es de una entre mil millones.
Los usos importantes incluyen herramientas de espacio de usuario del sistema de archivos ext2 / ext3 / ext4 ( e2fsprogs usa libuuid proporcionado por util-linux ), LVM , particiones cifradas LUKS , GNOME , KDE y macOS , [23] la mayoría de los cuales se derivan de la implementación original de Theodore Ts. 'Oh . [10] 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 emparejar datos de volcado de fallas con eventos de administración de fallas en el caso de pánico del kernel. [24] La "etiqueta de partición" y el "UUID de partición" se almacenan en el superbloque . Ambos son parte del sistema de archivos y no de la partición. Por ejemplo, ext2–4 contienen un UUID, mientras que NTFS o FAT32 no. El superbloque es parte del sistema de archivos y, por lo tanto, está completamente contenido dentro de la partición, por lo que deja dd if=/dev/sda1 of=/dev/sdb1tanto sda1 como sdb1 con la misma etiqueta y UUID.
Hay varios tipos de GUID utilizados en el Modelo de objetos componentes (COM) de Microsoft:
[HKEY_CLASSES_ROOT\Interface][25] )[HKEY_CLASSES_ROOT\CLSID])[HKEY_CLASSES_ROOT\TypeLib][26] )[HKEY_CLASSES_ROOT\Component Categories][27] )Los UUID se utilizan comúnmente como clave única en las tablas de bases de datos . La función NEWID en Microsoft SQL Server versión 4 Transact-SQL devuelve UUID estándar aleatorios versión 4, mientras que la función NEWSEQUENTIALID devuelve identificadores de 128 bits similares a los UUID que están comprometidos a ascender en secuencia hasta el próximo reinicio del sistema. [28] La función SYS_GUID de Oracle Database no devuelve un GUID estándar, a pesar del nombre. En su lugar, devuelve un valor RAW de 16 bytes y 128 bits basado en un identificador de host y un identificador de proceso o subproceso, algo similar a un GUID. [29] PostgreSQL contiene un tipo de datos UUID [30] y puede generar la mayoría de las versiones de UUID mediante el uso de funciones de módulos. [31] [32] MySQL proporciona una función UUID , que genera UUID versión 1 estándar. [33] 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 localidad o el rendimiento de la base de datos cuando los UUID se utilizan como claves primarias . 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 enfoque llamado "COMB" (GUID de tiempo combinado) hizo que los UUID no fueran estándar y tuvieran muchas más probabilidades de duplicarse, como reconoció Nilsson, pero Nilsson solo requería unicidad dentro de la aplicación. [34] Al reordenar y codificar los UUID de las versiones 1 y 2 para que la marca de tiempo sea lo primero, se puede evitar la pérdida de rendimiento de inserción. [35]
Algunos marcos web, como Laravel , admiten UUID con "marca de tiempo primero" que pueden almacenarse de manera eficiente en una columna de base de datos indexada. Esto crea un UUID COMB que utiliza el formato versión 4, pero donde los primeros 48 bits forman una marca de tiempo dispuesta como en UUIDv1. [36] [37] Los formatos más específicos basados en la idea COMB UUID incluyen:
Hace referencia a una interfaz en tiempo de ejecución con un identificador de interfaz único global (
IID
).
Este
IID
, que es una instancia específica de un identificador único global (
GUID
) soportado por COM, permite a un cliente preguntar a un objeto con precisión si soporta la semántica de la interfaz, sin gastos innecesarios y sin la confusión que podría surgir en un sistema. de tener múltiples versiones de la misma interfaz con el mismo nombre.
Una lista de los CATID y los nombres legibles por humanos se almacena en una ubicación conocida del registro.