開発者ツール · UUID ジェネレーター
Apollo NCS から RFC まで 9562: UUID の短い歴史
· 背景
uuid 暗号化 ブラウザ API
奇妙な 8-4-4-4-12 レイアウトと 128 ビット サイズは、1980 年代の分散コンピューティングから継承されています。この投稿では、DCE、Microsoft の GUID、および 2 つの IETF 標準を介して、Apollo のネットワーク コンピューティング システムからの UUID を追跡します。
なぜ 128 ビットなのか、なぜハイフンなのか? — 新人が抱く疑問と歴史の答え
8-4-4-4-12 のハイフン付き形式と UUID の 128 ビット サイズは、歴史家が即座に疑問を呈する設計上の選択です。計算を簡単にするために 96 ビットを使用しないのはなぜでしょうか?なぜその特定のセグメント レイアウトなのでしょうか?なぜbase-64やより単純なエンコードではなく、ハイフンを含むbase-16を使用するのでしょうか?答えは、1980 年代初頭の分散コンピューティング プラットフォームである Apollo ネットワーク コンピューティング システムにあります。このシステムは、真の問題に直面していました。ネットワーク内のシステムは、中央機関なしで一意の識別子を割り当てる必要があり、それらの識別子は、圧倒的な確率で世界的に一意である必要がありました。 Apollo NCS は、タイムスタンプ、ネットワーク アドレス、およびクロック シーケンスを、どのマシンでも独立して生成できる 128 ビットの識別子に結合することで、この問題を解決しました。
Apollo ネットワーク コンピューティング システム — 時間とネットワーク アドレスから構築された一意の識別子の 1980 年代の起源
現在の標準は、Apollo NCS から OSF 分散コンピューティング環境およびその後の Microsoft プラットフォームまでの系統を記録します。この歴史は、最新のシステムが古いレイアウトのバリアント マーカーを保持しながら、認識可能な 128 ビット ファミリを共有している理由を説明しています。絶対的な一意性の保証は確立されていません。各バージョンには独自の生成ルールと障害モードがあります。永続的な成果は、中央登録サービスなしでの相互運用性です。ブラウザ、データベース、およびオペレーティング システムは、同じ標準 16 進数形式を交換し、そのバリアントおよびバージョン フィールドを検査し、生成レシピが受信側システムのニーズに適合するかどうかを判断できます。
OSF DCE とバリアント フィールド — 分散コンピューティング環境がレイアウトを形式化し、バリアント ビットを追加する方法
レイアウトは、デザインの最初から埋め込まれたバージョンおよびバリアント フィールドによる複数の生成戦略に対応します。時間ベースの生成、ランダム生成、および名前ベースの生成はすべて、同じ識別子空間内に共存できます。最新のアプリケーションには、1980 年代の NCS とは異なる要件 (ソート可能なキーが必要なデータベース、プライバシーが必要なクラウド システム、衝突耐性が必要な分散システム) がありますが、同じ 128 ビット構造が依然としてそれらに対応します。 2024 の RFC 9562 に追加されたバージョン 6 および 7 は、元の設計者が下位互換性を損なうことなく将来の進化の余地を残したことを証明しています。
Microsoft の GUID — COM、レジストリ、および現在も存続している中括弧と大文字のスタイル
Apollo Network Computing System は、1980 年代に Apollo Computer ワークステーション上で実行されていた分散コンピューティング プラットフォームです。これは、リモート プロシージャ コール、データ レプリケーション、およびネーミング サービスのグローバルに一意な識別子に依存していました。ネットワークが分断されたり切断されたりした場合、中央サーバーに接続できないため、ネットワーク内のノードは ID 割り当てを調整する方法がありませんでした。そこで、Apollo の設計者は、タイムスタンプ 60 ビット、通常はネットワーク カードの MAC アドレスから派生するノード識別子 48 ビット、およびクロックの変更を処理するためのクロック シーケンス 14 ビットを組み合わせた 128 ビット形式を作成しました。このアプローチでは、ノードは時間、クロック シーケンス、ノード フィールドを組み合わせて識別子を独立して生成できます。その動作は依然としてクロックとノードの選択に依存していました。
RFC 4122 (2005) — ITU-T X.667 に準拠したバージョン 1 から 5 と URN 名前空間を定義した IETF 標準
OSF が後にこれを 1992 を中心とした分散コンピューティング環境用に標準化したとき、同じレイアウトを維持し、異なる UUID タイプを区別するためにバリアント フィールドを追加しました。この設計は実稼働システムですでに実証されています。 IETF は、Apollo NCS から約 20 年後、DCE 標準化から約 13 年後、RFC 4122 を 2005 で標準化しました。 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 設計用のスペースを予約しています。新しいバージョンは、UUID の 40 年間の展開で明らかになった問題、つまり、ランダム キーのデータベース パフォーマンスの低下、バージョン 1 のプライバシー漏洩、クラウド システムでの並べ替え可能な識別子の要望に対処しています。ただし、コアの 128 ビット構造、バリアントおよびバージョン フィールド、および全体のレイアウトはそのまま残ります。
これでカバーされないもの — 各バージョンの実装の詳細 (独自の投稿があります)
Microsoft は、1990 年代からコンポーネント オブジェクト モデルの GUID グローバル一意識別子として UUID を採用し、Windows システムに UUID を深く埋め込みました。 GUID は、レジストリ、COM インターフェイス、および ActiveDirectory インフラストラクチャに出現しました。 Microsoft はマイナーなバリエーションを追加しました。ネットワーク バイト オーダー標準から逸脱して、一部のコンポーネントの GUID をリトル エンディアン バイト オーダーで保存しました。この問題は一部の Windows API にも残ります。GUID を Windows からエクスポートして Unix システムにインポートすると、バイト順序の問題により明らかな不一致が発生する可能性があります。しかし、形式自体は同じであり、この混乱は規格の脚注であり、根本的な違いではありません。中かっこと大文字のスタイル {3FA85F64-5717-4562-B3FC-2C963F66AFA6} は Windows の規約に基づいています。他のシステムでは、中括弧のない小文字とハイフンが好まれます。
要点: 40 年に渡って機能する設計 — ToolAcre ジェネレーターは、順序付けが必要ない場合のために RFC 9562 が今でも定義しているランダム (バージョン 4) UUID を生成します。
完成したタイムラインは、設計の長寿命と安定性を示しています。1980 年代の Apollo NCS がコンセプトを発明。 1992 OSF の DCE はレイアウトを標準化します。 2000 年代の Microsoft は Windows にそれを埋め込みました。 2005 IETF は RFC 4122 を公開します。 2024 IETF は最新バージョンの RFC 9562 を公開しています。これはコンピューティング分野における標準化の取り組みとしては最も長期にわたるものの 1 つであり、これは紛争のためではなく、元の設計が非常に堅牢で適応性が高かったためです。分散 NFS システムからクラウド データベース、Windows COM からモバイル デバイス、1980 年代の 64 ビット マシンから最新のシステムに至るまで、基本的な再設計を行うことなく、アーキテクチャの変化の波に対応してきました。実際の影響は、UUID が遍在し、安定していることです。 ToolAcre ジェネレーターで UUID を生成すると、1980 年代に確立された形式の識別子が生成され、2005 で国際的に標準化され、2024 で永続的な関連性が維持されます。