git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
9829567ed
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
projects
fr
hidserv.wml
updated translations for the website
Runa A. Sandvik
commited
9829567ed
at 2010-08-18 21:15:21
hidserv.wml
Blame
History
Raw
## translation metadata # Revision: $Revision: 22515 $ # Translation-Priority: 4-optional #include "head.wmi" TITLE="NLnet Project: Speed Up Tor Hidden Services" CHARSET="UTF-8" <div class="main-column"> <!-- PUT CONTENT AFTER THIS TAG --> <h2>Projet NLnet: accélérer les Services Cachés Tor</h2> <hr /> <p> Les services cachés Tor permettent aux utilisateurs de mettre en place des services d'information anonymes tels que des sites web qui peuvent uniquement être accédés à travers le réseau Tor et qui sont protégés contre l'identification des machines qui font tourner le service. Les limites les plus critiquées des services cachés Tor sont le temps nécessaire à l'enregistrement du service dans le réseau et le temps de latence lorsque le client accède au service. En raison de problèmes de conception dans le protocole Tor d'origine, la connexion vers un nouveau service caché peut prendre plusieurs minutes ce qui conduit la majorité des utilisateurs à abandonner avant que la connexion ne se fasse. A cause de cette grande latence dans le circuit des services cachés, il est pratiquement impossible de réaliser des communications interactives d'utilisateur à utilisateur (ex: messagerie instantanée) à l'aide de ces services. </p> <p> Ce projet a pour but d'accélérer d'une part les services cachés Tor en améliorant la manière dont les circuits Tor sont construits entre l'utilisateur et le service et d'autre part, leurs enregistrements dans le réseau Tor. Dans un premier temps, des diagnostics précis sur le comportement des services cachés en conditions de laboratoire ou en conditions réelles seront menés afin de découvrir les causes principales de ces lenteurs. Des stratégies d'optimisation, basées sur ces diagnostics, seront élaborées de manière à éviter les risques de sécurité et d'anonymat dans le réseau Tor. Les optimisations les plus prometteuses seront alors implémentées de manière à améliorer sensiblement les performances pour les utilisateurs. Des mesures précises seront mises en place lors de la phase de diagnostic, une fois que la lumière sera faîte sur les causes de lenteur et sur les améliorations réalistes. L'objectif principal est de réaliser le changement du protocole des services cachés en production et propagé à l'ensemble des utilisateurs Tor dans un pas de temps de moins de 12 mois. </p> <p> Ce projet est généreusement financé par: </p> <p> <a href="http://www.nlnet.nl/news/2008/20080514-awards.html"> <img src="$(IMGROOT)/nlnet-160x60.png" alt="La fondation NLnet" /></a> </p> <table width="100%" border="0" cellspacing="0" cellpadding="3"> <thead> <tr> <th><big>Projet</big></th> <th><big>Date de rendu</big></th> </tr> </thead> <tr bgcolor="#e5e5e5"> <td> <b>Livrable A:</b> Analyse, mesures et exposé des problèmes<br /> <small><em>Etant donné qu'il y a eu peu de développement sur les services cachés Tor au cours des dernières années, certains aspects des problèmes sont sous-diagnostiqués. Il est nécessaire d'effectuer une analyse complète des causes de latence et de perte de temps. Le livrable A nécessite environ un mois de travail. Les résultats de l'analyse influenceront les décisions de conception à prendre pour le livrable B.</em></small> </td> <td> 15 juin 2008 </td> </tr> <tr> <td> <b>Livrable B:</b> Conception et évaluation des changements nécessaires<br /> <small><em>Les changements dans les services cachés Tor affecteront les fonctionnalités au coeur du protocole et imposent une évaluation prudente des possibles répercussion en matière de sécurité et d'anonymat. Une période de deux mois est planifiée pour la phase de conception et d'évaluation qui se conclura par des tests utilisateurs.</em></small> </td> <td> 15 août 2008 </td> </tr> <tr bgcolor="#e5e5e5"> <td> <b>Livrable C:</b> Implémentation<br /> <small><em>Après la conception, l'évaluation et le test utilisateur, les modifications doivent être implémentées et intégrées dans la base actuelle du code source de Tor. Cette implémentation prendra approximativement deux mois. </em></small> </td> <td> 15 octobre 2008 </td> </tr> <tr> <td> <b>Livrable D:</b> Implémentation et tests des changements jusqu'à l'état de livraison<br /> <small><em>Étant donné que la modification est hautement critique en terme de sécurité et de maintient d'anonymat pour le réseau Tor, elle requière des tests et du debugging en conditions de laboratoire et en conditions réelles. Une période de trois mois est planifiée pour ces opérations où le développeur responsable est dévolu à ce travail à 1/3 de son temps. Une partie de la phase de tests sera une période de version beta publique.</em></small> </td> <td> 15 janvier 2009 </td> </tr> <tr bgcolor="#e5e5e5"> <td> <b>Livrable E:</b> Déploiement<br /> <small><em>Le déploiement vers le serveur Tor sur le réseau sera mené en lien avec le calendrier des versions régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre de facteurs externes tels que l'état des autres projets logiciels devant être incorporés dans la version, la date de livraison de la version actuelle et celle où les modifications auront été complètement acceptées et installées par la majorité des opérateurs de serveurs Tor peuvent varier. D'expérience, on peut s'attendre à une période de trois à quatre mois.</em></small> </td> <td> 15 mars 2009 </td> </tr> </table> <br /> <a id="Reports"></a> <h2><a class="anchor" href="#Reports">Rapports mensuels d'avancement</a></h2> <p> Il y aura au total huit rapports mensuels d'état qui commenceront avec le premier livrable aux alentours du 15 juin 2008 et se termineront avec la fin de l'implémentation et des tests aux alentours du 15 janvier 2009. </p> <table width="100%" border="0" cellspacing="0" cellpadding="3"> <thead> <tr> <th><big>Mois,</big></th> <th><big>Rapport d'avancement</big></th> </tr> </thead> <tr bgcolor="#e5e5e5"> <td> <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 2008</a> </td> <td> <small><em>L'objectif d'origine de l'analyse de la lenteur des services cachés Tor a été atteint. Une partie de cette analyse a été de mesurer le temps pour mettre en place ou accéder à un service caché. De plus, on peut maintenant tirer parti des données de mesure d'avril 2008 en vue d'explorer les temps intermédiaires pendant la mise en place d'une connexion vers un service caché. Les résultats sont disponibles dans <a href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">un rapport de 22 pages</a> qui a été rendu public sur <a href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">la liste de diffusion des développeurs Tor</a>.</em></small> <br/> <small><em> L'analyse a également révélé quelques bugs responsables des délais importants avant qu'un service caché soit accessible. Quelques-uns de ces bugs ont été corrigés, les autres le seront bientôt. L'évaluation a amené plusieurs approches pour améliorer la performance des services cachés. Quelques-unes de ces idées peuvent-être appliquées tout de suite alors que d'autres nécessitent davantage d'analyse ainsi que de nouvelles mesures. Finalement, au cours de l'analyse, nous avons découvert que certaines améliorations imposent de profonds changements à Tor qui ne sont pas forcément liés aux services cachés. Ces changement ne pourront intervenir dans le pas de temps prévu pour ce projet.</em></small> </td> </tr> <tr> <td> <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a> </td> <td> <small><em>Tous les bugs trouvés dans l'analyse ont été corrigés. Cela inclut les 2 bugs corrigés pendant l'analyse et 4 autres corrigés dans les 30 derniers jours. Alors que la correction des bugs a supprimé les goulets d'étranglement des performances dûs aux erreurs de programmation, quelques-uns des changements de conception mis en avant au cours de la précédente analyse ont des effets sur l'anonymat ou sur la charge réseau et doivent être expertisés pour vérifier si les gains qu'ils permettent sont valables compte-tenu de leur impact. Un <a href="http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf">rapport</a> a été publié sur <a href="http://archives.seul.org/or/dev/Jul-2008/msg00034.html">la liste de diffusion des développeurs</a> et inclue potentiellement 7 changements de conception devant être débattus. Certaines évaluations (les mesures de faible bande passante et le plan de grande échelle) nécessitent plus de temps que prévu et doivent être planifiées après le livrable B. Le plan actuel consiste à réaliser ces évaluations avant le 15 janvier et à travailler avec des hypothèses avant la publication du résultat final.</em></small> </td> </tr> <tr bgcolor="#e5e5e5"> <td> <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a> </td> <td> <small><em>Durant les 30 derniers jours, les 7 propositions de conception ont été mieux évaluées et débattues. Quatre d'entre-elles se sont montrées réalisables en terme de changement de code et de respect de l'anonymat. Une a été classée comme bug plutôt que comme changement de conception. Deux ont dû être exclues car elles menaient à des problèmes de sécurité ou à des incertitudes dans l'amélioration des performances.</em></small> <br/> <small><em> Selon les résultats du 15 juillet, la phase de conception est terminée. Les tâches à venir pour la phase d'implémentation sont maintenant clairement définies: un bug doit être corrigé et quatre changements de conception doivent être implémentés. De plus, il faudra réaliser des évaluations des changements de conception afin de vérifier leur utilité. Un <a href="http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf">rapport</a> contenant les résultats de la phase de conception a été publié sur <a href="http://archives.seul.org/or/dev/Aug-2008/msg00025.html">la liste de diffusion des développeurs</a>.</em></small> </td> </tr> <tr> <td> <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 2008</a> </td> <td> <small><em>During the first half of the implementation phase two bugs could be fixed that were related to hidden services: the <a href="https://trac.torproject.org/projects/tor/ticket/767">first bug</a> has already been identified in the design phase and was responsible for an unusual high failure rate when making a hidden service available in the system; the <a href="https://trac.torproject.org/projects/tor/ticket/814">second bug</a> was found during the implementation phase and was responsible for failure to connect to a working hidden service. Both bugfixes will be included in the next unstable version and likely be backported to one of the next stable releases.</em></small> <br/> <small><em>The four design changes that were proposed as result of the design phase have been implemented in an <a href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">experimental branch</a> of the unstable development tree. Early function tests have shown that these changes work and provide better (perceived) performance. This needs to be confirmed throughout the next four weeks in internal tests. The next goal is to prepare a release of this experimental branch that can be given out to beta testers at the beginning of the upcoming testing phase.</em></small> </td> </tr> <tr bgcolor="#e5e5e5"> <td> <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 2008</a> </td> <td> <small><em>La phase d'implémentation est terminée. Les corrections de bugs trouvés lors des 30 derniers jours ont été ajoutées dans la version de développement <a href="http://archives.seul.org/or/talk/Oct-2008/msg00093.html">0.2.1.6-alpha</a>. Les quatre changements de conception qui ont été identifiés lors de la phase de conception ont été décrits dans <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt">la proposition 155</a>. Trois changements de conception ont été ajoutés au code de développement et seront automatiquement injectés dans la prochaine version de développement. Les deux premiers améliorent l'établissement de la connexion à un service caché en réduisant le temps nécessaire à cette opération de 60 à 30 secondes tout en lançant un deuxième essai en parallèle après 15 secondes. Le troisième changement concerne la publication d'un service caché dans le réseau en annonçant le service à 5 au lieu de 3 points dans le réseau en parallèle et en considérant la publication valide dès que les 3 points sont atteints. Maintenant, il n'y a plus de bugs ni de nouveaux concepts. Tous les changements sont dans le code source et peuvent être testés dans la prochaine phase.</em></small> </td> </tr> <tr> <td> <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a> </td> <td> <small><em>Les améliorations de performance qui ont été implémentées lors de la dernière phase ont été livrées dans la version 0.2.1.7-alpha de Tor. Les utilisateurs peuvent télécharger cette version en développement depuis la page d'accueil de Tor et tester ainsi les améliorations au prix d'un effort minime. De plus, deux corrections de bugs (<a href="http://bugs.noreply.org/flyspray/index.php?id=767&do=details">1</a>, <a href="http://bugs.noreply.org/flyspray/index.php?id=814&do=details">2</a>) qui avaient été découverts au cours de ce projet ont été rétroportées dans la branche stable et seront incluses dans la prochaine version stable 0.2.0.31.</em></small> <br/> <small><em>L'objectif principal des 31 derniers jours a été de se concentrer sur de nouvelles mesures afin de vérifier l'état des améliorations. Les mesures se sont déroulées sur deux jours entre le 6 et le 8 novembre. Malheureusement, le réseau Tor a connu un problème sérieux pendant cette période: un certificat périmé d'une autorité d'annuaire a provoqué une grande quantité de trafic au sein du réseau Tor ce qui a <a href="http://archives.seul.org/or/talk/Nov-2008/msg00053.html">forcé un grand nombre d'opérateurs à fermer leur relais</a>. Une seconde mesure a été réalisée entre le 13 et le 15. Les données brutes sont disponibles <a href="http://freehaven.net/~karsten/hidserv/perfdata-2008-11-13.tar.gz">ici</a> (40Mo). Néanmoins, les résultats montrent que les performances globales du réseau sont encore plus mauvaises qu'au mois de juin 2008, date de la première mesure sur les services cachés. Ceci est visible quand on observe les requêtes vers les annuaires Tor qui n'ont pas été touchées par les améliorations et qui montrent une performance plus mauvaise qu'auparavant. Les effets sur l'amélioration des performances sont bien visibles même si les valeurs absolues ne sont pas comparables pour le moment. De nouvelles mesures seront lancées en décembre dans l'espoir de voir les effets de ce problème réduits.</em></small> <br/> <small><em>De plus, il y a peut-être un <a href="http://bugs.noreply.org/flyspray/index.php?id=847&do=details">bug</a> dans la manière dont Tor télécharge les informations d'annuaire pendant l'amorçage. Même si cela n'est pas lié aux services cachés, une amélioration de ce côté profiterait quand même à ces derniers. Une partie du travail pour les 30 jours à venir concernera ce bug. </em></small> </td> </tr> <tr bgcolor="#e5e5e5"> <td> <a id="Dec08"></a> <a class="anchor" href="#Dec08">Décembre 2008</a> </td> <td> <small><em>Part of the last 30 days has been used to fix bugs that have influenced the previous hidden service measurements. The first <a href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">bugfix</a> corrects a possible segmentation fault that was very likely responsible for a number of failed measurement runs. Another <a href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> could be explained that lead to significant delays in bootstrapping: Very slow directory authorities occupied bootstrapping clients for a long time before clients finally gave up and bootstrapped using another authority. As a result, the slowest two directory authorities have dedicated more bandwidth to their nodes, so that the effect is mitigated. A third <a href="https://trac.torproject.org/projects/tor/ticket/874">bug</a> has been introduced with the hidden service performance improvements in November; the effect was that Tor processes running hidden services would stop advertising their service upon reloading their configuration. Further, this bug has uncovered that Tor has re-established its introduction points upon reloading, which might have affected hidden service stability. This bug has been fixed and will be included in the upcoming version 0.2.1.9-alpha.</em></small> <br/> <small><em>Apart from fixing bugs, new measurements have been performed between December 8 and 10. These will very likely be the final measurements to compare hidden service performance now with the beginning of the project. The data have not been completely evaluated, so it is difficult to make a statement about improvements at this point. However, a <a href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">preliminary evaluation</a> shows that service publication times have improved significantly. This is a result of Tor clients bootstrapping faster and of the performance improvements added in November. In contrast to this, the results for establishing a connection to a hidden service are less promising. While the improvements added in November seem to have a positive effect on performance, some substeps exhibit significantly worse performance. One example is fetching hidden service descriptors in order to contact a hidden service. A possible explanation is that the sudden increase in the number of hidden service directory nodes in September has had a negative effect on performance. Part of the work in the final 31 days will be to evaluate these data in more detail and make a final conclusion on the achievements of this project.</em></small> </td> </tr> <tr> <td> <a id="Jan09"></a> <a class="anchor" href="#Jan09">Janvier 2009</a> </td> <td> <small><em>La phase de test est terminée. Ces tests ont été menés en tant que phase de beta-test publique incluant tout les changements concernant les service cachés dans la série 0.2.1.x-alpha. Suite à ces tests, deux bugs ont été identifiés, il peuvent d'ores et déjà être corrigés.</em></small> <br/> <small><em>Les autres tests ont servi de mesures et ont été menés en décembre. Une <a href="http://freehaven.net/~karsten/hidserv/comparison-2009-01-15.pdf">comparaison</a> des mesures effectuées successivement en juin et en décembre a montré que les changements dûs à ce projet sont efficaces. En moyenne, le temps de publication du service est passé de 2 minutes 12 à 58 secondes. Cette amélioration dépasse les attentes. Grâce à cette amélioration, il est également envisageable de réduire le temps de stabilisation de 30 secondes à une valeur plus faible dans le futur. Toutefois, l'établissement de la connexion reste aux alentours de 56 secondes entre la requête et la connexion au serveur caché. La principale cause de ce problème est le passage d'un stockage centralisé des descripteurs de services cachés à une forme décentralisée. Cet effet de détérioration de la distribution de l'annuaire des services cachés n'avait pas été envisagé jusqu'à présent. Un travail futur devrait se focaliser sur l'amélioration du téléchargement de l'annuaire distribué des services cachés par exemple, en parallélisant les requêtes.</em></small> <br/> <small><em>Ce rapport est le dernier de la série. Le déploiement de la série 0.2.1.x qui inclue les améliorations des services cachés devrait se dérouler dans les prochaines semaines ou prochains mois.</em></small> </td> </tr> </table> <!-- Do we want a people section? If so, would it make sense to write what these people will be doing? And what exactly are these people going to do? :) <a id="People"> </a> <h2><a class="anchor" href="#People">People</a></h2> <ul> <li><a href="<page people>#Core">Karsten Loesing</a></li> <li><a href="<page people>#Core">Steven Murdoch</a></li> </ul> --> <br /> <a id="Links"></a> <h2><a class="anchor" href="#Links">Liens</a></h2> <ul> <li>Papier de recherche sur <b>Mesures de performance et de statistiques sur les services cachés Tor</b> (<a href="http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/loesing2008performance.pdf">PDF</a>) par Karsten Loesing, Werner Sandmann, Christian Wilms, and Guido Wirtz. Dans the Proceedings of the 2008 International Symposium on Applications and the Internet (SAINT), Turku, Finlande juillet 2008.</li> <!-- In the future, put links to proposal, preliminary results, etc. here --> </ul> </div> #include <foot.wmi>