BitTorrent

Ця стаття про протокол. Стаття про клієнта: BitTorrent (програма).
Логотип BitTorrent

BitTrrent (букв. англ. " бітовий потік ") - пірінговий ( P2P) мережевий протокол для кооперативного обміну файлами через Інтернет.

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

Протокол був створений Бремом Коеном, написав перший torrent-клієнт " BitTorrent "на мові Python 4 квітня 2001. Запуск першої версії відбувся 2 липня 2001.

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


1. Файл метаданих

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

2. Принцип роботи протоколу

Принцип роботи BitTorrent: навантаження на розповсюджувача файлу зменшується завдяки тому, що клієнти починають обмінюватися даними відразу ж, навіть якщо файл не докачати ними до кінця.

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

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

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

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


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

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

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

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

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


2.2. Режим End game

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

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


2.3. Сідування

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

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

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

3. Протоколи і порти

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

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

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

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


4. Трекер

Трекер ( англ. tracker ; / Trkə (r) / ) - Спеціалізований сервер, що працює по протоколу HTTP. Трекер потрібний для того, щоб клієнти могли знайти один одного. Фактично, на трекері зберігаються IP-адреси, вхідні порти клієнтів та хеш-суми, унікальним чином ідентифікують об'єкти, що беруть участь в завантаженнях. За стандартом, імена файлів на трекері не зберігаються, і взнати їх по хеш-сумам не можна. Однак на практиці трекер часто окрім своєї основної функції виконує і функцію невеликого веб-сервера. Такий сервер зберігає файли метаданих і опису поширюваних файлів, надає статистику закачувань по різних файлах, показує поточну кількість підключених пірів і пр.


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

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

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

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

Робота без трекера також можлива при використанні мультипротокольних клієнтів, що підтримують BitTorrent. Shareaza через мережу Gnutella2 обмінюється хешамі та адресами бенкетів інших підтримуваних мереж, в тому числі BitTorrent. У GreyLink 6.0 планується підтримка BitTorrent, при цьому мережа Direct Connect може використовуватися не тільки для перетворення в TTH, але і для пошуку бенкетів.


5. Робота без торрент-клієнта

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

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


6. Web-сіди

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

Вперше був створений Джоном "TheSHAD0W" Хоффманом, який створив BitTornado [5]. Починаючи з версії 5.0 клієнт BitTorrent підтримує веб-сіди і завантаження з веб-сайтів, був створений простий інструмент, який створює публікації веб сідів торрентів. У μTorrent додана підтримка для отримання веб-сідів у версії 1.7. У BitComet додана підтримка для отримання веб-сідів у версії 1.14.


7. BTIH (BitTorrent Info Hash)

Це SHA1 хеш поля Info з файлу метаданих. Даний хеш використовується в магнет-посиланнях, а також для ідентифікації на трекері і між клієнтами. При завантаженні на трекер файлу метаданих його Info Hash може змінитися, оскільки трекер може змінити поле info, встановивши прапор закритою роздачі private або змінивши / додавши поля всередині info. Тому необхідно знову завантажити файл метаданих (файл. torrent) з трекера і додати його в клієнт [6].


8. BTC-посилання

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

btc://[Адрес]: [Порт]/[Peer ID]/[ BTIH ]

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

9. Недоліки та обмеження

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

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

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

Принцип роботи BitTorrent-протоколу передбачає, що кожному клієнту відомі IP-адреси як мінімум інших клієнтів, отримані від сервера. Використання різноманітних розширень протоколу в деяких випадках дозволяє дізнатися також і адреси інших пірів з рою. Тому:

  • Користувачі незахищених систем і клієнтів з відомими уразливими можуть бути піддані атаці.
  • Можливо дізнатися адреси користувачів, які передають або приймають певний файл.

З іншого боку, протокол не передбачає використання ніків. Відсутній чат між бенкетами. Неможливо переглянути список файлів бенкету (в пошуках інших файлів, які могли б зацікавити). Більшість цих функцій реалізовано в інших протоколах (наприклад, / DirectConnect).


9.3. Проблема лічерів

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

9.4. Відсутність точного обліку трафіку

На відміну від багатьох комерційних протоколів дистрибуції медіаконтенту, архітектура протоколу не передбачає точного механізму обліку і контролю трафіку між точками мережі. Все, що є - поля downloaded і uploaded, в яких клієнти передають при анонсі трекеру кількість байт врахованих при скачуванні / завантаженні даних з моменту попереднього анонсу. Однак не контролюємо ніким, крім як клієнтом, вони можуть бути легко підмінені. Для цього користувачі статично прописують значення цих полів у URI трекера, користуються патчами для клієнтів або ж окремими програмами (RatioMaster, GiveMeTorrent, GreedyTorrent і т. д.), або просто видаляють з клієнта запис про трекері відразу-ж після отримання з трекера списку точок мережі. Все це дозволяє обходити штучні обмеження, створювані адміністрацією багатьох приватних і публічних трекерів.


10. Термінологія

Лічер і його рій.
  • Анонс ( англ. announce ) - Звернення клієнта до трекеру допомогою HTTP-GET -запиту. При кожному анонсі клієнт передає на трекер інформацію про об'єми ним завантаженого і відданого, a трекер передає клієнтові список адрес інших клієнтів. Звернення клієнта до трекера відбувається через певні інтервали часу, які визначаються налаштуваннями клієнта і трекера.
  • Веб-сид - HTTP або FTP -сервер, який використовується як джерело даних, нарівні із звичайними сідамі
  • Доступність ( англ. availability , англ. distributed copies - Поширені копії) - кількість повних копій файлу, доступних клієнтові. Кожен сид додає 1,0 до цього числа; Лічер збільшують доступність залежно від кількості завантаженого, якого немає в інших лічерів. До прикладу, якщо на роздачі є один сид і два пірів, викачали по 50% файлу (викачані частини рівні між собою), то доступність дорівнює 1,50.
  • Затихлий ( англ. choked - Затихлий, придушений) - клієнт, обмін даними з яким заглох. Або його канал на вихід забитий повністю і він не може нічого передати (досяг max_uploads), або він є Сідом і йому нічого не потрібно отримувати.
  • Зацікавлений ( англ. interested ) - Учасник, який бажає отримати шматки файлу, наявні у іншого учасника. Наприклад, якщо у клієнта А немає якихось частин, які є у клієнта Б, вважається, що клієнт А зацікавлений в обміні з клієнтом Б.
  • Надлишки - дані, які були послані бенкетом або сідом, але одержувач їх не потребує. До надлишкам також відносяться помилки хешу.
  • Індекс ( англ. index ) - Це список. Torrent-файлів (зазвичай включає описи та іншу інформацію), керований веб-сайтом (індексатор) і доступний для пошуку. Індексує сайти часто помилково називають трекером.
  • Ліч, іноді лічер ( англ. leech - П'явка) - бенкет, не має поки всіх сегментів, тобто продовжує скачування. Термін часто вживається і в негативному сенсі, який він має в інших файлообмінних мережах: користувач, який віддає значно менше, ніж викачує.
  • Отруєний торрент - ситуація, коли частина бенкетів роздає пошкоджені, або спеціально сфальсифіковані сегменти.
  • Бенкет ( англ. peer - Співучасник) - клієнт, бере участь в роздачі.
  • Пошкребти ( англ. scrape - Шкребти, дряпати) - процес, аналогічний анонсу, але клієнт запитує тільки статистику торрента, інформацію про підключені клієнтів і можливості з ними зв'язатися для обміну.
  • Необачливий ( англ. snubbed ) - Клієнт, підключений до одержувача, але не надсилав йому дані вже більше 60 секунд.
  • Роздача ( англ. seeding ) - Процес поширення файлу по протоколу BitTorrent.
  • Рейтинг ( англ. share ratio ) - Відношення відданого до викачаного.
  • Рой ( англ. swarm ) - Сукупність всіх пірів, що беруть участь в роздачі.
  • Сегмент ( англ. part - Частина) - всі файли для передачі діляться на невеликі шматки - сегменти, які, потім, передаються по мережі в довільному порядку для оптимізації обміну.
  • Сід, іноді сідер ( англ. seeder - Сіяч) - бенкет, має всі сегменти поширюваного файлу, тобто або початковий розповсюджувач файлу, або вже викачав весь файл і залишився на роздачі.
  • Супер-сідерну роздачу - спеціальний режим роздачі в деяких BitTorrent-клієнтах, намагається мінімізувати кількість даних, яке віддасть роздає до появи першого завантажившого. Суперсід пропонує кожному бенкеті завантажити тільки один сегмент файлу, якого ще немає в інших бенкетів. Потім сид не дає цьому бенкеті наступних сегментів, поки не отримає від інших бенкетів підтвердження, що вони теж отримали цей сегмент. Таким чином, суперсід намагається уникнути повторної віддачі одних і тих же сегментів, і намагається віддавати сегменти тільки тим бенкетам, які активно передають їх іншим.
  • Хеш ( англ. hash ) - SHA1 окремих сегментів оригінальних файлів, перерахованих в словнику "info". torrent-файлу. Кожна частина після отримання спочатку перевіряється на збіг хешу. Якщо перевірка не вдалася, дані відкидаються і запитуються ще раз. Також в протоколі використовується хеш самого словника "info" ("інфохеш"), виступаючий в ролі ідентифікатора конкретної роздачі при зверненні до трекера, до інших точок мережі, і при складанні magnet-посилань (він містять Base32 -вистава інфохеша).
  • Passkey - аутентіфікатор користувача на неанонімних трекерах. Міститься в викачуваних torrent-файлі. Таким чином, якщо хтось отримає доступ до torrent-файлу (наприклад, користувач по необережності Разшарив його), він зможе працювати з трекером від імені цього користувача. Трекер може змінити passkey по запиту користувача, але при цьому необхідно буде перескачать всі минулі torrent-файли (або вручну відредагувати їх), щоб мати можливість і далі роздавати викачані файли.
  • URL анонса ( англ. announce URL ) - Адреса трекера, до якого клієнт робить анонс. У багатьох клієнтах називається "Tracker URL". Може включати "passkey" - унікальний код, що призначається трекером для аккаунта користувача, допомагає ідентифікувати його на трекері (додається до URL анонса в самому *. Torrent-файлі при скачуванні).

Примітки

  1. BitTorrent Specification: End Game - wiki.theory.org / BitTorrentSpecification # End_Game
  2. HAL - INRIA :: [inria-00000156, version 3] Understanding BitTorrent: An Experimental Perspective - hal.inria.fr/inria-00000156/en
  3. What is DHT? / / Torrent FAQ - www.utorrent.com / faq.php # What_is_DHT.3F
  4. Інтернетні штучки "Качаємо торренти без клієнта: Bitlet, Torrent2exe, httpTorrents - internetno.net/2009/12/10/torrents-without-client /
  5. HTTP-Based Seeding Specification - bittornado.com / docs / webseed-spec.txt (TXT). Читальний - www.webcitation.org/6184q7Pjn з першоджерела 22 серпня 2011.
  6. Як почати роздачу (на прикладі клієнта μTorrent 1.8.3.) - rutracker.org / forum / viewtopic.php? t = 215520