Identificador universalmente único - Universally unique identifier

UUID / GUID conforme usado por variáveis UEFI

Um identificador universalmente exclusivo ( UUID ) é um rótulo de 128 bits usado para informações em sistemas de computador. O termo identificador globalmente exclusivo ( GUID ) também é usado, geralmente em softwares criados pela Microsoft .

Quando gerados de acordo com os métodos padrão, os UUIDs são, para fins práticos, únicos. Sua singularidade não depende de uma autoridade central de registro ou coordenação entre as partes que os geram, ao contrário da maioria dos outros esquemas de numeração. Embora a probabilidade de que um UUID seja duplicado não seja zero, ele é próximo o suficiente de zero para ser desprezível.

Assim, qualquer um pode criar um UUID e usá-lo para identificar algo com quase certeza de que o identificador não duplica um que já foi, ou será, criado para identificar outra coisa. As informações rotuladas com UUIDs por partes independentes podem, portanto, ser combinadas posteriormente em um único banco de dados ou transmitidas no mesmo canal, com uma probabilidade insignificante de duplicação.

A adoção de UUIDs é generalizada, com muitas plataformas de computação fornecendo suporte para gerá-los e analisar sua representação textual.

História

Na década de 1980, a Apollo Computer usava originalmente UUIDs no Network Computing System (NCS) e, posteriormente, no Distributed Computing Environment (DCE) da Open Software Foundation (OSF ). O design inicial dos UUIDs DCE foi baseado nos UUIDs NCS, cujo design, por sua vez, foi inspirado nos identificadores exclusivos ( 64 bits ) definidos e usados ​​amplamente no Domínio / OS , um sistema operacional projetado pela Apollo Computer. Posteriormente, as plataformas Microsoft Windows adotaram o design DCE como "identificadores exclusivos globalmente" (GUIDs). A RFC 4122 registrou um namespace URN para UUIDs e recapitulou as especificações anteriores, com o mesmo conteúdo técnico. Quando, em julho de 2005, o RFC 4122 foi publicado como um padrão IETF proposto , a ITU também padronizou os UUIDs, com base nos padrões anteriores e nas primeiras versões do RFC 4122.

Padrões

UUIDs são padronizados pela Open Software Foundation (OSF) como parte do Distributed Computing Environment (DCE).

UUIDs são documentados como parte da ISO / IEC 11578: 1996 " Tecnologia da informação  - Interconexão de sistemas abertos - Chamada de procedimento remoto (RPC)" e, mais recentemente, na Rec ITU-T. X.667 | ISO / IEC 9834-8: 2005.

A Internet Engineering Task Force (IETF) publicou o Standards-Track RFC 4122, tecnicamente equivalente ao ITU-T Rec. X.667 | ISO / IEC 9834-8.

Formato

Em sua representação textual canônica, os 16 octetos de um UUID são representados como 32 dígitos hexadecimais (base 16), exibidos em cinco grupos separados por hífens, no formato 8-4-4-4-12 para um total de 36 caracteres (32 caracteres hexadecimais e 4 hifens). Por exemplo:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Os campos M de quatro bits e N de 1 a 3 bits codificam o formato do próprio UUID.

Os quatro bits de dígito Msão a versão UUID e os 1 a 3 bits mais significativos de Ncódigo de dígito a variante UUID. (Veja abaixo. ) No exemplo, M é 1, e N é a(10xx 2 ), o que significa que este é um UUID versão-1, variante-1; isto é, um UUID DCE / RFC 4122 baseado em tempo.

A string de formato canônico 8-4-4-4-12 é baseada no layout de registro para os 16 bytes do UUID:

Layout de registro UUID
Nome Comprimento (bytes) Comprimento (dígitos hexadecimais) Comprimento (bits) Conteúdo
time_low 4 8 32 inteiro dando os 32 bits mais baixos da época
time_mid 2 4 16 inteiro fornecendo os 16 bits intermediários do tempo
time_hi_and_version 2 4 16 "Versão" de 4 bits nos bits mais significativos, seguida pelos 12 bits mais altos da época
clock_seq_hi_and_res clock_seq_low 2 4 16 "Variante" de 1 a 3 bits nos bits mais significativos, seguida pela sequência de relógio de 13 a 15 bits
6 12 48 o id do nó de 48 bits

Esses campos correspondem aos da versão 1 e 2 UUIDs (ou seja, UUIDs baseados em tempo), mas a mesma representação 8-4-4-4-12 é usada para todos os UUIDs, mesmo para UUIDs construídos de forma diferente.

A RFC 4122 Seção 3 requer que os caracteres sejam gerados em minúsculas, embora não façam distinção entre maiúsculas e minúsculas na entrada.

GUIDs da Microsoft às vezes são representados por colchetes:

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

Este formato não deve ser confundido com o " formato do Registro do Windows ", que se refere ao formato entre chaves.

RFC 4122 define um namespace Uniform Resource Name (URN) para UUIDs. Um UUID apresentado como um URN aparece da seguinte forma:

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

Codificação

A codificação binária de UUIDs varia entre os sistemas. Os UUIDs da variante 1, atualmente a variante mais comum, são codificados no formato big-endian . Por exemplo, 00112233-4455-6677-8899-aabbccddeeffé codificado como bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

Os UUIDs da variante 2, historicamente usados ​​nas bibliotecas COM / OLE da Microsoft , usam um formato endian misto , em que os três primeiros componentes do UUID são little-endian e os dois últimos são big-endian . Por exemplo, 00112233-4455-6677-8899-aabbccddeeffé codificado como bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Variantes

O campo "variante" dos UUIDs ou a posição N indicam seu formato e codificação. RFC 4122 define quatro variantes de comprimentos de 1 a 3 bits:

  • A variante 0 (indicada pelo padrão de um bit 0xxx 2 , N  =  0..7) é para compatibilidade com o agora obsoleto formato UUID do Apollo Network Computing System 1.5 desenvolvido por volta de 1988. Os primeiros 6 octetos do UUID são um carimbo de data / hora de 48 bits ( o número de unidades de 4 microssegundos de tempo desde 1 de janeiro de 1980 UTC); os próximos 2 octetos são reservados; o próximo octeto é a "família de endereços"; e os 7 octetos finais são um ID de host de 56 bits na forma especificada pela família de endereços. Embora diferentes em detalhes, a semelhança com os UUIDs da versão 1 moderna é evidente. Os bits variantes na especificação UUID atual coincidem com os bits altos do octeto da família de endereços em UUIDs NCS. Embora a família de endereços pudesse conter valores no intervalo 0..255, apenas os valores 0..13 foram definidos. Consequentemente, o padrão de bit variante 0 0xxxevita conflitos com UUIDs NCS históricos, caso ainda exista algum nos bancos de dados.
  • A variante 1 (10xx 2 , N  =  8..b, 2 bits) é referida como UUIDs RFC 4122 / DCE 1.1 ou UUIDs "Leach-Salz", em homenagem aos autores do Internet Draft original .
  • A variante 2 (110x 2 , N  =  c..d, 3 bits) é caracterizada na RFC como "reservada, compatibilidade com versões anteriores da Microsoft Corporation" e foi usada para GUIDs anteriores na plataforma Microsoft Windows . Ele difere da variante 1 apenas pelo endianness no armazenamento ou transmissão binário: os UUIDs da variante-1 usam ordem de bytes de "rede" (big-endian), enquanto os GUIDs da variante-2 usam ordem de bytes "nativos" (little-endian) para alguns subcampos do UUID.
  • Reservado é definido como o padrão de bit variante de 3 bits 111x 2 ( N  =  e..f).

As variantes 1 e 2 são usadas pela especificação UUID atual. Em suas representações textuais, as variantes 1 e 2 são iguais, exceto para os bits variantes. Na representação binária, há uma diferença de endianismo. Quando a troca de bytes é necessária para converter entre a ordem de bytes big-endian da variante 1 e a ordem de bytes little-endian da variante 2, os campos acima definem a troca. Os três primeiros campos são inteiros de 32 e 16 bits não assinados e estão sujeitos a troca, enquanto os dois últimos campos consistem em bytes não interpretados, não sujeitos a troca. Essa troca de bytes se aplica mesmo às versões 3, 4 e 5, onde os campos canônicos não correspondem ao conteúdo do UUID.

Embora alguns GUIDs importantes, como o identificador para a interface IUnknown do Component Object Model , sejam UUIDs nominalmente variantes 2, muitos identificadores gerados e usados ​​no software Microsoft Windows e referidos como "GUIDs" são variantes padrão 1 RFC 4122 / DCE 1.1 UUIDs de ordem de byte de rede, em vez de UUIDs da variante 2 de little-endian. A versão atual da ferramenta Microsoft produz UUIDs variante-1 padrão. Algumas documentações da Microsoft afirmam que "GUID" é sinônimo de "UUID", conforme padronizado na RFC 4122. A própria RFC 4122 afirma que UUIDs "também são conhecidos como GUIDs". Tudo isso sugere que "GUID", embora originalmente se referindo a uma variante do UUID usado pela Microsoft, tornou-se simplesmente um nome alternativo para UUID, com os GUIDs de variante 1 e 2 existentes. guidgen

Versões

Para ambas as variantes 1 e 2, cinco "versões" são definidas nos padrões, e cada versão pode ser mais apropriada do que as outras em casos de uso específicos. A versão é indicada pelo Mna representação da string.

Os UUIDs da versão 1 são gerados a partir de um tempo e um ID de nó (geralmente o endereço MAC ); os UUIDs da versão 2 são gerados a partir de um identificador (geralmente um grupo ou ID de usuário), hora e um ID de nó; as versões 3 e 5 produzem UUIDs determinísticos gerados por hash de um nome e identificador de namespace ; e os UUIDs da versão 4 são gerados usando um número aleatório ou pseudo-aleatório .

Nil UUID

O UUID "nulo", um caso especial, é o UUID 00000000-0000-0000-0000-000000000000; ou seja, todos os bits definidos como zero.

Versão 1 (data-hora e endereço MAC)

A versão 1 concatena o endereço MAC de 48 bits do "nó" (ou seja, o computador que gera o UUID), com um carimbo de data / hora de 60 bits, sendo o número de intervalos de 100 nanossegundos desde a meia-noite de 15 de outubro de 1582 Hora Universal Coordenada (UTC ), a data em que o calendário gregoriano foi adotado pela primeira vez. A RFC 4122 afirma que o valor do tempo passa por volta de 3400 DC, dependendo do algoritmo usado, o que implica que o carimbo de data / hora de 60 bits é uma quantidade assinada. No entanto, alguns softwares, como a biblioteca libuuid, tratam o carimbo de data / hora como não assinado, colocando o tempo de rollover em 5236 AD. O tempo de rollover conforme definido por ITU-T Rec. X.667 é 3603 AD.

Uma sequência de relógio "uniquificadora" de 13 ou 14 bits estende o carimbo de data / hora para lidar com casos em que o relógio do processador não avança rápido o suficiente ou onde há vários processadores e geradores de UUID por nó. Quando UUIDs são gerados mais rápido do que o relógio do sistema poderia avançar, os bits mais baixos dos campos de carimbo de data / hora podem ser gerados incrementando-os toda vez que um UUID está sendo gerado, para simular um carimbo de data / hora de alta resolução. Com cada UUID da versão 1 correspondendo a um único ponto no espaço (o nó) e no tempo (intervalos e sequência de relógio), a chance de dois UUIDs da versão 1 gerados corretamente serem involuntariamente os mesmos é praticamente nula. Uma vez que o tempo e a sequência de relógio totalizam 74 bits, 2 74 (1,8 × 10 22 , ou 18 sextilhões) UUIDs de versão 1 podem ser gerados por ID de nó, a uma taxa média máxima de 163 bilhões por segundo por ID de nó.

Em contraste com outras versões de UUID, a versão 1 e -2 UUIDs com base em endereços MAC de placas de rede contam para sua exclusividade em parte em um identificador emitido por uma autoridade de registro central, ou seja, a parte Organizationally Unique Identifier (OUI) do endereço MAC , que é emitido pelo IEEE para fabricantes de equipamentos de rede. A exclusividade dos UUIDs da versão 1 e 2 com base nos endereços MAC da placa de rede também depende dos fabricantes de placas de rede atribuírem endereços MAC exclusivos a suas placas, o que, como outros processos de fabricação, está sujeito a erros. Além disso, alguns sistemas operacionais permitem que o usuário final personalize o endereço MAC, principalmente o OpenWRT .

O uso do endereço MAC da placa de rede do nó para o ID do nó significa que um UUID da versão 1 pode ser rastreado até o computador que o criou. Os documentos às vezes podem ser rastreados até os computadores onde foram criados ou editados por meio de UUIDs incorporados a eles por um software de processamento de texto. Esta falha de privacidade foi usada para localizar o criador do vírus Melissa .

O RFC 4122 permite que o endereço MAC em um UUID versão 1 (ou 2) seja substituído por um ID de nó aleatório de 48 bits, seja porque o nó não tem um endereço MAC ou porque não é desejável expô-lo. Nesse caso, o RFC exige que o bit menos significativo do primeiro octeto do ID do nó seja definido como 1. Isso corresponde ao bit multicast em endereços MAC, e sua configuração serve para diferenciar UUIDs onde o ID do nó é gerado aleatoriamente de UUIDs com base em endereços MAC de placas de rede, que normalmente têm endereços MAC unicast .

Versão 2 (data-hora e endereço MAC, versão de segurança DCE)

O RFC 4122 reserva a versão 2 para UUIDs de "segurança DCE"; mas não fornece detalhes. Por esta razão, muitas implementações de UUID omitem a versão 2. No entanto, a especificação dos UUIDs da versão 2 é fornecida pela especificação DCE 1.1 Authentication and Security Services.

Os UUIDs da versão 2 são semelhantes aos da versão 1, exceto que os 8 bits menos significativos da sequência do relógio são substituídos por um número de "domínio local" e os 32 bits menos significativos do carimbo de data / hora são substituídos por um identificador inteiro significativo dentro do especificado domínio local. Em sistemas POSIX , os números de domínio local 0 e 1 são para IDs de usuário ( UIDs ) e IDs de grupo ( GIDs ), respectivamente, e outros números de domínio local são definidos pelo site. Em sistemas não POSIX, todos os números de domínio locais são definidos pelo site.

A capacidade de incluir um domínio / identificador de 40 bits no UUID tem uma compensação. Por um lado, 40 bits permitem cerca de 1 trilhão de valores de domínio / identificador por ID de nó. Por outro lado, com o valor do relógio truncado para os 28 bits mais significativos, em comparação com 60 bits na versão 1, o relógio em um UUID da versão 2 irá "marcar" apenas uma vez a cada 429,49 segundos, um pouco mais de 7 minutos, como oposto a cada 100 nanossegundos para a versão 1. E com uma sequência de relógio de apenas 6 bits, em comparação com 14 bits na versão 1, apenas 64 UUIDs exclusivos por nó / domínio / identificador podem ser gerados por tique de relógio de 7 minutos, em comparação com 16.384 valores de sequência de relógio para a versão 1. Assim, a versão 2 pode não ser adequada para os casos em que são necessários UUIDs, por nó / domínio / identificador, a uma taxa superior a cerca de um a cada sete minutos.

Versões 3 e 5 (com base no nome do namespace)

Os UUIDs da versão 3 e 5 são gerados por hash de um nome e identificador de namespace . A versão 3 usa MD5 como algoritmo de hash e a versão 5 usa SHA-1 .

O próprio identificador de namespace é um UUID. A especificação fornece UUIDs para representar os namespaces para URLs , nomes de domínio totalmente qualificados , identificadores de objeto e nomes distintos X.500 ; mas qualquer UUID desejado pode ser usado como um designador de namespace.

Para determinar o UUID da versão 3 correspondente a um determinado namespace e nome, o UUID do namespace é transformado em uma string de bytes, concatenada com o nome de entrada e, em seguida, hash com MD5, resultando em 128 bits. Em seguida, 6 ou 7 bits são substituídos por valores fixos, a versão de 4 bits (por exemplo, 0011 2 para a versão 3) e a "variante" de UUID de 2 ou 3 bits (por exemplo, 10 2 indicando UUIDs RFC 4122 ou 110 2 indicando um Microsoft GUID legado). Visto que 6 ou 7 bits são assim predeterminados, apenas 121 ou 122 bits contribuem para a exclusividade do UUID.

Os UUIDs da versão 5 são semelhantes, mas SHA-1 é usado em vez de MD5. Como o SHA-1 gera resumos de 160 bits, o resumo é truncado para 128 bits antes que a versão e os bits variantes sejam substituídos.

Os UUIDs da versão 3 e 5 têm a propriedade de que o mesmo namespace e nome serão mapeados para o mesmo UUID. No entanto, nem o namespace nem o nome podem ser determinados a partir do UUID, mesmo se um deles for especificado, exceto por pesquisa de força bruta. O RFC 4122 recomenda a versão 5 (SHA-1) sobre a versão 3 (MD5) e alerta contra o uso de UUIDs de qualquer uma das versões como credenciais de segurança.

Versão 4 (aleatório)

Um UUID versão 4 é gerado aleatoriamente. Como em outros UUIDs, 4 bits são usados ​​para indicar a versão 4 e 2 ou 3 bits para indicar a variante (10 2 ou 110 2 para as variantes 1 e 2, respectivamente). Assim, para a variante 1 (ou seja, a maioria dos UUIDs), um UUID de versão 4 aleatório terá 6 bits de variante e versão predeterminados, deixando 122 bits para a parte gerada aleatoriamente, para um total de 2 122 , ou 5,3 × 10 36 (5,3  undecillion ) possível versão-4 variante-1 UUIDs. Há metade do número possível de UUIDs da versão 4 variante 2 (GUIDs legados) porque há um bit aleatório a menos disponível, 3 bits sendo consumidos para a variante.

Colisões

A colisão ocorre quando o mesmo UUID é gerado mais de uma vez e atribuído a diferentes referentes. No caso de UUIDs de versão 1 e 2 padrão usando endereços MAC exclusivos de placas de rede, é improvável que ocorram colisões, com uma possibilidade aumentada apenas quando uma implementação diverge dos padrões, inadvertidamente ou intencionalmente.

Em contraste com os UUIDs da versão 1 e 2 gerados usando endereços MAC, com UUIDs da versão 1 e -2 que usam IDs de nó gerados aleatoriamente, UUIDs da versão 3 e 5 baseados em hash e UUIDs da versão 4 aleatórios, colisões podem ocorrer mesmo sem problemas de implementação, embora com uma probabilidade tão pequena que normalmente pode ser ignorada. Essa probabilidade pode ser calculada com precisão com base na análise do problema do aniversário .

Por exemplo, o número de UUIDs da versão 4 aleatória que precisam ser gerados para ter uma probabilidade de 50% de pelo menos uma colisão é 2,71 quintilhões, calculado da seguinte forma:

Este número é equivalente a gerar 1 bilhão de UUIDs por segundo por cerca de 85 anos. Um arquivo contendo tantos UUIDs, de 16 bytes por UUID, teria cerca de 45  exabytes .

O menor número de UUIDs da versão 4 que deve ser gerado para que a probabilidade de encontrar uma colisão seja p é aproximado pela fórmula

Assim, a probabilidade de encontrar uma duplicata dentro de 103 trilhões de UUIDs da versão 4 é de uma em um bilhão.

Usos

Usos significativos incluem ferramentas de espaço de usuário do sistema de arquivos ext2 / ext3 / ext4 ( e2fsprogs usa libuuid fornecido pelo util-linux ), LVM , partições criptografadas por LUKS , GNOME , KDE e macOS , muitos dos quais são derivados da implementação original de Theodore Ts'o .

Um dos usos dos UUIDs no Solaris (usando a implementação do Open Software Foundation) é a identificação de uma instância do sistema operacional em execução com o objetivo de emparelhar dados de despejo de memória com Fault Management Event no caso de kernel panic.

Normalmente usado em protocolos bluetooth para determinar os serviços e o perfil geral do bluetooth.

Em COM

Existem vários tipos de GUIDs usados ​​no Component Object Model (COM) da Microsoft :

  • IID - identificador de interface; (Os que estão registrados em um sistema são armazenados no Registro do Windows em [HKEY_CLASSES_ROOT\Interface])
  • CLSID - identificador de classe; (Armazenado em [HKEY_CLASSES_ROOT\CLSID])
  • LIBID - identificador de biblioteca de tipo; (Armazenado em [HKEY_CLASSES_ROOT\TypeLib])
  • CATID - identificador da categoria; (sua presença em uma classe o identifica como pertencente a certas categorias de classe, listadas em [HKEY_CLASSES_ROOT\Component Categories])

Como chaves de banco de dados

UUIDs são comumente usados ​​como uma chave exclusiva em tabelas de banco de dados . A função NEWID no Transact-SQL do Microsoft SQL Server versão 4 retorna UUIDs padrão aleatórios da versão 4, enquanto a função NEWSEQUENTIALID retorna identificadores de 128 bits semelhantes aos UUIDs que são comprometidos a subir em sequência até a próxima reinicialização do sistema. A função SYS_GUID do banco de dados Oracle não retorna um GUID padrão, apesar do nome. Em vez disso, ele retorna um valor RAW de 128 bits de 16 bytes com base em um identificador de host e um identificador de processo ou thread, algo semelhante a um GUID. PostgreSQL contém um tipo de dados UUID e pode gerar a maioria das versões de UUIDs por meio do uso de funções de módulos. O MySQL fornece uma função UUID , que gera UUIDs versão 1 padrão.

A natureza aleatória dos UUIDs padrão das versões 3, 4 e 5 e a ordem dos campos nas versões 1 e 2 padrão podem criar problemas com a localidade ou desempenho do banco de dados quando os UUIDs são usados ​​como chaves primárias . Por exemplo, em 2002, Jimmy Nilsson relatou uma melhoria significativa no desempenho com o Microsoft SQL Server quando os UUIDs da versão 4 usados ​​como chaves foram modificados para incluir um sufixo não aleatório baseado na hora do sistema. Essa abordagem chamada "COMB" (GUID de tempo combinado) tornou os UUIDs fora do padrão e significativamente mais propensos a serem duplicados, como Nilsson reconheceu, mas Nilsson só exigia exclusividade no aplicativo. Reordenando e codificando os UUIDs das versões 1 e 2 para que o carimbo de data / hora venha primeiro, a perda de desempenho de inserção pode ser evitada.

Alguns frameworks web, como o Laravel, têm suporte para UUIDs "timestamp first" que podem ser armazenados de forma eficiente em uma coluna de banco de dados indexada. Isso cria um UUID COMB usando o formato da versão 4, mas onde os primeiros 48 bits formam um carimbo de data / hora disposto como em UUIDv1. Os formatos mais especificados com base na ideia COMB UUID incluem:

  • "ULID", que elimina os 4 bits usados ​​para indicar a versão 4, usa uma codificação base32 por padrão e exige monotonicidade total por statefulness.
  • UUID versões 6 a 8, uma proposta formal de três formatos COMB UUID.

Veja também

Referências

links externos

Padrões

ITU-T UUID Generator

Artigos Técnicos

Diversos

Implementação em vários idiomas