डेवलपर टूल · UUID जनरेटर
अपोलो NCS से RFC 9562 तक: UUID का संक्षिप्त इतिहास
· पेजभूमि
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
विषम 8-4-4-4-12 लेआउट और 128-बिट आकार 1980 के वितरित कंप्यूटिंग से विरासत में मिला है। यह पोस्ट अपोलो के नेटवर्क कंप्यूटिंग सिस्टम से DCE, माइक्रोसॉफ्ट के GUID और दो IETF मानकों के माध्यम से UUID का पता लगाता है।
128 bits क्यों और ये हाइफ़न क्यों? - वे प्रश्न जो हर नवागंतुक पूछता है और इतिहास उत्तर देता है
8-4-4-4-12 हाइफ़नेटेड प्रारूप और UUID का 128-बिट आकार ऐसे डिज़ाइन विकल्प हैं जिन पर इतिहासकार तुरंत सवाल उठाते हैं। आसान गणित के लिए 96 bits क्यों नहीं? वह विशिष्ट खंड लेआउट क्यों? आधार-64 या सरल एन्कोडिंग के बजाय आधार-16 को हाइफ़न के साथ क्यों? उत्तर 1980 के दशक की शुरुआत में अपोलो नेटवर्क कंप्यूटिंग सिस्टम में छिपे हैं, एक वितरित कंप्यूटिंग प्लेटफ़ॉर्म जिसे एक वास्तविक समस्या का सामना करना पड़ा: एक नेटवर्क में सिस्टम को केंद्रीय प्राधिकरण के बिना अद्वितीय पहचानकर्ताओं को आवंटित करने की आवश्यकता होती थी, और उन पहचानकर्ताओं को अत्यधिक संभावना के साथ विश्व स्तर पर अद्वितीय होना था। अपोलो NCS ने एक टाइमस्टैम्प, एक नेटवर्क पता और एक घड़ी अनुक्रम को एक 128-बिट पहचानकर्ता में संयोजित करके इस समस्या को हल किया जिसे किसी भी मशीन द्वारा स्वतंत्र रूप से उत्पन्न किया जा सकता है।
अपोलो नेटवर्क कंप्यूटिंग सिस्टम - 1980 के दशक में समय और नेटवर्क पते से निर्मित अद्वितीय पहचानकर्ताओं की उत्पत्ति
वर्तमान मानक अपोलो NCS से OSF वितरित कंप्यूटिंग वातावरण और बाद में Microsoft प्लेटफ़ॉर्म तक की वंशावली को रिकॉर्ड करता है। वह इतिहास बताता है कि क्यों आधुनिक सिस्टम पुराने लेआउट के लिए भिन्न मार्करों को संरक्षित करते हुए एक पहचानने योग्य 128-बिट परिवार साझा करते हैं। यह पूर्ण विशिष्टता की गारंटी स्थापित नहीं करता है: प्रत्येक संस्करण के अपने स्वयं के पीढ़ी नियम और विफलता मोड होते हैं। टिकाऊ उपलब्धि केंद्रीय पंजीकरण सेवा के बिना अंतरसंचालनीयता है। एक ब्राउज़र, डेटाबेस और ऑपरेटिंग सिस्टम समान कैनोनिकल हेक्साडेसिमल फॉर्म का आदान-प्रदान कर सकते हैं, इसके वेरिएंट और संस्करण फ़ील्ड का निरीक्षण कर सकते हैं, और यह तय कर सकते हैं कि उत्पादन नुस्खा प्राप्तकर्ता सिस्टम की आवश्यकताओं के अनुरूप है या नहीं।
OSF DCE और वैरिएंट फ़ील्ड - कैसे वितरित कंप्यूटिंग वातावरण ने लेआउट को औपचारिक बनाया और वैरिएंट बिट्स जोड़े
लेआउट संस्करण और भिन्न फ़ील्ड के माध्यम से कई पीढ़ी की रणनीतियों को समायोजित करता है जो डिज़ाइन की शुरुआत से एम्बेडेड थे। समय-आधारित पीढ़ी, यादृच्छिक पीढ़ी और नाम-आधारित पीढ़ी सभी एक ही पहचानकर्ता स्थान में सह-अस्तित्व में रह सकते हैं। आधुनिक अनुप्रयोगों की 1980 के दशक की NCS से भिन्न आवश्यकताएं हैं - डेटाबेस जो सॉर्ट करने योग्य कुंजी चाहते हैं, क्लाउड सिस्टम जो गोपनीयता चाहते हैं, वितरित सिस्टम जो टकराव प्रतिरोध चाहते हैं - फिर भी वही 128-बिट संरचना अभी भी उन्हें समायोजित करती है। संस्करण 6 और 7 जो 2024 में RFC 9562 में जोड़े गए थे, यह साबित करते हैं कि मूल डिजाइनरों ने पिछली अनुकूलता को तोड़े बिना भविष्य के विकास के लिए जगह छोड़ी थी।
माइक्रोसॉफ्ट की GUID - COM, रजिस्ट्री और ब्रेसिज़-और-अपरकेस शैली जो आज भी कायम है
अपोलो नेटवर्क कंप्यूटिंग सिस्टम एक वितरित कंप्यूटिंग प्लेटफ़ॉर्म था जो 1980 के दशक में अपोलो कंप्यूटर वर्कस्टेशन पर चलता था। यह दूरस्थ प्रक्रिया कॉल, डेटा प्रतिकृति और नामकरण सेवाओं के लिए विश्व स्तर पर अद्वितीय पहचानकर्ताओं पर निर्भर था। नेटवर्क में नोड्स के पास ID असाइनमेंट को समन्वित करने का कोई तरीका नहीं था क्योंकि यदि नेटवर्क विभाजित या डिस्कनेक्ट हो जाता तो आप केंद्रीय सर्वर से संपर्क नहीं कर सकते। इसलिए अपोलो डिजाइनरों ने टाइमस्टैम्प 60 bits को मिलाकर एक 128-बिट प्रारूप बनाया, एक नोड पहचानकर्ता जो आमतौर पर नेटवर्क कार्ड MAC पते 48 bits और घड़ी अनुक्रम 14 bits से प्राप्त होता है ताकि घड़ी में बदलाव को संभाला जा सके। यह दृष्टिकोण नोड्स को समय, एक घड़ी अनुक्रम और एक नोड फ़ील्ड को मिलाकर स्वतंत्र रूप से पहचानकर्ता उत्पन्न करने देता है; इसका व्यवहार अभी भी घड़ियों और नोड चयन पर निर्भर था।
RFC 4122 (2005) - द IETF मानक जो संस्करणों को परिभाषित करता है 1 को 5 और यह URN नेमस्पेस, के साथ संरेखित ITU-टी एक्स.667
जब OSF ने बाद में 1992 के आसपास अपने वितरित कंप्यूटिंग वातावरण के लिए इसे मानकीकृत किया, तो उन्होंने एक ही लेआउट रखा और विभिन्न UUID प्रकारों को अलग करने के लिए वैरिएंट फ़ील्ड जोड़ा। डिज़ाइन पहले से ही उत्पादन प्रणालियों में सिद्ध हो चुका था। IETF ने 2005 में RFC 4122 को मानकीकृत किया, अपोलो NCS के लगभग बीस साल बाद और DCE मानकीकरण के लगभग तेरह साल बाद। RFC 4122 संहिताबद्ध संस्करण 1 से 5: समय-आधारित पीढ़ी के लिए संस्करण 1, नाम-आधारित पीढ़ी के लिए संस्करण 3, MD5 के साथ संस्करण 4 यादृच्छिक, और SHA-1 के साथ नाम-आधारित संस्करण 5। मानक स्थिर था और व्यापक रूप से अपनाया गया था क्योंकि यह पहले से ही 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 के समय क्षेत्रों को पुन: व्यवस्थित करता है। संस्करण 7 1582-आधारित गणना के बजाय आधुनिक और परिचित Unix टाइमस्टैम्प का उपयोग करता है, जो क्रमबद्धता में सुधार करता है और आधुनिक डेटाबेस आवश्यकताओं को पूरा करता है। संस्करण 8 कस्टम कार्यान्वयन और प्रयोगात्मक UUID डिज़ाइन के लिए स्थान आरक्षित करता है। नए संस्करण UUID परिनियोजन के चालीस वर्षों में उभरी समस्याओं का समाधान करते हैं: यादृच्छिक कुंजियों का खराब डेटाबेस प्रदर्शन, संस्करण 1 की गोपनीयता लीक, और क्लाउड सिस्टम में क्रमबद्ध पहचानकर्ताओं की इच्छा। फिर भी कोर 128-बिट संरचना, वैरिएंट और संस्करण फ़ील्ड और समग्र लेआउट बरकरार है।
इसमें क्या शामिल नहीं है - प्रत्येक संस्करण का कार्यान्वयन विवरण, जिसकी अपनी पोस्ट हैं
माइक्रोसॉफ्ट द्वारा UUID को GUID के रूप में कंपोनेंट ऑब्जेक्ट मॉडल में वैश्विक रूप से अद्वितीय पहचानकर्ताओं को अपनाने से उन्हें 1990 के दशक से विंडोज सिस्टम में गहराई से एम्बेड किया गया। GUID रजिस्ट्री में, COM इंटरफेस में और ActiveDirectory इंफ्रास्ट्रक्चर में दिखाई दिया। माइक्रोसॉफ्ट ने एक मामूली बदलाव जोड़ा: उन्होंने नेटवर्क-बाइट-ऑर्डर मानक से हटकर, कुछ घटकों के लिए GUID को छोटे-एंडियन बाइट क्रम में संग्रहीत किया। यह विचित्रता कुछ विंडोज़ APआई में बनी रहती है: यदि आप विंडोज़ से GUID निर्यात करते हैं और इसे Unix सिस्टम में आयात करते हैं, तो बाइट-ऑर्डर समस्याएं स्पष्ट बेमेल का कारण बन सकती हैं। लेकिन प्रारूप स्वयं वही है, और भ्रम मानक में एक फुटनोट है, कोई बुनियादी अंतर नहीं। ब्रेसिज़ और अपरकेस शैली {3FA85F64-5717-4562-B3FC-2C963F66AFA6} विंडोज़ परंपराओं से आती है; अन्य सिस्टम ब्रेसिज़ के बिना लोअरकेस और हाइफ़न पसंद करते हैं।
टेकअवे: एक चालीस-वर्षीय डिज़ाइन जो अभी भी काम करता है - ToolAcre जनरेटर यादृच्छिक (संस्करण 4) UUID उत्पन्न करता है जो RFC 9562 अभी भी उन मामलों के लिए परिभाषित करता है जहां ऑर्डर करने की आवश्यकता नहीं है
एक कार्यशील समयरेखा डिज़ाइन की दीर्घायु और स्थिरता को दर्शाती है: 1980 के दशक के अपोलो NCS ने अवधारणा का आविष्कार किया; 1992 OSF का DCE लेआउट को मानकीकृत करता है; 2000 के दशक में माइक्रोसॉफ्ट ने इसे विंडोज़ में एम्बेड किया; 2005 IETF RFC 4122 प्रकाशित करता है; 2024 IETF आधुनिक संस्करणों के साथ RFC 9562 प्रकाशित करता है। यह कंप्यूटिंग में सबसे लंबे मानकीकरण प्रयासों में से एक है, विवादों के कारण नहीं बल्कि इसलिए क्योंकि मूल डिज़ाइन इतना मजबूत और अनुकूलनीय था। इसने वास्तुशिल्प परिवर्तन की लहरों को समायोजित किया है - वितरित NFS सिस्टम से लेकर क्लाउड डेटाबेस तक, विंडोज़ COM से लेकर मोबाइल डिवाइस तक, 1980 के दशक की 64-बिट मशीनों से लेकर आधुनिक सिस्टम तक - बिना मौलिक रीडिज़ाइन के। व्यावहारिक प्रभाव यह है कि UUID सर्वव्यापी और स्थिर हैं; जब आप ToolAcre जनरेटर के साथ UUID उत्पन्न करते हैं, तो आप एक पहचानकर्ता उत्पन्न कर रहे हैं जिसका प्रारूप 1980 के दशक में स्थापित किया गया था, जिसे अंतरराष्ट्रीय स्तर पर 2005 में मानकीकृत किया गया था और स्थायी प्रासंगिकता के साथ 2024 में बनाए रखा गया था।