Công cụ dành cho nhà phát triển · Trình tạo UUID
Từ Apollo NCS đến RFC 9562: Lịch sử ngắn gọn về UUID
· Lý lịch
uuid mật mã browser-apis
Bố cục 8-4-4-4-12 lẻ và kích thước 128-bit được kế thừa từ điện toán phân tán những năm 1980. Bài đăng này theo dõi UUID từ Hệ thống máy tính mạng của Apollo thông qua DCE, GUID của Microsoft và hai tiêu chuẩn IETF.
Tại sao 128 bits và tại sao lại có những dấu gạch nối đó? — những câu hỏi mà mọi người mới đến đều hỏi và câu trả lời trong lịch sử
Định dạng có dấu gạch nối 8-4-4-4-12 và kích thước bit 128 của UUID là những lựa chọn thiết kế mà các nhà sử học ngay lập tức đặt câu hỏi. Tại sao không 96 bits để làm toán dễ dàng hơn? Tại sao lại bố trí phân khúc cụ thể đó? Tại sao base-16 có dấu gạch ngang thay vì base-64 hoặc mã hóa đơn giản hơn? Câu trả lời nằm trong Hệ thống máy tính mạng Apollo vào đầu những năm 1980, một nền tảng điện toán phân tán gặp phải một vấn đề thực sự: các hệ thống trong mạng cần phân bổ số nhận dạng duy nhất mà không cần cơ quan trung ương và những số nhận dạng đó phải là duy nhất trên toàn cầu với xác suất áp đảo. Apollo NCS đã giải quyết vấn đề này bằng cách kết hợp dấu thời gian, địa chỉ mạng và chuỗi đồng hồ thành mã định danh 128-bit có thể được tạo độc lập bởi bất kỳ máy nào.
Hệ thống máy tính mạng Apollo - nguồn gốc của những mã định danh duy nhất được xây dựng từ thời gian và địa chỉ mạng vào những năm 1980
Tiêu chuẩn hiện tại ghi lại dòng từ Apollo NCS đến OSF Môi trường điện toán phân tán và các nền tảng Microsoft sau này. Lịch sử đó giải thích tại sao các hệ thống hiện đại chia sẻ dòng 128-bit dễ nhận biết trong khi vẫn giữ nguyên các điểm đánh dấu biến thể cho các bố cục cũ hơn. Nó không thiết lập sự đảm bảo tính duy nhất tuyệt đối: mỗi phiên bản có các quy tắc tạo và chế độ lỗi riêng. Thành tựu bền vững là khả năng tương tác mà không cần dịch vụ đăng ký trung tâm. Một trình duyệt, cơ sở dữ liệu và hệ điều hành có thể trao đổi cùng một dạng thập lục phân chuẩn, kiểm tra các trường biến thể và phiên bản của nó, đồng thời quyết định xem công thức sản xuất có phù hợp với nhu cầu của hệ thống tiếp nhận hay không.
OSF DCE và trường biến thể — cách Môi trường điện toán phân tán chính thức hóa bố cục và thêm các bit biến thể
Bố cục chứa nhiều chiến lược tạo thông qua các trường phiên bản và biến thể đã được nhúng từ đầu thiết kế. Việc tạo dựa trên thời gian, tạo ngẫu nhiên và tạo dựa trên tên đều có thể cùng tồn tại trong cùng một không gian định danh. Các ứng dụng hiện đại có các yêu cầu khác với NCS của những năm 1980—cơ sở dữ liệu muốn có khóa có thể sắp xếp, hệ thống đám mây muốn có quyền riêng tư, hệ thống phân tán muốn có khả năng chống va chạm—nhưng cấu trúc 128-bit vẫn đáp ứng được chúng. Các phiên bản 6 và 7 đã được thêm vào RFC 9562 trong 2024 chứng minh rằng các nhà thiết kế ban đầu vẫn còn chỗ cho sự phát triển trong tương lai mà không phá vỡ khả năng tương thích ngược.
GUID — COM của Microsoft, sổ đăng ký và kiểu dấu ngoặc nhọn và chữ hoa vẫn tồn tại cho đến ngày nay
Hệ thống máy tính mạng Apollo là một nền tảng điện toán phân tán chạy trên các máy trạm của Máy tính Apollo vào những năm 1980. Nó dựa vào các mã định danh duy nhất trên toàn cầu cho các cuộc gọi thủ tục từ xa, sao chép dữ liệu và dịch vụ đặt tên. Các nút trong mạng không có cách nào để phối hợp việc gán ID vì bạn không thể liên hệ với máy chủ trung tâm nếu mạng có thể bị phân vùng hoặc ngắt kết nối. Vì vậy, các nhà thiết kế của Apollo đã tạo định dạng 128-bit kết hợp dấu thời gian 60 bits, mã nhận dạng nút thường bắt nguồn từ địa chỉ MAC của card mạng 48 bits và chuỗi đồng hồ 14 bits để xử lý các thay đổi về đồng hồ. Cách tiếp cận này cho phép các nút tạo số nhận dạng độc lập bằng cách kết hợp thời gian, chuỗi đồng hồ và trường nút; hành vi của nó vẫn phụ thuộc vào đồng hồ và lựa chọn nút.
RFC 4122 (2005) — tiêu chuẩn IETF xác định các phiên bản 1 đến 5 và không gian tên URN, được căn chỉnh với ITU-T X.667
Khi OSF sau đó chuẩn hóa điều này cho Môi trường điện toán phân tán của họ xung quanh 1992, họ vẫn giữ nguyên bố cục và thêm trường biến thể để phân biệt các loại UUID khác nhau. Thiết kế đã được chứng minh trong các hệ thống sản xuất. IETF được tiêu chuẩn hóa RFC 4122 vào 2005, gần 20 năm sau Apollo NCS và khoảng 13 năm sau khi tiêu chuẩn hóa DCE. RFC 4122 phiên bản được mã hóa 1 đến 5: phiên bản 1 để tạo dựa trên thời gian, phiên bản 3 để tạo dựa trên tên với MD5, phiên bản 4 để tạo ngẫu nhiên và phiên bản 5 cho dựa trên tên với SHA-1. Tiêu chuẩn này ổn định và được áp dụng rộng rãi vì nó đã có mặt khắp nơi trong Microsoft Windows, cơ sở hạ tầng DNS và các hệ thống phân tán. Vào thời điểm RFC 4122 được xuất bản, UUID đã được nhúng vào cơ sở hạ tầng đến mức việc tiêu chuẩn hóa gần như mang tính hàn lâm.
RFC 9562 (2024) — bản sửa đổi đã lỗi thời RFC 4122, đã thêm các phiên bản 6, 7 và 8, đồng thời viết ra lời khuyên hiện đại về tính ngẫu nhiên
Trong 2024, IETF đã xuất bản RFC 9562, lỗi thời RFC 4122 và thêm các phiên bản 6, 7 và 8. Phiên bản 6 sắp xếp lại các trường thời gian của phiên bản 1 để có khả năng sắp xếp và vị trí cây B tốt hơn. Phiên bản 7 sử dụng dấu thời gian Unix hiện đại và quen thuộc thay vì số lượng dựa trên 1582, cải thiện khả năng sắp xếp và phù hợp với các yêu cầu cơ sở dữ liệu hiện đại. Phiên bản 8 dành chỗ cho việc triển khai tùy chỉnh và thiết kế UUID thử nghiệm. Phiên bản mới giải quyết các vấn đề nảy sinh trong hơn 40 năm triển khai UUID: hiệu suất cơ sở dữ liệu kém của các khóa ngẫu nhiên, rò rỉ quyền riêng tư của phiên bản 1 và mong muốn có số nhận dạng có thể sắp xếp trong hệ thống đám mây. Tuy nhiên, cấu trúc cốt lõi 128-bit, các trường biến thể và phiên bản cũng như bố cục tổng thể vẫn được giữ nguyên.
Điều này không bao gồm những gì - chi tiết triển khai của từng phiên bản, có bài đăng riêng
Việc Microsoft áp dụng UUID làm GUID Định danh duy nhất trên toàn cầu trong Mô hình đối tượng thành phần đã nhúng chúng sâu vào các hệ thống Windows bắt đầu từ những năm 1990. GUID xuất hiện trong sổ đăng ký, trong giao diện COM và trong cơ sở hạ tầng ActiveDirectory. Microsoft đã thêm một biến thể nhỏ: họ lưu trữ GUID theo thứ tự byte cuối nhỏ cho một số thành phần, khác với tiêu chuẩn thứ tự byte mạng. Vấn đề đó vẫn tồn tại trong một số API Windows: nếu bạn xuất GUID từ Windows và nhập nó vào hệ thống Unix, các vấn đề về thứ tự byte có thể gây ra sự không khớp rõ ràng. Nhưng bản thân định dạng thì giống nhau và sự nhầm lẫn chỉ là chú thích cuối trang trong tiêu chuẩn chứ không phải là sự khác biệt cơ bản. Kiểu dấu ngoặc nhọn và chữ hoa {3FA85F64-5717-4562-B3FC-2C963F66AFA6} xuất phát từ các quy ước của Windows; các hệ thống khác thích chữ thường và dấu gạch nối không có dấu ngoặc nhọn.
Bài học rút ra: thiết kế đã 40 năm vẫn hoạt động — trình tạo ToolAcre tạo ra các UUID ngẫu nhiên (phiên bản 4) mà RFC 9562 vẫn xác định cho các trường hợp không cần đặt hàng
Dòng thời gian hoạt động cho thấy tuổi thọ và tính ổn định của thiết kế: Apollo những năm 1980 NCS phát minh ra khái niệm; 1992 OSF'S DCE chuẩn hóa bố cục; Những năm 2000 Microsoft nhúng nó vào Windows; 2005 IETF xuất bản RFC 4122; 2024 IETF xuất bản RFC 9562 với các phiên bản hiện đại. Đó là một trong những nỗ lực tiêu chuẩn hóa lâu dài nhất trong lĩnh vực điện toán, không phải vì tranh chấp mà vì thiết kế ban đầu quá mạnh mẽ và có khả năng thích ứng. Nó đã tạo điều kiện cho các làn sóng thay đổi kiến trúc—từ phân tán NFS hệ thống đến cơ sở dữ liệu đám mây, từ Windows COM đến thiết bị di động, từ những năm 1980 64-máy bit cho đến các hệ thống hiện đại—không cần thiết kế lại cơ bản. Tác động thực tế là UUID có mặt khắp nơi và ổn định; khi bạn tạo ra một UUID với ToolAcre trình tạo, bạn đang tạo một mã định danh có định dạng được thiết lập vào những năm 1980, được tiêu chuẩn hóa quốc tế trong 2005 và duy trì ở 2024 với sự liên quan lâu dài.