أدوات المطور · مولد UUID
من أبولو NCS إلى RFC 9562: تاريخ قصير لـ UUID
· خلفية
uuid التشفير متصفح API
تم توريث التخطيط الغريب 8-4-4-4-12 وحجم 128 بت من الحوسبة الموزعة في الثمانينيات. يتتبع هذا المنشور UUID من نظام حوسبة شبكة Apollo من خلال DCE، ومعيار GUID من Microsoft واثنين من معايير IETF.
لماذا 128 bits ولماذا تلك الواصلات؟ - الأسئلة التي يطرحها كل وافد جديد ويجيب عليها التاريخ
يعد التنسيق 8-4-4-4-12 التنسيق الموصول وحجم 128 بت لـ UUID اختيارات تصميمية يشكك فيها المؤرخون على الفور. لماذا لا 96 bits لتسهيل العمليات الحسابية؟ لماذا هذا تخطيط الجزء المحدد؟ لماذا الأساس-16 باستخدام الواصلات بدلاً من الأساس-64 أو التشفير الأبسط؟ تكمن الإجابات في نظام حوسبة شبكة أبولو في أوائل ثمانينيات القرن العشرين، وهو عبارة عن منصة حوسبة موزعة واجهت مشكلة حقيقية: حيث كانت الأنظمة في الشبكة بحاجة إلى تخصيص معرفات فريدة من دون سلطة مركزية، وكان لابد أن تكون هذه المعرفات فريدة عالميًا وباحتمالات ساحقة. قام Apollo NCS بحل هذه المشكلة عن طريق الجمع بين الطابع الزمني وعنوان الشبكة وتسلسل الساعة في معرف 128 بت الذي يمكن إنشاؤه بشكل مستقل بواسطة أي جهاز.
نظام حوسبة شبكة أبولو – أصل الثمانينيات من المعرفات الفريدة التي تم إنشاؤها من الوقت وعنوان الشبكة
يسجل المعيار الحالي السلالة من Apollo NCS عبر OSF بيئة الحوسبة الموزعة ومنصات Microsoft اللاحقة. يشرح هذا التاريخ سبب مشاركة الأنظمة الحديثة في عائلة 128 بت التي يمكن التعرف عليها مع الحفاظ على العلامات المتغيرة للتخطيطات القديمة. إنه لا يوفر ضمانًا مطلقًا للتفرد: كل إصدار له قواعد الجيل الخاصة به وأنماط الفشل. الإنجاز الدائم هو إمكانية التشغيل البيني بدون خدمة تسجيل مركزية. يمكن للمتصفح وقاعدة البيانات ونظام التشغيل تبادل نفس النموذج السداسي العشري المتعارف عليه، وفحص حقول المتغير والإصدار، وتحديد ما إذا كانت الوصفة المنتجة تناسب احتياجات النظام المتلقي.
OSF DCE والحقل المتغير - كيف قامت بيئة الحوسبة الموزعة بإضفاء الطابع الرسمي على التخطيط وإضافة البتات المتغيرة
يستوعب التخطيط استراتيجيات إنشاء متعددة من خلال حقول الإصدار والمتغيرات التي تم تضمينها منذ بداية التصميم. يمكن أن يتواجد كل من الإنشاء المستند إلى الوقت والتوليد العشوائي والتوليد المستند إلى الاسم في نفس مساحة المعرف. تتمتع التطبيقات الحديثة بمتطلبات مختلفة عما كانت عليه في الثمانينات NCS - قواعد البيانات التي تحتاج إلى مفاتيح قابلة للفرز، والأنظمة السحابية التي تريد الخصوصية، والأنظمة الموزعة التي تريد مقاومة التصادم - ومع ذلك فإن نفس البنية 128 بت لا تزال تستوعبها. الإصدارات 6 و7 التي تمت إضافتها في RFC 9562 في 2024 تثبت أن المصممين الأصليين تركوا مجالًا للتطور المستقبلي دون كسر التوافق مع الإصدارات السابقة.
GUID من Microsoft — COM، والتسجيل ونمط الأقواس والأحرف الكبيرة الذي لا يزال قائمًا حتى اليوم
كان نظام حوسبة شبكة أبولو عبارة عن منصة حوسبة موزعة تعمل على محطات عمل كمبيوتر أبولو في الثمانينات. لقد اعتمد على معرفات فريدة عالميًا لاستدعاءات الإجراءات عن بعد ونسخ البيانات وخدمات التسمية. لم يكن لدى العقد الموجودة في الشبكة طريقة لتنسيق تعيين المعرف لأنه لا يمكنك الاتصال بخادم مركزي إذا كانت الشبكة مقسمة أو منفصلة. لذلك قام مصممو Apollo بإنشاء تنسيق 128 بت يجمع بين الطابع الزمني 60 bits، ومعرف العقدة المشتق عادة من بطاقة الشبكة MAC العنوان 48 bits، وتسلسل الساعة 14 bits للتعامل مع تغييرات الساعة. يتيح هذا النهج للعقد إنشاء معرفات بشكل مستقل من خلال الجمع بين الوقت وتسلسل الساعة وحقل العقدة؛ لا يزال سلوكه يعتمد على الساعات واختيار العقدة.
RFC 4122 (2005) — معيار IETF الذي يحدد الإصدارات 1 إلى 5 ومساحة الاسم URN، المتوافقة مع ITU-T X.667
عندما قام OSF لاحقًا بتوحيد ذلك لبيئة الحوسبة الموزعة الخاصة بهم حول 1992، احتفظوا بنفس التخطيط وأضافوا حقل المتغير للتمييز بين أنواع UUID المختلفة. وقد تم بالفعل إثبات التصميم في أنظمة الإنتاج. تم توحيد IETF RFC 4122 في 2005، بعد عشرين عامًا تقريبًا من أبولو NCS وحوالي ثلاثة عشر عامًا بعد توحيد DCE. RFC 4122 الإصدارات المقننة 1 حتى 5: الإصدار 1 للإنشاء المستند إلى الوقت، الإصدار 3 المستند إلى الاسم مع MD5، الإصدار 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 بإعادة ترتيب الحقول الزمنية للإصدار 1 لتحسين موقع B-tree وإمكانية الفرز. يستخدم الإصدار 7 طابعًا زمنيًا حديثًا ومألوفًا لنظام Unix بدلاً من العدد المستند إلى 1582، مما يؤدي إلى تحسين إمكانية الفرز وملاءمة متطلبات قاعدة البيانات الحديثة. يحتفظ الإصدار 8 بمساحة للتطبيقات المخصصة والتصميمات التجريبية UUID. تعالج الإصدارات الجديدة المشكلات التي ظهرت على مدى أربعين عامًا من نشر UUID: ضعف أداء قاعدة البيانات للمفاتيح العشوائية، وتسريب الخصوصية للإصدار 1، والرغبة في معرفات قابلة للفرز في الأنظمة السحابية. ومع ذلك، تظل البنية الأساسية 128 بت، وحقول المتغير والإصدار والتخطيط العام سليمة.
ما لا يغطيه هذا هو تفاصيل التنفيذ لكل إصدار، والتي لها مشاركاتها الخاصة
إن اعتماد Microsoft للمعرفات الفريدة الفريدة (UUID) كمعرفات فريدة عالميًا في نموذج كائن المكون قد أدى إلى تضمينها بعمق في أنظمة Windows بدءًا من التسعينيات. ظهر GUID في السجل وفي واجهات COM وفي البنية الأساسية لـ ActiveDirectory. أضافت Microsoft اختلافًا بسيطًا: فقد قامت بتخزين المعرفات الفريدة العمومية (GUIDs) بترتيب بايت صغير لبعض المكونات، مبتعدة عن معيار ترتيب بايت الشبكة. تستمر هذه المشكلة في بعض واجهات برمجة تطبيقات Windows: إذا قمت بتصدير GUID من Windows واستيراده إلى نظام Unix، فقد تتسبب مشكلات ترتيب البايت في حدوث عدم تطابق واضح. لكن الشكل نفسه هو نفسه، والارتباك هو حاشية في المعيار، وليس فرقا جوهريا. يأتي نمط الأقواس والأحرف الكبيرة {3FA85F64-5717-4562-B3FC-2C963F66AFA6} من اصطلاحات Windows؛ تفضل الأنظمة الأخرى الأحرف الصغيرة والواصلات بدون الأقواس.
الوجبات الجاهزة: تصميم عمره أربعون عامًا لا يزال يعمل — يُنتج المولد ToolAcre المعرفات UUID العشوائية (الإصدار 4) التي لا يزال RFC 9562 يحددها للحالات التي لا يلزم فيها الطلب
يوضح الجدول الزمني العملي طول عمر التصميم واستقراره: في الثمانينيات، ابتكر أبولو NCS هذا المفهوم؛ 1992 OSF's DCE يعمل على توحيد التخطيط؛ في العقد الأول من القرن الحادي والعشرين، قامت شركة Microsoft بتضمينه في نظام التشغيل Windows؛ 2005 IETF ينشر RFC 4122؛ 2024 IETF ينشر RFC 9562 بالإصدارات الحديثة. يعد هذا واحدًا من أطول جهود التقييس في مجال الحوسبة، ليس بسبب النزاعات ولكن لأن التصميم الأصلي كان قويًا جدًا وقابلاً للتكيف. لقد استوعب موجات من التغيير المعماري — بدءًا من أنظمة NFS الموزعة إلى قواعد البيانات السحابية، ومن Windows COM إلى الأجهزة المحمولة، ومن أجهزة 64 بت في الثمانينيات إلى الأنظمة الحديثة - دون إعادة تصميم أساسية. التأثير العملي هو أن UUIDs موجودة في كل مكان ومستقرة؛ عندما تقوم بإنشاء UUID باستخدام المولد ToolAcre، فإنك تقوم بإنشاء معرف تم إنشاء تنسيقه في الثمانينيات، وتم توحيده دوليًا في 2005 وتم الحفاظ عليه في 2024 بأهمية دائمة.