IPFS - HTTP décentralisé

Publier le 2 février 2021 08:00

Surfons sur l'actu !

Bonjour Mesdames, Mesdemoiselles et Messieurs, et bienvenue sur mon premier article réseau \o/

Aujourd'hui je vous parle d'IPFS, et je remercie le navigateur Brave pour m'avoir fait découvrir ce protocole malgré lui ! Dans un article de blog récent, Brave indique qu'il supporte ce protocole.

Mais qu'est-ce qu'IPFS ? C'est un protocole réseau qui s'apparente à "une alternative" de HTTP.

Enfin, c'est ce que j'ai lu dans les sites d'actualités, à croire que HTTP va disparaitre et qu'IPFS est son remplaçant tout désigné. Non, ce n'est pas une bonne définition. Je n'aime pas trop le terme d'alternative. Utilisons plutôt le groupe de mots "changement d'architecture", ça sera déjà moins mensonger.

Les architectures en jeux

Lorsque vous faites une recherche sur le web, un serveur répond à votre requête : c'est le principe du client-serveur où toute l'architecture est centralisée sur un seul et unique serveur.

L'un des soucis majeurs avec cette architecture est la localisation de ce serveur. Dans des petites structures, il n'y a qu'un seul serveur qui répond aux requêtes client. Si ce dernier est amené à tomber, le site web et les différents services ne sont plus accessibles et les clients sont mécontents (et en fonction de la boite vous arrivez en TT sur Twitter).

Pour remédier à ce genre d'incident, on peut utiliser des CDNs et mettre en place d'autres serveurs de secours avec plusieurs actifs et plusieurs passifs.

Les serveurs CDNs mettront en cache le contenu du site web dans un serveur plus proche de l'utilisateur afin de limiter la latence. Un routage basé sur DNS est également mis en place pour trouver le serveur le plus proche.

On se retrouve ainsi avec plusieurs serveurs centraux, plusieurs serveurs CDNs, et plusieurs serveurs de secours qui fournissent la même ressource.

Vous voyez l'idée ? Au lieu d'avoir une architecture centralisée sur un seul serveur, on a maintenant une architecture décentralisée avec différents serveurs.

Mais alors, qu'est-ce qu'apporte IPFS ?

Rien ! Aller hop fin de l'article !

Plus sérieusement, pour ceux qui ne l'ont pas encore compris, IPFS suit l'architecture décentralisée tandis que HTTP suit une architecture centralisée par défaut.

Si on souhaite avoir une architecture décentralisée en HTTP, on met en place des serveurs de secours, des CDNs et ont déploie tout un mécanisme de réplications / sauvegarde / restauration qui doivent être superviser à longueur de journée.

Avec IPFS, c'est le principe de peer-to-peer qui prime. Lorsque l'on déploie un serveur IPFS, le serveur se connecte à d'autres serveurs IPFS pour partager les ressources.

Les serveurs qui sont dans le réseau IPFS sont appelés des noeuds et les données échangées sont copiées dans plusieurs noeuds : comme s'ils étaient copiés dans plusieurs CDNs en HTTP.

Donc... c'est juste un réseau de CDNs ?

C'est une définition valable. Cependant, il ne faut pas croire que les données entre le client et les serveurs se passent de la même manière que HTTP.

Pour rappel : quand vous demandez une ressource en HTTP, le DNS connait le serveur (ou suit un routage DNS pour le trouver). Avec IPFS, les ressources sont demandées via leur hachage cryptographique et c'est l'un des noeuds du réseau IPFS qui vous répondra.

Contrairement au CDN qui stocke l'entièreté de la ressource (image, vidéo, texte...) en cache, les noeuds stockent une partie de la ressource (un segment du fichier) identifiée par une clé unique (le hash).

Notre fichier étant segmenté dans différents serveurs, il faut récupérer ses différentes parties pour reconstruire notre fichier, ce qui peut entrainer un délai. IPFS étant encore "Jeune", il n'y a pas beaucoup de serveurs qui fournissent ce protocole, mais on peut supposer qu'à l'avenir ses opérations de répartitions de segments et de reconstruction soient moins couteuses en termes de performance.

Autres soucis à ne pas négliger : la modification et la suppression d'un fichier sous IPFS ne sont pas possibles. Lorsque l'on modifie un fichier et que l'on publie sa modification, son hash est mis à jour (mais l'ancien hash de la version précédente est toujours disponible). Pour la suppression, rien ne nous garantit que tous les segments du fichier sont supprimés dans les différents noeuds du réseau IPFS.

D'accord... mais c'est à quel usage finalement ?

Quelques exemples d'usages sont présents dans cette documentation. Voici une petite liste présente dans la documentation :

  • Réaliser un système d'archive.

  • Stocker ses assets (images, JavaScript, css...) et fichiers divers.

  • Paralléliser les analyses Big Data.

Voilà ce qui conclut le petit tour avec IPFS, pour ceux qui sont encore debout, je vous ai laissé un dessert dans la dernière partie pour mieux appréhender la bête.

Les rideaux se ferment.

Source pour approfondir

Dans les coulisses.

Pour les personnes curieuses qui souhaitent obtenir plus d'informations (et pourquoi pas s'y essayer), je vous mets ci-dessous des liens qui peuvent vous aider à mieux comprendre les concepts :