projects/pl/lowbandwidth.wml (2a9aaa802) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Revision: $Revision: 22186 $
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="NLnet Project: Tor for Low Bandwidth Clients" CHARSET="UTF-8"
<div class="main-column">

<h2>Projekt NLnet: Tor dla klientów o wolnym łączu</h2>
<hr />

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

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

Ten projekt jest hojnie sponsorowany przez:

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Projekt</big></th>
<th><big>Czas zakończenia</big></th>
</tr>
</thead>

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

<tr>
 <td>
 Część B:Implementacja zmiany protokołu Po projekcie,
sprawdzeniu i przeglądzie, zmiany muszą zostać zaimplementowane i
zintegrowane z bieżącym kodem Tora. Sama implementacja niezbędnych zmian
zajmie około trzech miesięcy. 
 </td>
 <td>
 15 Października 2008
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Część C:Testowanie Zmiana jest bardzo ważna dla
bezpieczeństwa i anonimowości sieci Tora, wymaga więc dogłębnego testowania
i szukania błędów w warunkach laboratoryjnych i rzeczywistych. Okres trzech
miesięcy jest przewidziany na testowanie i usuwanie błędów, podczas którego
odpowiedzialny za to programista poświęci 1/3 swojego czasu na testowanie.
Część fazy testowania będzie okresem publicznej wersji beta. 
 </td>
 <td>
 January 15, 2009
 </td>
</tr>

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

 </td>
 <td>
 15 Kwietnia 2009
 </td>
</tr>
</table>

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

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

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Miesiąc,</big></th>
<th><big>Raport o stanie</big></th>
</tr>
</thead>

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

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

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a> <a class="anchor" href="#Aug08">Sierpień 08</a>
 </td>
 <td>
 Dokumenty głosowania serwerów katalogowych i ich algorytm
tworzenia dokumentów konsensusu zostały zmienione, by uwzględniać informacje
o przepustowości łącza i podsumowania polityk, według Propozycji 141. Gdy
już pięć z sześciu działających centrów katalogowych zaktualizują się do
wersji SVN co najmniej 16554, dokumenty konsensusu zaczną zawierać te
informacje.
 </td>
</tr>

<tr>
 <td>
 <a id="Sep08"></a> <a class="anchor" href="#Sep08">Wrzesień 08</a>
 </td>
 <td>
We wrześniu nie było żadnych aktualizacji.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a> <a class="anchor" href="#Oct08">Październik 08</a>
 </td>
 <td>
Nie osiągnęliśmy naszego kroku milowego "skończenia
implementacji" w tym miesiącu, gdyż deweloper prowadzący ten projekt ma zbyt
dużo zajęć. Dobrą wiadomością jest to, że zrobiliśmy całkiem sporą część
implementacji, a było to kilka miesięcy temu (od etapu sierpniowego), więc
zdążyliśmy już ją nieźle przetestować. Pozostałe kroki implementacji to
nauczenie przekaźników, jak otrzymywać żądania pobierania deskryptorów
przekaźników z wewnątrz obwodów (prawdopodobnie potrzebujemy nowego typu
komórki specjalnie do tych celów, abyśmy mogli wyciąć drogę naokoło), a
potem nauczyć klientów, by robiły to, gdy używany przez nich przekaźnik
używa dostatecznie nowej wersji. Te dwa kroki są szczegółowo opisane w <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt"
>Sekcji 3.2 propozycji 141</a>

Nasz nowy plan czasowy to zrobienie tych dwóch rzeczy do połowy
listopada, a jeśli to zacznie wyglądać na coraz mniej prawdopodobne, zrobimy
większe zmiany planu i być może też projektu.

Jest kilka innych komponentów, którymi chcielibyśmy się zająć
potem -- jeden, o którym dużo ostatni myśleliśmy, to pobieranie różnic
ostatnich konsensusów: <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt"
>140-consensus-diffs.txt</a>. Po pierwsze, to mogłoby zaoszczędzić
przepustowość łącza, co zawsze jest dobre, gdy pomnożyć je przez liczbę
klientów, ale to też oznacza, że możemy użyć tej zaoszczędzonej
przepustowości do pobierania różnic częściej niż bieżące "co 3-4
godziny". Jeśli klienci poznają bardziej aktualne informacje katalogowe,
mogą budować szybsze ścieżki, gdyż mają lepsze dane o przepustowości każdego
przekaźnika (co wiąże się z projektem NLnet), ale głównym nowym pomysłem
jest to, że lepiej korzystamy z przelotnych przekaźników: w chwili obecnej
przekaźnik musi działać przez 3-4 godziny, zanim zobaczy jakichkolwiek
użytkowników, a to wyklucza wielu wolontariuszy chcących prowadzić
przekaźniki tylko przez kilka godzin na raz.
Kolejnym krokiem jest skończenie implementacji propozycji 141,
byśmy mogli przedstawić ją użytkownikom do testów. Mamy nadzieję, że
wkrótce!
 </td>
</tr>

<tr>
 <td>
 <a id="Nov08"></a> <a class="anchor" href="#Nov08">Listopad 08</a>
 </td>
 <td>
Zdaje się, że pierwszy plan, który mieliśmy na ostatnią fazę
rozwoju jest zarówno a) znacznie trudniejszy, niż myśleliśmy i b)
przypuszczalnie przesadny w stosunku do tego, czego
potrzebujemy.

Roger wznowił dyskusję projektową na or-dev: <a
href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.

Myślę, że teraz mamy lepsze rozeznanie w możliwościach i ich
kosztach: <a
href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.

Nick został zasypany innymi projektami deweloperskimi (miejmy
nadzieję, że zacznie kończenie ich w tym miesiącu), a ja chcę znać jego
zdanie na temat kontynuacji; mam nadzieję, że wybierzemy jedno z prostszych
podejść.

Z drugiej strony, te najprostsze rozwiązania dają też mniejszą
skalowalność. Ale moim zdaniem będą dobrymi rozwiązaniami tymczasowymi na
pewien czas -- a gdy nadejdzie ta chwila, kto wie, co jeszcze zostanie
zmienione.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jan09"></a> <a class="anchor" href="#Jan09">Jan 09</a>
 </td>
 <td>
 Napisałem bardziej szczegółową wersję naszego nowego pomysłu
projektowego jako <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt"
>propozycję #158</a>, a dyskusja zaczęła się od <a
href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html"
>http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.

Myślę, że to w końcu jest to! (No, jak już skończę zajmować się
komentarzami.)

Jednym z głównych powodów, dla których ten projekt nie jest
realizowany zgodnie z planem jest to, że główny wniosek z <a href="<page
projects/hidserv>">projektu Karstena z NLnet o wydajności usług ukrytych</a>
mówi, iż to rozszerzenie obwodu jest głównym powodem spadku wydajności. Ale
ten projekt zaproponował dodanie większej liczby przejść i złożoności
właśnie do tego punktu. Tak więc, musimy stworzyć lepszy plan, by dotrzeć do
pierwotnego celu bez dodatkowego pogarszania wydajności.

Przeglądaliśmy propozycję projektową w ciagu ostatnich kilku
tygodni i moim zdaniem wkrótce będziemy gotowi, by zacząć
implementację. Skoro jednak mamy kilka zadań deweloperskich, które już
lądują w lutym, jest prawdopodobne, że tą implementacją nie zajmiemy się
przed końcem lutego lub w marcu. Ale tym razem na pewno!
 </td>
</tr>
</table>

</div>

#include <foot.wmi>

tor-webwml.git

first cut of the new, shiny tor website as wml.