Identificador universalmente único - Universally unique identifier

De Wikipedia, la enciclopedia libre

Un identificador único universal ( UUID ) es una etiqueta de 128 bits que se utiliza para la información en los sistemas informáticos. El término identificador único global ( GUID ) también se utiliza, a menudo en software creado por Microsoft .

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 o 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, está lo suficientemente cerca de 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 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 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, y muchas plataformas informáticas brindan soporte para generarlos y analizar su representación textual.

Historia

En la década de 1980, Apollo Computer usó originalmente UUID en el Network Computing System (NCS) y más tarde en el Distributed Computing Environment (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 (de 64 bits ) definidos y utilizados de forma generalizada en Domain / OS , un sistema operativo diseñado por Apollo Computer. Más tarde, 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 estándar propuesto por IETF , la UIT también había estandarizado 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 de Computación Distribuida (DCE).

Los UUID se documentan como parte de ISO / CEI 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: 2005.

El Grupo de trabajo de ingeniería de Internet (IETF) publicó el estándar RFC 4122, técnicamente equivalente a la Rec. UIT-T. X.667 | ISO / IEC 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

Los campos M de cuatro bits y N de 1 a 3 bits codifican el formato del UUID en sí.

Los cuatro bits de dígitos M son la versión UUID y los 1 a 3 bits de dígitos más significativos N codifican la variante UUID. (Consulte a continuación ) . En el ejemplo, M es 1 y N es a (10xx 2 ), lo que significa que se trata de un UUID de 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:

Diseño de registro UUID
Nombre Longitud (bytes) Longitud (dígitos hexadecimales) Contenido
time_low 4 8 entero que da los 32 bits más bajos del tiempo
time_mid 2 4 entero que da los 16 bits del medio del tiempo
time_hi_and_version 2 4 "Versión" de 4 bits en los bits más significativos, seguidos de los 12 bits más altos del tiempo
clock_seq_hi_and_res clock_seq_low 2 4 "Variante" de 1 a 3 bits en los bits más significativos, seguida de la secuencia de reloj de 13 a 15 bits
nodo 6 12 el ID de nodo de 48 bits

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

La sección 3 del RFC 4122 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 circundantes:

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

Este formato no debe confundirse con el " formato del Registro de Windows ", que se refiere al formato entre llaves.

RFC 4122 define un espacio de nombres Uniform Resource Name (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 UUID varía entre sistemas. Los UUID de la variante 1, hoy en día 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, históricamente utilizados en las bibliotecas COM / OLE de Microsoft , utilizan un formato de endian mixto , en el que los tres primeros componentes del UUID son little-endian y los dos últimos son big-endian . 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

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

  • La variante 0 (indicada por el patrón de un bit 0xxx 2 , N  =  0..7 ) es para compatibilidad hacia atrás con el formato UUID del Apollo Network Computing System 1.5, ahora obsoleto , desarrollado alrededor de 1988. Los primeros 6 octetos del UUID son una marca de tiempo de 48 bits ( el número de unidades de tiempo de 4 microsegundos desde el 1 de enero de 1980 UTC); los siguientes 2 octetos están reservados; el siguiente octeto es la "familia de direcciones"; y los 7 octetos finales son un ID de host de 56 bits en la forma especificada por la familia de direcciones. Aunque es diferente en detalles, la similitud con los UUID modernos de la versión 1 es evidente. Los bits variantes en la especificación UUID actual coinciden con los bits altos del octeto de la familia de direcciones en los UUID NCS. Aunque la familia de direcciones podría contener valores en el rango 0..255, solo se definieron los valores 0..13. En consecuencia, el patrón de bits de la variante 0 0xxx evita conflictos con los UUID de NCS históricos, en caso de que todavía exista alguno en las bases de datos.
  • La variante 1 (10xx 2 , N  =  8..b , 2 bits) se conoce como UUID RFC 4122 / DCE 1.1 o UUID "Leach-Salz", en honor a los autores del borrador original de Internet .
  • La variante 2 (110x 2 , N  =  c..d , 3 bits) se caracteriza en el RFC como "reservada, compatibilidad con versiones anteriores de Microsoft Corporation" y se utilizó para los primeros GUID en la plataforma Microsoft Windows . Se diferencia de la variante 1 solo por el endianness en el almacenamiento o la transmisión binarios: los UUID de la variante 1 usan el orden de bytes de "red" (big-endian), mientras que los GUID de la variante 2 usan el orden de bytes "nativo" (little-endian) para algunos subcampos del UUID.
  • Reservado se define como el patrón de bits variante de 3 bits 111x 2 ( 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 de variante. 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 sin firmar de 32 y 16 bits y están sujetos a intercambio, mientras que los dos últimos campos constan de bytes no interpretados, no sujetos a intercambio. Este intercambio de bytes se aplica incluso para las versiones 3, 4 y 5, donde los campos canónicos no corresponden al contenido del UUID.

Si bien algunos GUID importantes, como el identificador de la interfaz IUnknown del modelo de objeto componente , son UUID de variante 2 nominalmente, muchos identificadores generados y utilizados en el software de Microsoft Windows y denominados "GUID" son la variante 1 estándar RFC 4122 / DCE 1.1. UUID de orden de bytes de red, en lugar de UUID de variante 2 de little-endian. La versión actual de la herramienta de Microsoft produce UUID variante 1 estándar. Parte de la documentación de Microsoft indica que "GUID" es un sinónimo de "UUID", como está estandarizado en RFC 4122. El propio RFC 4122 afirma 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 variant-1 y variant-2 existentes. guidgen

Versiones

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

Los UUID de la versión 1 se generan a partir de una hora y una ID de nodo (generalmente la dirección MAC ); Los UUID de la versión 2 se generan a partir de un identificador (generalmente un ID de grupo o usuario), una 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 UUID "nulo", 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, que 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 transfiere alrededor de 3400 d.C., 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 5236 AD. El tiempo de renovación definido en la Rec. UIT-T. X.667 es 3603 d.C.

Una secuencia de reloj "uniquificante" de 13 o 14 bits extiende la marca de tiempo para manejar los 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. 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 involuntariamente iguales es prácticamente nula. Puesto que los bits de tiempo y secuencia de reloj total 74, 2 74 (1,8 × 10 22 , o 18 sextillion) 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.

A diferencia de otras versiones de UUID, los UUID de la versión 1 y -2 basados ​​en direcciones MAC de tarjetas de red dependen en parte para su unicidad de un identificador emitido por una autoridad de registro central, es decir, la parte del identificador organizativo único (OUI) de la dirección MAC. , que emite 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 las direcciones MAC de la tarjeta de red también depende de que los fabricantes de tarjetas de red asignen correctamente direcciones MAC únicas a sus tarjetas, lo que, al igual que otros procesos de fabricación, está sujeto a errores.

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 versión 1 hasta la computadora que lo creó. A veces, los documentos se pueden rastrear hasta las computadoras donde fueron creados o editados a través de UUID incrustados en ellos por 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 de la 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 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 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 servicios de seguridad y autenticación del 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 número de "dominio local", y los 32 bits menos significativos de la marca de tiempo se reemplazan por un identificador de número entero significativo dentro del 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. En 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 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á" solo 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 14 bits en la versión 1, solo se pueden generar 64 UUID únicos por nodo / dominio / identificador por tic de reloj de 7 minutos, en comparación con 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 (basadas en el nombre del espacio de nombres)

Los UUID de la versión 3 y la versión 5 se generan mediante el hash de 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 se puede utilizar cualquier UUID deseado como designador de espacio de nombres.

Para determinar el UUID de la versión 3 correspondiente a un espacio de nombres y un nombre dados, el UUID del espacio de nombres se transforma en una cadena de bytes, se concatenan con el nombre de entrada y luego se 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" UUID de 2 o 3 bits (por ejemplo, 10 2 que indica un UUID RFC 4122, o 110 2 indicando un GUID de Microsoft heredado). Dado que de este modo se predeterminan 6 o 7 bits, 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 búsqueda por 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 (aleatoria)

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 2 o 110 2 para las variantes 1 y 2 respectivamente). Por lo tanto, para la variante 1 (es decir, la mayoría de UUID), un UUID de versión 4 aleatorio tendrá 6 bits de versión y variante predeterminados, dejando 122 bits para la parte generada aleatoriamente, para un total de 2122 , o 5.3 × 10 36 (5.3  undecillion ) posibles UUID de la versión 4 variante-1. Hay la mitad de los UUID (GUID heredados) de la versión 4 posible porque hay un bit aleatorio menos disponible y se consumen 3 bits para la variante.

Colisiones

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 de la versión 1 y la versión 2 que utilizan direcciones MAC únicas de las tarjetas de red, las colisiones pueden ocurrir solo cuando una implementación difiere de los estándares, ya sea de manera inadvertida o intencional.

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

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 de 2,71 trillones, calculado de la siguiente manera:

Este número equivale a generar mil millones de UUID por segundo durante aproximadamente 85 años. Un archivo que contenga tantos UUID, a 16 bytes por UUID, sería de unos 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 los 103 billones de UUID de la versión 4 es de uno en mil millones.

Usos

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 , la mayoría de los cuales se derivan de la implementación original de Theodore Ts'o .

Uno de los usos de los UUID en Solaris (mediante la implementación de Open Software Foundation) es la identificación de una instancia del sistema operativo en ejecución con el fin de emparejar los datos de volcado por caída con el evento de gestión de fallas en el caso de un pánico del kernel.

Se utiliza comúnmente dentro de los protocolos de bluetooth para determinar los servicios y el perfil general de bluetooth.

En COM

Hay varios tipos de GUID utilizados 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_ROOT\Interface] )
  • CLSID - identificador de clase; (Almacenado en [HKEY_CLASSES_ROOT\CLSID] )
  • LIBID - identificador de biblioteca de tipo; (Almacenado en [HKEY_CLASSES_ROOT\TypeLib] )
  • 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] )

Como claves de la base de datos

Los UUID se utilizan comúnmente como una clave única en las tablas de la base 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. 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. 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 estándar de la versión 1.

La naturaleza aleatoria de UUID estándar de 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 base de datos localidad o el rendimiento cuando se utilizan UUID 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 que tuvieran muchas más probabilidades de ser duplicados, como reconoció Nilsson, pero Nilsson solo requería unicidad dentro de la aplicación. Al reordenar y codificar los UUID de la versión 1 y 2 para que la marca de tiempo sea lo primero, se puede evitar la pérdida de rendimiento de la inserción.

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

  • "ULID", que se deshace de los 4 bits utilizados para indicar la versión 4, utiliza una codificación base32 de forma predeterminada y exige la monotonicidad total por estado.
  • UUID versiones 6 a 8, una propuesta formal de tres formatos UUID COMB.

Ver también

Referencias

enlaces externos

Estándares

Generador de UUID ITU-T

Articulos tecnicos

Diverso