Длительное и достаточно активное использование файлообмена на основе протокола BitTorrent не может порой не вызывать некоторого недоумения на предмет его неудобства, непродуманности, стойкого дискомфорта при работе – особенно, когда дело касается раздачи материалов.
Исторически до выхода на большую сцену торрент-файлообмена существовали несколько файлообменных сетей, среди которых до наших дней дожили eDonkey и DC++. Однако в последних по причине централизованности установления контактов между участниками существовала серьёзная проблема очередей на доступ у раздаваемому материалу, что было неудобно. Кроме этого, в то время имели место быть невысокие скорости обмена данными – проблема, конечно, не имеющая отношения к протоколу, но в совокупности сказанное приводило к низкой интегральной эффективности существующих файлообменных сетей. В 2004-м году начал стремительно набирать обороты файлообмен на основе протокола BitTorrent, первая спецификация которого появилась тремя годами ранее. На ранних этапах это был полудецентрализованный сервис, также предполагавший обращение пользователя-получателя файла к определённым серверам – торрент-трекерам – с поисковыми запросами на наличие фрагментов принимаемого файла у других участников файлообмена. Вскоре, протокол был улучшен алгоритмами DHT (Kademlia), долгожданным PeX, превращающим протокол в по-настоящему децентрализованный, LSD и, наконец, uTP. В результате BitTorrent превратился в надёжное, стопроцентно работающее, стойкое к блокирующим действиям средство файлообмена но… суть осталась той же: BitTorrent неудобен. Протокол стал настолько популярен и широко распространён, что на фоне этой успешности пользователи перестали замечать его принципиальные недостатки, не позволящие считать его отличным средством файлообмена в современных вычислительных сетях. Итак, в чём здесь дело?
Протокол предполагает следующий подход (см. рисунок).
Рисунок — Структура файлообмена в BitTorrent-сети
Обязательным является наличие файла-описателя – торрент-файла. Иногда его называют „метафайлом раздачи“. Количество информационных блоков, содержащихся в метафайле, в принципе, ничем не ограничено, но обязательным является указание:
- объёма и файловой структуры раздаваемого/принимаемого материала;
- размера и количества фрагментов раздаваемого/принимаемого материала;
- хеш-суммы каждого фрагмента раздаваемого/принимаемого материала.
Это так называемая „инфо-секция“ торрент файла, без знания которой нельзя начать файлообмен. Дополнительные секции могут содержать ссылки на торрент-трекеры, комментарии и пр.
Изъяны реализации протокола
1. Для отдачи/скачивания контента требуется дополнительный файл-описатель раздачи. Даже если для скачивания контента используются магнет-ссылки, всё равно они указывают не на контент, а лишь на торрент-файл.
Сказанное требует наличия некоторого централизованного сервиса, хранящего торрент-файлы всех раздач. С появлением магнет-ссылок указанный недостаток несколько сгладился, но проблема централизации осталась. Магнет-ссылки более компактны и удобны, но плохо, что это лишь ещё одно звено в цепи между получателем контента и его источником. Исключением в контексте проблем, связанных с централизацией, на данный момент является разве что Tribler.
2. Торрент-файл содержит не хеш(-и) всего файла (группы файлов), а хеши фрагментов раздаваемого материала.
Причина такой ситуации ясна: BitTorrent-протокол в целях децентрализации файлообмена предполагает раздачу материала небольшими кусочками. Но почему бы в торрент-файле не сделать обязательным ещё одно поле, содержащее хеш-сумму цельного файла или хеш-суммы всех раздаваемых файлов? Как результат: пользователь не имеет возможности быстро определить, что же реально раздаётся через данный конкретный торрент, пока не скачает материал. В данном случае остаётся лишь довериться тому централизованному сервису, с которого взят торрент-файл. Хеш-сумма, содержащаяся в магнет-ссылке в этом нисколько не помогает, так как она является результатом хеширования инфо-секции торрент-файла, но не самого раздаваемого материала.
3. Размер фрагментов раздачи могут быть произвольными и, чаще всего, находятся в пределах от 64 кБ до 16 МБ.
Как результат: для одной и ой же раздачи торрент-файлы могут быть совершенно различными, следовательно, и магнет-ссылки на них будут содержать различные хеш-суммы. При создании торрент файла каждый волен выбирать, каким будет объём фрагмента. Чаще это делает клиентская программа автоматически на основе информации об объёме раздаваемого контента, но каждый клиент делает это по-своему. Такая неопределённость и неоднозначность вносит дополнительную путаницу в процесс файлообмена. Нередки случаи, когда пользователь желает поддержать редкую раздачу, сформировав собственный метафайл на неё. Однако в силу различия в размерах фрагментов, указанных в его метафайле и метафайле, находящемся на том или ином ресурсе в открытой сети, он ничего не сможет раздать, так как технически оба торрента указывают на различные раздачи.
Изъяны реализации клиент-серверов
1. Торрент файл, загруженный в клиент-сервер, должен точно указывать на раздаваемый материал.
Изменение имени файла(-ов) или пути к раздаваемому материалу – например, при переносе в другую папку – делает раздачу неработоспособной или, что хуже, заново скачивает контент в то же самое место. Удаление материала раздачи с жёсткого диска также требует удаления метафайла из торрент-клиента. При большом количестве раздач такие манипуляции не могут не вызывать раздражения. Безусловно, некоторые клиенты – например, qBittorrent – дают возможность переименовать файлы в раздача, но делается это в ручном режиме, что нельзя назвать оптимальным решением.
2. Нет возможности открыть доступ к папаке с множеством файлов, подлежащих раздаче.
Таким образом, каждый файл, подлежащий раздаче, требует:
- создания отдельного метафайла;
- публикации метафайла на торрент-портале;
- связывания сгенерированного метафайла с конкретным локальным файлом
и, наконец,
- неусыпного контроля за торрент-клиентом и локальными файлами.
Для большого количества раздаваемого материала такая процедура разделения ресурсов чудовищна по трудоёмкости. (Хвала тем людям, которые находят время и силы для формирования и поддержания большого количества раздач, что, без сомнения, делает наш мир лучше).
3. Отсутствует возможность децентрализованного поиска файлов по имени или хеш-суммам.
Требуется постоянное обращение к торрент-порталам в Интернете для поиска желаемого материала. На фоне современных тенденций в файлообмене это выглядит нелепо. Нет доступа к порталу, где хранятся торрент-файлы, – нет контента. В свете последних тенденций это не только нерационально, но и опасно. Не зря в течение последних нескольких лет появились базы данных с хеш-суммами инфо-секций всех метафайлов, опубликованных на крупнейших порталах. Справедливости ради, следует отметить, что в некоторых клиентах имеется встроенный поиск – как в упомянутом qBittorrent, – но всё равно при осуществлении поиска обращение идёт к определённым сайтам в Интернете. Иключение среди открытых продуктов одно – Tribler.
4. Если донор и реципиент файла находятся за непрозрачными роутерами, файлообмен не состоится.
Протоколом не предусматривается решение проблемы „проброса“ портов, не привлекаются различные подходы к установлению соединения, не синтезируется соответствующая топология сети. В современных файлообменных сетях проблеме уделяется должное внимание, решения имеются и, в большинстве случаев, отдача файла(-ов) начнётся.
А какие же альтернативы? Для примера приводится полная ссылка на видеофайл в шифрованной сети RetroShare: „retroshare://file?name=Rising%20arrows%20(2010).mp4&size=75967501&hash=2d34dfbba466a9974ce49bd489f505bf904395b2“. В представленной ссылке имеется
- имя файла – допустим поиск по имени или фрагменту имени файла, а также расширению;
- объём файла в байтах – поиск по запросу не больше (не меньше) определённого объёма;
- уникальная хеш-сумма файла – пользователь может её сохранить и позднее быть уверенным в том, что он качает именно тот файл, который ему нужен.
Аналогичная ссылка для сети eDonkey: „ed2k://|file|Centos-7.0-1406-x86%2064-Everything.iso|7062159360|D849C30B8D630470FB9C9F74AB11D9ED|/“. Для скачивания никаких вспомогательных файлов не требуется; доступ к ресурсам открывается целыми папками; система сама отслеживает изменения файлов в разделяемых папках.
Заключение
BitTorrent как протокол и файлообмен на его основе, возможно, неплохо адаптирован к потребителю контента. Однако в силу его изначально дефективной специфики, данный протокол ни в коей мере нельзя назвать удобным и эффективным средством для распространителя контента.
Материал статьи может незначительно изменяться и дополняться
adorabilis 