projects/ru/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>Проект NLnet: Tor для клиентов с низкой полосой пропускания</h2>
<hr />

В настоящее время система анонимности Tor используется только Интернет
пользователями, у которых имеются подключения с высокой пропускной
способностью. При запуске клиента Tor загружается большой файл со всеми
серверными описаниями Tor. Это так называемая Директория Tor, которая
позволяет клиенту выбирать из доступных смешанных серверов в сети
Tor. Загрузка всей Директории Tor требуется существующим протоколом
Tor. Этот справочный файл является слишком большим для пользователей
модемных линий или таких мобильных сетей передачи данных, как GPRS, таким
образом из-за медленной скорости передачи линии первоначальная загрузка,
которая срабатывает каждый раз, когда пользователь входит в систему,
занимает от 10 до 30 минут. В результате - пользователи модемов или
мобильных телефонов не могут использовать Tor. Одной из основных целей
проекта Tor является предоставление безопасного анонимного Интернет доступа
для пользователей в странах с диктаторским или репрессивным режимом. Как
правило, Интернет соединение в этих странах очень медленное - либо через
модем, либо с низкой полосой пропускания. Поэтому значительный прогресс на
пути свободы коммуникации и информации может быть сделан в этих странах,
если предоставить гражданам этих стран возможность использования сети Tor.

Для того, чтобы сделать Tor доступным также для клиентов с подключениями с
низкой полосой пропускания, необходимо развитие протокола Tor таким образом,
чтобы уменьшить первоначальный размер загрузки. Новая версия протокола Tor
должна изменить способ получения клиентом информации для схемы установки Tor
на способ, когда первоначальная установка может быть совершена через 14.4
kbps модемную линию в течение примерно трех минут. Конечной целью работы,
которая должна быть проделана согласно данному предложению, является
изменение протокола и его распространение среди пользователей Tor в течение
менее 12 месяцев. Полученное программное обеспечение будет опубликовано, как
и все коды Tor, согласно лицензии 3-Clause BSD. Информация о всех этапах
будет полностью общедоступной.

Данный проект великодушно финансируется:

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Проект</big></th>
<th><big>Срок выполнения</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
 <td>
 Этап A: Разработка и оценка изменения протокола Этот
этап включает в себя детальную разработку и оценку существующего на данный
момент протокола Tor на основе моделирования необходимых изменений и
модификаций. Изменения в протоколе будут относительно значительными, поэтому
они требуют тщательной оценки возможных последствий для безопасности и
анонимности сети Tor. На фазу разработки и оценки запланировано два месяца,
что включает всестороннюю экспертную оценку. Частью этапа А будет
определение цели работы на стадии имплементации. Целью разработки является
уменьшение размера Директории Tor, чтобы она составляла примерно 300Кб, что,
в свою очередь, даст возможность пользователю 14.4 kbps линии загрузить ее в
течение трех минут. Для сохранения анонимности и безопасности допустимы
некоторые отступления от данной цели, но это та цифра, к которой мы
стремимся. 
 </td>
 <td>
 15 июля 2008г.
 </td>
</tr>

<tr>
 <td>
 Этап B:Внедрение изменений протокола После
разработки, оценки и экспертной оценки, модификации должны быть внедрены и
интегрированы в существующую базу кодов Tor. Внедрение необходимых изменений
займет примерно три месяца. 
 </td>
 <td>
 15 октября 2008г.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Этап C:Тестирование Так как модификация очень
рискованна для безопасности и анонимности сети Tor, требуется тщательное
тестирование и отладка как в лаборатории, так и в условиях реальной
жизни. На это планируется отвести три месяца, треть которых ответственные
разработчики будут заниматься тестированием. Частью фазы тестирования будет
также публичный бета период. 
 </td>
 <td>
 15 января 2009г.
 </td>
</tr>

<tr>
 <td>
 Этап D:Массовый выпуск Фактически массовый выпуск
на сервер сети Tor будет осуществлен вместе со списком регулярных релизов
Tor. Так как этот график зависит от множества внешних факторов, в частности
завершение других проектов программного обеспечения, то и данный выпуск
должен идти в тот же релиз. Фактическое время релиза и время, когда этот
релиз принят и установлен большинством серверных операторов Tor, может
различаться. По опыту можно ожидать период трех - четырех месяцев. Массовый
выпуск будет осуществлен как часть процесса регулярного релиза Tor, что
активно выполняется волонтерами и персоналом, получающим оплату через другие
гранты проекта Tor. 
 </td>
 <td>
 15 апреля 2009г.
 </td>
</tr>
</table>

<a id="Reports"></a>
<h2><a class="anchor" href="#Reports">Ежемесячные статус-отчеты</a></h2>

Всего будет сделано восемь статус-отчетов, начиная с первого этапа 15 июля
2008г. и заканчивая завершением работы по реализации и тестированию 15
января 2009г.

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Месяц,</big></th>
<th><big>Статус-отчет</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jun08"></a> <a class="anchor" href="#Jun08">Июнь 2008</a>
 </td>
 <td>
 Мы провели некоторые измерения загрузок, выполняемых клиентами
Tor. Результаты не очень удивительны: клиент получает примерно 10Кб
сертификатов, одно соглашение на 140Кб (сейчас 90Кб, смотрите следующий
параграф) и около 1.5 Мб Дескрипторов Сервера (после получения половины
которых начинается построение схемы). <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Предложение
138</a> уменьшает соглашение документов на 30-40% и уже было внедрено и
объединено со спецификацией. Внедрение является частью дерева 0.2.1.x-альфа
и код начнет действовать как только больше двух третей главных директорий
(т.е.5 из 6) будут обновлены. <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Предложение
140</a> не относится к уменьшению первоначального размера загрузки напрямую,
но пытается сделать так, чтобы основные загрузки новых документов соглашения
использовали меньше байтов, также записывается и <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">посылается для
дискуссии среди разработчиков or-dev</a>. Разработчики Tor должны сначала
ответить на некоторые вопросы, но в принципе оно уже может
применяться. Большим успехом является
предоставление клиенту возможности не загружать все 1.5 Мб дескрипторов
сервера. <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Предложение
141</a> было <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">отправлено в
список вопросов для разработчиков or-dev</a>. Фактически, на данный момент
нужно сделать 3 вещи: переместить информацию о балансировки нагрузки в
соглашение (что не должно быть очень сложно), внедрять что-либо таким
образом, чтобы клиенты Tor могли по запросу получать SD с рутеров в их схеме
(описано в проекте) и рассматривать выбор выхода. Мы все еще разрабатываем
идеи по последней части; некоторые возможности упомянуты в
проекте.
 </td>
</tr>

<tr>
 <td>
 <a id="Jul08"></a> <a class="anchor" href="#Jul08">Июль 2008</a>
 </td>
 <td>
 Работы над<a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Предложением
141</a>продолжается: Существует две основные идеи о том, как переместить
информацию о балансировки нагрузки в соглашение: одна заключается в том, что
администрация подсчитывает, сколько должен использовать клиент и вносит это
в соглашение; другой подход заключается в помещении там информации о
пропускной способности с дескриптора сервера. Вероятно, последний вариант
является более подходящим, если также рассматривать <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Предложение
140</a>, так как в таком случае в соглашении нет большого количества
постоянно меняющихся цифр. Для управления
схемой выхода <a
href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">автор поста в
списке рассылки or-dev </a> предлагает, чтобы в документ соглашения был
добавлен знак, определяющий выходную схему узла. Добавление в соглашение
дополнительных 160 непредсказуемых битов на узел может быть причиной
беспокойства, но мы полагаем, что, поскольку множество выходных схем
одинаковы, то документ соглашения будет отлично сжат. Действия скоро
последуют.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a> <a class="anchor" href="#Aug08">Август 2008</a>
 </td>
 <td>
 Документы, определяющие источники директории и их соглашение,
формирующее алгоритм, были изменены для включения информации о пропускной
способности и итоги схемы, как это задокументировано в Предложении 141. Как
только пять из шести работающих источников будут обновлены как минимум до
канала 16554, соглашение станет включать эту информацию.
 </td>
</tr>

<tr>
 <td>
 <a id="Sep08"></a> <a class="anchor" href="#Sep08">Сентябрь 2008</a>
 </td>
 <td>
Обновлений за сентябрь нет.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a> <a class="anchor" href="#Oct08">Октябрь 2008</a>
 </td>
 <td>
Мы не достигли цели этого месяца - "закончить реализацию", так
как разработчику проекта нужно было очень много делать. Однако хорошей
новостью является то, что достаточно количество работы по реализации было
проделано и уже несколько месяцев (с августа), как проект запущен; таким
образом он уже проходит стадию тестирования. Следующие шаги по реализации
включают в себя два аспекта: обучение серверов получению запросов для добычи
сервера дескриптора из схемы (вероятно, мы будем использовать новый тип
ячейки для этого, поэтому мы исключим полный обход), а затем мы обучим этому
клиентов, когда у них будут серверы более последних версий. Более подробно
эти два шага описаны в <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Части
3.2 Предложения 141</a>

Согласно нашему новому плану оба шага должны быть выполнены к
середине ноября. И если это начнет выглядеть менее вероятным, то мы более
радикально пересмотрим наш план и возможно даже переделаем его.

Существуют несколько других компонентов, которые мы хотели бы
достигнуть после этого этапа -- об одном мы недавно долго думали и это
загрузка "разниц" последнего соглашения <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">140-consensus-diffs.txt</a>.
Во-первых, это могло бы сохранить пропускную способность, которая всегда
отлична, если помножить на количество клиентов, но также это означает, что
мы можем использовать эту сохраненную пропускную способность для получения
разниц чаще, чем обычные "каждые 3-4 часа". Если клиенты изучат больше
информации об обновленной директории, то они смогут быстрее строить
маршруты, так как у них будет лучшая информация о пропускной способности
каждого сервера (что связано с первым проектом NLnet, описанным выше). Но
основное заключается в том, что мы будем больше использовать в своих
интересах кратковременные серверы: сейчас серверу нужно до трех-четырех
часов для обнаружения каких-либо пользователей, и это препятствует многим
волонтерам использовать сервер, но только несколько часов за
раз.
Следующим шагом является окончание реализации Предложения 141,
после чего мы сможем предлагать его пользователям для тестирования. Уже
скоро, мы надеемся!
 </td>
</tr>

<tr>
 <td>
 <a id="Nov08"></a> <a class="anchor" href="#Nov08">Ноябрь 2008</a>
 </td>
 <td>
Кажется, что первоначальный план, который был у нас на последний
этап разработки а) тяжелее, чем мы думали, б) будем надеяться, перегиб по
сравнению с тем, что нам нужно.

Роджер возобновил дискуссию о разработке: <a
href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.

Я думаю, теперь мы должны лучше справляться с дополнениями и
альтернативами: <a
href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.

Ник погрузился в другие проекты (надеюсь, он начнет давать
краткое заключение в этом месяце), и я хочу узнать его точку зрения о том,
как продолжать; я надеюсь, что мы выберем один из наиболее простых
подходов.

Увы, но самые простые решения предоставляют меньше
масштабируемости. Но до определенного момента они могут служить хорошими
временными заменителями, а кто знает, что еще изменится со
временем.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jan09"></a> <a class="anchor" href="#Jan09">Январь 2009</a>
 </td>
 <td>
Я написал более подробную версию нашей идеи новой разработки, так
как <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt">
Предложение Tor №158</a>, и обсуждение уже началось <a
href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.

Думаю, что наконец это то самое! (Ну, когда я закончу со всеми
комментариями.)

Одной из главных причин, по которым проект не соответствует
своему первоначальному плану, является заключение <a href="<page
projects/hidserv>">NLnet проекта Карстена по работе скрытых сервисов</a> о
том, что главным вредителем является расширение схемы. Этот проект предложил
добавить больше полных обходов и коэффициента сложности именно в этот
шаг. Таким образом, нам нужно было создать лучший план для достижения
первоначальной цели без нанесения еще большего ущерба
производительности.

В течение последних недель мы пересматривали предложение
разработки, и я думаю, что в вскоре мы будем готовы начать реализацию. Хочу
заметить, что так как нам нужно работать над некоторыми разработками, то мы
надеемся быть готовыми к середине февраля. Вероятно, реализация проекта
начнется только в конце февраля или в марте. Но точно не
позднее!
 </td>
</tr>
</table>

</div>

#include <foot.wmi>

tor-webwml.git

updated translations for the website