tor-webwml.git

1) 
2) 
3) 
4) 
5) 
6) 
7) ## translation metadata
8) # Revision: $Revision: 21511 $
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>Проект NLnet: Tor для клиентов с низкой полосой пропускания</h2>
17) <hr />
18) 
19) <p>
20) В настоящее время система анонимности Tor используется только Интернет
21) пользователями, у которых имеются подключения с высокой пропускной
22) способностью. При запуске клиента Tor загружается большой файл со всеми
23) серверными описаниями Tor. Это так называемая Директория Tor, которая
24) позволяет клиенту выбирать из доступных смешанных серверов в сети
25) Tor. Загрузка всей Директории Tor требуется существующим протоколом
26) Tor. Этот справочный файл является слишком большим для пользователей
27) модемных линий или таких мобильных сетей передачи данных, как GPRS, таким
28) образом из-за медленной скорости передачи линии первоначальная загрузка,
29) которая срабатывает каждый раз, когда пользователь входит в систему,
30) занимает от 10 до 30 минут. В результате - пользователи модемов или
31) мобильных телефонов не могут использовать Tor. Одной из основных целей
32) проекта Tor является предоставление безопасного анонимного Интернет доступа
33) для пользователей в странах с диктаторским или репрессивным режимом. Как
34) правило, Интернет соединение в этих странах очень медленное - либо через
35) модем, либо с низкой полосой пропускания. Поэтому значительный прогресс на
36) пути свободы коммуникации и информации может быть сделан в этих странах,
37) если предоставить гражданам этих стран возможность использования сети Tor.
38) </p>
39) 
40) <p>
41) Для того, чтобы сделать Tor доступным также для клиентов с подключениями с
42) низкой полосой пропускания, необходимо развитие протокола Tor таким образом,
43) чтобы уменьшить первоначальный размер загрузки. Новая версия протокола Tor
44) должна изменить способ получения клиентом информации для схемы установки Tor
45) на способ, когда первоначальная установка может быть совершена через 14.4
46) kbps модемную линию в течение примерно трех минут. Конечной целью работы,
47) которая должна быть проделана согласно данному предложению, является
48) изменение протокола и его распространение среди пользователей Tor в течение
49) менее 12 месяцев. Полученное программное обеспечение будет опубликовано, как
50) и все коды Tor, согласно лицензии 3-Clause BSD. Информация о всех этапах
51) будет полностью общедоступной. 
52) </p>
53) 
54) <p>
55) Данный проект великодушно финансируется:
56) </p>
57) 
58) <p>
59) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html"> <img
60) src="$(IMGROOT)/nlnet-160x60.png" alt="The NLnet foundation" /></a>
61) </p>
62) 
63) <table width="100%" border="0" cellspacing="0" cellpadding="3">
64) <thead>
65) <tr>
66) <th><big>Проект</big></th>

67) <th><big>Срок выполнения</big></th>

68) </tr>
69) </thead>
70) 
71) <tr bgcolor="#e5e5e5">
72)   <td>
73)     <b>Этап A:</b> Разработка и оценка изменения протокола<br /> <small><em>Этот
74) этап включает в себя детальную разработку и оценку существующего на данный
75) момент протокола Tor на основе моделирования необходимых изменений и
76) модификаций. Изменения в протоколе будут относительно значительными, поэтому
77) они требуют тщательной оценки возможных последствий для безопасности и
78) анонимности сети Tor. На фазу разработки и оценки запланировано два месяца,
79) что включает  всестороннюю экспертную оценку. Частью этапа А будет
80) определение цели работы на стадии имплементации. Целью разработки является

81) уменьшение размера Директории Tor, чтобы она составляла примерно 300Кб, что,
82) в свою очередь, даст возможность пользователю 14.4 kbps линии загрузить ее в
83) течение трех минут. Для сохранения анонимности и безопасности допустимы
84) некоторые отступления от данной цели, но это та цифра, к которой мы
85) стремимся. </em></small>

86)   </td>
87)   <td>
88)     15 июля 2008г.
89)   </td>
90) </tr>
91) 
92) <tr>
93)   <td>
94)     <b>Этап B:</b>Внедрение изменений протокола<br /> <small><em>После
95) разработки, оценки и экспертной оценки, модификации должны быть внедрены и
96) интегрированы в существующую базу кодов Tor. Внедрение необходимых изменений
97) займет примерно три месяца. </em></small>
98)   </td>
99)   <td>
100)     15 октября 2008г.
101)   </td>
102) </tr>
103) 
104) <tr bgcolor="#e5e5e5">
105)   <td>
106)     <b>Этап C:</b>Тестирование<br /> <small><em>Так как модификация очень
107) рискованна для безопасности и анонимности сети Tor, требуется тщательное
108) тестирование и отладка как в лаборатории, так и в условиях реальной
109) жизни. На это планируется отвести три месяца, треть которых ответственные
110) разработчики будут заниматься тестированием. Частью фазы тестирования будет
111) также публичный бета период. </em></small>
112)   </td>
113)   <td>
114)     15 января 2009г.
115)   </td>
116) </tr>
117) 
118) <tr>
119)   <td>
120)     <b>Этап D:</b>Массовый выпуск<br /> <small><em> Фактически массовый выпуск
121) на сервер сети Tor будет осуществлен вместе со списком регулярных релизов
122) Tor. Так как этот график зависит от множества внешних факторов, в частности
123) завершение других проектов программного обеспечения, то и данный выпуск
124) должен идти в тот же релиз. Фактическое время релиза и время, когда этот
125) релиз принят и установлен большинством серверных операторов Tor, может
126) различаться. По опыту можно ожидать период трех - четырех месяцев. Массовый
127) выпуск будет осуществлен как часть процесса регулярного релиза Tor, что
128) активно выполняется волонтерами и персоналом, получающим оплату через другие
129) гранты проекта Tor.  </em></small>
130)   </td>
131)   <td>
132)     15 апреля 2009г.
133)   </td>
134) </tr>
135) </table>
136) 
137) <br /> <a id="Reports"></a>
138) <h2><a class="anchor" href="#Reports">Ежемесячные статус-отчеты</a></h2>
139) <p>
140) Всего будет сделано восемь статус-отчетов, начиная с первого этапа 15 июля
141) 2008г. и заканчивая завершением работы по реализации и тестированию 15
142) января 2009г.
143) </p>
144) 
145) <table width="100%" border="0" cellspacing="0" cellpadding="3">
146) <thead>
147) <tr>
148) <th><big>Месяц,</big></th>
149) <th><big>Статус-отчет</big></th>
150) </tr>
151) </thead>
152) 
153) <tr bgcolor="#e5e5e5">
154)   <td>
155)     <a id="Jun08"></a> <a class="anchor" href="#Jun08">Июнь 2008</a>
156)   </td>
157)   <td>
158)     <small><em>Мы провели некоторые измерения загрузок, выполняемых клиентами
159) Tor. Результаты не очень удивительны: клиент получает примерно 10Кб
160) сертификатов, одно соглашение на 140Кб (сейчас 90Кб, смотрите следующий
161) параграф) и около 1.5 Мб Дескрипторов Сервера (после получения половины
162) которых начинается построение схемы).</em></small> <br /> <small><em><a
163) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Предложение
164) 138</a> уменьшает соглашение документов на 30-40% и уже было внедрено и
165) объединено со спецификацией. Внедрение является частью дерева 0.2.1.x-альфа
166) и код начнет действовать как только больше двух третей главных директорий
167) (т.е.5 из 6) будут обновлены.</em></small> <br /> <small><em><a
168) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Предложение
169) 140</a> не относится к уменьшению первоначального размера загрузки напрямую,
170) но пытается сделать так, чтобы основные загрузки новых документов соглашения
171) использовали меньше байтов, также записывается и <a
172) href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">посылается для
173) дискуссии среди разработчиков or-dev</a>. Разработчики Tor должны сначала
174) ответить на некоторые вопросы, но в принципе оно уже может
175) применяться.</em></small> <br /> <small><em>Большим успехом является
176) предоставление клиенту возможности не загружать все 1.5 Мб дескрипторов
177) сервера. <a
178) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Предложение
179) 141</a> было <a
180) href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">отправлено в
181) список вопросов для разработчиков or-dev</a>. Фактически, на данный момент
182) нужно сделать 3 вещи: переместить информацию о балансировки нагрузки в
183) соглашение (что не должно быть очень сложно), внедрять что-либо таким
184) образом, чтобы клиенты Tor могли по запросу получать SD с рутеров в их схеме
185) (описано в проекте) и рассматривать выбор выхода. Мы все еще разрабатываем
186) идеи по последней части; некоторые возможности упомянуты в
187) проекте.</em></small>
188)   </td>
189) </tr>
190) 
191) <tr>
192)   <td>
193)     <a id="Jul08"></a> <a class="anchor" href="#Jul08">Июль 2008</a>
194)   </td>
195)   <td>
196)     <small><em>Работы над<a
197) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Предложением
198) 141</a>продолжается: Существует две основные идеи о том, как переместить
199) информацию о балансировки нагрузки в соглашение: одна заключается в том, что
200) администрация подсчитывает, сколько должен использовать клиент и вносит это
201) в соглашение; другой подход заключается в помещении там информации о
202) пропускной способности с дескриптора сервера. Вероятно, последний вариант
203) является более подходящим, если также рассматривать <a
204) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Предложение
205) 140</a>, так как в таком случае в соглашении нет большого количества
206) постоянно меняющихся цифр.</em></small> <br /> <small><em>Для управления
207) схемой выхода <a
208) href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">автор поста в
209) списке рассылки or-dev </a> предлагает, чтобы в документ соглашения был
210) добавлен знак, определяющий выходную схему узла. Добавление в соглашение
211) дополнительных 160 непредсказуемых битов на узел может быть причиной
212) беспокойства, но мы полагаем, что, поскольку множество выходных схем
213) одинаковы, то документ соглашения  будет отлично сжат. Действия скоро
214) последуют.</em></small>
215)   </td>
216) </tr>
217) 
218) <tr bgcolor="#e5e5e5">
219)   <td>

220)     <a id="Aug08"></a> <a class="anchor" href="#Aug08">Август 2008</a>

221)   </td>
222)   <td>
223)     <small><em>Документы, определяющие источники директории и их соглашение,
224) формирующее алгоритм, были изменены для включения информации о пропускной
225) способности и итоги схемы, как это задокументировано в Предложении 141. Как
226) только пять из шести работающих источников будут обновлены как минимум до
227) канала 16554, соглашение станет включать эту информацию.</em></small>
228)   </td>
229) </tr>
230) 
231) <tr>
232)   <td>
233)     <a id="Sep08"></a> <a class="anchor" href="#Sep08">Сентябрь 2008</a>
234)   </td>
235)   <td>
236) <small><em>Обновлений за сентябрь нет.</em></small>
237)   </td>
238) </tr>
239) 
240) <tr bgcolor="#e5e5e5">
241)   <td>
242)     <a id="Oct08"></a> <a class="anchor" href="#Oct08">Октябрь 2008</a>
243)   </td>
244)   <td><p>
245) <small><em>Мы не достигли цели этого месяца - "закончить реализацию", так
246) как разработчику проекта нужно было очень много делать. Однако хорошей
247) новостью является то, что достаточно количество работы по реализации было
248) проделано и уже несколько месяцев (с августа), как проект запущен; таким
249) образом он уже проходит стадию тестирования. Следующие шаги по реализации
250) включают в себя два аспекта: обучение серверов получению запросов для добычи
251) сервера дескриптора из схемы (вероятно, мы будем использовать новый тип
252) ячейки для этого, поэтому мы исключим полный обход), а затем мы обучим этому
253) клиентов, когда у них будут серверы более последних версий. Более подробно
254) эти два шага описаны в <a
255) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Части
256) 3.2 Предложения 141</a></em></small></p>
257) 
258) <p><small><em>Согласно нашему новому плану оба шага должны быть выполнены к
259) середине ноября. И если это начнет выглядеть менее вероятным, то мы более
260) радикально пересмотрим наш план и возможно даже переделаем его.</em></small></p>
261) 
262) <p><small><em>Существуют несколько других компонентов, которые мы хотели бы
263) достигнуть после этого этапа -- об одном мы недавно долго думали и это
264) загрузка "разниц" последнего соглашения <a
265) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">140-consensus-diffs.txt</a>.
266) Во-первых, это могло бы сохранить пропускную способность, которая всегда
267) отлична, если помножить на количество клиентов, но также это означает, что
268) мы можем использовать эту сохраненную пропускную способность для получения
269) разниц чаще, чем обычные "каждые 3-4 часа". Если клиенты изучат больше
270) информации об обновленной директории, то они смогут быстрее строить

271) маршруты, так как у них будет лучшая информация о пропускной способности