Nains sans géants
|Chapitre 2. Décentraliser les services internet
Texte intégral
1Internet est une ressource partagée – un réseau coopératif construit sur des millions d’hôtes répandus dans le monde. À ce jour, un nombre toujours croissant d’applications utilise le réseau, envoie des paquets, et consomme de la bande passante. Dès 1994, le public commence à rejoindre en masse la communauté d’ordinateurs qui composent l’Internet, posant problème pour la durabilité de la plus basique des ressources : la bande passante. De plus, la confiance croissante dont les utilisateurs investissent le « réseau des réseaux », pour des usages et des applications à la fois fondamentaux et critiques, entraîne de nouveaux critères de sécurité, conduisant à la mise en place de pare-feu qui divisent fortement l’Internet en régions s’auto-alimentant et se suffisant à elles-mêmes.
2Le système Internet passe à l’échelle de façon bien plus importante qu’il n’était prévu dans les intentions originelles de ses développeurs, et les paquets d’information se frayent un chemin entre des fournisseurs d’accès au réseau de plus en plus encombrés. La modélisation du trafic par des lois statistiques classiques, qui suffisaient jusqu’aux années 1990, présente désormais de nombreuses difficultés additionnelles dues au « caractère décentralisé, stochastique […], non linéaire […], complexe » [Baccelli, 2005 : 2] d’un réseau très étendu et impliquant des interactions entre et avec de nombreux intermédiaires [Musiani & Schafer, 2011]. Les raisons de cette complexification sont à chercher dans l’utilisation de nouveaux protocoles de routage et de contrôle des transmissions, qui ont donné lieu à l’extension potentiellement indéfinie et indéfinissable du réseau [Baccelli, 2005 : 3], tout en apportant des variations – et des tensions – aux « protocoles coopératifs » TCP et IP [Minar & Hedlund, 2005 : 13].
3C’est ainsi qu’au cours de ces dernières années, un grand nombre de modèles sont proposés afin de prendre en compte les nouvelles complexités du réseau, tels que la multi-fractalité du trafic global ou l’équité du partage d’un même canal de communication entre plusieurs flux de données [Baccelli, 2005] : en particulier, autour de l’année 2000, certains développeurs commencent – dans l’effort de répondre à certains points d’interrogation posés par la massification des usages – à revenir sur des chemins déjà parcourus. Aux côtés d’un modèle de réseau ayant survécu à la croissance importante des cinq années précédentes, apparaissent des modèles qui tiennent d’un passé un peu moins récent.
- 26 Le P2P est loin d’être né avec Napster, mais c’est avec ce logiciel que ce modèle de réseau inform (...)
4En particulier, au sein d’un large mouvement appelé « peer-to-peer », initié par l’application de partage de fichiers musicaux Napster26, les millions d’usagers connectés à l’Internet commencent à utiliser leurs ordinateurs personnels et domestiques, toujours plus puissants, pour faire autre chose que naviguer sur le Web et échanger des courriels. Les machines, dans les maisons et dans les bureaux, (re)commencent à se connecter les unes aux autres directement, formant des groupes et des clusters, pour prendre la forme de moteurs de recherche, machines de calcul et systèmes de fichiers créés par des usagers – et composés par eux.
5Nombre de questions et réflexions qui tiennent à la fois du juridique, de l’économique, du social et du technique sont soulevées par ces reconfigurations. Plusieurs fournisseurs d’accès au réseau, ayant programmé leurs systèmes sur la base de l’idée que les usagers passaient le plus clair de leur temps en ligne à télécharger données et informations depuis des serveurs, soulèvent des objections de nature économique aux modèles P2P. Certains commencent par empêcher l’accès aux services P2P sous prétexte que ceux-ci constituent une violation des conditions d’usage et qu’ils consomment, voire gaspillent, trop de bande passante, tandis que derrière ces revendications se cachent souvent des débats sur la nature licite ou illicite de certains types d’échanges et de contenus partagés. Par ailleurs, de nombreuses entreprises du secteur IT tentent d’identifier les problèmes spécifiques qui se posent quand l’architecture de l’Internet est durement mise à l’épreuve par les scénarios de « concentration » actuels – et, en cherchant les meilleures façons de contourner ces problèmes et les solutions les plus efficaces, ils se retournent, de façon peut-être surprenante, vers l’Internet d’il y a quinze ou vingt ans.
P2P, LES QUALITÉS PERSISTANTES D’UNE ANCIENNE TECHNOLOGIE
6Le premier Internet a été créé, foncièrement, en tant que système P2P. Au fil du temps, il est de plus en plus construit selon un modèle client-serveur, avec des millions de clients/consommateurs communiquant avec un ensemble relativement réduit de serveurs. Nombre d’applications construites sur le modèle P2P, que l’on a vu naître au cours de la dernière décennie, utilisent à nouveau l’Internet de la façon dont il avait été conçu : comme un moyen de communication entre machines qui partagent des ressources l’une avec l’autre, comme des égaux. Au fur et à mesure que d’autres évolutions de l’Internet se sont mises en place – l’augmentation de la quantité et de la qualité de bande passante à disposition de chaque utilisateur ; la puissance croissante des terminaux domestiques ; la diversification des « activités numériques » au-delà de la navigation du Web et de l’envoi de messages – les conditions se sont formées pour un autre changement, voire un revirement, basé sur « la connexion réciproque et directe de machines domestiques, formant des groupes et collaborant pour devenir des moteurs de recherche, des outils de calcul et des systèmes de fichiers crées par les utilisateurs » [Minar & Hedlund, 2001 : 3].
7Ce modèle de réseau ne doit pas sa « nouveauté » à son concept : l’innovation réside dans son passage à l’échelle et ses implémentations particulières. Certains concepteurs d’applications cherchent aujourd’hui à apprendre des systèmes Internet distribués ou avec d’importantes composantes distribuées, comme Usenet ou le Domain Name System ; dans d’autres cas, ils cherchent à inverser, modifier ou reconfigurer les changements auxquels l’Internet a fait face dans sa phase de commercialisation et d’ouverture au grand public, afin d’adapter ou réadapter le réseau à de nouvelles applications P2P. Comme souligne à ce propos un développeur : « En tout cas, les leçons qu’on apprend de ces systèmes sont instructives, et pourraient nous aider – nous, les concepteurs d’applications – à empêcher la mort de l’Internet. »
INTERNET DÉCENTRALISÉ, ENTRE COOPÉRATIONS ET TENSIONS
8L’Internet tel qu’il a été conçu à l’origine – dans la deuxième partie des années 1960 – était un système P2P. Le but de l’ARPANET originel était de partager des ressources de calcul sur le territoire américain. Le défi principal auquel cet effort a dû faire face a été l’intégration de différents types de réseaux existants, mais aussi des futures technologies, dans un réseau commun, qui permettrait à chaque hôte d’être un participant égal dans le jeu. Les quatre premiers hôtes sur ARPANET – University of California at Los Angeles, Stanford Research Institute, University of California at Santa Barbara et University of Utah – étaient déjà des sites de calcul indépendants, avec un statut égal, et ARPANET les connectait l’un à l’autre en tant que tels.
9L’Internet des débuts était aussi beaucoup plus ouvert et libre que le réseau d’aujourd’hui. Les pare-feu étaient inconnus jusqu’aux années 1980, et généralement, toute machine connectée à l’Internet pouvait envoyer des paquets à une autre de son choix, alors que le réseau d’aujourd’hui est beaucoup plus cloisonné. La toile était l’« aire de jeux » de chercheurs guidés par le principe de coopération, et qui n’avaient que très peu de besoin de protection. Les protocoles et les systèmes étaient suffisamment obscurs – et suffisamment spécialisés – pour rendre les failles de sécurité rares et, pour la plupart, négligeables.
- 27 L’étiquette « killer application » désigne un programme informatique si attrayant qu’il justifie à (...)
10Les premières « killer applications »27 de l’Internet, FTP et Telnet (proposés par l’IETF en mai 1983), étaient quant à elles des applications client/serveur : pour échanger des communications et pour échanger des fichiers, respectivement, les clients Telnet et les clients FTP devaient se connecter à des serveurs. Mais si l’application en elle-même était client/serveur, les modèles d’usage dans leur ensemble étaient symétriques : chaque hôte sur le Net pouvait se connecter au moyen de FTP ou Telnet à tout autre hôte, et dans ces débuts des mini-ordinateurs et des unités centrales, les serveurs se comportaient souvent dans l’économie du réseau en tant que clients.
11Cette symétrie fondamentale était la caractéristique qui rendait l’Internet si radicalement différent des systèmes d’interconnexion précédents, tels que la téléphonie – et à son tour, elle a donné lieu à la naissance d’une variété de systèmes plus complexes, comme Usenet et le DNS, qui se servaient de modèles de communication P2P de façon intéressante pour les développeurs d’aujourd’hui.
Usenet, le modèle décentralisé originel
12Le système de forums Usenet, qui a fait sa première apparition en 1979, implémente un modèle de contrôle décentralisé qui, à certains égards, est l’aïeul d’applications P2P beaucoup plus récentes. Le modèle de gouvernance « anarchiste » et l’organisation sociale de Usenet ont été étudiés en détail au fil des années [Hauben & Hauben, 1996 ; Pfaffenberger, 1996 ; Latzko-Toth, 2010 ; Paloque-Bergès, 2012]. Non moins intéressantes, en termes d’influence du dispositif sur les innovations plus récentes, sont l’architecture et les procédures de fonctionnement de ce système : il s’agit en effet d’un système qui, sans contrôle central, copie des fichiers entre ordinateurs. Chaque site participant au réseau sauvegarde ses copies des messages postés dans les forums, et se synchronise périodiquement avec ses pairs.
13Le système Usenet était à l’origine basé sur une installation appelée Unix-to-Unix copy protocol – UUCP, un mécanisme par lequel une machine Unix pouvait automatiquement en « appeler » une autre, échanger des fichiers avec elle, et puis se déconnecter. Ce mécanisme permettait à Unix d’échanger des fichiers, des emails, des mises à jour de système, ou d’autres types de messages. Usenet utilisait ce protocole pour échanger des messages rentrant dans plusieurs sujets, de façon à ce que les étudiants de University of North Carolina et Duke University puissent chacun « poster » des messages sur un sujet donné et lire des messages écrits par d’autres sur le même sujet. Usenet s’est diffusé à partir de ces deux hôtes originaux, jusqu’à connecter des centaines de milliers de sites. Au fur et à mesure que le réseau grandissait, croissaient aussi le nombre et la structuration des sujets sur lesquels un message pouvait être posté. Aujourd’hui, Usenet utilise un protocole de type TCP/IP, connu en tant que Network News Transfer Protocol (NNTP), introduit en 1985 en tant que solution plus flexible et adaptée à des transferts Internet informels que l’UUCP. NNTP permet à deux machines sur le réseau Usenet de découvrir de nouveaux groupes de discussion, ou groupes de nouvelles (newsgroups) de façon efficace, et d’échanger de nouveaux messages à l’intérieur de chacun d’entre eux ; depuis le boom de l’Internet des années 90, la presque totalité de la distribution Usenet est sur protocole NNTP.
14Le modèle de base d’Usenet donne une grande capacité de contrôle local, et une administration du réseau relativement simple [Latzko-Toth, 2010]. Un nouvel usager Usenet se connecte au reste du monde en installant une connexion d’échange de nouvelles avec au moins un autre serveur de nouvelles sur le réseau Usenet. Usenet est donc organisé autour du principe des newsgroups, qui rassemblent chacun des articles (contributions) sur un sujet précis. Les sujets des newsgroups sont organisés selon une hiérarchie ; une fois connectés à un serveur fournissant un service Usenet, les utilisateurs peuvent choisir les groupes mis à disposition par ce serveur auxquels ils souhaitent s’« abonner ». Pour chaque groupe auquel il est abonné, l’utilisateur peut alors voir tous les nouveaux articles mis à disposition sur ce groupe (le serveur envoie une notice à l’utilisateur pour lui signaler un nouvel article, qu’il lui transmet) et tous les articles reçus par le serveur depuis un certain temps. Lorsqu’un utilisateur, à son tour, envoie un article sur un serveur Usenet, celui-ci le diffuse à tous les autres serveurs avec lesquels il a conclu des accords d’échange d’articles (littéralement, il l’« alimente »), et ainsi de suite. Chaque serveur conserve une copie de cet article, et peut ensuite le mettre à disposition des utilisateurs ayant accès à ce serveur.
15Aujourd’hui, le volume du trafic Usenet est énorme, et assurer la charge de l’ensemble des newsgroups ou des messages n’est certes pas à la portée de tout serveur. Les fournisseurs de service Usenet peuvent donc contrôler la taille de l’installation en spécifiant quels newsgroups vont être pris en charge par un serveur en particulier. De surcroît, l’administrateur peut fixer une durée de validité des articles par groupe, ou par hiérarchie, de façon à ce que les articles dans un newsgroup soient maintenus durant une période donnée mais pas plus. Ces contrôles permettent à chaque fournisseur de service Usenet de rejoindre le réseau, et d’y définir leur participation, en accord avec leurs propres critères. Plusieurs fournisseurs décident, par exemple, de ne pas accepter des newsgroups qui contiennent et transmettent des données de nature sexuellement explicite, ou illégales sous certains aspects. Il s’agit là d’une différence marquée par rapport à Freenet, qui, par choix de design, ne permet pas à un usager de voir quels types de données sa machine est en train de recevoir et de transmettre.
16Usenet a influencé certains des exemples les plus réussis de structures de contrôle décentralisées sur le Net. Il n’y a pas d’autorité centrale qui gouverne le système de transmission des nouvelles, mais l’ajout de nouveaux newsgroups à la hiérarchie des sujets est contrôlé par un processus rigoureux, qui utilise le groupe Usenet news. admin pour proposer et discuter la création de nouveaux groupes [voir Pfaffenberger, 1996 et Auray, 2007]. Une fois qu’un nouveau groupe est proposé, et discuté pendant une période de temps prédéterminée, toute personne dotée d’une adresse email peut soumettre un avis et demander un vote pour ou contre sa proposition. S’il obtient gain de cause, un nouveau message de groupe est envoyé et se propage à travers le réseau Usenet.
17Une forme « institutionnalisée » d’anarchie, alt.*, est également prévue, et peut subvertir le processus news. admin de manière codifiée. Un newsgroup de type alt.* peut être ajouté à tout moment par tout usager, mais les sites préférant éviter a priori les situations problématiques qui peuvent en résulter peuvent choisir de ne pas avoir l’option. À l’intérieur de Usenet, chaque hôte participant peut prévoir ses propres politiques locales, mais le réseau dans son ensemble fonctionne grâce à la coopération et la bonne volonté de la communauté : le succès du modèle « démocratique » de ce réseau pionnier réside avec toute probabilité dans son mélange de régulation par l’organisation (procédurale) et de distribution de l’architecture [Auray, 2007].
- 28 Et de leur côté, les systèmes à la Freenet évitent délibérément de déléguer aux administrateurs lo (...)
18Beaucoup des systèmes P2P émergeant au cours des dix dernières années n’ont pas encore atteint pleinement le contrôle décentralisé,28 mais considèrent qu’y travailler est une des questions primordiales à résoudre. Dans la plupart des cas, la question intéressante à aborder est : combien de contrôle (ou quel degré de contrôle ?) faut-il donner aux administrateurs locaux des applications ?
19Pour certains, les systèmes modernes de P2P feraient bien de s’inspirer du protocole utilisé par Usenet. Les co-fondateurs de Popular Power, une start-up proposant une solution de calcul partagé, remarquent à ce propos :
« NNTP, en tant que protocole, contient un certain nombre d’optimisations […] par exemple, les messages de nouvelles maintiennent un titre qui retrace leur parcours de transmission d’un serveur de nouvelles à l’autre, appelé path header. Si le serveur
A reçoit une requête du serveur B, et la copie du message de A liste B dans son parcours, A n’essayera pas de retransmettre ce message à B. Puisque le but de la transmission de type NNTP est d’être sûr que chaque serveur de nouvelles sur Usenet peut recevoir un article s’il le veut ; le path header évite une inondation de messages répétés. Gnutella, par exemple, n’a pas utilisé un tel système en transmettant les requêtes de recherche, aussi un seul nœud Gnutella peut recevoir plusieurs fois la même requête » [Minar & Hedlund, 2001].
20La nature ouverte et décentralisée d’Usenet a, par ailleurs, des inconvénients aussi bien que des avantages. Usenet a représenté un des plus grands succès du premier Internet, dans la mesure où il a survécu depuis 1979 et qu’il continue d’héberger des communautés d’experts florissantes, ayant largement dépassé ses débuts modestes. Pourtant, sous plusieurs aspects, l’ethos de confiance et la nature décentralisée du protocole en ont parfois réduit l’utilité et l’ont relégué au rang de canal de communication trop bruyant. En particulier, comme on le verra, Usenet a été une victime privilégiée du spam dans les premières phases de développement de l’Internet commercial. Cependant, son système de contrôle décentralisé, les méthodes que ce réseau déploie pour éviter la saturation du réseau, et quelques autres caractéristiques en font un excellent objet de leçon pour les concepteurs des nouveaux systèmes P2P.
Domain Name System, l’hybride souple
21Le Domain Name System (DNS, système de noms de domaine) est un autre exemple de système qui combine un type d’interconnexion pair à pair avec un modèle hiérarchique de propriété de l’information. Pour le développeur d’outils de type P2P, ce qui paraît le plus remarquable dans le DNS est sa capacité de passer à l’échelle, des quelques milliers de hôtes qu’il était destiné à héberger en 1983 jusqu’aux centaines de millions qui forment désormais l’Internet. Les leçons qui dérivent du DNS sont directement applicables aux applications contemporaines en P2P, surtout celles destinées au partage de données.
22Le DNS a été établi, à l’origine, en tant que solution à un problème de partage de fichiers. À l’aube de l’Internet, la façon d’associer une étiquette plus facilement lisible à une adresse IP était de se servir d’un seul fichier, hosts. txt, qui était copié à tout le réseau Internet périodiquement. Au fur et à mesure que la toile se peuplait de milliers d’hôtes, et que la gestion de ce fichier devenait impossible, le DNS a été développé, pour distribuer le partage des données sur l’ensemble de l’Internet, à ce moment encore une structure égalitaire.
23L’espace de nommage du DNS est, par ailleurs, « naturellement » hiérarchique : une hiérarchie intégrée au système à son niveau le plus profond. Il s’agit d’un mécanisme de délégation de responsabilité dans la gestion des différentes parties de la base de données DNS. Chaque domaine a une autorité, le serveur qui enregistre les hôtes pour cette base de données. Quand un hôte sur l’Internet veut connaître l’adresse d’un nom en particulier, il le demande au serveur de nommage le plus proche. Si ce serveur ne le connaît pas, il délègue la requête à l’autorité pour l’espace de nommage. Cette requête peut, à son tour, être déléguée à une autorité supérieure, et le processus peut se répéter jusqu’aux serveurs racine pour l’Internet dans son ensemble. Pendant que la réponse est renvoyée vers le demandeur, le résultat est mis en mémoire (cache) aux différents stades du parcours, pour que la requête suivante puisse être traitée plus efficacement. Les serveurs de nommage opèrent soit en tant que clients, soit en tant que serveurs.
- 29 Par ailleurs, l’« ordonnancement » d’un système qui n’avait pas prévu, à l’origine, d’ordre politi (...)
24Dans son ensemble, le DNS fonctionne correctement aujourd’hui, d’une façon presque surprenante au vu de son passage à l’échelle très important (presque 10 000 fois sa taille originelle)29. Plusieurs éléments fondamentaux de son design sont susceptibles d’être répliqués dans les systèmes distribués contemporains. En premier lieu, les hôtes peuvent opérer soit comme clients, soit comme serveurs, en propageant si besoin les requêtes. Ces hôtes facilitent aussi le passage à l’échelle en mettant les réponses en cache. Deuxièmement, la manière de propager les requêtes de données à travers le réseau. Tout serveur DNS peut en interroger un autre, mais normalement, il y a un parcours standard dans la chaine d’autorité. La charge est distribuée sur l’ensemble du réseau DNS, pour que tout serveur individuel ne doive servir que les nécessités de ses clients et l’espace de nommage qu’il gère individuellement.
25Le succès du DNS, en tant qu’hybride doté d’une capacité d’évolution souple, a donc été lié à l’introduction d’une dynamique distribuée dans un système conçu de manière totalement hiérarchique.
26Ainsi, depuis ses premiers stades de développement, l’Internet a été construit en se basant sur des modèles de communication en pair à pair. Cela amène les développeurs à regarder vers ces premières expériences pour leur design de nouveaux systèmes P2P, puisque les questions et problèmes à affronter dans les nouvelles applications ont beaucoup en commun avec les problèmes abordés par Usenet et le DNS il y a vingt ans. Il s’agit de dispositifs avec des spécifications distribuées, articulées avec des formats de régulation à la fois technologiques et politiques – d’un côté, une gestion interne de conflits avec un lourd appareillage de consultation, et de l’autre, un alignement sur le droit des marques.
L’INTERNET COMMERCIAL ET SES CONSÉQUENCES POUR L’ARCHITECTURE DU RÉSEAU
27En 1994, l’explosion commerciale de l’Internet en change radicalement la forme, transformant le réseau des réseaux, tranquille utopie d’intellectuels passionnés, en agité médium de masse. Des millions de nouveaux utilisateurs font leur apparition sur le Net, une vague représentant des nouveaux profils d’internautes : les ordinary people intéressés par la facilité avec laquelle on peut entrer en contact, visiter des pages d’information, et acheter en ligne, plutôt que par les secrets et les détails de structuration de réseaux complexes. La transformation de l’Internet en un phénomène de culture de masse entraine bientôt des changements d’une portée considérable dans l’architecture du réseau, un impact qui n’est pas sans conséquences sur la création d’applications P2P dans l’Internet d’aujourd’hui. Ces changements s’explicitent notamment dans la façon dont le réseau est utilisé, dans la rupture du principe de coopération sur le réseau, le déploiement de pare-feu, et l’augmentation de liens de réseau asymétriques tels que l’ADSL et les câbles Ethernet.
Le passage au modèle client/serveur et la rupture de la coopération
- 30 Par exemple SLIP (Serial Line Internet Protocol, ou protocole Internet de liaison en série, protoc (...)
- 31 Un routeur fait du Network Address Translation (NAT, « traduction d’adresse réseau ») lorsqu’il fa (...)
28Le modèle de réseau sous-tendant les applications destinées à l’utilisateur final – non seulement en termes de consommation de bande passante, mais aussi en termes de contact, relation et communication entre machines – change radicalement avec l’avènement de l’Internet commercial et la connexion de millions d’usagers « domestiques » des années 1990. Les protocoles de modem deviennent toujours plus populaires30, les applications sont de plus en plus programmées pour des modems et des lignes analogiques à basse vitesse, et les entreprises commencent à doter leurs réseaux de pare-feu et de Network Address Translation31. Beaucoup de ces changements reflètent les priorités d’usage communes à ce moment historique particulier ; la plupart concernent le téléchargement de données plutôt que la publication d’informations ou leur téléchargement vers l’amont.
29Le navigateur Web, et plusieurs autres applications qui naissent dans les premières phases de la commercialisation de l’Internet, se basent sur un simple protocole client/serveur : le client amorce une connexion à un serveur connu, en télécharge des données, et se déconnecte. Quand l’utilisateur a terminé ce téléchargement et que les données sont collectées, le processus se répète. Ce modèle s’est avéré une façon simple et directe de mettre en place nombre d’applications qui impliquaient un service à l’utilisateur, de la navigation du Web, au visionnage des vidéos en streaming. De leur côté, les développeurs commencent à y mettre des chariots de courses, des transactions de stocks, des jeux interactifs, et beaucoup d’autres « biens ». Les machines qui hébergent un client web ne nécessitent pas, elles, une adresse reconnue ni permanente. Elles n’ont pas besoin d’une connexion permanente à l’Internet, ni de gérer les besoins de plusieurs usagers. Elles doivent juste, souligne un développeur, « savoir comment poser une question, et comment écouter et comprendre la réponse ».
30Cependant, toutes les applications utilisées au niveau domestique ne répondent pas à ce modèle. La messagerie électronique, par exemple, repose beaucoup plus sur une communication à double sens entre un serveur et un client email ; par ailleurs, dans ce cas, le client est souvent en train de « parler » à un serveur sur le réseau local (soit le serveur du FAI, soit le serveur d’une entreprise). Les systèmes de chat tel que l’Instant Messenger de AOL, largement diffusés, ainsi que les systèmes Usenet, ont des propriétés « locales » semblables. En conséquence, les instructions de configuration typiques d’un FAI pour le chat, l’email ou le partage de nouvelles sont détaillées, mais elles n’ont pas besoin d’être comprises par l’utilisateur pour les usages communs. Mises à part quelques exceptions qui non seulement exigeaient une configuration manuelle de la part de l’usager, mais – prône un développeur – « méritaient aussi son effort », le modèle de téléchargement à sens unique est à ce stade plus simple, bien que souvent moins transparent, et fonctionne sans que l’utilisateur ait besoin de s’investir dans le processus de configuration ; le modèle à double sens est utilisé de moins en moins fréquemment.
31Les premières visions du Web traçaient un portrait de grand « égalisateur de communications » – un système permettant à tout usager de publier son point de vue au lieu d’être purement et simplement un consommateur de médias. L’explosion commerciale de l’Internet dirige rapidement une grande majorité de son trafic vers le paradigme « downstream » propre à la télévision et aux médias traditionnels ; même si la fabrication de contenus ad hoc, liée à la spécificité de chaque requête et de chaque contribution des utilisateurs, reste une première évolution par rapport à ce modèle – une évolution destinée à s’inscrire dans la durée.
32Le premier Internet a été dessiné en accord avec des principes de coopération et avec la « bonne ingénierie » qui donnent la priorité aux questions d’efficacité et d’optimisation technique du dispositif. Toute personne travaillant sur l’Internet avait un même but : construire un réseau fiable, efficace et puissant. L’entrée de l’Internet dans sa phase commerciale change les équilibres, les avantages et les structures ; elle provoque nombre de points de stress et de faiblesse. Ce phénomène s’actualise de plusieurs façons, notamment dans l’augmentation importante de spam circulant sur le réseau et dans les défis rencontrés dans la construction de protocoles de réseau efficaces, pouvant gérer les ressources nécessaires à son fonctionnement dans une perspective de bien commun.
Des agents non coopératifs : le spam
33Les spam, ou messages électroniques commerciaux non sollicités, sont aujourd’hui un phénomène omniprésent sur l’Internet. Au cours de la phase pré-commerciale du réseau, la publicité non sollicitée était généralement reçue avec surprise et indignation. La « fin de l’innocence » [Minar & Hedlund, 2001] a lieu le 12 avril 1994, le jour où les avocats Laurence Canter et Martha Siegel postent le premier spam commercial de masse sur Usenet, le « Green Card Spam » : il s’agit d’une publicité postée individuellement sur tous les groupes de discussion Usenet, qui atteint le monde entier avec un message publicisant les services de la firme de Canter et Siegel [Everett-Church, 1999]. À l’époque, ce genre d’action est sans précédent et engendre une forte désapprobation. Non seulement la plupart du public potentiel touché n’est pas intéressé par le service, mais beaucoup de gens estiment que Canter et Siegel ont, de facto, volé les ressources de Usenet. Les deux avocats ne sont pas ceux qui paient pour la transmission de la publicité : les coûts sont, plutôt, pris en charge par Usenet dans son ensemble.
34Dans l’Internet contemporain, le spam n’apparaît pas comme surprenant ; Usenet y a largement cédé, et les FAI fournissent maintenant des services de filtrage de spam pour le courrier électronique de leurs utilisateurs, à la fois pour aider ceux-ci et pour défendre leurs propres infrastructures. La messagerie électronique et Usenet comptaient sur la coopération des individus, et sur leur volonté individuelle et collective de ne pas inonder les ressources communes avec des courriers publicitaires indésirables : c’est ce principe de coopération qui tombe en panne. À ce jour, l’Internet ne s’est pas doté d’une technologie vraiment efficace pour empêcher le spam.
35Dans ce cas, le manque d’attribution de responsabilité dans l’architecture de l’Internet devient un problème, et pose des nouvelles questions. Puisque n’importe quel hôte peut se connecter à tout autre hôte, et que les connexions sont presque anonymes, les usagers peuvent insérer du spam dans le réseau à tout moment. Commence alors une sorte de « course aux armements » pour essayer de responsabiliser les utilisateurs : la fermeture des relais ouverts pour l’envoi de messages, le suivi des sources de spam sur Usenet, les représailles contre les spammeurs. Mais la bataille est perdue depuis le début : aujourd’hui, le spam est un phénomène avec lequel les utilisateurs (et les dispositifs de communication eux-mêmes) ont, de facto, appris à vivre.
36Les concepteurs de P2P voient une leçon importante dans la naissance du spam : sans l’attribution de responsabilité au sein du réseau, il est difficile d’implémenter les règles de la responsabilité sociale. Tout comme Usenet et le courrier électronique, les systèmes P2P actuels courent le risque d’être envahis par des publicités non sollicitées. Il est difficile de concevoir un système dans lequel tout usage socialement inapproprié peut être complètement prévenu. Des technologies de responsabilité et responsabilisation, telles que les systèmes de réputation ou l’identification chiffrée – implémentées et renforcées depuis le début du développement – peuvent être des outils précieux pour aider à gérer un réseau P2P.
Des protocoles coopératifs : TCP et le « best effort »
37Un principe fondamental de conception de l’Internet est le best effort, le « meilleur effort » de livraison de paquets : cela signifie que la composition et la structure du réseau Internet ne garantit pas qu’un paquet va rejoindre sa destination, mais tout simplement que le réseau « fera de son mieux » pour que cela arrive.
38Les protocoles de niveau supérieur, tel le Transmission Control Protocol (TCP), créent des connexions fiables en détectant quand un paquet est perdu et en le renvoyant. Une des raisons principales pour laquelle les paquets ne sont pas livrés sur l’Internet est l’encombrement : si un routeur du réseau est débordé, il commence à supprimer des paquets au hasard. TCP y remédie en modifiant la vitesse à laquelle les données sont envoyées. Lorsque le réseau est encombré, chaque connexion TCP ralentit de façon indépendante, cherchant à trouver le taux optimal d’échange tout en ne perdant pas trop de paquets. Par ailleurs, non seulement les connexions TCP individuelles optimisent leur utilisation de bande passante, mais le protocole est également conçu pour permettre à l’Internet dans son ensemble de fonctionner efficacement. Le comportement collectif de nombre de connexions TCP individuelles qui ralentissent de façon indépendante entraîne une diminution de la saturation au niveau du routeur ; l’algorithme TCP est donc, en fait, une façon pour les différents pairs de gérer une ressource partagée, sans coordinateur central.
39Le problème est que l’efficacité du protocole TCP à l’échelle de l’Internet dans son ensemble requiert, fondamentalement, de la coopération : à chaque utilisateur du réseau, il est demandé de jouer avec les mêmes règles. Comme explique un développeur :
« Les performances d’une connexion individuelle au moyen de TCP sont inversement proportionnelles à la racine carrée du taux de perte de paquets – ladite “TCP rate equation”, loi fondamentale pour une bonne gouvernance de l’Internet. Les protocoles qui suivent cette loi sont connus comme les protocoles “TCP-friendly”. Il est possible de concevoir d’autres protocoles qui ne suivent pas cette équation, et qui vont rudement essayer de consommer plus de bande passante qu’ils ne devraient. Ces protocoles peuvent causer des ravages sur le Net. »
40Ces « ravages » seraient dus non seulement à l’utilisation d’une quantité trop importante et non équitable de ressources, mais aussi à l’endommagement d’une ressource commune pour tous. Un problème qui a été cité comme exemple classique de la tragédie des communs [Ostrom, 1999] – le dilemme découlant de situations dans lesquelles plusieurs individus, agissant de manière indépendante et consultant rationnellement leur propre intérêt, finissent par épuiser une ressource partagée limitée, même quand il est clair que ce n’est l’intérêt à long terme de personne que cela se produise – dilemme auquel l’Internet d’aujourd’hui est tout à fait vulnérable.
41Le problème est à la fois théorique et très pratique : ces protocoles ont été élaborés au cours de ces dernières années par des entreprises aux exigences commerciales, tandis qu’en parallèle, d’autres composantes du secteur IT, le monde de l’open source en tout premier lieu, ont exprimé l’inquiétude croissante que les protocoles hostiles commencent à nuire à l’Internet.
42Un des premiers exemples est la fonctionnalité ajoutée par Netscape à son navigateur qui donne la possibilité de télécharger plusieurs fichiers en même temps. En 1996, les ingénieurs de Netscape découvrent que si on télécharge des images intégrées en parallèle, plutôt qu’une seule à la fois, la page entière se télécharge plus rapidement, ce que les utilisateurs apprécient. Mais une question se pose alors : cette utilisation de bande passante est-elle équitable ? Non seulement on force le serveur à envoyer plusieurs images simultanément, mais on multiplie les canaux TCP, et on contourne les algorithmes TCP contre la saturation.
43Une controverse s’installe lorsque Netscape introduit cette fonction. Elle s’apaisera une fois que, Netscape ayant rendu publiques les caractéristiques de son navigateur, on découvre dans la pratique que la stratégie de téléchargement en parallèle ne porte pas indûment préjudice à l’Internet. Aujourd’hui, cette technique est la norme pour tous les navigateurs et demeure incontestée, mais le même type de questionnements s’est posé pour les programmes visant à accélérer le téléchargement simultané des différents morceaux d’un même fichier, menaçant à nouveau de bouleverser la gestion délicate du réseau Internet afin d’en éviter la saturation.
44La diffusion du spam et le fonctionnement de l’algorithme TCP partagent une même caractéristique : ils démontrent la fragilité du bon fonctionnement durable de l’Internet, et la nécessité de coopération que celui-ci implique. Dans le cas du protocole TCP, le système a résisté, et le réseau a été préservé. Dans le cas du spam, cependant, les consensus est établi parmi les développeurs : comme souligne l’un d’entre eux, « la bataille a été perdue et un comportement asocial et non coopératif est avec nous pour toujours. La leçon pour les concepteurs de systèmes est donc d’examiner la question de la “politesse” entre usagers en amont. »
45Une alternative se pose donc aux développeurs : ou bien il est nécessaire de concevoir des systèmes qui n’ont pas besoin de la coopération comme principe fondateur de leur bon fonctionnement, ou bien, plus vraisemblablement, il faut créer des incitations à la coopération, en récompensant les comportements responsables ou en implémentant des mécanismes de vérification, afin que les initiatives déséquilibrées ou nuisibles puissent être punies.
La fin du réseau ouvert
46En même temps que la nature coopérative de l’Internet se voit menacée, les administrateurs de réseau mettent en place diverses mesures de gestion, qui finissent par se traduire dans un Internet beaucoup moins ouvert. Notamment, la symétrie du réseau – le principe selon lequel si un hôte peut accéder au réseau, tout le monde sur le réseau peut atteindre cet hôte – commence à être érodée au milieu des années 1990 par trois tendances controversées : le déploiement toujours plus fréquent de pare-feu, l’augmentation des adresses IP dynamiques, et la popularité de la Network Address Translation.
47L’Internet devient un système plus mûr, et avec sa maturation vient la nécessité de sécuriser le réseau, pour protéger chaque hôte individuel d’un accès illimité par les autres. Les utilisateurs moyens ne pouvant pas gérer de manière autonome les risques de sécurité pour leurs machines qui résultent d’une conception symétrique des réseaux, leurs gestionnaires se tournent vers les pare-feux en tant qu’outils permettant de contrôler l’accès à ces machines. Les pare-feux se trouvent au point de contact entre le réseau interne et l’Internet à l’extérieur. Ils filtrent les paquets, et choisissent quel trafic laisser passer et à qui refuser l’accès. Le pare-feu met à l’épreuve le modèle fondamental de l’Internet : certaines parties du réseau ne peuvent plus parler de façon totalement libre à d’autres parties. Ainsi, un outil de sécurité très utile, le pare-feu, pose un premier obstacle sérieux aux modèles de communication en P2P.
48Le fonctionnement typique du pare-feu est de permettre à quiconque est situé à l’intérieur d’un réseau d’amorcer et établir une connexion avec tout autre internaute, mais d’empêcher des hôtes au hasard sur l’Internet d’initier des connexions avec des hôtes sur le réseau interne : une porte à sens unique par laquelle on peut sortir, mais pas entrer. En outre, les connexions en sortie peuvent être limitées exclusivement à certaines applications, comme FTP et le Web, et bloquer le trafic d’autres portes au niveau du pare-feu. Un hôte protégé de cette façon ne peut plus facilement fonctionner comme un serveur : il ne peut être qu’un client.
49Permettre à un hôte sur l’Internet de n’être qu’un client, et pas un serveur, est un thème transversal à beaucoup de changements de l’Internet après son explosion commerciale. Avec l’augmentation du nombre d’utilisateurs dotés d’une connexion à l’Internet par modem, la pratique de donner à chaque hôte une adresse IP fixe devient impraticable, le nombre d’adresses IP n’étant plus suffisant. L’affectation dynamique des adresses IP prend pied jusqu’à devenir la norme pour de nombreux hôtes sur l’Internet, où l’adresse d’un ordinateur particulier peut maintenant changer même une fois par jour. Les fournisseurs de bande passante, de leur côté, trouvent les adresses IP dynamiques utiles pour le déploiement de services toujours disponibles. Le résultat final est que de nombreux hôtes sur l’Internet, se déplaçant constamment, ne sont pas facilement accessibles. Par rapport à l’Internet des débuts où les hôtes étaient statiques, les choses se compliquent : les applications P2P servant des buts tels que la messagerie instantanée ou le partage de fichiers, pour contourner ce problème, doivent désormais construire des répertoires dynamiques d’hôtes.
50Cette tendance s’accroît ultérieurement quand on commence à ne plus attribuer une adresse Internet publique et valide à un hôte, mais à utiliser la NAT pour cacher cette adresse derrière un pare-feu. Par rapport au type de trafic P2P, la NAT allie les problèmes des pare-feu et ceux des adresses IP dynamiques : la véritable adresse de l’hôte n’est pas seulement instable, elle n’est plus accessible. Toute communication doit parler un langage relativement simple, que le routeur NAT puisse comprendre, ce qui entraîne une grande perte de flexibilité dans les communications entre applications. Par exemple, remarque un développeur de jeux en ligne :
« de nombreux jeux coopératifs sur l’Internet ont eu des problèmes avec la NAT […] chaque joueur veut être en mesure de contacter tous les autres joueurs, mais les paquets ne peuvent pas passer par le routeur NAT. Le résultat est que un serveur central doit être établi pour agir en tant que routeur de messages au niveau de l’application, en servant la même fonction que le protocole TCP/IP servait avant. »
51Les pare-feux, les IP dynamiques, et la NAT sont nés d’un besoin de sécuriser l’architecture Internet au fur et à mesure que celle-ci évoluait et se peuplait d’usagers, et ils ont contribué de manière déterminante à amener des millions d’ordinateurs clients sur l’Internet, de façon rapide et souple. Ces mêmes technologies ont, par ailleurs, profondément reconfiguré les équilibres de l’infrastructure Internet dans son ensemble, en « reléguant » la plupart des ordinateurs au seul statut de clients. Architecture que les nouvelles applications P2P mettent, une fois de plus, en discussion.
La disponibilité de bande passante : des connexions asymétriques
52Une autre tendance de l’Internet des années 1990 qui pose problème aux applications P2P est la montée en puissance de connexions asymétriques au réseau, telles que l’ADSL ou les modems câblés. Afin de maximiser l’efficacité du câblage disponible, les fournisseurs de services à large bande choisissent de fournir une bande passante asymétrique. L’installation domestique typique d’une ligne ADSL ou d’un modem câblé est conçue de façon à ce qu’elle offre trois à huit fois plus de bande passante en téléchargeant des données depuis l’Internet qu’en envoyant des données vers le réseau, favorisant ainsi des usages de type client plutôt que de type serveur.
53La raison pour laquelle ce déséquilibre entre téléchargements vers l’amont et vers l’aval est largement toléré par le public est liée au rôle de « killer application » de l’Internet que le Web a occupé pendant ces années : la plupart des usagers du Web n’ont que très rarement besoin d’être plus qu’un client. Même les usagers qui publient leurs propres pages Web ne le font pas, généralement, depuis leur connexion domestique à bande large, mais depuis des serveurs dédiés appartenant à des tiers, tels IT GeoCities ou Exodus. Si dans les premiers jours d’existence du Web la situation était moins claire – la possibilité que chaque usager se dote d’un serveur web personnel n’était pas écartée a priori – il devint bientôt clair que le Web commercial comportait en soi des éléments d’asymétrie – beaucoup de clients pour peu de serveurs – et que la plupart des usagers étaient, dans ce contexte, bien servis par l’asymétrie de la bande passante.
54Les applications P2P mettent à nouveau et radicalement en débat l’approche selon laquelle les usagers finaux exécutent presque exclusivement des opérations de téléchargement vers l’aval, et non vers l’amont. Déjà les premières applications de partage de fichiers, telles Napster ou la première version de Gnutella, renversent ce modèle d’utilisation de bande passante : les terminaux servent souvent beaucoup plus de fichiers qu’ils n’en téléchargent. Le canal de téléchargement vers l’amont ne peut souvent pas satisfaire la demande, ce qui, à cause des détails de fonctionnement du protocole TCP, entraine également des répercussions sur les bonnes performances du canal de téléchargement vers l’aval.
55L’architecture du réseau Internet, au début des années 2000, reflète cette asymétrie : les connexions ADSL, au moyen de modems câblés (et plus généralement tout réseau géré par un FAI) sont conçues pour que le flux des bits se dirige vers l’utilisateur [Taylor & Harrison, 2001 : 6]. Cette assomption d’asymétrie est remise en discussion par la technologie P2P ; par ailleurs, il y a très peu de solution « directe » qu’une application P2P à elle seule puisse mettre en œuvre pour la contourner.
ENTRE ANCIENS MODÈLES ET INNOVATION : LA « RENAISSANCE » DU P2P
56Le début des années 2000 voit l’avènement de nouveaux dispositifs qui se revendiquent du P2P : ceux-ci profitent à la fois des leçons fournies par les premiers modèles de l’Internet, et de la mise en place de caractéristiques novatrices. Ils permettent de nuancer et de séparer les concepts de création de l’information et de publication ; ils ouvrent la voie à des nouvelles organisations du trafic Internet, en soumettant les pare-feu à des efforts jusque là inédits ; ils expérimentent avec la conception d’applications décentralisées, ce qui pose à la fois des défis nouveaux et ouvre des nouvelles possibilités.
Création et publication de l’information
57Une des promesses de l’Internet est depuis le début que ses usagers deviennent capables de publier les informations dont ils sont les créateurs, par exemple en utilisant des sites web personnels pour révéler au public leurs points de vue et leurs intérêts. Les pratiques d’auto-publication deviennent certes plus populaires avec l’avènement de l’Internet commercial ; pourtant les usagers passent, pour l’essentiel la plupart de leur temps en ligne à lire (et télécharger) de l’information, et moins à en publier [Minar & Hedlund, 2001 : 15-16]. Comme on l’a vu, les fournisseurs de services et d’accès Internet construisent leur offre en s’appuyant sur cette asymétrie.
58Les applications P2P qui jouissent d’un succès considérable au début des années 2000 sont porteurs d’une réalité intermédiaire entre le supposé cas idéal des origines, « tout le monde publie », et l’apparente réalité de l’Internet commercial, « tout le monde consomme ». Ces applications, Napster en particulier, rendent très facile la publication de données dont on n’est pas l’auteur, tandis que les machines des utilisateurs sont utilisées comme répétiteurs pour la retransmission des données qu’elles reçoivent. Le design du réseau qui repose sur l’existence d’un nombre limité d’auteurs, et l’asymétrie de bande passante comme principe d’optimisation, se voient profondément remis en discussion par ce développement. Un nombre important de réseaux, en premier lieu les systèmes des campus et des petites entreprises, se trouvent surchargés.
59Les systèmes P2P se voient rapidement bannis de ces réseaux, parce qu’ils changent de facto la direction et l’importance des flux de données, et ainsi faisant, ils prouvent la fausseté d’une assomption qui a guidé le développement de l’Internet des années 1990. Les serveurs ne sont pas tous placés sous le contrôle des éditeurs de contenus ; les éditeurs et les auteurs des contenus ne correspondent pas toujours à un même emplacement sur le réseau. Les usagers n’ont pas besoin de créer du contenu pour vouloir et pouvoir le publier [Dauphin & Dagiral, 2005] ; la faisabilité de la publication de masse par les « lecteurs » est démontrée par la grande échelle que certains de ces systèmes sont capables d’atteindre.
Les défis pour la « sécurisation » des réseaux
- 32 Un port logiciel (identifié au moyen d’un numéro) permet, sur un ordinateur donné, de distinguer d (...)
60Les outils de type P2P posent aussi des nouvelles questions et problèmes pour les outils de sécurisation du premier Internet commercial. En particulier, ils soumettent à des nouveaux efforts le « port 80 »32, que le trafic http utilise lorsque les utilisateurs naviguent sur le Web [Minar & Hedlund, 2001]. Sauf exception, les pare-feux filtrent le trafic en se basant sur sa direction (en entrée ou en sortie) et son port de destination. Comme le Web est l’application principale de nombreux utilisateurs Internet, presque tous les pare-feu autorisent les connexions en sortie sur le port 80, même si leur politique est par ailleurs très restrictive.
61Dans les premières années de l’Internet, le numéro de port indiquait habituellement quel type d’application était en train d’utiliser le réseau : le pare-feu pouvait considérer automatiquement que le port 80 était uniquement destiné au trafic Web. Mais précisément parce que de nombreux pare-feu autorisent les connexions au port 80, les auteurs d’autres types d’applications commencent à acheminer le trafic de ces applications à travers ce port. Streaming audio, messagerie instantanée sont envoyés au moyen du port 80, et la plupart des applications P2P destinées au partage de fichiers commencent à faire de même, contournant ainsi les politiques de sécurisation des réseaux : les pare-feu sont programmés de façon à ne pas se rendre compte du fait qu’ils sont en train de permettre l’accès à un trafic que l’administrateur du réseau désire précisément bloquer.
62Cela pose deux points de tension. Tout d’abord, puisque le numéro de port a été contourné, il n’y a pas de moyen efficace pour un pare-feu d’identifier les applications qui le traversent. Une nouvelle génération de pare-feux commence donc à voir le jour, qui permet d’analyser le trafic réel qui le traverse pour voir s’il s’agit d’un flux http légitime ; cette dynamique encourage cependant, à son tour, les concepteurs d’applications à masquer le trafic de celles-ci en http, donnant ainsi lieu, souligne un gestionnaire de réseau, à une « course aux armements qui ne profite à personne ». Un deuxième point ouvert est que, même si une application a une raison légitime de passer par le pare-feu, il n’y a pas de moyen simple pour l’application de demander l’autorisation de le faire. Le pare-feu, en tant que mesure de sécurisation du réseau, est dépassé : tant qu’un pare-feu permet à un type de trafic quelconque de s’y glisser, les applications P2P trouvent un moyen de le faire.
Quelle décentralisation ?
63Les systèmes P2P ne sont pas synonymes de décentralisation, bien qu’ils y soient étroitement liés. Dans un système totalement décentralisé, non seulement tous les hôtes sont des partenaires égaux, mais il n’y a pas d’hôtes avec des rôles particuliers, de facilitateur ou d’administrateur. Dans la pratique, la construction de systèmes entièrement décentralisés, ainsi que leur préservation dans le temps, présentent nombre de défis techniques ; de nombreuses applications P2P adoptent donc des approches hybrides pour résoudre ces problèmes. Les exemples qu’on a présentés au cours de ce chapitre et du précédent en sont des exemples : le DNS est décentralisé dans la conception du protocole qui le gouverne, mais un principe organisationnel hiérarchique y est profondément inscrit. Il existe de nombreux autres exemples de systèmes qui sont en première instance décentralisés, mais dont l’organisation est semi-centralisée au niveau de l’application : c’est le cas de Usenet et de plusieurs outils de messagerie instantanée, ainsi que de partage de fichiers.
- 33 En informatique, un arbre est une structure de données qui émule une arborescence hiérarchique ave (...)
64Usenet, en particulier, est un exemple éclairant de l’évolution d’un système décentralisé. La propagation des nouvelles par Usenet est symétrique ; il s’agit d’hôtes qui partagent du trafic. Par ailleurs, puisque les coûts pour maintenir une news feed complète sont élevés, il existe dans la pratique une ossature de nœuds « primaires » qui se chargent de tout le trafic et le servent à un grand nombre de « nœuds/feuilles »33 dont le rôle est surtout de recevoir des articles. Coexistent donc dans Usenet une tendance à la propagation du trafic de façon hiérarchique, même si les protocoles sous-jacents ne l’exigent pas. Cette forme de centralisation « molle » s’avère viable et économique pour plusieurs des nouveaux systèmes P2P, avec des systèmes de transmission de données à coût élevé.
65Beaucoup d’autres applications P2P aux débuts des années 2000 présentent une facette décentralisée, tout en s’appuyant sur un facilitateur central pour coordonner les opérations : par exemple, aux yeux de l’utilisateur d’un système de messagerie instantanée, l’application dont il se sert semble de type P2P, envoyant les données directement à l’ami qui est leur destinataire. Mais tous les principaux systèmes de messagerie instantanée sous-tendent un serveur qui facilite la communication entre les nœuds.
66Les développeurs introduisent l’« objet serveur » dans leurs projets pour différents buts : celui-ci peut gérer l’association entre le nom de l’utilisateur et son adresse IP courante, stocker temporairement les messages si l’utilisateur est déconnecté, et acheminer les messages aux utilisateurs qui se protègent d’un pare-feu ; ou encore, dans le cas des systèmes qui permettent une communication directe entre clients lorsque cela est possible, il est présent comme solution de repli. Dans la plupart des cas où ces approches hybrides sont déployées, il s’agit de parvenir, avec difficulté, à un compromis avec la forme du réseau dans son ensemble : une approche entièrement décentralisée de messagerie instantanée ne fonctionnerait pas sur l’Internet d’aujourd’hui. Pourtant, permettre la communication de client à client, lorsque cela est possible, a des avantages en termes de passage à l’échelle.
67Napster, le pionnier des applications de partage de fichiers en P2P, est un autre exemple d’un système hybride, ce qui a entrainé sa perte. D’un point de vue technique, le partage de fichiers dans Napster était décentralisé : un client téléchargeait un fichier Napster directement de la machine d’un autre client de Napster. Mais le répertoire des fichiers était centralisé, les serveurs de Napster répondant à des requêtes de recherche et agissant en tant qu’intermédiaires des connexions entre les clients. À nouveau d’un point de vue technique, cette approche hybride a été très puissante en termes de passage à l’échelle : le répertoire restait efficace face à l’augmentation de la quantité de matériel mis à disposition sur le réseau, car il utilisait peu de bande passante.
68Au moment même où Napster connaît son heure de gloire, il paraît bientôt évident que les expérimentations avec des modèles décentralisés ne sont pas sans détracteurs. Dans la pratique, certaines applications peuvent mieux travailler avec un design entièrement centralisé sans utiliser de technologie P2P : ce serait le cas, par exemple, d’une recherche sur une grande base de données relativement statiques, car les actuels moteurs de recherche Web sont capables de servir jusqu’à un milliard de pages à partir d’un seul et même endroit et les algorithmes de recherche, à ce jour, ont été optimisés à fond pour un fonctionnement centralisé. La décentralisation peut aussi engendrer des échecs spécifiques à ce modèle, comme le manque de fiabilité ou une synchronisation des données incorrectes. Une leçon se profile donc pour les développeurs en P2P des générations suivantes : la nécessité d’équilibrer la puissance de distribution typique des modèles P2P et les complications, voire les limites, des systèmes décentralisés.
AUX MARGES DU RÉSEAU
69Dans un scénario où dominent les connections asymétriques et la concentration des ressources, le P2P se profile comme la technologie capable de fournir à un système la capacité de servir des ressources avec une grande disponibilité à un coût inférieur, tout en maximisant l’utilisation des ressources de la part de chaque pair connecté au réseau. Les solutions client-serveur tirent leur force du fait que le fournisseur de service ajoute, dans les cas où le nombre de clients augmente, des ressources additionnelles – bande passante, équipement, accès physique. Le P2P peut obtenir un niveau de robustesse semblable en partageant les demandes de ressources sur l’ensemble du réseau. Cependant, dans la pratique, le P2P « pur » ou intégral – celui qui utilise une structure de réseau complètement décentralisée – n’est presque jamais utilisé, au profit de solutions hybrides ou de compromis. Des choix architecturaux extrêmes, dans une direction ou dans l’autre, ne se révèlent que rarement la meilleure option quand il s’agit de construire un système « utilisable » [Taylor & Harrison, 2009 : 197] : le développement des « nouvelles » applications P2P est une histoire de compromis et d’épreuves.
70La définition de la décentralisation en train de se construire dans ces projets et dispositifs amène, en effet, à repenser ce qu’est un serveur, alors même que la démarche des développeurs vise souvent à s’en détacher le plus possible, afin d’augmenter la spécificité des dispositifs par rapport à leur rivaux centralisés plus célèbres et répandus.
71« Bien que la décentralisation ne soit pas une condition nécessaire à un système P2P, elle est une condition souhaitée » [Taylor & Harrison, 2009 : 125] ; en particulier, lors de la phase de conception d’un système P2P, la plupart des développeurs se trouvent face à un compromis : mêler suffisamment de décentralisation et de centralisation pour que le système soit à la fois résistant aux ruptures et capable de passer à l’échelle en cas d’augmentation substantielle du nombre d’utilisateurs. Plutôt que la présence ou l’absence d’un ou plusieurs serveurs, ce qui qualifie le P2P comme une technologie « décentralisée » est le fait que la responsabilité du réseau se voit poussée, de manière plus ou moins centrale mais toujours importante, aux marges ou à la périphérie du réseau, au lieu d’être maintenue dans un point central et concentré.
Un environnement fragile
72Plusieurs tentatives visant à extraire les points communs aux différents systèmes étiquetés sous le terme « peer-to-peer », et à donner une définition inclusive, ont été mises en œuvre dès la naissance de ces systèmes à l’aube du nouveau millénaire. En 2000, Clay Shirky tente la définition suivante :
« Le P2P est une classe d’applications qui tire parti des ressources, par exemple espace de stockage, cycles processeur, contenus, la présence humaine, disponibles aux marges de l’Internet. Puisque accéder à ces ressources décentralisées signifie opérer dans un environnement de connectivité instable et d’adresses IP imprévisibles, les nœuds P2P doivent opérer en dehors du système DNS et disposent d’une autonomie importante ou totale des serveurs centraux. » [Shirky, 2000].
73Il s’agit donc de systèmes d’ordinateurs ou de dispositifs « aux marges du réseau », ceux qui opèrent dans des environnements transitoires et souvent fragiles, qui se connectent et déconnectent fréquemment du réseau, sont souvent cachés derrière un pare-feu, utilisent des protocoles de transport et systèmes d’exploitation souvent différents avec des systèmes formés par une quantité de terminaux souvent énorme et plusieurs millions de pairs interconnectés.
74La deuxième partie de la définition de Shirky en limite par ailleurs le degré de globalité, en excluant du P2P des systèmes de calcul distribué ou réparti, tels que le célèbre programme de recherche extraterrestre SETI@home, et ce à cause du contrôle central inhérent à ces systèmes. Cette définition, en se concentrant sur l’environnement des dispositifs et des ressources, marque aussi un changement par rapport aux définitions précédentes qui s’étaient focalisées exclusivement sur le statut de « servents » (serveur et client à la fois) des nœuds d’un système P2P, et sur le fait que, pour être de « vrais » systèmes P2P, ceux-ci devaient être complètement décentralisés :
« Un pair peut agir à la fois comme un client et un serveur (on l’appelle alors un servent, serveur et client). […] Le réseau est complètement décentralisé et n’a pas de point de contrôle. Les pairs dans un réseau sont généralement connectés à trois ou quatre autres nœuds et, pour exécuter une recherche, une requête est diffusée à travers le réseau. » [Shirky, 2000].
75Par ailleurs, les réseaux P2P ne doivent pas être nécessairement complètement décentralisés. Les implémentations plus modernes de nombreux services de partage de fichiers, Gnutella par exemple, utilisent une approche à la fois centralisée et décentralisée, afin de faciliter le passage à l’échelle du réseau et augmenter l’efficacité des recherches. Ces réseaux sont implémentés en utilisant des « super-pairs » qui conservent en cache les informations d’emplacement des données ; les pairs peuvent ainsi obtenir une réponse à leurs recherches en ne recherchant que dans une petite fraction de l’ensemble du réseau.
Partager des ressources à la périphérie de l’Internet
76Ainsi, la définition de Shirky semble ici plus appropriée pour décrire une nouvelle « classe » d’applications, dont le dénominateur commun est le fait d’opérer dans un environnement en reconfiguration constante. D’autres auteurs et praticiens le suivent, en constatant qu’une telle définition décrit les systèmes P2P à large échelle actuellement présents sur le marché d’une façon beaucoup plus précise que l’idéal-type du « vrai » P2P [Foster & Iamnitchi, 2003 ; Ripeanu, 2001 ; Adar & Huberman, 2000 ; Gunther, 2002].
77La définition donnée par Oram [2004], postulant que le P2P est « toute technologie de réseau dont la responsabilité principale réside à ses marges (end-points) », renforce aussi l’idée que ce qui caractérise les réseaux P2P est la responsabilité des nœuds qui se trouvent à la périphérie. La périphérie est donc constituée par des nœuds qui ne font pas partie de l’infrastructure de l’Internet ; c’est-à-dire qu’ils ne sont pas une partie intégrante des réseaux qui composent l’Internet, ou le DNS. Ces nœuds, qui ne font pas partie du tissu de base de l’Internet, forment par ailleurs la majorité des nœuds présents sur le « réseau des réseaux ». Oram remarque aussi :
« Le P2P révèle toutes les faiblesses qui existent dans l’implémentation actuelle de l’Internet. En fait, et en dépit des difficultés de définition, le P2P est tout autant un ensemble de problèmes qu’il est un ensemble de technologies. » [Oram, 2004].
78Cette intuition, qui est par ailleurs implicite dans la deuxième partie de la définition de Shirky, est importante car elle contribue à faire émerger l’ensemble de facteurs et dynamiques sociotechniques qui concernent le développement d’une variété d’applications en P2P. Des questions telles que « Comment peut-on exploiter la grande quantité de ressources, telles que la puissance de calcul ou les données, disponibles en régime de quasi-gratuité sur l’Internet ? », « Comment peut-on connecter deux personnes, ou deux machines, et comment les deux connexions peuvent-elles s’entremêler ? », « Comment la liberté de circulation des données, proxy de la liberté de communication et de parole, peut-elle être assurée dans l’âge de l’information ? » ont amené aux technologies P2P. Des communautés très différentes se sont appropriées de ces questions avec des préoccupations variées, ce qui rend le P2P difficile à décrire. De surcroît, tout en essayant de répondre à ces questions, elles ont créé des bases d’usagers qui ont largement dépassé les attentes des développeurs, pour prendre des directions et des configurations inattendues, ce qui a influencé ensuite les développements successifs de façon très importante, comme on pourra observer au cours des chapitres suivants.
79Il est donc possible de définir, pour notre argument, le P2P en tant qu’ensemble de technologies déployées et développées pour déplacer le stockage, le calcul, la responsabilité ou le pouvoir aux marges du réseau Internet, et ce pour répondre à une large variété de préoccupations différentes. En relevant ce défi, les développeurs de plusieurs de ces systèmes se sont focalisés sur les manières d’entretenir la stabilité du réseau, malgré la nature inconstante et imprévisible des nœuds aux marges. Cela s’est souvent traduit par l’utilisation d’architectures décentralisées afin de gérer une éventuelle défaillance des nœuds, et leur mobilité. Plusieurs de ces architectures décentralisées se sont révélées être, à leur tour, robustes et capables de passer à l’échelle de façon efficace : comme a noté le développeur Paul James, « la meilleure façon de passer à l’échelle est d’utiliser l’ordinateur de quelqu’un d’autre » [James, 2011].
Optimiser sans stabiliser
80Comment organiser des réseaux décentralisés de façon à obtenir une performance optimale ? Tel est sans doute le but déclaré de tout ingénieur des réseaux P2P, mais les moyens d’y parvenir semblent beaucoup moins évidents. La performance des réseaux P2P est « non-deterministe », note un développeur, puisque le réseau est le plus souvent construit de façon ad hoc et, en raison de la nature temporaire de la disponibilité de ses pairs, il est impossible de stabiliser le réseau et ses frontières pour une performance optimale. Cela n’oblige pas, pour autant, à renoncer à la performance : les ingénieurs s’engagent donc dans un processus de négociation d’algorithmes qui puissent tirer le meilleur parti de la situation à tout moment donné.
81La performance n’est pas définie une fois pour toute au moyen d’une mesure valide et absolue, mais elle prend forme à la suite d’une série de mesures empiriques temporairement valides. Un développeur note :
« On se pose ces questions sans cesse, et ce n’est pas parce que la performance ne peut pas être déterminée une fois pour toute que la question est moins délicate. Au contraire, comparés à d’autres types de réseaux, les réseaux P2P sont bien les plus sensibles à des questions de performance, puisqu’on ne peut pas obtenir une réponse stable. »
82Les types de questions abordées sont, par exemple : combien de temps va prendre la recherche d’un fichier ; quelle quantité de bande passante cette recherche va-t-elle consommer ; combien de passages faudra-t-il à un paquet pour rejoindre un pair qui se trouve à la marge opposée du réseau ; le réseau est-il capable de résister à la disparition d’un pair – ou, de façon plus contre-intuitive, à l’ajout d’un de ces pairs ; au cas où le réseau verrait sa taille augmenter de quelques centaines, de plusieurs milliers voire de millions de pairs, le passage à l’échelle peut-il se passer sans problèmes ? La recherche d’optimisation d’un réseau cesse, donc, d’être synonyme d’obtention progressive de la stabilité, pour acquérir une signification d’exploration et de recherche d’une série d’équilibres transitoires.
83C’est, par ailleurs, de cette négociation constante qu’un système P2P est susceptible de tirer sa force en cas de défaillance. Les réseaux décentralisés opèrent, comme nous l’avons déjà rappelé, dans des environnements où les pairs sont constamment en train de se connecter et se déconnecter, et les ressources qu’ils hébergent peuvent devenir indisponibles pour différentes raisons, liées tout autant aux motivations des individus, à une participation discontinue ou à des contraintes techniques – y compris les défaillances du matériel, les coupures électriques et les attaques délibérées. Dans ces cas, susceptibles de cibler autant les terminaux domestiques que des serveurs dédiés, des algorithmes pouvant gérer la restructuration continuelle du cœur du réseau sont souvent plus efficaces que les pare-feu. Les différentes conceptions de la sécurité ont souvent un rôle très important dans les choix du modèle de réseau sous-tendant un service : « [l] es systèmes P2P doivent traiter les défaillances en tant que norme, pas en tant qu’exceptions bizarres » [Taylor & Harrison, 2009], et ils doivent chercher à assurer la redondance du système au moyen d’une constante négociation de l’incertitude.
LE BAR SICILIEN ET LES SYSTÈMES DISTRIBUÉS
Lors de la rédaction de notre livre, on a fait un voyage d’écriture de trois semaines en Sicile. Une nuit, on était dans un pub, et là, ils adoptaient un schéma de service assez bizarre : le client devait marcher jusqu’à un serveur, au fin fond de ce long bar, commander sa boisson, pour ensuite revenir à son tabouret et passer son reçu au barman, qui lui apporterait son verre. On a pensé que c’était très étrange, cette manière dont ils modifiaient un service par nature décentralisé en un service centralisé ! Pourquoi, nous nous sommes dits, n’aurait-on pas pu payer directement le barman ?
Quoi qu’il en soit, après quelques verres le bar est devenu plutôt bondé, et on s’est vite rendus compte que ce régime fonctionnait, en faite, plutôt bien. Cela nous a profondément troublés, parce qu’on était là, à réfléchir aux avantages des systèmes décentralisés pour le livre, et ces Siciliens ont complètement contourné l’idée ! On n’avait peut-être rien compris… Peu après, cependant, on a été sauvés par la prise de conscience de deux faits, à savoir : les Italiens, en général, ne boivent pas beaucoup, tandis que ce schéma n’aurait jamais pu marcher, par exemple, en Grande-Bretagne. Mais, le plus important, on a compris que ce n’était pas un système centralisé qu’ils faisaient marcher, mais un système hybride, de courtage : ils centralisaient la découverte, et par conséquence le paiement, mais la part du service qui consistait à fournir des boissons restait décentralisée : permettant l’évolutivité et le passage a l’échelle du mécanisme.
De plus, on a remarqué que pendant la soirée, chaque fois que le caissier s’en allait de son poste pour fumer une cigarette, non seulement un nombre non négligeable de clients s’accumulait, mais aussi, les serveurs achevaient leur dernier ordre et s’en restaient là, en ne faisant absolument rien : tout le système s’arrêtait. Par conséquent, on a conclu que ce pub de Catane avait, en fait, la même taxonomie que les systèmes P2P centralisés de type Napster : découverte centralisée, et donc disponibilité intermittente, sans redondance. Toutefois, en raison de sa communication décentralisée, les services qui avaient été découverts (et payés), pouvaient encore être conclus, normalement. [Taylor & Harrison, 2009 : 205]
84Ce n’est pas l’âme nationaliste de l’auteure qui la porte, dans le but de réaffirmer les qualités de buveur des Italiens par rapport à celles des Britanniques, a retranscrire ici cette anecdote par Ian Taylor et Andrew Harrison, développeurs et co-auteurs d’un populaire manuel sur les technologies P2P pour étudiants en informatique. On laissera la question à des ultérieurs débats d’experts. Par ailleurs, en guise de conclusion de ce chapitre, l’anecdote résume bien l’exploration continue qu’est la mise en opération d’un système P2P : les principaux défis, épreuves et critiques auxquels se trouvent confrontés ses développeurs, face au choix d’introduire un niveau de décentralisation plus ou moins élevé dans un réseau, qu’il doive servir à un moteur de recherche, un partage de fichiers, un réseau social, ou encore des hybrides entre ces applications.
85Comme l’histoire du premier Internet et l’histoire en train de se faire du « nouveau » P2P viennent de le montrer, une architecture P2P est le résultat d’un compromis compliqué entre décentralisation, présence d’intermédiaires, passage à l’échelle, organisation autonome des terminaux/utilisateurs, et résistance aux pannes. La décentralisation peut opérer à plusieurs niveaux, ou bien s’adapter à une couche de l’application et pas à d’autres ; la recherche d’un bon point d’équilibre peut, en fin de compte, ramener à un modèle où l’intermédiation est partiellement présente, tout comme dans l’organisation des serveurs et du système de paiement du bar sicilien.
86Un modèle technique distribué peut signifier un avantage économique pour l’entreprise à ses premiers pas, ou pour un utilisateur qui, en permettant à ses pairs de tirer profit de ses propres ressources matérielles, voit sa qualité de service améliorée – ou encore les deux à la fois. En même temps, le serveur ou le point central du réseau, classiquement défini comme « ordinateur hébergeant un ensemble de logiciels, dont le rôle est de répondre de manière automatique à des demandes envoyées par des clients via le réseau », se voit saisi, mis à l’épreuve, réapproprié, transformé. Il assume tour à tour les rôles de sauvegarde principale de la sureté des données, de garant de la stabilité du dispositif pendant sa phase d’amorçage, ou encore de « délégateur de tâches » centralisé pour un réseau d’utilisateurs/nœuds qui conduit ensuite ses opérations de manière distribuée au sein du dispositif – comme le caissier l’est pour les barmans dans le pub de Catane.
87Les dynamiques de développement d’une architecture définie comme « décentralisée » ou « P2P » montrent la validité de l’intuition d’Andy Oram quand il qualifiait, en 2004, l’architecture P2P comme « ensemble de problèmes aussi bien qu’ensemble de technologies ». Plutôt que la présence ou l’absence d’un ou plusieurs serveurs au sein du système, ce qui qualifie le P2P comme une technologie « décentralisée » est le fait que la responsabilité du réseau – en termes de ressources fournies, de gestion de données, de durabilité du système – se voit poussée, de façon plus ou moins centrale mais toujours fondamentale, aux marges ou à la périphérie de celui-ci.
Notes
26 Le P2P est loin d’être né avec Napster, mais c’est avec ce logiciel que ce modèle de réseau informatique se fait connaître du grand public.
27 L’étiquette « killer application » désigne un programme informatique si attrayant qu’il justifie à lui seul, pour de nombreux consommateurs, l’achat ou l’adoption d’un type particulier d’ordinateur, de système d’exploitation ou d’autre dispositif. En certains cas, il finit par « invalider » les concurrents existants, les contraignant à s’aligner sur ses spécificités ou à disparaître.
28 Et de leur côté, les systèmes à la Freenet évitent délibérément de déléguer aux administrateurs locaux le contrôle sur le contenu de leurs machines car ce contrôle affaiblirait de façon importante les finalités de connexion entre politiques dissidents du système [Langley, 2001].
29 Par ailleurs, l’« ordonnancement » d’un système qui n’avait pas prévu, à l’origine, d’ordre politique a rendu nécessaire la mise en place d’un système de régulation des disputes, Uniform Dispute Resolution Policy (UDRP), organisé sur le modèle du droit des marques, après l’invention du système lui-même. Selon Cécile Méadel et Meryem Marzouki, l’imposition de l’ordre économico-politique qui s’est mis en place avec l’UDRP a « redoublé » les aspects hiérarchiques inscrits dans l’architecture [Méadel & Marzouki, 2005]. Voir [Hancock, 2001] ; [Mueller, 2001, 2002] ; [Musiani, 2009, 47-49].
30 Par exemple SLIP (Serial Line Internet Protocol, ou protocole Internet de liaison en série, protocole de liaison Internet simple n’effectuant ni contrôle d’adresse, ni contrôle d’erreur, permettant l’envoi d’une trame composée uniquement des données à envoyer suivies d’un caractère de fin de transmission) et PPP (Point to Point Protocol, ou protocole point à point, qui autorise un adressage des machines et est doté d’un contrôle d’erreur).
31 Un routeur fait du Network Address Translation (NAT, « traduction d’adresse réseau ») lorsqu’il fait correspondre les adresses IP internes non uniques et souvent non routables d’un intranet à un ensemble d’adresses externes uniques et routables. Ce mécanisme permet notamment de faire correspondre une seule adresse externe publique visible sur Internet à un ensemble d’adresses d’un réseau privé.
32 Un port logiciel (identifié au moyen d’un numéro) permet, sur un ordinateur donné, de distinguer différents « interlocuteurs », c’est-à-dire des programmes informatiques qui, selon les cas, écoutent ou émettent des informations sur ces ports.
33 En informatique, un arbre est une structure de données qui émule une arborescence hiérarchique avec un ensemble de nœuds reliés ; un nœud qui a un descendant est appelé son nœud parent, tandis que les nœuds qui n’ont pas de descendants sont appelés nœuds feuilles ou nœuds terminaux.
© Presses des Mines, 2015