Ferramentas para desenvolvedores · Gerador UUID
Da Apollo NCS a RFC 9562: Uma Breve História do UUID
· Fundo
uuid criptografia APIs do navegador
O estranho layout 8-4-4-4-12 e o tamanho de 128 bits são herdados da computação distribuída dos anos 1980. Esta postagem rastreia o UUID do Network Computing System da Apollo por meio de DCE, GUID da Microsoft e dois padrões IETF.
Por que 128 bits e por que esses hífens? - as perguntas que todo recém-chegado faz e a história responde
O formato hifenizado 8-4-4-4-12 e o tamanho de 128 bits de um UUID são escolhas de design que os historiadores questionam imediatamente. Por que não 96 bits para facilitar a matemática? Por que esse layout de segmento específico? Por que base-16 com hífens em vez de base-64 ou uma codificação mais simples? As respostas estão no Apollo Network Computing System do início da década de 1980, uma plataforma de computação distribuída que enfrentava um problema genuíno: os sistemas numa rede precisavam de atribuir identificadores únicos sem uma autoridade central, e esses identificadores tinham de ser globalmente únicos com uma probabilidade esmagadora. Apollo NCS resolveu esse problema combinando um carimbo de data/hora, um endereço de rede e uma sequência de relógio em um identificador 128 bits que poderia ser gerado independentemente por qualquer máquina.
Apollo Network Computing System - a origem dos identificadores exclusivos construídos a partir do tempo e de um endereço de rede na década de 1980
O padrão atual registra uma linhagem do Apollo NCS até o OSF Distributed Computing Environment e plataformas posteriores da Microsoft. Essa história explica por que os sistemas modernos compartilham uma família reconhecível de 128 bits, preservando marcadores de variantes para layouts mais antigos. Não estabelece uma garantia absoluta de unicidade: cada versão possui regras de geração e modos de falha próprios. A conquista duradoura é a interoperabilidade sem um serviço de registro central. Um navegador, banco de dados e sistema operacional podem trocar a mesma forma hexadecimal canônica, inspecionar seus campos de variante e versão e decidir se a receita produzida atende às necessidades do sistema receptor.
OSF DCE e o campo variante — como o Ambiente de Computação Distribuída formalizou o layout e adicionou os bits variantes
O layout acomoda diversas estratégias de geração por meio de campos de versão e variante que foram incorporados desde o início do design. A geração baseada em tempo, a geração aleatória e a geração baseada em nome podem coexistir no mesmo espaço de identificadores. Os aplicativos modernos têm requisitos diferentes dos NCS dos anos 80 – bancos de dados que desejam chaves classificáveis, sistemas em nuvem que desejam privacidade, sistemas distribuídos que desejam resistência a colisões – mas a mesma estrutura de 128 bits ainda os acomoda. As versões 6 e 7 que foram adicionadas em RFC 9562 em 2024 provam que os designers originais deixaram espaço para evolução futura sem quebrar a compatibilidade com versões anteriores.
GUID — COM da Microsoft, o registro e o estilo entre colchetes e letras maiúsculas que persiste até hoje
O Apollo Network Computing System era uma plataforma de computação distribuída executada em estações de trabalho da Apollo Computer na década de 1980. Baseava-se em identificadores exclusivos globalmente para chamadas de procedimentos remotos, replicação de dados e serviços de nomenclatura. Os nós da rede não tinham como coordenar a atribuição de ID porque não seria possível contatar um servidor central se a rede pudesse estar particionada ou desconectada. Portanto, os designers da Apollo criaram um formato de 128 bits combinando um carimbo de data e hora 60 bits, um identificador de nó geralmente derivado do endereço MAC da placa de rede 48 bits e uma sequência de relógio 14 bits para lidar com mudanças de relógio. Esta abordagem permite que os nós gerem identificadores de forma independente, combinando tempo, uma sequência de relógio e um campo de nó; seu comportamento ainda dependia de relógios e da seleção de nós.
RFC 4122 (2005) — o padrão IETF que definiu as versões 1 a 5 e o namespace URN, alinhado com ITU-T X.667
Quando OSF posteriormente padronizou isso para seu ambiente de computação distribuída em torno de 1992, eles mantiveram o mesmo layout e adicionaram o campo variante para distinguir diferentes tipos de UUID. O design já foi comprovado em sistemas de produção. O IETF padronizou RFC 4122 em 2005, quase vinte anos após a Apollo NCS e cerca de treze anos após a padronização de DCE. RFC 4122 versões codificadas 1 a 5: versão 1 para geração baseada em tempo, versão 3 para baseada em nome com MD5, versão 4 para aleatória e versão 5 para baseado em nome com SHA-1. O padrão era estável e amplamente adotado porque já era onipresente no Microsoft Windows, na infraestrutura DNS e nos sistemas distribuídos. Na época em que RFC 4122 foi publicado, o UUID já estava tão integrado à infraestrutura que a padronização era quase acadêmica.
RFC 9562 (2024) — a revisão que tornou obsoleta RFC 4122, adicionou versões 6, 7 e 8 e escreveu conselhos modernos sobre aleatoriedade
Em 2024, o IETF publicou RFC 9562, que obsoleta RFC 4122 e adiciona as versões 6, 7 e 8. A versão 6 reordena os campos de tempo da versão 1 para melhor localidade e classificação da árvore B. A versão 7 usa um carimbo de data/hora Unix moderno e familiar em vez da contagem baseada em 1582, melhorando a classificação e atendendo aos requisitos de banco de dados modernos. A versão 8 reserva espaço para implementações personalizadas e designs experimentais UUID. As novas versões abordam problemas que surgiram ao longo de quarenta anos de implantação do UUID: o baixo desempenho do banco de dados de chaves aleatórias, o vazamento de privacidade da versão 1 e o desejo por identificadores classificáveis em sistemas em nuvem. No entanto, a estrutura central de 128 bits, os campos de variante e versão e o layout geral permanecem intactos.
O que isso não cobre – detalhes de implementação de cada versão, que possuem suas próprias postagens
A adoção de UUIDs como GUIDs, identificadores globalmente exclusivos no modelo de objeto componente, pela Microsoft, incorporou-os profundamente nos sistemas Windows a partir da década de 1990. GUID apareceu no registro, nas interfaces COM e na infraestrutura do ActiveDirectory. A Microsoft adicionou uma pequena variação: eles armazenaram GUIDs em ordem de bytes little-endian para alguns componentes, afastando-se do padrão de ordem de bytes da rede. Essa peculiaridade persiste em algumas APIs do Windows: se você exportar um GUID do Windows e importá-lo para um sistema Unix, problemas de ordem de bytes podem causar aparentes incompatibilidades. Mas o formato em si é o mesmo, e a confusão é uma nota de rodapé no padrão, e não uma diferença fundamental. O estilo entre colchetes e letras maiúsculas {3FA85F64-5717-4562-B3FC-2C963F66AFA6} vem das convenções do Windows; outros sistemas preferem letras minúsculas e hífens sem colchetes.
Conclusão: um design de quarenta anos que ainda funciona - o gerador ToolAcre produz os UUIDs aleatórios (versão 4) que RFC 9562 ainda define para casos em que o pedido não é necessário
Uma linha do tempo trabalhada mostra a longevidade e estabilidade do design: Apollo NCS dos anos 1980 inventa o conceito; O DCE de 1992 OSF padroniza o layout; A Microsoft dos anos 2000 o incorpora ao Windows; 2005 IETF publica RFC 4122; 2024 IETF publica RFC 9562 com versões modernas. Este é um dos mais longos esforços de padronização na computação, não por causa de disputas, mas porque o design original era muito robusto e adaptável. Ele acomodou ondas de mudanças arquitetônicas – de sistemas NFS distribuídos a bancos de dados em nuvem, de Windows COM a dispositivos móveis, de máquinas 64 bits da década de 1980 a sistemas modernos – sem uma reformulação fundamental. O impacto prático é que os UUIDs são onipresentes e estáveis; ao gerar um UUID com o gerador ToolAcre, você está gerando um identificador cujo formato foi estabelecido na década de 1980, padronizado internacionalmente em 2005 e mantido em 2024 com relevância duradoura.