한국어

개발자 도구 · UUID 생성기

Apollo NCS에서 RFC까지 9562: UUID의 간략한 역사

· 배경

uuid 암호화 브라우저 API

DCE, GUID 및 RFC 4122를 통한 Apollo 네트워크 컴퓨팅 시스템에서 RFC 9562까지의 타임라인
원본 ToolAcre 벡터 일러스트레이션

이상한 8-4-4-4-12 레이아웃과 128비트 크기는 1980년대 분산 컴퓨팅에서 상속되었습니다. 이 게시물은 DCE, Microsoft의 GUID 및 두 가지 IETF 표준을 통해 Apollo의 네트워크 컴퓨팅 시스템에서 UUID를 추적합니다.

왜 128 비트이고 그 하이픈은 무엇입니까? — 모든 신규 이민자가 묻는 질문과 역사 답변

8-4-4-4-12 하이픈 형식과 UUID의 128비트 크기는 역사가들이 즉시 의문을 제기하는 디자인 선택입니다. 더 쉬운 수학을 위해 96 비트를 사용하지 않는 이유는 무엇입니까? 왜 특정 세그먼트 레이아웃이 필요합니까? base-64 또는 더 간단한 인코딩 대신 하이픈을 사용하는 base-16을 사용하는 이유는 무엇입니까? 그 대답은 1980년대 초의 Apollo 네트워크 컴퓨팅 시스템에 있습니다. 분산 컴퓨팅 플랫폼은 진정한 문제에 직면했습니다. 즉, 네트워크의 시스템은 중앙 권한 없이 고유 식별자를 할당해야 하고, 해당 식별자는 압도적인 확률로 전역적으로 고유해야 했습니다. Apollo NCS는 타임스탬프, 네트워크 주소 및 시계 시퀀스를 모든 시스템에서 독립적으로 생성할 수 있는 128비트 식별자로 결합하여 이 문제를 해결했습니다.

Apollo 네트워크 컴퓨팅 시스템 — 시간과 네트워크 주소를 기반으로 구축된 고유 식별자의 1980년대 기원

현재 표준은 OSF 분산 컴퓨팅 환경 및 이후 Microsoft 플랫폼을 통해 Apollo NCS의 계보를 기록합니다. 이러한 역사는 최신 시스템이 이전 레이아웃에 대한 변형 마커를 유지하면서 인식 가능한 128 비트 제품군을 공유하는 이유를 설명합니다. 절대적인 고유성을 보장하지는 않습니다. 각 버전에는 고유한 생성 규칙과 오류 모드가 있습니다. 지속적인 성과는 중앙 등록 서비스가 없는 상호 운용성입니다. 브라우저, 데이터베이스 및 운영 체제는 동일한 표준 16진수 형식을 교환하고, 변형 및 버전 필드를 검사하고, 생성 레시피가 수신 시스템의 요구 사항에 맞는지 여부를 결정할 수 있습니다.

OSF DCE 및 변형 필드 — 분산 컴퓨팅 환경이 레이아웃을 공식화하고 변형 비트를 추가하는 방법

레이아웃은 설계 시작부터 포함된 버전 및 변형 필드를 통해 여러 생성 전략을 수용합니다. 시간 기반 생성, 무작위 생성 및 이름 기반 생성은 모두 동일한 식별자 공간에 공존할 수 있습니다. 최신 애플리케이션은 정렬 가능한 키를 원하는 데이터베이스, 개인 정보 보호를 원하는 클라우드 시스템, 충돌 방지를 원하는 분산 시스템 등 1980년대 NCS와는 다른 요구 사항을 갖고 있지만 동일한 128비트 구조는 여전히 이러한 요구 사항을 수용합니다. 2024의 RFC 9562에 추가된 버전 6 및 7는 원래 설계자가 이전 버전과의 호환성을 유지하면서 향후 발전을 위한 여지를 남겼음을 증명합니다.

Microsoft의 GUID — COM, 레지스트리, 오늘날에도 지속되는 중괄호 및 대문자 스타일

Apollo 네트워크 컴퓨팅 시스템은 1980년대 Apollo Computer 워크스테이션에서 실행된 분산 컴퓨팅 플랫폼이었습니다. 원격 프로시저 호출, 데이터 복제 및 이름 지정 서비스에 대해 전역적으로 고유한 식별자를 사용했습니다. 네트워크가 분할되거나 연결이 끊어지면 중앙 서버에 연결할 수 없기 때문에 네트워크의 노드는 ID 할당을 조정할 방법이 없습니다. 따라서 Apollo 설계자는 타임스탬프 60 비트, 일반적으로 네트워크 카드 MAC 주소 48 비트에서 파생된 노드 식별자, 클록 변경을 처리하기 위한 클록 시퀀스 14 비트를 결합한 128 비트 형식을 만들었습니다. 이 접근 방식을 사용하면 노드는 시간, 클록 시퀀스 및 노드 필드를 결합하여 독립적으로 식별자를 생성할 수 있습니다. 그 동작은 여전히 ​​시계와 노드 선택에 따라 달라집니다.

RFC 4122 (2005) — 1 ~ 5 버전과 URN 네임스페이스를 정의한 IETF 표준으로, ITU-T X.667에 맞춰 조정되었습니다.

OSF는 나중에 1992 주변의 분산 컴퓨팅 환경에 대해 이를 표준화했을 때 동일한 레이아웃을 유지하고 다양한 UUID 유형을 구별하기 위해 변형 필드를 추가했습니다. 디자인은 이미 생산 시스템에서 입증되었습니다. IETF는 Apollo NCS 이후 거의 20년, DCE 표준화 이후 약 13년 후인 2005에서 RFC 4122를 표준화했습니다. RFC 4122 성문화된 버전 1 ~ 5: 시간 기반 생성의 경우 버전 1, MD5를 사용한 이름 기반의 경우 버전 3, 임의의 경우 버전 4, 이름 기반 생성의 경우 버전 5 SHA-1. 이 표준은 이미 Microsoft Windows, DNS 인프라 및 분산 시스템에 널리 퍼져 있었기 때문에 안정적이고 널리 채택되었습니다. RFC 4122가 게시되었을 때 UUID은 이미 인프라에 너무 내장되어 표준화가 거의 학문적인 수준이었습니다.

RFC 9562 (2024) — RFC 4122을 폐기하고 6, 7 및 8 버전을 추가하고 무작위성에 대한 최신 조언을 기록한 개정판입니다.

2024에서 IETF는 RFC 9562을 게시했습니다. 이는 RFC 4122를 폐기하고 6, 7 및 8 버전을 추가합니다. 버전 6은 더 나은 B-트리 지역성과 정렬 가능성을 위해 버전 1의 시간 필드를 재정렬합니다. 버전 7은 1582 기반 카운트 대신 현대적이고 친숙한 Unix 타임스탬프를 사용하여 정렬 가능성을 개선하고 최신 데이터베이스 요구 사항에 적합합니다. 버전 8은 사용자 정의 구현 및 실험적인 UUID 설계를 위한 공간을 예약합니다. 새 버전은 40년 동안 UUID 배포를 통해 발생한 문제, 즉 임의 키의 낮은 데이터베이스 성능, 1 버전의 개인정보 유출, 클라우드 시스템의 정렬 가능한 식별자에 대한 요구 등을 해결합니다. 그러나 핵심 128비트 구조, 변형 및 버전 필드, 전체 레이아웃은 그대로 유지됩니다.

여기서 다루지 않는 내용 — 자체 게시물이 있는 각 버전의 구현 세부정보

Microsoft는 UUID를 구성 요소 개체 모델의 GUID 전역 고유 식별자로 채택하여 1990년대부터 Windows 시스템에 깊이 내장했습니다. GUID는 레지스트리, COM 인터페이스 및 ActiveDirectory 인프라에 나타났습니다. Microsoft는 약간의 변형을 추가했습니다. 즉, 네트워크 바이트 순서 표준에서 벗어나 일부 구성 요소에 대해 리틀 엔디안 바이트 순서로 GUID를 저장했습니다. 이러한 문제는 일부 Windows API에서 지속됩니다. Windows에서 GUID를 내보내고 이를 Unix 시스템으로 가져오는 경우 바이트 순서 문제로 인해 명백한 불일치가 발생할 수 있습니다. 하지만 형식 자체는 동일하며 혼동은 표준의 각주일 뿐 근본적인 차이는 아닙니다. 중괄호 및 대문자 스타일 {3FA85F64-5717-4562-B3FC-2C963F66AFA6}은 Windows 규칙에서 유래되었습니다. 다른 시스템에서는 중괄호가 없는 소문자와 하이픈을 선호합니다.

요점: 여전히 작동하는 40년 설계 — ToolAcre 생성기는 주문이 필요하지 않은 경우에 대해 RFC 9562이 여전히 정의하는 무작위(버전 4) UUID를 생성합니다.

작업된 타임라인은 디자인의 수명과 안정성을 보여줍니다. 1980년대 Apollo NCS가 컨셉을 발명했습니다. 1992 OSF의 DCE는 레이아웃을 표준화합니다. 2000년대 마이크로소프트는 이를 윈도우에 내장했다. 2005 IETF는 RFC 4122를 게시합니다. 2024 IETF는 최신 버전의 RFC 9562를 게시합니다. 이는 논쟁 때문이 아니라 원래 디자인이 매우 강력하고 적응력이 뛰어났기 때문에 컴퓨팅 분야에서 가장 긴 표준화 노력 중 하나입니다. 분산 NFS 시스템에서 클라우드 데이터베이스, Windows COM에서 모바일 장치, 1980년대 64비트 시스템에서 최신 시스템에 이르기까지 근본적인 재설계 없이 아키텍처 변화의 물결을 수용했습니다. 실질적인 영향은 UUID가 어디에나 있고 안정적이라는 것입니다. ToolAcre 생성기로 UUID을 생성하면 1980년대에 확립되고 2005에서 국제적으로 표준화되었으며 지속적인 관련성을 가지고 2024에서 유지 관리되는 형식의 식별자를 생성하게 됩니다.