updated translations for th...
Runa A. Sandvik authored 13 years ago
|
9) # Translation-Priority: 4-optional
10) #include "head.wmi" TITLE="NLnet Project: Speed Up Tor Hidden Services" CHARSET="UTF-8"
11) <div class="main-column">
12)
13)
14)
15) <!-- PUT CONTENT AFTER THIS TAG -->
16) <h2>Projet NLnet: accélérer les Services Cachés Tor</h2>
17) <hr />
18)
19) <p>
20) Les services cachés Tor permettent aux utilisateurs de mettre en place des
21) services d'information anonymes tels que des sites web qui peuvent
22) uniquement être accédés à travers le réseau Tor et qui sont protégés contre
23) l'identification des machines qui font tourner le service. Les limites les
24) plus critiquées des services cachés Tor sont le temps nécessaire à
25) l'enregistrement du service dans le réseau et le temps de latence lorsque le
26) client accède au service. En raison de problèmes de conception dans le
27) protocole Tor d'origine, la connexion vers un nouveau service caché peut
28) prendre plusieurs minutes ce qui conduit la majorité des utilisateurs à
29) abandonner avant que la connexion ne se fasse. A cause de cette grande
30) latence dans le circuit des services cachés, il est pratiquement impossible
31) de réaliser des communications interactives d'utilisateur à utilisateur (ex:
32) messagerie instantanée) à l'aide de ces services.
33) </p>
34)
35) <p>
36) Ce projet a pour but d'accélérer d'une part les services cachés Tor en
37) améliorant la manière dont les circuits Tor sont construits entre
38) l'utilisateur et le service et d'autre part, leurs enregistrements dans le
39) réseau Tor. Dans un premier temps, des diagnostics précis sur le
40) comportement des services cachés en conditions de laboratoire ou en
41) conditions réelles seront menés afin de découvrir les causes principales de
42) ces lenteurs. Des stratégies d'optimisation, basées sur ces diagnostics,
43) seront élaborées de manière à éviter les risques de sécurité et d'anonymat
44) dans le réseau Tor. Les optimisations les plus prometteuses seront alors
45) implémentées de manière à améliorer sensiblement les performances pour les
46) utilisateurs. Des mesures précises seront mises en place lors de la phase de
47) diagnostic, une fois que la lumière sera faîte sur les causes de lenteur et
48) sur les améliorations réalistes. L'objectif principal est de réaliser le
49) changement du protocole des services cachés en production et propagé à
50) l'ensemble des utilisateurs Tor dans un pas de temps de moins de 12 mois.
51) </p>
52)
53) <p>
54) Ce projet est généreusement financé par:
55) </p>
56)
57) <p>
58) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html"> <img
59) src="$(IMGROOT)/nlnet-160x60.png" alt="La fondation NLnet" /></a>
60) </p>
61)
62) <table width="100%" border="0" cellspacing="0" cellpadding="3">
63) <thead>
64) <tr>
65) <th><big>Projet</big></th>
66) <th><big>Date de rendu</big></th>
67) </tr>
68) </thead>
69)
70) <tr bgcolor="#e5e5e5">
71) <td>
72) <b>Livrable A:</b> Analyse, mesures et exposé des problèmes<br />
73) <small><em>Etant donné qu'il y a eu peu de développement sur les services
74) cachés Tor au cours des dernières années, certains aspects des problèmes
75) sont sous-diagnostiqués. Il est nécessaire d'effectuer une analyse complète
76) des causes de latence et de perte de temps. Le livrable A nécessite environ
77) un mois de travail. Les résultats de l'analyse influenceront les décisions
78) de conception à prendre pour le livrable B.</em></small>
79) </td>
80) <td>
81) 15 juin 2008
82) </td>
83) </tr>
84)
85) <tr>
86) <td>
87) <b>Livrable B:</b> Conception et évaluation des changements nécessaires<br
88) /> <small><em>Les changements dans les services cachés Tor affecteront les
89) fonctionnalités au coeur du protocole et imposent une évaluation prudente
90) des possibles répercussion en matière de sécurité et d'anonymat. Une période
91) de deux mois est planifiée pour la phase de conception et d'évaluation qui
92) se conclura par des tests utilisateurs.</em></small>
93) </td>
94) <td>
95) 15 août 2008
96) </td>
97) </tr>
98)
99) <tr bgcolor="#e5e5e5">
100) <td>
101) <b>Livrable C:</b> Implémentation<br /> <small><em>Après la conception,
102) l'évaluation et le test utilisateur, les modifications doivent être
103) implémentées et intégrées dans la base actuelle du code source de Tor. Cette
104) implémentation prendra approximativement deux mois. </em></small>
105) </td>
106) <td>
107) 15 octobre 2008
108) </td>
109) </tr>
110)
111) <tr>
112) <td>
113) <b>Livrable D:</b> Implémentation et tests des changements jusqu'à l'état de
114) livraison<br /> <small><em>Étant donné que la modification est hautement
115) critique en terme de sécurité et de maintient d'anonymat pour le réseau Tor,
116) elle requière des tests et du debugging en conditions de laboratoire et en
117) conditions réelles. Une période de trois mois est planifiée pour ces
118) opérations où le développeur responsable est dévolu à ce travail à 1/3 de
119) son temps. Une partie de la phase de tests sera une période de version beta
120) publique.</em></small>
121) </td>
122) <td>
123) 15 janvier 2009
124) </td>
125) </tr>
126)
127) <tr bgcolor="#e5e5e5">
128) <td>
129) <b>Livrable E:</b> Déploiement<br /> <small><em>Le déploiement vers le
130) serveur Tor sur le réseau sera mené en lien avec le calendrier des versions
131) régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre
132) de facteurs externes tels que l'état des autres projets logiciels devant
133) être incorporés dans la version, la date de livraison de la version actuelle
134) et celle où les modifications auront été complètement acceptées et
135) installées par la majorité des opérateurs de serveurs Tor peuvent
136) varier. D'expérience, on peut s'attendre à une période de trois à quatre
137) mois.</em></small>
138) </td>
139) <td>
140) 15 mars 2009
141) </td>
142) </tr>
143) </table>
144)
145) <br /> <a id="Reports"></a>
146) <h2><a class="anchor" href="#Reports">Rapports mensuels d'avancement</a></h2>
147) <p>
148) Il y aura au total huit rapports mensuels d'état qui commenceront avec le
149) premier livrable aux alentours du 15 juin 2008 et se termineront avec la fin
150) de l'implémentation et des tests aux alentours du 15 janvier 2009.
151) </p>
152)
153) <table width="100%" border="0" cellspacing="0" cellpadding="3">
154) <thead>
155) <tr>
156) <th><big>Mois,</big></th>
157) <th><big>Rapport d'avancement</big></th>
158) </tr>
159) </thead>
160)
161) <tr bgcolor="#e5e5e5">
162) <td>
163) <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 2008</a>
164) </td>
165) <td>
166) <small><em>L'objectif d'origine de l'analyse de la lenteur des services
167) cachés Tor a été atteint. Une partie de cette analyse a été de mesurer le
168) temps pour mettre en place ou accéder à un service caché. De plus, on peut
169) maintenant tirer parti des données de mesure d'avril 2008 en vue d'explorer
170) les temps intermédiaires pendant la mise en place d'une connexion vers un
171) service caché. Les résultats sont disponibles dans <a
172) href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">un
173) rapport de 22 pages</a> qui a été rendu public sur <a
174) href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">la liste de
175) diffusion des développeurs Tor</a>.</em></small> <br/> <small><em> L'analyse
176) a également révélé quelques bugs responsables des délais importants avant
177) qu'un service caché soit accessible. Quelques-uns de ces bugs ont été
178) corrigés, les autres le seront bientôt. L'évaluation a amené plusieurs
179) approches pour améliorer la performance des services cachés. Quelques-unes
180) de ces idées peuvent-être appliquées tout de suite alors que d'autres
181) nécessitent davantage d'analyse ainsi que de nouvelles mesures. Finalement,
182) au cours de l'analyse, nous avons découvert que certaines améliorations
183) imposent de profonds changements à Tor qui ne sont pas forcément liés aux
184) services cachés. Ces changement ne pourront intervenir dans le pas de temps
185) prévu pour ce projet.</em></small>
186) </td>
187) </tr>
188)
189) <tr>
190) <td>
191) <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a>
192) </td>
193) <td>
194) <small><em>Tous les bugs trouvés dans l'analyse ont été corrigés. Cela
195) inclut les 2 bugs corrigés pendant l'analyse et 4 autres corrigés dans les
196) 30 derniers jours. Alors que la correction des bugs a supprimé les goulets
197) d'étranglement des performances dûs aux erreurs de programmation,
198) quelques-uns des changements de conception mis en avant au cours de la
199) précédente analyse ont des effets sur l'anonymat ou sur la charge réseau et
200) doivent être expertisés pour vérifier si les gains qu'ils permettent sont
201) valables compte-tenu de leur impact. Un <a
202) href="http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf">rapport</a>
203) a été publié sur <a
204) href="http://archives.seul.org/or/dev/Jul-2008/msg00034.html">la liste de
205) diffusion des développeurs</a> et inclue potentiellement 7 changements de
206) conception devant être débattus. Certaines évaluations (les mesures de
207) faible bande passante et le plan de grande échelle) nécessitent plus de
208) temps que prévu et doivent être planifiées après le livrable B. Le plan
209) actuel consiste à réaliser ces évaluations avant le 15 janvier et à
210) travailler avec des hypothèses avant la publication du résultat
211) final.</em></small>
212) </td>
213) </tr>
214)
215) <tr bgcolor="#e5e5e5">
216) <td>
217) <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a>
218) </td>
219) <td>
220) <small><em>Durant les 30 derniers jours, les 7 propositions de conception
221) ont été mieux évaluées et débattues. Quatre d'entre-elles se sont montrées
222) réalisables en terme de changement de code et de respect de l'anonymat. Une
223) a été classée comme bug plutôt que comme changement de conception. Deux ont
224) dû être exclues car elles menaient à des problèmes de sécurité ou à des
225) incertitudes dans l'amélioration des performances.</em></small> <br/>
226) <small><em> Selon les résultats du 15 juillet, la phase de conception est
227) terminée. Les tâches à venir pour la phase d'implémentation sont maintenant
228) clairement définies: un bug doit être corrigé et quatre changements de
229) conception doivent être implémentés. De plus, il faudra réaliser des
230) évaluations des changements de conception afin de vérifier leur utilité. Un
231) <a
232) href="http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf">rapport</a>
233) contenant les résultats de la phase de conception a été publié sur <a
234) href="http://archives.seul.org/or/dev/Aug-2008/msg00025.html">la liste de
235) diffusion des développeurs</a>.</em></small>
236) </td>
237) </tr>
238)
239) <tr>
240) <td>
241) <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 2008</a>
242) </td>
243) <td>
|
|
new and updated translation...
Runa A. Sandvik authored 13 years ago
|
244) <small><em>Durant la première moitié de la phase d'implémentation, deux bugs
245) relatifs aux services cachés ont pu être corrigés: <a
246) href="https://trac.torproject.org/projects/tor/ticket/767">le premier</a>
247) avait déjà été identifié dans la phase de conception et était responsable
248) d'un grand taux d'échec lors de la mise en place du service caché dans le
249) système. Le <a
250) href="https://trac.torproject.org/projects/tor/ticket/814">second bug</a> a
251) été trouvé pendant la phase d'implémentation et était responsable des echecs
252) de connexions à un service caché actif. Ces deux corrections seront livrées
253) dans la prochaine version instable et probablement incluses dans une des
254) prochaines versions stables.</em></small> <br/> <small><em>Les quatre
255) changements de conception qui ont été proposés ont été implémentés dans <a
256) href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">une
257) branche expérimentale</a> de l'arbre de développement non-stable. Les
258) premiers tests fonctionnels montrent que ces changements fonctionnent et
259) permettent de meilleures performances (ressenties). Cela doit être confirmé
260) au cours des prochaines quatre semaines lors des tests internes. Le prochain
261) objectif est de de préparer une version de cette branche expérimentale
262) pouvant être livrée à des beta-testeurs au début de la prochaine phase de
263) tests.</em></small>
|
|
updated translations for th...
Runa A. Sandvik authored 13 years ago
|
264) </td>
265) </tr>
266)
267) <tr bgcolor="#e5e5e5">
268) <td>
269) <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 2008</a>
270) </td>
271) <td>
272) <small><em>La phase d'implémentation est terminée. Les corrections de bugs
273) trouvés lors des 30 derniers jours ont été ajoutées dans la version de
274) développement <a
275) href="http://archives.seul.org/or/talk/Oct-2008/msg00093.html">0.2.1.6-alpha</a>.
276) Les quatre changements de conception qui ont été identifiés lors de la phase
277) de conception ont été décrits dans <a
278) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt">la
279) proposition 155</a>. Trois changements de conception ont été ajoutés au
280) code de développement et seront automatiquement injectés dans la prochaine
281) version de développement. Les deux premiers améliorent l'établissement de la
282) connexion à un service caché en réduisant le temps nécessaire à cette
283) opération de 60 à 30 secondes tout en lançant un deuxième essai en parallèle
284) après 15 secondes. Le troisième changement concerne la publication d'un
285) service caché dans le réseau en annonçant le service à 5 au lieu de 3 points
286) dans le réseau en parallèle et en considérant la publication valide dès que
287) les 3 points sont atteints. Maintenant, il n'y a plus de bugs ni de
288) nouveaux concepts. Tous les changements sont dans le code source et peuvent
289) être testés dans la prochaine phase.</em></small>
290) </td>
291) </tr>
292)
293) <tr>
294) <td>
295) <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a>
296) </td>
297) <td>
298) <small><em>Les améliorations de performance qui ont été implémentées lors de
299) la dernière phase ont été livrées dans la version 0.2.1.7-alpha de Tor. Les
300) utilisateurs peuvent télécharger cette version en développement depuis la
301) page d'accueil de Tor et tester ainsi les améliorations au prix d'un effort
302) minime. De plus, deux corrections de bugs (<a
303) href="http://bugs.noreply.org/flyspray/index.php?id=767&do=details">1</a>,
304) <a
305) href="http://bugs.noreply.org/flyspray/index.php?id=814&do=details">2</a>)
306) qui avaient été découverts au cours de ce projet ont été rétroportées dans
307) la branche stable et seront incluses dans la prochaine version stable
308) 0.2.0.31.</em></small> <br/> <small><em>L'objectif principal des 31 derniers
309) jours a été de se concentrer sur de nouvelles mesures afin de vérifier
310) l'état des améliorations. Les mesures se sont déroulées sur deux jours
311) entre le 6 et le 8 novembre. Malheureusement, le réseau Tor a connu un
312) problème sérieux pendant cette période: un certificat périmé d'une autorité
313) d'annuaire a provoqué une grande quantité de trafic au sein du réseau Tor ce
314) qui a <a
315) href="http://archives.seul.org/or/talk/Nov-2008/msg00053.html">forcé un
316) grand nombre d'opérateurs à fermer leur relais</a>. Une seconde mesure a été
317) réalisée entre le 13 et le 15. Les données brutes sont disponibles <a
318) href="http://freehaven.net/~karsten/hidserv/perfdata-2008-11-13.tar.gz">ici</a>
319) (40Mo). Néanmoins, les résultats montrent que les performances globales du
320) réseau sont encore plus mauvaises qu'au mois de juin 2008, date de la
321) première mesure sur les services cachés. Ceci est visible quand on observe
322) les requêtes vers les annuaires Tor qui n'ont pas été touchées par les
323) améliorations et qui montrent une performance plus mauvaise
324) qu'auparavant. Les effets sur l'amélioration des performances sont bien
325) visibles même si les valeurs absolues ne sont pas comparables pour le
326) moment. De nouvelles mesures seront lancées en décembre dans l'espoir de
327) voir les effets de ce problème réduits.</em></small> <br/> <small><em>De
328) plus, il y a peut-être un <a
329) href="http://bugs.noreply.org/flyspray/index.php?id=847&do=details">bug</a>
330) dans la manière dont Tor télécharge les informations d'annuaire pendant
331) l'amorçage. Même si cela n'est pas lié aux services cachés, une amélioration
332) de ce côté profiterait quand même à ces derniers. Une partie du travail pour
333) les 30 jours à venir concernera ce bug. </em></small>
334) </td>
335) </tr>
336)
337) <tr bgcolor="#e5e5e5">
338) <td>
339) <a id="Dec08"></a> <a class="anchor" href="#Dec08">Décembre 2008</a>
340) </td>
341) <td>
|
|
new and updated translation...
Runa A. Sandvik authored 13 years ago
|
342) <small><em>Une partie des 30 derniers jours a été consacrée à la correction
343) de bugs qui ont influencé les dernières mesures sur les services cachés. La
344) première <a
345) href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">correction</a>
346) efface un problème d'erreur de segmentation reponsable en grande partie de
347) nombreux échecs de mesures. Un autre <a
348) href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> était
349) responsable du délai important dans l'amorçage: les autorités d'annuaire
350) lentes occupaient pendant longtemps l'amorçage des clients avant que ces
351) derniers abandonnent et utilisent une nouvelle autorité. Par conséquent,
352) nous avons alloué davantage de bande passante aux deux plus lentes autorités
353) d'annuaire, de manière à réduire ces désagréments. Un troisième <a
354) href="https://trac.torproject.org/projects/tor/ticket/874">bug</a> a été
355) introduit avec l'amélioration des performances des services cachés de
356) novembre. L'effet entraîné était que les processus Tor qui faisaient tourner
357) des services cachés arrêtaient d'annoncer ces services lors de
358) l'actualisation de leur configuration. De plus, ce bug a révélé que Tor
359) recréait ces points d'introduction à chaque actualisation ce qui pouvait
360) affecter la stabilisation des services cachés. Ce bug a été corrigé et sera
361) inclus dans la version 0.2.1.9-alpha à venir.</em></small> <br/>
362) <small><em>En dehors de la correction de bugs, de nouvelles mesures ont été
363) effectuées entre le 8 et le 10 décembre. Elles seront probablement les
364) dernières pour comparer les performances actuelles des services cachés avec
365) celles du début du projet. Les données n'ont pas complètement été évaluées,
366) il est donc difficile de faire un jugement sur ces améliorations à ce
367) stade. Toutefois, une <a
368) href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">analyse
369) préliminaire</a> montre que les temps de publication des services ont été
370) largement améliorés. C'est le résultat d'un amorçage plus rapide des clients
371) et des améliorations ajoutées en novembre. En revanche, les résultats
372) concernant l'établissement des connexions vers un service caché sont moins
373) prometteurs. Un exemple est la récupération des descripteurs de services
374) afin de rentrer en contact avec un service caché. Une explication possible
375) est que l'augmentation soudaine du nombre de noeuds d'annuaire de services
376) cachés au cours du mois de septembre a eut un effet négatif sur les
377) performances. Une partie du travail de ces 31 derniers jours consistera à
378) évaluer plus finement ces données et à rendre une conclusion sur
379) l'achèvement de ce projet.</em></small>
|
updated translations for th...
put the svn properties back