Просмотр кода страницы BitTorrent

{{Значения|BitTorrent (значения)}}
'''BitTorrent''' (букв. {{lang-en|[[битовый поток]]}}) — [[Одноранговая сеть|пиринговый]] (P2P) [[Протокол передачи данных|сетевой протокол]] для кооперативного обмена [[файл]]ами через [[Интернет]].

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

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

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

== Файл метаданных ==
{{main|.torrent}}

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

== Принцип работы протокола ==
[[Файл:Torrentcomp small.gif|thumb|600px|Принцип работы BitTorrent: нагрузка на распространителя файла уменьшается благодаря тому, что клиенты начинают обмениваться данными сразу же, даже если файл не докачан ими до конца]]
Перед началом скачивания клиент подсоединяется к [[BitTorrent-трекер|трекеру]] по адресу, указанному в торрент-файле, сообщает ему свой адрес и хеш-сумму торрент-файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует трекер о ходе процесса и получает обновлённый список адресов. Этот процесс называется объявлением ({{lang-en|announce}}).

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

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

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

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

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

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

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

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

Спецификация протокола не определяет, когда именно клиент должен войти в режим «end game», однако существует набор общепринятых практик. Некоторые клиенты входят в этот режим, когда не осталось незапрошенных блоков, другие — пока количество оставшихся блоков меньше количества передающихся и не больше 20. Существует негласное мнение, что лучше поддерживать количество ожидаемых блоков низким (1 или 2) для минимизации избыточности, и что при случайном запрашивании меньший шанс получить дубликаты одного и того же блока<ref>{{Cite web |url=http://wiki.theory.org/BitTorrentSpecification#End_Game |title=BitTorrent Specification: End Game |access-date=2010-02-14 |archive-date=2006-12-14 |archive-url=https://web.archive.org/web/20061214094732/http://wiki.theory.org/BitTorrentSpecification#End_Game |url-status=live }}</ref><ref>[http://hal.inria.fr/inria-00000156/en]{{Wayback|url=http://hal.inria.fr/inria-00000156/en|date=20120217170319}}<span> HAL — INRIA:: [inria-00000156, version 3</span>&#x5D;<span> Understanding BitTorrent: An Experimental Perspective</span></ref>.

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

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

== Протоколы и порты ==
Клиенты соединяются с трекером по протоколу [[TCP]]. Наиболее часто используемый входящий [[Порт (TCP/IP)|порт]] трекера: 6969. Наиболее часто используемый диапазон входящих портов клиентов: 6881—6889.

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

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

Кроме того, протокол [[UDP]] используется {{iw|UDP-трекер|UDP-трекерами|en|UDP tracker}} (поддерживается не всеми клиентами и не является официальной частью протокола) и для соединения клиентов друг с другом через UDP [[NAT-T|NAT Traversal]] (используется только в клиенте BitComet и не является официальной частью протокола).

== Трекер ==
{{main|BitTorrent-трекер}}
'''Трекер''' ({{lang-en|tracker}}; {{IPA|/ˈtɹækə(ɹ)/}}) — специализированный [[Сервер (программное обеспечение)|сервер]], работающий по протоколу [[HTTP]]. Трекер нужен для того, чтобы клиенты могли найти друг друга. Фактически, на трекере хранятся [[IP-адрес]]а, входящие порты клиентов и [[Хеширование|хеш-суммы]], уникальным образом идентифицирующие объекты, участвующие в закачках. По стандарту, имена файлов на трекере не хранятся, и узнать их по хеш-суммам нельзя. Однако на практике трекер часто помимо своей основной функции выполняет и функцию небольшого [[веб-сервер]]а. Такой сервер хранит файлы метаданных и описания распространяемых файлов, предоставляет статистику закачек по разным файлам, показывает текущее количество подключённых пиров и пр.

=== Работа без трекера ===
В новых версиях протокола были разработаны бестрекерные ({{lang-en|trackerless}}) системы, которые решают некоторые из предыдущих проблем. Отказ трекера в таких системах не приводит к автоматическому отказу всей сети.

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

На данный момент не все клиенты используют совместимый друг с другом протокол. Совместимы между собой [[BitComet]], [[µTorrent]], [[Deluge]], [[KTorrent]], [[Transmission]], [[qBittorrent]] и [[BitTorrent (программа)|официальный клиент BitTorrent]]. [[Vuze]] (Azureus) также имеет режим бестрекерной работы, но его реализация отличается от официальной, вследствие чего он не может работать через DHT с вышеперечисленными клиентами<ref>[http://www.utorrent.com/faq.php#What_is_DHT.3F What is DHT?//Torrent FAQ] {{webarchive|url=https://web.archive.org/web/20070708005526/http://www.utorrent.com/faq.php#What_are_.C2.B5Torrent.27s_system_requirements.3F |date=2007-07-08 }}</ref>. Однако, для Vuze существует поддержка стандартного DHT через плагин Mainline DHT.

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

== Работа без торрент-клиента ==
Для того чтобы брать и раздавать файлы в торрент-сетях, не обязательно пользоваться специальными программами. Существует несколько сервисов, которые позволяют скачивать файлы, используя только браузер<ref>{{cite web|url=http://internetno.net/2009/12/10/torrents-without-client/|title=Качаем торренты без клиента: Bitlet, Torrent2exe, httpTorrents|website=Интернетные штучки|archive-url=https://web.archive.org/web/20091213114421/http://internetno.net/2009/12/10/torrents-without-client/|archive-date=2009-12-13}}</ref>.

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

== Web-сиды ==
Одним из вариантов использования является так называемое web-сидирование. Иногда на сервере по разным причинам нельзя запустить полноценный торрент-клиент. В этом случае в качестве источника раздачи выступает сервер, работающий по протоколу HTTP. Как правило, клиенты отдают предпочтение другим BitTorrent клиентам и обращаются к web-сиду только по необходимости. Следует знать, что реализован этот вариант использования как минимум тремя способами: [http://www.bittorrent.org/beps/bep_0017.html BEP0017 BitTornado style webseeding], [http://www.bittorrent.org/beps/bep_0019.html BEP0019 GetRight style webseeding] и [http://wiki.depthstrike.com/index.php/P2P:Protocol:Specifications:BitTorrent:External_Sourcing External Sourcing], каждый из которых отличается в деталях реализации.

Впервые был создан Джоном «TheSHAD0W» Хоффманом, который создал BitTornado<ref>{{cite web|url=http://bittornado.com/docs/webseed-spec.txt|title=HTTP-Based Seeding Specification|format=TXT|access-date=2006-05-09|archive-url=https://www.webcitation.org/6184q7Pjn?url=http://bittornado.com/docs/webseed-spec.txt|archive-date=2011-08-22|url-status=dead}}</ref>. Начиная с версии 5.0 клиент BitTorrent поддерживает веб-сиды и загрузки с веб-сайтов, был создан простой инструмент, который создаёт публикации веб-сидов торрентов. В μTorrent добавлена поддержка для получения веб-сидов в версии 1.7. В BitComet добавлена поддержка для получения веб-сидов в версии 1.14.

== BTIH (BitTorrent Info Hash) ==
Это [[SHA-1]]-[[Хеш-сумма|хеш]] поля Info из [[#Файл метаданных|файла метаданных]]. Данный [[Хеш-сумма|хеш]] используется в [[Magnet-ссылка|магнет-ссылках]], а также для идентификации на [[BitTorrent-трекер|трекере]] и между клиентами. При загрузке на [[BitTorrent-трекер|трекер]] [[#Файл метаданных|файла метаданных]] его Info Hash может измениться, так как [[BitTorrent-трекер|трекер]] может изменить поле info, установив флаг закрытой раздачи private или изменив/добавив поля внутри info. Поэтому необходимо снова скачать [[#Файл метаданных|файл метаданных]] (файл .torrent) с трекера и добавить его в клиент<ref>{{Cite web |url=rutracker.org/forum/viewtopic.php?t=215520 |title=Как начать раздачу (на примере клиента µTorrent 1.8.3.) |access-date=2010-03-02 |archive-date=2014-03-25 |archive-url=https://web.archive.org/web/20140325165917/rutracker.org/forum/viewtopic.php?t=215520 |url-status=live }}</ref>.

== BTC-ссылка ==
Указывается в виде:

<code>btc://[Адрес]: [Порт]/[Peer ID]/[ [[BitTorrent#BTIH (BitTorrent Info Hash)|BTIH]] ]</code>

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

== Недостатки и ограничения ==

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

Для поощрения раздач даже был создан BitTorrent-токен<ref>{{Cite web|lang=en|url=https://www.bittorrent.com/token/btt/|title=BitTorrent Token (BTT) {{!}} Tokenizing Decentralized File Sharing|access-date=2021-09-22|archive-date=2021-09-27|archive-url=https://web.archive.org/web/20210927004623/https://www.bittorrent.com/token/btt/|url-status=live}}</ref>.

=== Отсутствие анонимности и персонализации ===
Принцип работы BitTorrent-протокола подразумевает, что каждому участнику раздачи видны IP-адреса других клиентов, полученные от трекера или обнаруженные через дополнительные механизмы обмена пирами. Из-за этого:
* Пользователи незащищённых клиентов или систем с известными уязвимостями могут стать целью атак.
* IP-адреса людей, загружающих или раздающих конкретный файл, могут быть определены сторонними наблюдателями. Именно на этом принципе основаны сервисы, отслеживающие активность в торрентах, такие как, например, [[YouHaveDownloaded]], которые демонстрируют возможность сопоставления IP-адресов с раздаваемым контентом.

Проблема с [[аноним]]ностью может быть решена при помощи использования [[Tor]]<ref>{{Cite web |url=https://grepular.com/Making_BitTorrent_Safe_to_Use_Over_Tor |title=Making BitTorrent Safe to Use Over Tor |access-date=2013-07-31 |archive-date=2013-05-16 |archive-url=https://web.archive.org/web/20130516233753/https://grepular.com/Making_BitTorrent_Safe_to_Use_Over_Tor |url-status=live }}</ref>. BitTorrent-клиент [[Vuze]] имеет встроенную программную поддержку этой [[Анонимные сети|анонимной сети]]. Но данный метод не является стопроцентно эффективным<ref>{{Cite web |url=https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea |title=Bittorrent over Tor isn’t a good idea |access-date=2013-07-31 |archive-date=2016-10-13 |archive-url=https://web.archive.org/web/20161013120154/https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea |url-status=live }}</ref>.

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

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

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



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

== BitTorrent v2 ==
Работа над BitTorrent протоколом второй версии ведётся с 2008 года. В протоколе осуществлён уход от использования алгоритма SHA-1, имеющего проблемы с подбором коллизий, в пользу [[SHA-2]] 256. Инфо-хеш второй версии применяется как для контроля целостности блоков данных, так и для записей в индексах (info-dictionary), что нарушает совместимость в коммуникации по сети DHT новых и необновившихся клиентов, и трекеров (длина v2 хеша 32 байта, а v1 — 20 байт). Для магнитных ссылок на торренты с хэшами SHA2-256 предложен новый префикс «<nowiki>urn:btmh</nowiki>:» (для SHA-1 и гибридных торрентов используется «<nowiki>urn:btih</nowiki>:»).

Разработка спецификации BitTorrent v2 изначально велась без оглядки на обратную совместимость и в состав были приняты другие существенные улучшения, такие как использование [[Дерево Меркле|хеш-дерева Меркла]] в индексах для сокращения размера torrent-файлов и проверки загруженных данных на уровне блоков.

Из изменений в BitTorrent v2 также выделяется переход к привязке отдельных хэш-деревьев к каждому файлу и применение выравнивания файлов по частям (без добавления добавочного заполнения после каждого файла), что позволяет избавиться от дублирования данных при наличии одинаковых файлов и упрощает выявление разных источников для файлов. Тем самым решается потребность скачивания полного размера части, для проверки целостности отдельных файлов, экономя пространство и трафик. Торрент-файл содержит значения коренных хешей файлов, которые отличаются от стандартного SHA2-256 файла, эти хеши могут также быть показаны на трекерах. Это даёт возможность поиска торрентов по значению хешей файлов, что упрощает нахождение торрентов с нужными файлами, восстанавливания умирающих раздач. Они также могут быть извлечены из .torrent файлов, с помощью пользовательских программ<ref>{{cite web |title=TMRR |url=https://github.com/kovalensky/tmrr |website=github.com |publisher=kovalensky |url-status=live |access-date=2023-04-09 |archive-date=2023-04-09 |archive-url=https://web.archive.org/web/20230409153548/https://github.com/kovalensky/tmrr }}</ref>. Повышена эффективность кодирования структуры каталогов (уходом от повторения полного пути для каждого файла), уменьшая размер .torrent файла.

Для сглаживания сосуществования BitTorrent v1 и BitTorrent v2 реализована возможность создания гибридных torrent-файлов, которые включают, помимо структур с хэшами SHA-1, также индексы с SHA2-256. Гибридные торренты могут использоваться клиентами, без поддержки BitTorrent v2. Так как данные обоих протоколов вшиты в info-раздел гибридного .torrent файла, то клиенты с дополнительной поддержкой BitTorrent v2, автоматически подцепляют поддержку v2 протокола через DHT пиров (клиенты которых могут даже его не поддерживать), при этом руководствуясь только v1 хешом в магнитной ссылке. Протокол BEP-47 (выравнивание файлов по частям файлами заполнения во мнимой папке .pad) обязателен для гибридных файлов. Для решения несовместимости пользователям на первое время рекомендуется пользоваться гибридами<ref>{{Cite web|url=https://blog.libtorrent.org/2020/09/bittorrent-v2/|title=Introducing BitTorrent v2|lang=en-US|author=Arvid Nordberg|access-date=2023-08-07|archive-date=2020-10-30|archive-url=https://web.archive.org/web/20201030011550/https://blog.libtorrent.org/2020/09/bittorrent-v2/|url-status=live}}</ref>.


== WebTorrent ==

{{main|WebTorrent}}

Протокол WebTorrent позволяет скачивать файлы прямо в браузерах без необходимости устанавливать торрент клиент. Пользователи могут сами становится сидами пока открыта вкладка в браузере. Некоторые Торрент клиенты уже поддерживают раздачу пирам в WebTorrent например [[BiglyBT]] (есть версия для Android) и основанные на [[libtorrent]] такие как [[QBittorrent]], [[Deluge]] и [https://f-droid.org/ru/packages/org.proninyaroslav.libretorrent/ LibreTorrent] (Android).

== Примечания ==
{{примечания|2}}

== Ссылки ==
<!--
ВНИМАНИЕ!!!
Пожалуйста, НЕ добавляйте сюда ссылки на торрент-трекеры, архивы торрентов и т. д. — такие ссылки будут УДАЛЯТЬСЯ. Заранее спасибо.-->

{{Викиучебник|BitTorrent|BitTorrent}}
* [http://bittorrent.org/beps/bep_0003.html The BitTorrent Protocol Specification]
* [http://www.bittorrent.com/ Официальный сайт BitTorrent]
* [http://wiki.theory.org/BitTorrentSpecification Текущая спецификация протокола BitTorrent]
* {{dmoz|Computers/Internet/File_Sharing/BitTorrent/|BitTorrent}}

{{BitTorrent|state=open}}
{{IPstack|nocat=1}}

[[Категория:BitTorrent]]
[[Категория:Файлообменные сети]]
[[Категория:Файлообменные протоколы]]
[[Категория:Протоколы прикладного уровня]]

{{спам-ссылки|1=
* rutracker.org/forum/viewtopic.php?t=215520
}}