Bit Torrent.
BitTórrent (букв. англ. «битовый поток») — пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет.
Файлы передаются частями, каждый torrent-клиент, получая (скачивая) эти части, в то же время отдаёт (закачивает) их другим клиентам, что снижа-ет нагрузку и зависимость от каждого клиента-источника и обеспечивает из-быточность данных. Протокол был создан Брэмом Коэном, написавшим пер-вый torrent-клиент «BitTorrent» на языке Python 4 апреля 2001 года. Запуск первой версии состоялся 2 июля 2001 года. Файл метаданных Для каждой раздачи создаётся файл метаданных с расширением .torrent, который содержит следующую информацию: - URL трекера; ¬- Общую информацию о файлах (имя, длину и пр.) в данной раздаче; - Контрольные суммы (точнее, хеш-суммы SHA1) сегментов раздавае-мых файлов; - Passkey пользователя, если он зарегистрирован на данном трекере.
Длина ключа устанавливается трекером.
Необязательно: - Хеш-суммы файлов целиком; - Альтернативные источники, работающие не по протоколу BitTorrent.
Наиболее распространена поддержка так называемых web–сидов (протокол HTTP), но допустимыми также являются ftp, ed2k, magnet URI. Файл метаданных является словарём в bencode формате.
Файлы мета-данных могут распространяться через любые каналы связи: они (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публико-ваться в блогах или новостных лентах RSS. Также есть возможность полу-чить info часть публичного файла метаданных напрямую от других участни-ков раздачи благодаря расширению протокола "Extension for Peers to Send Metadata Files". Это позволяет обойтись публикацией только магнет-ссылки.
Получив каким-либо образом файл с метаданными, клиент может начинать скачивание. Принцип работы протокола Перед началом скачивания клиент подсоединяется к трекеру по адресу, указанному в торрент-файле, сообщает ему свой адрес и хеш-сумму торрент-файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует тре-кер о ходе процесса и получает обновлённый список адресов.
Этот процесс называется объявлением (англ. announce). Клиенты соединяются друг с другом и обмениваются сегментами фай-лов без непосредственного участия трекера, который лишь хранит информа-цию, полученную от подключенных к обмену клиентов, список самих клиен-тов и другую статистическую информацию. Для эффективной работы сети BitTorrent необходимо, чтобы как можно больше клиентов были способны принимать входящие соединения.
Неправильная настройка NAT или бранд-мауэра могут этому помешать. При соединении клиенты сразу обмениваются информацией об имею-щихся у них сегментах. Клиент, желающий скачать сегмент (личер), посыла-ет запрос и, если второй клиент готов отдавать, получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента. Если она совпала с той, что записана в торрент-файле, то сегмент считается успешно скачанным, и клиент оповещает всех присоединённых пиров о наличии у него этого сег-мента.
Если же контрольные суммы различаются, то сегмент начинает скачи-ваться заново. Некоторые клиенты банят тех пиров, которые слишком часто отдают некорректные сегменты. Таким образом, объём служебной информации (размер торрент-файла и размер сообщений со списком сегментов) напрямую зависит от количества, а значит, и размера сегментов. Поэтому при выборе сегмента необходимо со-блюдать баланс: с одной стороны, при большом размере сегмента объём служебной информации будет меньше, но в случае ошибки проверки кон-трольной суммы придется скачивать ещё раз больше информации.
С другой стороны, при малом размере ошибки не так критичны, так как необходимо заново скачать меньший объём, но зато размер торрент-файла и сообщений об имеющихся сегментах становится больше. Когда скачивание почти завершено, клиент входит в особый режим, на-зываемый end game. В этом режиме он запрашивает все оставшиеся сегменты у всех подключенных пиров, что позволяет избежать замедления или полного «зависания» почти завершенной закачки из-за нескольких медленных клиен-тов. Спецификация протокола не определяет, когда именно клиент должен войти в режим end game, однако существует набор общепринятых практик.
Некоторые клиенты входят в этот режим, когда не осталось незапрошенных блоков, другие — пока количество оставшихся блоков меньше количества передающихся и не больше 20. Существует негласное мнение, что лучше поддерживать количество ожидаемых блоков низким (1 или 2) для миними-зации избыточности, и что при случайном запрашивании меньший шанс по-лучить дубликаты одного и того же блока.
Недостатки и ограничения • Недоступность раздачи – если нет раздающих пользовате-лей(сидов); • Отсутствие анонимности: - пользователи незащищенных систем и клиентов с извест-ными уязвимостями могут быть подвергнуты атаке. - возможно узнать адреса пользователей, обменивающихся контрафактным контентом и подать на них в суд. • Проблема личеров – клиентов, которые раздают гораздо меньше, чем скачивают.
Это ведёт к падению производитель-ности. • Проблема читеров – пользователей, модифицирующих ин-формацию о количестве скачанныхпереданных данных. • Персонализация – протокол не поддерживает ников, чата, просмотра списка файлов пользователя. 4.