เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
จากอพอลโล NCS ถึง RFC 9562: ประวัติโดยย่อของ UUID
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
เค้าโครง 8-4-4-4-12 แบบแปลก และขนาด 128-บิต นั้นสืบทอดมาจากการคำนวณแบบกระจายในปี 1980 โพสต์นี้ติดตาม UUID จากระบบคอมพิวเตอร์เครือข่ายของ Apollo ผ่าน DCE, GUID ของ Microsoft และมาตรฐาน IETF สองมาตรฐาน
เพราะเหตุใด 128 bits และเพราะเหตุใดจึงใช้ยัติภังค์เหล่านั้น — คำถามที่ผู้มาใหม่ทุกคนถามและคำตอบในประวัติศาสตร์
รูปแบบ 8-4-4-4-12 รูปแบบยัติภังค์และ 128 บิตของ UUID เป็นตัวเลือกการออกแบบที่นักประวัติศาสตร์ตั้งคำถามในทันที ทำไมไม่ 96 bits เพื่อคณิตศาสตร์ที่ง่ายขึ้นล่ะ เหตุใดจึงต้องจัดวางส่วนเฉพาะดังกล่าว เหตุใด base-16 ด้วยยัติภังค์แทนที่จะเป็น base-64 หรือการเข้ารหัสที่ง่ายกว่า คำตอบอยู่ในระบบคอมพิวเตอร์เครือข่าย Apollo ในช่วงต้นทศวรรษ 1980 ซึ่งเป็นแพลตฟอร์มคอมพิวเตอร์แบบกระจายที่ประสบปัญหาอย่างแท้จริง นั่นคือ ระบบในเครือข่ายจำเป็นต้องจัดสรรตัวระบุที่ไม่ซ้ำกันโดยไม่มีอำนาจจากส่วนกลาง และตัวระบุเหล่านั้นจะต้องมีเอกลักษณ์เฉพาะทั่วโลกและมีความน่าจะเป็นอย่างล้นหลาม Apollo NCS แก้ไขปัญหานี้โดยการรวมการประทับเวลา ที่อยู่เครือข่าย และลำดับนาฬิกาเข้ากับตัวระบุ 128 บิตที่สามารถสร้างได้อย่างอิสระโดยเครื่องใดก็ได้
Apollo Network Computing System — ต้นกำเนิดของตัวระบุเฉพาะที่สร้างขึ้นในช่วงทศวรรษ 1980 ตามเวลาและที่อยู่เครือข่าย
มาตรฐานปัจจุบันบันทึกเชื้อสายจาก Apollo NCS ผ่าน OSF Distributed Computing Environment และแพลตฟอร์ม Microsoft รุ่นใหม่กว่า ประวัติดังกล่าวอธิบายว่าทำไมระบบสมัยใหม่จึงแบ่งปันตระกูล 128 บิตที่เป็นที่รู้จัก ในขณะที่ยังคงรักษาเครื่องหมายตัวแปรสำหรับเค้าโครงเก่า ไม่ได้สร้างการรับประกันเอกลักษณ์ที่แน่นอน: แต่ละเวอร์ชันมีกฎการสร้างและโหมดความล้มเหลวของตัวเอง ความสำเร็จที่ยั่งยืนคือการทำงานร่วมกันได้โดยไม่ต้องใช้บริการลงทะเบียนจากส่วนกลาง เบราว์เซอร์ ฐานข้อมูล และระบบปฏิบัติการสามารถแลกเปลี่ยนรูปแบบเลขฐานสิบหกมาตรฐานที่เหมือนกัน ตรวจสอบช่องตัวแปรและเวอร์ชัน และตัดสินใจว่าสูตรการผลิตนั้นตรงกับความต้องการของระบบที่รับหรือไม่
OSF DCE และฟิลด์ตัวแปร - วิธีที่ Distributed Computing Environment จัดรูปแบบอย่างเป็นทางการและเพิ่มบิตของตัวแปร
เค้าโครงรองรับกลยุทธ์การสร้างหลายรุ่นผ่านช่องเวอร์ชันและตัวแปรที่ฝังไว้ตั้งแต่เริ่มต้นการออกแบบ การสร้างตามเวลา การสร้างแบบสุ่ม และการสร้างตามชื่อสามารถอยู่ร่วมกันได้ในพื้นที่ตัวระบุเดียวกัน แอปพลิเคชันสมัยใหม่มีข้อกำหนดที่แตกต่างจาก NCS ในช่วงทศวรรษ 1980 ไม่ว่าจะเป็นฐานข้อมูลที่ต้องการคีย์ที่จัดเรียงได้ ระบบคลาวด์ที่ต้องการความเป็นส่วนตัว ระบบแบบกระจายที่ต้องการความต้านทานการชนกัน แต่โครงสร้าง 128 บิตเดียวกันยังคงรองรับแอปพลิเคชันเหล่านั้น เวอร์ชัน 6 และ 7 ซึ่งเพิ่มใน RFC 9562 ใน 2024 พิสูจน์ว่านักออกแบบดั้งเดิมเหลือพื้นที่ไว้สำหรับการพัฒนาในอนาคตโดยไม่ทำลายความเข้ากันได้แบบย้อนหลัง
GUID ของ Microsoft — COM รีจิสทรีและรูปแบบวงเล็บปีกกาและตัวพิมพ์ใหญ่ที่ยังคงมีอยู่ในปัจจุบัน
Apollo Network Computing System เป็นแพลตฟอร์มการประมวลผลแบบกระจายที่ทำงานบนเวิร์กสเตชัน Apollo Computer ในช่วงทศวรรษ 1980 โดยอาศัยตัวระบุที่ไม่ซ้ำกันทั่วโลกสำหรับการเรียกขั้นตอนระยะไกล การจำลองข้อมูล และบริการตั้งชื่อ โหนดในเครือข่ายไม่มีวิธีประสานการกำหนด ID เนื่องจากคุณไม่สามารถติดต่อกับเซิร์ฟเวอร์กลางได้หากเครือข่ายอาจถูกแบ่งพาร์ติชันหรือยกเลิกการเชื่อมต่อ ดังนั้นผู้ออกแบบ 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 เกือบยี่สิบปีหลังจาก Apollo 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 locality และความสามารถในการจัดเรียงที่ดีขึ้น เวอร์ชัน 7 ใช้การประทับเวลา Unix ที่ทันสมัยและคุ้นเคย แทนการนับตาม 1582 ซึ่งปรับปรุงความสามารถในการจัดเรียงและปรับข้อกำหนดฐานข้อมูลสมัยใหม่ให้เหมาะสม เวอร์ชัน 8 สงวนพื้นที่สำหรับการใช้งานที่กำหนดเองและการออกแบบ UUID แบบทดลอง เวอร์ชันใหม่แก้ไขปัญหาที่เกิดขึ้นตลอดสี่สิบปีของการปรับใช้ UUID: ประสิทธิภาพของฐานข้อมูลที่ไม่ดีของคีย์สุ่ม การรั่วไหลของความเป็นส่วนตัวของเวอร์ชัน 1 และความต้องการตัวระบุที่จัดเรียงได้ในระบบคลาวด์ แต่โครงสร้างหลัก 128-บิต ฟิลด์ตัวแปรและเวอร์ชัน และโครงร่างโดยรวมยังคงไม่บุบสลาย
สิ่งนี้ไม่ครอบคลุม — รายละเอียดการใช้งานของแต่ละเวอร์ชันซึ่งมีโพสต์ของตัวเอง
การนำ UUID ของ Microsoft มาใช้เป็นตัวระบุ GUID ที่ไม่ซ้ำทั่วโลกใน Component Object Model ฝังตัว UUID เหล่านี้อย่างลึกซึ้งในระบบ Windows โดยเริ่มตั้งแต่ปี 1990 GUID ปรากฏในรีจิสทรี ในอินเทอร์เฟซ COM และในโครงสร้างพื้นฐาน ActiveDirectory Microsoft เพิ่มรูปแบบเล็กน้อย: พวกเขาจัดเก็บ GUID ในลำดับไบต์แบบ little-endian สำหรับส่วนประกอบบางส่วน ซึ่งแยกออกจากมาตรฐานลำดับไบต์ของเครือข่าย ลักษณะพิเศษดังกล่าวยังคงมีอยู่ใน Windows API บางตัว: หากคุณส่งออก GUID จาก Windows และนำเข้าไปยังระบบ Unix ปัญหาลำดับไบต์อาจทำให้เกิดความไม่ตรงกันได้อย่างชัดเจน แต่รูปแบบเองก็เหมือนกัน และความสับสนนั้นเป็นเพียงเชิงอรรถในมาตรฐาน ไม่ใช่ความแตกต่างพื้นฐาน รูปแบบวงเล็บปีกกาและตัวพิมพ์ใหญ่ {3FA85F64-5717-4562-B3FC-2C963F66AFA6} มาจากแบบแผนของ Windows; ระบบอื่นชอบใช้ตัวพิมพ์เล็กและยัติภังค์ที่ไม่มีเครื่องหมายปีกกา
Takeaway: การออกแบบสี่สิบปีที่ยังคงใช้งานได้ — ตัวสร้าง ToolAcre สร้าง UUID แบบสุ่ม (เวอร์ชัน 4) ที่ RFC 9562 ยังคงกำหนดไว้สำหรับกรณีที่ไม่จำเป็นต้องสั่งซื้อ
ลำดับเวลาที่ใช้งานแสดงให้เห็นถึงความยืนยาวและความมั่นคงของการออกแบบ: ในช่วงปี 1980 Apollo NCS คิดค้นแนวคิดนี้ 1992 OSF's DCE ทำให้เค้าโครงเป็นมาตรฐาน Microsoft ยุค 2000 ฝังไว้ใน Windows; 2005 IETF เผยแพร่ RFC 4122; 2024 IETF เผยแพร่ RFC 9562 ด้วยเวอร์ชันที่ทันสมัย นั่นเป็นหนึ่งในความพยายามในการสร้างมาตรฐานที่ยาวนานที่สุดในการประมวลผล ไม่ใช่เพราะข้อโต้แย้ง แต่เป็นเพราะการออกแบบดั้งเดิมมีความแข็งแกร่งและปรับเปลี่ยนได้ รองรับคลื่นของการเปลี่ยนแปลงทางสถาปัตยกรรม ตั้งแต่ระบบ NFS แบบกระจายไปจนถึงฐานข้อมูลบนคลาวด์ จาก Windows COM ไปจนถึงอุปกรณ์มือถือ จากเครื่อง 64 บิตในปี 1980 ไปจนถึงระบบสมัยใหม่ โดยไม่ต้องมีการออกแบบพื้นฐานใหม่ ผลกระทบในทางปฏิบัติคือ UUID นั้นแพร่หลายและมีเสถียรภาพ เมื่อคุณสร้าง UUID ด้วยตัวสร้าง ToolAcre คุณกำลังสร้างตัวระบุที่มีรูปแบบที่ถูกสร้างขึ้นในช่วงทศวรรษ 1980 ซึ่งเป็นมาตรฐานสากลใน 2005 และคงไว้ใน 2024 โดยมีความเกี่ยวข้องที่ยั่งยืน