АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Огляд досліджень щодо архітектури однорангових мереж

Читайте также:
  1. NETSUKUKU — концепція публічних мереж
  2. Аналітичний огляд наукових публікацій на тему : «Процентна політика НБУ та оцінка її ефективності»
  3. Апаратні і програмні засоби Internet. Протоколи TCP/IP. Доступ користувачів до мережі Internet, система адресації у мережі Internet.
  4. Архітектурна специфіка розосереджених та однорангових мереж
  5. Аудит та огляд фінансової звітності та іншої історичної фінансової інформації.
  6. Бароковий світогляд в Західній Європі та Україні
  7. В чому полягають особливості кореляційного опису результатів біометричних досліджень?
  8. Вибір мережного обладнання
  9. Види публіцистичних оглядів
  10. Використання виділених служб нагляду за мережею
  11. Відділ маркетингових досліджень та аналізу (5 осіб)
  12. ВІДПОВІДІ на тести по ДОГЛЯДУ ЗА ХВОРИМИ

 

Концепція однорангових мереж не була новою на початку XXI століття, її основні риси були відмічені одночасно з виникненням Інтернет в 1969 році.

Хоча учасники проекту ARPA не могли передбачити майбутній обсяг всесвітнього розповсюдження того, що тоді було лише одним каналом зв’язку між двома мейнфреймами, ідея з’єднання однорангових вузлів в мережу вже існувала.

Потрібно відмітити, що термінали інтерфейсів користувача на той момент були незрівнянні з головними комп’ютерами — мейнфреймами, і у них були відсутні пристрої обчислювання та зберігання, і тому ідея однорангових мереж залишалася забутою на довгий час.

Тільки коли персональні комп’ютери рушили на користувацький ринок в 1970-х та 1980-х роках, «клієнт-серверна архітектура» почала своє домінування, яке буде тривати кілька десятиліть.

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

На той час одноранговий обмін був поширеною практикою, якщо мова йшла про серверне програмне забезпечення та архітектуру мереж. Схеми маршрутизації TCP/IP були суттєво одноранговими настільки, що саме слово «peering» (одноранговий) ввійшло в специфічний лексикон маршрутизації, незважаючи на те, що реально існуючі канали зв’язку були (і досі залишаються) побудованими відносно національних магістралей та точок обміну, роблячи їх більш-менш підлеглими один до одного.

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

Спроби побудувати однорангові мережі незалежно від Інтернету також мали місце.

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

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

Одразу після появи FidoNet була по-справжньому одноранговою, в тому розумінні що кожний вузол мережі відправляв повідомлення адресату безпосередньо, викликаючи його адресу (в даному випадку — телефонний номер). Пізніше в 1990-х FidoNet також почала відчувати на собі ефекти росту інфраструктури, коли мережа вибухнула тисячами вузлів по всьому світу.

В цей час структура FidoNet була відзначена чіткою ієрархічною структурою, базованою на географічному принципі, та багатьма керуючими структурами в мережі. Потрібно відмітити, що на відміну від Інтернет (адресний простір IPv4 сягає 232 адреси, включаючи зарезервовані та немаршрутизовані), ієрархічна структура адресного простору FidoNet мала простір для 248 адрес для мережевих вузлів та 264 точок підключення взагалі.

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

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

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

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

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

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

Приклад клієнт-серверної схеми взаємодії зображено на рис.3.1. (додано посилання на рис)

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

 

Рисунок 3.1. Приклад клієнт-серверної схеми взаємодії

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

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

Справді, немає особливої потреби концентрувати інформаційне наповнення в так званій «єдиній точці відмови» (SPF, single point of failure), навіть коли вона захищена різними засобами відмовостійкості.

Також не обов’язковою є необхідність надсилання одних і тих же даних неодноразово в різні клієнтські вузли.

Однорангові мережі (P2P, peer-to-peer networks) визначають вузли, що беруть участь в роботі мережі як рівних, тобто таких, що знаходяться на одному рівні в їхньому відношенні і важливості. Кожний вузол мережі може діяти як сервер для будь-якого іншого вузла в клієнтському контексті і може діяти як клієнт, що потребує послуг від будь-якого іншого вузла в серверному контексті.

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

Приклад схеми взаємодії вузлів в одноранговій мережі зображено на рис. 3.2. (фразу додано!)

 

Рисунок 3.2. Приклад схеми взаємодії вузлів в одноранговій мережі

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

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

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

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

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

Наочний приклад вищезгаданої особливості — мережі сімейства GNUtella. Вони спроектовані таким чином, щоб бути повністю децентралізованими, хоча деякі вузли при наявності відповідних умов і доступної полоси пропускання можуть автоматично бути обрані т.з. концентраторами — вузлами, які координують роботу невеликої логічно-локальної сукупності вузлів, передають між ними повідомлення тощо.

На відміну від звичайних вузлів (за термінологією GNUtella — «листків»), концентратори підтримують більше ніж 2-3 підключення із сусідніми вузлами, але це не дає їм ніякої переваги перед вузлами, що працюють у режимі листка (рис. 3.3).

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

Рисунок 3.3. Схема однорангової взаємодії в мережах сімейства GNUtella

Були зроблені деякі кроки для подолання проблеми великого часу очікування, викликаного децентралізованою природою однорангових мереж.

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

Такі сервери, однак, не призначені для централізації мережі та отримання контролю над нею завдяки:

можливості мережі eDonkey2000 працювати взагалі без серверів;

можливості клієнтів вільно обирати сервер для свого підключення;

безкоштовності серверного ПЗ для бажаючих створити власний сервер мережі.

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

В найбільш відомих на сьогодні мережах спільного використання файлів (eDonkey2000 і GNUtella) файл розділений на так звані "порції" (chunks), які розповсюджуються в мережі окремо, якщо більше ніж один вузол однорангової мережі запитав такий файл (рис. 3.4, 3.5).

Рисунок 3.2. Розподіл файлу з 3 порціями серед трьох клієнтів у класичній "клієнт-серверній" схемі

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

 

Рисунок 3.3. Розподіл файлу з 3 порціями серед трьох клієнтів в одноранговій мережі. Видно, що початковий розповсюджувальний «сервер» посилає кожну порцію в мережу тільки один раз

Більш детально і наочно цей процес подано на наступній серії рисунків (рис. 3.6 – 3.8).

Рисунок 3.4. Початкова стадія — файл існує тільки на первинному розповсюджувачі

Рисунок 3.5. Перші дві випадкові порції передаються випадковим вузлам. Порції файлу позначені різним кольором

Рисунок 3.6. Вузли з попередньої фази починають розповсюдження своїх частин.

Третя і четверта випадкові порції роздаються іншим вузлам (рис. 3.9- 3.14)

Рисунок 3.7. Вузол первинного розповсюджувача передає в мережу дві останні порції файлу, на цьому його роль (в ідеальному випадку) повністю вичерпана

Рисунок 3.8. Всі порції файлу циркулюють в мережі, незважаючи на те, що жоден вузол не має повного набору порцій

Рисунок 3.9. Один вузол мережі отримав повний набір і в подальшому займається тільки розповсюдженням

Рисунок 3.10. На цьому етапі внутрішній мережевий трафік, як правило, починає зменшуватися. Ще два вузли мережі отримали повний набір порцій

Рисунок 3.11. Всі, крім одного, вузли мережі, мають повний набір порцій файлу

Рисунок 3.12. Передається остання порція останньому вузлу мережі.

В той час як цей підхід може потенційно заощаджувати час і полосу пропускання для поширення деякого загальнодоступного ресурсу у мережу P2P в ідеальному випадку (рис. 3.15). Дійсність полягає в тому, що може бути набагато більше клієнтських запитів ніж файлових порцій.

Рисунок 3.13. Всі вузли мережі мають повний набір порцій файлу

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

Через децентралізовану і розподілену природу однорангових мереж дуже важко (і, здається, небажано з точки зору більшості розробників реалізацій) здійснити будь-який вид системи керування правами (DRM, Digital Rights Management) — проти чого первісні однорангові мережі були дуже вразливі, наприклад, відома мережа Napster.

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

За цю особливість однорангові мережі, їх користувачі та розробники часто стають об’єктами судового переслідування. Одним з недавніх прикладів такого переслідування є позов Американської Асоціації Компаній Звукозапису (RIAA, Record Industry Association of America) до Верховного Суду США проти MetaMachine, Inc з метою припинення діяльності як засновників, розробників і прихильників однієї із найуспішніших однорангових мереж — eDonkey2000.

Незважаючи на успіх судового позову і той факт, що MetaMachine дійсно припинила всю діяльність, пов’язану з eDonkey2000, функціонування мережі в цілому порушене не було.

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

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

Щоб спільно використовувати файл або групу файлів, пір спочатку створює torrent-файл. Цей маленький файл містить метадані про файли, які будуть розміщені і про трекер — сервер, що координує роботу по розподілу файлу. Піри, які хочуть завантажити файл, спочатку одержують torrent-файл для нього, і з’єднуються із зазначеним трекером, що повідомляє їм, за якими адресами знайти інших пірів і які частини яких файлів у них є.

Хоча обидва протоколи (BitTorrent та HTTP) в остаточному підсумку передають файли по мережі, завантаження BitTorrent відрізняється від класичного повнофайлового HTTP-запиту декількома фундаментальними особливостями:

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

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

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

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

Пір, що розподіляє файл, обробляє файл як набір порцій, що мають однаковий розмір, типово між 64 і 1024 КБайт кожний. Порція з розміром, більшим за 512 КБ, зменшить розмір torrent-файлу для дуже великого контенту, але, як стверджують автори, зменшує ефективність протоколу. Пір також створює контрольну суму для кожної порції, використовуючи хеш-алгоритм, і записує її у torrent-файлі. Коли інший пір пізніше одержує цю частину, контрольна сума частини порівнюється із зареєстрованою контрольною сумою, щоб перевірити чи ця частина передана безпомилково. Пірів, які забезпечують повний файл, називають «сідери» (seeder), і піра, що забезпечує вивантаження початкової копії файлу в мережу, називають початковим сідером.

Точна інформація, що міститься у torrent-файлі, залежить від версії протоколу BitTorrent. Відповідно до прийнятої розробниками угоди, torrent-файлу має розширення torrent. У torrent-файлів є розділ оголошення, що визначає адресу трекера, і секція "інформація", що містить (переважно) назви для файлів, їхні довжини, довжини частин, контрольну суму SHA-1 для кожної частини; тобто все що використовується клієнтами, щоб перевірити цілісність даних, які вони одержують.

Виготовлені torrent-файли типово публікуються на веб-сайтах або в іншому середовищі, і реєструються на трекері. Трекер підтримує списки клієнтів у цей час, що беруть участь у розповсюдженні. Існують альтернативні системи, без трекерів, що реалізують децентралізоване відстежування, тоді кожний пір діє як трекер. Це здійснено клієнтами BitTorrent, µTorrent, BitComet і KTorrent через розподілену хеш-таблицю (DHT, distrubuted hash table). Клієнт Azureus також підтримує безтрекерний метод, але він є несумісним (за станом на на квітень 2007 року) з форматами і протоколами DHT що запропоновані всіма іншими клієнтами.

У листопаді 2006 року, компанія BitTorrent, Inc ввела в експлуатацію власну Службу Публікації (http://www.bittorrent.com/publish), що самостійно створює і публікує torrent-файл (згенерований на основі вже існуючого опублікованого в мережі мультимедійного файлу) і простежує завантаження. Обслуговування в цій службі вимагає клієнта, що підтримує її (у цей час тільки офіційні клієнти, Azureus і µTorrent.

Користувачі переглядають Інтернет, щоб знайти torrent-файл за своїми інтересами, завантажують і відкривають його в клієнті BitTorrent. Клієнт з’єднується із трекерами, що вказані у torrent-файлі. Від них клієнт одержує список пірів, що передають порції файлів в рамках однієї роздачі на даний момент. Клієнт з’єднується з цими пірами, щоб одержати різні частини. Таку групу перів, зв’язаних один з одним, щоб спільно використовувати torrent-файл, називають роєм. Якщо рій містить тільки початкового сідера, клієнт з’єднується безпосередньо із цим і починає запитувати порції. Як тільки піри входять в рій, вони починають обмінюватися порціями один з одним, замість того, щоб завантажити їх безпосередньо від початкового сідера.

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

Ефективність такого обміну даними залежить значною мірою від політики, яку впроваджують клієнти, для визначення, кому посилати дані. Клієнти можуть захотіти посилати дані тільки пірам, які відсилають дані назад до них, що заохочує сумлінну конкуренцію. Але така сувора політика часто приводить до неоптимальних ситуацій; наприклад, коли піри, які щойно приєдналися, не здатні одержати будь-які дані, тому що в них ще немає ніяких завантажених частин, щоб безпосередньо поділитися з іншими або коли два піри з швидким підключенням між ними не обмінюються частинами просто тому, що жоден з них не хоче взяти ініціативу. Щоб протистояти цим ефектам, офіційний BitTorrent клієнт використовує механізм під назвою “optimistic unchoking”, де клієнт резервує частину його доступної полоси пропускання для того, щоб послати порції файлу випадковим пірам (не обов’язково відомим з переважними параметрами), з метою виявлення ще швидших партнерів і гарантування, що новоприбулі піри одержують шанс приєднатися до рою.

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

Компанія BitTorrent Inc нагромадила значну кількість ліцензій від Голлівудських студій для того, щоб розподілити популярний контент зі свого веб-сайту.

SubPopRecords випускає композиції та відео через BitTorrent Inc для розповсюдження більше тисячі альбомів. Група Ween використовує веб-сайт Browntracker.net для поширення безкоштовних аудіо і відеозаписів своїх живих концертів. Крім того, Babyshambles і The Libertines інтенсивно використовують BitTorrent для розповсюдження сотень демонстраційних кліпів і відеозаписів живих концертів.

Автор протоколу BitTorrent Bram Cohen одного часу працював на Valve Software. Valve використовує протокол BitTorrent у своїй системі доставки контенту Steam.

Програмне забезпечення для подкастінгу починає інтегрувати технологію BitTorrent для того, щоб допомогти авторам подкастів задовольнити вимоги до завантаження їх MP3 «радіо»-програм. Особливо, Juice та Miro (раніше відомі як Democracy Player) підтримують автоматичну обробку torrent-файлів з опублікованих агрегаторних потоків. Також, деякі BitTorrent клієнти, такі як µTorrent, можуть обробляти веб-сторінки та автоматично завантажувати контент який вони там знайдуть.

Amazon S3 "Simple Storage Service" є масштабним Інтернет-базованим контейнером даних з простим веб-інтерфейсом, який включає в себе підтримку протоколу BitTorrent.

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

Багато проектів з розробки програмного забезпечення, що працюють за принципами Open source та Free software заохочують використання BitTorrent так само як і звичайне завантаження їхніх продуктів, що збільшує доступність і зменшує навантаження на їхні сервери.

Blizzard Entertainment в своїй багатокористувацькій грі World of Warcraft використовує протокол BitTorrent, щоб надсилати оновлення гри клієнтам.

В грі Gun The Duel є вбудований клієнт BitTorrent.

CableLabs, дослідницька організація північноамериканської інтернет-індустрії, оцінює, що BitTorrent представляє 18% усього користувацього інтернет-трафіку. В 2004, CacheLogic повідомили, що це значення становить приблизно 35%, аналізуючи структуру всього трафіка в Інтернеті. Невідповідності в цих числах викликані розходженнями в методології вимірювання трафіку однорангових мереж в Інтернеті.

Маршрутизатори, які використовують NAT, повинні підтримувати внутрішні таблиці джерел й призначень у вигляді IP адрес і портів. Типові домашні маршрутизатори обмежені приблизно 2000 елементами таблиці, у той час як деякі більш дорогі маршрутизатори можуть побудувати значно більші таблиці. BitTorrent часто зв’язується з 300-500 адресами в секунду, що швидко заповнює таблиці NAT. Це є частою причиною сбоїв домашніх маршрутизаторів.

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

Публічні трекерні сайти, такі як The Pirate Bay дозволяють користувачам здійснювати пошук серед їхньої колекції torrent-файлів і завантажувати їх; вони також підтримують трекер для цих файлів. Користувачі можуть також завантажувати torrent-файли для матеріалів, що вони бажають розповсюдити.

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

Існують спеціалізовані трекерні сайти, такі як FlixFlux для фільмів, elbitz для контенту, що відноситься до освіти, PureTnA для порнографії, і TV torrents для телесеріалів. Часто вони також бувають приватними.

Пошукові системи дозволяють знайти torrent-файли, які розміщені і простежуються на інших сайтах; наприклад Mininova, Btjunkie, TorrentSpy, isoHunt. Ці сайти надають користувачам можливість вказати певне ключове слово або інший критерій і виводять список torrent-файлів, які задовольняють цим вимогам. Цей список часто сортується відносно релевантності або числа сідерів в даний момент. Bram Cohen заснував пошуковий сервер BitTorrent, що перемішує ліцензійні матеріали з результатами пошуку. Механізми Metasearch дозволяють шукати на декількох індексах BitTorrent і пошукових серверах відразу.

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

Для вирішення цієї проблеми, деякі мережі, наприклад eDonkey2000 наприклад, мають певні особливості реалізації.

В мережі eDonkey2000 хеш MD5 ідентифікує кожний файл. Якщо розмір файлу менше ніж одна порція (приблизно 9.72 мегабайта), хеш MD5 береться від всього файлу. Якщо файл складається з багатьох порцій, то окремі MD5 хеші беруться від кожної порції, а потім основний хеш береться від набору порційних хешів, представлених просто як потік даних. Це робить великий файл ідентифікованим не тільки первинним хешем, але також і рядом вторинних.

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

Вищезгаданий метод також служить перевіркою цілісності файлу. Якщо виникають проблеми в мережі зв’язку або помилка в програмному забезпеченні, що може спричинити до ушкодження даних в отриманій порції, то не тільки основний MD5 хеш файлу буде не відповідати призначеному, але також і набір хешів дозволить визначити, яка з порцій отримана ушкодженою (рис. 3.16).

Яким би корисним цей підхід не був, перспектива перезавантажувати порцію цілком (9.72 Мегабайта) із-за пошкодження одного біту є дещо неприємною. Це привело до реалізації алгоритму AICH (Advanced Intelligent Corruption Handling). AICH також працює шляхом логічного розбивання контенту файлу на порції, тільки розмір їх у цьому випадку лише 180 Кілобайтів. Щоб запобігти надлишковим розмірам таблиці хешів, отриманих з таких маленьких порцій, AICH використовує багаторівневе хешування, де наступний рівень даних складається з хешів попереднього рівня.

Рисунок 3.14. Виявлення пошкоджень даних при передачі

Системи резервного копіювання, особливо ті, які спеціалізуються на довгостроковому зберіганні даних, також страждають від тих же самих проблем, що і класична "клієнт-серверна" архітектура. Необхідно або залучати великі інвестиції в складні апаратні і програмні рішення, які надають повністю автоматизовану і надійну систему резервного копіювання підприємству, або думати про рішення, базовані на SAN (Storage Area Networks) або NAS (Networked Archive Storage), зменшуючи вартість шляхом побудови децентралізованого середовища для резервного копіювання, що все ще відносно дорого.

Використовуючи технології P2P можливо зменшити витрати на систему резервного копіювання і вартість його обслуговування до не більше ніж фактичних витрат на підключення додаткових вузлів до загальної корпоративної мережі.

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

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

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

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

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

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

Одним з найпростіших способів такої перевірки є застосування біту парності (паритету). Такий спосіб застосовується, зокрема, в протоколі послідовної передачі двійкових даних по електричному інтерфейсу RS-232. Цей інтерфейс використовує диференціальну передачу, де електричний потенціал від +3 В до +25 В вважається за біт «0», а від ±3 В до ±25 В вважається за біт «1». Біти передаються в одному напрямку по одному контакту послідовно, дотримуючись певних вимог щодо часових характеристик сигналу. Початок та кінець байта (сукупності з 5, 6, 7 або 8 бітів) маркірується так званим «старт-стоповим бітом», який має більшу за звичайний біт тривалість.

Так як RS-232 є фізичним протоколом низького рівня, передача даних може бути спотворена наявністю джерела електромагнітного випромінювання поблизу каналу передачі, відсутністю якісного заземлення пристроїв тощо. Тому інтерфейси, які реалізують цей протокол передачі, можуть бути запрограмовані на використання додаткового біта парності — спеціального біта, який має таку ж форму і тривалість, як і біти даних, але значення якого не входить в байт, що передається. Принцип дії контролю парності полягає в тому, що цей спеціальний біт парності виставляється в «1» якщо кількість біт зі значенням «1» в байті є непарною, і в «0», якщо парною. Приймаючий пристрій проводить підрахунок кількості одиничних бітів і порівнює це значення зі значенням біта парності. Якщо молодший біт кількості співпадає з бітом парності, передача пройшла успішно. Таким чином імовірність того, що пошкоджена передача буде прийнята за коректну, зменшується вдвічі. Однак така ситуація залишається цілком можливою, наприклад, якщо в переданому пакеті пошкоджено (тобто змінено значення на протилежне) два біти, навіть коли один з них є бітом парності.

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

Модифікації алгоритму перевірки парності застосовувалися в обчислювальних машинах Bell Labs в 1940-х роках. Зокрема, алгоритм «2 з 5» перевіряв на наявність двох обов’язкових одиниць в кожному блоці з 5 біт які поступали на вхід від пристрою зчитування перфокарт. В деяких інших розробках того часу застосовувався алгоритм повтору даних, в якому кожний біт передавався тричі підряд. В цьому випадку, якщо приймальний пристрій отримував пошкоджений блок де значення трьох бітів були не ідентичні, значення результуючого біту приймалося як більшість значень. Тобто, послідовність «001», «010» та «100» сприймалася як «0», а послідовність «110», «101» та «011» як «1». Хоча цей спосіб, на відміну від біту парності, вже дозволяє робити виправлення пошкоджених даних, він теж не досить надійний, адже пошкодження двох бітів в блоці приведе до прийняття неправильного рішення.

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

Вперше ця проблема була розв’язана Ричардом Хеммінгом, співробітником Bell Labs в 1950 році. Він запропонував скомбінувати залишкові дані зі значущими таким чином, щоб біти парності в групі залишкових даних обчислювалися за значимими бітами в періодичній послідовності. Так, наприклад, в байт з 7 бітів додаються 4 біти парності, перший з яких розташовується на 1-му місці (20) і обчислюється для груп по 1 біту через 1 позицію, другий на 2-му місці (21) і обчислюється для груп по 2 біти через 2 позиції, третій на 4-му місці (22) і обчислюється для груп по 4 біти через 4 позиції і так далі.

Алгоритм дозволяє при об’ємі залишкових даних меншому за об’єм значущих даних ефективно відстежувати пошкодження даних і, головне, відновлювати пошкоджені при передачі біти. Наприклад, в якщо в попередньому прикладі було пошкоджено останній значущий біт, перевірки парності покажуть негативний результат по 1-му, 2-му та 4-му бітам парності, до обчислення яких входить лише останній біт — отже, пошкоджено було саме його.

Порівняно висока ефективність коду Хеммінга зменшувалась протягом часу зі збільшенням обсягів даних, що передаються та швидкості передачі. Код Хеммінга додає не менш як 3 біти залишкових даних до кожних 4 бітів значущих даних, що при його застосуванні призводить до зростання обсягів передачі на 75%, що зменшує ефективну швидкість передачі даних.

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

Відтак область застосування кодів Хеммінга перемістилася з телекомунікаційних областей до технологій зберігання та архівування даних. Наприклад, популярний на сьогоднішній день архіватор RAR використовує модифікований код Хеммінга для захисту архівів від пошкодження шляхом додавання спеціального блоку даних для відновлення (recovery data). Розмір блоку даних задається у відсотках від об’єму даних, і чим більший розмір такого блоку, тим більше стійкість архівних даних до випадкових ушкоджень, наприклад, внаслідок неякісної пам’яті або дискової системи.

На сьогодні, найбільш розповсюдженою практикою контролю цілісності переданих даних в телекомунікаційній галузі є контрольні суми (checksum), контрольні суми з циклічною залишковістю (cyclic redundancy check) або дайджести (digest).

Основним елементом обчислення контрольних сум та дайджестів є так звана функція згортки, або хеш-функція (hash function). Функція згортки приймає в якості аргументу блок даних, а на виході видає згортку, або хеш (hash) — набір даних, зазвичай фіксованого розміру.

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

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

Таблиця 3.2. Зміна значення дайджестів від зміни одного байту в слові «dog»

  The quick brown fox jumps over the lazy dog The quick brown fox jumps over the lazy cog
CRC-16 (16 біт) FCDF 3D6E
CRC-32 (32 біт) 414FA339 4400B5BC
MD4 (128 біт) 1BEE69A46BA81118-5C194762ABAEAE90 B86E130CE7028DA5-9E672D56AD0113DF

Хеш характеризується потужністю — кількістю біт, які його складають. Відповідно, імовірність знайти два блоки даних, які видадуть однаковий хеш, обернено пропорційна до двійки в степені потужності хеша. Наприклад, алгоритм MD4, розроблений Рональдом Райвстом з Массачусетського Технологічного Інституту в 1990-му році, має потужність 128 біт, а імовірність знайти два блоки даних — колізію — випадковим перебором дорівнює, відповідно, .

Не зважаючи на те, що згодом було доведено незадовільну стійкість алгоритму, розроблені методики пошуку колізій та знайдені самі колізії не шляхом повного перебору, ті принципи, що були використані при його розробці, знайшли своє застосування в подальших розробках — алгоритмах MD5, SHA, RIPEMD та інших.

На сьогоднішній день існує багато різних алгоритмів генерації дайджестів та контрольних сум, які різняться потужністю, відносною обчислювальною вартістю, складністю і т.п. Деякі з цих алгоритмів, зокрема алгоритми сімейства SHA (SHA-1, SHA-224, SHA-256, SHA-384 та SHA-512) були розроблені Агентством Національної Безпеки США та прийняті в якості стандартів для урядових установ США. Вперше розроблений та опублікований в 1993 році алгоритм зазнав значних вдосконалень протягом часу, у відповідь на успішні «зломи», які зазнали перші його версії.

 


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.023 сек.)