git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
20b8263f4
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
projects
fr
hidserv.wml
Add a French page
Mfr
commited
20b8263f4
at 2008-07-06 19:55:27
hidserv.wml
Blame
History
Raw
## translation metadata # Based-On-Revision: 15630 #Last-Translator: mfr(�]misericordia.be #include "head.wmi" TITLE="NLnet Project: Acc�l�rer les Services Cach�s de Tor" CHARSET="UTF-8" <div class="main-column"> <!-- PUT CONTENT AFTER THIS TAG --> <h2>Projet NLnet: Acc�l�rer les Services Cach�s de Tor</h2> <hr /> <p> Les services cach�s de Tor permettent aux utilisateurs de mettre en place des services d'information anonymes, tels des sites web, qui ne peuvent �tre accessibles que par le r�seau Tor et sont prot�g�s contre l'identification de l'h�te qui ex�cute ce service. Les limitations les plus critiques des services cach�s de Tor sont le temps qu'il faut jusqu'� un service cach� soit enregistr� dans le r�seau et le temps de r�ponse lorsque d'une consultation par un utilisateur. En raison de probl�mes de conception dans le protocole original Tor, la connexion � un nouveau service cach� peut prendre plusieurs minutes, ce qui conduit la plupart des utilisateurs � abandonner avant la connexion ai �t� �tablie. L'usage des services cach�s de Tor pour des services de communication interactif d'utilisateurs � utilisateurs (messagerie par exemple) est presque impossible en raison du long temps de r�ponse lors de la mise en place du circuit du service cach�. </p> <p> Ce projet vise � acc�l�rer Tor les services cach�s par l'am�lioration de la mani�re dont les circuits Tor sont mis en place entre l'utilisateur et le service cach�, ainsi que la mani�re dont un service cach� est enregistr� dans le r�seau Tor. Dans une premi�re �tape, un diagnostic pr�cis du comportement des services cach�s en laboratoire et en situation r�elle sera effectu� pour trouver les causes profondes des mauvaises performances. Sur la base de ces diagnostics, des strat�gies d'optimisation seront con�ues et avec v�rification des effets ind�sirables sur la s�curit� et l'anonymat du R�seau Tor. Les optimisations les plus promettrices seront ensuite mises en �uvre pour atteindre une am�lioration notable pour les utilisateurs. Des mesures pr�cises de succ�s seront d�velopp�es dans la phase de diagnostic, afin que soit visible o� du temps est perdu et o� des am�liorations sont r�alistes. Le but ultime est d'avoir un changement du protocole des services cach�s en production pr�t et diffus� aux utilisateurs de Tor dans un d�lai 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="The NLnet foundation" /></a> </p> <table width="100%" border="0" cellspacing="0" cellpadding="3"> <thead> <tr> <th><big>Projet</big></th> <th><big>Date de Livraison</big></th> </tr> </thead> <tr bgcolor="#e5e5e5"> <td> <b>Livrable A:</b> Analyse, mesures et clarification des probl�mes<br /> <small><em>Comme les services cach�s de Tor n'ont �t� activement mis au point que depuis la derni�re ann�e du d�veloppement de Tor, certains aspects de des probl�mes ont �t� sous-analys�s. Pour identifier les sources pr�cises de temps de r�ponse et des pertes de temps, une analyse approfondie des raisons plus profondes pour de ces �l�ments n�cessite d'�tre effectu�e. Ce livrable, n�cessitera environ un mois de travail. Les r�sultats de l'analyse auront une influence sur les d�cisions de conception � prendre dans Livrable B.</em></small> </td> <td> 15 Juin 2008 </td> </tr> <tr> <td> <b>Livrable B:</b> Conception et �valuation des modifications n�cessaires<br /> <small><em>Les modifications apport�es aux services cach�s de Tor auront une incidence sur le fonctionnement des services de base du protocole et, par cons�quent, exigent une �valuation attentive des r�percussions possibles pour la s�curit� et l'anonymat. Un d�lai de deux mois est pr�vu pour la conception et la phase d'�valuation, qui se terminera par un vaste examen par les pairs. </em></small> </td> <td> 15 Aout 2008 </td> </tr> <tr bgcolor="#e5e5e5"> <td> <b>Livrable C:</b> Mise en �uvre<br /> <small><em>Apr�s la conception, l'�valuation et l'examen par les pairs les modifications doivent �tre mises en �uvre et int�gr�e avec le code pricipal de Tor. La mise en �uvre effective des changements n�cessaires prendra environ deux mois.</em></small> </td> <td> 15 Octobre 2008 </td> </tr> <tr> <td> <b>Livrable D:</b> Mise en �uvre et conduite du changement jusqu'� la livraison<br /> <small><em>Cette modification est tr�s critique pour la s�curit� et de l'anonymat le r�seau Tor, elle n�cessite de nombreux essais et d�bogage en laboratoire et en r�el. Une p�riode de trois mois est pr�vu pour tester et d�boguer, o� le d�veloppeur responsable passera 1/3 de son temps � des essais. Une partie de la phase d'essai sera une p�riode de b�ta 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 dans le r�seau des serveurs Tor sera r�alis� en synchronisation avec le calendrier normal de diffusion de Tor. Comme ce calendrier d�pend d'un certain nombre de facteurs externes, tel que l'ach�vement d'autres projets de logiciels qui devraient aller dans le m�me livraison, la date de sortie effective et la date auquelle cette version a �t� accept� et install� par la plupart des op�rateurs de serveur Tor peuvent varier. D'exp�rience une p�riode de trois � quatre mois peut �tre pr�vue.</em></small> </td> <td> 15 Mai 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 de situation en commen�ant par le premier livrable le 15 juin 2008 et terminant avec l'ach�vement de la mise en oeuvre et les tests de bon fonctionnement le 15 janvier 2009. </p> <table width="100%" border="0" cellspacing="0" cellpadding="3"> <thead> <tr> <th><big>Mois,</big></th> <th><big>Rapport d'activit�</big></th> </tr> </thead> <tr bgcolor="#e5e5e5"> <td> <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 08</a> </td> <td> <small><em>L'objectif initial d'analyser les probl�mes qui conduisent au ralentissement des services cach�s de Tor a �t� accompli. Une partie de ces analyses a mesur� que le retard que l'utilisateur subit lors de la mise en place ou de l'acc�s � un service cach�. En outre, les donn�es de mesure d'avril 2008 pourrait �tre un moyen pour explorer les d�lais internes d'�tablissement d'une connexion � un service cach�. Les r�sultats de cette analyse sont contenues dans un <a href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">rapport</a> de 22 pages qui a �t� rendu public sur la <a href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">liste de diffusion des developpeurs</a> de Tor.</em></small> <br/> <small><em>L'analyse a aussi d�voil� quelques bogues qui sont responsables en partie du retard dans la mise en service du service cach� pour les clients. Quelques bogues ont �t� corrig�s � la suite de l'analyse, d'autres le seront prochainement. L'�valuation a en outre mis en place plusieurs les approches possibles pour am�liorer la performance du service cach� Tor. Certains de ces id�es peuvent �tre appliqu�es imm�diatement, tandis que d'autres exigent une analyse plus profonde et de nouvelles mesures. Enfin, au cours de l'analyse, nous avons d�couvert que certaines am�liorations n�cessitent des modification plus profondes de Tor, qui ne sont pas directement li�es aux services cach�s. Ces changements ne peuvent pas �tre r�alis�s dans les d�lais de ce projet.</em></small> </td> </tr> <tr> <td> Juil 08 </td> <td> </td> </tr> <tr bgcolor="#e5e5e5"> <td> Aou 08 </td> <td> </td> </tr> <tr> <td> Sep 08 </td> <td> </td> </tr> <tr bgcolor="#e5e5e5"> <td> Oct 08 </td> <td> </td> </tr> <tr> <td> Nov 08 </td> <td> </td> </tr> <tr bgcolor="#e5e5e5"> <td> Dec 08 </td> <td> </td> </tr> <tr> <td> Jan 09 </td> <td> </td> </tr> </table> <br /> <!-- 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> --> <a id="Links"></a> <h2><a class="anchor" href="#Links">Liens</a></h2> <ul> <li>Research paper on <b>Performance Measurements and Statistics of Tor Hidden Services</b> (<a href="http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/loesing2008performance.pdf">PDF</a>) by Karsten Loesing, Werner Sandmann, Christian Wilms, and Guido Wirtz. In the Proceedings of the 2008 International Symposium on Applications and the Internet (SAINT), Turku, Finland, July 2008. <!-- In the future, put links to proposal, preliminary results, etc. here --> </ul> </div><!-- #main --> #include <foot.wmi>