Студопедия

Главная страница Случайная страница

Разделы сайта

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






Функції резервування.






Інтерфейс прикладного рівня. Для користування сервісами прикладного рівня користувачу надається інтерфейс прикладного рівня (рис.2.2). Інтерфейс прикладного рівня може представляти собою комунікаційні функції, доступ до таблиці мережних об’єктів (мережні змінні, словник об’єктів) тощо. Деякі промислові мережі надають можливість графічного конфігурування обміну даними на прикладному рівні, наприклад через мову функціональних блоків (FF, LONWorks). Ці програмні засоби надають графічний вигляд інтерфейсу прикладного рівня.

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

Взаємодія між прикладними Процесами. Для того, щоб прикладні Процеси на вузлах могли обмінюватися даними, необхідно налаштувати між ними зв’язок. В залежності від реалізації такого зв’язку можна виділити три моделі взаємодії між прикладними Процесами:

- модель Клієнт-Сервер (Client-Server);

- модель Видавець-Абонент (Publisher-Subscriber);

- модель Виробник-Споживач (Producer-Consumer);

Модель Клієнт-Сервер передбачає взаємодію тільки двох прикладних Процесів: Процесу-запитувача (Клієнт) та Процесу-відповідача (Сервер). Замовлення послуг проводиться за допомогою запитів (request). Сервер, обробивши запит повертає відповідь (response). Структура запиту і відповіді залежить від реалізації протоколу. У виродженому варіанті це можуть бути дані для запису (в запиті) та для читання (у відповіді).

Модель Видавець-Абонент(Publisher-Subscriber)

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

Процедура передачі даних називає-ться публікацією (publication).Цей тип обміну найбільш підходить для передачі даних у багатоадресному режимі, оскільки прикладних Процесів-Абонентів може бути декілька. Таким чином у певний момент часу дані надходять від прикладного Процесу-видавця всім Процесам-абонентів. У залежності від того, який прикладний Процес генерує публікацію, виділяють два типи моделі Видавець-Абонент (рис.2.5):

- pull model, коли момент публікації визначає прикладний Процес одного із вузлів, який у необхідний момент відправляє запит на публікацію. У деяких системах це може бути спеціально виділений прикладний Процес, що називається Pull Publishing Manager;

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

Прикладний Процес у системі для одних даних може бути Видавцем, а для інших – Абонентом.

Рисунок 2.3 - Функціонування моделі Видавець-Абонент: pull model – ліворуч, push model – праворуч, 1 – публікація, 2- запит на публікацію

Модель Виробник-Споживач (Producer-Consumer) з точки зору користувача аналогічна моделі Видавець-Абонент, за винятком того, що для адресації отримувачів використовується фільтрація по ідентифікатору повідомлень типу Виробник-Споживач-msg. Як правило фільтрація повідомлень проходить вже на канальному рівні, однак для мереж на базі Ethernet, цей процес може проходити на більш високих рівнях. Прикладний Процес, який в широкомовному режимі видає (виробляє) дані в мережу називається Виробником, а який їх приймає – Споживачем. Всі інші характеристики аналогічні моделі Видавець-Підписувач, тому при розгляді функціонування мереж на прикладному рівні – ці моделі ототожнюються.
Слід зазначити, що с стандарті МЕК 61158-1 виділені тільки дві моделі взаємодії між прикладними процесами Клієнт-Сервер та Видавець-Абонент.

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

Можна виділити два способи ідентифікації даних: вказати необхідні дані для обміну на початку функціонування мережі або вказувати область та формат даних безпосередньо в момент обміну між прикладними Процесами. Перший спосіб будемо називати ідентифікованим обміном (identified data), а другий обміном повідомленнями (messaging).

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

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

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

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

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

- обмін повідомленнями для даних процесу, що потрібні по запиту, або для параметричних даних (конфігурування, програмування, діагностика тощо);

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

1. Клієнт-серверна модель обміну повідомленнями; представники: MODBUS (MBAP), CANOpen (SDO), FF(незаплановані повідомлення), WorldFIP (Aperiodic Traffic).

2. Клієнт-серверна модель ідентифікованого обміну (Polling); представники: Profibus DP (DP-V0/V1), INTERBUS(PDC), AS-I.

3. Модель Видавець-Абонент / Виробник-Споживач ідентифікованого обміну; представники:

WorldFIP(PeriodicTraffic), FF (заплановані повідомлення), RTPS, Profibu DP (DPV2), CANOpen (PDO), LON-Works (NVT).

4. Модель Видавець-Абонент/ Виробник-Споживач обміну повідомленнями; представники: CIP (ExplicitMessage Connection), LonWorks (SNVT), FF (VCR розсилка звітів).

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

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

 

Приклад 2.1. Основні концепції. Клієнт-сереверна модель обміну повідомленнями.

Завдання. Навести приклад роботи клієнт-серверної моделі обміну повідомленнями.

Рішення. Припустимо, що прикладному Процесу вузла 1 (рис.2.6) необхідно прочитати значення змінної А з Процесу на вузлі 2 і занести результат у свою змінну В. Для цього користувачу (інженеру) необхідно скористатися відповідним інтерфейсом. Це може бути візуальний інтерфейс або прикладна функція типу:

ЧИТАТИ_МЕРЕЖ_ЗМІННУ_ (А, В),

де: А – назва змінної з віддаленого вузла, а В – назва змінної, куди буде записуватись результат.

Рисунок 2.4 - Приклад організації клієнт-серверної архітектури

У цьому випадку Процес вузла 1 виступає як Клієнт, а вузла 2 – як Сервер. Вузол 1 робить запит, який складається з 2-х байт. Перший байт вказує на команду, тобто функцію (в нашому прикладі „R”- читання змінної), другий – являє собою аргумент даної функції. Оскільки використовувана функція – це читання, то аргументом буде об’єкт для читання (в нашому випадку змінна А). Єдиний протокол прикладного рівня робить такий формат запиту зрозумілим для Процесу вузла 2. Обробивши запит Клієнта, Процес-Сервер зчитує значення змінної А (=10) і направляє відповідь із 3 байт: функція – „r” (відповідь на читання), аргумент відповідної функції і безпосередньо результат. На рисунку не показане проходження запиту та відповіді через всі рівні мережі (приклад 2.3), тому вони прямують безпосередньо між Процесами

Як правило, для клієнт-серверного обміну повідомленнями, дані при читанні/запису групують. Так, наприклад, при циклічн-періодичному опитуванні системою SCADA/HMI не згрупованих даних з контролера, вона буде звертатися до нього за кожною змінною окремим запитом, що значно зменшить продуктивність обміну. В найгіршому випадку для 100 змінних треба буде генерувати 100 повідомлень-запитів і відповідно отримати 100 повідомлень-відповідей. Крім того кожний запит обрамляється службовими байтами (символами), які можуть бути більшими за корисну інформацію. Тому на практиці при читанні та при записі користуються повідомленнями-запитами групового пересилання даних з полями „номер початкової змінної” і „кількість змінних”. Для збільшення швидкодії мережі всі змінні, які приймають участь в обміні, бажано групувати разом, щоб вони зчитувались по можливості одним запитом-повідомленням!

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

- читання/запис значень змінних;

- управління роботою пристроїв (старт, стоп, ініціалізація);

- діагностика пристроїв;

- конфігурування пристроїв та завантаження програми.

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

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

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

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

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

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

Таблиця 2.2 - Найбільш підходящі моделі для реалізації сервісів обміну даними на прикладному рівні

сервіси прикладного рівня краща модель реалізації
обмін даними процесу циклічно-періодичний pull Publish-Subscribe (Producer-Consumer) ідентифікованого обміну
ациклічний по зміні push Publish-Subscribe (Producer-Consumer) ідентифікованого обміну
ациклічний по запиту клієнт-серверна модель обміну повідомленнями
програмування/конфігурування вузла (обмін параметричними даними) клієнт-серверна модель обміну повідомленнями
управління станом вузла клієнт-серверна модель обміну повідомленнями
діагностичні сервіси для ідентифікації помилки - Publish-Subscribe (Producer-Consumer) обміну повідомленнями
функції резервування для відправки образу процесу - Publish-Subscribe (Producer-Consumer) ідентифікованого обміну

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

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

Архітектура клієнт – сервер

Архітектура клієнт – сервер (client-server architecture) – це концепція інформаційної мережі, в якій основна частина її ресурсів зосереджена в серверах, обслуговуючих своїх клієнтів (рис. 1). Розглянута архітектура визначає два типи компонентів: сервери і клієнти.

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

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

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

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

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

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

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

- NetWare фірми Novel;

- Windows NT фірми Microsoft;

- UNIX фірми AT & T;

- Linux.

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

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

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

Мережі клієнт – серверної архітектури мають наступні переваги:

- Дозволяють організовувати мережі з великою кількістю робочих станцій;

- Забезпечують централізоване управління обліковими записами користувачів, безпекою та доступом, що спрощує мережне адміністрування;

- Ефективний доступ до мережевих ресурсів;

- Користувачеві потрібен один пароль для входу в мережу і для отримання доступу до всіх ресурсів, на які поширюються права користувача.

Поряд з перевагами мережі клієнт – серверної архітектури мають і ряд недоліків:

- Несправність сервера може зробити мережу непрацездатною, як мінімум втрату мережевих ресурсів;

- Вимагають кваліфікованого персоналу для адміністрування;

- Мають вищу вартість мереж і мережевого обладнання.

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

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

Розглянемо випадок, коли користувачеві, який працює з текстовим редактором на персональному комп'ютері А, треба прочитати частину деякого файла, розташованого на диску персонального комп'ютера В (рис.2.5). Передбачимо, що ми зв'язали ці комп'ютери по кабелю зв'язку через СОМ-порти, які, як відомо, реалізовують інтерфейс RS-232C (таке з'єднання часто називають нуль-модемним). Нехай для визначеності комп'ютери працюють під управлінням MS-DOS, хоч принципового значення в цьому випадку це не має.

Драйвер СОМ-порту разом з контролером СОМ-порту працюють приблизно так само, як і у описаному вище разі взаємодії ПП з комп'ютером. Однак при цьому роль пристрою управління ПП виконує контролер і драйвер СОМ-порту іншого комп'ютера. Разом вони забезпечують передачу по кабелю між комп'ютерами одного байта інформації. (У “справжніх” локальних мережах подібні функції передачі даних в лінію зв'язку виконуються мережевими адаптерами і їх драйверами.)

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

Рисунок 2.5 - Взаємодія двох комп’ютерів

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

Щоб передати це повідомлення комп'ютеру В, додаток А звертається до драйвера СОМ-порту, повідомляючи йому адресу в оперативній пам'яті, по якій драйвер знаходить повідомлення і потім передає його байт за байтом додатку В.Додаток В, прийнявши запит, виконує його, тобто прочитує необхідну область файла з диска за допомогою засобів локальної ОС в буферну область своєї оперативної пам'яті, а далі за допомогою драйвера СОМ-порту передає прочитані дані по каналу зв'язку в комп'ютер А, де вони і попадають до додатку А.

Описані функції додатку А могла б виконати сама програма текстового редактора, але включати ці функції до складу кожного додатку текстових редакторів, графічних редакторів, систем управління базами даних і інших додатків, яким потрібен доступ до файлів, не дуже раціонально (хоч існує велика кількість програм, які дійсно самостійно вирішують всі задачі по міжмашинному обміну даними, наприклад Kermit програма обміну файлами через СОМ-порти, реалізована для різних ОС, Norton Commander 3.0 з його функцією Link). Набагато вигідніше створити спеціальний програмний модуль, який буде виконувати функції формування повідомлень-запитів і прийому результатів для всіх додатків комп'ютера. Як вже було раніше сказано, такий службовий модуль називається клієнтом. На стороні комп'ютера В повинен працювати інший модуль сервер, що постійно чекає приходу запитів на виділений доступ до файлів, розташованих на диску цього комп'ютера. Сервер, прийнявши запит з мережі, звертається до локального файла і виконує з ним задані дії, можливо, з участю локальної ОС.

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

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

Рисунок 2.6 - Взаємодія програмних компонентів при зв'язку двох комп'ютерів

 

Дуже зручною і корисною функцією клієнтської програми є здатність відрізнити запит до виділеного файла від запиту до локального файла. Якщо клієнтська програма уміє це робити, то додатки не повинні піклуватися про те, з яким файлом вони працюють (локальним або виділеним), клієнтська програма сама розпізнає і перенаправляє (redirect) запит до виділеної машини. Звідси і назва, що часто використовується для клієнтської частини мережевої ОС, редиректор. Іноді функції розпізнавання виділяються в окремий програмний модуль, в цьому випадку редиректором називають не всю клієнтську частину, а тільки цей модуль.

Сервери Інтернет. Web-сервер, його функції та вимоги до нього вимоги. Microsoft Internet Information Services (MIIS). Web-сервер Apaсhe. Протоколи прикладного рівня: HTTP, FTP, POP, IMAP, SMTP Теlnet. Їх призначення та застосування. Взаємодія з сервером HTTP. Компоненти запиту клієнта і відповіді сервера. Web-сервіс, його функціональні блоки та конструктивні рішення. Протокол SOAP, застосування та переваги.

В залежності від функціонального призначення розрізняють файлові сервери (англ. File server), проксі-сервери, FTP-сервери, Web-сервери, DNS-сервери, SQL-сервери, термінальні сервери, Інтернет-сервери та інші.

Веб-се́ рвер (англ. Web Server) — це сервер, що приймає HTTP-запити від клієнтів, зазвичай веб-браузерів, видає їмHTTP-відповіді, зазвичай разом з HTML-сторінкою, зображенням, файлом, медіа-потоком або іншими даними. Веб-сервер — основа Всесвітньої павутини.

Веб-сервером називають як програмне забезпечення, що виконує функції веб-сервера, так і комп'ютер, на якому це програмне забезпечення працює.

Клієнти дістаються веб-сервера за URL-адресою потрібної їм веб-сторінки або іншого ресурсу.

Додатковими функціями багатьох веб-серверів є:

- Ведення журналу серверу про звернення користувачів до ресурсів

- Автентифікація користувачів

- Підтримка сторінок, що динамічно генеруються

- Підтримка HTTPS для захищених з'єднань з клієнтами

Існує багато веб-серверів. Сьогодні найпоширенішими є:

- NCSA HTTPd — один із перших веб-серверів, розроблений Робертом Маккулом (англ. Robert McCool) та іншими у компанії NCSA.

- Apache — веб-сервер з відкритим початковим кодом, найчастіше використовується в Unix-подібних ОС

- IIS — веб-сервер компанії Microsoft, розповсюджується з ОС сімейства Windows NT

- lighttpd — open-source веб-сервер.

- Google Web Server — веб-сервер, створений на основі Apache компанією Google.

- Resin — open-source сервер для застосувань java.

- Cherokee — вільний багатоплатформовий веб-сервер, написаний на С.

- Rootage — багатоплатформовий веб-сервер, написаний на java.

- THTTPD — простий, маленький, швидкий, переносний і добре захищений веб-сервер, розроблений для Unix-систем.

- GlassFish — Java EE сервер застосувань з відкритим кодом, розроблений компанією Sun Microsystems

IIS (Internet Information Services, до версії 5.1 — Internet Information Server) — це набір серверів для декількох службІнтернету від компанії Майкрософт. IIS поширюється з операційними системами родини Windows NT.

Основний компонент IIS — веб-сервер, який дозволяє розміщувати в Інтернеті сайти. IIS підтримує протоколи HTTP, HTTPS, FTP, POP3, SMTP, NNTP. IIS другий за популярністю веб-сервер за кількістюсайтів, після Apache HTTP Server. За даними компанії Netcraft на11.10.2007, понад 37.13% сайтів обслуговується веб-сервером IIS.

Apache HTTP -сервер - вільний веб -сервер.

Apache є кросплатформним ПО, підтримує операційні системи Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.

Основними достоїнствами Apache вважаються надійність і гнучкість конфігурації. Він дозволяє підключати зовнішні модулі для надання даних, використовувати СУБД для аутентификації користувачів, модифікувати повідомлення про помилки і т. д. Підтримує IPv6.

Ядро Apache включає в себе основні функціональні можливості, такі як обробка конфігураційних файлів, протокол HTTP і система завантаження модулів. Ядро (на відміну від модулів) повністю разрабативаетсяApache Software Foundation, без участі сторонніх програмістів.

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

Ядро Apache повністю написано на мові програмування C.

система конфігурації

Система конфігурації Apache заснована на текстових конфігураційних файлах. Має три умовних рівня конфігурації:

- Конфігурація сервера (httpd.conf).

- Конфігурація віртуального хоста (httpd.conf з версії 2.2 додаткова / HTTPD - vhosts.conf).

- Конфігурація рівня директорії (. Htaccess).

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

Частина модулів використовує у своїй роботі конфігураційні файли операційної системи (наприклад / і т.д. / passwdі / і т.д. / хостів).

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

Мультіпроцессовие модулі (MPM)

Для веб -сервера Apache існує безліч моделей симетричною мультипроцессорности. Ось основні з них:

Таблиця 2.3 – Порівняльна характеристика операційних систем

Назва Розробник ОС, які підтримуються Опис Призначення Статус
worker Apache Soft-ware Foun-dation Linux, FreeBSD Гібридна мультипроцесорного-мультипоточна модель. Зберігаючи стабільність мультипроцесорних рішень, вона дозволяє обслуговувати велику кількість клієнтів з мінімальним використанням ресурсів. Середньо навантажені веб-сервери. Стабіль-ний.
pre-fork Apache Software Foun-dation Linux, FreeBSD MPM, основана на попередньому створенні окремих процесів, що не використовує механізм теми. Велика безпека і стабільність за рахунок ізоляції процесів один від одного, збереження сумісності зі старими бібліотеками, що не підтримують threads. Стабіль-ний
perchild Apache Soft-ware Foun-dation Linux Гібридна модель, з фіксованою кількістю процесів. Високонава-нтажені сервери, можливість запуску дочірніх процесів використову-ючи інше ім'я користувача для підвищення безпеки. В розробці, нестабільний.
netware Apache Soft-ware Foun-dation Novell NetWare Мультипоточна модель, оптимізована для роботи в середовищі NetWare. Сервери Novell NetWare Стабіль-ний
winnt Apache Soft-ware Foun-dation Microsoft Windows Мульти потокова модель, створена для операційної системи Microsoft Windows. Сервери під керуванням Windows Server. Стабіль-ний.
Apache-ITK Steinar H. Gunderson Linux, FreeBSD MPM, заснована на моделі prefork. Дозволяє запуск кожного віртуального хоста під окремими uid і gid. Хостінгові сервери, сервери, критичні до ізоляції користувачів та обліку ресурсів. Стабільний..
peruser Sean Gabriel Heacock Linux, FreeBSD Модель, створена на базі MPM perchild. Дозволяє запуск кожного віртуального хоста під окремими uid і gid. Не використовує потоки. Забезпечення підвищеної безпеки, робота з бібліотеками, що не підтримують threads. Стабільна версія від 4 жовтня 2007 року, експериментальна - від 10 сентября2009 року.

 

Система модулів

Apache HTTP Server підтримує модульність. Існує більше 500 модулів [ 5 ], що виконують різні функції. Частина з них розробляється командою Apache Software Foundation, але основна кількість - окремими відкритим вихідним кодом - розробниками.

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

У модулях реалізуються такі речі, як:

- Підтримка мов програмування.

- Додавання функцій.

- Виправлення помилок або модифікація основних функцій.

- Посилення безпеки.

Частина веб-додатків, наприклад панелі управління ISPmanager і VDSmanager реалізовані у вигляді модуля Apache.

Механізм віртуальних хостів

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

Для кожного віртуального хоста можна вказати власні настройки ядра і модулів, обмежити доступ до всього сайту або окремих файлів. Деякі MPM, наприклад Apache - ITK дозволяють запускати процес HTTPd для кожного віртуального хоста з окремими ідентифікаторами UID і GUID.

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

Інтеграція з іншим ПЗ і мовами програмування

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

До них відносяться:

- PHP (mod_php).

- Python (тієї пітон, мод WSGI).

- Рубін (Apache - рубін).

- Perl (тієї Perl).

- ASP (Apache - ASP).

- Tcl (заклепки)

Крім того, Apache підтримує механізми CGI і FastCGI, що дозволяє виконувати програми на практично всіх мовах програмування, в тому числі C, C + +, Lua, ш, Java.

Безпека

Apache має різні механізми забезпечення безпеки та розмежування доступу до даних. Основними є:

- Обмеження доступу до певних директоріям або файлам.

- Механізм авторизації користувачів для доступу до директорії на основі HTTP - аутентифікації (mod_auth_basic) і переварити - аутентифікації (mod_auth_digest).

- Обмеження доступу до певних директоріям або всьому серверу, засноване на IP -адресах користувачів.

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

- Існують модулі, що реалізують авторизацію через СУБД або PAM.

У деяких MPM - модулях присутня можливість запуску кожного процесу Apache використовуючи різні UID іgid з відповідними цим користувачам і групам користувачів.

Також, існує механізм Suexec, який використовується для запуску скриптів і CGI -додатків з правами і ідентифікаційними даними користувача.

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

Існують зовнішні засоби забезпечення безпеки, наприклад mod_security.

Інтернаціоналізація

Починаючи з версії 2.0 з'явилася можливість визначення сервером локалі користувача. Повідомлення про помилки і події, що посилаються браузеру, тепер представлені на декількох мовах і використовують SSI технологію.

Також, можна реалізувати засобами сервера відображення різних сторінок для користувачів з різними Локаль. Apache підтримує безліч кодувань, у тому числі Unicode, що дозволяє використовувати сторінки, створені в будь-яких кодуваннях і на будь-яких мовах.

Обробка подій

Адміністратор може встановити власні сторінки і обробники для всіх HTTP помилок і подій, таких як 404 (Не знайдено) або 403 (Forbidden). У тому числі існує можливість запуску скриптів і відображення повідомлень на різних мовах.

Протоколи прикладного рівня: HTTP, FTP, POP, IMAP, SMTP Теlnet.

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

Рисунок 2.7 - Інтернет-протоколи

Найвищий рівень в ієрархії протоколів Інтернету займають наступні протоколи прикладного рівня:

- DNS – розподілена система доменних імен, яка за запитом, який задається доменним іменем хоста повідомляє IP адресу;

- HTTP – протокол передачі гіпертексту в Інтернет;

- HTTPS – розширення протоколу HTTP, яке підтримує шифрування;

- FTP (File Transfer Protocol – RFC 959) – протокол, який призначений для передачі файлів в комп’ютерних мережах;

- Telnet (TELecommunication NETwork – RFC 854) – мережевий протокол для реалізації текстового інтерфейсу по мережі;

- SSH (Secure Shell – RFC 4251) – протокол прикладного рівня, який дозволяє проводити віддалене керування операційною системою і передачу файлів. На відміну від Telnet шифрує весь трафік;

- POP3 – протокол поштового клієнта, який використовується поштовим клієнтом для отримання повідомлень електронної пошти з сервера; IMAP – протокол доступу до електронної пошти в Інтернет;

- SMTP – протокол, який використовується для відправлення пошти від користувачів до серверів і між серверами для подальшого пересилання отримувачу;

- LDAP – протокол для доступу до служби каталогів X.500, який є популярним стандартом.

- XMPP (Jabber) – розширювальний протокол, який базується на XML для миттєвого обміну повідомленнями майже в реальному часі;

- SNMP – базовий протокол управління мережі Internet.

Отож, більш детальніше про протоколи.

FTP

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

Telnet

Назву “telnet” мають також деякі утиліти, які реалізують клієнтську частину протоколу. Протокол telnet працює у відповідності з принципами архітектури “клієнт-сервер” і забезпечує емуляцію алфавітно-цифрового терміналу, обмежуючи користувача режимом командної стрічки. Додаток telnet надав моду для «спілкування» терміналів з віддаленими комп’ютерами. Коли появилася мережа ARPANET, для кожної комп’ютерної системи потрібні були власні термінали. Додаток telnet став спільним знаменником для терміналів. Достатньо було написати для кожного комп’ютера програмне забезпечення, яке підтримує “термінал telnet ”, щоби один з терміналів міг взаємодіяти з комп’ютерами всіх типів.

SSH

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






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.