- Gnutella est aujourd’hui presque un protocole de partage de fichiers oublié, mais il a représenté un cas réel où des millions d’utilisateurs, sans conscience particulière des technologies décentralisées, ont résolu leur problème de téléchargement de MP3
- En 2000–2001, un taux de pénétration d’Internet de 50 % aux États-Unis, la baisse du prix des lecteurs MP3, les limites du streaming et une culture de gestion directe des fichiers ont favorisé son adoption
- Grâce à une architecture sans serveur et à l’absence de point de défaillance unique, il est devenu difficile à faire disparaître après son annulation par AOL, et il a continué à fonctionner malgré des années de tentatives d’interruption
- Son architecture de base combine le transfert de fichiers via HTTP et un protocole de gossip sur TCP ; PING/PONG, QUERY/QUERYHIT et PUSH assurent la recherche, la réponse et le contournement des pare-feu
- S’il a disparu du grand public, ce n’est pas à cause d’un échec technique immédiat, mais parce que l’environnement utilisateur de l’époque a lui-même disparu ; le réseau, lui, continue de survivre à plus petite échelle
Pourquoi Gnutella a survécu si longtemps
- Gnutella est un protocole de partage de fichiers que beaucoup ont oublié, mais il constitue un exemple concret d’un système utilisé par des millions d’utilisateurs ordinaires, sans chercher à comprendre la décentralisation, simplement pour résoudre un vrai problème
- Les utilisateurs rejoignaient le réseau Gnutella non pas pour spéculer sur la valeur d’un token, mais pour télécharger des MP3 ; le réseau a connu une croissance explosive, puis une phase de stabilité d’environ dix ans, avant de conserver une longue traîne avec un usage réduit
- Gnutella était une technologie sous-jacente, masquée derrière des projets plus visibles comme LimeWire ; avec le modèle actuel des jardins clos des plateformes modernes, beaucoup d’internautes ne se souviennent même plus du système de fichiers lui-même
- Le projet Gnutella est né après la fuite publique d’une démo interne annulée par AOL, et sa conception décentralisée sans serveur l’a rendu difficile à reprendre en main une fois publié
- Malgré les tentatives d’interruption, Gnutella a continué à fonctionner pendant des années, et on peut encore retrouver une copie de
Gnutella.exe d’origine sur archive.org
- Il est difficile de parler d’un protocole raté, pour des raisons évidentes
- il est monté jusqu’à des millions d’utilisateurs actifs simultanés et a prospéré pendant environ dix ans comme usage grand public
- s’il a disparu du mainstream, ce n’est pas à cause d’un échec immédiat du protocole lui-même, mais parce que l’environnement utilisateur dans lequel Gnutella est né a disparu
- il continue encore aujourd’hui à fonctionner à une échelle réduite
Les conditions historiques qui ont rendu son adoption possible
- Vers 2000–2001, le taux de pénétration d’Internet auprès des consommateurs américains atteignait 50 %, et Internet passait d’un outil de passionnés à une infrastructure du quotidien
- Le partage de fichiers musicaux s’est généralisé parce que plusieurs conditions se sont combinées
- l’industrie musicale ne s’est pas adaptée aux préférences changeantes des consommateurs
- les lecteurs MP3 et les supports de stockage à semi-conducteurs devenaient moins chers et plus répandus
- sur les connexions bas débit par modem, le streaming musical n’était pas réaliste
- la gestion manuelle de l’espace disque, des répertoires, des sauvegardes et des fichiers téléchargés restait acceptable, même pour des utilisateurs informatiques ordinaires à l’époque
- Ces conditions ont créé l’âge d’or du partage de fichiers, qui s’est prolongé jusqu’au début des années 2010, et LimeWire reste le nom le plus représentatif de cette expérience
- Gnutella était difficile à tuer car il n’avait aucun point de défaillance unique, et son protocole de base était simple tout en restant facilement extensible grâce aux extensions optionnelles prévues dans la spécification
La nature fondamentale du protocole
- Pour la plupart des utilisateurs, Gnutella servait à transférer des fichiers, mais au fond il ressemblait davantage à un moteur de recherche P2P de blobs
- En théorie, il aurait aussi pu servir de DNS simplifié, de table globale de consultation de métadonnées clé/valeur ou de service d’appariement pour des ligues Unreal Tournament ; dans l’histoire réelle, il est surtout resté associé au téléchargement de fichiers correspondant à une recherche, notamment de MP3
- Le brouillon de spécification Gnutella 0.6 indique que les ressources partagées peuvent être n’importe quoi : mappages vers d’autres ressources, clés de chiffrement, fichiers de tout type, ou métadonnées de ressources adressables par clé
- Le flux d’utilisation typique ressemblait à ceci
- lancer un client Gnutella comme LimeWire, BearShare ou GTK-Gnutella
- le client se connecte à quelques pairs quelque part sur Internet
- l’utilisateur saisit une requête comme
LinkinPark.mp3.exe
- la requête se propage de pair en pair vers l’extérieur du réseau
- les résultats reviennent lentement depuis des ordinateurs arbitraires partout dans le monde
- l’utilisateur regarde les noms de fichiers pour estimer s’ils sont faux, compare les vitesses de connexion et espère l’absence de virus
- une fois le fichier choisi, le client télécharge directement des morceaux via HTTP depuis l’ordinateur de l’utilisateur distant
- On pouvait tomber sur un mauvais fichier, découvrir accidentellement de nouveaux contenus ou recevoir un malware ; ce comportement de cueillette exploratoire a disparu avec l’arrivée des moteurs de recommandation
- Les clients proposaient généralement quatre grandes fonctions
- gestionnaire de requêtes : gère des recherches qui se propagent lentement à travers des milliers de pairs
- gestionnaire de fichiers : définit les répertoires ou chemins à partager, ainsi que l’emplacement de stockage des téléchargements
- gestionnaire de transferts : gère la reprise, la segmentation et l’administration des transferts de fichiers bidirectionnels
- fonctions annexes : chat IRC, forums, surveillance des requêtes de recherche, exploration d’hôtes spécifiques, etc., sans que la plupart relèvent du protocole lui-même
- L’écosystème Gnutella comptait des leaders du marché comme LimeWire, mais plusieurs clients coexistaient, et des développeurs indépendants pouvaient aussi écrire un client from scratch
- Lors de l’implémentation de Gnutella Bun Client, de nombreux éléments non décrits par la spécification, des fonctions non documentées et des ajouts dispersés dans d’autres spécifications sont apparus, signe que le protocole a évolué de manière organique
La combinaison de HTTP et d’un protocole de gossip
- On pourrait penser qu’il suffit d’exposer un serveur HTTP sur un ordinateur personnel et d’en communiquer l’adresse IP pour permettre le partage de fichiers, mais aujourd’hui cela est difficile à cause du NAT, des pare-feu et des politiques des FAI résidentiels
- Il y a vingt ans, faire tourner un petit serveur HTTP sur une machine locale et l’exposer avec une IP publique était bien plus courant qu’aujourd’hui
- Gnutella exploitait cet environnement pour permettre à chaque participant d’héberger des fichiers à l’intérieur d’un maillage de pairs échangeant des messages de gossip
- L’étape de transfert quand on téléchargeait un fichier avec LimeWire ressemblait à un téléchargement de fichier avec
curl ou wget
- Mais un simple serveur HTTP ne suffit pas à créer un réseau de partage de fichiers P2P
- même à l’époque, les FAI fournissaient rarement des IP statiques fiables
- une adresse IP partagée aujourd’hui pouvait changer dès le lendemain
- une URL arbitraire comme
http://74.6.231.21:4000 avait peu de chances d’être indexée par un moteur de recherche, et elle devenait hors ligne dès qu’on refermait son ordinateur portable
- Les clients Gnutella exécutaient donc, en plus du serveur HTTP, un protocole de gossip sur TCP
- ils annonçaient leur présence à d’autres participants Gnutella dans un maillage de pairs qui exposaient leurs répertoires partagés via HTTP
- des informations comme les adresses de pairs, la bande passante, la latence ou les requêtes de recherche circulaient dans ce maillage
- des outils existaient aussi pour gérer les pare-feu, même si des extensions ultérieures ont été nécessaires pour affronter les problèmes de NAT modernes
- Les nœuds Gnutella avaient essentiellement trois rôles
- transférer des fichiers à qui les voulait via un serveur HTTP local
- découvrir et annoncer les fichiers disponibles via des messages de gossip
- dans certains cas, utiliser des techniques de contournement des pare-feu
- Comme Gnutella ne possédait ni point d’entrée central ni registre d’utilisateurs, une fois entré dans le maillage, on commençait à découvrir de nouveaux pairs, des requêtes de recherche entrantes et d’autres trafics réseau
Amorçage
- Le bootstrap consiste à trouver quelques pairs de départ pour entrer pour la première fois dans un maillage P2P sans invitation ni porte d’entrée officielle
- Le réseau Gnutella global est un mélange d’adresses IP de participants, et il suffit de se connecter à un seul pair fiable déjà relié au réseau principal pour commencer à voir le trafic d’un grand ensemble d’utilisateurs
- Avec le temps, davantage de pairs sont découverts via les messages PONG, et la liste des pairs est enregistrée sur disque pour permettre les reconnexions
- À cause des changements d’adresse IP et des périodes hors ligne, une partie de cette liste sauvegardée devient invalide au fil du temps, et le client l’essaie successivement jusqu’à trouver des pairs valides
- Lorsqu’on rejoint le réseau pour la première fois, ou après une longue absence, cette liste locale peut ne pas suffire ; un bootstrap redevient alors nécessaire
- La méthode la plus courante était Gnutella Web Cache (GWebCache)
- une fédération de serveurs web indépendants exploités par des bénévoles, généralement sous forme de petites applications CGI ou PHP
- ils enregistrent les adresses IP des participants Gnutella qui se signalent volontairement
- ils conservent aussi des IP ou domaines d’autres serveurs GWebCache pour prendre le relais si le serveur actuel disparaît
- ils fournissent une liste alternative de serveurs GWebCache
- ils fournissent une liste d’adresses IP de participants actuellement connus sur le réseau Gnutella
- Certains clients Gnutella contactaient automatiquement ces serveurs de cache ; d’autres obligeaient à copier leurs IP dans un fichier de configuration ou un menu de réglages
- Une fois connecté à des pairs de départ, le client collecte indirectement davantage de pairs via les messages du réseau, ce qui réduit la dépendance au cache
- GWebCache n’est pas un goulot d’étranglement central
- il existe plusieurs serveurs GWebCache sans lien entre eux
- il existe aussi plusieurs méthodes pour amorcer un client sans GWebCache
- même sans GWebCache, Gnutella pourrait survivre sous une forme moins pratique
- Exemple de requête de liste d’amorçage
- en ajoutant
?get=1&client=TEST&version=1 à la fin de l’URL, on peut récupérer une liste, mais des requêtes trop nombreuses entraînent rapidement une limitation de débit
http://cache.jayl.de/g2/gwc.php
http://gweb.4octets.co.uk/skulls.php
http://midian.jayl.de/g2/bazooka.php
http://p2p.findclan.net/skulls.php
http://skulls.gwc.dyslexicfish.net/skulls.php
H|106.107.193.27:23459|88579
H|182.233.59.26:23464|88581
U|http://bj.ddns.net/skulls/skulls.php|208999
U|http://scissors.gwc.dyslexicfish.net:3709/|341201
- Les entrées commençant par
H sont des pairs, celles commençant par U sont des serveurs de cache redondants utilisables plus tard
Les types de messages essentiels
- Gnutella est un protocole basé sur TCP, et lorsqu’on se connecte à un pair qui accepte des connexions entrantes, un handshake a lieu en premier
- Le client envoie
GNUTELLA CONNECT/0.4 ou GNUTELLA CONNECT/0.6, puis si l’autre côté répond positivement, la connexion est établie et les messages binaires Gnutella commencent à circuler
- Tous les messages binaires commencent par un en-tête de 23 octets
- l’en-tête contient l’identifiant du message, le type de payload, le TTL, le nombre de sauts et la longueur du payload
- le TTL représente la durée de vie restante du message, et le nombre de sauts la distance déjà parcourue
TTL + Hops représente la portée initialement visée par le message
- En pratique, il existe cinq messages vraiment centraux
- PING : découvre les pairs actifs, type de payload
0x00
- PONG : réponse à PING contenant adresse IP, port et statistiques de partage, type de payload
0x01
- QUERY : requête de recherche lancée par l’utilisateur ou par un pair proche, type de payload
0x80
- QUERYHIT : réponse positive à QUERY, contenant des enregistrements de résultats et les informations de connexion pour le téléchargement, type de payload
0x81
- PUSH : mécanisme de contournement pour les uploaders derrière un pare-feu, demandant au détenteur du fichier de se reconnecter vers le downloader, type de payload
0x40
- Il existe aussi un message
BYE, mais il n’est pas strictement obligatoire
- Les messages du protocole prennent en charge des champs de données d’extension, ce qui permet aux clients d’ajouter des fonctionnalités sans casser l’ensemble du réseau
- GTK-Gnutella prend en charge des fonctions absentes du petit protocole central, comme TLS, IPv6 ou UDP
Les extensions du protocole
- Il est probablement possible de créer un client Gnutella fonctionnel en n’implémentant que ces cinq types de messages, mais la spécification date d’il y a presque 30 ans et l’écosystème ne s’est jamais figé
- Gnutella a laissé suffisamment de place pour insérer de nouvelles idées dans d’anciens paquets
- GGEP (Gnutella Generic Extension Protocol) fournit un espace générique pour inclure des données d’extension à l’intérieur des messages ordinaires
- HUGE (Hash/URN Gnutella Extensions) permet aux clients d’identifier les fichiers par hash SHA au lieu de se limiter au nom du fichier
- La prise en charge de payloads d’extension XML est mentionnée, mais la spécification en parle au passé et elle n’a pas été observée dans le trafic réseau moderne
- Le design initial était petit, mais assez souple pour continuer à grandir
Comment fonctionnent la recherche et le transfert
- Les messages PING/PONG jouent le rôle de battement de cœur entre les nœuds
- un PING n’a pas de payload obligatoire au-delà de l’en-tête standard de 23 octets, mais il peut contenir des données d’extension GGEP optionnelles
- un PONG contient le port, l’adresse IPv4, le nombre de fichiers partagés et le nombre de kilo-octets partagés du servent qui répond
- les nœuds accumulent les informations IP/port jointes aux PONG pour devenir des membres mieux connectés du maillage, puis conservent ces données pour les sessions suivantes
- QUERY/QUERYHIT fonctionnent de manière similaire à PING/PONG, mais transportent du trafic de recherche plutôt que des annonces de pairs
- QUERY contient un champ de vitesse minimale, c’est-à-dire de bande passante de transfert, suivi d’une chaîne de recherche terminée par NUL
- exemple :
beethoven.mp3
- un message QUERY se propage en inondation depuis l’émetteur vers l’extérieur, et les messages QUERYHIT reviennent vers l’émetteur lorsqu’il y a des résultats
- QUERYHIT contient l’adresse IP, le port, la vitesse et l’ensemble des résultats du répondant
- chaque résultat comprend un index de fichier, sa taille, son nom et éventuellement des métadonnées ou extensions
- l’index de fichier sert ensuite à demander le fichier en HTTP
- En raison du routage par inondation de Gnutella, les résultats arrivaient lentement et pouvaient prendre plusieurs minutes avant d’être complets
- Les ingénieurs de LimeWire ont conçu un routage de requêtes dynamique pour rendre le tout plus scalable
- en s’appuyant sur des filtres de Bloom et une topologie réseau plus intelligente
- cette architecture avancée a permis de monter à l’échelle de plusieurs millions d’utilisateurs sans subir les problèmes du routage par inondation
- aujourd’hui encore, la plupart des clients grand public implémentent ce système
PUSH et les pare-feu
- Le message PUSH est un mécanisme de contournement qui aide certains serveurs HTTP à franchir les pare-feu, sans résoudre tous les cas
- Au lieu du modèle HTTP habituel, où le client se connecte au serveur, il s’agit ici plutôt de demander au serveur de se connecter au client
- Le message PUSH contient l’identifiant du servent et d’autres identifiants nécessaires pour permettre à l’uploader de retrouver le downloader
- Comme le client ne peut pas se connecter directement, il demande à l’autre extrémité de se reconnecter pour envoyer le fichier
- Pour plus de détails, voir la spécification Gnutella
- Les clients modernes utilisent des techniques supplémentaires et des extensions UDP pour gérer ces problèmes de manière plus naturelle
Ce qu’il en reste et ressources
- Gnutella a pu monter jusqu’à des millions d’utilisateurs simultanés, résister au blocage et rester en ligne pendant des décennies sans aide extérieure grâce à un bon design initial
- Le fait qu’il ne s’agisse pas d’un réseau effondré dès l’arrivée du trafic réel, mais d’un réseau issu de la culture Y2K qui refuse toujours de disparaître, montre la solidité de sa conception
- La conclusion la plus juste est sans doute que Gnutella s’est estompé parce qu’il a survécu plus longtemps que le monde qui l’avait créé
- Le réseau lui-même a survécu plus longtemps que les sites qui hébergeaient sa documentation
-
Liens de référence
- GTK-Gnutella GitHub - un client à utiliser si l’on veut réellement employer Gnutella dans les années 2020 ; son mainteneur principal a participé à la rédaction de la spécification Gnutella 0.6 et reste toujours actif
- Gnutella Bun Client GitHub - une implémentation amateur d’un client Gnutella en TypeScript/Bun, qui fonctionne réellement et reste globalement compatible avec GTK-Gnutella, sans être parfaite
- Gnutella Terminology Glossary - un glossaire couvrant les termes Gnutella et des notions connexes comme QRP, GGEP ou GIV
- Gnutella Forums - un ancien forum consacré aux clients Gnutella, au dépannage et aux discussions réseau, peu actif à l’horizon 2026
- Cap’n Bry’s Gnutella Site - une ancienne page de fan sur Gnutella
- Annotated Gnutella Protocol Specification v0.4 - la spécification originale et annotée du protocole Gnutella 0.4
- Gnutella Protocol 0.6 Draft - le brouillon ultérieur de la spécification du protocole Gnutella 0.6
- Query Routing Protocol Spec - la spécification de QRP, le système de routage des requêtes de Gnutella destiné à réduire l’inondation inefficace ; les diagrammes ont disparu
1 commentaires
Avis sur Lobste.rs
Je me souviens surtout de Gnutella comme d’un moyen de télécharger facilement beaucoup de fichiers correspondant à une recherche, généralement des MP3, mais il y avait aussi « autre chose »
C’est sympa pour la nostalgie, même s’il est dommage que le web d’aujourd’hui soit devenu un monstre
Au milieu des années 2000, le réseau du dortoir universitaire était un réseau plat, et iTunes était extrêmement populaire, au point de partager de la musique avec n’importe qui sur le réseau
En une semaine, j’avais rempli mon nouveau portable HP 64 bits acheté chez Circuit City avec du Evanescence et du Green Day, et j’avais l’impression que le Columbia House CD Club ne servait plus à rien
Quelques années après mon diplôme, quelqu’un en a parlé devant la mauvaise personne, l’IT en a officiellement pris connaissance, et ils ont fini par devoir le fermer
Plus tard, j’ai compris que ça ne voulait pas dire un « réseau plat » de nœuds de partage de fichiers construit au-dessus du réseau universitaire, mais que le réseau lui-même était plat
Cela dit, la fac était une période amusante pour faire ce genre de choses
Soulseek est toujours bien vivant et fonctionne encore très bien
Le point le plus drôle avec Gnutella, c’est que ça n’a absolument aucun rapport avec le projet GNU, ils ont juste mis GNU dans le nom parce que ça faisait cool
Je me demande souvent dans quelle mesure les techniques clés de Gnutella pourraient être réutilisées pour la découverte de contenu sur un small-web plus moderne ou quelque chose de proche de Gemini
Dire que « ça a échoué » est incomplet. En général, on ne réussit ni n’échoue dans l’absolu ; on ne peut réussir ou échouer qu’au regard d’un objectif donné
Il y a essentiellement deux raisons pour lesquelles les utilisateurs de Gnutella n’existent plus, et les deux peuvent être vues comme des échecs
Premièrement, Gnutella et plusieurs logiciels n’assuraient pas une protection de la vie privée suffisante pour les utilisateurs, ce qui les exposait à des risques réels ou perçus
Deuxièmement, c’était un très bon système de distribution de fichiers multimédias, mais il n’offrait pas le bon équilibre qualité/prix pour satisfaire la plupart des utilisateurs. Il donnait l’accès illimité que les utilisateurs voulaient, mais sans garantir qu’il s’agissait du vrai contenu, alors que Spotify offrait les deux
Dans ce sens, les utilisateurs de Gnutella existent toujours, mais ils utilisent autre chose aujourd’hui
Je pensais à créer une archive de fichiers
*.gmi, interrogeable via une extension Gnutella, ainsi qu’un système de pointeurs permettant aux gens de signer et publier des documents gemtextCe n’est pas une idée totalement nouvelle, mais la combinaison Gemtext + distribution via Gnutella me semble inédite : https://github.com/RickCarlino/gnutella-bun-client/…
Ce texte est le résultat d’un brainstorming mené avec GPT-5.4 et enterré pour plus tard, donc il n’était pas encore destiné à être partagé ; à lire avec prudence
J’aimerais bien entendre des idées sur l’espace Gemini + Gnutella ; on me trouve facilement sur Linkedin, Reddit, le Fediverse, etc., et mes coordonnées figurent aussi sur mon blog
OnionShare est aussi assez amusant : https://onionshare.org/
Ça pourrait faire partie du DaRkWeB
D’après la documentation, ça ressemble davantage à un outil de transfert de fichiers en connexion directe
Il me semble qu’il manque une raison pour laquelle Gnutella a survécu si longtemps dans les conditions de l’époque : il y avait très peu d’incitation concrète à faire du spam de recherche P2P
Plus tard, le spam de recherche P2P est bel et bien apparu
J’ai l’impression qu’il y a aussi très peu de spam sur IRC de nos jours pour une raison comparable
Ce qui est intéressant, c’est qu’une grande partie du protocole fait confiance au client
Les GUID sont censés être aléatoires, mais comme l’utilisateur les contrôle, tout le monde pourrait aussi bien régler son GUID sur
0000. Si on recréait Gnutella aujourd’hui, on y mettrait probablement un système complexe d’échange de clés et une identité fondée sur des clés ED25519Le nombre de fichiers annoncés, la bande passante, etc. reposent aussi essentiellement sur l’hypothèse que l’utilisateur dit la vérité. Un protocole plus complexe aurait peut-être essayé de vérifier réellement ce genre d’affirmations
Avec trop de signatures de clés ou de gestion de réputation, l’implémentation serait peut-être devenue beaucoup trop complexe, et il est possible que sa simplicité ait justement été l’une des raisons de son succès. Un client Gnutella, ça se code vraiment
Je pense que beaucoup de projets P2P modernes passent à côté de ça. J’aime beaucoup Secure Scuttlebutt, mais j’ai l’impression qu’en essayant de construire quelque chose de presque parfait, capable de prendre en compte toutes sortes d’échecs et de détournements, le résultat est devenu un écosystème où le seul client fonctionnel est celui des auteurs de la spécification
Le même exemple s’applique à
gemini://. Ce n’est pas du P2P mais un protocole fédéré ; malgré les problèmes et les failles de la spécification, des gens ont quand même réellement créé des clients, et l’écosystème compte une diversité d’implémentations assez appréciable malgré ces défautsGnutella doit aussi beaucoup, à ce moment-là, au rôle joué par Gene Kan et Spencer Kimball, tous deux membres du Berkeley XCF
Spencer a ensuite réalisé beaucoup d’excellent travail d’ingénierie chez Google, et il est aujourd’hui CEO de la société de bases de données Cockroach Labs
Gene a connu un succès précoce en vendant sa société de recherche à Sun, mais il est malheureusement décédé de façon tragique en 2002, beaucoup trop jeune