Як працюють веб-сервери. Веб-сервер (Web Server): для чого він потрібен, як влаштований та як працює Як працює web сервер на комп'ютері

Як правило, у рядового користувача такі поняття, як веб-сервер або хостинг, асоціюються з чимось абсолютно незрозумілим. Тим часом нічого складного в цьому питанні немає. Спробуємо пояснити, що являє собою web server, навіщо він потрібен і як працює, особливо не вдаючись в технічні подробиці, а, так би мовити, на пальцях. Окремо зупинимося на питанні про те, як створити та налаштувати такий сервер на домашньому комп'ютерному терміналі чи ноутбуці.

Що таке веб-сервер?

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

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

Навіщо потрібні web-сервери?

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

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

Як це все працює?

Всі користувачі звикли, що для входу на якийсь ресурс в інтернеті (веб-сторінку), на якому розташовується інформація певного типу, в адресному рядку просто вводиться префікс www (або http) та наступне ім'я. Але ніхто не замислюється над тим, яким чином web server розуміє запит і видає результат.

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

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

Найпопулярніші web-сервери

З усього серверного програмного забезпечення, як вважається, найпоширенішими є Apache та Microsoft IIS. Перший є більш популярним і більшою мірою використовується в UNIX-подібних системах, хоч і може встановлюватися в середу Windows. Крім того, сервер Apache є абсолютно безкоштовним програмним забезпеченням і сумісний практично з усіма відомими операційними системами. Однак, як зазначається, призначене це програмне забезпечення переважно для професійних програмістів і розробників.

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

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

Веб-сервер на домашньому комп'ютері: встановлення

Для інсталяції потрібно завантажити спеціальний серверний пакет, скорочено позначений як WAMP, до якого входять три основні компоненти:

• Apache - програмна оболонка сервера, яка може працювати самостійно, але тільки у разі відсутності на сторінках динамічного контенту, що розміщуються.
• PHP - мова програмування, що використовується надбудовами для керування серверами з динамічним вмістом типу WordPress, Joomla, Drupal.
• MySQL - уніфікована система управління базами даних, що використовується, знову ж таки, при створенні сайтів з динамічним контентом.

Інсталяцію можна зробити з пакета WampServer. Для цього достатньо дотримуватися вказівок «Майстра», який на одній із стадій запропонує вибрати інтернет-браузер, який використовуватиметься за умовчанням.

Для цього потрібно буде перейти в папку з файлом браузера, що виконується (якщо це не Internet Explorer, зазвичай вона розташовується в директорії Program Files). Принагідно сам браузер слід додати до списку винятків брендмауера Windows. На фінішній стадії ставиться галочка навпроти пункту негайного запуску, після чого в системному треї з'явиться відповідний значок, на який потрібно натиснути і вибрати запуск локального хоста (localhost).

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

Приклад налаштування та тестування сервера

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

Вітання!

Можете просто скопіювати текст у «Блокнот» та зберегти файл під ім'ям index.php у тій самій папці WWW (хоча можна обійтися і без того, оскільки цей крок застосовується виключно для перевірки локального хоста). Замість привітання можна вставити будь-який інший текст або фразу.

Потім у браузері потрібно оновити сторінку (F5), після чого на екрані з'явиться вміст. Але для інших комп'ютерів сторінка недоступна.

Щоб відкрити доступ, потрібно змінити файл httpd.conf, прописавши розділ, який починається з наступні рядки:

Order Allow,Deny

Замість післямови

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

Грамотна клієнт-серверна архітектура: як правильно проектувати та розробляти web API

Розповідає Володимир, веб-розробник Noveo

Більшості розробників сайтів, веб-сервісів та мобільних програм рано чи пізно доводиться мати справу з клієнт-серверною архітектурою, а саме розробляти web API або інтегруватися з ним. Щоб не винаходити щоразу щось нове, важливо виробити відносно універсальний підхід до проектування web API, ґрунтуючись на досвіді розробки таких систем. Пропонуємо до вашої уваги об'єднаний цикл статей, присвячених цьому питанню.

Наближення перше: Чинні особи

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

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

Клієнт та сервер

Серверомв даному випадку ми вважаємо абстрактну машину в мережі, здатну отримати HTTP-запит, обробити його та повернути коректну відповідь. У контексті цієї статті зовсім не важливі його фізична суть і внутрішня архітектура, чи то студентський ноутбук, чи величезний кластер із промислових серверів, розкиданих по всьому світу. Нам так само неважливо, що у нього під капотом, хто зустрічає запит біля дверей, Apache або Nginx, який невідомий звір, PHP, Python або Ruby виконує його обробку і формує відповідь, яке сховище даних використовується: Postgresql, MySQL або MongoDB . Головне, щоб сервер відповідав головному правилу – почути, зрозуміти та пробачити відповісти.

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

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

Філософія REST

REST (Representational state transfer) спочатку був задуманий як простий і однозначний інтерфейс для управління даними, що передбачав лише кілька базових операцій з безпосереднім мережевим сховищем (сервером): вилучення даних (GET), збереження (POST), зміна (PUT/PATCH) та видалення (DELETE). Зрозуміло, цей перелік завжди супроводжувався такими опціями, як обробка помилок у запиті (чи коректно складено запит), розмежування доступу до даних (раптом цього знати не слід) і валідація вхідних даних (раптом ви написали нісенітницю), загалом, усіма можливими перевірками , які сервер виконує перед тим, як виконати бажання клієнта.

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

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

Приклад: GET /api/v1/users/25/name

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

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

Чого нам не вистачає

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

Виклики функцій

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

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

Ще варіант- Створення та розрив зв'язків між даними. Наприклад, додавання користувача до групи. Викликаємо по суті групафункцію addUser, як параметр передаємо об'єкт користувач, Отримуємо результат.

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

Множинні операції

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

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

Статистичні запити, агрегатори, форматування даних

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

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

Різновиди даних

Об'єкти

Ключовим типом даних у спілкуванні між клієнтом та сервером виступає об'єкт. По суті, об'єкт – це перелік властивостей та відповідних їм значень. Ми можемо надіслати об'єкт на сервер у запиті та отримати результат запиту у вигляді об'єкта. При цьому об'єкт не обов'язково буде реальною сутністю, що зберігається в базі даних, принаймні у тому вигляді, в якому він відправлений або отриманий. Наприклад, облікові дані для авторизації передаються як об'єкта, але є самостійної сутністю. Навіть об'єкти, що зберігаються в БД, схильні обростати додатковими властивостями внутрішньосистемного характеру, наприклад, датами створення і редагування, різними системними мітками і прапорами. Властивості об'єктів можуть бути як власними скалярними значеннями, так і містити пов'язані об'єктиі колекції об'єктів, які є частиною об'єкта. Частина властивостей об'єктів може бути редагованою, частиною системною, доступною тільки для читання, а частина може мати статистичний характер і обчислюватися на льоту (наприклад, кількість лайків). Деякі властивості об'єкта можуть бути приховані залежно від прав користувача.

Колекції об'єктів

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

Скалярні значення

У чистому вигляді скалярні значення як окрема сутність моєї пам'яті зустрічалися вкрай рідко. Зазвичай вони фігурували як властивості об'єктів або колекцій, і в цій якості можуть бути доступні як для читання, так і для запису. Наприклад, ім'я користувача може бути отримано та змінено в індивідуальному порядку GET /users/1/name . На практиці ця можливість трапляється рідко, але в разі потреби хотілося б, щоб вона була під рукою. Особливо це стосується властивостей колекції, наприклад, числа записів (з фільтрацією або без неї): GET /news/count .

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

Наближення друге: Правильний шлях

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

Про що варто подумати, стоячи на березі

Версійність

Рано чи пізно будь-яка діюча система починає еволюціонувати: розвиватись, ускладнюватись, масштабуватись, усучаснюватись. Для розробників REST API це загрожує в першу чергу тим, що необхідно запускати нові версії API при старих старих. Тут я говорю більше не про архітектурні зміни під капотом вашої системи, а про те, що змінюється формат даних і набір операцій з ними. У будь-якому випадку версійність необхідно передбачити як в початковій організації вихідного коду, так і в принципі створення URL. Що стосується URL, тут існує два найбільш популярні способи вказівки версії API, якій адресовано запит. Префіксація шляху example-api.com/v1/ та розведення версій на рівні субдомену v1.example-api.com. Використовувати можна будь-який із них, залежно від потреби та необхідності.

Автономність компонентів

Web API складних систем, що підтримують кілька ролей користувача, часто вимагає поділу на частини, кожна з яких обслуговує свій спектр завдань. По суті кожна частина може бути самостійним додатком, працювати на різних фізичних машинах і платформах. У контексті опису API нам не важливо, як сервер обробляє запит і які сили та технології в цьому замішані. Для клієнта API – система інкапсульована. Проте різні частини системи можуть мати зовсім різну функціональність, наприклад, адміністративна і користувальницька частина. І методологія роботи з тими самими, начебто, ресурсами може істотно відрізнятися. Тому такі частини необхідно розділяти на рівні домену admin.v1.example-api.com або префіксу шляху example-api.com/v1/admin/. Ця вимога не є обов'язковою, і багато залежить від складності системи та її призначення.

Формат обміну даними

Найзручнішим і функціональнішим, на мою думку, форматом обміну даними є JSON, але ніхто не забороняє використовувати XML, YAML або будь-який інший формат, що дозволяє зберігати серіалізовані об'єкти без втрати типу даних. За бажанням можна зробити API підтримку кількох форматів вводу/вывода. Достатньо використовувати HTTP заголовок запиту для вказівки бажаного формату відповіді Accept і Content-Type для вказівки формату переданих у запиті даних. Іншим популярним способом є додавання розширення до URL ресурсу, наприклад, GET /users.xml , але такий спосіб здається менш гнучким і красивим, хоча б тому, що обважнює URL-адресу і вірний швидше для GET-запитів, ніж для всіх можливих операцій.

Локалізація та багатомовність

На практиці багатомовність API найчастіше зводиться до перекладу сервісних повідомлень та повідомлень про помилки необхідною мовою для прямого відображення кінцевому користувачеві. Багатомовний контент теж має місце бути, але збереження та видача контенту різними мовами, на мій погляд, повинна розмежовуватися більш явно, наприклад, якщо у вас одна і та ж стаття існує різними мовами, то за фактом це дві різні сутності, згруповані за ознакою єдності змісту. Для ідентифікації мови можна використовувати різні способи. Найпростішим можна вважати стандартний HTTP-заголовок Accept-Language. Я зустрічав інші способи, такі як додавання GET-параметра language="en" , використання префіксу шляху example-api.com/en/ або навіть на рівні доменного імені en.example-api.com . Мені здається, що вибір способу вказівки локалі залежить від конкретної програми та завдань, що стоять перед ним.

Внутрішня маршрутизація

Отже, ми дісталися кореневого вузла нашого API (або одного з його компонентів). Всі подальші маршрути будуть проходити вже безпосередньо всередині вашої серверної програми, відповідно до підтримуваного ним набору ресурсів.

Шляхи до колекцій

Для вказівки шляху до колекції ми просто використовуємо назву відповідної сутності, наприклад якщо це список користувачів, то шлях буде таким /users . До колекції застосовні два методи: GET (отримання лімітованого списку сутностей) і POST (створення нового елемента). У запитах отримання списків ми можемо використовувати безліч додаткових GET параметрів, застосовуваних для постраничного виведення, сортування, фільтрації, пошуку etc, але вони мають бути опціональними, тобто. ці параметри не повинні передаватися як частина шляху!

Елементи колекції

Для звернення до конкретного елемента колекції ми використовуємо у маршруті унікальний ідентифікатор /users/25 . Це і є унікальна дорога до нього. Для роботи з об'єктом застосовні методи GET (отримання об'єкта), PUT/PATCH (зміна) та DELETE (видалення).

Унікальні об'єкти

Багато сервісів існують унікальні для поточного користувача об'єкти, наприклад профіль поточного користувача /profile , або персональні налаштування /settings . Зрозуміло, з одного боку, це елементи однієї з колекцій, але вони є відправною точкою використання нашого Web API клієнтським додатком, і до того ж дозволяють набагато ширший спектр операцій над даними. При цьому колекція, що зберігає налаштування користувача може бути взагалі недоступна з міркувань безпеки і конфіденційності даних.

Властивості об'єктів та колекцій

Для того, щоб дістатися до будь-якої з властивостей об'єкта безпосередньо, достатньо додати до шляху до об'єкта ім'я властивості, наприклад, отримати ім'я користувача /users/25/name . До властивості застосовні методи GET (отримання значення) та PUT/PATCH (зміна значення). Метод DELETE не можна застосувати, т.к. властивість є структурною частиною об'єкта як формалізованої одиниці даних.

У попередній частині ми говорили про те, що колекції, як і об'єкти, можуть мати власні властивості. На моїй пам'яті мені знадобилося тільки властивість count, але ваш додаток може бути складнішим і специфічнішим. Шляхи до властивостей колекцій будуються за тим самим принципом, як і до властивостей їх елементів: /users/count . Для властивостей колекцій застосовується лише метод GET (отримання властивості), т.к. колекція – це лише інтерфейс доступу до списку.

Колекції пов'язаних об'єктів

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

Функції об'єктів та колекцій

Для побудови шляху до інтерфейсу виклику функції у колекції чи об'єкта ми використовуємо той самий підхід, що й звернення до властивості. Наприклад, для об'єкта /users/25/sendPasswordReminder або для колекції /users/disableUnconfirmed . Для викликів функцій ми у будь-якому випадку використовуємо метод POST. Чому? Нагадаю, що в класичному REST немає спеціального дієслова для виклику функцій, а тому нам доведеться використовувати один з існуючих. На мій погляд, для цього найбільш підходить метод POST т.к. він дозволяє передавати на сервер необхідні аргументи, не є ідемпотентним (що повертає той самий результат при багаторазовому зверненні) і найбільш абстрактний по семантиці.

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

Наближення третє: Запити та відповіді

У попередніх наближеннях я розповів про те, як прийшла ідея зібрати та узагальнити досвід розробки Web API. У першій частині я постарався описати, з якими видами ресурсів та операцій над ними ми маємо справу з проектуванням web API. У другій частині були порушені питання побудови унікальних URL-адрес для звернення до цих ресурсів. А в цьому наближенні я спробую описати можливі варіанти запитів та відповідей.

Універсальна відповідь

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

Success – маркер успішності виконання запиту

Для того, щоб при отриманні відповіді від сервера відразу зрозуміти, чи увінчався запит успіхом, і передати його відповідному обробнику, достатньо використовувати маркер успішності «success». Найпростіша відповідь сервера, що не містить жодних даних, буде виглядати так:

POST /api/v1/articles/22/publish ( "success": true )

Error - відомості про помилку

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

GET /api/v1/user ( "success": false, "error": ( "code" : 401, "message" : "Authorization failed" ) )

Data - дані, що повертаються сервером

Більшість відповідей сервера мають повертати дані. Залежно від типу запиту та його успіху очікуваний набір даних буде різним, проте атрибут «data» буде у переважній більшості відповідей.

Приклад даних, що повертаються у разі успіху. У разі відповідь містить запитуваний об'єкт user.

GET /api/v1/user ( "success": true, "data": ( "id" : 125, "email" : "john.smit [email protected]", "name" : "John", "surname" : "Smith", ) )

Приклад даних, що повертаються у разі помилки. У цьому випадку містить імена полів та повідомлення про помилки валідації.

PUT /api/v1/user ( "success": false, "error": ( "code" : 422, "message" : "Validation failed" ) "data": ( "email" : " Email could not be blank. ", ))

Pagination - відомості, необхідні організації посторінкової навігації

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

Мінімальний набір значень для пагінації складається з:

• загальної кількості записів;
• числа сторінок;
• номери поточної сторінки;
• числа записів на сторінці;
• максимального числа записів на сторінці, яку підтримує серверна сторона.

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

GET /api/v1/articles Response: ( "success": true, "data": [ ( "id" : 1, "title" : "Interesting thing", ), ( "id" : 2, "title" : "Boring text", ) ], "pagination": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )

Робота над помилками

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

Які ж потенційні причини одержуваних винятків?

500 Internal server error - все зламалося, але ми скоро полагодимо

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

400 Bad request - а тепер у вас все зламалося

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

401 Unauthorized - незнайомець, назви себе

Для доступу до цього ресурсу потрібна авторизація. Зрозуміло, наявність авторизації не гарантує того, що ресурс стане доступним, але не авторизувавшись, ви точно цього не дізнаєтесь. Виникає, наприклад, при спробі звернутися до закритої частини API або після закінчення терміну дії поточного токена.

403 Forbidden – вам сюди не можна

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

404 Not found - за цією адресою ніхто не живе

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

405 Method not allowed - не можна таке робити

Цей різновид виключення безпосередньо пов'язаний із використаним дієсловом (GET, PUT, POST, DELETE), який, у свою чергу, свідчить про дію, яку ми намагаємося зробити з ресурсом. Якщо запитаний ресурс не підтримує цю дію, сервер говорить про це прямо.

422 Unprocessable entity - виправте та надішліть знову

Один із найкорисніших винятків. Повертається щоразу, коли у даних запиту є логічні помилки. Під даними запиту ми маємо на увазі або набір параметрів і відповідних значень, переданих методом GET, або поля об'єкта, що передається в тілі запиту методами POST, PUT і DELETE. Якщо дані не пройшли валідацію, сервер у секції data повертає звіт про те, які саме параметри невалідні і чому.

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

Запити

Отримання елементів колекції

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

Посторінкова навігація

page- параметр вказує на те, яка сторінка має бути відображена. Якщо цей параметр не передано, то з'явиться перша сторінка. З першої ж успішної відповіді сервера буде зрозуміло, скільки сторінок має колекція за поточних параметрів фільтрації. Якщо значення перевищує максимальну кількість сторінок, то найрозумніше повернути помилку 404 Not found.

GET /api/v1/news?page=1

perPage- Вказує на бажану кількість елементів на сторінці. Як правило, API має власне значення за умовчанням, яке повертає як поле perPage у секції pagination, але в ряді випадків дозволяє збільшувати це значення до розумних меж, надавши максимальне значення maxPerPage:

GET /api/v1/news?perPage=100

Сортування результатів

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

sortBy- Існує кілька підходів до передачі даних про складне сортування в GET параметрах. Тут необхідно чітко вказати порядок сортування та напрямок.

У деяких API це пропонується зробити у вигляді рядка:

GET /api/v1/products?sortBy=name.desc,price.asc

В інших варіантах пропонується використовувати масив:

GET /api/v1/products? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

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

Проста фільтрація за значенням

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

GET /api/v1/articles?authorId=25

Ускладнені варіанти фільтрації

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

Фільтрування по верхній і нижній межі з використанням операторів порівняння from (більше або одно), higher (більше), to (менше або одно), lower (менше). Застосовується до полів, значення яких піддаються ранжування.

GET /api/v1/products?price=500&price=1000

Фільтрування за кількома можливими значеннями зі списку. Застосовується до полів, набір можливих значень яких обмежений, наприклад, фільтр за кількома статусами:

GET /api/v1/products?status=1&status=2

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

GET /api/v1/users?name=John GET /api/v1/products?code=123

Іменовані фільтри

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

GET /api/v1/products?filters=recommended

Іменовані фільтри можуть мати свої параметри.

GET /api/v1/products?filters=kidds

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

Навіщо потрібен сервер і коли варто купувати його для свого бізнесу?

Для початку уточнимо, що сервер – це обладнання, яке використовує серверне програмне забезпечення. Він оптимізований до роботи з іншими комп'ютерами (клієнтами). Клієнтами сервера можуть бути комп'ютери, телефони, факси, принтери та інші пристрої, які підключаються до інтернету. Чим більше інформації Ви плануєте зберігати на серверному устаткуванні, тим потужнішим повинен бути сервер. З якою метою орендують сервер? Докладніше у матеріалі на блозі ГіперХост.

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

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

Якщо Ваш бізнес працює на перспективне майбутнє, слід подумати про вибір сервера.

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

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

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

Веб-сервер– сервер підключений до Інтернету та приймає запити користувачів за протоколом HTTP. Усі сайти, які є в мережі, розміщені на веб-серверах. Такий вид сервера – безпосередній провідник між сайтом та клієнтами. Веб-сервер отримує запит, далі обробляє його та видає результат (файловий чи гіпертекстовий). За своєю суттю веб-хостинг та веб-сервер поняття ідентичні. Веб сервер Nginx і apache - що це і як працює ця зв'язка? Відповідь на це питання.

Сервер бази даних.У більшості програм використовують бази даних. Даний вид серверів забезпечує доступ до даних за допомогою системи клієнт-сервер. Найпопулярнішими серверами баз даних є SQL Server (Microsoft), SQL Base Server, Oracle Server (Oracle Corporation), IBM DB2, Informix. Вони працюють на платформі різних операційних систем, таких як MSDOS, OS/2, Xenix, Unix.

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

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

Нині дуже важко уявити роботу підприємства без використання серверів. У цьому трудомісткому процесі беруть участь сервери всіх типів.

Причини, через які можна визначити, чи потрібно для вашої фірми?

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

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

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

Чи потрібно вибрати операційну систему для роботи сервера? Дана допоможе вам зробити правильний вибір та оцінити всі можливості кожної ОС. Про панелі керування для серверів з Linux.

42787 раз(и) 17 Сьогодні переглянуто раз(и)

У цій статті я намагатимусь максимально широко викласти схеми роботи веб-серверів. Це допоможе вибрати сервер або вирішувати, яка архітектура швидше, не ґрунтуючись на часто необ'єктивних бенчмарках.

Загалом - стаття є глобальним оглядом "що буває". Без циферок.

Стаття написана на основі досвіду роботи із серверами:

• Apache, Lighttpd, Nginx (на C)
• Tomcat, Jetty (на Java)
• Twisted (Python)
• Erlang OTP (мова Erlang)
• та операційними системами Linux, FreeBSD

Тим не менш, принципи досить загальні, тому повинні поширюватися в якомусь вигляді на OS Windows, Solaris і на велику кількість інших веб-серверів.

Ціль веб-сервера

Мета веб-сервера проста – обслуговувати одночасно велику кількість клієнтів, максимально ефективно використовуючи hardware. Як це зробити - у цьому основна проблема і предмет статті;)

Робота зі з'єднаннями

З чого починається обробка запиту? Очевидно – з прийому з'єднання від користувача.

Для цього у різних OS використовуються різні системні дзвінки. Найбільш відомий та повільний на великій кількості сполук - select. Більше ефективні - poll, kpoll, epoll.

Сучасні веб-сервери поступово цураються select.

Оптимізації ОС

Ще прийому з'єднання можливі оптимізації лише на рівні ядра ОС. Наприклад, ядро ​​ОС, отримавши з'єднання, може не турбувати веб-сервер, поки не відбулася одна з подій.

• поки не прийшли дані (dataready)
• поки не прийшов повністю HTTP-запит (httpready)

На момент написання статті обидва методи підтримуються в FreeBSD (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA), і лише перший - в Linux (TCP_DEFER_ACCEPT).

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

З'єднання прийнято

Отже, з'єднання прийнято. Тепер на плечі сервера лягає основне завдання – обробити запит та надіслати відповідь відвідувачеві. Будемо тут розглядати лише динамічні запити, значно складніші, ніж віддача картинок.

В усіх серверах використовується асинхронний підхід.

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

Залежно від реалізації - процес-помічник ("worker") може пересилати результат назад серверу цілком (для подальшої віддачі клієнту), може передавати серверу лише дескриптор результату (без копіювання), або може віддавати результат клієнту сам.

Основні стратегії роботи з worker

Робота з воркерами складається з кількох елементів, які можна по-різному комбінувати та отримувати різний результат.

Тип worker"а

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

Процес

Різні worker"и можуть бути процесами. У цьому випадку вони не взаємодіють між собою, і дані різних worker"а повністю незалежні один від одного.

Потік

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

Адресний простір

Кожен процес, у тому числі і сервер, має свій адресний простір, який використовує для поділу даних.

Усередині сервера

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

Плюсом є відсутність пересилання даних з одного адресного простору до іншого.

Зовні сервера

Worker може бути запущений взагалі незалежно від сервера та приймати дані на обробку за спеціальним протоколом (наприклад, FastCGI).

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

Народження worker"ів

Щоб обробляти багато з'єднань одночасно – потрібно мати достатню кількість робітників.

Основних стратегій – дві.

Статика

Кількість робітників може бути жорстко фіксованою. Наприклад, 20 робочих процесів всього. Якщо ж усі робітники зайняті і надходить 21й запит - сервер видає код Temporary Unavailable - "тимчасово недоступний".

Динаміка

Для більш гнучкого управління ресурсами – робітники можуть породжуватися динамічно, залежно від завантаження. Алгоритм народження робочих може бути параметризований, наприклад (Apache pre-fork), так:

• Мінімальна кількість вільних робітників = 5
• Максимальна кількість вільних робітників = 20
• Усього робітників не більше = 30
• Початкова кількість робочих = 10

Чищення між запитами

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

Чистий

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

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

Персистентний

Жодного очищення стану. В результаті – економія ресурсів.

Розбір типових конфігурацій

Apache (pre-fork MPM) + mod_php

• Процес
• Усередині сервера
• Динаміка
• Чистий

Apache (worker MPM) + mod_php

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

При цьому, оскільки php працює в адресному просторі сервера, дані потоками дані періодично псуються, тому зв'язка нестабільна і не рекомендована. Це відбувається через помилки в mod_php, який включає в себе ядро ​​PHP і різні php-модулі.

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

• Потік
• Усередині сервера
• Динаміка
• Чистий

Apache (event mpm) + mod_php

Event MPM - це стратегія роботи з worker"ами, яку використовує тільки Apache. Все - так само, як зі звичайними потоками, але з невеликим доповненням для обробки Keep-Alive

Установка Keep-Alive слугує для того, щоб клієнт міг надіслати багато запитів в одному з'єднанні. Наприклад, отримати веб-сторінку та 20 картинок. Зазвичай, worker закінчує обробку запиту - і чекає якийсь час (keep-alive time), чи не підуть у цьому з'єднанні додаткові запити. Тобто просто висить у пам'яті.

Event MPM створює додатковий потік, який бере на себе очікування на всі Keep-Alive запити, звільняючи робітника для інших корисних справ. В результаті, загальна кількість worker'ів значно скорочується, тому що ніхто тепер не чекає на клієнтів, а всі працюють.

• Потік
• Усередині сервера
• Динаміка
• Чистий

Apache + mod_perl

Особливість зв'язки Apache з mod_perl - у можливості викликати Perl-процедури в процесі обробки запиту апачем.

Завдяки тому, що mod_perl працює в одному адресному просторі з сервером, він може реєструвати свої процедури через Apache hooks, на різних стадіях роботи сервера.

Наприклад, можна працювати на тій же стадії, що й mod_rewrite, переписуючи урл у хуку PerlTransHandler.

Наступний приклад описує rewrite з /example на /passed, але на перлі.

# у конфізі апача при включеному mod_perl PerlModule MyPackage::Example PerlTransHandler MyPackage::Example # у файлі MyPackage/Example.pm use strict; sub handler ( my $r = shift; $r->uri("/passed") if $r->uri == "/example" return DECLINED; ) 1;

На жаль, mod_perl - дуже важкий сам собою, тому використання його лише реврайтів - дуже накладно.

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

• Процес/потік - залежить від MPM
• Усередині сервера
• Динаміка
• Персистентний

Twisted

Тут програміст, отримавши запит, використовує виклик deferToThread створення окремого потоку, якому доручено виконати функцію do_something_big. При успішному закінченні do_something_big, буде виконано функцію handleOK, при помилці - handleError.

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

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

• Потік
• Усередині сервера
• Динаміка
• Персистентний

Tomcat, Servlets

Сервлети – класичний приклад потокових веб-додатків. Єдиний Java-код програми запускається у безлічі потоків. Синхронізація є обов'язковою і повинна виконуватися програмістом.

• Потік
• Усередині сервера
• Динаміка
• Персистентний

FastCGI

FastCGI - інтерфейс спілкування web-сервера із зовнішніми worker"ами, які зазвичай запущені як процеси. Сервер у спеціальному (не HTTP) форматі передає змінні оточення, заголовки та тіло запиту, а worker - повертає відповідь.

Є два способи породження таких робітників.

1. Інтегрований із сервером
2. Окремий від сервера

У першому випадку сервер сам створює зовнішні робочі процеси та керує їх числом.

У другий випадок - для породження робочих процесів використовується окремий " spawner " , другий, додатковий сервер, який вміє спілкуватися лише з FastCGI-протоколу і керувати робочими. Зазвичай spawner породжує робочих як процесів, а чи не потоків. Динаміка/Статика - визначається налаштуваннями spawnerа, а Чистий/Персистентний - характеристиками робочого процесу.

Шляхи роботи з FastCGI

З FastCGI можна працювати двома шляхами. Перший спосіб – найпростіший, його використовує Apache.

отримати запит -> віддати на обробку в FastCGI -> зачекати на відповідь-> Віддати відповідь клієнту.

Другий спосіб використовують сервери типу lighttpd/nginx/litespeed/і т.п.

отримати запит -> віддати на обробку в FastCGI -> обробити інших клієнтів-> Віддати відповідь клієнту, коли прийде.

Зазначена відмінність дозволяє Lighttpd + fastcgi працювати ефективніше, ніж це робить Apache, тому що поки процес Apache чекає - Lighttpd встигає обслужити інші з'єднання.

Режими роботи FastCGI

• Responder - звичайний режим, коли FastCGI приймає запит та змінні, і повертає відповідь
• Authorizer - режим, коли FastCGI як відповідь дозволяє або забороняє доступ. Зручно для контролю за закритими статичними файлами

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

FastCGI PHP vs PERL

PHP-інтерпретатор щоразу очищає себе перед обробкою скрипта, а Perl - просто обробляє запити один за одним у циклі виду:

Підключити модулі; while (прийшов запит) (обробити його; print answer; ) Тому Perl-FastCGI набагато ефективніше там, де більшу частину часу виконання займають include допоміжних модулів.

Резюме

У статті розглянуто загальну структуру обробки запитів та види worker"ів. Крім того, заглянули в Apache Event MPM та способи роботи з FastCGI, переглянули сервлети та Twisted.

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

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

Складові клієнт-серверної схеми

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

Для чого потрібний сервер

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

Плюси та мінуси моделі

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

Безпека

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