Công cụ dành cho nhà phát triển · Trình tạo UUID
RFC 4122 so với RFC 9562: Điều gì đã thay đổi trong tiêu chuẩn 2024 UUID
· Lý lịch
uuid mật mã browser-apis
Hai RFC được trích dẫn cho UUID và chúng không nói lên điều gì hoàn toàn giống nhau. Bài đăng này trình bày những nội dung RFC 9562 đã được thêm, làm rõ và không được dùng nữa so với RFC 4122.
Tôi trích dẫn RFC nào? — sự nhầm lẫn khi tài liệu và thư viện tham khảo các tiêu chuẩn khác nhau
Hai RFC thường được trích dẫn trong tài liệu UUID và chúng không nói những điều giống nhau. RFC 4122, được xuất bản trong 2005, UUID đã xác định và năm phiên bản của chúng (v1 đến v5). RFC 9562, được xuất bản trong 2024, lỗi thời hoàn toàn RFC 4122, làm rõ những điểm mơ hồ mà những người thực hành đã giải quyết, thêm ba phiên bản mới (v6, v7, v8) và cập nhật hướng dẫn về cách triển khai tính ngẫu nhiên. Khi thư viện trích dẫn RFC 4122, điều đó không sai—thư viện đó có thể đã được phát hành trước khi RFC 9562 được xuất bản hoặc người bảo trì có thể không có tài liệu cập nhật. Việc kiểm tra RFC trích dẫn sẽ cho bạn biết thời điểm thư viện được cập nhật đáng kể lần cuối. Khi viết các thông số kỹ thuật mới hoặc đánh giá việc triển khai, RFC 9562 là tài liệu tham khảo quy chuẩn.
Lỗi thời, không thay thế định dạng — mọi thứ hợp lệ theo RFC 4122 vẫn hợp lệ; bố cục và các bit biến thể không thay đổi
RFC 9562 chính thức lỗi thời RFC 4122 làm tài liệu tham chiếu hiện tại trong khi vẫn giữ lại cách trình bày 128-bit quen thuộc, nhóm thập lục phân, vị trí phiên bản và bố cục biến thể chính. Các chuỗi UUID đã lưu trữ hiện tại không cần phải được phát hành lại chỉ vì có RFC mới hơn. Quá trình di chuyển thực tế nằm trong tài liệu, trình tạo và chính sách xác thực: trích dẫn tiêu chuẩn hiện tại, hiểu các phiên bản đã thêm và kiểm tra xem liệu mã cũ có dựa vào sự mơ hồ mà bản sửa đổi đã làm rõ hay không. Khả năng tương thích vẫn phải được kiểm tra ở các ranh giới hệ thống, đặc biệt khi thư viện tuần tự hóa các cấu trúc Microsoft GUID hoặc thực thi một tập hợp phiên bản hẹp hơn so với tiêu chuẩn mô tả.
Ba phiên bản mới - v6 (thời gian được sắp xếp lại), v7 (được sắp xếp theo thời gian Unix) và v8 (được xác định khi triển khai)
RFC 9562 thêm ba phiên bản mới vào tiêu chuẩn. Phiên bản 6 sắp xếp lại các bit dấu thời gian v1 để tạo ra các mã định danh có thể sắp xếp theo từ điển để có hiệu suất cơ sở dữ liệu tốt hơn. Phiên bản 7 sử dụng dấu thời gian mili giây Unix 48-bit, theo sau là các bit ngẫu nhiên, cung cấp khả năng tạo theo thứ tự thời gian mà không cần lo ngại về quyền riêng tư của phiên bản v1. Phiên bản 8 là một lối thoát cho bố cục do triển khai xác định. Không có phiên bản nào trong số này thay đổi cách hoạt động của v1-v5 hoặc ý nghĩa của chúng. v1 UUID từ 2005 và v7 UUID từ 2024 có thể cùng tồn tại trong cùng một cơ sở dữ liệu, mỗi cơ sở dữ liệu có các bit phiên bản xác định phương thức tạo của nó. Ba phiên bản mới giải quyết các mô hình phổ biến xuất hiện trong thực tế.
Max UUID tham gia Nil - giá trị toàn F được xác định cùng với giá trị hoàn toàn bằng 0
RFC 4122 đã ghi lại Nil UUID (tất cả các bit 0) dưới dạng giá trị tham chiếu đặc biệt trong các ví dụ và tài liệu. RFC 9562 bao gồm cùng định nghĩa Nil nhưng xác định chính thức Max UUID (tất cả các bit được đặt thành một) cho ranh giới phạm vi. Cả Nil và Max đều không phải là phiên bản 4 ngẫu nhiên UUID vì chúng không có phiên bản và bit biến thể chính xác. Max UUID rất hữu ích khi làm ranh giới phạm vi giới hạn trên trong các truy vấn cơ sở dữ liệu: WHERE uuid_column <= MAX_UUID khớp với tất cả các UUID có thể có. Nil hữu ích như một điểm kiểm tra cho việc chưa được gán trong các cột UUID có thể rỗng. RFC 9562 ghi lại cả hai tài liệu mà không bắt buộc sử dụng chúng trong dữ liệu ứng dụng.
Hướng dẫn rõ ràng — lời khuyên rõ ràng về cách sử dụng CSPRNG cho các trường ngẫu nhiên, trên các bộ đếm đơn điệu trong vòng một phần nghìn giây và ưu tiên các phiên bản theo thứ tự thời gian cho vị trí cơ sở dữ liệu
Hướng dẫn thực hành tốt nhất của RFC 9562 phân biệt khả năng chống va chạm với khả năng không đoán được. Các trường ngẫu nhiên phải sử dụng nguồn phù hợp với mô hình mối đe dọa của ứng dụng và độ mờ liên quan đến bảo mật yêu cầu CSPRNG. Các trình tạo dựa trên thời gian có vấn đề về tính đơn điệu riêng biệt khi một số mã định danh chia sẻ một dấu thời gian; tiêu chuẩn mô tả các bộ đếm và độ chính xác bổ sung của dấu thời gian như các phương pháp có thể, mỗi phương pháp đều có quy tắc trạng thái và chuyển đổi. Các phiên bản dựa trên tên vẫn là số nhận dạng xác định, không phải bằng chứng xác thực. Những thông tin làm rõ này rất quan trọng vì một trình phân tích cú pháp UUID có thể chấp nhận tất cả các bố cục mặc dù các yêu cầu tạo và thuộc tính tiết lộ thông tin của chúng khác nhau.
Nơi ý tưởng của ULID xuất hiện - định dạng cộng đồng ảnh hưởng như thế nào đến thiết kế của v7
RFC 9562 cho biết tác giả của nó đã phân tích một số lược đồ nhận dạng có thể sắp xếp hiện có, bao gồm ULID, Snowflake và KSUID, đồng thời phát triển bố cục mới. Điều đó hỗ trợ cho một kết luận khiêm tốn: nhu cầu vận hành đối với các mã định danh phân tán, được sắp xếp theo thời gian đã cung cấp thông tin cho bản sửa đổi. Điều đó không chứng minh được rằng một định dạng cộng đồng đã tặng bố cục trường chính xác cho phiên bản 7. Sự giống nhau về mặt thực tế là đủ cho công việc kiến trúc: những họ này đặt thông tin thời gian ở gần phía trước để thứ tự thông thường có thể duy trì trật tự sáng tạo rộng rãi, sau đó khác nhau về mã hóa, phối hợp và hành vi bên trong dấu tích. Hãy lựa chọn giữa chúng dựa trên khả năng tương thích của hệ sinh thái và những đảm bảo bằng văn bản thay vì tuyên bố về nguồn gốc trực tiếp.
Điều này không bao gồm những gì - sự khác biệt từng dòng một; bài đăng này đi theo những hậu quả thiết thực cho người thực hiện
Bài đăng toàn diện này trình bày các kết quả thực tế và việc triển khai RFC 9562 cho người triển khai và người dùng, không khác biệt từng dòng một so với RFC 4122. Thông số kỹ thuật đầy đủ có sẵn từ các cơ quan tiêu chuẩn và đáng đọc để triển khai xử lý UUID bằng ngôn ngữ hoặc nền tảng—văn bản cung cấp chi tiết đáng tin cậy ngoài những gì tổng quan có thể bao gồm. Bài đăng này không mô tả cơ chế cấp độ bit về cách v6 sắp xếp lại các byte v1 hoặc cách v7 mã hóa mili giây Unix. Cả tiêu chuẩn và hướng dẫn triển khai vẫn là tài liệu tham khảo có thẩm quyền chính cho mọi câu hỏi triển khai liên quan đến bố cục bit, mã hóa hoặc xác minh tuân thủ.
Bài học rút ra: cập nhật các trích dẫn và giá trị mặc định của bạn — trình tạo ToolAcre tuân theo hướng dẫn CSPRNG mà cả hai RFC đều chia sẻ
Đối với bất kỳ tác phẩm mới nào, hãy cập nhật tài liệu và thông số kỹ thuật để trích dẫn RFC 9562. Mọi UUID từ RFC 4122 vẫn hợp lệ theo RFC 9562—việc di chuyển hoàn toàn mang tính chất quản lý và hướng tới tương lai. Hướng dẫn làm rõ về tính ngẫu nhiên của mật mã củng cố rằng số nhận dạng phải đến từ các nguồn được bảo mật bằng mật mã trong các hệ thống sản xuất. ToolAcre tuân theo hướng dẫn về tính ngẫu nhiên của mật mã từ cả hai RFC, chỉ sử dụng Web Crypto API của trình duyệt. Khi bạn gặp UUID từ nhật ký, xuất cơ sở dữ liệu hoặc phản hồi API, kiểm tra ToolAcre được định dạng đúng sẽ báo cáo phiên bản và biến thể của nó so với RFC 9562. RFC 9562 là làm rõ và hiện đại hóa một tiêu chuẩn vốn đã ổn định.