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)     15 Stycznia 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) Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej
137) części 15. lipca 2008 i kończących się na ukończeniu implementacji i testów
138) 15. stycznia 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>Przeprowadziliśmy trochę wstępnych badan uruchamiania się klienta
155) Tora.  Wyniki nie są zbyt zadziwiające: klient pobiera około 10kB
156) certyfikatów, jeden konsensus rozmiaru 140kB (teraz 90kB, zobacz kolejny
157) paragraf) i około 1,5MB deskryptorów serwerów (po pobraniu połowy zaczyna
158) budować obwody).</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">Propozycja
160) 138</a> zmniejsza rozmiar konsensusu o od 30% do 40% i została już
161) zaimplementowana i połączona ze specyfikacją. Implementacja jest częścią
162) drzewa 0.2.1.x-alpha i odniesie skutek, gdy ponad dwie trzecie serwerów
163) katalogowych (czyli 5 z 6)  zainstalują nową wersję.</em></small> <br />

164) <small><em><a

165) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycja
166) 140</a> nie jest bezpośrednio związana ze zmniejszeniem rozmiaru wstępnego
167) pobierania, zamiast tego próbuje zmniejszyć kolejne pobierania dokumentów
168) konsensusu i została <a
169) href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">wysłana na
170) or-dev</a>. Najpierw jest jeszcze kilka pytań wymagających odpowiedzi od
171) innych deweloperów Tora, ale poza tym propozycja wydaje się być dobra i może
172) być implementowana.</em></small> <br /> <small><em>Wielką Sprawą jest
173) sprawienie, by klienci nie pobierali całych 1,5MB deskryptorów serwerów. <a
174) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycja
175) 141</a> została <a
176) href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">wysłana na
177) or-dev</a>. Składa się w chwili bieżącej z 3 podstawowych rzeczy: przenieść
178) informacje o równowadze wykorzystania łącza do konsensusu (nie powinno być
179) trudne), zaimplementować coś, co pozwoli klientom Tora pobieranie
180) deskryptorów na żądanie od routerów na ich obwodzie w czasie jego budowania
181) (opisane w szkicu), zabrać się za wybór punktu wyjścia. Ciągle tworzymy
182) pomysły odnośnie ostatniej części; niektóre możliwości są wspomniane w
183) szkicu.</em></small>

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

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

190)   </td>
191)   <td>

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

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

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

215)   </td>
216)   <td>

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

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

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

238)   </td>

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

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

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

281)   </td>
282)   <td>

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

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

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

312)   </td>
313)   <td>

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

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

343) </div>

344) 
345)