BitTorrent

BitTorrent («битовый поток») — пиринговый (P2P) сетевой протокол, используемый для кооперативного обмена файлами посредством сети Интернет. Передача файлов осуществляется частями, каждый torrent-клиент, скачивая эти части, в то же время осуществляет раздачу их для других клиентов. Это существенно сокращает нагрузку и зависимость от каждого клиента-источника.

Протокол bitTorrent был создан Брэмом Коэном. Он написал первый torrent-клиент «BitTorrent» на языке Python 4 апреля 2001 года. Первая версия была запущена 2 июля 2001 года.

На рынке, помимо bitTorrent, существует и множество других программ-клиентов, осуществляющих обмен файлами по протоколу BitTorrent.

Принципы работы

Перед тем, как начать скачивание, клиент подключается к трекеру по адресу, указанному в торрент-файле. Файл сообщает ему свой адрес и хеш-сумму торрент-файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Затем клиент информирует трекер о ходе процесса (с определенной периодичностью) и получает при этом обновленный список адресов. Этот процесс носит название «объявление».

Клиенты подключаются друг к другу и осуществляют обмен сегментами файлов без непосредственного участия трекера. Трекер, в свою очередь, только хранит информацию, полученную от подключенных к обмену клиентов, список самих клиентов и другую статистическую информацию. 

Чтобы сеть BitTorrent работала эффективно, требуется как можно больше принимающих входящие соединения клиентов.

После соединения клиенты обмениваются информацией об имеющихся у них сегментах. Тот клиент, который желает скачать сегмент (личер), посылает запрос и, если другой клиент готов отдавать, то он получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента. Если она совпадает с той, что записана в торрент-файле, то сегмент считается скачанным, и клиент оповещает всех присоединенных пиров о наличии у него этого сегмента. В том случае, если контрольные суммы различаются,  сегмент начинает скачиваться заново. 

Так, объем служебной информации прямым образом зависит от количества и размера сегментов. 

Алгоритм обмена данными

Каждый клиент может осуществить временную блокировку отдачи другому клиенту. Это нужно для более эффективного использования канала отдачи. Также, при выборе клиента для разблокировки, предпочтение отдается пирам, которые, в свою очередь, сами передали этому клиенту много сегментов: пиры с хорошими скоростями отдачи поощряют друг друга.

Обмен сегментами осуществляется по принципу «ты — мне, я — тебе» симметрично в двух направлениях. Клиенты сообщают друг другу об имеющихся у них сегментах при подключении и затем при получении новых сегментов, и поэтому каждый клиент может хранить информацию о том, какие сегменты есть у других подключенных пиров. Порядок обмена выбирается таким образом, чтобы клиенты обменивались прежде всего наиболее редкими сегментами: так повышается доступность файлов в раздаче. Тем же временем выбор сегмента среди наиболее редких случаен, что позволяет избежать ситуации, когда все клиенты вдруг начинают скачивать один и тот же редкий сегмент. Это негативно отражается на общей производительности.

Процесс обмена данными начинается, когда обе стороны в нем заинтересованы, то есть, каждая из сторон имеет сегменты, которых нет у другой. Число переданных сегментов подсчитывается, и если одна из сторон вычислила, что передает в среднем больше, чем принимает, она блокирует на некоторое время отдачу другой стороне. Так, в протокол заложена защита от личеров.

Сегменты разделены на блоки (16-4096 килобайт), каждый клиент посылает запрос на эти блоки. Одновременно могут запрашиваться блоки из разных сегментов. Более того, некоторые клиенты поддерживают скачивание блоков одного сегмента у разных пиров. В этом случае описанные выше алгоритмы и механизмы обмена применимы и к уровню блоков.

Режим End game

Когда процесс скачивания подходит к концу, клиент переключается в особый режим «end game». В нем он запрашивает все оставшиеся сегменты у подключенных пиров, благодаря чему исключено замедление или полная остановка почти завершенной закачки.

Спецификация протокола не может определить, когда именно клиент войдет в режим «end game», однако существуют общепринятые практики: некоторые клиенты входят в режим «end game», когда не осталось незапрошенных блоков, другие — пока количество оставшихся блоков меньше количества передающихся (и не превышает 20). Бытует мнение, что лучше поддерживать количество ожидаемых блоков низким, чтобы минимизировать избыточность, так, при случайном запрашивании шанс получить дубликаты одного и того же блока меньше.

Сидирование

Когда клиент получил полный файл, он переходит в специальный режим работы, где он только отдает скаченные данные, то есть становится сидом. Сид информирует трекер об изменениях в торрентах и периодически обновляет списки IP-адресов.

Характерные особенности

  • Нет очередей на скачивание;
  • Закачка файла происходит небольшими фрагментами;
  • Клиенты осуществляют обмен сегментами между собой по принципу «ты — мне, я — тебе»;
  • Скаченные фрагменты сразу становятся доступными другим клиентам;
  • Осуществляется контроль целостности каждого фрагмента;
  • На фрагменты разбивается вся раздача полностью, а не отдельные файлы; 
  • Объектом раздачи могут выступать несколько файлов.

Протоколы и порты

Соединение клиентов с трекером осуществляется по протоколу TCP.

Наиболее часто используемый входящий порт трекера - 6969. Наиболее часто используемый диапазон входящих портов клиентов: 6881—6889.

В спецификации протокола номера портов не фиксируются и могут изменяться, в случае необходимости. В настоящее время, большинство трекеров пользуются обычным HTTP портом 80, для клиентов рекомендуется случайный входящий порт. Кроме того, некоторые трекеры не допускают использование портов клиентов из стандартного диапазона 6881—6889, поскольку некоторые провайдеры запрещают использование данного диапазона портов. DHT-сеть в BitTorrent-клиентах использует протокол UDP. Протокол UDP применяется UDP-трекерами, однако поддерживаются они не всеми клиентами, поскольку не являются официальной частью самого протокола. Для соединения клиентов друг с другом применяется UDP NAT Traversal.

Трекер

Трекер — спец сервер, функционирующий на протоколе HTTP. Для чего требуется трекер? Чтобы клиенты могли находить друг друга. По сути, на трекере происходит хранение IP-адресов, входящих портов клиентов и хеш-суммы. Согласно стандарту, имена файлов на трекере не хранятся, поэтому распознать их по хеш-суммам нельзя. Однако на практике трекер, помимо своей основной функции, зачастую является своеобразным небольшим веб-сервером. Этот сервер хранит файлы метаданных и описания распространяемых файлов, предоставляет статистику закачек по разным файлам, отображает текущее количество подключенных пиров и т.д.

Без трекера

Новые версии протокола являются бестрекерными системами, это решает некоторые из «старых» проблем. Например, отказ трекера в таких системах не приводит к отказу всей сети.

Начиная с версии 4.2.0 клиента, в него внедрена функция бестрекерной работы. Она базируется на DHT Kademlia. В этих системах трекер доступен децентрализовано, на клиентах, в форме распределенной хеш-таблицы.

В настоящее время, не все клиенты применяют совместимый между собой протокол. 

Совместимы: BitComet, µTorrent, Deluge, KTorrent, Transmission и официальный клиент BitTorrent. 

Функционирование без трекера возможно и при использовании мультипротокольных клиентов с поддержкой BitTorrent. Например, Shareaza посредством сети Gnutella2, обменивается хешами и адресами пиров других поддерживаемых сетей. 

Без торрент-клиента

Для раздачи файлов в торрент-сетях не обязательно иметь специальное ПО. Существуют также несколько сервисов, позволяющих скачку файлов с применением браузера.

Присутствие в файлах метаданных дополнительной информации, такой, например, как дополнительные источники и опциональные хеши, позволяет использовать файл метаданных .torrent аналогично форматам Metalink, MAGMA, Список файлов (Direct Connect). Клиент Shareaza применяет опциональные хеши для поиска альтернативных источников в других сетях.

Web-сиды

Web-сидирование - это один из вариантов использования клиента. Порой на сервере, ввиду тех или иных причин, нельзя запустить полноценный торрент клиент. В таком случае, в качестве источника раздачи выступает сервер, который работает по протоколу HTTP. Обычно клиенты отдают предпочтение другим BitTorrent-клиентам и обращаются к web-сиду только в случае необходимости. Реализован этот вариант использования тремя способами: BEP0017 BitTornado style webseeding, BEP0019 GetRight style webseeding и External Sourcing. Каждый из них выделяется деталями реализации.

BTIH (BitTorrent Info Hash)

BTIH - это SHA1 хеш поля Info из файла метаданных. Он используется в магнет-ссылках, а также для идентификации на трекере и между клиентами. В ходе загрузки на трекер файла метаданных его Info Hash может измениться из-за того, что трекер может изменить поле info, установив флаг закрытой раздачи private или изменив поля внутри info. Вот почему так необходимо скачивать файл метаданных (файл .torrent) заново с трекера и добавляеть его непосредственно в клиент.

Недостатки BitTorrent

Недоступность раздачи

Если, например, раздача непопулярна, то может получится так, что нет ни одного сида, а данных у присутствующих пиров не хватает для завершения скачивания. В таком случае, необходимо ждать появления либо сида, либо пира с теми сегментами, которые отсутствуют у остальных. Также можно применять копии файлов, полученные иным путем. Раздача, не имеющая на протяжении длительного времени ни одного сида, называется «мертвой».

Никакой анонимности и персонализации

Согласно принципам работы BitTorrent-протокола, каждому клиенту известны IP-адреса других клиентов. Применение различных расширений протокола в некоторых случаях позволяет узнать даже адреса других пиров.

Так:

  • Пользователи незащищенных систем и клиентов могут быть атакованы;
  • Адреса пользователей, передающих или принимающих файлы, легко узнать.

Однако, протокол не использует никнеймы, а чат между пирами не применяется. Нет возможности просмотреть список файлов пира. Эти функции реализованы в других протоколах (DC++/DirectConnect).

Проблема личеров

Некоторые пользователи не поддерживают раздачу после завершения скачивания, что ведет к уменьшению производительности. Данная особенность является ключевой причиной популярности частных торрент-трекеров, ведущих учет количества скачанного/отданного.

Нет точного учета трафика

Архитектурой протокола не предусмотрено точного механизма учета и контроля трафика между точками сети. Имеются только два поля: downloaded и uploaded, в них клиенты передают при анонсе трекеру количество байт учтенных при скачивании/загрузке данных с момента предыдущего анонса. Они не контролируются никем, кроме клиента, и соответственно, могут быть легко подменены. Для этого пользователи статично прописывают значения этих полей в URI трекера, пользуются патчами для клиентов или же отдельными программами, либо же просто удаляют из клиента запись о трекере после получения с трекера списка точек сети. Это позволяет обходить созданные администрацией многих частных и публичных трекеров искусственные ограничения.

#