|
Біографія | Реферат | Портал магістрів | ДонНТУ RUS | ENG | UKR |
|||||||||||||
Дослідження завантаженості каналу та сервера служби миттєвих повідомлень. Розробка програмних засобів розподілу навантаження на сервер
|
|||||||||||||
|
У даний момент у комунікаційному середовищі велику популярність отримує такий мережевий сервіс, як служба миттєвих повідомлень (IM), а також IP телефонія. Це обумовлено тим, що при використанні даних сервісів можлива більша економія коштів у спілкуванні з людьми на далеких відстанях і в інших країнах. IM залишається вибором способу спілкування для багатьох людей, так як надає більш «особисте» спілкування, ніж електронна пошта, але менш нав'язливе, ніж телефон. IM також корисно при спілкуванні в надзвичайних ситуаціях, тому що Інтернет може функціонувати під час неполадок на телефонній лінії. Сервіси миттєвих повідомлень поступово витісняють електронну пошту в результаті наступних недоліків останньої:
Основна причина спаму для електронної пошти, це відсутність надійної системи ідентифікації відправника повідомлення. У сьогоднішній системі електронної пошти спамери можуть поставити в полі «Відправник» будь-яку інформацію. Це є однією з основних причин низької безпеки. Незручності активного листування полягає в складності контролю всієї історії спілкування. У результаті, активним користувачам електронної пошти доводиться самим організовувати способи зберігання логів. Доставка повідомлень по електронній пошті повільна, якщо порівнювати саме з системами миттєвих повідомлень. Затримка в 1-10 секунд (офіційна специфікація стверджує про можливості доставки пошти протягом 24 годин) утруднює спілкування в режимі реального часу. Крім того, занадто часта перевірка пошти може трактуватися сервером як мережева атака, приводячи до тимчасового блокування користувача. Експерти міжнародної дослідницької компанії TNS з'ясували, що SMS та електронна пошта на мобільному телефоні поступово втрачають свою популярність. «Неголосове» спілкування тепер все більше будується на обміні миттєвими повідомленнями. За даними дослідження, в якому взяли участь 17 тис. респондентів з 30 країн світу, серед власників мобільних телефонів, що використовують при спілкуванні служби миттєвих повідомлень, 61% віддає перевагу саме цей спосіб зв'язку, 55% використовують SMS і тільки 12% - електронну пошту. Вибір IM замість SMS цілком логічний: «Як тільки власники мобільних телефонів отримують доступ в інтернет і мають можливість використовувати служби миттєвих повідомлень, вартість текстових послань різко знижується і досягає практично нуля, тому що користувачі в даному випадку платять тільки за трафік, а самі повідомлення нічого їм не варті. Крім того, велика кількість людей звикло спілкуватися за допомогою служб миттєвих повідомлень через інтернет на персональних комп'ютерах, тому вони з великою охотою перемикаються на аналогічне спілкування і на своїх мобільних телефонах. А так як все більше операторів мобільного зв'язку пропонують своїм клієнтам необмежений доступ в інтернет, то ми можемо з упевненістю говорити про подальше зростання популярності миттєвих повідомлень і зниження ролі SMS і повідомлень по електронній пошті », - пояснюють експерти TNS. На сьогоднішній день у всьому світі за допомогою миттєвих повідомлень по мобільному телефону спілкуються 8% людей. Найбільш популярне таке спілкування в Гонконзі, де цей показник досягає 23%. Далі слідують Китай (16%), Саудівська Аравія (15%), ПАР (12%), Індія (11%) і Бразилія (10%). Незважаючи на всі свої переваги, сервіси IM не позбавлені недоліків. Ось головні з них:
Мережева безпека служб миттєвих повідомлень. Різні IM програми використовують різні пропрієтарні протоколи, і стандартна конфігурація брандмауера може не виявити їх. Багато IM програми можуть обходити системи аутентифікації. Деякі IM клієнти можуть використовувати порти відмінні від тих, які асоціюються з IM, навіть звичайно відкриті порти, такі як 80. Основні проблеми безпеки IM сервісів:
Виходячи з усіх статистичних досліджень, можна побачити, що підвищується популярність сервісів миттєвих повідомлень. Актуальність роботи полягає в підвищенні якості роботи сервісів шляхом вирішення зазначених вище недоліків. Мотивація роботи заснована на особистому досвіді використанні різних служб миттєвих повідомлень, а також досвід людей, з якими доводилося спілкуватися за допомогою даних служб. Найбільш неприємним фактом є спам при використанні протоколу ICQ. Позначається низький рівень безпеки, в результаті чого спам приходить від тих контактів, які знаходяться в списку. Таким чином, сервіс ICQ уразливий до злому і розкраданню облікових записів. Крім того, нерідкі обриви з'єднання з подальшою неможливістю відновлення протягом від 5 до 15 хвилин. В даному випадку позначається недостатні можливості мережі компанії AOL, що володіє даним сервісом. Схожа проблема властива службі Skype. Клієнт Skype помітно довше з'єднується з сервером, ніж клієнти інших протоколів. Крім того часто трапляються періодичні розриви з'єднання в режимі очікування. При використанні Skype для голосового спілкування даних розривів помічено не було. І останнім мотивуючим фактором для вибору теми магістерської роботи є бажання вивчити прийоми шифрування при передачі даних, набути досвіду в розробці мережевого програмного забезпечення, активно використовуючого бази даних. Таким чином, виходячи з перерахованих вище недоліків IM сервісів та мотиваційних факторів, ставляться наступні завдання:
Передбачувана наукова новизна полягає у складанні алгоритмів маршрутизації між серверами служб миттєвих повідомлень, а також у розробці нового протоколу для обміну повідомленнями. Крім того пропонуються кілька підходів до боротьби зі спамом в мережах, які використовують протокол DMP. Огляд досліджень і розробок по темі На рисунку 1 представлено процентне співвідношення служб миттєвих повідомлень в країнах СНД за станом на липень 2008 року.  Рисунок 1 - Використання служб миттєвих повідомлень Найбільш популярна служба миттєвих повідомлень в країнах СНД - ICQ, що використовує протокол OSCAR. Проте багато зустрічалися з повідомленнями «ліміт підключень перевищено», а також з великою кількістю спама, що розсилається ботами. Розсилка спаму полегшується способом представлення протоколом OSCAR ідентифікації контактів - за номерами. Таким чином, розсилка спаму полягає в переборі номерів із заданого діапазону. Протокол OSCAR надає низьку безпеку для використання в комерційних мережах. Другий протокол, що набирає популярність - XMPP. За даним протоколом працюють служби Jabber і GTalk. XMPP заснований на XML, відкритий, вільний для використання протокол для миттєвого обміну повідомленнями та інформацією про присутність у режимі, близькому до режиму реального часу, який також є децентралізованим, але теж має слабкі сторони:
Методи балансування завантаженості серверів Існує багато способів, які дозволяють досягти балансування завантаженості серверів. Фактори вибору того чи іншого способу залежать від вимог, пропонованого сервісу, складності реалізації і вартості. Наприклад, апаратна реалізація балансуючого обладнання помітно дорожче програмної реалізації. Балансування за методом Round Robin DNS Можливе використання вбудованого в DNS сервер алгоритму Round Robin. Це один з перших алгоритмів. Переваги: дуже простий в реалізації, низька вартість, легкість у впровадженні. Недоліки: DNS сервер не має уявлення про можливості серверів, які належить збалансувати. Крім того DNS сервер може диференціювати сервера по IP адресами, але не по портах. Даний спосіб не можна організувати в локальній мережі. Апаратне балансування Апаратне балансування може маршрутизувати TCP / IP пакети на різні сервери. Такий тип балансування надає надійну топологію і високу продуктивність, але має більшу вартість. Переваги: даний тип балансування використовує канальний рівень для маршрутизації пакетів. Недоліки: висока вартість у порівнянні з програмною реалізацією. Програмне балансування Найбільш часто використовуваний тип балансування - це програмна балансування і часто надається як компонент дорогих серверних рішень. Переваги: надає більш гнучкий спосіб розвантаження мережі, що враховує вимоги сервера. Можливість маршрутизації в залежності від вхідних параметрів. Недоліки: потрібен додатковий апаратний комплекс для розгортання даного балансуючого ПЗ. Плановані практичні результати За результатами розробок і досліджень планується в мережах, що працюють по протоколу DMP отримати наступні результати:
Результати, присутні на момент завершення роботи над авторефератом Рішення проблеми недостатніх обчислювальних можливостей сервера, недостатньої ширини каналу Протокол DMP (decentralized messaging protocol) орієнтований насамперед на зменшення навантаження на сервер і кількості переданої інформації Протокол є децентралізованим, тобто використовують кілька серверів для розподілу навантаження на кожен з них. Як показує статистика, близько 90% контактів користувача територіально знаходяться в межах однієї адміністративної одиниці. Таким чином, для обслуговування даної території ефективно використання окремого сервера, а для решти 10% контактів - межсерверного обміну. Це вирішує проблему обчислювальних можливостей сервера. Проблема ж ширини каналу вирішується практикою використання протоколу XMPP - відкриття стандартів розробляється протоколу, а також можливість будь-якому охочому підняти сервер служби миттєвих повідомлень. Тобто сервери обслуговуються не єдиною організацією, а багатьма приватними або юридичними особами, що мають різні можливості з передачі трафіку. На відміну від протоколу XMPP, маршрутизатор виділений зі складу сервера і є окремою програмною одиницею, яка може бути встановлена як на окрему машину, так і на машину з встановленим сервером DMP. Також можливе пряме підключення серверів між собою минаючи маршрутизатор для розвантаження останнього, а також прискорення обміну між серверами (див. рис. 2). Рисунок 2 - Можлива структура служби DMP (flash-анімація,38KБ, 5.7 секунд) З рисунка 2 можна побачити приклад можливої структури служби DMP. На другому сервері можливо як присутність маршрутизатора, так і його відсутність. Крім того, протокол передбачає стиск даних різними компресорами, формат яких встановлюється активної версією протоколу. Для бета-версії протоколу встановлюється компресор bzip2. bzip2 є вільним ПЗ з відкритим вихідним кодом. Для наступних версій можливе розширення протоколу більш ефективними компресорами. Крім того, стиснення інформації, що передається повинне бути виправдане. Компресія бінарної інформації, наприклад, при передачі файлів далеко не завжди себе виправдовує. Дану ефективність слід визначати на стороні клієнта, що є вже побажанням для розробників клієнтського ПЗ (це не є вимогою в умовах складності контролю для відкритого ПЗ). Для зниження трафіку використовується мінімалізм в організації пакетів, структура яких розглянуто нижче. Протокол передбачає можливість використання кількості маршрутизаторів, обмеженого лише ефективністю їх використання. Також недоліком є складність контролю можливостей, надійності і безпеки сервера. Дана проблема вирішується скоріше досвідом використання конкретного сервера, а також відгуками користувачів. Протокол DMP має можливість виключення P2P обміну при передачі файлів. Підвищення безпеки реалізується обміном виключно через сервер. Даний підхід явно навантажує як канал, так і сервер всієї служби DMP в цілому. Однак, інформаційна безпека, поза сумнівом, важливіше, так як, протокол орієнтований на використання в корпоративних мережах, де присутня конфіденційна інформація. Крім того, протокол передбачає шифрування переданих даних і безпечну аутентифікацію. Шифрування необхідно для виключення можливих перехоплень інформації, що передається та прослуховування. Крім того, робиться спроба в боротьбі зі спамом. А саме: лімітування кількості переданої інформації за одиницю часу, а також порівняння відбитків MD5 або SHA частин повідомлень або повідомлень цілком одного контакту. Якщо вони однакові, то при перевищенні певної кількості збігів можливе блокування контакту сервером, як підозра на розсилку спаму ботом. Однак, останній спосіб є експериментальним і досить сумнівним і вимагає додаткового тестування і дослідження на практиці. Загальний опис можливостей протоколу Можливості протоколу DMP представлені в наступних пунктах:
Коротка специфікація протоколу У даному розділі розглядається основна одиниця протоколу - пакет. Довжина пакету не фіксована, але не повинно перевищувати фіксованого значення - 1Мбайт. Структура пакета зображена на рисунку 3.  Рисунок 3 - Структура пакета протоколу DMP Як видно з рисунка 3, пакет містить 4 поля: сигнатуру, дані шифрування, стиснення, а також поле команд і даних. Для мінімізації трафіку протокол виключає такі надлишкові способи організації інформації, як XML. Сигнатура містить версію протоколу. Формат команд має вигляд: ID команди: параметри. ID команди представляє собою числове поле розміром 16 біт, тобто максимальне число команд дорівнює 65536. Слід зазначити, що шифрування і стиснення може бути відсутнім. Програмний функціонал, присутній до даного моменту До даного моменту розроблені клієнт і сервер, що працюють по протоколу DMP. Це програмне забезпечення реалізує базові можливості протоколу. Це програмне забезпечення реалізовано на 2 платформах - Win32 і Linux. Коректність роботи протестовано на системах Windows XP SP3 і Mandriva Linux 2009.1. Також заплановано реалізувати наступні можливості:
Крім того, обов'язковим до реалізації є маршрутизатор протоколу DMP. Грунтуючись на досвіді використання служб миттєвих повідомлень ICQ та XMPP, розробляється протокол DMP. Протокол зменшує вплив загальних недоліків для служб миттєвих повідомлень, а саме:
1. AIM/Oscar Protocol Specification - http://www.oilcan.org/oscar/ 2. XMPP Standards Foundation - http://xmpp.org/ 3. ICQ / From Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/Icq 4. XMPP / From Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/Jabber 7. IM vs. SMS - http://blog.imobis.ru/research/im-vs-sms-novaya-statistika.html 8. Server Load Balancing: Algorithms - http://content.websitegear.com/article/load_balance_types.htm 9. Server Load Balancing Methods - http://content.websitegear.com/article/load_balance_methods.htm 12. Leskovec J., Horvitz E., Planetary-scale views on a large instant-messaging network / Microsoft Research Technical Report MSR-TR-2006-186 13. Sharma S., Singh S., Sharma M., Performance Analysis of Load Balancing Algorithms / World Academy of Science, Engineering and Technology 38 2008 14. Czerwinski M., Cutrell E. and Horvitz E., Instant Messaging: Effects of Relevance and Timing / Microsoft Research |
|||||||||||||
 |
|||||||||||||
|
Біографія |
Реферат |
Портал магістрів |
ДонНТУ |
|||||||||||||
| RUS | ENG | UKR | |||||||||||||