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: Tor for Low Bandwidth Clients" CHARSET="UTF-8"
11) <div class="main-column">

12) 
13) 
14) 
15) <!-- PUT CONTENT AFTER THIS TAG -->
16) <h2>Projekt NLnet: Tor dla klientów o wolnym łączu</h2>
17) <hr />
18) 
19) <p>

20) System Tor jest w tej chwili najbardziej nadający się do używania dla ludzi
21) mających połączenie z Internetem o dużej przepustowości. W czasie
22) uruchamiania klienta Tora pobierany jest ogromny plik z opisem wszystkich
23) serwerów Tora. Ten plik to tak zwany Katalog Tora i umożliwia on klientowi
24) wybieranie spośród serwerów w sieci Tora. Pobieranie całego katalogu jest
25) wymagane w bieżącej wersji protokołu Tora. Ten plik z katalogiem jest zbyt
26) duży dla użytkowników z modemami lub będącymi w sieciach mobilnych jak GPRS,
27) jako że wstępne pobieranie uruchamiane przy każdym logowaniu użytkownika
28) trwa od 10 do 30 minut na wolnym połączeniu. W wyniku tego, Tor nie jest
29) zdatny do używania przez użytkowników modemów lub sieci mobilnych. Jednym z
30) głównych celów Tora jest dostarczanie bezpiecznego anonimowego Internetu
31) użytkownikom w krajach z dyktaturą lub represjami. Takie miejsca często mają
32) wolne połączenia internetowe, przez modem albo niskiej przepustowości łącza
33) do świata zewnętrznego.  Poprzez umożliwienie tym użytkownikom używania
34) sieci Tora można uczynić znaczny postęp w kierunku swobodnej komunikacji i
35) informacji w tych krajach.

36) </p>
37) 
38) <p>

39) By Tor nadawał się do użycia na wolnych łączach, potrzebny jest rozwój
40) protokołu Tora, by zmniejszyć rozmiar wstępnego pobierania. Nowa wersja
41) protokołu Tora powinna zmienić sposób, w jaki klient otrzymuje informacje do
42) stworzenia obwodu tak, by pierwsze pobieranie mogło być wykonane na linii
43) modemowej 14.4k w czasie około trzech minut. Celem prac w tym projekcie jest
44) umożliwienie wprowadzenia zmian w protokole i rozprowadzenia ich wśród
45) użytkowników Tora w przeciągu 12 miesięcy. Stworzone oprogramowanie zostanie
46) wydane na 3-punktowej licencji BSD, jak cały kod Tora. Wszystkie części będą

47) całkowicie publiczne.
48) </p>
49) 
50) <p>
51) Ten projekt jest hojnie sponsorowany przez:
52) </p>
53) 
54) <p>

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

57) </p>
58) 
59) <table width="100%" border="0" cellspacing="0" cellpadding="3">
60) <thead>
61) <tr>
62) <th><big>Projekt</big></th>
63) <th><big>Czas zakończenia</big></th>
64) </tr>
65) </thead>
66) 
67) <tr bgcolor="#e5e5e5">
68)   <td>
69)     <b>Część A:</b> Projektowanie i sprawdzanie zmian protokołu<br />

70) <small><em>W tej części zawarty jest szczegółowy projekt i oparte na
71) symulacjach sprawdzenie niezbędnych zmian i modyfikacji projektu bieżącego
72) protokołu Tora.  Zmiany w protokole będą raczej istotne, więc wymaga to
73) dokładnego sprawdzenia wszystkich możliwych skutków dla bezpieczeństwa i
74) anonimowości sieci Tora. Dla tej fazy projektowania i sprawdzania
75) przewidziany jest dwumiesięczny okres, zakończony wyczerpującą recenzją.
76) Celem tej części jest m.in. zdefiniowanie wydajności do osiągnięcia w fazie
77) implementacji.  Celem projektowym jest zmniejszenie pobieranego rozmiaru
78) Katalogu Tora do około 300 kilobajtów, co umożliwiłoby użytkownikowi łącza
79) 14.4 kbps pobranie go w ciągu około trzech minut. Mogą być odstępstwa od
80) tego celu, jeśli będą wymagane do zachowania bezpieczeństwa i anonimowości,
81) ale to jest obszar, w który należy celować.  </em></small>

82)   </td>
83)   <td>
84)     15 Lipca 2008
85)   </td>
86) </tr>
87) 
88) <tr>
89)   <td>

90)     <b>Część B:</b>Implementacja zmiany protokołu<br /> <small><em>Po projekcie,
91) sprawdzeniu i przeglądzie, zmiany muszą zostać zaimplementowane i
92) zintegrowane z bieżącym kodem Tora. Sama implementacja niezbędnych zmian
93) zajmie około trzech miesięcy.  </em></small>

94)   </td>
95)   <td>
96)     15 Października 2008
97)   </td>
98) </tr>
99) 
100) <tr bgcolor="#e5e5e5">
101)   <td>

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

108)   </td>
109)   <td>

110)     January 15, 2009

111)   </td>
112) </tr>
113) 
114) <tr>
115)   <td>

116)     <b>Część D:</b>Wypuszczenie<br /> <small><em>Wypuszczenie zmian do sieci
117) serwerów Tora będzie zsynchronizowane z regularnymi wydaniami Tora. Jako że
118) regularne wydania zależą od wielu czynników zewnętrznych, jak zakończenie
119) innych projektów, które powinny wyjść w tym samym wydaniu, właściwy czas
120) wydania i instalacji u większości operatorów serwerów Tora może być różny. Z
121) doświadczenia wiemy, że można oczekiwać okresu od trzech do czterech
122) miesięcy. Wydanie będzie przeprowadzone jako część regularnego procesu
123) wydawania Tora, który jest działaniem wykonywanym przez wolontariuszy i
124) personel wynagradzany z innych grantów przeznaczonych na projekt Tor.
125) </em></small>

126)   </td>
127)   <td>

128)     15 Kwietnia 2009

129)   </td>
130) </tr>
131) </table>
132) 

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

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

136) There will be in total eight monthly status reports beginning with the first
137) deliverable on July 15, 2008 and ending with completion of implementation
138) and testing work on January 15, 2009.

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

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

152)   </td>
153)   <td>

154)     <small><em>We did some initial measuring of Tor clients bootstrapping. The
155) results are not very surprising: a client fetches about 10KB of certs, one
156) consensus for 140KB (now 90KB, see next paragraph), and about 1.5 megs of
157) Server Descriptors (after half of which it starts building
158) circuits).</em></small> <br /> <small><em><a
159) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Proposal
160) 138</a> shrinks consensus documents by 30% to 40% and has already been
161) implemented and merged into the spec.  Implementation is part of the
162) 0.2.1.x-alpha tree and the code will take effect once over two-thirds of the
163) directory authorities (i.e. 5 out of 6) have upgraded.</em></small> <br />
164) <small><em><a
165) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposal
166) 140</a> does not directly relate to reducing initial download size, but
167) instead tries to make subsequent downloads of new consensus documents use
168) fewer bytes has also been written up and <a
169) href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">sent to
170) or-dev</a>. There are some questions to be answered from other Tor
171) developers first, but other than that I think it's fine and could be
172) implemented.</em></small> <br /> <small><em>The Big Thing is making clients
173) not download all 1.5 megs of server descriptors. <a
174) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposal
175) 141</a> has been <a
176) href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">sent to
177) or-dev</a>. There are basically 3 things to it, as far as I can see at the
178) moment: move load balancing info into the consensus (should not be hard),
179) implement something so that Tor clients can fetch SDs on demand from routers
180) along their circuit while they are building it (described in the draft), and
181) deal with exit selection. We're still developing ideas for the last part;
182) some possibilities are mentioned in the draft.</em></small>

183)   </td>
184) </tr>
185) 
186) <tr>
187)   <td>

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

189)   </td>
190)   <td>

191)     <small><em>Praca nad <a
192) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycją
193) 141</a> trwa: Są dwa podstawowe pomysły na to, jak przenieść informacje o
194) równowadze wykorzystania łącza do konsensusu: jeden pomysł mówi, że centra
195) katalogowe generują wagi, których klienci powinni używać i umieszczają to w
196) konsensusie, drugi jest taki, by po prostu umieścić w nim informacje o łączu
197) z deskryptora serwera. Ta druga opcja jest prawdopodobnie lepsza, gdy weźmie
198) się też pod uwagę <a
199) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycję
200) 140</a>, gdyż unika to dużej ilości często zmieniających się liczb w
201) konsensusie.</em></small> <br /> <small><em>Odnośnie polityk wyjścia, <a
202) href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">list na liście
203) mailingowej or-dev</a> sugeruje dodanie hasza identyfikującego politykę
204) wyjścia węzła do dokumentu konsensusu. Dodanie kolejnych 160 bitów o
205) wysokiej entropii na każdy węzeł może budzić niepokój, ale naszym zdaniem
206) wiele polityk wyjścia jest takich samych, więc dokument konsensusu powinien
207) dobrze się kompresować. Pomiary trwają.</em></small>

208)   </td>
209) </tr>
210) 
211) <tr bgcolor="#e5e5e5">
212)   <td>

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

214)   </td>
215)   <td>

216)     <small><em>Dokumenty głosowania serwerów katalogowych i ich algorytm
217) tworzenia dokumentów konsensusu zostały zmienione, by uwzględniać informacje
218) o przepustowości łącza i podsumowania polityk, według Propozycji 141. Gdy
219) już pięć z sześciu działających centrów katalogowych zaktualizują się do
220) wersji SVN co najmniej 16554, dokumenty konsensusu zaczną zawierać te
221) informacje.</em></small>

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

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

228)   </td>
229)   <td>

230) <small><em>We wrześniu nie było żadnych aktualizacji.</em></small>

231)   </td>
232) </tr>
233) 
234) <tr bgcolor="#e5e5e5">
235)   <td>

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

237)   </td>

238)   <td><p>
239) <small><em>Nie osiągnęliśmy naszego kroku milowego "skończenia
240) implementacji" w tym miesiącu, gdyż deweloper prowadzący ten projekt ma zbyt
241) dużo zajęć.  Dobrą wiadomością jest to, że zrobiliśmy całkiem sporą część
242) implementacji, a było to kilka miesięcy temu (od etapu sierpniowego), więc
243) zdążyliśmy już ją nieźle przetestować. Pozostałe kroki implementacji to
244) nauczenie przekaźników, jak otrzymywać żądania pobierania deskryptorów
245) przekaźników z wewnątrz obwodów (prawdopodobnie potrzebujemy nowego typu
246) komórki specjalnie do tych celów, abyśmy mogli wyciąć drogę naokoło), a
247) potem nauczyć klientów, by robiły to, gdy używany przez nich przekaźnik
248) używa dostatecznie nowej wersji. Te dwa kroki są szczegółowo opisane w <a
249) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt"
250) >Sekcji 3.2 propozycji 141</a></em></small></p>
251) 
252) <p><small><em>Nasz nowy plan czasowy to zrobienie tych dwóch rzeczy do połowy
253) listopada, a jeśli to zacznie wyglądać na coraz mniej prawdopodobne, zrobimy
254) większe zmiany planu i być może też projektu.</em></small></p>
255) 
256) <p><small><em>Jest kilka innych komponentów, którymi chcielibyśmy się zająć
257) potem -- jeden, o którym dużo ostatni myśleliśmy, to pobieranie różnic
258) ostatnich konsensusów: <a
259) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt"
260) >140-consensus-diffs.txt</a>.  Po pierwsze, to mogłoby zaoszczędzić
261) przepustowość łącza, co zawsze jest dobre, gdy pomnożyć je przez liczbę
262) klientów, ale to też oznacza, że możemy użyć tej zaoszczędzonej
263) przepustowości do pobierania różnic częściej niż bieżące "co 3-4
264) godziny". Jeśli klienci poznają bardziej aktualne informacje katalogowe,
265) mogą budować szybsze ścieżki, gdyż mają lepsze dane o przepustowości każdego
266) przekaźnika (co wiąże się z projektem NLnet), ale głównym nowym pomysłem
267) jest to, że lepiej korzystamy z przelotnych przekaźników: w chwili obecnej
268) przekaźnik musi działać przez 3-4 godziny, zanim zobaczy jakichkolwiek
269) użytkowników, a to wyklucza wielu wolontariuszy chcących prowadzić
270) przekaźniki tylko przez kilka godzin na raz.</em></small></p>
271) <p><small><em>Kolejnym krokiem jest skończenie implementacji propozycji 141,
272) byśmy mogli przedstawić ją użytkownikom do testów. Mamy nadzieję, że
273) wkrótce!</em></small></p>

274)   </td>
275) </tr>
276) 
277) <tr>
278)   <td>

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

280)   </td>
281)   <td>

282) <p><small><em>Zdaje się, że pierwszy plan, który mieliśmy na ostatnią fazę
283) rozwoju jest zarówno a) znacznie trudniejszy, niż myśleliśmy i b)
284) przypuszczalnie przesadny w stosunku do tego, czego
285) potrzebujemy.</em></small></p>
286) 
287) <p><small><em> Roger wznowił dyskusję projektową na or-dev: <a
288) href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.
289) </em></small></p>
290) 
291) <p><small><em>Myślę, że teraz mamy lepsze rozeznanie w możliwościach i ich
292) kosztach: <a
293) href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.
294) </em></small></p>
295) 
296) <p><small><em>Nick został zasypany innymi projektami deweloperskimi (miejmy
297) nadzieję, że zacznie kończenie ich w tym miesiącu), a ja chcę znać jego
298) zdanie na temat kontynuacji; mam nadzieję, że wybierzemy jedno z prostszych
299) podejść.</em></small></p>
300) 
301) <p><small><em>Z drugiej strony, te najprostsze rozwiązania dają też mniejszą
302) skalowalność.  Ale moim zdaniem będą dobrymi rozwiązaniami tymczasowymi na
303) pewien czas -- a gdy nadejdzie ta chwila, kto wie, co jeszcze zostanie
304) zmienione.</em></small></p>

305)   </td>
306) </tr>
307) 
308) <tr bgcolor="#e5e5e5">
309)   <td>

310)     <a id="Jan09"></a> <a class="anchor" href="#Jan09">Jan 09</a>

311)   </td>
312)   <td>

313) <p><small><em> Napisałem bardziej szczegółową wersję naszego nowego pomysłu
314) projektowego jako <a
315) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt"
316) >propozycję #158</a>, a dyskusja zaczęła się od <a
317) href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html"
318) >http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.</em></small></p>
319) 
320) <p><small><em> Myślę, że to w końcu jest to! (No, jak już skończę zajmować się
321) komentarzami.)  </em></small></p>
322) 
323) <p><small><em> Jednym z głównych powodów, dla których ten projekt nie jest
324) realizowany zgodnie z planem jest to, że główny wniosek z <a href="<page
325) projects/hidserv>">projektu Karstena z NLnet o wydajności usług ukrytych</a>
326) mówi, iż to rozszerzenie obwodu jest głównym powodem spadku wydajności. Ale
327) ten projekt zaproponował dodanie większej liczby przejść i złożoności
328) właśnie do tego punktu. Tak więc, musimy stworzyć lepszy plan, by dotrzeć do
329) pierwotnego celu bez dodatkowego pogarszania wydajności.  </em></small></p>
330) 
331) <p><small><em> Przeglądaliśmy propozycję projektową w ciagu ostatnich kilku
332) tygodni i moim zdaniem wkrótce będziemy gotowi, by zacząć
333) implementację. Skoro jednak mamy kilka zadań deweloperskich, które już
334) lądują w lutym, jest prawdopodobne, że tą implementacją nie zajmiemy się
335) przed końcem lutego lub w marcu. Ale tym razem na pewno!</em></small></p>

336)   </td>
337) </tr>
338) </table>
339) 
340) <br />
341) 

342) </div>

343) 
344)