projects/pl/lowbandwidth.wml (9829567ed) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Revision: $Revision: 21511 $
# 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>
 15 Stycznia 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>

Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej
części 15. lipca 2008 i kończących się na ukończeniu implementacji i testów
15. stycznia 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>
 Przeprowadziliśmy trochę wstępnych badan uruchamiania się klienta
Tora. Wyniki nie są zbyt zadziwiające: klient pobiera około 10kB
certyfikatów, jeden konsensus rozmiaru 140kB (teraz 90kB, zobacz kolejny
paragraf) i około 1,5MB deskryptorów serwerów (po pobraniu połowy zaczyna
budować obwody). <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Propozycja
138</a> zmniejsza rozmiar konsensusu o od 30% do 40% i została już
zaimplementowana i połączona ze specyfikacją. Implementacja jest częścią
drzewa 0.2.1.x-alpha i odniesie skutek, gdy ponad dwie trzecie serwerów
katalogowych (czyli 5 z 6) zainstalują nową wersję. 
<a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycja
140</a> nie jest bezpośrednio związana ze zmniejszeniem rozmiaru wstępnego
pobierania, zamiast tego próbuje zmniejszyć kolejne pobierania dokumentów
konsensusu i została <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">wysłana na
or-dev</a>. Najpierw jest jeszcze kilka pytań wymagających odpowiedzi od
innych deweloperów Tora, ale poza tym propozycja wydaje się być dobra i może
być implementowana. Wielką Sprawą jest
sprawienie, by klienci nie pobierali całych 1,5MB deskryptorów serwerów. <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycja
141</a> została <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">wysłana na
or-dev</a>. Składa się w chwili bieżącej z 3 podstawowych rzeczy: przenieść
informacje o równowadze wykorzystania łącza do konsensusu (nie powinno być
trudne), zaimplementować coś, co pozwoli klientom Tora pobieranie
deskryptorów na żądanie od routerów na ich obwodzie w czasie jego budowania
(opisane w szkicu), zabrać się za wybór punktu wyjścia. Ciągle tworzymy
pomysły odnośnie ostatniej części; niektóre możliwości są wspomniane w
szkicu.
 </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">Styczeń 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

updated translations for the website