Желаемое и действительное

Несколько ловких финтов ушами Один удачный маркетинговый ход – и старый добрый Bittorrent «получил новую версию» и, надо полагать, серьезный апгрейд. Тем более что разработка BEP 52 (The BitTorrent Protocol Specification v2) началась 14 лет назад. Вероятно, всё уже отлажено и протестировано и всем нужно быстро перейти на новую версию и получать профит? Но на деле все обстоит совершенно не так.

Протокол Bittorrent v2 был придуман и реализован разработчиками библиотеки libtorrent-rasterbar (используемой в некоторых популярных торрент-клиентах – Deluge, qBittorrent, Transmission). Судя по всему, его создание изначально было частной инициативой узкого круга разработчиков и никогда широко не обсуждалось в сообществе. Реального тестирования тоже не было – для этого необходимо было набрать определенный набор статистики в «полевых испытаниях», из которой можно наделать наглядных табличек и сделать прямые сравнительные выводы по обоим версиям.

Для проведения испытаний нового протокола разработчики решили добровольно-принудительно привлечь лабораторных крыс своих пользователей. В (как минимум) новых версиях qBittorrent по умолчанию производится создание гибридных .torrent-файлов – без какого-либо уведомления или разъяснения этого факта. Вроде бы ничего страшного (исключая увеличенный в несколько раз размер) – ведь по заявлениям разработчиков гибридные торренты содержат в себе метаданные обоих версий. Можно предположить, что гибридные торренты можно использовать так же, как и торренты старых версий, но это не так!

Добавление гибридного торрента в клиент, не использующий libtorrent-rasterbar, скорее всего завершится ошибкой. На примере rtorrent видно, что гибридные .torrent-файлы содержат некорректные с точки зрения v1 данные (в частности, файлы .pad, являющиеся «костылями», дополняющими каждый файл версии 2 до размера блока). Очевидно, что заявленная обратная совместимость работает только в рамках libtorrent-rasterbar.

Собственно, именно «сломанная» обратная совместимость и послужила причиной написания данной статьи. Мы не в первый раз получаем жалобы типа «я сделал .torrent в домашнем клиенте, но в сидбоксе он почему-то не работает, хотя я все делал как обычно». По факту пользователи просто не обращают внимания на то, что в обновленной версии их торрент-клиента формат создаваемых torrent-файлов стал другим – несовместимым с другими клиентами.

А как бывает обычно? Внедрение новых версий протоколов происходит постепенно, с соблюдением требований обратной совместимости и незаметно для пользователей – если это делается правильно, а не как в Bittorrent v2. Годный пример верного подхода – это HTTP/2. Далеко не все о нем слышали, но он есть и уже часто встречается в наших браузерах.

Что же в итоге нам предлагает Брэм Ко́эн (кстати, автор оригинальной концепции Bittorrent и первых версий одноименного клиента) сотоварищи? Фактически это еще один Bittorrent, не совместимый с привычной нам версией абсолютно ни в чем – другой формат метаданных, другие хэши и, как следствие, разделение swarm (участников обмена данными) на 2 пула (по поддерживаемым версиям) и даже другой протокол обмена данными между пирами/анонсерами. Но, может быть, результат стоит того?

Насколько всё это актуально?

Проблема хэш-коллизий в Bittorrent

Основной «идентификатор» любого торрента – это его хэш. Для любой хэш-функции возможна коллизия – когда одно и то же значение хэша определяет 2 разных раздачи. В экосистеме Bittorrent не заложены механизмы разрешения коллизий, поэтому кажется логичным использование как можно более «устойчивой» к коллизиям хэш-функции.

Коллизии возможны и они встречаются – в 2017 г. в блоге Google был опубликован материал о первой(!) зарегистрированной коллизии SHA-1. Однако, судя по всему, это был единичный случай – с тех пор повторных публикаций по данной теме не было. Протокол Bittorrent широко используется уже не первый десяток лет и давно занял свою устойчивую нишу – что позволяет предположить, что никакого массового экспоненциального роста количества торрентов не будет – а значит не будет и хоть какого-то заметного на практике увеличения частоты коллизий.

Стоит отметить, что фактически коллизия проявляется только тогда, когда разные торренты с одинаковыми хэшами «оказываются» в одном торрент-клиенте или на одном торрент-трекере. Ввиду большой децентрализации Bittorrent вероятность коллизии сильно снижена – к примеру, 2 пользователя наших сидбоксов могут беспроблемно раздавать 2 разные раздачи с одним и тем же хэшем, если они используют разные трекеры или анонсеры. По факту, за более чем 10 лет нашего существования, проблема коллизии ни разу не была зарегистрирована.

Повторно скачиваемые блоки

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

С другой стороны, малый размер блока означает большое их количество – и, соответственно, большой .torrent-файл. Многие торрент-трекеры имеют ограничение на его размер, поскольку это увеличивает нагрузку и на трекер и на анонсеры. Малый размер блока также увеличивает объем обмена служебными данными между пирами/анонсерами, фрагментацию файловой системы, количество операций (iops) дискового ввода-вывода и менее эффективно использует пропускную способность сетевого подключения. Все это негативным образом сказывается на производительности торрент-клиента.

Насколько важно в современных реалиях учитывать «синдром повторной загрузки испорченных блоков»? Удивительно, но нам не удалось найти ни релевантной статистики в торрент-клиентах, ни соответствующих дискуссий. Самое близкое – это широко обсуждавшиеся примерно десять лет назад вопросы типа «High wasted on a torrent download» или «Lots of skipped data». Однако они относятся к совершенно другой проблеме, приводившей к отправке пирами «лишних» данных.

Кроме того, проблема коррекции передаваемых по сети пакетов – задача сетевых протоколов, а не прикладных приложений. Если сетевое соединение настолько «плохое», что торрент-клиенту приходится часто перекачивать блоки, то проблемы будут так же часто наблюдаться в браузерах, в мессенджерах, в клиентах облачных хранилищ и т.д.

Эпоха «интернета по лапше» давно ушла в прошлое – вместе с обычаем разбивать архивы на мелкие части. На практике мы никогда не наблюдали проблем с торрентами с большим размером блока (32МБ и более), поэтому кардинальное усложнение протокола ради «решения» крайне редко встречающихся проблем нам кажется совершенно ненужным. Если метаданных торрента «слишком много», то достаточно просто взять блок побольше.

Размер торрент-файла

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

Мы решили сравнить размеры .torrent-файлов для обоих версий (плюс «гибридной», об этом дальше) на практике. Размер исходной папки – 170МБ (17 подпапок, 700+ файлов), размер блока – 1МБ. Со скриншота видно, что размер для версии v2 больше в 1.4, а для гибридной – в 3.5 раза! Практически на любом наборе исходных файлов «новые» торренты будут заметно «тяжелее».

Перспективы протокола

Очевидно, что v2 был спроектирован не как развитие v1, а как его потенциальная замена. Древовидная организация метаданных и более устойчивая к коллизиям хэш-функция – несомненные плюсы. Но есть и много минусов, главные из которых – отсутствие обратной совместимости, увеличение размера .torrent-файлов и больши́е временны́е затраты на реализацию и отладку v2 в торрент-клиентах и трекерах.

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