BitTorrent (протокол)

Файли передаються частинами, кожен torrent-клієнт, отримуючи (завантажуючи) ці частини, водночас віддає (закачує) їх іншим клієнтам, що знижує навантаження і залежність від кожного клієнта-джерела та забезпечує надмірність даних.

Існує безліч інших програм-клієнтів для обміну файлами за протоколом BitTorrent.

Зміст

Файл метаданих є словником у форматі bencode з розширенням .torrent — містить інформацію про роздачу (файли, трекери та ін.)

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

При з'єднанні клієнти одночасно обмінюються інформацією про наявні в них сегменти. Клієнт, який бажає завантажити сегмент (лічер), надсилає запит і, якщо другий клієнт готовий віддавати, отримує цей сегмент. Після цього клієнт перевіряє контрольну суму сегмента. Якщо вона збіглася з тією, що записана в торрент-файлі, то сегмент вважається успішно завантаженим, і клієнт повідомляє всіх приєднаних бенкетів про наявність у нього цього сегмента. Якщо ж контрольні суми різняться, то сегмент починає завантажуватися заново. Деякі клієнти банять тих бенкетів, які надто часто віддають некоректні сегменти.

Таким чином, обсяг службової інформації (розмір торрент-файлу та розмір повідомлень зі списком сегментів) безпосередньо залежить від кількості, а отже, і розміру сегментів. Тому при виборі сегмента необхідно дотримуватися балансу: з одного боку, привеликому розмірі сегмента обсяг службової інформації буде меншим, але у разі помилки перевірки контрольної суми доведеться заново завантажувати більше інформації. З іншого боку, при малому розмірі помилки не такі критичні, оскільки необхідно заново завантажити менший обсяг, зате розмір торрент-файла і повідомлень про наявні сегменти стає більше.

Алгоритм обміну даними

Кожен клієнт має можливість тимчасово блокувати віддачу іншому клієнту (choke). Це робиться для ефективнішого використання каналу віддачі. Крім того, при виборі — кого розблокувати, перевага надається бенкетам, які самі передали цьому клієнту багато сегментів. Таким чином, бенкети з хорошими швидкостями віддачі заохочують один одного за принципом «ти мені, я тобі».

Обмін сегментами ведеться за принципом "ти - мені, я - тобі" симетрично у двох напрямках. Клієнти повідомляють один одному про наявні у них сегменти при підключенні і потім при отриманні нових сегментів, і тому кожен клієнт може зберігати інформацію про те, які сегменти мають інші підключені бенкети. Порядок обміну вибирається таким чином, щоб спочатку клієнти обмінювалися найрідкіснішими сегментами: таким чином підвищується доступність файлів у роздачі. У той же час вибір сегмента серед найбільш рідкісних випадків, і тому можна уникнути ситуації, коли всі клієнти починають скачувати один і той самий рідкісний сегмент, що негативно позначилося б на продуктивності.

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

Сегменти поділяються на блоки розміром 16-4096 кілобайт [джерело не вказано 547 днів] , і кожен клієнт запитує саме ці блоки. Одночасно можуть вимагати блоки з різних сегментів. Більше того, деякі клієнти підтримують завантаження блоків одного сегмента у різних бенкетів. У цьому випадку описані вище алгоритми та механізми обміну застосовуються і до рівня блоків.

Режим End game

Коли завантаження майже завершено, клієнт входить у особливий режим, званий end game. У цьому режимі він запитує всі сегменти, що залишилися, у всіх підключених бенкетів, що дозволяє уникнути уповільнення або повного «зависання» майже завершеного закачування через кілька повільних клієнтів.

Специфікація протоколу не визначає, коли клієнт повинен увійти в режим «end game», проте існує набір загальноприйнятих практик. Деякі клієнти входять в цей режим, коли не залишилося незапитаних блоків, інші — поки кількість блоків, що залишилися, менша за кількість переданих і не більше 20. Існує негласна думка, що краще підтримувати кількість очікуваних блоків низьким (1 або 2) для мінімізації надмірності, і що при випадковому запиті менший шанс отримати дублікати одного і того ж блоку [1] [2] .

Сидіння

Загальні особливості

Відсутність черг на завантаження.
Файли закачуються невеликими фрагментами; що менше доступний фрагмент, то частіше він передаватиметься. Таким чином, присутність у мережі «сидера» з повним файлом для завантаження необов'язково — система розподіляє сегменти між «бенкетами», щоб у подальшому вони могли обмінюватися сегментами, що бракують.
Клієнти (peers) обмінюються сегментами безпосередньо між собою,принципу «ти мені, я тобі».
Завантажені фрагменти стають негайно доступними для інших клієнтів.
Контролюється цілісність кожного фрагмента.
На фрагменти розбиваються не окремі файли, а вся роздача цілком, тому в «лічері», який побажав завантажити лише деякі файли з роздачі, для підтримки цілісності фрагментів нерідко зберігатиметься також невеликий обсяг надлишкової (для нього) інформації.
Як об'єкт роздачі можуть виступати кілька файлів (наприклад, вміст каталогу).

Клієнти з'єднуються з трекером за протоколом TCP. Найчастіше використовуваний вхідний порт трекера: 6969. Найчастіше використовуваний діапазон вхідних портів клієнтів: 6881-6889.

Номери портів не фіксуються у специфікації протоколу і можуть змінюватись за потреби. В даний момент більшість трекерів використовують звичайний HTTP порт 80, а для клієнтів рекомендується вибрати випадковий порт. Більше того, деякі трекери не допускають використання портів клієнтів зі стандартного діапазону 6881-6889, оскільки деякі провайдери забороняють використання цього порту.

DHT-мережа в BitTorrent-клієнтах використовує протокол UDP.

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

Робота без трекера

У нових версіях протоколу були розроблені безтрекерні (англ. trackerless) системи, які вирішують деякі з попередніх проблем. Відмова трекера в таких системах не призводить до автоматичної відмови всієї мережі.

Починаючи з версії 4.2.0 офіційногоклієнта, випущеної наприкінці 2015 року, реалізовано функцію безтрекерної роботи, яка базується на DHT Kademlia. У такій реалізації трекер доступний децентралізовано на клієнтах у формі розподіленої хеш-таблиці.

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

Для того, щоб брати і роздавати файли в торрент-мережах, не обов'язково користуватися спеціальними програмами. Існує кілька сервісів, які дозволяють завантажувати файли, використовуючи лише браузер [4] .

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

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

Вказується у вигляді:

Посилання такого виду посилається на роздачу та її джерело. Підтримується у Shareaza.

Недоступність роздачі

Якщо роздача непопулярна, то може виникнути ситуація, коли немає жодного сиду, а даних у присутніх бенкетів не вистачає, щоб завершити скачування. У разі необхідно чекати появи або сиду, або бенкету, має сегменти, відсутні в інших. Також можна використовувати копії файлів, отримані іншим шляхом. Роздача, яка не має жодного сиду довгий час, називається «мертвою».

Відсутність анонімності та персоналізації

Проблему з анонімністю можна вирішити за допомогою використання Tor [7] . BitTorrent-клієнт Vuze має вбудовану програмну підтримку цієї анонімної мережі. Але цей метод не є повністю ефективним [8] .

Проблема лікерів

Деякі користувачі, особливо на трекерах, що не вимагають реєстрації, не підтримують роздачу після завершення скачування, що веде до зменшення загальної продуктивності, тому деякі торрент-трекери враховують і кількість завантаженого/відданого, і видають дозвіл на скачування залежно від розміру відданих клієнтом даних.