alex_emilsson
alex_emilsson Emilsson Magazine. Обо всём, кроме политики
Продолжение статьи, посвящённой основным настройкам µTorrent.
В этой части речь пойдёт о группах настроек «Скорость«, «BitTorrent«, «Предел передачи«, и «Очерёдность«.
По умолчанию:
Не установлен (нет ограничений).
Рекомендации:
Желательно включить. Но если у Вас «быстрый» Интернет, эффект не будет особо заметен.
По умолчанию:
Флажок снят (нет ограничений).
Рекомендации:
Если Вы желаете настроить индивидуальные значения скорости загрузки и отдачи для каждого торрента (это полезно, если у Вас не самый быстрый Интернет-канал, или же Вы хотите, чтобы один из торрентов загрузился быстрее, чем другой), то тогда смело устанавливайте этот флажок!
По умолчанию:
Флажок снят.
Рекомендации:
Действительно полезная опция, и я рекомендую Вам её использовать.
Рекомендации:
Можете выбрать на Ваше усмотрение (или оставить по умолчанию), но не стоит в этом переусердствовать. Для скорости 2 Мбит/с превосходно подходит значение 400.
Рекомендации:
Опять-таки, постарайтесь не переусердствовать в выборе этого значения. Для скорости 2 Мбит/с годятся значения в диапазоне 60-80, и лично я использую 60.
Рекомендации:
Это значение не должно быть слишком большим. Для скорости 2 Мбит/с можно использовать от 5 до 7 слотов (я использую 5).
Рекомендации:
В большинстве случаев, Вы можете спокойно оставить это поле пустым.
Рекомендации:
Если у Вас нет проблем с ISP, не снимайте флажок.
Группа » Предел передачи «
Флажок » Ограничивать полосу «:
Используется для включения возможностей ограничения полосы пропускания.
Подгруппа » Установки ограничения «:
В этой области отбражается статистика всего переданного трафика за указанный период.
Рекомендации:
На Ваше усмотрение; главное, чтобы Ваш Интернет-канал это позволял!
Рекомендации:
На Ваше усмотрение.
Рекомендации:
Опять-таки, на Ваш выбор.
По умолчанию:
Флажок не установлен (обычный порядок).
Рекомендации:
И здесь так же данная опция может быть включена на Ваше усмотрение.
ВАЖНО: эта опция, как и две предыдущие влияют только на торренты, добавленные после того, как эти значения были установлены. Уже существующие торренты не затрагиваются, и продолжают использовать свои настройки цели сидирования.
По умолчанию:
Флажок не установлен (нет ограничений).
Рекомендации:
Как обычно, на Ваше усмотрение 8)
Как не стать ботом в Bittorrent DHT и других P2P сетях
Сеть Bittorrent DHT позволяет найти источники торрента по хешу из магнет-ссылки. Сеть состоит из узлов которые могут быть как Bittorent клиентами так и вредоносными программами которые препятсвуют нормальной работе сети. Они мешают клиенту получить источники торрента, перенаправляют запросы на атакуемые узлы, заполняют список узлов бесполезными адресами.
Пока я работал над счетчиком пиров и сидов(DHT Scrape) в этой сети я наткнулся на такие виды атаки.
Порт номер 1
Некоторые узлы выдавали список узлов где в качестве порта был указан первый. В интернете была рекомендация не соеденятся с 0 по 1024 портом. На них находятся критически важные для работы интрнета сервисы. Узел приславший адреса с портом в этом отрезке игнорируется.
Зеркала
Есть узлы которые просто возвращают обратно присланный пакет. Получается что мы спрашиваем сами себя и себе же отвечаем. Поскольку узел ответил корректно он помечается некоторыми клиентами как активный и его адрес передатся другим узлам. Для того чтобы такие узлы исключить из сети надо проверять этот вариант.
Флуд портами
Некоторые узлы выдают один и тотже IP с кучей разных портов. Такое может случиться с узлом за NAT который меняет исходящий порт узла. В таком случе если узел с таким IP и ID уже подтвержден (т.е. с ним была связь) новая информация отбрасывается. В другом случае используется последняя или случайная запись для проверки.
Токен
В каждом пакете имеется токен который позволяет определить что наш запрос попал к адресату и он нам ответил исключая тем самым атаки с подменой адреса. Но надо проверять что токен (как и остальные строки) не вылезает за рамки пакета. Это может позволить читать данные из памяти следующей за пакетом.
Таймер
Токен не панацея от входящих запросов с подельным адресом. В таком случае разрешается только 2 подряд запроса в секунду от одного IP. В случае большего количества они просто игнорируются.
Локальные адреса
Некоторые узлы возврашают локальные адреса которые соответственно недоступны из интернета. Этот также может быть внутренний адрес роутера. Эти адреса также должны игнорироваться если конечно они не получены от узла в этой же локальной сети.
Публикуем только проверенные узлы
Когда у нас спрашивают список узлов из базы узлов выбираются только те от которых мы получали корректный отет на наш запрос (активные). Остальные (неопределнные) опрашиваются постепенно и удаются из базы при отсутствии ответа (мертвые).
Сеть G2 последнее время очень страдала от того что в ней курсирует большое количество адресов мертвых узлов. Это замедляет вход в сеть и поск по ней.
Храним базу узлов
После длительного перерыва в работе клиента в базе узлов все записи становятся просроченными. Но клиент должен использовать их для входа в сеть до получения достаточного количества активных узлов. Если все узлы мертвые то клиент обращается к входным узлам. На моем опыте даже очень старая база с достаточно большим количеством узлов позволяет войти в сеть.
Фильтруем биты
Для получения количества пиров и сидов раздачи в сети используется Фильтр Блума. Поддельные узлы могут заполнить его едницами и исказить тем самым цифры. Поэтому сравниваются данные минимум от трех узлов.
Отправляем пинг перед ответом
Для того чтобы не участвовать в примитивных DDoS атаках перед отправкой большого пакета отправляем пинг на узел. При корректном ответе на пинг отправляем большой пакет.
Заключение
Надеюсь данная статья поможет писать более эффективные и безопасные клиенты для P2P сетей.
Про µTP в новых версиях µTorrent: что это, как, зачем?
Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.
Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу.
Поскольку торрент-клиент и так этим занимается — это не большая проблема. Дело в том, что посылаемые через TCP-«трубу» данные в процессе разбиваются на куски («пакеты»), каждый из которых отправляется независимо. При этом один пакет может идти одним маршрутом, другой — другим, последний кусок может прийти первым, первый — вообще по дороге потеряться. Поэтому каждый участник «трубы» (от операционной системы до маршрутизаторов) вынужден хранить у себя буфер, в который собирает отдельные пакеты, проверяя целостность и порядок, и требуя перепосылку если часть пакетов не дошла.
При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.
Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:
1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения
Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.
В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP — благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего.
Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.
Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.
Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.
За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrent’е начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне
Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.
Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.
Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее».
Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.
С другой стороны, не всё сетевое железо — модемы, марштуризаторы — и не весь софт рассчитывался на такое количество UDP-трафика, поэтому у некоторых пользователей с ним возникают глюки. Например со скоростью — когда периодически она вдруг падает до нуля, потом снова восстанавливается, или плавает от нуля до максимума. Видимо где-то в сетевом окружении переполняется некий связанный с UDP буфер, чёрт знает. Опять же, на официальном форуме можно поискать про совместимость с разным софтом и железом в случае проблем.
Другие «продвинутые» опции, на которые можно обратить внимание:
bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше.
peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.
Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: forum.utorrent.com/viewtopic.php?id=60602
По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает.
Kademlia DHT: Основы
Здравствуйте!
В этой статье, как и, надеюсь, в последующих, я хочу рассказать об одной из современных структурированных пиринговых сетей. Данный материал включает в себя мою переработку документаций, описаний и статей, найденных по теме. В качестве введения представлена общая краткая теория p2p-сетей, DHT, а уж затем следует основная часть, которой посвящена заметка.
1. Общая теория p2p
Распределение данных, процессорного времени и других ресурсов между пользователями заставляют искать решения организации сетей разного уровня и взаимодействия.
На смену клиент-серверному взаимодействую приходят сети p2p (point-to-point), чтобы предоставить больший уровень масштабируемости, автономности, анонимности, отказоустойчивости.
Далее будет приведена общая классификация.
Минусы и плюсы зависят от степени «гибридности» — какие характеристики она наследует от централизованных, а какие от децентрализованных (о которых речь пойдет далее).
Децентрализованные — Данный тип сетей подразумевает полное отсутствие серверов. Таким образом, исключается узкое место из сети.
При проектировании топологии и протоколов структурированных сетей оптимальным считается выполнение соотношений:
— Размер таблицы маршрутизации на каждом узле: O(log(n))
— Сложность поиска: O(log(n))
2. DHT
DHT (Distributed Hash Table) — распределенная хэш-таблица. Данная структура зачастую используется для децентрализованных топологий. Однако, это не единственный выбор (как подсказывает литература, впрочем, здесь лучше заняться дальнейшим самостоятельным поиском).
Для каждого значения (данных) на каждом узле вычисляется по определенным правилам хэш (например, с помощью SHA-1), который становится ключом. Также, вычисляется идентификатор узла (той же длины, что и хэш, а зачастую, той же функцией). Таким образом, каждый узел сети обладает своим идентификатором. Ключи публикуются в сети. Узел несет ответственность за ключи таблицы, которые близки к нему по определенной метрике (т.е. расстоянию), здесь подразумевается «похожесть» ключа на идентификатор, если опустить язык математики. Благодаря этому, каждый узел занимает свою зону ответственности при хранении ключей и связанных с ней информации (координаты узла, на котором расположено значение). Это позволяет определенным образом организовать алгоритм поиска по точным значениям (сначала вычислить ключ значения для поиска, например, имени файла, а затем искать этот ключ, направляя запросы к узлу, ответственному за него через посредников, предоставляющих полный путь).
DHT в полной степени обеспечивает отказоустойчивость и масштабируемость. В сочетании с Peer Exchange, например, DHT позволяет перехватить функции Torrent-трекера.
3. Kademlia
Метрика
Создателями данной топологии являются Petar Maymounkov и David Mazières. В основе работы протокола и построения таблиц лежит определения расстояния между узлами через XOR-метрику:
d(x, y) = x XOR y. Важно отметить, что расстоянием является результат операции XOR, интерпретируемый, как число, а не количество различающихся бит (такой критерий тоже может порождать метрику в пространстве ключей/идентификаторов). Т.е. при длине ключа 4 бита: d(2,5) = 0010 XOR 0101 = 0111 = 7.
XOR метрика удовлетворяет всем аксиомам метрики:
Данное свойство отмечают в связи с возможностью формального доказательства тезисов о размерах таблиц маршрутизации и сложности поиска. (Справедливости ради, предоставляемого в виде наброска).
Таблица маршрутизации
На вычислении расстояний между узлами (посредством применения метрики к их идентификаторам) базируется алгоритм построения таблиц маршрутизации.
Каждый i-ый столбец таблицы ответственен за хранение информации об узлах на расстоянии от 2^(i+1) до 2^i. Таким образом, последний столбец для узла 0111 может содержать информацию о любых узлах 1xxx, предпоследний об узлах 00xx, еще на уровень ближе — об узлах 010x.
Конечно, в реальной сети, применяется обычно длина ключа в 128, либо в 160 бит. Зависит от реализации.
Далее, вводится ограничение на число хранимых узлов на каждом уровне, K. Поэтому столбцы таблицы, ограниченные таким K, называют K-buckets (к сожалению, русский эквивалент, звучит совсем неблагозвучно).
Если рассмотреть бинарное дерево поиска, в листах которого лежат идентификаторы узлов, становится понятно, что такая структура K-buckets не случайна: каждый узел (а на примере 110) получает знания хотя бы об одном участнике каждого поддерева (для 110 выделенных залитыми овалами). Таким образом, каждый K-bucket отражает связь узла с не более, чем K участниками поддерева на уровне i. 
Протокол
STORE запрос, позволяющий разместить информацию на заданном узле. Перед выполнением STORE узел должен найти K ближайших к ключу значения, которое он собирается опубликовать, а лишь потом отправить каждому STORE с ключом и своими координатами. Хранение сразу на K узлах позволяет повысить доступность информации.
FIND_VALUE запрос, который, зачастую, повторяется для образования итерации, позволяющий найти значение по ключу. Реализует поиск значения в сети. Возвращает либо K ближайших узлов, либо само значение, в зависимости от достижения узла, хранящего искомые данные. Итерации прекращают как раз либо при возвращении значения (успех), либо при возврате уже опрошенных K узлов (значения нет в сети).
FIND_NODE запрос, используемый для поиска ближайших K к заданному идентификатору (поведение сходно с FIND_VALUE, только никогда не возвращает значение, всегда узлы!). Используется, например, при присоединении узла к сети по следующей схеме:
— Контакт с bootstrap узлом
— Посылка запроса FIND_NODE со своим идентификатором к bs узлу, дальнейшая итеративная рассылка
— Обновление K-buckets (при этом обновляются как K-buckets нового узла, так и всех, мимо которых проходил запрос (здесь на руку симметричность метрики XOR))
Как видно, протокол в своей спецификации практически не покрывает вопросы безопасности, что нашло отражение в исследованиях и работах по атаке Kademlia-based сетей.
Из особенностей стоит подчеркнуть наличие репликации, времени жизни значения (необходимость повторного размещения через определенный промежуток времени), параллелизм при посылке запросов FIND_*, дабы достигнуть нужных узлов за более короткое время (обозначается α, в реализациях обычно равно 3). При каждом прохождении запросов происходит попытка обновить K-bucket, что позволяет держать таблицы маршрутизации максимально оптимальными.
4. Реализации
Прежде всего, самой известной сетью, базирующейся на Kademlia является Kad Network, доступная в aMule/eMule. Для bootstrap используются существующие узлы в eDonkey.
Khashmir — Kademlia-реализация на Python, использующаяся в BitTorrent
Из ныне развивающихся и активных библиотек я бы еще отметил
maidsafe-dht — C++ реализация инфраструктуры с поддержкой UDT и NAT Traversal.
Mojito — Java библиотека от LimeWire.
5. Что дальше?
Хотел бы получить комментарии о том, во что следует углубиться подробнее, т.к. статья носит чрезвычайно поверхностный характер. Дабы пробудить интерес, а не выложить все карты разом на стол. Сам планирую в следующей заметке о Kademlia рассказать о проблемах безопасности, атаках и их предотвращении.
Как работают торренты и насколько это законно
Содержание
Содержание
Многие пользователи Интернета привыкли скачивать фильмы и сериалы, хотя сейчас куча разнообразных сервисов, приложений и сайтов, где за небольшую плату можно посмотреть все, что душе угодно. Некоторые лейблы даже новинки сразу выкатывают на своих сервисах, и в кино идти не нужно. Но так называемые торренты не теряют популярности. Что это такое, как работает и насколько это законно — разберемся в этом материале.
Что такое торрент
Торрент, он же BitTórrent (в буквальном переводе — поток бит) — это пиринговый (P2P) сетевой протокол, созданный, чтобы совместно обмениваться файлами через Интернет. А пиринговая сеть — это одноранговая сеть, где узлы «общаются» без центрального элемента. Сетевой протокол является набором правил и последовательности действий. Все это вместе позволяет устройствам соединяться и обмениваться данными.
Торрент-файлы передаются частями между устройствами (для удобства будем иметь в виду ПК). Каждый клиент скачивает кусочки файлов и одновременно раздает их другим участникам сети. При этом достигается избыточность данных, которая позволяет снизить зависимость от каждого узла сети. Проще говоря, одни и те же куски файлов хранятся на многих компьютерах, и если часть компьютеров, хранящих файлы, пропадет из сети, то сеть продолжит работу.
Торренты распространяются через файлы с метаданными, имеющими расширение «.torrent». Каждый такой файл содержит обязательную информацию: URL трекера, имя и размер файла и контрольные хеш-суммы SHA1-сегментов раздаваемых файлов. Также в файле может быть необязательная информация: хеш-суммы файлов целиком и альтернативные источники, работающие не по протоколу BitTorrent.
Принцип работы протокола BitTorrent
Приложение-клиент подключается к трекеру, указанному в файле. Передает ему свой адрес и хеш-сумму файлов, которые он хочет скачать. В ответ трекер передает клиенту адреса других ПК, которые раздают нужные файлы. Далее терекер периодически передает клиенту новые адреса раздающих ПК, если такие появляются в сети.
Клиенты связываются друг с другом напрямую, без участия сервера-трекера. Чем больше устройств будет хранить нужный вам файл, тем быстрее будет происходить скачивание, так как разные куски файла можно будет одновременно скачивать из кучи источников.
При соединении клиенты сообщают друг другу об имеющихся у них сегментах. ПК, желающий скачать сегмент, — он называется личер — посылает запрос и, если второй ПК, — сидер — готов отдавать, личер получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента. Если она совпала с той, что записана в торрент-файле, то сегмент успешно скачивается, а клиент оповещает всех присоединенных о том, что у него есть этот сегмент. Если же контрольные суммы различаются, то сегмент начинает скачиваться заново. Некоторые клиенты банят тех пиров, которые слишком часто отдают некорректные сегменты.
Порядок обмена сегментами выстроен, чтобы между клиентами распространялись в первую очередь самые редкие сегменты, так повышается доступность файла в сети. Сегменты могут весить от 16 до 4096 килобайт.
Режим End game
Компьютер переходит в этот режим, когда скачивание почти закончилось. В еnd game клиент запрашивает оставшиеся сегменты у всех подключенных. Благодаря этому не происходит замедление или полное «зависание» процесса скачивания файла, который почти уже загрузился, из-за каких-то медленных клиентов.
Сидирование
Когда клиент получил полный файл, он начинает отдавать данные другим участникам сети, то есть, становится сидом. Далее сид периодически подает трекеру сигналы об изменениях в состоянии закачек, обновляя списки IP-адресов.
Общие особенности протокола
На фрагменты разбивается вся раздача целиком, поэтому у «личера», который решил скачать только несколько файлов из закачки, будет храниться небольшой запас информации, для поддержания целостности фрагментов. В качестве объекта раздачи могут выступать несколько файлов, например, содержимое каталога.
Клиенты работают по протоколу TCP (Transmission Control Protocol — протокол управления передачей, один из основных протоколов передачи данных интернета). Клиенты и трекеры могут использовать любой порт, вместо стандартного 6969, чтобы избежать блокировки по порту некоторыми провайдерами.
Трекер
Трекер — это специальный сервер, позволяющий клиентам найти друг друга. Трекер хранит у себя только IP-адреса и хэш-суммы раздач и ничего не знает об имени и содержимом передаваемых файлов. Начиная с версии 4.2.0 официального клиента, выпущенного в 2015 году, появилась бестрекерная работа, которая базируется на DHT Kademlia. В этой реализации трекер доступен децентрализовано на клиентах в форме распределенной хеш-таблицы.
DHT — аббревиатура Distributed hash table, то есть распределенная хэш-таблица. Является протоколом, позволяющим битторрент-клиентам находить друг друга без использования трекера. Клиенты с поддержкой DHT образуют общую DHT-сеть и помогают друг другу найти участников одних и тех же раздач. Это позволяет участникам быстрее находить друг друга, снизить нагрузку на трекер, поддерживает участников вместе в периоды недоступности трекера.
На многих трекерах торренты раздаются с установленным флагом private, не позволяющим использовать сеть DHT. Цель этого — не допускать раздачу материала клиентам, не зарегистрированным на данном трекере. Однако для пользователя это означает уменьшение количества сидеров, иногда — значительное. Для популярных клиентов uTorrent и qBitTorrent умельцы создали бесплатные патчи, позволяющие отключить функции ограничения использования DHT для приватных торрентов.
Magnet-ссылка
magnet: — это открытый стандарт URI (Uniform Resource Identifier — единообразный идентификатор ресурса) схемы. Магнитная ссылка позволяет найти файлы без файла torrent. Эта ссылка содержит в себе только хэш-код раздачи. Также magnet-ссылки могут распространяться в виде файлов с расширением *.magnet.
Одним из преимуществ magnet-ссылок является их открытость и независимость от платформы: они могут быть использованы для загрузки файла при помощи разнообразных приложений на большинстве операционных систем. Благодаря тому, что magnet-ссылка представляет собой короткую строку текста, она может быть легко скопирована через буфер обмена, отправлена по электронной почте, через мессенджеры и SMS.
Недостатки и ограничения
Если в сети нет сидера, у которого есть все фрагменты раздачи нужного файла, то все части невозможно скачать, пока не появится клиент с полным набором. Раздача, в которой долгое время нет полного содержимого, называется «мертвой». Также в торрент-сети отсутствует анонимность, возможно узнать IP-адреса тех, кто скачивает, и тех, кто раздает. Но нельзя узнать какие еще раздачи или скачивания производятся с данного адреса.
Также некоторые из торрент-трекеров имеют открытый доступ, то есть каждый желающий может загрузить любую информацию, и эти раздачи не проверяются. Поэтому некоторые торренты могут содержать вредоносное ПО.
В 2008 году началась разработка нового поколения протокола — BitTorrent v2. В нем алгоритм хеширования SHA-1 заменен на более совершенный SHA-256. Он несовместим со старым, поэтому современные клиенты могут работать с обоими протоколами.
Законно ли пользоваться торрентами
Многие трекеры заблокированы в России за раздачу пиратского контента. Но в трекерах также содержится много авторских файлов и свободных раздач, которые полностью легальны. Если скачивать контент, не защищенный авторским правом — никаких последствий не будет.
За нарушение авторского права в российском законодательстве существует административная ответственность — уголовная и гражданская. Чтобы привлечь к административной ответственности по п.7.12 КоАП, надо доказать, что с помощью скаченного контента человек получит доход. А для привлечения к уголовной ответственности стоимость нарушения авторских прав должна превышать 100 тысяч рублей.
В России и во многих других странах в борьбе с нелегальным распространением контента в основном используется ограничение доступа. При этом пользователю фактически не грозит ответственность за незаконное скачивание. Но в некоторых государствах даже простое скачивание незаконного контента влечет за собой реальную административную или даже уголовную ответственность.
Протокол BitTorrent сам по себе не является незаконным или небезопасным. Это просто средство для обмена файлами любого типа, и существует множество легальных торрент-сервисов.
Но совместное использование и загрузка материалов, защищенных авторским правом, с помощью BitTorrent или иными способами, является незаконным процессом во многих странах. Простыми словами: торрент сам по себе легален, но загрузка несанкционированных материалов, защищенных авторским правом — это противозаконный процесс.
Лучшие торрент-клиенты
BitTorrent — это оригинальный и официальный торрент-клиент от разработчиков протокола. В бесплатной версии показывает рекламу.
BitComet — еще одно классическое приложение, появившееся чуть ли не одновременно с разработкой протокола. Но отзывы о нем протитвречивые.
BitLord — еще один собственный торрент-клиент, который доступен для платформ Windows и MacOS. Первоначально выпущенный в 2003 году, BitLord появился из вышеупомянутого BitComet и включает в себя ряд функций, которых нет на других платформах. Например, встроенный проигрыватель VLC для просмотра видео в приложении, поддержку субтитров с использованием API и встроенный торрент-поисковик.
Halite — это сверхлегкий, суперуниверсальный торрент-клиент. Поставляется со всеми программами и функциями, которые можно ожидать от современного торрент-клиента, в том числе с системой управляемых торрент-очередей, поддержкой магнитного URI, супер-заполнением и возможностью создавать торрент-файлы в приложении.
uTorrent — очень популярный клиент, который, со временем стало труднее рекомендовать из-за переизбытка рекламы. Изначально программа была легким и простым в использовании торрент-клиентом. В 2010 году uTorrent начала включать панель инструментов Conduit Engine в свою утилиту загрузки, а также делать домашнюю страницу и поисковую систему Conduit по умолчанию без согласия. В 2011 году uTorrent начал включать панель инструментов Bing, а затем объявил о платной версии приложения под названием uTorrent Plus.
qBittorrent — бесплатный клиент с открытым исходным кодом, без рекламных объявлений, регулярно обновляется.
Deluge — еще один бесплатный клиент с открытым кодом. От qBittorrent отличается меньшим размером — 34 килобайта.
Transmission — клиент для MacOS и linux, версия для Windows имеет меньший функционал.
Vuze — торрент-клиент. Имеет бесплатную и платную версии.
Сеть торрент и криптовалюты
BitTorrent, Inc. — частная американская компания со штаб-квартирой в Сан-Франциско, была основана 22 сентября 2004 года Брэмом Коэном (Bram Cohen) и Ашвином Невином (Ashwin Navin). На пике популярности аудитория сервисов BitTorrent достигала 150 миллионов активных пользователей в месяц.
В июне 2018 года компанию купил миллиардер, создатель криптовалюты TRON, Джастин Сан (Justin Sun). Протокол позволяет передавать любые типы файлов. Это помогло скомбинировать cеть BitTorrent и блокчейн TRON, так и был создан проект Atlas и криптовалюта BTT.
Проект Atlas не предполагает майнинг. Разработчики не видят смысла поощрять майнеров за огромные траты электроэнергии и дорогостоящее оборудование — принцип действия алгоритма proof-of-work (например, у биткоина).
Алгоритм консенсуса BTT — delegated proof-of-stake (DPoS). Он основан на голосовании между владельцами токенов в реальном времени. Выбираются супер представители, которые следят за стабильностью системы, и за это получают вознаграждение. Если сообщество не устраивают представители, их можно переизбрать. Такой же алгоритм у криптовалюты Tron (TRX) — основного блокчейна для проекта Atlas.
BTT можно получить через обмен на другие валюты, либо через эирдроп. Для владельцев криптовалюты Tron (TRX) производится эирдроп, запланированный на шесть лет. Чтобы получить монеты BTT бесплатно, достаточно хранить любое количество токенов TRX. Но чем больше их будет, тем больше BTT получите на эирдроп:
Эирдроп для держателей TRX производится 11 числа каждого месяца. Следить за курсом BTT можно здесь.
