Identificador único universal

Un identificador único universal o universally unique identifier (UUID) es un número de 16 bytes (128 bits). Por tanto, el número de posibles UUID es de 16³², o unos 3,4 × 10³⁸. En su forma canónica un UUID se expresa mediante 32 dígitos hexadecimales divididos en cinco grupos separados por guiones de la forma 8-4-4-4-12 lo que da un total de 36 caracteres (32 dígitos y 4 guiones). Por ejemplo:

550e8400-e29b-41d4-a716-446655440000

Un UUID puede ser usado con un identificador específico "intencionalmente" y ser usado en varias ocasiones para identificar el mismo objeto en diferentes contextos. Por ejemplo, en Microsoft Component Object Model, todos los componentes deben implementar la interfaz IUnknown (interfaz desconocido), que es realizado creando un UUID representante de IUnknow. En todos los casos cuando IUnknown es usado, ya sea usado por un proceso intentando acceder a la interfaz IUnknow en un componente, o por un componente implementando la interfaz IUnknown, siempre es referenciado por el mismo identificador:

00000000-0000-0000-C000-000000000046.

Historia

UUID se utilizó originalmente en el Apolo Computing System Red (NCS) y más tarde en el Open Software Foundation (OSF) Informática entorno distribuido (DCE). El diseño inicial de DCE UUID se basó en el NCS UUID, cuyo diseño fue a su vez inspirados por los identificadores únicos definidos y utilizados en sistemas Domain / OS , un sistema operativo diseñado también por Apollo Computer. Más tarde, las plataformas Microsoft Windows adoptaron el diseño de DCE como identificadores únicos globales (GUID). En la RFC 4122 se registró un URN espacio de nombres para los UUID, y recapitulado las especificaciones anteriores con el mismo contenido técnico. En el momento en el RFC 4122 se publicó como una propuesta IETF estándar, la UIT también se había normalizado UUID, basado en las normas anteriores y las primeras versiones de la RFC 4122.

Normas

UUID están estandarizados por la Open Software Foundation (OSF) como parte de la Distributed Computing Environment (DCE). Además se documentan como parte de la norma 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 el UIT-T Rec. X.667 | ISO / IEC 9834-8: 2005.

El Grupo de Trabajo de Ingeniería de Internet (IETF) publicó la pista de las normas, RFC 4122, técnicamente equivalentes a UIT-T Rec. X.667 | ISO / IEC 9834-8.

Formato

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

123e4567-e89b-12d3-a456-426655440000

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Los tres bits más significativos del dígito N indican la variante UUID y los cuatro bits del dígito M indican la versión UUID. En el ejemplo, M es 1 y N es a (10xx), significando que el UUID es una variante 1 de la versión 1; es decir, un DCE / RFC 4122 UUID basado en el tiempo.

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

• Un número entero de 4 bytes (8 dígitos hexadecimales) "time_low" con los 32 bits bajos del timestamp.
• Un número entero de 2 bytes (4 dígitos hexadecimales) "time_mid" con los 16 bits centrales del timestamp.
• Un número entero de 2 bytes (4 dígitos hexadecimales) "time_hi_and_version", con la "versión" de 4 bits en los bits más significativos, seguido por los 12 bits altos del timestamp.
• Dos campos de 1 byte (4 dígitos hexadecimales) "clock_seq_hi_and_reserved" y "clock_seq_lo", con la "variante" en los 1 a 3 bits más significativos de clock_seq_hi_and_reserved, seguido de la secuencia del reloj
• Seis bytes (12 dígitos hexadecimales) con el "nodo" de 48 bits

Estos campos reflejan principalmente los de la versión 1 y 2 UUID, basados en el tiempo, pero la misma representación 8-4-4-4-12 se utiliza para todos los UUID, incluso si la semántica de la UUID es diferente de las versiones 1 y 2 o es opaca.

Los GUID de Microsoft son a veces representados entre corchetes:

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

Este formato no debe confundirse con "formato de registro", que se refiere al formato dentro de las llaves.

RFC 4122 define un Uniform Resource Name espacio de nombres (URN) de UUID. Un UUID presentado como un URN aparece como sigue:

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

Versiones

Para las variantes 1 y 2, cinco "versiones" se definen en las normas y cada versión pueden ser más apropiados que los otros en casos de uso específicos. La versión está indicada por el Mde la representación de cadena.

La versión 1 del UUID se genera a partir del valor tiempo (reloj del sistema) y un ID de nodo (por lo general la dirección MAC); la versión 2 del UUID se genera a partir de un identificador (por lo general un grupo o identificador de usuario), el tiempo, y un ID de nodo; las versión 3 y 5 del UUID son productos deterministas generados por hashing un espacio de nombres identificador y nombre; y la versión 4 UUID se generan utilizando un aleatoria o pseudo-aleatoria número.

UUID Nulo

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

UUID Versión 1 (fecha-hora y la dirección MAC)

La Versión 1 concatena los 48 bits de direcciones MAC del nodo (es decir, el equipo que genera el UUID) con una marca de tiempo de 60 bits, siendo el número de 100- nanosegundos intervalos desde la medianoche 15 de octubre 1582 Tiempo Universal Coordinado (UTC ), la fecha en que el calendario gregoriano fue adoptado por primera vez. RFC 4122 establece que el valor de tiempo se da la vuelta alrededor de 3400 AD, en función del algoritmo utilizado, lo que implica que la marca de tiempo de 60 bits es un número con signo. Sin embargo, algunos programas, como la biblioteca libuuid, trata a la marca de tiempo como un número sin signo, poniendo el momento de vuelco en 5236 AD.

Una secuencia "uniquifying" reloj de 14 bits se extiende la marca de tiempo con el fin de manejar los casos en que el reloj del procesador no avanza lo suficientemente rápido, o cuando hay múltiples procesadores y generadores UUID por nodo. Con cada versión 1 UUID correspondiente a un solo punto en el espacio (el nodo) y el tiempo (intervalos y la secuencia de reloj), la posibilidad de dos correctamente-generado versión 1 UUID de ser involuntariamente la misma es prácticamente nula. Puesto que el tiempo y secuencia de reloj total de 74 bits de, 2 ⁷⁴ (1.8x10 ²² o 18 sextillones) versión 1 UUID pueden ser generados por ID de nodo, a una velocidad media máxima de 163 mm por segundo y por ID de nodo.

En contraste con otras versiones UUID, versión 1 y 2 UUID basado en direcciones MAC de las tarjetas de red dependen para su singularidad en parte en un identificador emitido por una autoridad de registro central, a saber, el punto de vista organizativo Identificador Único parte (OUI) de la dirección MAC, el cual se emite por el IEEE para los fabricantes de equipos de red. La singularidad de la versión 1 y 2 UUID basado en la tarjeta de red direcciones MAC también depende de los fabricantes de tarjetas de red asignando direcciones MAC únicas para las tarjetas.

El uso de la dirección MAC de la tarjeta de red del nodo para el ID de nodo significa que un UUID versión 1 se puede seguir de nuevo al equipo que lo creó. Documentos veces se pueden remontar a los equipos en los que fueron creados o editados a través de UUID incrustados en ellos por el procesamiento de textos de software. Este privacidad se utilizó agujero cuando se localiza el creador del virus Melissa .

RFC 4122 no permitir que la dirección de MAC en una versión 1 (o 2) UUID para ser sustituido por un azar ID de nodo de 48 bits, ya sea porque el nodo no tiene una dirección MAC, o porque no es deseable para exponerlo. En ese caso, el RFC requiere que el bit menos significativo del primer octeto de la ID de nodo se debe establecer en 1. Esto corresponde a la multidifusión de bits en direcciones MAC y el establecimiento de la que sirve para diferenciar UUID donde el ID de nodo es aleatoriamente generados a partir de las basadas en las direcciones MAC de las tarjetas de red, que normalmente tienen unicast direcciones MAC.

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

RFC 4122 se reserva para la versión 2 UUID de "seguridad" DCE; pero no proporciona ningún detalle. Por esta razón, muchas implementaciones UUID omiten versión 2. Sin embargo, la especificación de la versión 2 UUID es proporcionada por la autenticación DCE 1.1 y la especificación de Servicios de Seguridad.

Versión 2 UUID son similares a la versión 1, excepto que los 8 bits menos significativos de la secuencia de reloj (clock_seq_low) se sustituyen por un número "dominio local", y los significativos 32 bits menos de la marca de tiempo (Time_Low) se sustituyen por un número entero identificador significativa dentro del dominio local especificado. En POSIX sistemas, los números de dominio local 1 y 2 son para los identificadores de usuario (UID), y los ID de grupo (GID), respectivamente, y otros números de dominio local son sitio-definido. En los sistemas no POSIX, todos los números de dominio local son definidos por el sitio.

La capacidad para incluir un dominio / identificador de 40 bits en el UUID viene con una solución de compromiso. Por un lado, 40 bits permiten valores de 1 billón de dominio / identificador. Por otro lado, con el valor de reloj truncado para los 28 bits más significativos, en comparación con 60 bits en la versión 1, el reloj en un UUID versión 2 se "tick", sólo una vez cada 429.49 segundo, un poco más de 7 minutos, como en oposición a cada 100 nanosegundos para la versión 1. Y con una secuencia de reloj de sólo 6 bits, en comparación con 14 bits en la versión 1, por nodo / dominio / identificador de sólo el 64 de UUID único puede ser generado por ciclo de reloj 7 minutos, en comparación con 16.384 reloj valores de secuencia para la versión 1. por lo tanto, versión 2 pueden no ser adecuados para los casos donde se requieren UUID, por nodo / dominio / identificador, a una velocidad que excede de aproximadamente 1 por cada 7 segundos.

UUID Versiones 3 y 5 (namespace name-based)

Versión 3 y 5 UUID son generados por hashing un espacio de nombres identificador y nombre. Versión 3 utiliza MD5 como el algoritmo de hash, y la versión 5 utiliza SHA1.

El identificador de espacio de nombres es en sí mismo un UUID. La especificación proporciona UUID para representar los espacios de nombres para URLs, completamente nombres calificados de dominio, identificadores de objeto, y X.500 nombres distinguidos; pero cualquier UUID deseado puede ser utilizado como un designador de espacio de nombres.

Para determinar el UUID versión 3 que corresponde a un espacio de nombres y el nombre dado, el UUID del espacio de nombres se transforma en una cadena de bytes, concatenado con el nombre de entrada, a continuación, hash con MD5, produciendo 128 bits. Seis o siete bits son entonces reemplazados por valores fijos, la versión de 4 bits (por ejemplo, 0011para la versión 3), y el UUID "variante" de 2 o de 3 bits (por ejemplo, 10que indica una RFC 4122 UUID, o 110indicando un legado Microsoft GUID) . Desde 6 o 7 bits son por tanto predeterminados, sólo 121 o 122 bits de contribuyen a la singularidad de la UUID.

Versión 5 UUID son similares, pero SHA1 se utiliza en lugar de MD5. Desde SHA1 genera 160 bits digiere, el digesto se trunca a 128 bits antes se insertan los bits de versión y variantes.

Versión 3 y 5 UUID tienen la propiedad de que el mismo espacio de nombres y el nombre se asignarán al mismo UUID. Sin embargo, el espacio de nombres y el nombre no se pueden determinar a partir de la versión 3 o 5 UUID solo.

RFC 4122 recomienda versión 5 (SHA1) sobre la versión 3 (MD5) y consejos contra el uso de UUID de cualquiera de las versiones como credenciales de seguridad.

UUID Versión 4 (al azar)

Un UUID versión 4 se genera aleatoriamente. Como en otros UUID, cuatro bits se utilizan para indicar la versión 4, y 2 o 3 bits para indicar la variante (10o 110para las variantes 1 y 2, respectivamente). Por lo tanto, para la variante 1 (es decir, la mayoría de los UUID) un azar versión 4 UUID tendrá 6 bits variante y versión predeterminadas, dejando 122 bits para la parte generada de forma aleatoria, para un total de 2 ¹²² , o 5.3x10 ³⁶ (5,3 undecillones ) posible versión 4 variante 1 UUID. Hay un medio como muchas posibles variantes de la versión 4 2 UUID (GUID heredados) porque no es uno menos de bits aleatorios disponibles, 3 bits que se consumen para la variante.

Algunos generadores de números pseudoaleatorios carecen de entropía necesaria para producir un número suficiente pseudoaleatorios. Por ejemplo, el WinAPI generador GUID, que utiliza un generador de números pseudoaleatorios, se ha demostrado que producen UUID que siguen un patrón predecible. ^{[ Citación necesaria ]} RFC 4122 informa que "aplicaciones distribuidas generando UUID en una variedad de huéspedes deben estar dispuestos a depender de la fuente de número aleatorio a todos los hosts. Si esto no es factible, la variante de espacio de nombres debe ser utilizado."

Enlaces externos

• Generador de códigos GUID/UUID en español
• UUID – generate UUIDs (or GUIDs) in Java (código open source)