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

lowbandwidth.wml

## translation metadata
# Based-On-Revision: 18357
# Translation-Priority: 3-low
# Last-Translator: bogdandr_at_op . pl

#include "head.wmi" TITLE="Projekt NLnet: Tor dla klientów o wolnym łączu" CHARSET="UTF-8"

<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 2008
 </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. czerwca
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 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 jesgo 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>
 Grudzień 08
 </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

Mainetance/polish translation update.