додати матеріал


Протокол HTTP

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Курсова робота

На тему: Протокол HTTP

Зміст

Зміст. 1
Введення. 4
1. Дослідницький розділ. 8
1.1 Постановка завдання. 8
1.2 Передача даних. 9
1.2.1 Протоколи передачі даних. 9
1.2.2 Протокол TCP. 11
1.2.3 Протокол HTTP. 12
1.3 Системна інформація ОС Linux. 18
1.3.1 Розташування системної інформації. 18
1.3.2 Файлова система / proc. 19
2. Технологічний розділ. 24
2.1 Вибір мови програмування. 24
2.2 Програмні засоби. 24
2.2.1 Потоки. 24
2.2.2 Семафори і м'ютекси .. 25
2.2.3 Сокети .. 26
2.2.4 Сигнали .. 27
2.3 Структура модулів програми .. 27
2.3.1 Система ініціалізації. 29
2.3.2 Сервер і система управління динамічними бібліотеками. 31
2.3.3 Система журналювання. 31
2.3.3 Система безпеки. 32
2.4 Динамічні бібліотеки. 33
2.4.1 PROCESSES - інформація про процеси. 33
2.4.2 MEMINFO - інформація про системну пам'яті. 34
2.4.3 DISKFREE - інформація про вільне місце на дисках. 34
2.4.4 NETWORK - інформація про мережеві пристрої. 35
2.4.5 VERSION - версія операційної системи .. 35
2.4.6 INDEX - сторінка допомоги. 36
2.5 Використання програми .. 36
2.5.1 Налаштування сервера. 36
2.5.2 Доступ до сервера. 37
2.5.3 Завершення роботи сервера. 38
Висновок. 40
Список використаної літератури .. 42

Введення

В даний час спостерігається тенденція до перенесення великої кількості додатків в середу Інтернет - це дозволяє більш ефективно організовувати спільну роботу з даними, комунікацію віддалених користувачів і швидке реагування на виникаючі події. Розподілені додатки, доступ до яких здійснюється за допомогою ліній зв'язку, виявилися дуже зручними - з'явилася можливість розділяти місця зберігання даних і ефективно організовувати доступ до них персоналу з будь-якої точки земної кулі. Зрозуміло, активне використання розподілених веб-додатків накладає вкрай високі вимоги на платформу, на якій відбувається їх виконання - повинна забезпечуватися надійна та безперебійна робота серверів, висока швидкість доступу і можливість динамічного оновлення програмного забезпечення на серверних комп'ютерах.
В останні кілька років все більшої популярності набувають сервери, що працює під управлінням операційних систем сімейства UNIX: FreeBSD, OpenBSD, Solaris, Linux. Всі ці системи спроектовані у відповідності зі стандартом POSIX і мають ідентичний програмний інтерфейс, що дозволило з легкістю переносити додатки, написані в одній системі, на іншу. Крім того, всі ці системи показали себе вкрай надійність і відмовостійкість, здебільшого з-за постійного вдосконалення, яке, часто, виконується безкоштовно ентузіастами з усього світу.
UNIX-системи не прижились в якості користувацьких операційних систем в силу своєї складності і необхідності вивчити велику кількість команд, однак у сфері серверів Інтернету подібні системи поступово витісняють серверні версії Microsoft Windows.
З появою великої кількості серверів під управлінням операційних систем сімейства UNIX постало питання про адміністрування цих серверів і, зокрема, проводити адміністративні дії віддалено, за допомогою мереж передачі даних. Необхідність подібних дій викликана тим, що фізично сервер не завжди може бути доступний: адміністратор може обслуговувати відразу декілька серверів, фізично віддалених один від одного на значну відстань, що не дозволяє отримати безпосередній доступ до кожної машині; також адміністратор не може перебувати на робочому місці постійно , тоді як неполадки можуть виникнути в будь-який момент. Крім того, серверні комп'ютери, до яких пред'являються підвищені вимоги надійності та безпеки, часто розташовують у закритих приміщеннях, доступ у які дозволено тільки спеціальним обслуговуючому персоналу. Все це призвело до створення ряду програмних засобів, службовців однієї мети - можливості здійснювати віддалене адміністрування комп'ютера.
Одним з перших з'явився програмний продукт під назвою telnet. Він складався з клієнтської і серверної частин і дозволяв клієнтської частини підключатися до серверної, що знаходиться на віддаленому комп'ютері. Після цього користувач отримував в своє розпорядження так званий віртуальний термінал - він міг набирати стандартні команди UNIX, які потім транслювалися через мережу на віддалений комп'ютер telnet-сервера, виконувалися, а результати виконання передавалися назад на клієнтську машину. Таким чином, здійснювалася віддалена робота з комп'ютером, аналогічна за функціональністю безпосередньому доступу.
Основною проблемою даної програмної системи була безпеку доступу. Авторизація користувача здійснювалася стандартними засобами UNIX, що призводило до передачі по мережах у відкритому вигляді інформації про облікові записи системи. Ця інформація, у свою чергу, могла бути перехоплена зловмисниками і використана з метою виведення системи з ладу або отримання над нею повного контролю.
Наступним кроком стало створення так званої захищеної оболонки (secure shell або, скорочено, ssh). Цей програмний комплекс по своїй структурі був схожий на telnet - також виділялися клієнтська і серверна частина і користувач отримував в своє розпорядження віртуальний термінал при підключенні. Проте в даному випадку при авторизації користувача використовувалися вже не стандартні вчені запису UNIX, а власна база даних користувачів, інформація про які передавалася в зашифрованому вигляді. Шифрувалися також і команди, що передаються на сервер, і у відповідь інформація. Все це зробило віддалене адміністрування досить безпечним і призвело до зростання популярності ssh.
Проте все ще залишалося деяку незручність при роботі з зазначеними ші програмами - вони не дозволяли оперативно отримувати інформацію про систему в зручному для сприйняття вигляді. Для отримання даних про стан системи необхідно було знати певні команди оболонки UNIX, а також розташування структур даних, що містять потрібну інформацію. Тривалість процедури підключення та отримання інформації зробила незручним постійне спостереження за станом системи і наклала високі вимоги на кваліфікацію обслуговуючого персоналу.
Програма, розроблена в рамках курсового проекту, частково вирішує дану проблему. Вона дозволяє отримувати доступ до інформації про стан Linux-системи (як найпоширенішою серед UNIX-систем) через мережу Інтернет, надаючи дані в зручному вигляді, що дозволяє користуватися програмою не тільки персоналу з високою кваліфікацією і детальним знанням внутрішнього устрою UNIX, але і звичайним користувачам.
Функціональність програми може бути легко розширена - вона використовує спільні модулі, що дозволяє додавати необхідні можливості без перезапуску самої програми. Хоча спочатку програма була призначена для спостереження за системою, додаванням необхідних модулів можна забезпечити і можливість впливу на систему.
Програма забезпечує високу безпеку підключення: для отримання доступу до інформації про систему використовується власна база облікових записів, причому дані користувача передаються в зашифрованому вигляді. Крім того, за допомогою програми неможливо пошкодити віддаленій системі, так як, на відміну від віртуального терміналу, вона надає доступ тільки до дій, певним адміністратором під час налаштування програми.
Підключення до програми, що знаходиться на віддаленому комп'ютері, може бути вироблено з будь-якої операційної системи, до складу якої входить Інтернет-браузер, що підтримує стандарти HTTP і HTML, у тому числі з користувальницьких систем, таких як Microsoft Windows та MacOS.
Таким чином, розроблена в рамках курсового проекту програма не претендує на роль повноцінної заміни традиційним віртуальним терміналам, однак надає функції, які можуть бути корисними при віддаленому адмініструванні: швидке отримання у зрозумілому людині вигляді інформації про стан системи, можливість підключення до віддаленої машині з будь-якої операційної системи до встановленого Інтернет-браузером, а також можливість налаштування та удосконалення програми відповідно до потреб адміністратора.

1. Дослідницький розділ

1.1 Постановка завдання

При розробці серверного програмного забезпечення необхідно враховувати ряд вимог, які можуть не враховуватися в процесі розробки користувальницьких додатків. Це і підвищені вимоги до стійкості роботи, і необхідність розгляду питання безпеки передачі даних, і наявність надійної системи обмеження доступу, і мінімізація використовуються програмою ресурсів операційної системи.
У разі розробки серверної програми спостереження за станом Linux-системи було виділено ряд вимог, які в процесі розробки в тій чи іншій мірі були задоволені:
· Має бути можливість підключення до програми за допомогою програмного забезпечення, встановленого на більшості комп'ютерів і самих різноманітних операційних системах, наприклад, Інтернет-браузера; це призводить до того, що програмою повинні певною мірою підтримуватися поширені протоколи передачі даних;
· Програма повинна підтримувати можливість одночасного підключення декількох клієнтів; при цьому не повинно бути взаємного впливу між частинами програми, що відповідають за обробку запитів від різних клієнтів: помилка при роботі з одним з клієнтів не повинна приводити до краху всієї програми і не повинна впливати на роботу з іншими клієнтами;
· Доступ підключаються користувачів до інформації про систему повинен бути обмежений за допомогою механізму облікових записів, причому дані про користувачів повинні зберігатися в зашифрованому вигляді;
· Модулі, що використовуються для отримання інформації про систему, повинні бути динамічно підключаються з метою можливості додавати нові модулі, не перериваючи роботу програми і, тим більше, без її повторної компіляції;
· Програма повинна відповідати стандарту POSIX і використовувати тільки стандартні бібліотеки, що входять до складу більшості UNIX-систем.

1.2 Передача даних

1.2.1 Протоколи передачі даних

Протоколом передачі даних називається ряд правил і тверджень, призначених для створення уніфікованого інтерфейсу між взаємодіючим програмним забезпеченням. Це дозволяє розробляти додатки, взаємодія між якими визначається не операційною системою, під управлінням якої вони працюють, а протоколами, врахованими при розробці.
Всі сучасні протоколи передачі даних класифіковані організацією ISO на рівні, в результаті чого з'явилося поняття моделі OSI (open systems interconnection - з'єднання відкритих систем). Відповідно до цієї моделі, існує сім рівнів розгляду передачі даних:
1. Фізичний (physical) - представлений лініями зв'язку та комунікаційним обладнанням.
2. Зв'язку (datalink) - представлений драйверами мережевого обладнання та програмним забезпеченням нижнього рівня.
3. Мережевий (network) - представлений протоколами IPv4 та IPv6.
4. Транспортний (transport) - представлений протоколами транспортного рівня, такими як TCP, UDP, ICMP та іншими.
5. Сеансовий (session) - представлений програмними засобами, що підтримують сеанси зв'язку.
6. Подання даних (divsentation) - представлений програмними засобами, які забезпечують незалежність інтерпретації даних від використовуваної системи.
7. Прикладної (application) - представлений безліччю протоколів, спрямованих на передачу певних даних - файлів, гіпертекстових документів і т.д. До цих протоколах відносяться HTTP, FTP, SMTP і ін
Програми, як правило, не використовують пряме звернення до програмних засобів, які реалізують протоколи нижніх рівнів - аж до мережевого. Для протоколів транспортного рівня в сучасних операційних системах передбачені спеціальний інтерфейс - сокети.
Найбільш поширені протоколи і взаємозв'язок між ними відображені на малюнку 2.1.

1.2.2 Протокол TCP

При розробці програми основним протоколом передачі інформації було обрано протокол транспортного рівня - TCP (Transmission Control Protocol - протокол контролю передачі). Цей протокол є надбудовою над протоколом IP і надає деяку додаткову функціональність:
· Протокол забезпечує надійну передачу даних, здійснюючи, якщо необхідно повторне відправлення або прийом пакетів, роблячи це прозоро для програми, на відміну від протоколу IP;
· Послідовність отримання пакетів суворо контролюється: пакети приходять в тому ж порядку, в якому і були відправлені; ця особливість відрізняє TCP від ​​дейтаграмним протоколів, таких як UDP;
· Протокол TCP має прийнятий у більшості операційних систем програмний інтерфейс, званий сокетами (sockets), що сильно спрощує його застосування при розробці додатків.
Протокол TCP має довгу історію - він був розроблений Міністерством оборони США для створення її внутрішньої оборонної мережі ARPAnet і спочатку призначався для об'єднання програм у складі різнорідної обчислювальної середи. Вперше протокол був реалізований університетом Берклі в операційній системі BSD4.2. У силу популярності цієї системи протокол швидко поширився на інші UNIX-системи та фактично став основою сучасної мережі Інтернет, а також більшості локальних мереж. Незважаючи на свої переваги в порівнянні з протоколом IP, TCP має і свої негативні сторони - він вкрай вимогливий до обчислювальних ресурсів комп'ютера в силу того, що потік байтів, яким оперує програма, при передачі за допомогою TCP розбивається на безліч пакетів, кожен з яких може бути відправлений кілька разів, до тих пір, поки не буде отримана відповідь про його прийом. Крім того, гнучка система адресації вимагає наявності в мережі спеціалізованих серверів, таких як DNS, DHCP і інших.

1.2.3 Протокол HTTP

Протокол HTTP (HyperText Transfer Protocol - протокол передачі гіпертексту) - це протокол рівня додатки, що здійснює зв'язок додатків в межах розподілених, спільних або різнорідних інформаційних систем. Протокол дозволяє додаткам обмінюватися даними, представленими в зрозумілому для сприйняття людиною вигляді.
Як випливає з його назви, спочатку HTTP призначався для передачі між додатками так званого гіпертексту (hypertext), що представляє собою особливий вид даних, створений у відповідності зі стандартом HTML (HyperText Markup Language - мова розмітки гіпертексту). Гіпертекстовий документ складається з даних, розмічених за допомогою тегів (tag) мови HTML, і являє собою комбінацію тексту, зображень, гіперпосилань та інших засобів подання даних. Гіперпосилання - одна з найважливіших складових HTML-документа - представляють собою інтерактивні області, вплив на які призводить до отримання пов'язаних з гіперпосиланням даних. Це дозволяє користувачеві, який працює з гіпертекстової інформацією, здійснювати навігацію в межах набору документів чи навіть всієї мережі Інтернет, отримуючи потрібну йому інформацію за допомогою контекстних гіперпосилань.
Протокол HTTP є надбудовою над протоколом TCP і є засобом контролю вмісту переданих даних. На відміну від TCP, який не враховував структуру переданих пакетів, HTTP впроваджує в дані метаінформацію, що дозволяє одержувачу коректно інтерпретувати отримані дані. На основі HTTP функціонує глобальна мережа Інтернет (звана також World Wide Web або WWW). Перша версія протоколу - HTTP/0.9 - володіла достатньо обмеженими можливостями, але з активним розвитком всесвітньої мережі з'явилися нові версії: HTTP/1.0 та HTTP/1.1, що дозволяють контролювати передачу з обчислювальних мереж не тільки гіпертекстової інформації, а й довільні бінарні файли: звукові, графічні, архівні та ін
У силу того, що HTTP є надбудовою над протоколом TCP, при передачі даних також виділяються дві сторони: клієнт і сервер.
Клієнт є ініціатором з'єднання і запитує у сервера деякі дані або послуги. Клієнтом, як правило, є програма, яка називається браузером (browser), що дозволяє як відображати гіпертекстове інформацію, так і приймати файли інших форматів. Щоб отримати деяку інформацію, клієнт посилає серверу запит (request), що містить опис запитуваної інформації.
Сервер при передачі даних через HTTP називають веб-сервером (web-server). Ця програма здійснює обробку запитів від клієнтів, передаючи запитані дані у вигляді відповідей (response), що містять крім шуканих даних метаінформацію, їх описує.
Отримання користувачем цікавлячих його даних складається з наступних етапів:
1. Користувач вводить в рядку браузера адресу цікавить його ресурсу.
2. Браузер на основі інформації, отриманої від користувача, а також з огляду на свої налаштування і конфігурацію операційної системи, формує запит.
3. Браузер підключається до сервера, розташованому, можливо, на віддаленому комп'ютері, і передає йому запит.
4. Сервер, аналізуючи запит, виконує необхідні дії: формує відповідь, включаючи в нього тіло запитаного документа. Якщо це гіпертекстовий документ, він завантажується з файлу або ж генерується динамічно за допомогою сценарію. У відповідь також включається інформація про його даних.
5. Сервер передає відповідь браузеру.
6. Браузер аналізує відповідь і або зберігає отримані дані у файл, або, у разі гіпертекстового документа, аналізує теги HTML і відображає документ на екрані.
Слід зауважити, що клієнтською програмою може бути не тільки браузер, тим не менш, всі кроки, за винятком, може бути, першого, виконуються в будь-якому випадку.
Слід зауважити, що тут розглядається безпосереднє підключення клієнта до сервера, який містить цікаву інформацію, однак, це не завжди можливо в силу різних обставин. У такому випадку підключення може здійснюватися за допомогою однієї чи більше проміжних точок підключення. Можна розділити ці проміжні точки на три групи:
· Проксі-сервери (proxy-server) - програма-посередник, що виконує функції як клієнта, так і сервера з метою створення запитів від імені інших клієнтів. Запити обслуговуються проксі-сервером, або пересилаються їм з внесенням до них змін (у цьому випадку проксі-сервер має назву непрозорим) або без змін (у цьому випадку проксі-сервер має назву прозорим). Проксі-сервер дозволяє групі комп'ютерів виступати в якості одного клієнта, що часто застосовується при підключенні до Інтернету локальних мереж.
· Шлюз (gateway) - як і проксі-сервер, здійснює трансляцію запитів, однак, не ставлю їх зміни. Шлюз отримує від клієнта запит, як до сервера, який містить шуканий ресурс. Таким чином, клієнт не може визначити, підключається він через шлюз або безпосередньо до містить ресурс сервера.
· Тунель (tunnel) - програма-посередник, що підтримує з'єднання. Хоча після установки з'єднання тунель не розглядається в якості елемента передачі через протокол HTTP, з'єднання, як правило, ініціюється саме HTTP-запитом. Тунель перериває свою роботу, якщо хоча б один з учасників обміну даними закриває з'єднання.
Для збереження функціональності передачі даних при підключенні через проміжні точки не потрібно внесення змін в запити і відповіді, за винятком випадку проксі-сервера: в цьому випадку в клієнтському запиті повинно міститися додаткові поля. Однак, з точки зору сервера, обмін даними здійснюється безпосередньо з клієнтом, отже, ніяких змін в запитах не відбувається. Поетом при розробці програми можливість підключення через проміжні точки не враховувалася.
Запит, що відправляється клієнтом серверу, служить для точної ідентифікації запитуваного ресурсу, а також містить відомості, необхідні для коректної обробки запиту.
За своєю структурою запит складається з трьох частин:
· Рядок запиту
· Блок заголовків
· Об'єкт
Рядок запиту складається з трьох полів, розділених символами пробілу (ASCII-код 20h, далі SP), і закінчується комбінацією з двох символів: повернення каретки (ASCII-код 0Dh, далі CR) і переклад рядка (ASCII-код 0Ah, далі LF) . Елементи рядка запиту представлені наступними полями:
· Метод (method) - визначає метод обробки, застосовуваний до запитуваного ресурсу. У залежності від зазначеного методу формат запиту може бути різним. Допустимі методи:
o OPTIONS
o GET
o HEAD
o POST
o PUT
o DELETE
o TRACE
При розробці програми була введена підтримка тільки методу GET, в силу того, що саме цей метод браузер вказує в запиті, створюваному за замовчуванням.
· URI (Universal Resource Identifier) ​​ресурсу (resource URI) - вказує місце розташування запитуваного ресурсу в стандартизованому форматі, тобто є адресою ресурсу. При використанні методу GET даний рядок може містити в собі набір параметрів, що передаються серверу у вигляді рядків формату «імя_параметра = значеніе_параметра», розділених символами амперсанда '&'. Блок параметрів знаходиться в кінці рядка URI і відокремлюється від адреси символом знаку питання '?'.
· Версія протоколу HTTP - при розробці програми була реалізована підтримка прийому запитів, відповідних версіями 1.0 та 1.1, яким відповідають рядки «HTTP/1.0» і «HTTP/1.1» відповідно.
Блок заголовків, наступний за рядком запиту, може складатися з одного або більше заголовків:
· Тема запиту - містить поля, службовці модифікаторами запиту і містять інформацію про запит і про конфігурацію клієнтської машини.
· Тема об'єкта - у разі, якщо запит включає в себе деякий об'єкт (довільний набір даних), поля цієї таблиці описують об'єкт, вказуючи його формат, кодування та інші параметри.
· Загальний заголовок - містить службові параметри, необхідні для забезпечення коректності передачі та включення додаткових послуг, таких, як кешування.
Розділ заголовків закінчується двома парами символів CR і LF, що дозволяє легко визначити факт закінчення прийому запиту в силу того, що сам запит подібну комбінацію символів містити не може.
Відповідь, що відправляється сервером клієнтові, може бути створений лише в результаті обробки клієнтського запиту. Він містить опис результатів виконання запиту і, якщо були запитані дані, включає в себе запитаний ресурс.
За своєю структурою відповідь складається з наступних частин:
· Рядок стану
· Блок заголовків
· Об'єкт
Рядок стану складається з трьох полів, розділених символами SP, і містить в кінці послідовність символів CR, LF. Елементи рядка стану:
· Версія протоколу HTTP - розроблена програма завжди використовує рядок «HTTP/1.1».
· Код стану (status code) - трьохсимвольний цифровий код, який ідентифікує результат виконання запиту. Хоча стандартом визначений достатньо великий набір кодів стану, у програмі використовуються наступні коди:
o 200 - успішне виконання;
o 400 - некоректний запит;
o 401 - несанкціонований доступ;
o 404 - ресурс не знайдений;
o 405 - непридатний метод;
o 505 - непідтримувана версія HTTP.
· Фраза стану (reason phrase) - коротка фраза, яка пояснює код стану виконання запиту. Стандартом запропонований стандартний набір фраз, проте в програмі цей набір був кілька модифікований.
Блок заголовків, наступний за рядком стану, може складатися з одного або більше заголовків:
· Тема запиту
· Тема об'єкта
· Загальний заголовок
Детальний розгляд заголовків було вироблено в п. 2.2.3.3.
Розділ заголовків закінчується двома парами символів CR і LF, після чого слід довільний набір символів - об'єкт. При роботі програми такими об'єктами можуть бути тільки гіпертекстові документи у форматі HTML, динамічно генеруються модулями, що підключаються.

1.3 Системна інформація ОС Linux

1.3.1 Розташування системної інформації

Всю системну інформацію про операційну систему Linux можна розділити на дві групи - за ознакою розташування цієї інформації в системі:
1. Статична інформація - до цієї групи можна віднести всі текстові конфігураційні файли, мають вплив на процес завантаження системи, функціонування її компонент. Подібна інформація, як правило, розташована в каталозі / etc і його підкаталогах.
2. Динамічна інформація - описує поточний стан системи. Подібна інформація може бути отримана читанням контексту пам'яті ядра операційної системи; доступ до цієї інформації здійснюється через файлову систему / proc (див. п. 2.3.2).
Методи отримання інформації можна також розділити на кілька груп за способом організації взаємодії з системою:
1. Читання файлів конфігурації і файлів, розташованих в / proc, за допомогою системних викликів.
2. Виклик системних утиліт, що надають відповідну інформацію.
3. Отримання інформації за допомогою виконання спеціальних системних викликів.

1.3.2 Файлова система / proc

Як було зазначено в п. 2.3.1, для отримання динамічної інформації про систему необхідно отримати доступ до контексту пам'яті ядра. В операційній системі Linux пам'ять ядра відображається на пристрій / dev / kmem. Однак, читання безпосередньо з цього можуть створити досить велику складність у силу того, що виникає необхідність знати розташування структур даних у пам'яті ядра. У ранніх версіях UNIX-систем доступ до інформації здійснювався саме так.
Згодом був запропонований механізм доступу до структур пам'яті ядра, який істотно полегшував отримання системної інформації: більшість структур даних були відображені у файли і каталоги, складові ієрархію, фактично існуючу в структурах даних ядра. Всі ці файли і каталоги були об'єднані в спеціальну файлову систему - / proc.
Адреси структур даних ядра заносяться в / proc на етапі компіляції системи. Відповідно, програми, які звертаються до / proc, повинні враховувати можливість її модифікації при встановленні більш нової версії ядра з, можливо, зміненою структурою / proc.
Звернення до файлової системи / proc відбувається тим же шляхом, що й до звичайної дискової файлової системи - за допомогою системних викликів read () і write (). Слід, однак, зауважити, що / proc не пов'язана з яким-небудь фізичним пристроєм: вміст файлів / proc генерується безпосередньо під час читання цих файлів, що призводить до неможливості визначити їх розмір звичайними засобами, а спроба дізнатися час створення і модифікації будь-якого файлу призведе до отриманню поточного часу.
Деякі файли системи / proc можуть бути використані і для запису в них даних для зміни стану системи, однак ця можливість не передбачалася при розробці програми.
Файлова система / proc містить по одному каталогу для кожного виконується в даний момент процесу. Іменем каталогу є ідентифікатор процесу; в деяких UNIX-системах ідентифікатор доповнюється нулями для додання імен каталогів процесів однакової довжини, проте, в ОС Linux подібні дії не проводяться.
Каталоги процесів динамічно створюються і знищуються в міру запуску і завершення відповідних процесів. У кожному каталозі є файли, що надають доступ до різноманітної інформації про процес.
Кожен каталог процесу містить наступні файли:
· Cmdline - містить список аргументів, переданий процесу при запуску; першим аргументом є ім'я файлу, що виконується; у разі, якщо процес вивантажений (наприклад, знаходиться в стані зомбі), файл буде порожній;
· Cwd - є символічною посиланням на поточний робочий каталог процесу;
· Environ - містить змінні середовища процесу;
· Exe - є символічною посиланням на виконуваний файл процесу; її читання є практично єдиним способом визначити каталог, що містить виконуваний файл;
· Fd - підкаталог, що містить символічні посилання на файли, відкриті процесом;
· Maps - містить інформацію про файли, які відображаються в адресному просторі процесу; до числа файлів, що відноситься виконуваний файл процесу, а також завантажені бібліотеки;
· Root - є символічною посиланням на кореневий каталог процесу;
· Stat - містить статистичну інформацію про процес;
· Status - містить ті ж дані, що і stat, але в відформатованому вигляді.
З міркувань безпеки права доступу до деяких файлів каталогів процесу надані тільки власнику процесу або надкористувачу.
У файловій системі / proc є додатковий елемент, що дозволяє програмам знаходити інформацію про своє власне процесі. Файл / proc / self є символічною посиланням на каталог, що відповідає поточному процесу. Зрозуміло, вміст посилання залежить від того, який процес до неї звертається.
Інформація про апаратуру, встановленої на комп'ютері, може бути отримана з наступних файлів файлової системи / proc:
· / Proc / cpuinfo - містить інформацію про центральному процесорі (або процесорах, якщо їх більше одного); файл містить інформацію в відформатованому вигляді; крім вказівки моделі процесора, файл містить вказівку доступних процесорних функцій, таких як розширені інструкції MMX;
· / Proc / devices - містить список старших номерів усіх символьних і блокових пристроїв, встановлених в системі;
· / Proc / pci - містить інформацію про всі пристрої, підключених до шини PCI, включаючи пристрої, вбудовані в материнську плату;
· / Proc / ide - каталог, що містить файли, які описують пристрої, підключені до шин IDE і SCSI.
· / Proc / net / dev - містить інформацію про мережеві платах і їх конфігурації.
Інформація про конфігурацію та стан ядра системи представлена ​​в наступних файлах:
· / Proc / version - містить рядок, що описує номер версії та модифікації ядра; в неї також включена додаткова інформація: ім'я користувача, що здійснив компіляцію, дата компіляції і версія компілятора;
· / Proc / meminfo - зберігає відомості про використання системної пам'яті; вказуються дані як про фізичної пам'яті, так і про область підкачки;
· / Proc / modules - повний список встановлених модулів ядра в текстовому вигляді.
Інформація про файлових системах представлена ​​наступними файлами:
· / Proc / filesystems - список файлових систем, підтримуваних ядром;
· / Proc / mounts - містить перелік змонтованих файлових систем; кожен рядок файлу містить ім'я пристрою, ім'я точки монтування, тип файлової системи і прапори монтування.

2. Технологічний розділ

2.1 Вибір мови програмування

В даний час в UNIX-подібних операційних системах представлена ​​велика кількість самих різноманітних мов програмування, кожний з яких володіє своїми перевагами. При розробці програми була обрана мова C і відповідний йому компілятор з пакета gcc (GNU compilers collection) з наступних причин:
· У силу того, що саме ядро ​​операційної системи написано на мові C, компілятор мови, що входить до складу пакету gcc, постійно оновлюється і виправляється, що практично виключає помилки при компіляції з його боку, у свою чергу, це призводить до генерації найбільш оптимізованого коду ;
· Мова C припускає використання простих конструкцій, що вигідно відрізняє його від інших мов, особливо інтерпретованих і об'єктно-орієнтованих, з точки зору швидкості виконання програм;
· Мова C надає програмісту найбільш повний доступ до всіх можливостей програмного інтерфейсу POSIX, що дозволяє найбільш ефективно організовувати взаємодію програми з операційною системою.

2.2. Програмні засоби

2.2.1 Потоки

Розроблена програма має можливість паралельної обробки запитів від декількох клієнтів. Це досягнуто за рахунок використання більш ніж одного потоку управління, що здійснюють обробку запитів.
Потоки в системі Linux реалізуються за допомогою програмного інтерфейсу, що надається входить до складу Linux бібліотеки потоків libpthread.
Створення потоку розбивається на кілька етапів:
1. Опис функції, яка буде виконуватися в рамках потоку. Ця функція не повинна містити статичних змінних.
2. Створення екземпляра описувача атрибутів потоку - структури типу pthread_attr_t, - і заповнення її полів у відповідності з необхідними властивостями створюваного потоку.
3. Створення змінної типу pthread_t, яка буде служити ідентифікатором створюваного потоку.
4. Створення потоку за допомогою функції pthread_create (), в яку передається покажчик на ідентифікатор потоку, покажчик на описувач атрибутів потоку, а також адресу потокової функції та її аргумент.
Після створення потік виконується паралельно з іншими потоками процесу і завершує свою роботу при виконанні в потоковій функції оператора return або примусовому завершення ззовні.

2.2.2 Семафори і м'ютекси

Для забезпечення безпеки доступу виконуються потоків до поділюваних змінним, якими є, наприклад, змінні стану систем журналювання та безпеки, використовується механізм взаємоблокування потоків за допомогою об'єкту ядра - мьютекса.
М'ютекс являє собою змінну типу pthread_mutex_t, до якої застосовні дві операції:
· Pthread_mutex_lock - захоплення мьютекса; при застосуванні цієї операції до захопленого іншим потоком мьютекс викликав потік блокується до звільнення мьютекса.
· Pthread_mutex_unlock - звільнення мьютекса.
Для контролю числа одночасно обслуговуваних запитів в серверному модулі застосовується об'єкт ядра - семафор.
Семафор являє собою змінну типу sem_t, до якої застосовні дві основні операції:
· Sem_wait - зменшує на 1 поточне значення семафора; якщо поточне значення дорівнює 0, потік блокується;
· Sem_post - збільшує на 1 значення семафора.
Початкове значення семафора задається при його ініціалізації за допомогою функції sem_init ().

2.2.3 Сокети

Сокет представляє собою об'єкт, що дає програмний інтерфейс до протоколу TCP / IP і є кінцевою точкою підключення. Використання сокета нічим не відрізняється від використання операцій введення-виведення стосовно до файлового дескриптора - до сокета застосовуються ті ж функції read () і write (), що і при файловому введенні-висновку. Існують, однак, специфічні функції send () і recv (), що розширюють функціональність стандартних read () і write (), але їх використання не є обов'язковим.
Перед початком процесу передачі даних через сокет необхідно здійснити ряд дій:
1. Створити змінну типу int, яка буде виступати в якості дескриптора сокета.
2. Створити описувач адреси сокета - структуру типу sockaddr_in, - і заповнити її поля у відповідності з адресою і портом, через які планується встановлювати з'єднання.
3. Створити об'єкт «сокет» за допомогою функції socket (). Значення, повернене функцією, присвоюється дескриптору сокета.
4. Прив'язати сокет до адреси і порту за допомогою функції bind ().
5. Почати прослуховування адреси і порту на предмет вхідних з'єднань за допомогою функції listen ().
6. Приймати з'єднання за допомогою функції accept ().
Слід зауважити, що процедура ініціалізації клієнтського сокета виконується трохи інакше і не розглядалася в силу того, що розроблена програма не виступає в якості клієнта.

2.2.4 Сигнали

Контроль сигналів використовується в програмі для припинення роботи серверу. При надходженні певного сигналу обнуляється мінлива-умова, в результаті чого цикл прийому повідомлень переривається.
Установка деякої функції в якості обробника сигналу проводиться наступним чином:
1. Визначення функції - обробника сигналу.
2. Створення і заповнення описувача параметрів обробника - структури типу sigaction. Одне з полів описувача містить адресу функції-обробника.
3. Призначення оброблювача сигналу за допомогою функції sigaction ().

2.3 Структура модулів програми

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


2.3.1 Система ініціалізації

Система ініціалізації призначена для конфігурування програми і запуску сервера. З неї починається виконання програми в силу того, що вона включає в себе функцію main ().
При розробці програми були визначені наступні параметри:
· LogMode - режим журналювання, може приймати значення short (короткий режим журналювання) і verbose (висновок розширених повідомлень).
· LogDir - каталог, в який буде здійснюватися запис журнальних файлів.
· Address - адреса в форматі xxx.xxx.xxx.xxx, який буде використаний для прив'язки серверного сокета.
· Port - номер порту, який буде використаний для прив'язки серверного сокета.
· MaxClients - максимальне число одночасно обслуговуваних клієнтів.
· AccountFile - шлях до файлу, що містить облікові записи користувача.
· ModulesDir - каталог, що містить модулі, що підключаються (у вигляді динамічних бібліотек).
Система ініціалізації виробляє трехшаговую установку параметрів:
1. Встановлюються значення за замовчуванням.
2. Завантажуються значення з файлу конфігурації.
3. Завантажуються значення з аргументів командного рядка.
Кожен наступний крок має пріоритет над попереднім; це означає, що якщо для параметра існує рядок у файлі конфігурації, то буде враховуватися значення, завантажене з файлу конфігурації, а якщо значення параметра вказано ще й у командному рядку, то буде використано саме воно.
Після визначення значень параметрів система ініціалізації робить налаштування відповідних систем (сервери, системи журналювання і системи безпеки) через наданий ними інтерфейс.
Система ініціалізації також здійснює настройку обробника сигналу SIGINT (див. п. 3.2.2) з метою можливості коректно перервати роботу сервера. Для цього створюється змінна типу int, спочатку містить значення 1. При виникненні сигналу функція обробки здійснює скидання змінної в 0, тим самим роблячи умова циклу прийому підключень помилковим, що призводить до виходу з циклу і завершення роботи сервера.

2.3.2 Сервер і система управління динамічними бібліотеками

Серверна система є центральною системою програми і забезпечує серверні функції: ініціалізацію мережевих засобів, організацію прийому вхідних підключень, перевірку коректності запиту і т.д.
Дії, що виконуються сервером, можна описати наступним чином:
1. Створення та налаштування серверного сокета.
2. Прийом вхідного підключення.
3. Створення потоку, який буде обробляти запит.
Пункти 2 і 3 повторюються протягом усього часу роботи сервера.
Потік, що обробляє запит, виконує наступні дії:
1. Приймає запит від клієнта.
2. Перевіряє коректність запиту.
3. У разі коректного запиту звертається до системи безпеки для підтвердження доступу.
4. У разі дозволу доступу звертається до системи управління динамічними бібліотеками, передавши їй ім'я запитаного модуля.
5. Система управління динамічними бібліотеками завантажує відповідну бібліотеку і виконує зберігається в ній функцію генерації.
Робота сервера продовжується до тих пір, поки не дорівнює нулю мінлива, адреса якої був переданий серверного модуля при старті. Ця змінна обнуляється при отриманні процесом сигналу SIGINT (відповідного комбінації Ctrl + C на клавіатурі). Використання сигналів описано в п. 3.2.4.

2.3.3 Система журналювання

Система журналювання забезпечує запис у журнальний файл ключових подій, що відбуваються під час роботи сервера. У журнал подій записується інформація про такі події:
· Старт сервера - із зазначенням адреси і порту прив'язки.
· Вхідне підключення - із зазначенням адреси клієнта.
· Авторизація клієнта.
· Запит модуля.
· Повідомлення про різноманітні помилки в роботі сервера.
Система журналювання самостійно генерує ім'я файлу на підставі поточної дати: журнальні файли мають імена виду dd-mm-yyyy.log.
Для захисту своїх статичних даних система використовує мьютекс (див. п. 3.2.2), що призводить до монополізації доступу потоків до системи. Це може дещо сповільнити роботу, однак розроблене додаток не є критичним до часу, тому виникають затримки цілком припустимі.
Система безпеки слугує для перевірки можливості доступу клієнта до будь-яких модулів сервера.
Система безпеки може функціонувати в двох режимах:
· Режим перевірки доступу - сервер передає системі ім'я користувача та пароль, які вона намагається знайти у файлі облікових записів. У разі знаходження збіги доступ надається, в іншому - не надається.
· Режим надання доступу - в цьому випадку доступ надається для всіх клієнтів незалежно від зазначених імені та пароля. Використовується тільки для тестування сервера.
Режим роботи системи і адреса файлу з обліковими записами можуть бути задані в конфігураційному файлі.
Система безпеки, як і система журналювання, використовує мьютекс (див. п. 3.2.2) для захисту доступу до своїх статичним змінним.

2.4 Динамічні бібліотеки

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

2.4.1 PROCESSES - інформація про процеси

Ця динамічна бібліотека служить для отримання інформації про всі процеси, що існують у даний момент в системі. Для кожного процесу виводиться наступна інформація:
· Ідентифікатор (PID) процесу - виходить шляхом читання списку каталогів файлової системи / proc і вибору тих з них, назва яких складається лише з цифр. У цьому випадку ім'я каталогу і буде ідентифікатором процесу.
· Ім'я файлу, що виконується - зчитується з файлу stat каталогу процесу в / proc.
· Стан процесу - зчитується з файлу status каталогу процесу.
· Ім'я власника процесу - виходить за допомогою функції stat (), застосованої до каталогу процесу. Ім'я власника процесу збігається з ім'ям власника каталогу процесу.
· Ім'я групи власника процесу - аналогічно імені власника процесу, виходить за допомогою функції stat ().
· Розмір резидентної частини процесу - зчитується з файлу statm з каталогу процесу.
Результати роботи динамічної бібліотеки відображаються в клієнтському браузере у вигляді таблиці.

2.4.2 MEMINFO - інформація про системну пам'яті

Результат роботи цієї динамічної бібліотеки являє собою таблицю, що містить інформацію про розподіл системної пам'яті. Серед ключових полів таблиці можна зазначити:
· Загальна кількість доступної фізичної пам'яті.
· Розмір вільної частини пам'яті.
· Розмір пам'яті, що розділяється між процесами.
· Кількість буферів вводу-виводу.
· Інформація про область підкачки.
Надана інформація витягується з файлу / proc / meminfo.

2.4.3 DISKFREE - інформація про вільне місце на дисках

Дана динамічна бібліотека відображає у вигляді таблиці інформацію про змонтованих в даний момент дискових файлових системах, а також інформацію про доступний і вільному просторі на дисках.
Інформація виходить за допомогою команди оболонки fd (файл / bin / fd). Для того, щоб перенаправити дані, що видаються при виконанні команди, використовується дублювання процесу за допомогою функції fork () і завантаження в адресний простір породженого процесу даних програми fd за допомогою функції execv (). Виведення інформації в дескриптор сокета замість виведення на консоль здійснюється відображенням потоку даних, що виводяться в стандартний потік виводу, на дескриптор сокета за допомогою функції dup2 ().

2.4.4 NETWORK - інформація про мережеві пристроях

Дана динамічна бібліотека дозволяє отримати статистичні дані про роботу мережевих пристроїв (мережевих інтерфейсів), встановлених в системі. Для кожного пристрою виводиться наступна інформація:
· Кількість прийнятих та відправлених байтів і пакетів.
· Кількість виникли за час прийому і передачі помилок.
· Кількість втрачених при прийомі і передачі пакетів.
· Кількість колізій при передачі.
Інформація виходить за допомогою аналізу файлу / proc / net / dev, що містить докладну статистичну інформацію про мережеві пристрої. Деяка інформація, отримана з файлу, не враховувалася, оскільки не представляє великої цінності для системного адміністратора.

2.4.5 VERSION - версія операційної системи

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

2.4.6 INDEX - сторінка допомоги

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

2.5 Використання програми

2.5.1 Налаштування сервера

Конфігурування систем програми може бути здійснено одним з трьох способів:
· Встановлення значень за замовчуванням - параметри всіх систем встановлюються за замовчуванням; значення параметрів за умовчанням встановлюються на етапі компіляції програми.
· Завантаження конфігурації з файлу - всі параметри завантажуються з файлу, що складається з рядків виду «імя_параметра = значення». Для зберігання параметрів використовується файл linspy.conf, що знаходиться в одному каталозі з виконуваним файлом програми.
· Встановлення значень з командного рядка - в цьому випадку параметри системи встановлюються відповідно до переданих аргументами командного рядка.
Останній спосіб найбільш зручний для швидкої зміни настройок сервера. Всі опції командного рядка, які підтримуються програмою, представлені в таблиці 3.1:
Таблиця 3.1
Опція командного рядка
Пояснення
-H, - help
програма виводить опис опцій командного рядка і завершується;
-M dir, - moddir dir
встановлює каталог завантаження динамічних бібліотек рівним dir; може бути використано для швидкої зміни набір бібліотек;
-V, - verbose
включає розширений режим ведення журнального файлу
-S mode, - security mode
включає або вимикає режим перевірки доступу в залежності від значення mode; якщо mode = "on", перевірка доступу включається, а якщо mode = "off" - вимикається;
-A ip, - addr ip
встановлює адресу прив'язки серверного сокета рівним ip;
-P num, - port num
встановлює порт прив'язки серверного сокета рівним num;
-D, - daemon
програма завантажується у фоновому режимі (режимі демона).

2.5.2 Доступ до сервера

Доступ до сервера через браузер передбачає знання користувачем адреси і порту прив'язки сервера, а також, у випадку роботи системи безпеки в режимі перевірки доступу, ім'я користувача та пароль, які присутні у файлі облікових записів.
Наприклад, при зверненні до модуля «somemodule» при підключенні до сервера, прив'язаному до адресою 123.123.123.123 і порту 8080, при включеній системі безпеки, знаючи ім'я користувача - «mylogin» - і пароль - «mypassword» - рядок адреси, яка повинна бути введена в браузері, буде виглядати наступним чином: http://123.123.123.123:8080/somemodule?login=mylogin&password=mypassword
У разі відключеною системи безпеки рядок зміниться: http://123.123.123.123:8080/somemodule
При виникненні будь-якої помилки при обробці запиту - як з боку коректності запиту, так і з боку можливості виконати запитані дії - у вікно браузера видається повідомлення про помилку.
Помилка може виникнути в одній з наступних ситуацій:
· Отриманий сервером запит некоректний - вказана невірна версія протоколу HTTP, непідтримуваний метод або сама структура запиту містить помилки.
· Запитаний модуль не може бути знайдений, або він пошкоджений.
· Зазначені ім'я користувача та пароль недійсні.

2.5.3 Завершення роботи сервера

Завершення роботи сервера виникає в результаті прийому серверним процесом сигналу SIGINT, відповідного натисненню клавіатурної комбінації Ctrl + C. Однак, якщо сервер запущений у фоновому режимі (режимі демона), вплив на нього за допомогою клавіатури не представляється можливим. У цьому випадку слід надіслати процесу сигнал за допомогою команди оболонки kill або killall:
· Kill-INT pid, в цьому випадку необхідно знати PID запущеного процесу;
· Killall-INT linspy - тут пошук процесу ведеться на ім'я виконуваного файлу.
Друга команда включена в файл shutdown.sh, що представляє собою сценарій оболонки і завершальний роботу програми.
У разі примусового завершення роботи програми, наприклад, за допомогою сигналу SIGKILL, серверний сокет не буде закрито коректно, що призведе до неможливості деякий час прив'язатися до тих же адресою та в порту, до яких здійснювалася прив'язка до цього. Крім того, може виникнути спотворення записуваних в журнальний файл даних - деякі повідомлення можуть виявитися втраченими.

Висновок

Розроблена програма дозволяє віддалено спостерігати за станом комп'ютера, що працює під управлінням операційної системи Linux. У програмі реалізована часткова підтримка протоколу HTTP/1.1, що дозволяє підключитися до неї за допомогою браузера, що працює під управлінням будь-якої сучасної операційної системи. Також програма з мінімальними змінами може бути перенесена на більшість сучасних UNIX-подібних систем в силу того, що при розробці використовувалися виключно засоби API POSIX.
Програма повністю задовольняє вимогам технічного завдання, забезпечуючи:
· Можливість гнучкого налаштування програми, в тому числі її прив'язка до будь-якою адресою та в порту.
· Можливість одночасної обробки запитів від віддалених клієнтів за рахунок використання механізму багатопоточності.
· Можливість обмеження кількості одночасно оброблюваних запитів.
· Забезпечення безпеки за рахунок необхідності вказувати ім'я користувача і пароль при підключенні до сервера; програма використовує власний файл облікових записів.
· Можливість підключення за допомогою будь-якого браузера, що підтримує протокол HTTP/1.0 або HTTP/1.1.
Хоча для вирішення адміністративних завдань вже існують готові програмні рішення, а в якості HTTP-сервера в середовищі Linux, як правило, використовується сервер Apache, розроблена програма має перед ними певні переваги:
· Швидкість роботи, що забезпечується невеликим розміром програми і простотою логіки її роботи.
· Простота доступу до системної інформації Linux.
· Легкість для читання одержуваної інформації, що не накладає вимог на кваліфікацію користувача.

Список використаної літератури

1. M. Mitchel, J. Oldham, A. Samuel Advanced Linux Programming / Indianapolis , Indiana : Williams, 2004 - 288 с.
2. RFC 1945 - HTTP/1.0 Protocol
3. RFC 2616 - HTTP/1.1 Protocol
4. E. Nemeth, G. Snyder, S. Seebass, T. Hein UNIX System Administration Handbook 3 rd Edition / New Jersey: Prentice Hall, 2003 - 925 c., илл.
5. R. Stevens, B. Fenner, A. Rudoff UNIX Network Programming / Addison Wesley, 2003 - 1024 c., илл.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
108.1кб. | скачати


Схожі роботи:
Робота з HTTP протоколом в Delphi
Зчитування інформаії з мережі Internet за допомогою HTTP
Протокол розбіжностей
Протокол ТСР
Протокол TACASC
Протокол міжмережевої взаємодії IP
Протокол ТфОП інтерфейсів V5 1 і V5 2
Протокол судового засідання
Протокол огляду місця події
© Усі права захищені
написати до нас
Рейтинг@Mail.ru