BitTorrent

 

BitTorrent ( «потік бітів») - пірінговий (P2P) мережевий протокол, який використовується для кооперативного обміну файлами за допомогою мережі Інтернет. Передача файлів здійснюється частинами, кожен torrent-клієнт, викачувавши ці частини, в той же час здійснює роздачу їх для інших клієнтів. Це істотно скорочує навантаження і залежність від кожного клієнта-джерела.

Автор:

 

alterbit.ru

8 хв

Переглянути оригінал

Протокол bitTorrent був створений Бремом Коеном. Він написав перший torrent-клієнт «BitTorrent» на мові Python 4 квітня 2001 року. Перша версія була запущена 2 липня 2001 року.

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

Принципи роботи

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

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

Щоб мережа BitTorrent працювала ефективно, потрібно якомога більше приймають вхідні з'єднання клієнтів.

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

Так, обсяг службової інформації прямим чином залежить від кількості і розміру сегментів.

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

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

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

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

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

Режим End game

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

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

сидирування

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

характерні особливості

• Немає черг на скачування;
• Закачування файлу відбувається невеликими фрагментами;
• Клієнти здійснюють обмін сегментами між собою за принципом «ти - мені, я - тобі»;
• Скачані фрагменти відразу стають доступними іншим клієнтам;
• Здійснюється контроль цілісності кожного фрагмента;
• На фрагменти розбивається вся роздача повністю, а не окремі файли;
• Об'єктом роздачі можуть виступати декілька файлів.

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

З'єднання клієнтів з трекером здійснюється по протоколу TCP.

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

У специфікації протоколу номера портів не фіксуються і можуть змінюватися, якщо буде потреба. В даний час, більшість трекерів користуються звичайним HTTP портом 80, для клієнтів рекомендується випадковий вхідний порт. Крім того, деякі трекери не допускають використання портів клієнтів з стандартного діапазону 6881-6889, оскільки деякі провайдери забороняють використання даного діапазону портів. DHT-мережу в BitTorrent-клієнтах використовує протокол UDP. Протокол UDP застосовується UDP-трекера, але підтримуються вони не всіма клієнтами, оскільки не є офіційною частиною самого протоколу. Для з'єднання клієнтів один з одним застосовується UDP NAT Traversal.

Трекер

Трекер - спец сервер, що функціонує на протоколі HTTP. Для чого потрібно трекер? Щоб клієнти могли знаходити один одного. По суті, на трекері відбувається зберігання IP-адрес, що входять портів клієнтів і хеш-суми. Відповідно до стандарту, імена файлів на трекері не зберігається, тому розпізнати їх по хеш-сумам не можна. Однак на практиці трекер, крім своєї основної функції, найчастіше є своєрідним невеликим веб-сервером. Цей сервер зберігає файли метаданих і опису поширюваних файлів, надає статистику закачувань по різних файлах, відображає поточну кількість підключених бенкетів і т.д.

Без трекера

Нові версії протоколу є бестрекерной системами, це вирішує деякі з «старих» проблем. Наприклад, відмова трекера в таких системах не призводить до відмови всієї мережі.

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

В даний час, не всі клієнти застосовують сумісний між собою протокол.

Сумісні: BitComet, μTorrent, Deluge, KTorrent, Transmission і офіційний клієнт BitTorrent.

Функціонування без трекера можливо і при використанні мультипротокольних клієнтів з підтримкою BitTorrent. Наприклад, Shareaza за допомогою мережі Gnutella2, обмінюється хешамі і адресами бенкетів інших підтримуваних мереж.

Без торрент-клиента

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

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

Web-сіди

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

BTIH (BitTorrent Info Hash)

BTIH - це SHA1 хеш поля Info з файлу метаданих. Він використовується в Magnet-посилання, а також для ідентифікації на трекері і між клієнтами. В ході завантаження на трекер файлу метаданих його Info Hash може змінитися через те, що трекер може змінити поле info, встановивши прапор закритою роздачі private або змінивши поля всередині info. Ось чому так необхідно викачувати файл метаданих (файл .torrent) заново з трекера і добавляеть його безпосередньо в клієнт.

недоліки BitTorrent

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

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

Ніякої анонімності і персоналізації

Згідно з принципами роботи BitTorrent-протоколу, кожному клієнту відомі IP-адреси інших клієнтів. Застосування різних розширень протоколу в деяких випадках дозволяє дізнатися навіть адреси інших бенкетів.

Так:

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

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

Проблема личеров

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

Немає точного обліку трафіку

Архітектурою протоколу не передбачено точного механізму обліку і контролю трафіку між точками мережі. Є тільки два поля: downloaded та uploaded, в них клієнти передають при анонсі трекеру кількість байт врахованих при скачуванні / завантаженні даних з моменту попереднього анонсу. Вони не контролюються ніким, крім клієнта, і відповідно, можуть бути легко підмінені. Для цього користувачі статично прописують значення цих полів в URI трекера, користуються патчами для клієнтів або ж окремими програмами, або ж просто видаляють з клієнта запис про трекер після отримання з трекера списку точок мережі. Це дозволяє обходити створені адміністрацією багатьох приватних і публічних трекерів штучні обмеження.