Salut et bienvenue dans ce nouvel épisode de Code Garage, je m'appelle Nicolas Brondin-Bernard
et aujourd'hui on va parler d'un sujet qui est l'UEID.
OK ? UID, ça signifie universally unique identifier et ça désigne en fait un standard
d'identifiant généré aléatoirement et globalement unique.
Donc si jamais vous voyez pas exactement ce que ça donne, vous en avez sûrement
déjà croisé dans du code, c'est un identifiant qui va ressembler par exemple la 158, c'est
999, 8, tiré, 1, 8, DA, tiré, 4, BEF, tiré, etc.
Donc la version la plus utilisée de l'UEID, c'est la version 4 et c'est une version
dans laquelle chaque identifiant est généré aléatoirement sur 30 caractères et dont 2
caractères sont réservés pour stocker la version de la norme utilisée.
Alors pourquoi est-ce que cet identifiant il est de plus en plus utilisé et particulièrement
intéressant ? En fait on va le découvrir et ça va être notamment grâce au concept
d'unicité globale à contrario avec l'unicité locale.
Nous on est habitué à ce que nos identifiants y soient uniques de manière locale.
En SQL par exemple, on va vérifier que chaque clé primaire est unique dans la table
grâce à un index.
L'identifiant il n'est pas aléatoire, il est incrementé depuis le dernier identifiant
généré et unique localement dans chaque table.
C'est à dire que par exemple j'ai une table utilisateur, j'ai un objet avec l'ID
1, 2, 3, 4 et puis j'ai une autre table avec des articles de blogs et leurs identifiants
vont être 1, 2, 3, 4.
Ils ne sont pas uniques globalement dans toute la base de données, ils sont uniques
localement dans chacune des tables.
Et bien à l'inverse, un UID c'est universelment unique et donc sans autorité de contrôle.
L'autorité de contrôle par exemple dans les bases de données dans les tables dont
je vous ai parlé de tout à l'heure, c'est des index.
Et bien là, l'UID, son unicité elle est assurée par le nombre gigantesque de possibilités
lors de la génération aléatoire.
Alors je sais, c'est par et un peu bizarre et on se demande comment est-ce que c'est possible.
Simplement, un UID, il est composé de 128 bits, ça veut dire 32 caractères hexadecimo,
on utilise 4 bits par caractère et donc le nombre de possibilités différentes pour
générer des UID uniques, il est de 5,31 fois 10 puissance 36, soit en gros plus grand
que le nombre estimé de bactéries présentes sur Terre, qui est de 10 puissance 30.
Donc là je pense que vous l'aurez compris, comme il n'y a pas de contrôle, il y a quand
même des risques de collision.
Une collision ça veut dire une génération de deux identifiants similaires.
Ça peut pas être nul à partir du moment où on a un nombre de possibilités maximum.
Mais avec un tel nombre de possibilités, comme je l'ai dit juste avant, le risque de collision
il existe mais il est techniquement négligeable.
J'ai regardé un petit peu sur Wikipedia et pour atteindre un risque de collision de
50%, il faudrait générer un milliard d'UID par seconde pendant environ 85 ans.
Ça veut dire qu'un fichier qui contiendrait autant d'UID, ça pèserait 45 hexa octets,
soit 45 milliards de gigas.
Donc ça c'est une chose mais il faut aussi savoir que cette génération aléatoire elle
est soumise à un concept qu'on appelle l'anthropie.
L'anthropie c'est la possibilité pour un système informatique de générer des nombres
aléatoires très différents les uns des autres.
Si jamais l'anthropie est trop faible, donc en fait le nombre de collisions possibles,
il risque d'augmenter vraiment énormément.
Ça varie en gros cette entreprenie en fonction des algorithmes qu'on appelle de PRNG.
PRNG c'est pseudo random number generation.
Donc c'est la génération de nombres pseudo aléatoires.
Si jamais le concept vous échappe un petit peu, je vous mets dans les notes du podcast
fin de cet épisode-là un article sur l'aléatoire absolu en informatique.
Et d'ailleurs vous pouvez retrouver sinon en version audio dans un précédent épisode
le concept d'aléatoire absolu en informatique.
Donc par exemple les aléatoires de PRNG dans les négoviateurs web,
ils ont une entrepix souvent trop faible pour générer des UID fiable parce qu'ils n'ont
pas toujours accès aux algorithmes du système d'exploitation.
Ceux-là, les algorithmes du système d'exploitation, eux, ils sont suffisamment fiable pour des
opérations de cryptographie et donc la génération du UID.
Alors d'où il vient un petit peu ce concept du UID ?
L'origine, ça a été inventé par la société Apollo Computer pour identifier de manière
unique des appels RPC.
RPC, ça veut dire Remote Procedure Call, c'est un protocole pour exécuter des méthodes
sur une machine distante.
Et aujourd'hui, il existe cinq versions différentes de la norme UID, mais c'est la version 4
qui est actuellement la plus utilisée pour refaire un petit d'historique.
La version 1, elle était prévue pour transiter sur le réseau.
Donc au début, elle contenait la chaîne de l'adresse Mac de la machine source plus
un timestamp, ce qui le rendait unique en tout cas sur le réseau parce qu'on ne devait
pas avoir deux machines qui avaient la même adresse Mac.
Donc ça, ça permettait de contraindre, on va dire, l'unicité de l'identifiant.
Mais ça avait comme un convainc de dévoiler des données privées de la machine puisque
l'adresse Mac de la machine, normalement, c'est quelque chose qui est quand même privé.
Ensuite, on a la version 2 qui est une simple variante de la version 1 et la version 3 qui
est l'équivalent d'un HMD5 et la version 5 qui est l'équivalent d'un H, mais en
chat.
En fait, c'est avec la version 4 qui est arrivée l'aléatoire complet de l'identifiant et
donc l'utilisation comme un identifiant global unique en dehors du contexte du réseau.
Et quand on parle juste pour terminer de ce que c'est un identifiant global unique,
ça veut dire que théoriquement, si vous aviez deux bases de données, deux bases de données
avec, je ne sais pas, disons, 20 000 entrées dans votre base de données, dans plusieurs
tables, eh ben, vous pourriez fusionner ces deux bases de données si vous utilisez que
des UID puisque normalement, il n'y aurait aucune collision entre ces deux bases de données
puisque chaque identifiant est globalement unique même en dehors de toute index ou quoi
que ce soit.
Donc, normalement, vous savez à peu près tout ce qu'il y a à connaître sur l'UID.
Maintenant, il n'y a plus qu'à, si jamais le concept vous intéresse, et ben voir comment
vous pouvez l'implémenter dans vos bases de données et dans vos projets de tous les
jours.
En tout cas, c'est en général très, très simple.
Quand vous êtes sur, voilà, pas sur un environnement smartphone ou web, quand vous
êtes directement sur un serveur, eh ben, vous avez simplement à utiliser une bibliothèque
qui va générer de manière cryptographique un UID et vous allez pouvoir tout simplement
le stocker dans les id de vos objets et vous en servir de manière très, très simple.
Voilà, j'espère que cet épisode vous aura plu, qu'il vous aura appris quelque chose,
et moi, je vous dis à très vite pour un nouvel épisode du podcast.
Ciao !