projects/fr/lowbandwidth.wml (a6503afbe) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Based-On-Revision: 15959
#Last-Translator: mfr(ä]misericordia.be

#include "head.wmi" TITLE="Projet NLnet: Tor pour clients bas débit" CHARSET="UTF-8"

<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 complet 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>

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

<tr>
  <td>
			<a id="Jul08"></a>
			<a class="anchor" href="#Jul08">Juil 08</a>
  </td>
  <td>
				<small><em>La travail sur la <a
    href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposition
    141</a> continue:  Il y a principalement deux idées sur la façon de 
				déplacer les informations d'équilibrage de charge dans le consensus: 
				la première est que les autorités générent le poids que les clients 
				doivent utiliser et le mettre dans le consensus, 
				l'autre approche est de mettre juste les informations de bande passante
				du descriteur du serveur. Cette dernière option est probablement 
				plus pratique si l'on considère également la <a
    href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposition
    140</a> qui évite d'avoir un nombre très fluctuant dans le consensus.</em></small>
    <br />
    <small><em>Pour la gestion des politiques de sortie <a
    href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">un
    message sur la liste or-dev</a> propose qu'un hash identifie une 
				politique de sortie ajoutée au document de consensus. L'addition
				de 160 bits aléatoires par noeud au consensus pourrait être un 
				souci mais comme nous pensons qu'un grand nombre de politiques 
				de sorties sont identiques, le document de consensus sera compressé 
				efficacement. Des mesures sont en attente.</em></small>
  </td>
</tr>

<br />

</div>

#include <foot.wmi>

tor-webwml.git

Maintenance French Translation