BitTorrent

Эта статья о протоколе. Статья о клиенте: BitTorrent (программа).

BitTórrent (букв. англ. «битовый поток») в пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет.

Файлы передаются частями, каждый torrent-клиент, получая (скачивая) эти части, в то же время отдаёт (закачивает) их другим клиентам, что снижает нагрузку и зависимость от каждого клиента-источника и обеспечивает избыточность данных.

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

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

[править] Файл метаданных

Основная статья: .torrent

Файл метаданных является словарём в bencode формате с расширением .torrent в содержит информацию о раздаче (файлах, трекерах и др.)

[править] Принцип работы протокола

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

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

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

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

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

[править] Алгоритм обмена данными

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

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

Обмен данными начинается, когда обе стороны в нём заинтересованы, то есть, каждая из сторон имеет сегменты, которых нет у другой. Количество переданных сегментов подсчитывается, и если одна из сторон обнаруживает, что передаёт в среднем больше, чем принимает, она блокирует (англ. choke) на некоторое время отдачу другой стороне. Таким образом, в протокол заложена защита от личеров.

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

[править] Режим End game

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

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

[править] Сидирование

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

[править] Общие особенности

Отсутствие очередей на скачивание.
Файлы закачиваются небольшими фрагментами; чем менее доступен фрагмент, тем чаще он будет передаваться. Таким образом, присутствие в сети «сидера» с полным файлом для загрузки необязательно в система распределяет сегменты между «пирами», чтобы в последующем они могли обмениваться недостающими сегментами.
Клиенты (peers) обмениваются сегментами непосредственно между собой, по принципу «ты в мне, я в тебе».
Скачанные фрагменты становятся немедленно доступны другим клиентам.
Контролируется целостность каждого фрагмента.
На фрагменты разбиваются не отдельные файлы, а вся раздача целиком, поэтому у «личера», пожелавшего скачать лишь некоторые файлы из раздачи, для поддержания целостности фрагментов нередко будет храниться также небольшой объём избыточной (для него) информации.
В качестве объекта раздачи могут выступать несколько файлов (например, содержимое каталога).

[править] Протоколы и порты

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

Номера портов не фиксированы в спецификации протокола и могут изменяться при необходимости. В данный момент большинство трекеров используют обычный HTTP порт 80, а для клиентов рекомендуется выбрать случайный входящий порт. Более того, некоторые трекеры не допускают использование портов клиентов из стандартного диапазона 6881в6889, так как некоторые провайдеры запрещают использование этого диапазона портов.

DHT-сеть в BitTorrent-клиентах использует протокол UDP.

Кроме того, протокол UDP используется UDP-трекерами (поддерживается не всеми клиентами и не является официальной частью протокола) и для соединения клиентов друг с другом через UDP NAT Traversal (используется только в клиенте BitComet и не является официальной частью протокола).

[править] Трекер

Основная статья: BitTorrent-трекер

Трекер (англ. tracker; /ˈtrækə(r)/) в специализированный сервер, работающий по протоколу HTTP. Трекер нужен для того, чтобы клиенты могли найти друг друга. Фактически, на трекере хранятся IP-адреса, входящие порты клиентов и хеш-суммы, уникальным образом идентифицирующие объекты, участвующие в закачках. По стандарту, имена файлов на трекере не хранятся, и узнать их по хеш-суммам нельзя. Однако на практике трекер часто помимо своей основной функции выполняет и функцию небольшого веб-сервера. Такой сервер хранит файлы метаданных и описания распространяемых файлов, предоставляет статистику закачек по разным файлам, показывает текущее количество подключённых пиров и пр.

[править] Работа без трекера

В новых версиях протокола были разработаны бестрекерные (англ. trackerless) системы, которые решают некоторые из предыдущих проблем. Отказ трекера в таких системах не приводит к автоматическому отказу всей сети.

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

На данный момент не все клиенты используют совместимый друг с другом протокол. Совместимы между собой BitComet, µTorrent, Deluge, KTorrent, Transmission и официальный клиент BitTorrent. Vuze (Azureus) также имеет режим бестрекерной работы, но его реализация отличается от официальной, вследствие чего он не может работать через DHT с вышеперечисленными клиентами.^[3] Однако, для Vuze существует поддержка стандартного DHT через плагин Mainline DHT.

Работа без трекера также возможна при использовании мультипротокольных клиентов, поддерживающих BitTorrent. Shareaza через сеть Gnutella2 обменивается хешами и адресами пиров других поддерживаемых сетей, в том числе BitTorrent. В GreyLink 6.0 планируется поддержка BitTorrent, при этом сеть Direct Connect может использоваться не только для преобразования в TTH, но и для поиска пиров.

[править] Работа без торрент-клиента

Для того чтобы брать и раздавать файлы в торрент-сетях, не обязательно пользоваться специальными программами. Существуют несколько сервисов, которые позволяют скачивать файлы, используя только браузер^[4].

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

[править] Web-сиды

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

Впервые был создан Джоном «TheSHAD0W» Хоффманом, который создал BitTornado^[5]. Начиная с версии 5.0 клиент BitTorrent поддерживает веб-сиды и загрузки с веб-сайтов, был создан простой инструмент, который создает публикации веб сидов торрентов. В μTorrent добавлена поддержка для получения веб-сидов в версии 1.7. В BitComet добавлена поддержка для получения веб-сидов в версии 1.14.

[править] BTIH (BitTorrent Info Hash)

Это SHA1 хеш поля Info из файла метаданных. Данный хеш используется в магнет-ссылках, а также для идентификации на трекере и между клиентами. При загрузке на трекер файла метаданных его Info Hash может измениться, так как трекер может изменить поле info, установив флаг закрытой раздачи private или изменив/добавив поля внутри info. Поэтому необходимо снова скачать файл метаданных (файл .torrent) с трекера и добавить его в клиент^[6].

[править] BTC-ссылка

Указывается в виде:

btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]

Ссылка такого вида ссылается на раздачу и на её источник. Поддерживается в Shareaza.

[править] Недостатки и ограничения

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

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

[править] Отсутствие анонимности и персонализации

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

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

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

[править] Проблема личеров

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

[править] Отсутствие точного учета трафика

В отличие от многих коммерческих протоколов дистрибуции медиаконтента, архитектура протокола не предусматривает точного механизма учета и контроля трафика между точками сети. Всё, что есть в поля downloaded и uploaded, в которых клиенты передают при анонсе трекеру количество байт учтенных при скачивании/загрузке данных с момента предыдущего анонса. Однако не контролируясь никем, кроме как клиентом, они могут быть легко подменены. Для этого пользователи статично прописывают значения этих полей в URI трекера, пользуются патчами для клиентов или же отдельными программами(RatioMaster, GiveMeTorrent, GreedyTorrent и т. д.), либо просто удаляют из клиента запись о трекере сразу-же после получения с трекера списка точек сети. Всё это позволяет обходить искусственные ограничения, создаваемые администрацией многих частных и публичных трекеров.

[править] Терминология

Личер и его рой.

Анонс (англ. announce) в обращение клиента к трекеру посредством HTTP-GET-запроса. При каждом анонсе клиент передаёт на трекер информацию об объёмах им скачанного и отданного, a трекер передаёт клиенту список адресов других клиентов. Обращение клиента к трекеру происходит через определённые интервалы времени, которые определяются настройками клиента и трекера.
Веб-сид в HTTP или FTP-сервер, используемый в качестве источника данных, наравне с обычными сидами
Доступность (англ. availability, англ. distributed copies в распространённые копии) в количество полных копий файла, доступных клиенту. Каждый сид добавляет 1,0 к этому числу; личеры увеличивают доступность в зависимости от количества скачанного, которого нет у других личеров. К примеру, если на раздаче есть один сид и два личера, скачавшие по 50 % файла (скачанные части равны между собой), то доступность равна 1,50.
Заглохший (англ. choked в заглохший, придушенный) в клиент, обмен данными с которым заглох. Либо его канал на выход забит полностью и он не может ничего передать (достиг max_uploads), либо он является сидом и ему ничего не нужно получать.
Заинтересованный (англ. interested) в участник, желающий получить куски файла, имеющиеся у другого участника. Например, если у клиента А нет каких-то частей, которые есть у клиента Б, считается, что клиент А заинтересован в обмене с клиентом Б.
Излишки в данные, которые были посланы пиром или сидом, но получатель в них не нуждается. К излишкам также относятся ошибки хеша.
Индекс (англ. index) в это список .torrent-файлов (обычно включающий описания и другую информацию), управляемый веб-сайтом (индексатором) и доступный для поиска. Индексирующий сайт часто ошибочно называют трекером.
Лич, иногда личер (англ. leech в пиявка) в пир, не имеющий пока всех сегментов, то есть продолжающий скачивание. Термин часто употребляется и в негативном смысле, который он имеет в других файлообменных сетях: пользователь, который отдаёт гораздо меньше, чем скачивает.
Отравленный торрент в ситуация, когда часть пиров раздаёт повреждённые, либо специально сфальсифицированные сегменты.
Пир (англ. peer в соучастник) в клиент, участвующий в раздаче.
Поскрестись (англ. scrape в скрести, царапать) в процесс, аналогичный анонсу, но клиент запрашивает только статистику торрента, информацию о подключённых клиентах и возможности с ними связаться для обмена.
Пренебрегающий (англ. snubbed) в клиент, подключённый к получателю, но не посылавший ему данные уже более 60 секунд.
Раздача (англ. seeding) в процесс распространения файла по протоколу BitTorrent.
Рейтинг (англ. share ratio) в отношение отданного к скачанному.
Рой (англ. swarm) в совокупность всех пиров, участвующих в раздаче.
Сегмент (англ. part в часть) в все файлы для передачи делятся на небольшие куски в сегменты, которые, затем, передаются по сети в произвольном порядке для оптимизации обмена.
Сид, иногда сидер (англ. seeder в сеятель) в пир, имеющий все сегменты распространяемого файла, то есть либо начальный распространитель файла, либо уже скачавший весь файл и оставшийся на раздаче.
Супер-сидирование в специальный режим раздачи в некоторых BitTorrent-клиентах, пытающийся минимизировать количество данных, которое отдаст раздающий до появления первого скачавшего. Суперсид предлагает каждому пиру скачать только один сегмент файла, которого ещё нет у других пиров. Затем сид не даёт этому пиру следующих сегментов, пока не получит от других пиров подтверждения, что они тоже получили этот сегмент. Таким образом, суперсид пытается избежать повторной отдачи одних и тех же сегментов, и старается отдавать сегменты только тем пирам, которые активно передают их другим.
Хеш (англ. hash) в SHA1 отдельных сегментов оригинальных файлов, перечисленных в словаре «info» .torrent-файла. Каждая часть после получения сначала проверяется на совпадение хеша. Если проверка не удалась, данные отбрасываются и запрашиваются ещё раз. Также в протоколе используется хеш самого словаря «info»(«инфохеш»), выступающий в роли идентификатора конкретной раздачи при обращении к трекеру, к другим точкам сети, и при составлении magnet-ссылок (он содержат Base32-представление инфохеша).
Passkey в аутентификатор пользователя на неанонимных трекерах. Содержится в скачиваемом torrent-файле. Таким образом, если кто-то получит доступ к torrent-файлу (например, пользователь по неосторожности расшарил его), он сможет работать с трекером от имени этого пользователя. Трекер может изменить passkey по запросу пользователя, но при этом необходимо будет перескачать все прошлые torrent-файлы (или вручную отредактировать их), чтобы иметь возможность и дальше раздавать скачанные файлы.
URL анонса (англ. announce URL) в адрес трекера, к которому клиент делает анонс. Во многих клиентах называется «Tracker URL». Может включать «passkey» в уникальный код, назначаемый трекером для аккаунта пользователя, помогающий идентифицировать его на трекере (добавляется к URL анонса в самом *.torrent-файле при скачивании).

[править] Примечания

в‘ BitTorrent Specification: End Game
в‘ HAL в INRIA :: [inria-00000156, version 3] Understanding BitTorrent: An Experimental Perspective
в‘ What is DHT?//Torrent FAQ
в‘ Интернетные штучки " Качаем торренты без клиента: Bitlet, Torrent2exe, httpTorrents
в‘ HTTP-Based Seeding Specification (TXT). Архивировано из первоисточника 22 августа 2011. Проверено 9 мая 2006.
в‘ Как начать раздачу (на примере клиента µTorrent 1.8.3.)

[править] См. также

[править] Ссылки

Официальная страница BitTorrent
Текущая спецификация протокола BitTorrent
BitTorrent в каталоге ссылок Open Directory Project (dmoz).

[0] в‘ BitTorrent Specification: End Game

[1] в‘ HAL в INRIA :: [inria-00000156, version 3] Understanding BitTorrent: An Experimental Perspective

[2] в‘ What is DHT?//Torrent FAQ

[3] в‘ Интернетные штучки " Качаем торренты без клиента: Bitlet, Torrent2exe, httpTorrents

[4] в‘ HTTP-Based Seeding Specification (TXT). Архивировано из первоисточника 22 августа 2011. Проверено 9 мая 2006.

[5] в‘ Как начать раздачу (на примере клиента µTorrent 1.8.3.)

[1]

[2]

[3]

[4]

[5]

[6]

Протокол обмена файлами BitTorrent (программы-клиенты)
Авторы	Персоны: Брэм Коэн Ashwin Navin Компании: BitTorrent, Inc. Vuze, Inc.
Технологии	Суперсид Обмен пирами (Peer exchange, PEX) Распределённая хеш-таблица (DHT) Broadcatching Protocol encryption DNA Мультитрекер Ретрекер announce scrape
Трекеры	The Pirate Bay isoHunt Jamendo Mininova Rutracker.org Pornolab.net Free-Torrents.org Demonoid Torrents.net.ua
Движки	IPB (IPBTT) phpBB2 (TorrentPier TorrentPier II) phpBB3 (ppkBB3cker xbtBB3cker) SMF (SMF Torrent Simple Tracker) TBDev (CyBERhype Tracker KinoKPK LiteTracker Tesla Torrent-Tracker) Прочие (Xbtit BTITeam Tracker TorrentTrader Torrent Hoster vBulletin Torrent Tracker)

Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP)
Физический	Ethernet RS-232 EIA-422 RS-449 RS-485
Канальный	Ethernet PPPoE PPP L2F 802.11 Wi-Fi 802.16 WiMax Token ring ARCNET FDDI HDLC SLIP ATM DTM X.25 Frame relay SMDS STP
Сетевой	IPv4 IPv6 IPsec ICMP IGMP ARP RARP RIP2 OSPF
Транспортный	TCP UDP SCTP DCCP RUDP RTP GRE
Сеансовый	ADSP H.245 iSNS NetBIOS PAP RPC L2TP PPTP RTCP SMPP SCP SSH ZIP SDP
Представления	XDR SSL TLS
Прикладной	BGP HTTP HTTPS DHCP IRC SNMP DNS DNSSEC NNTP XMPP SIP IPP NTP SNTP Электронная почта (SMTP POP3 IMAP4) Передача файлов (FTP TFTP SFTP) Удалённый доступ (rlogin Telnet RDP)
Другие прикладные	OSCAR CDDB Multicast FTP Multisource FTP BitTorrent Gnutella Skype

BitTorrent

Содержание

[править] Файл метаданных

[править] Принцип работы протокола

[править] Алгоритм обмена данными

[править] Режим End game

[править] Сидирование

[править] Общие особенности

[править] Протоколы и порты

[править] Трекер

[править] Работа без трекера

[править] Работа без торрент-клиента

[править] Web-сиды

[править] BTIH (BitTorrent Info Hash)

[править] BTC-ссылка

[править] Недостатки и ограничения

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

[править] Отсутствие анонимности и персонализации

[править] Проблема личеров

[править] Отсутствие точного учета трафика

[править] Терминология

[править] Примечания

[править] См. также

[править] Ссылки

Личные инструменты

Пространства имён

Варианты

Просмотры

Действия

Поиск

Навигация

Участие

Печать/экспорт

Инструменты

На других языках