git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
2c8a5fadc
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
projects
fr
lowbandwidth.wml
Add a French page
Mfr
commited
2c8a5fadc
at 2008-07-03 12:25:01
lowbandwidth.wml
Blame
History
Raw
## translation metadata # Based-On-Revision: 15621 #Last-Translator: mfr(ä]misericordia.be #include "head.wmi" TITLE="Projet NLnet: Tor pour clients bas débit" CHARSET="UTF-8" <div class="main-column"> <!-- PUT CONTENT AFTER THIS TAG --> <h2>Projet NLnet: Tor pour clients bas débit</h2> <hr /> <p> Le système Tor anonymat est actuellement uniquement utilisable par les utilisateurs internet qui ont des connexions à haut débit. Dès lancement du client Tor, un grand fichier contenant toutes les descriptions de serveur Tor est téléchargé. Ce fichier, appellé le répertoire de Tor, permet au client de choisir parmi les serveurs de mélange disponibles dans le réseau Tor. Le téléchargement compler du répertoire Tor est requis par le protocole actuel de Tor. Ce répertoire fichier est trop volumineux pour les utilisateurs de modem sur des lignes ou des réseaux de données mobiles comme le GPRS car le téléchargement initial est déclenché à chaque fois qu'un utilisateur se connecte et prend de 10 à 30 minutes sur une ligne lente. En conséquence, Tor n'est pas utilisable par modem et par les utilisateurs mobiles. L'un des principaux objectifs du projet Tor est d'assurer la sécurité des accès anonymes à Internet pour les utilisateurs dans les dictatures et les états répressifs. Ces sites ont souvent de accès internet très lents, soit par modem ou en raison du bas débit des liens vers le monde extérieur. En permettant à ces utilisateurs d'utiliser le réseau Tor, des progrès significatifs peuvent être accomplis en vue de la liberté de communication et d'information dans ces pays. </p> <p> Pour rendre Tor également utilisable pour les utilisateurs de connexions bas débit, une évolution du protocole Tor est nécessaire pour réduire la taille de téléchargement initial. Cette nouvelle version du protocole Tor devrait changer la façon dont un client reçoit les informations pour la création d'un circuit Tor de telle façon, que le téléchargement initial puisse être effectué à partir un ligne avec modem 14,4 kbps en trois minutes environ. Les travaux doivent mener de la proposition à la mise en production finale du protocole et à la diffusion auprès des utilisateurs dans un délai de moins de 12 mois. Le logiciel sera publiée sous la licence BSD 3, comme tout le code Tor. Tous les résultats seront entièrement publics. </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>Due Date</big></th> </tr> </thead> <tr bgcolor="#e5e5e5"> <td> <b>Livrable A:</b>Document de conception et évaluation du changement de protocole<br /> <small><em>Ce livrable couvre la conception détaillée et la simulation fondée sur l'évaluation des changements nécessaires et la conception des modifications au protocole actuel de Tor. Les changements dans le protocole seront relativement important, de sorte qu'ils exigent une évaluation attentive des répercussions possibles pour la sécurité et l'anonymat du réseau Tor. Un délai de deux mois est prévu pour cette conception et d'évaluation, qui se termine par un vaste examen par les pairs. L'objectif d'une partie du livrable A sera la définition de la performance pour la phase de mise en œuvre. L'objectif de conception est de réduire la taille du répertoire Tor qui doit être téléchargé à environ 300 kilo-octets, ce qui permettrait à un utilisateur sur une ligne de 14,4 kbit/s pour le télécharger à peu près trois minutes. Il peut y avoir des exceptions à cet objectif de conception si nécessaire, afin de préserver l'anonymat et la sécurité, mais c'est la valeur à viser. <em></small> </td> <td> 15 juillet 2008 </td> </tr> <tr> <td> <b>Livrable B:</b>Mise en œuvre du changement de protocole<br /> <small><em>Après la conception, l'évaluation par les pairs et les modifications doivent être mises en œuvre et intégrées dans la version actuelle de code de Tor. La mise en œuvre effective des changements nécessaires prendra environ trois mois. </em></small> </td> <td> 15 octobre 2008 </td> </tr> <tr bgcolor="#e5e5e5"> <td> <b>Livrable C:</b>Tests<br /> <small><em>L'aspect très critique de la modification pour la sécurité et l'anonymat du réseau Tor, nécessite de nombreux essais et le débogage en laboratoire et en condtions d'utilisations réelles. Une période de trois mois est prévue 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 novembre 2008 </td> </tr> <tr> <td> <b>Livrable D:</b>Déploiement<br /> <small><em>Le déploiement dans le réseau des serveurs Tor sera réalisé en synchronisation avec le calendier nomral 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. Le déploiement sera effectué dans le cadre du processus de livraison Tor qui est une activité permanente fait par des bénévoles et du personnel payé par d'autres subventions du projet Tor. </em></small> </td> <td> 15 Février 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 juillet 2008 et terminant avec l'achèvement de la mise en oeuvre et les tests de bon fonctionnement le 15 février 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">Jui 08</a> </td> <td> <small><em>Nous n'avons fait une mesure initiale de vitesse des clients Tor. Les résultats ne sont pas très surprenants: un client récupère environ 10 Ko de certificats, un consensus pour 140KB (90KB maintenant, voir le paragraphe suivant), et environ 1,5 Mo de descripteurs de serveurs (et avec la moitié d'entre eux il commence la construction de circuits).</small></em> <br /> <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">La proposition 138</a> qui réduit de 30 à 40% les documents de consensus a déjà été réalisée et fusionnée en les spécifications. La mise en œuvre est en place dans la branche 0.2.1.x-alpha et le code prendra effet une fois de plus des deux-tiers des répertoires autorités (c'est-à-dire 5 sur 6) auront été mis à jour.</small></em> <br /> <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Une proposition 140</a> qui ne se rapporte pas directement à la réduction de la taille du téléchargement initial, mais tente de rendre les nouveaux téléchargements de documents de consensus moins volumineux, a également été rédigée et <a href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">envoyée à or-dev</a>. Il y a des questions auxquelles doivent répondre les autres développeurs de Tor en premier, mais je pense que cela va bien et pourrait être mis en œuvre.</small></em> <br /> <small><em>Le Gros Travail est que les clients ne téléchargent pas tous les 1,5 Mo de descripteurs de serveurs. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt"> Une proposition 141</a> a été <a href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">envoyée à or-dev</a>. Il existe principalement 3 choses à l'intérieur, pour autant que je puisse voir actuellement: déplacer l'équilibrage des informations de charge dans le consensus (ne devrait pas être difficile), mettre en oeuvre quelque chose pour que clients Tor puissent récupérer les DSs à la demande de routeurs le long de leur circuit alors qu'ils sont en train de la construire (décrites dans le projet), et de selectionner le sortie. Nous sommes encore en phase de développement des idées pour cette dernière partie, plusieurs possibilités sont mentionnées dans le projet.</small></em> </td> </tr> <tr> <td> Jul 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> Déc 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">Peter Palfrader</a></li> </ul> --> <!-- In the future, put links to proposal, preliminary results, etc. here --> </div><!-- #main --> #include <foot.wmi>