projects/fr/hidserv.wml (cd98d6c7b) - tor-webwml.git

hidserv.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="NLnet Project: Speed Up Tor Hidden Services" CHARSET="UTF-8"
<div class="main-column">

<h2>Projet NLnet: accélérer les Services Cachés Tor</h2>
<hr />

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.

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.

Ce projet est généreusement financé par:

<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>
 Livrable A: Analyse, mesures et exposé des problèmes 
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.
 </td>
 <td>
 15 juin 2008
 </td>
</tr>

<tr>
 <td>
 Livrable B: Conception et évaluation des changements nécessaires 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.
 </td>
 <td>
 15 août 2008
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Livrable C: Implémentation 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. 
 </td>
 <td>
 15 octobre 2008
 </td>
</tr>

<tr>
 <td>
 Livrable D: Implémentation et tests des changements jusqu'à l'état de
livraison É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.
 </td>
 <td>
 15 janvier 2009
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Livrable E: Déploiement 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.
 </td>
 <td>
 15 mars 2009
 </td>
</tr>
</table>

<a id="Reports"></a>
<h2><a class="anchor" href="#Reports">Rapports mensuels d'avancement</a></h2>

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.

<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>
 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>. 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.
 </td>
</tr>

<tr>
 <td>
 <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a>
 </td>
 <td>
 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.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a>
 </td>
 <td>
 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. 
 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>.
 </td>
</tr>

<tr>
 <td>
 <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 2008</a>
 </td>
 <td>
 Durant la première moitié de la phase d'implémentation, deux bugs
relatifs aux services cachés ont pu être corrigés: <a
href="http://bugs.noreply.org/flyspray/index.php?do=details&amp;id=767">le
premier</a> avait déjà été identifié dans la phase de conception et était
responsable d'un grand taux d'échec lors de la mise en place du service
caché dans le système. Le <a
href="http://bugs.noreply.org/flyspray/index.php?id=814&amp;do=details">second
bug</a> a été trouvé pendant la phase d'implémentation et était responsable
des echecs de connexions à un service caché actif. Ces deux corrections
seront livrées dans la prochaine version instable et probablement incluses
dans une des prochaines versions stables. Les
quatre changements de conception qui ont été proposés ont été implémentés
dans <a
href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">une
branche expérimentale</a> de l'arbre de développement non-stable. Les
premiers tests fonctionnels montrent que ces changements fonctionnent et
permettent de meilleures performances (ressenties). Cela doit être confirmé
au cours des prochaines quatre semaines lors des tests internes. Le prochain
objectif est de de préparer une version de cette branche expérimentale
pouvant être livrée à des beta-testeurs au début de la prochaine phase de
tests.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 2008</a>
 </td>
 <td>
 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.
 </td>
</tr>

<tr>
 <td>
 <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a>
 </td>
 <td>
 Les améliorations de performance qui ont été implémentés lors de
la dernière phase ont été livrés dans la version 0.2.1.7-alpha de Tor. Les
utilisateurs peuvent télécharger cette version de 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&amp;do=details">1</a>,
<a
href="http://bugs.noreply.org/flyspray/index.php?id=814&amp;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. L'objectif principal des 31 derniers
jours s'est concentré 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é un 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. C'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
réduire les effets de ce problème. De plus, il
y a peut-être un <a
href="http://bugs.noreply.org/flyspray/index.php?id=847&amp;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. 
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Dec08"></a> <a class="anchor" href="#Dec08">Décembre 2008</a>
 </td>
 <td>
 Une partie des 30 derniers jours a été consacrée à la correction
de bugs qui ont influencé les dernières mesures sur les services cachés. La
première <a
href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">correction</a>
efface un problème d'erreur de segmentation reponsable en grande partie de
nombreux échecs de mesures. Un autre <a
href="https://bugs.torproject.org/flyspray/index.php?id=847&amp;do=details">bug</a>
était responsable du délai important dans l'amorçage: les autorités
d'annuaire lentes occupaient pendant longtemps l'amorçage des clients avant
que ces derniers abandonnent et utilisent une nouvelle autorité. Par
conséquent, nous avons alloué davantage de bande passante aux deux plus
lentes autorités d'annuaire, de manière à réduire ces désagréments. Un
troisième <a
href="https://bugs.torproject.org/flyspray/index.php?id=874&amp;do=details">bug</a>
a été introduit avec l'amélioration des performances des services cachés de
novembre. L'effet entraîné était que les processus Tor qui faisaient tourner
des services cachés arrêtaient d'annoncer ces services lors de
l'actualisation de leur configuration. De plus, ce bug a révélé que Tor
recréait ces points d'introduction à chaque actualisation ce qui pouvait
affecter la stabilisation des services cachés. Ce bug a été corrigé et sera
inclus dans la version 0.2.1.9-alpha à venir. 
En dehors de la correction de bugs, de nouvelles mesures ont été
effectuées entre le 8 et le 10 décembre. Elles seront probablement les
dernières pour comparer les performances actuelles des services cachés avec
celles du début du projet. Les données n'ont pas complètement été évaluées,
il est donc difficile de faire un jugement sur ces améliorations à ce
stade. Toutefois, une <a
href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">analyse
préliminaire</a> montre que les temps de publication des services ont été
largement améliorés. C'est le résultat d'un amorçage plus rapide des clients
et des améliorations ajoutées en novembre. En revanche, les résultats
concernant l'établissement des connexions vers un service caché sont moins
prometteurs. Un exemple est la récupération des descripteurs de services
afin de rentrer en contact avec un service caché. Une explication possible
est que l'augmentation soudaine du nombre de noeuds d'annuaire de services
cachés au cours du mois de septembre a eut un effet négatif sur les
performances. Une partie du travail de ces 31 derniers jours consistera à
évaluer plus finement ces données et à rendre une conclusion sur
l'achèvement de ce projet.
 </td>
</tr>

<tr>
 <td>
 <a id="Jan09"></a> <a class="anchor" href="#Jan09">Janvier 2009</a>
 </td>
 <td>
 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. 
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. 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.
 </td>
</tr>
</table>

<a id="Links"></a>
<h2><a class="anchor" href="#Links">Liens</a></h2>
<ul>
<li>Papier de recherche sur Mesures de performance et de statistiques sur les
services cachés Tor (<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>

</ul>

</div>

#include <foot.wmi>

tor-webwml.git

updated translations from pootle