Modélisation d'une application de décentralisation de serveurs web

L'utilisation d'Internet dans notre vie est aujourd'hui devenue quotidienne et indispensable. Au delà de l'accès à des services en ligne gouvernementaux ou commerciaux, Internet a permis à ses utilisateurs de diffuser de l'information accessible par l'ensemble des autres utilisateurs. L'Internet est un réseau qui ne comprend structurellement aucun centre et qui n'introduit aucun hiérarchie parmi les machines connectées et disposant d'adresses IP. On assiste cependant à une asymétrie de plus en plus importante entre les différents opérateurs réseaux. Certains opérateurs Internet se spécialisent dans la fourniture d'accès Internet aux particuliers, alors que d'autres sont spécialisés dans l'hébergement de serveurs et possèdent la majorité du contenu désiré par les internautes. Cela entraîne donc un trafic inter-AS totalement déséquilibré, permettant difficilement à de nouveaux opérateurs de s'interconnecter, en plus de poser des problèmes de concentration de l'information auprès de seulement quelques très grosses entreprises, ce qui soulève des problèmes de vie privée et de contrôle de données numériques. De par les usages, des centres artificiels sont ainsi créés. Le protocole IP étant neutre, il ne différencie pas les paquets provenant de serveurs ou de clients et ne fait que les transporter dans le réseau jusqu'à leur destinataire. L'hébergement sur une connexion Internet à usage personnel est donc possible mais relativement limité puisque la bande passante de ces utilisateurs est relativement faible et ces serveurs supporteraient très mal la montée en charge. Notre projet vise donc à proposer une manière simple et efficace pour un internaute quelconque de partager du contenu en s'affranchissant d'un hébergement en salle machine sauvant par la même occasion les coûts de location associés. Le partage devra s'effectuer de manière transparente pour les clients du site web qui ne changeront nullement leur façon de s'y connecter, tout en offrant une bande passante suffisamment importante pour résister à la montée en charge. Pour ce faire, nous introduirons le concept de partageur, correspondant à un client du site qui, sachant que le site à une capacité d'être partageable, prendra la décision d'installer un logiciel sur son ordinateur. Il permettra ainsi d'absorber une partie de la charge totale du site lorsque son ordinateur sera allumé. Le logiciel en question utilisera la bande passante restante et non utilisée ainsi que l'espace disque que l'internaute a bien voulu lui concéder. Plus le nombre de partageurs est important, plus le site web partagé sera robuste autant en matière de disponibilité qu'en tentative de censure. Nous passerons en revue le fonctionnement de plusieurs protocoles sur lesquels nous nous appuierons par la suite et verrons également des projets se rapprochant de notre solution sans pour autant répondre à nos hypothèses de départ. Par la suite, nous détaillerons l'ensemble des serveurs et logiciels que nous utiliserons et la façon dont ils traiteront les requêtes des clients. L'objectif étant pour les clients de ne pas modifier leur comportement pour récupérer des pages web, nous expliquerons en détail le mécanisme que nous proposerons afin de répartir la charge du site web partagé, sans pour autant introduire de point central dans notre architecture. Nous utiliserons pour cela le protocole DNS, auquel nous couplerons le protocole Kademdlia fonctionnant sur le principe de tables de hachage distribuées. Pour cela, nous présenterons un mécanisme de conversion d'adresses IP en ASCII et inversement et utiliserons les différents types d'enregistrement DNS, comme les délégations de zones et les noms canoniques. Nous verrons ensuite comment nous permettons aux différents partageurs d'alléger le nombre de requêtes leur provenant en distribuant les ressources associées (images, scripts Javascript, feuilles de style\dots) qui seront demandées par les clients, une fois les pages HTML ou les feuilles CSS téléchargées. Pour récupérer initialement les ressources du site, le partageur devra les récupérer par pair-à-pair en utilisant le protocole Bittorent couplé avec Kademlia. Nous continuerons donc par expliquer comment le logiciel pair-à-pair sera calibré, quelles ressources il devra récupérer en priorité et comment il communique avec les autres programmes. Nous finirons notre prototypage par introduire des métriques et des seuils permettant la prise de décision pour les différents serveurs applicatifs. Pour tester notre modèle, nous le comparerons à un une approche client/serveur avec un serveur en salle machine. Le débit, le nombre et la durée de connexion des partageurs dépendent de facteurs externes difficilement modélisables. Nous ferons donc des approximations en utilisant des études statistiques et comparerons les deux modèles sur les débits offerts dans un premier temps avant de nous pencher sur le taux de disponibilité. Les résultats de nos simulations nous montrerons des données encourageantes puisqu'avec un nombre de partageurs raisonnable (inférieur à 100) et un nombre important de clients, nous serons capable d'égaler les performances d'un serveur en salle machine, sur les critères que nous aurons préalablement défini.

Abstract

The use of the Internet in our today's society has become an essential part of our daily life. Not only do we use it by accessing online government web services or commercial websites but also in order to communicate with others. This could be by email, instant messaging or by sharing articles on websites if the targeted audience is aimed to be as big as possible. Everyone has now the ability to share information reachable by anyone on the planet. The Internet is a network with no centre or head that may regulate it. As its name states, it is an inter-network, a collection of thousands of different networks interconnected between each other and using the same protocol called the Internet Protocol (IP). However, we can notice a growing asymmetry between the traffic of the different network operators these days. Some ISP would only focus on targeting end user customers while in the same time, the others would only offer hosting rental plans and have the vast majority of the content that users want. The consequences are a totally unbalanced inter-AS traffic, giving the possibility for new comers to interconnect very difficult, as well as raising concerns about the concentration of all the information by only several companies on privacy and data control issues. By the use of the today's Internet, artificial centres have been created. IP is a neutral protocol that doesn't treat differently packets coming from servers than the ones from clients. Its only job is to carry the packets trough the network to the recipient. Thus, server hosting on a domestic Internet access is possible but rather limited since the usual bandwidth is too low to support scalability. Our project aims to tackle this issue by giving a simple and efficient way for Internet users to share contents without having to host those on a data-centre and in the same time being rid of monthly fees too. Web share will have to be transparent for the end users that will not change their way of sending requests. It also has to offer enough bandwidth to resist scalability. In order to do this, we are going to introduce the notion of sharer. A sharer is a client of the website that took the decision to install a piece of software on his/her computer, knowing that the website offers shared capabilities. All sharers, by doing this, will let clients of the website request contents on their computer when it's turned on. The piece of software will use the remaining bandwidth and the amount of space on the HDD/SSD the user would have let it first. The more the number of sharers is important, the more the shared website will be robust enough in term of availability as well as censorship. We will first see all the detail mechanisms of several interesting protocols that we will use on our solution such as HTTP, DNS as well as the different types of peer-to-peer protocols. We will also look over the different existing projects similar to what we aim to do but without answering to our initial requirements. Then, in the part of the establishment of the model, we will see which software we will use and how we answer client requests. The goal is for the client not to modify their usual behaviour on how they usualy proceed to retrieve web pages. We will then go through a detail explanation on how we manage load balancing between the different sharers without introducing a central point (or SPOF) in our architecture. We will use to answer this question, the DNS protocol that we will peer with the Kademlia protocol using DHT tables. To do this, we will introduce a way to translate IP addresses in ASCII characters and vice versa and we will take advantage of the different records offered by DNS such as zone delegation or canonical names. Then we will see how we manage to lighten the number of resource requests by distributing the associated related resources (such as images, Javascript scripts or CSS sheets) that would be requested by clients when downloads of HTML pages or CSS sheets have been completed. To initially retrieve the resources of the website , the sharers would have to download those on a peer-to-peer network using the Bittorent protocol peered with Kademlia. We will pursue by explaining how we calibrate the peer-to-peer application that we will use, which resources should be downloaded in priority and how it communicates whith the other pieces of software we will be using. Finally, we will introduce metrics and thresholds letting the different servers to take a decision on how they should behave. To evaluate our model, we will compare it to a client/server based server stored in a data-centre. The throughput, the number of sharers and the duration of the connections are external factors difficult to emulate since they are based on human interaction, especially the duration evaluation. We will make approximations and add random factors in our statistic studies in order to make the comparison bewteen our two models on throughput first before going trough disponibily. Our results will show interesting data. With a rather limited number of sharers (under 100) we will be able to reach the same results and quality compared to a server in a data-centre on the critera we will have defined before.