Hispanopedia Wiki
Articulo de referencia

Identificador universalmente único

Un identificador único universal ( UUID ) es un número de 128 bits que se utiliza para identificar información en sistemas informáticos. También se utiliza el término identifica...

Hispanopedia WikiContenido en espanolLectura gratuita

Un identificador único universal ( UUID ) es un número de 128 bits que se utiliza para identificar información en sistemas informáticos. También se utiliza el término identificador único global ( GUID ), generalmente en software creado por Microsoft . [ 1 ]

Cuando se generan de acuerdo con los estándares, los UUID son, a efectos prácticos, únicos. Su unicidad 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 demás sistemas de numeración.

Si bien la probabilidad de que un UUID se duplique no es cero, es lo suficientemente cercana a cero como para ser insignificante. [ 2 ] Por lo tanto, cualquiera puede crear una gran cantidad de UUID y usarlos como identificadores con casi total certeza de que no duplicarán UUID que otros hayan creado o vayan a crear, siendo la única coordinación necesaria para lograr la unicidad el cumplimiento de los estándares UUID. En consecuencia, la información etiquetada con UUID por partes independientes puede coexistir en las mismas bases de datos o canales, con una probabilidad de duplicación insignificante.

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

Historia

Apollo Computer utilizó UUID en el Network Computing System (NCS), lanzado en 1987, con un diseño inspirado en los identificadores únicos de 64 bits de Domain/OS , un sistema operativo Apollo anterior . [ 3 ] Las plataformas Microsoft Windows adoptaron el diseño NCS (y posteriormente, el DCE) como "Identificadores Únicos Globales" (GUID) a principios de los noventa.

Un poco más tarde, la Open Software Foundation (OSF) utilizó UUID en su Entorno de Computación Distribuida (DCE), con un diseño parcialmente basado en los UUID de NCS. Esto se documentó en la especificación DCE 1.1 RPC en 1996, y en la especificación DCE 1.1 de Servicios de Autenticación y Seguridad, publicada en 1997. [ 4 ] [ 5 ] [ 6 ] ISO/IEC documentó el diseño de DCE en 1996, en ISO / IEC 11578:1996 " Tecnología de la información – Interconexión de sistemas abiertos – Llamada a procedimiento remoto ". [ 7 ]

En julio de 2005, el Grupo de Trabajo de Ingeniería de Internet (IETF) publicó el RFC 4122 de la vía de estándares [ 1 ] , que también registró un espacio de nombres URN para UUID. Mientras tanto, la UIT también había estandarizado los UUID, basándose en los estándares anteriores y las primeras versiones del RFC 4122, en la Recomendación ITU-T X.667 ISO/IEC 9834-8. Esto era técnicamente equivalente al RFC 4122 [ 8 ].

La especificación actual de la IETF es la RFC 9562 [ 9 ] , una propuesta de estándar publicada en mayo de 2024. Esta definió tres nuevas versiones de UUID (6-8) de la variante DCE. Los UUID que se utilizan actualmente son el diseño DCE/IETF, con la posibilidad de compatibilidad con versiones anteriores de los UUID de Apollo NCS y los GUID de Microsoft.

Los autores de RFC 4122 fueron Paul Leach, Michael Mealling y Rich Salz , y los autores del borrador inicial de Internet de 1997 [ 10 ] fueron Leach y Salz. Leach había sido el arquitecto de Domain/OS, continuó en Apollo como diseñador de NCS y luego, como arquitecto distinguido de Microsoft, contribuyó al diseño de OLE/COM/DCOM, llevando el concepto de UUID a ese proyecto. [ 11 ] Leach también fue uno de los autores de RFC 9562. Salz fue miembro del equipo DCE en la Open Software Foundation. [ 12 ] Apollo se fusionó en 1989 con Hewlett-Packard , miembro fundador de la OSF. Antiguos miembros del equipo NCS, que se convirtieron en empleados de HP, llevaron los UUID a OSF DCE. Mealling fue un miembro destacado del IETF, ocupando un puesto en el Grupo Directivo de Ingeniería de Internet, y estuvo muy involucrado en el trabajo del IETF sobre URN. [ 13 ] RFC 4122 reunió todos estos hilos.

Formato

Un UUID es un número de 128 bits. El significado de estos bits viene determinado por la variante , de las cuales se definen tres. La más común es la variante 1, mientras que las demás se utilizan para la compatibilidad con formatos anteriores o para futuras definiciones. Las variantes 1 y 2 tienen "versiones", que definen aún más la interpretación del UUID.

Variantes

El campo de variante se encuentra en un número variable de los bits más significativos del noveno byte. En las representaciones textuales del UUID, forma parte del dígito hexadecimal que aparece después del tercer guion. Indica el formato del UUID. Se definen las siguientes variantes:

  • La variante 0 (indicada por el patrón de un bit 0 xxx 2 , 0 16 a 7 16 ) es para compatibilidad con versiones anteriores con el formato UUID 1.5 del Apollo Network Computing System, ahora obsoleto , desarrollado alrededor de 1987. El campo de variante de los UUID actuales se superpone al octeto de la familia de direcciones en los UUID de NCS de tal manera que cualquier UUID de NCS que aún esté en uso tiene un 0 en el primer bit del campo de variante. El espacio de numeración de la variante 0 también incluye el UUID nulo.
  • Los UUID de la variante 1 (10 xx 2 , que aparecen como 8 16 , 9 16 , a 16 o b 16 ) se denominan UUID RFC 4122/DCE 1.1 o UUID "Leach-Salz", en honor a los autores del borrador original de Internet . Estos son los UUID que se utilizan actualmente.
  • La variante 2 (110 x 2 , c 16 o d 16 ) es para garantizar la compatibilidad con versiones anteriores de los GUID utilizados en Microsoft COM/DCOM. Este formato se usó en los primeros GUID de la plataforma Microsoft Windows . Las herramientas actuales de Microsoft generan UUID de la variante 1, no de esta variante. La principal diferencia entre esta variante y la variante 1, además del bit de variante adicional, radica en el orden de los bytes dentro del UUID. El RFC 9562 declaró esta variante fuera de su alcance, por lo que las tres nuevas versiones definidas para la variante 1 no se aplican a la variante 2.
  • La variante 3 (111 x 2 , e 16 o f 16 ) incluye el UUID máximo, pero por lo demás no está definida y está reservada para uso futuro.

Versiones

Las variantes OSF DCE y Microsoft COM/DCOM (1 y 2, respectivamente) tienen versiones , indicadas por el valor de los cuatro bits más altos del séptimo byte del UUID. En las representaciones textuales del UUID, este es el dígito hexadecimal después del segundo guion. Los UUID Apollo NCS variante 0 no tienen versiones, sino que se subtipifican mediante "familias de direcciones" en lugar de versiones. El RFC 9562 [ 9 ] , que definió las versiones 6, 7 y 8, declaró que las variantes distintas de la variante OSF DCE 1 estaban "fuera del alcance" del RFC, dejando a Microsoft la definición de nuevas versiones para la variante 2. Sin embargo, las versiones 1 a 5, estandarizadas en el RFC 4122 [ 1 ] , son las mismas en la variante de Microsoft, excepto por el orden de los bytes.

Versiones 1 y 6 (fecha-hora y dirección MAC)

La versión 1 concatena la dirección MAC de 48 bits del "nodo" (es decir, el ordenador que genera el UUID) con una marca de tiempo de 60 bits. En sistemas con direcciones MAC EUI-64 de 64 bits, se utilizan los 48 bits menos significativos. También se puede utilizar un número aleatorio de 48 bits.

La marca de tiempo es 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 . RFC 4122 establece que el valor de tiempo se reinicia en el año 3409 d. C., [ 1 ] 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 signo, lo que sitúa el momento del reinicio en el año 5236 d. C. [ 14 ]

Una secuencia de reloj "única" 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 donde hay varios procesadores y generadores de UUID por nodo. Cuando los UUID se generan más rápido de lo que el reloj del sistema puede avanzar, los bits inferiores de la marca de tiempo y la secuencia de reloj se pueden incrementar para simular una mayor precisión y garantizar la unicidad. Dado que cada UUID de versión 1 corresponde a un único punto en el espacio (el nodo) y el tiempo (intervalos y secuencia de reloj), la probabilidad de que dos UUID de versión 1 generados correctamente sean involuntariamente iguales es prácticamente nula. Dado que el tiempo y la secuencia de reloj suman 74 bits, 2 74 (1,8 × 10Se pueden generar 22 (o 18 sextillones) UUID de versión 1 por ID de nodo, a una tasa promedio máxima de 163 mil millones por segundo por ID de nodo. [ 1 ]

La estructura de un UUID de versión 1 es:

La versión 6 es idéntica a la versión 1, salvo por el orden de los bits de la marca de tiempo. En la versión 6, los bits de la marca de tiempo se ordenan de mayor a menor importancia. Esto permite a los sistemas ordenar los UUID de la versión 6 según su fecha de creación simplemente ordenándolos lexicográficamente. Al restablecer el orden de bytes NCS original (de mayor a menor importancia) de la marca de tiempo para facilitar la ordenación, la versión 6 se asemeja aún más a los UUID NCS de la variante 0 "heredada" que la versión 1.

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

Los RFC 4122 y 9562 [ 9 ] reservan la versión 2 para los UUID de "seguridad DCE"; pero no proporcionan detalles. El RFC 9562 los declara "fuera de alcance". Muchas implementaciones y bibliotecas de UUID omiten la versión 2. Sin embargo, la especificación de los UUID de versión 2 se proporciona en la especificación de Servicios de Autenticación y Seguridad 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 gregoriana de 60 bits 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 los identificadores de usuario ( UID ) y los identificadores de grupo ( GID ) respectivamente, y los demás números de dominio local están definidos por el sitio. [ 6 ] En los sistemas que no son POSIX, todos los números de dominio local están definidos por el sitio.

Así, los UUID de la versión 2 son una forma de combinar un identificador local de 32 bits, con ámbito de nodo y de un tipo específico de 8 bits ("dominio"), con el identificador del nodo y una marca de tiempo de origen gregoriano, transformando el identificador con ámbito de nodo en uno universalmente único. La desventaja es que la marca de tiempo tiene baja resolución en comparación con las marcas de tiempo de la versión 1, registrándose solo una vez cada 429,49  segundos, un poco más de 7  minutos, muy diferente de los intervalos de 100 nanosegundos de la versión 1. [ 15 ]

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

Los UUID de versión 3 y versión 5 se generan mediante el hash de un identificador de espacio de nombres y un nombre. La versión 3 utiliza MD5 como algoritmo de hash, y la versión 5 utiliza SHA-1 . [ 9 ] Esto resulta útil cuando los sistemas necesitan generar de forma determinista el mismo UUID a partir de un conjunto de otros nombres o identificadores, sin coordinación.

El identificador de espacio de nombres es en sí mismo un UUID. El RFC proporciona UUID constantes para representar los espacios de nombres de URL , nombres de dominio completos , identificadores de objetos y nombres distinguidos X.500 ; sin embargo, se puede usar cualquier UUID deseado como designador de espacio de nombres. Existe un registro de IANA para identificadores de espacio de nombres adicionales.

Para determinar el UUID de la versión 3 correspondiente a un espacio de nombres y nombre dados, el UUID del espacio de nombres se transforma en una cadena de bytes, se concatena con el nombre de entrada y luego se aplica la función hash MD5, lo que produce 128 bits. Luego, seis o siete bits se reemplazan por valores fijos: la versión de cuatro bits (por ejemplo, 0011 2 para la versión 3) y la "variante" del UUID de dos o tres bits (por ejemplo, 10 2 que indica un UUID RFC 9562 [ 9 ] , o 110 2 que indica un GUID heredado de Microsoft). 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 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 que se reemplacen los bits de versión y variante.

Los UUID de versión 3 y versión 5 tienen la propiedad de que, dada la versión, el mismo espacio de nombres y 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 por fuerza bruta . El RFC 4122 recomienda la versión 5 (SHA-1) sobre la versión 3 (MD5). Esto se debe a que se cree que MD5 es más propenso a colisiones que SHA-1, aunque MD5 es algo más rápido. El RFC advierte contra el uso de UUID de cualquier versión como medidas de seguridad. [ 1 ] : 16

Versión 4 (aleatoria)

Un UUID de versión 4 se genera aleatoriamente. Al igual que en otros UUID, se utilizan cuatro bits para indicar la versión 4 y dos o tres 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á seis bits predeterminados de variante y versión, dejando 122 bits para la parte generada aleatoriamente, para un total de 2 122 , o 5,3 × 1036 (5,3 undecillones ) posibles UUID de la versión 4, variante 1. Hay la mitad de posibles UUID de la versión 4, variante 2 (GUID heredados) porque hay un bit aleatorio menos disponible, ya que se consumen tres bits para la variante. 

Versión 7 (marca de tiempo y aleatorio)

Los UUID de la versión 7 están diseñados para ser claves monótonamente ascendentes, ordenadas por fecha de creación y ordenables léxicamente en bases de datos grandes y sistemas distribuidos, lo que contribuye a la localidad y el rendimiento. Con la versión 7 como claves de base de datos, los registros "nuevos" se insertan al final lógico de la secuencia de claves, y los registros cercanos en el tiempo se encuentran próximos entre sí en la secuencia. Esto contrasta con la versión 4, que, al usarse como claves de base de datos, se distribuye de forma uniforme y aleatoria a lo largo de la secuencia de claves, incluso cuando los registros subyacentes son cercanos en el tiempo, lo que afecta negativamente al rendimiento en muchos tipos de bases de datos.

Se construyen de la siguiente manera:

Además de la marca de tiempo, se prevé un total de 74 bits para las tres construcciones opcionales (precisión adicional de la marca de tiempo, contador inicializado, datos aleatorios). Sin embargo, aparte del orden de las construcciones y el requisito de usar como máximo 12 bits para la precisión adicional de la marca de tiempo, el número de bits asignados a cada construcción (incluyendo posiblemente 0) y los detalles de las construcciones quedan a criterio del implementador. Las marcas de tiempo de 48 bits pueden modificarse, difuminarse o suavizarse para garantizar la monotonicidad y la privacidad, y se indica explícitamente que no existe ningún requisito sobre la proximidad de la marca de tiempo a la hora real (Unix). No obstante, la intención es clara: las marcas de tiempo deben ser monótonas y aproximarse a la hora Unix. El RFC establece que se debe usar la versión 8 de UUID personalizada para diseños basados ​​en marcas de tiempo que no sean de hora Unix. A diferencia de otras versiones de UUID, las versiones 7 no incorporan direcciones MAC y evitan los problemas de privacidad asociados a ellas.

Versión 8 (personalizada)

En un UUID personalizado, la versión es 8, y los bits de variante deben ser 10, sumando un total de 6 bits. Los 122 bits restantes no se especifican.

Según la RFC, los UUID de la versión 8 están destinados a casos de uso experimentales y específicos del proveedor. La RFC sugiere, por ejemplo, que esta versión podría utilizarse para un identificador basado en nombre/hash generado con una función hash más reciente que las especificadas para las versiones 3 (MD5) y 5 (SHA-1) de UUID. La RFC también sugiere que la versión 8 puede utilizarse para diseños de UUID basados ​​en marcas de tiempo que no se ajusten a las versiones 6 o 7, como por ejemplo, una época diferente.

Pero la versión 8 no se limita a esos escenarios. En esencia, los UUID de la versión 8 constan de 122 bits opacos, combinados con seis bits de versión y variante, lo que permite diferenciarlos de otras formas de UUID.

A diferencia de otras versiones, la RFC no exige una disposición de bits o un algoritmo de generación específicos, y no se debe asumir que sean únicos. A diferencia de los UUID de la versión 4, que deben ser de 122 bits provenientes de una fuente de aleatoriedad de alta entropía y donde la unicidad y la resistencia a colisiones están sujetas a análisis matemático, la unicidad, la imposibilidad de adivinar, la resistencia a colisiones, la privacidad, etc., de los UUID de la versión 8, en general, solo se pueden confiar en la fuente (si se conoce), la coordinación fuera de banda o la documentación externa más allá del estándar. Además, como con otras versiones de UUID, no existe el concepto de subtipos de versión. Esto significa que, para la versión 8, en una situación donde los UUID de la versión 8 de múltiples fuentes y métodos de generación se han agrupado en un solo flujo o base de datos y algunos resultan problemáticos, no hay forma de separar los UUID por fuente, excepto, quizás, resolviéndolos, si eso es posible.

Uso de direcciones MAC

A diferencia de las otras versiones de UUID, las versiones 1, 2 y 6 se basan en direcciones MAC de tarjetas de red , y su unicidad depende en parte de un identificador emitido por una autoridad de registro central, concretamente la parte del Identificador Único de Organización (OUI) de la dirección MAC, que es emitida por el IEEE principalmente a los fabricantes de equipos de red. [ 16 ] La unicidad de los UUID 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, lo que, como otros procesos de fabricación, está sujeto a errores. Las direcciones MAC también pueden provenir de fuentes distintas a las tarjetas de red. Por ejemplo, las máquinas virtuales reciben una dirección MAC de un rango que es configurable en el hipervisor , [ 17 ] y algunos sistemas operativos permiten al usuario final personalizar la dirección MAC, en particular OpenWrt . [ 18 ] Cuando un dispositivo tiene una "dirección MAC" EUI-64 de 64 bits, usar los 48 bits menos significativos, como recomienda la RFC, puede resultar en la duplicación de la parte del identificador de nodo del UUID. Por lo tanto, los identificadores de nodo basados ​​en direcciones MAC pueden no ser globalmente únicos.

El uso de la dirección MAC de la tarjeta de red del nodo como identificador del nodo a menudo implica que los UUID de las versiones 1, 2 y 6 pueden rastrearse hasta el ordenador que los generó. Dichos UUID pueden utilizarse para inferir el tipo de hardware empleado para su generación. En ocasiones, los documentos pueden rastrearse hasta los ordenadores donde se crearon o editaron mediante los UUID incrustados en ellos por el software de procesamiento de textos . Esta vulnerabilidad de privacidad se utilizó para localizar al creador del virus Melissa . [ 19 ]

RFC 9562 [ 9 ] permite que la dirección MAC en un UUID de versión 1, 2 o 6 se reemplace por un ID de nodo aleatorio de 48 bits, ya sea porque el nodo no tiene una dirección MAC o porque no es conveniente incluirla. En ese caso, el RFC requiere que el bit menos significativo del primer octeto del ID de 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 de nodo se genera aleatoriamente de los UUID basados ​​en direcciones MAC de tarjetas de red, que normalmente tienen direcciones MAC de unidifusión . [ 1 ]

Uso de marcas de tiempo

Las versiones 1, 2, 6 y 7 se basan en el momento en que se generó el UUID y lo exponen, lo que a menudo corresponde a la creación de un registro o un evento histórico. Si se asocia con personas o su actividad, es posible inferir la edad de una persona o la hora precisa de sus actividades a partir de los UUID. A partir de los UUID monótonamente ascendentes basados ​​en el tiempo, es posible determinar cuándo se puso en marcha un sistema o qué objetos del sistema son nuevos o se han actualizado recientemente. Si los objetos identificados representan pedidos de productos o registros de usuarios, por ejemplo, es posible determinar el crecimiento de usuarios o el volumen de ventas a lo largo del tiempo a partir de los UUID. Por lo tanto, los UUID basados ​​en el tiempo, si son visibles públicamente, pueden filtrar información personal o empresarial, generar preocupaciones sobre la privacidad y facilitar la minería de datos no deseada .

En cuanto al ordenamiento temporal y la posibilidad de ordenar los UUID, las versiones 1 y 2 comienzan "en el medio" con los 32 bits menos significativos de la marca de tiempo. Estas dos versiones, junto con las versiones 3 a 5 y la 8, no se ordenan léxicamente en orden temporal. La función de la marca de tiempo en estas versiones de UUID no era facilitar el ordenamiento temporal de los UUID, sino lograr una unicidad universal fijando su generación en el espacio y el tiempo.

Las versiones 6 y 7 priorizan el papel de la marca de tiempo en la indexación de bases de datos, permitiendo la clasificación léxica de registros en orden cronológico. Sin embargo, el RFC 9562 proporciona una flexibilidad de implementación significativa para la versión 7, definiendo un marco general en lugar de una disposición de bits rígida para la precisión opcional de la marca de tiempo de submilisegundos, contadores y aleatoriedad.

La especificación permite ajustar o "aplicar difusas" a la marca de tiempo Unix de 48 bits para mantener la monotonicidad (garantizando que los identificadores creados en rápida sucesión siempre aumenten) o para mejorar la privacidad. Dado que el RFC no define una desviación máxima estricta con respecto a la hora Unix real, las diferentes implementaciones pueden variar en cómo equilibran la precisión cronológica con estos otros requisitos. [ 20 ]

Por consiguiente, la ordenación léxica de los UUID de las versiones 6 y 7 es más consistente cuando se generan con la misma biblioteca o sistema. Mezclar UUID de distintas fuentes o intercalar diferentes versiones y variantes en una misma base de datos puede degradar el orden cronológico y la localidad del índice que estas versiones fueron diseñadas para proporcionar.

RFC 9562 no exige un número mínimo de bits aleatorios para la versión 7; permite que los campos de precisión submilisegundo y contador de monotonicidad ocupen el resto de la estructura de 128 bits. En consecuencia, la resistencia a colisiones y la capacidad de adivinación dependen completamente de la asignación de estos bits en la implementación específica. [ 21 ]

Valores especiales

El UUID nulo es 00000000-0000-0000-0000-000000000000(es decir, todos los bits en blanco), que puede ser útil para expresar el concepto de "no existe tal valor". [ 9 ] Este es un UUID NCS "variante 0" con una familia de direcciones de "0", definido en NCS como "no especificado o no inicializado". El UUID máximo, a veces también llamado UUID omni, es FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF(es decir, todos los bits activados). Este está destinado a ser utilizado para expresar "fin de la lista de UUID". [ 9 ]

Codificación

Representación binaria

Inicialmente, Apollo Computer diseñó el UUID con el siguiente formato de cable, basado en una marca de tiempo y un identificador de nodo, de forma similar a las versiones 1 y 6 [ 4 ] [ 22 ].

RFC 4122 incorporó los UUID NCS heredados como la "variante 0" del nuevo formato, superponiendo los bits de variante del nuevo formato con el campo Familia de direcciones NCS. Dado que el valor más alto de familia de direcciones definido en NCS es 13 (hexadecimal 00 a 0D), el bit más significativo del octeto de variante siempre es 0 para los UUID NCS existentes, mientras que este bit es 1 en las tres nuevas variantes IETF. En efecto, las familias de direcciones NCS 0-127 se convirtieron en la nueva "variante 0", mientras que el espacio de numeración de las familias de direcciones NCS 128-255, que no estaba definido en NCS, se reasignó a los UUID IETF y Microsoft de las variantes 1 a 3. El resultado fue que los UUID NCS heredados y los UUID de las variantes 1 a 3 se separaron y pudieron coexistir en las mismas bases de datos y en los mismos canales de comunicación.

El UUID heredado de Apollo NCS tiene el formato descrito en la tabla anterior. La variante OSF DCE UUID se describe en RFC 9562 [ 9 ] . La variante Microsoft COM / DCOM UUID se describe en la documentación de Microsoft, pero para las versiones 1 a 5, es generalmente la misma que la variante DCE, excepto por el bit de variante adicional y el orden de bytes. (Véase la siguiente sección). La variante 2 no está disponible en las versiones 6 a 8.

La interpretación de los distintos bloques de bits varía en las variantes 1 y 2 según la "versión". En la variante 2, los bytes de data_a, data_b y version|data_c se intercambian, mientras que los bytes de variant|data_d y data_e no se intercambian.

Ordenación de bytes

Los UUID de la variante 1 se codifican secuencialmente en big-endian . Por ejemplo, 00112233-4455-6677-8899-aabbccddeeffse codifica como los bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff. [ 23 ] [ 24 ]

En contraste, los UUID de variante 2 ("GUID"), utilizados históricamente en las bibliotecas COM/OLE de Microsoft , tienen un formato de orden de bytes mixto , donde los tres primeros campos (correspondientes a los subcampos de marca de tiempo de la versión 1) son little-endian , mientras que los dos últimos campos se emiten como matrices de bytes big-endian . El UUID de ejemplo anterior, si fuera un UUID de variante 2, se codificaría en la red como 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff. [ 25 ] [ 26 ] Todas las versiones de la variante 2 se emiten con este orden de bytes, incluidas las versiones que no contienen campos numéricos, como 3, 4 y 5.

Representación textual

En la mayoría de los casos, los UUID se representan como valores hexadecimales separados por guiones. El formato más utilizado es 8-4-4-4-12, una cadena de 32 dígitos hexadecimales con cuatro guiones xxxxxxxx-xxxx-vxxx-wxxx-xxxxxxxxxxxx. Los guiones separan los campos de la versión 1, pero el mismo formato se usa comúnmente para todas las versiones. Cada dígito hexadecimal representa 4 bits; vrepresenta el nibble de la versión; y los bits de orden superior del uno al tres wson la variante. El formato del registro de Windows es el mismo, pero envuelve el UUID entre {}llaves. Las diferencias en el orden de bytes de la variante 2 son aplicables en el almacenamiento binario o la transmisión por cable, y no afectan la presentación textual del UUID.

Aunque todavía se omiten ocasionalmente, el formato con guiones se introdujo con el nuevo sistema de variantes. Antes de eso, el formato Apollo anterior usaba un formato ligeramente diferente 34dc23469000.0d.00.00.7c.5f.00.00.00. La primera parte es la hora (time_high y time_low combinados). El campo reservado se omite. El campo de familia viene directamente después del primer punto, así que en este caso 0d(13 en decimal) para DDS (Data Distribution Service) . Las partes restantes, cada una separada por un punto, son los bytes del nodo.

Se prefieren los dígitos hexadecimales en minúscula. La recomendación X.667 de la UIT-T exige minúsculas para la generación, pero también requiere que se acepte la versión en mayúsculas como entrada. Dado que los UUID son números de 128 bits, son posibles otros formatos, y ocasionalmente se observan, como dígitos decimales o binarios.

RFC 4122 [ 1 ] registra el espacio de nombres "uuid" para URN. Esto permite formar 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 un OID a partir de un UUID, lo que a su vez proporciona otra forma de crear un URN a partir de él. El OID para el ejemplo anterior es 2.25.113059749145936325402354257176981405696. La forma decimal sin signo del UUID tiene el prefijo 2.25, que representa el {joint-iso-itu-t(2) uuid(25)}"arco" dentro del espacio de nombres OID. A este se le puede añadir otro prefijo urn:oid:para crear una segunda forma de URN para UUIDs. En general, uuidse recomienda el URN sobre el oidURN.

Colisiones

Se produce una colisión cuando se genera el mismo UUID más de una vez y se asigna a diferentes referentes. En el caso de muchos UUID estándar de las versiones 1, 2 o 6 que utilizan direcciones MAC y/o marcas de tiempo únicas, las colisiones solo pueden ocurrir como resultado de un error, como problemas de fabricación, relojes desajustados o fallos de software.

También pueden aparecer UUID duplicados debido a errores en las versiones de UUID generadas mediante procesos como la generación de números aleatorios o el hash. Es importante, por ejemplo, contar con una fuente de aleatoriedad de alta entropía al generar UUID de versión 4. Sin embargo, también pueden producirse colisiones sin error con dichos UUID, simplemente por casualidad: «mala suerte».

La probabilidad de esto es normalmente tan pequeña que puede ignorarse y puede calcularse con precisión basándose en el análisis del problema del cumpleaños . [ 27 ] Por ejemplo, el número de UUID de versión 4 aleatorios que deben generarse para tener una probabilidad del 50 % de al menos una colisión es 2,71  quintillones, calculado de la siguiente manera: [ 28 ]

norte≈12+14+ln⁡(2)×2123≈2.71×1018.{\displaystyle n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+\ln(2)\times 2^{123}}}\approx 2.71\times 10^{18}.}

Esta cifra equivaldría a generar mil  millones de UUID por segundo durante aproximadamente 86  años. Un archivo que contuviera esta cantidad de UUID, a razón de 16 bytes por UUID, sería de unos 43,4 exabytes (37,7 EiB ), un archivo que, al listar solo identificadores, sería varios órdenes de magnitud mayor que las bases de datos más grandes que existen actualmente, que rondan los 100 PB (por ejemplo, los índices web de Google). Si se generan según los estándares, es más probable que los UUID duplicados sean el resultado de errores de bits (un llamado fallo de evento único ) causados ​​por rayos cósmicos que atraviesan la memoria o el almacenamiento en disco, que el resultado de un error fortuito en el momento de la generación del UUID.  

El número mínimo de UUID de versión 4 que deben generarse para que la probabilidad de encontrar al menos una colisión sea p se aproxima mediante la fórmula

2123×ln⁡11−pag.{\displaystyle {\sqrt {2^{123}\times \ln {\frac {1}{1-p}}}}.}

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

Usos

Sistemas de archivos

Varios tipos de sistemas de archivos (por ejemplo, ext4 y Btrfs ) utilizan un UUID para identificar de forma única cada sistema de archivos ante el sistema operativo. ( NTFS y FAT32 no lo hacen, sino que utilizan un UID (identificador único) más corto). [ 29 ]

Las herramientas de espacio de usuario del sistema de archivos, [ 30 ] la mayoría de las cuales se derivan de la implementación original de Theodore Ts'o , [ 14 ] hacen uso de UUID.

Un /etc/fstabarchivo podría asignar puntos de montaje basándose en estos UUID (o un UID para una partición del sistema EFI FAT32 (ESP)):

# device-uuid mount-point fs-type options dump pass UUID = b18e3b6c-ccb7-4308-b527-35e5e6ee2145 / btrfs defaults 0 0 UUID = 103C-86D6 /efi vfat utf8 0 2 UUID = 64f3cb6a-e70e-45e5-8b90-d86cddbab7bb swap swap defaults 0 0 UUID = eda746c6-1f1b-4cf1-9225-d8b0b46511cc /mnt/Stuff btrfs defaults 0 0

Tablas de partición

La tabla de particiones GUID (GPT) utiliza UUID (denominados allí "GUID") para identificar particiones y tipos de partición. El sistema operativo asigna localmente identificadores únicos de partición. Los identificadores de tipo de partición son números conocidos, generalmente asignados por el sistema operativo o los fabricantes de hardware.

Microsoft COM

En el modelo de objetos componentes (COM) de Microsoft se utilizan varios tipos de GUID :

  • IID – identificador de interfaz; (Los que están registrados en un sistema se almacenan en el Registro de Windows en [HKEY_CLASSES_ROOT\Interface][ 31 ] )
  • CLSID– identificador de clase; (Almacenado en [HKEY_CLASSES_ROOT\CLSID]). En la práctica no está completamente separado del espacio IID , porque la comunicación remota de la interfaz puede requerir un objeto proxy/stub que algunos conjuntos de herramientas solían crear con un CLSID igual al IID de la interfaz .
  • LIBID – identificador de biblioteca de tipo; (Almacenado en [HKEY_CLASSES_ROOT\TypeLib][ 32 ] )
  • CATID – identificador de categoría; (su presencia en una clase la identifica como perteneciente a ciertas categorías de clase, enumeradas en [HKEY_CLASSES_ROOT\Component Categories][ 33 ] )

Bases de datos

Los UUID se utilizan comúnmente como clave única en tablas de bases de datos . La función NEWID en Microsoft SQL Server versión 4 Transact-SQL devuelve UUID estándar aleatorios de versión 4, mientras que la función NEWSEQUENTIALID devuelve identificadores de 128 bits similares a los UUID que se comprometen a ascender en secuencia hasta el siguiente reinicio del sistema. [ 34 ] 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 hilo, algo similar a un GUID. [ 35 ] PostgreSQL contiene un tipo de datos UUID [ 36 ] y puede generar la mayoría de las versiones de UUID mediante el uso de funciones de módulos. [ 37 ] [ 38 ] MySQL proporciona una función UUID que genera UUID estándar de versión 1. [ 39 ]

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 de la base de datos o el rendimiento cuando los UUID se utilizan como claves primarias . Por ejemplo, en 2002 Jimmy Nilsson informó de una mejora significativa en el rendimiento con Microsoft SQL Server cuando los UUID de la versión 4 que se utilizaban como claves se modificaron para incluir un sufijo no aleatorio basado en la hora del sistema. Al reordenar y codificar los UUID de las versiones 1 y 2 de manera que la marca de tiempo aparezca primero, se puede evitar la pérdida de rendimiento de inserción. [ 40 ] Esta es la razón de las versiones 6 y 7 de la variante 1 (DCE), estandarizadas en RFC 9562 [ 9 ] .

Otros ejemplos

UEFI y ACPI son ejemplos que utilizan GUID. [ 41 ]

Véase también

Referencias

  1. 1 2 3 4 5 6 7 8 9 Leach, P.; Mealling, M.; Salz, R. (2005). Un espacio de nombres URN de identificador único universal (UUID) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC4122 . RFC 4122. Recuperado el 17 de enero de 2017 .
  2. ↑ "Identificadores Universalmente Únicos (UUID)" . H2 . Consultado el 21 de marzo de 2021 .
  3. ↑ Leach, PJ; Levine, PH; Hamilton, JA; Stumpf, BL (18–20 de agosto de 1982). «UID como nombres internos en un sistema de archivos distribuido». Actas del primer simposio ACM SIGACT-SIGOPS sobre Principios de computación distribuida - PODC '82 . págs. 34–41 . doi : 10.1145/800220.806679 . ISBN  0-89791-081-8.
  4. 1 2 Zahn, Lisa; Dineen, Terence; Leach, Paul; Martin, Elizabeth; Mishkin, Nathaniel; Pato, Joseph; Wyant, Geoffrey (1990). Arquitectura de computación en red . Prentice Hall . pág. 10. ISBN  978-0-13-611674-5.
  5. ↑ "DCE 1.1: Llamada a procedimiento remoto" . The Open Group. 1997.
  6. 1 2 3 "DCE 1.1: Servicios de autenticación y seguridad" . The Open Group. 1997.
  7. ↑ ISO/IEC 11578:1996 Tecnología de la información – Interconexión de sistemas abiertos – Llamada a procedimiento remoto (RPC) (Informe técnico). Organización Internacional de Normalización . 1996.
  8. ↑ «Tecnología de la información – Procedimientos para el funcionamiento de las autoridades de registro de identificadores de objetos: Generación de identificadores universalmente únicos y su uso en identificadores de objetos» . UIT . Octubre de 2014. Consultado el 8 de mayo de 2026 .
  9. 1 2 3 4 5 6 7 8 9 10 Davis, K.; Peabody, B.; Leach, P. (2024). Identificadores Universalmente Únicos (UUID) . Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC9562 . RFC 9562. Recuperado el 9 de mayo de 2024 .
  10. ↑ P. Leach; R. Salz (febrero de 1998). UUIDs y GUIDs . IETF . ID draft-leach-uuids-guids-01.
  11. ↑ "Paul Leach — IETF Datatracker" . datatracker.ietf.org . Consultado el 8 de mayo de 2026 .
  12. ↑ "Biografía de Rich Salz" . XML.com . Consultado el 8 de mayo de 2026. Ha participado en diversos proyectos de estandarización de OSF, IETF, W3C y OASIS...
  13. ↑ "Michael Mealling — IETF Datatracker" . datatracker.ietf.org . Consultado el 8 de mayo de 2026 .
  14. 1 2 "ext2/e2fsprogs.git - Utilidades de espacio de usuario del sistema de archivos Ext2/3/4" . Kernel.org . Consultado el 9 de enero de 2017 .
  15. ↑ Kuchling, AM "Novedades de Python 2.5" . Python.org . Consultado el 23 de enero de 2016 .
  16. ↑ "Autoridad de Registro" . Asociación de Estándares IEEE . Archivado del original el 4 de abril de 2011.
  17. ↑ "Direcciones MAC para máquinas virtuales" . Superusuario .
  18. ↑ "Configuración de la dirección MAC" . OpenWrt. 15 de septiembre de 2021.
  19. ↑ Reiter, Luke (2 de abril de 1999). "Rastreando los alter egos de Melissa" . ZDNet . Consultado el 16 de enero de 2017 .
  20. ↑ Davis, K.; Peabody, B.; Leach, P. (mayo de 2024). "RFC 9562: Identificadores Universalmente Únicos (UUID), Sección 6.2: Monotonicidad y Contadores" . IETF . Consultado el 8 de mayo de 2026 .
  21. ↑ Davis, K.; Peabody, B.; Leach, P. (mayo de 2024). "RFC 9562: Identificadores Universalmente Únicos (UUID), Sección 8: Consideraciones de Seguridad" . IETF . Recuperado el 8 de mayo de 2026 .
  22. ↑ "uuid.c" . opensource.apple.com . Archivado del original el 24 de febrero de 2021. Consultado el 8 de junio de 2017 .
  23. ↑ Steele, Nick. "Desglosando UUIDs" .
  24. ↑ "Versiones de UUID explicadas | UUIDTools.com" . www.uuidtools.com .
  25. ↑ Leach, Paul. "UUIDs y GUIDs" .
  26. ↑ "Método Guid.ToByteArray (Sistema)" . learn.microsoft.com .
  27. ↑ Jesús, Paulo; Baquero, Carlos; Almaeida, Paulo. "Generación de ID en entornos móviles" (PDF) . Repositorio.Sdum.Uminho.pt .
  28. ↑ Mathis, Frank H. (junio de 1991). "Un problema generalizado del cumpleaños". SIAM Review . 33 (2): 265– 270. CiteSeerX 10.1.1.5.5851 . doi : 10.1137/1033051 . ISSN 0036-1445 . JSTOR 2031144. OCLC 37699182 .    
  29. ↑ Edge, Jake (18 de mayo de 2022). "Instantáneas, inodos e identificadores del sistema de archivos" . LWN.net . Consultado el 31 de enero de 2026 .
  30. ↑ "gen_uuid.c" . opensource.apple.com . Archivado del original el 6 de julio de 2017. Consultado el 17 de septiembre de 2017 .
  31. ↑ "Punteros de interfaz e interfaces" . Centro de desarrollo de Windows - Tecnologías de aplicaciones de escritorio . Microsoft . Consultado el 15 de diciembre de 2015. Se 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 ) compatible con COM, permite a un cliente preguntar a un objeto con precisión si admite la semántica de la interfaz, sin sobrecarga innecesaria y sin la confusión que podría surgir en un sistema al tener varias versiones de la misma interfaz con el mismo nombre.
  32. ↑ "Registro de una biblioteca de tipos" . Microsoft Developer Network . Microsoft . Consultado el 15 de diciembre de 2015 .
  33. ↑ "Categorización por capacidades de componentes" . Centro de desarrollo de Windows - Tecnologías de aplicaciones de escritorio . Microsoft . Consultado el 15 de diciembre de 2015. Una lista de los CATID y los nombres legibles para humanos se almacena en una ubicación conocida del registro.
  34. ↑ "NEWSEQUENTIALID (Transact-SQL)" . Microsoft Developer Network . Microsoft . 8 de agosto de 2015. Consultado el 14 de enero de 2017 .
  35. ↑ "Referencia SQL de la base de datos Oracle" . Oracle .
  36. ↑ "Sección 8.12 Tipo UUID" . Documentación de PostgreSQL 9.4.10 . Grupo de Desarrollo Global de PostgreSQL. 13 de febrero de 2020.
  37. ↑ "uuid-ossp" . PostgreSQL: Documentación: 9.6 . Grupo de Desarrollo Global de PostgreSQL. 12 de agosto de 2021.
  38. ↑ "pgcrypto" . PostgreSQL: Documentación: 9.6 . Grupo de Desarrollo Global de PostgreSQL. 12 de agosto de 2021.
  39. ↑ "Sección 13.20 Funciones misceláneas" . Manual de referencia de MySQL 5.7 . Oracle Corporation .
  40. ↑ "Almacenamiento de valores UUID en MySQL" . Percona. 19 de diciembre de 2014. Archivado del original el 29 de noviembre de 2020. Consultado el 10 de febrero de 2021 .
  41. ↑ "Tablas de datos ACPI" . UEFI .
  • Recomendación ITU-T X.667 (Acceso libre)
  • ISO/IEC 9834-8:2014 (De pago)
  • Nota técnica TN2166 - Secretos de la GPT - Desarrollador de Apple
  • Documentación de UUID - Identificador común de Apache
  • Clave CLSID - Documentación de Microsoft
  • Identificador Único Universal - Biblioteca de The Open Group
  • Herramienta decodificadora UUID
  • Breve historia del UUID
  • Comprender cómo se generan los UUID
Lecturas relacionadas
6 articulos
computación de 128 bitscomputación de 128 bitsEn arquitectura informática , los enteros de 128 bits , las direcciones de memoria u otras unidades de datos son aquellas que tienen un ancho de 12...MicrosoftMicrosoftMicrosoft Corporation es una corporación multinacional y empresa de tecnología estadounidense con sede en Redmond, Washington . [2] Sus productos d...ProbabilidadProbabilidadLas probabilidades de obtener varios números usando dos dados La probabilidad es la rama de las matemáticas que estudia los eventos y las descripci...Computadora ApolloComputadora ApolloApollo Computer Inc. , fundada en 1980 en Chelmsford, Massachusetts , por William Poduska (fundador de Prime Computer ) y otros, desarrolló y produ...Sistema de computación en redEl Sistema de Computación en Red ( NCS ) fue una implementación de la Arquitectura de Computación en Red (NCA), lanzada en 1987. Comprendía un conj...Sistema operativoSistema operativoUn sistema operativo ( SO ) es un software de sistema que administra los recursos de hardware y software de la computadora y proporciona servicios ...