tor-webwml.git

1) 
2) 
3) 
4) 
5) 
6) 

7) ## translation metadata

8) # Revision: $Revision$

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>Projekt NLnet: Przyspieszenie usług ukrytych Tora</h2>
17) <hr />
18) 
19) <p>

20) Tor Hidden Services allow users to set up anonymous information services,
21) like websites, that can only be accessed through the Tor network and are
22) protected against identification of the host that runs the services.  The
23) most critical limitations of Tor Hidden Services are the time it takes until
24) a Hidden Service is registered in the network and the latency of contact
25) establishment when accessed by a user.  Due to design issues in the original
26) Tor protocol, the connection to a new Hidden Service can take several
27) minutes, which leads most users to give up before the connection has been
28) established.  Using Tor Hidden Services for direct interactive user-to-user
29) communication (e.g. messaging) is nearly impossible due to the high latency
30) of Hidden Service circuit setup.

31) </p>
32) 
33) <p>

34) Celem tego projektu jest przyspieszenie usług ukrytych Tora poprzez
35) usprawnienie metody tworzenia obwodów między użytkownikiem a usługą, jak
36) również sposobu, w jaki usługa jest rejestrowana w sieci.  W pierwszym kroku
37) poprowadzone będą dokładne pomiary zachowania usług ukrytych w warunkach
38) laboratoryjnych i rzeczywistych, by znaleźć główne przyczyny opóźnień.
39) Opierając się na wynikach pomiarów, zaprojektowane i zweryfikowane będą
40) strategie optymalizacji niechcianych implikacji związanymi z bezpieczeństwem
41) i anonimowością sieci Tora.  Najbardziej obiecujące optymalizacje zostaną
42) zaimplementowane, by dać użytkownikom widoczny efekt. Dokładne pomiary
43) sukcesu zostaną stworzone w fazie diagnostyki, gdy już będzie jasne, gdzie
44) tracony jest czas i jakie ulepszenia są możliwe.  Ostatecznym celem jest
45) umożliwienie wprowadzenia zmian w protokole usług ukrytych i rozprowadzenia
46) ich wśród użytkowników Tora w przeciągu 12 miesięcy.

47) </p>
48) 
49) <p>
50) Ten projekt jest hojnie sponsorowany przez:
51) </p>
52) 
53) <p>

54) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html" ><img
55) src="$(IMGROOT)/nlnet-160x60.png" alt="Fundacja NLnet" /></a>

56) </p>
57) 
58) <table width="100%" border="0" cellspacing="0" cellpadding="3">
59) <thead>
60) <tr>
61) <th><big>Projekt</big></th>
62) <th><big>Czas zakończenia</big></th>
63) </tr>
64) </thead>
65) 
66) <tr bgcolor="#e5e5e5">
67)   <td>
68)     <b>Część A:</b> Analiza, pomiary i klaryfikacja problemu<br />

69) <small><em>Jako że usługi ukryte Tora nie były aktywnie rozwijane przez
70) około ostatni rok rozwoju Tora, niektóre aspekty tych problemów są nie do
71) końca zbadane. Należy przeprowadzić dogłębną analizę przyczyn strat czasu,
72) by znaleźć ich dokładne źródła. Część A będzie wymagać około miesiąca
73) pracy. Wyniki analizy wpłyną na decyzje projektowe, które zostaną podjęte w
74) Części B.</em></small>

75)   </td>
76)   <td>
77)     15 Czerwca 2008
78)   </td>
79) </tr>
80) 
81) <tr>
82)   <td>
83)     <b>Część B:</b> Projektowanie i sprawdzanie niezbędnych zmian<br />

84) <small><em>Zmiany w usługach ukrytych wpłyną na podstawy funkcjonowania
85) protokołu i dlatego wymagają dokładnego sprawdzenia możliwych skutków dla
86) bezpieczeństwa i anonimowości. Na projekt i sprawdzanie przewidziany jest
87) dwumiesięczny okres, zakończony wyczerpującą recenzją.</em></small>

88)   </td>
89)   <td>
90)     15 Sierpnia 2008
91)   </td>
92) </tr>
93) 
94) <tr bgcolor="#e5e5e5">
95)   <td>

96)     <b>Część C:</b> Implementacja<br /> <small><em>Po projekcie, sprawdzeniu i
97) przeglądzie, zmiany muszą zostać zaimplementowane i zintegrowane z bieżącym
98) kodem Tora. Sama implementacja niezbędnych zmian zajmie około dwóch
99) miesięcy.</em></small>

100)   </td>
101)   <td>
102)     15 Października 2008
103)   </td>
104) </tr>
105) 
106) <tr>
107)   <td>
108)     <b>Część D:</b> Implementacja i testowanie aż do wydania<br />

109) <small><em>Zmiana jest bardzo ważna dla bezpieczeństwa i anonimowości sieci
110) Tora, wymaga więc dogłębnego testowania i szukania błędów w warunkach
111) laboratoryjnych i rzeczywistych. Okres trzech miesięcy jest przewidziany na
112) testowanie i usuwanie błędów, podczas którego odpowiedzialny za to
113) programista poświęci 1/3 swojego czasu na testowanie.  Część fazy testowania
114) będzie okresem publicznej wersji beta.</em></small>

115)   </td>
116)   <td>
117)     15 Stycznia 2009
118)   </td>
119) </tr>
120) 
121) <tr bgcolor="#e5e5e5">
122)   <td>

123)     <b>Część E:</b> Wypuszczenie<br /> <small><em>Wypuszczenie zmian do sieci
124) serwerów Tora będzie zsynchronizowane z regularnymi wydaniami Tora. Jako że
125) regularne wydania zależą od wielu czynników zewnętrznych, jak zakończenie
126) innych projektów, które powinny wyjść w tym samym wydaniu, właściwy czas
127) wydania i instalacji u większości operatorów serwerów Tora może być różny. Z
128) doświadczenia wiemy, że można oczekiwać okresu od trzech do czterech
129) miesięcy.</em></small>

130)   </td>
131)   <td>
132)     15 Maja 2009
133)   </td>
134) </tr>
135) </table>
136) 

137) <br /> <a id="Reports"></a>

138) <h2><a class="anchor" href="#Reports">Miesięczne raporty o bieżącym stanie</a></h2>
139) <p>

140) Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej
141) części 15. czerwca 2008 i kończących się na ukończeniu implementacji i
142) testów 15. stycznia 2009.

143) </p>
144) 
145) <table width="100%" border="0" cellspacing="0" cellpadding="3">
146) <thead>
147) <tr>
148) <th><big>Miesiąc,</big></th>
149) <th><big>Raport o stanie</big></th>
150) </tr>
151) </thead>
152) 
153) <tr bgcolor="#e5e5e5">
154)   <td>

155)     <a id="Jun08"></a> <a class="anchor" href="#Jun08">Czerwiec 08</a>

156)   </td>
157)   <td>
158)     <small><em>Pierwotny cel analizy problemu, który prowadził do spowolnienia

159) usług ukrytych, został osiągnięty. Częścią tej analizy był pomiar opóźnienia
160) doświadczanego przez użytkownika podczas tworzenia lub łączenia się z
161) usługą.  Ponadto, dane z kwietnia 2008 mogą zostać użyte do badania czasu
162) wykonania wewnętrznych kroków nawiązywania połączenia z usługą
163) ukrytą. Wyniki analizy zawarte są w 22-stronicowym <a
164) href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">raporcie</a>
165) upublicznionym na <a
166) href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">liście
167) mailingowej deweloperów</a> Tora.</em></small> <br/> <small><em>Analiza
168) odkryła także kilka błędów odpowiedzialnych za część opóźnienia w
169) udostępnianiu usługi ukrytej klientom. Kilka błędów zostało poprawionych po
170) analizie, inne będą poprawione wkrótce. Badanie ukazało kilka możliwych
171) podejść do polepszenia wydajności usług ukrytych. Część z tych pomysłów może
172) zostać zastosowana natychmiast, inne wymagają głębszej analizy i nowych
173) pomiarów. W trakcie analizy odkryliśmy, że część usprawnień wymaga głębszych
174) zmian w Torze, które nie są bezpośrednio związane z usługami ukrytymi. Zmian
175) tych nie da się osiągnąć w czasie przeznaczonym na ten projekt.</em></small>

176)   </td>
177) </tr>
178) 
179) <tr>
180)   <td>

181)     <a id="Jul08"></a> <a class="anchor" href="#Jul08">Lipiec 08</a>

182)   </td>
183)   <td>

184)     <small><em>Wszystkie błędy znalezione w analizie zostały naprawione, łącznie
185) z 2 błędami naprawionymi w czasie analizy i jeszcze 4 znalezionymi w ciągu
186) ostatnich 30 dni. Podczas gdy usunięcie błędów usunęło niechciane wąskie
187) gardła wydajności związane z błędami w programowaniu, część zmian
188) projektowych zauważonych w poprzedniej analizie ma efekty uboczne na
189) anonimowości lub sumarycznym obciążeniu sieci. Efekty te muszą zostać
190) zanalizowane w odniesieniu do poszczególnych celów wydajnościowych. <a
191) href="http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf"
192) >Raport</a> został wydany na <a
193) href="http://archives.seul.org/or/dev/Jul-2008/msg00034.html" >listę
194) mailingową deweloperów</a>, zawiera on 7 możliwych zmian projektu, które
195) muszą zostać przedyskutowane. Okazało się, że część badań (pomiary wolnego
196) łącza i wielki plan skalowania) zajmie więcej czasu, niż się spodziewano,
197) więc zostały przełożonych na dalszą przyszłość niż część B. Bieżący plan
198) zakłada przeprowadzenie tych badań do 15. stycznia i pracę z założeniami do
199) czasu, gdy dostępne będą końcowe wyniki.</em></small>

200)   </td>
201) </tr>
202) 
203) <tr bgcolor="#e5e5e5">
204)   <td>

205)     <a id="Aug08"></a> <a class="anchor" href="#Aug08">Sierpień 08</a>

206)   </td>
207)   <td>

208)     <small><em>W przeciągu ostatnich 30 dni 7 zaproponowanych projektów zostało

209) dalej rozpatrzonych i omówionych. Cztery z nich okazały się możliwe do
210) zastosowania, biorąc pod uwagę wymagane zmiany kodu i możliwe implikacje na
211) anonimowość.  Jeden został zakwalifikowany jako błąd, a nie zmiana
212) projektu. Dwa musiały zostać wykluczone ze względów albo nieprzewidywalnych
213) problemów z anonimowością albo niepewnością co do zysków
214) wydajności.</em></small> <br/> <small><em>Łącznie z wynikami z 15. licpa,
215) faza projektowania została zakończona.  Zadania dla zbliżającej się fazy
216) implementacji są teraz całkiem jasne: należy usunąć jeden błąd i
217) zaimplementować cztery zmiany projektowe. Ponadto, należy przeprowadzić
218) badania zmienionego projektu, by sprawdzić jego przydatność.  <a
219) href="http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf">Raport</a>
220) z wynikami fazy projektowej został wydany na <a
221) href="http://archives.seul.org/or/dev/Aug-2008/msg00025.html">listę
222) mailingową deweloperów</a>.</em></small>

223)   </td>
224) </tr>
225) 
226) <tr>
227)   <td>

228)     <a id="Sep08"></a> <a class="anchor" href="#Sep08">Wrzesień 08</a>

229)   </td>
230)   <td>

231)     <small><em>During the first half of the implementation phase two bugs could
232) be fixed that were related to hidden services: the <a
233) href="https://trac.torproject.org/projects/tor/ticket/767">first bug</a> has
234) already been identified in the design phase and was responsible for an
235) unusual high failure rate when making a hidden service available in the
236) system; the <a
237) href="https://trac.torproject.org/projects/tor/ticket/814">second bug</a>
238) was found during the implementation phase and was responsible for failure to
239) connect to a working hidden service. Both bugfixes will be included in the
240) next unstable version and likely be backported to one of the next stable
241) releases.</em></small> <br/> <small><em>The four design changes that were
242) proposed as result of the design phase have been implemented in an <a
243) href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">experimental
244) branch</a> of the unstable development tree. Early function tests have shown
245) that these changes work and provide better (perceived)  performance. This
246) needs to be confirmed throughout the next four weeks in internal tests. The
247) next goal is to prepare a release of this experimental branch that can be
248) given out to beta testers at the beginning of the upcoming testing
249) phase.</em></small>

250)   </td>
251) </tr>
252) 
253) <tr bgcolor="#e5e5e5">
254)   <td>

255)     <a id="Oct08"></a> <a class="anchor" href="#Oct08">Październik 08</a>

256)   </td>
257)   <td>

258)     <small><em>The implementation phase has been concluded. The bugfixes that
259) were found in the past 30 days have been released in developer version <a
260) href="http://archives.seul.org/or/talk/Oct-2008/msg00093.html">0.2.1.6-alpha</a>.
261) The four design changes that were identified in the design phase have been
262) specified in <a
263) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt">proposal
264) 155</a>.  Three design changes have been included in the development
265) codebase and will automatically be included in the next development
266) version. The first two design changes improve connection establishment to a
267) hidden service by reducing a timeout from 60 to 30 seconds and by making a
268) second attempt in parallel after a delay of 15 seconds. The third design
269) change affects publication of a hidden service in the network by advertising
270) the service at 5 rather than 3 points in the network in parallel and
271) succeeding as soon as 3 points are established. The fourth design change has
272) turned out to be rather ineffective, but would add considerable code
273) complexity and was therefore dismissed. By now there are no more open
274) bugfixes or new designs. All changes are in the development codebase and can
275) be tested in the next phase.</em></small>

276)   </td>
277) </tr>
278) 
279) <tr>
280)   <td>

281)     <a id="Nov08"></a> <a class="anchor" href="#Nov08">Listopad 08</a>

282)   </td>
283)   <td>

284)     <small><em>The performance improvements that were implemented in the last
285) phase have been released in Tor version 0.2.1.7-alpha. Users can download
286) this development version from the Tor homepage and test the improvements
287) with minimal effort. Further, two bugfixes (<a
288) href="https://trac.torproject.org/projects/tor/ticket/767">1</a>, <a
289) href="https://trac.torproject.org/projects/tor/ticket/814">2</a>)  that were
290) found in the course of this project have been backported to the stable
291) branch and will be included with the next stable version
292) 0.2.0.32.</em></small> <br/> <small><em>The main focus of the past 31 days
293) was to perform new measurements to see whether the improvements are
294) effective or not.  Measurements were conducted for two days in the time of
295) November 6th to 8th. Unfortunately, the Tor network suffered a serious
296) problem in this time: An expired directory authority certificate produced
297) huge amounts of traffic within the Tor network which <a
298) href="http://archives.seul.org/or/talk/Nov-2008/msg00053.html">forced many
299) operators to shut down their relays</a>. A second measurement was performed
300) between 13th and 15th. The raw data are available <a
301) href="http://freehaven.net/~karsten/hidserv/perfdata-2008-11-13.tar.gz">here</a>
302) (40 MB). But results show that the overall network performance is still
303) worse than in June 2008 when the first hidden service measurements have been
304) performed. This becomes visible when comparing requests to the Tor
305) directories which have not been affected by the performance improvements and
306) which exhibit significantly worse performance than before. The effects of
307) performance improvements are visible, but absolute values are not comparable
308) at this time. New measurements will be conducted in December in the hope
309) that the effects of this problem have mitigated.</em></small> <br/>
310) <small><em>Further, there might be a <a
311) href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> in the
312) way how Tor downloads directory information during bootstrapping. Even
313) though this is not related to hidden services, an improvement would benefit
314) hidden service publication, too. Part of the work during the upcoming 30
315) days will be to investigate this bug.  </em></small>

316)   </td>
317) </tr>
318) 
319) <tr bgcolor="#e5e5e5">
320)   <td>

321)     <a id="Dec08"></a> <a class="anchor" href="#Dec08">Grudzień 08</a>

322)   </td>
323)   <td>

324)     <small><em>Part of the last 30 days has been used to fix bugs that have
325) influenced the previous hidden service measurements. The first <a
326) href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">bugfix</a>
327) corrects a possible segmentation fault that was very likely responsible for
328) a number of failed measurement runs. Another <a
329) href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> could be
330) explained that lead to significant delays in bootstrapping: Very slow
331) directory authorities occupied bootstrapping clients for a long time before
332) clients finally gave up and bootstrapped using another authority. As a
333) result, the slowest two directory authorities have dedicated more bandwidth
334) to their nodes, so that the effect is mitigated. A third <a
335) href="https://trac.torproject.org/projects/tor/ticket/874">bug</a> has been
336) introduced with the hidden service performance improvements in November; the
337) effect was that Tor processes running hidden services would stop advertising
338) their service upon reloading their configuration. Further, this bug has
339) uncovered that Tor has re-established its introduction points upon
340) reloading, which might have affected hidden service stability. This bug has
341) been fixed and will be included in the upcoming version
342) 0.2.1.9-alpha.</em></small> <br/> <small><em>Apart from fixing bugs, new
343) measurements have been performed between December 8 and 10. These will very
344) likely be the final measurements to compare hidden service performance now
345) with the beginning of the project. The data have not been completely
346) evaluated, so it is difficult to make a statement about improvements at this
347) point. However, a <a
348) href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">preliminary
349) evaluation</a> shows that service publication times have improved
350) significantly. This is a result of Tor clients bootstrapping faster and of
351) the performance improvements added in November. In contrast to this, the
352) results for establishing a connection to a hidden service are less
353) promising. While the improvements added in November seem to have a positive
354) effect on performance, some substeps exhibit significantly worse
355) performance. One example is fetching hidden service descriptors in order to
356) contact a hidden service. A possible explanation is that the sudden increase
357) in the number of hidden service directory nodes in September has had a
358) negative effect on performance. Part of the work in the final 31 days will
359) be to evaluate these data in more detail and make a final conclusion on the
360) achievements of this project.</em></small>

361)   </td>
362) </tr>
363) 
364) <tr>
365)   <td>

366)     <a id="Jan09"></a> <a class="anchor" href="#Jan09">Styczeń 09</a>

367)   </td>
368)   <td>

369)     <small><em>Faza testów została zakończona. Testy zostały przeprowadzone w
370) publicznej fazie beta, w której wszystkie zmiany w usługach ukrytych stały
371) się częścią serii 0.2.1.x-alpha. Wynikiem publicznej fazy beta jest kilka
372) znalezionych błędów, które mogły już być naprawione.</em></small> <br/>
373) <small><em>Kolejną częścią testów był drugi zestaw pomiarów przeprowadzonych
374) w grudniu <a
375) href="http://freehaven.net/~karsten/hidserv/comparison-2009-01-15.pdf">Porównanie</a>
376) pomiarów z czerwca i grudnia odkryło, że zmiany z tego projektu dają
377) efekt. Czasy publikacji usług mogą być ponad dwa razy mniejsze - z 2:12
378) minut do 58 sekund średnio.  To polepszenie jest znacznie lepsze, niż się
379) spodziewaliśmy. Mając taki postęp, można w przyszłości pomyśleć o
380) zmniejszeniu czasu stabilizacji z 30 sekund do jakiejś niższej
381) wartości. Jednak czas nawiązania połączenia zostaje na poziomie około 56
382) sekund między żądaniem usługi ukrytej a nawiązaniem połączenia z ukrytym
383) serwerem. Głównym powodem braku postępu jest przełączenie się między
384) scentralizowanym a zdecentralizowanym przechowywaniem deskryptorów usług
385) ukrytych. Ten pogarszający efekt dystrybucji katalogu usług ukrytych nie był
386) wcześniej spodziewany. Przyszłe prace powinny skupić się na polepszeniu
387) pobierania z rozproszonego katalogu usług ukrytych, na przykład poprzez
388) prowadzenie równoległych żądań.</em></small> <br/> <small><em>Ten raport
389) kończy serię comiesięcznych aktualizacji statusu. Wydanie serii 0.2.1.x
390) zawierającej polepszenia wydajności usług krytych odbędzie się w przeciągu
391) od najbliższych tygodni do miesięcy.</em></small>

392)   </td>
393) </tr>
394) </table>
395) 
396) <!-- Do we want a people section? If so, would it make sense to write what

397) these people will be doing? And what exactly are these people going to

398) do? :)

399) <a id="People">
400) </a>

401) <h2><a class="anchor" href="#People">People</a></h2>
402) <ul>
403) <li><a href="<page people>#Core">Karsten Loesing</a></li>
404) <li><a href="<page people>#Core">Steven Murdoch</a></li>
405) </ul>
406) -->

407) <br /> <a id="Links"></a>

408) <h2><a class="anchor" href="#Links">Linki</a></h2>
409) <ul>

410) <li>Dokument badań <b>Performance Measurements and Statistics of Tor Hidden
411) Services</b> ("Pomiary wydajności i statystyki usług ukrytych Tora")  (<a
412) href="http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/loesing2008performance.pdf">PDF</a>)
413) napisali: Karsten Loesing, Werner Sandmann, Christian Wilms, i Guido
414) Wirtz. We Wstępie do 2008 International Symposium on Applications and the

415) Internet (SAINT), Turku, Finlandia, lipiec 2008.</li>

416) 
417) 

418) 
419) <!-- In the future, put links to proposal, preliminary results, etc. here -->

420) </ul>
421) 

422) </div>

423) 
424)