4.6 Сервери
-
Підходи до побудови серверів прикладного програмного забезпечення
Сервер – це процес, який реалізує деяку службу, потрібну групі клієнтів. Усі сервери працюють за схожими алгоритмами: вони очікують на появу вхі- дного повідомлення, яке надсилає клієнт, перевіряють його на правильність, після чого чекають появи наступного повідомлення.
Сервери можуть бути організовані різними способами. Якщо сервер ітеративний, то він сам обробляє запит й у разі потреби повертає клієнтові у відповідь повідомлення, тоді як паралельний сервер не обробляє повідомлення сам, а передає його в окремий потік виконання або інший процес, після чого відразу переходить у стан очікування наступного вхідного повідомлення.
Приклад. Розглянемо багатопотоковий сервер. У реалізації такого па- ралельного сервера на кожен запит, що надійшов, може створюватися но- вий процес. Такий підхід застосовується в багатьох UNIX-системах. Потік або процес, який обробляє запит, відповідає за відправлення відповіді клієн- тові, що надіслав запит.
Клієнт завжди надсилає запити в кінцеву точку (endpoint), яку називають портом (port), тієї машини, на якій працює сервер. Кожен сервер переглядає вказану йому кінцеву точку. Одне з рішень проблеми щодо визначення кін- цевих точок клієнтом, яку складно розв’язати у загальному випадку, є глоба- льне призначення кінцевих точок найбільш поширеним службам.
Приклад. Сервери, які обслуговують запити до FTP в Internet, завжди пра- цюють з пор- том 21, HTTP-серверам World Wide Web завжди призначають TCP-порт 80.
Ці кінцеві точки визначені організацією реєстрації номерів Internet (Internet Assigned Numbers Authority – IANA). Маючи визначені кінцеві точки, клієн- тові достатньо знати мережну адресу тієї машини, на якій запущена служба. Для цього використовують служби іменування.
Багато служб не потребують попереднього призначення кінцевої точки.
Приклад. Служба часу може використовувати кінцеву точку, що в ди- наміці виглядає для неї як локальна операційна система. У такому разі клієнт має спочатку визначити кінцеву точку.
Для визначення кінцевої точки клієнтом у процесі виконання розподіле- ної прикладної програми розроблено рішення, яке реалізовано у розподіленому середовищі Distributed Computing Environment (DCE), яким є створення спе- ціального демона, що запускається на кожній машині, на якій працюють сервери. Демон відстежує поточну кінцеву точку кожного сервера, що реалі- зується на ньому, переглядає загальнодоступні кінцеві точки. Під час першого контакту з демоном клієнт запитує кінцеву точку, після чого зв’язується з потрібним сервером. Зазвичай кінцева точка асоціюється з конкретною служ- бою, проте на практиці реалізація кожної служби окремим сервером є недо- цільним витрачанням ресурсів.
Приклад. У типових UNIX-системах зазвичай працює одночасно багато серверів, при цьому велика їх частина пасивно чекає запитів від клієнта. Замість ведення такої кількості пасивних процесів часто ефективніше мати один суперсервер (superserver), який прослуховує всі кінцеві точки, що сто- суються конкретних служб, як показано на рис. 4.11. Такий підхід реалізує, наприклад, демон inetd у UNIX, який переглядає стандартні порти служб Internet і, якщо надійшов запит, то розпаралелює процес і передає запит для подальшої обробки, після закінчення якої дочірній процес завершується.
Приклад. Нехай користувач вирішив завантажити на FTP-сервер ве- ликий файл. Почавши робити це, він зрозумів, що обрав не той файл, і хотів би відмінити подальшу пересилку даних. Використовують декілька способів це зробити. Один з підходів, що надійно працює в сучасному Internet (інколи це єдиний можливий підхід), – користувач негайно закриває клієнтське про-
грамне забезпечення, що автоматично викликає процес розриву з’єднання із сервером, потім перезапускає його і продовжує роботу. Сервер розриває ста- ре з’єднання, вважаючи, що клієнт припинив роботу.
Продовження
роботи
Реальний сервер
Клієнт
Суперсервер
Визначення кінцевої точки
Реєстрація кінцевої точки
Таблиця кінцевих точок
Запит служби
Створення сервера для служби
Рис. 4.11. Прив’язка клієнта до сервера з використанням демона в середовищі ОС і суперсервера в UNIX
Найбільш коректний спосіб викликати переривання зв’язку – розробляти програмне забезпечення клієнта і сервера так, щоб вони могли пересилати один одному інформацію (out-ofband) стосовно сервера, який має обробляти раніше за рештуданих, які передаються клієнтом. Один з підходів до застосування сиг- налу кінця зв’язку – змусити сервер переглядати окрему кінцеву точку, на яку клієнт його відправлятиме й одночасно (з нижчим пріоритетом) переглядати кінцеву точку, через яку передаються нормальні дані. Інший підхід – пересилати сигнал кінця зв’язку тим самим з’єднанням, через яке клієнт пересилав свій запит. У протоколі TCP, наприклад, можна надсилати термінові дані. Коли термінові дані досягають сервера, він перериває свою роботу (в UNIX-системах – за сигналом), після чого може проглянути ці дані й обробити їх.
Важливою характеристикою сервера є можливість збереження інформа- ції про стан клієнтів на сервері. Сервер без фіксації стану (stateless sewer) не зберігає інформацію про стан своїх клієнтів і може змінювати власний стан, не інформуючи про це клієнтів.
Приклад. Web-сервер – це сервер без фіксації стану, який відповідає на вхідні HTTP-запити, які можуть вимагати завантаження файлу як на сервер, так і (набагато частіше) з сервера. Після виконання запиту Web-сервер забу-
ває про клієнта. Набір файлів, якими керує Web-сервер (можливо, в комбі- нації з файловим сервером), може бути змінений без повідомлення клієнтів про цю дію.
На відміну від сервера без фіксації стану, сервер із фіксацією стану
(stateful server) зберігає та обробляє інформацію про своїх клієнтів.
Приклад. Розглянемо файловий сервер, що дозволяє клієнтові створю- вати локальні копії файлів, скажімо, для підвищення продуктивності опера- цій оновлення. Такий сервер підтримує таблицю, яка містить записи пар (клі- єнт, файл) та дозволяє відстежувати, який клієнт з яким файлом працює, завдяки чому сервер завжди визначає «найсвіжішу» версію файлу. Цей підхід підвищує продуктивність операцій «читання–запису», які здійснюються на клієнтській стороні.
Підвищення продуктивності порівняно із серверами без фіксації стану найчастіше є основними перевагою і причиною розробки серверів із фікса- цією стану. Розглянутий приклад ілюструє й основний недолік таких сер- верів. У разі збою сервера він вимушений відновлювати свою таблицю із записами пар (клієнт, файл), інакше не буде жодної гарантії в тому, що робо- та виконується з останньою оновленою версією файлу. Зазвичай сервери з фіксацією стану потребують відновлення свого стану в тому вигляді, в якому вони були до збою, що дуже ускладнює програмне забезпечення. У разі архі- тектури без фіксації стану взагалі немає потреби вживати якихось спеціаль- них заходів для відновлення серверів після збою. Вони просто перезапуска- ються і працюють, чекаючи запитів клієнта.
У процесі розробки сервера вибір між архітектурою з фіксацією і без фіксації стану не відображається на службі, яку цей сервер має надавати. Так, оскільки до виконання операцій читання або запису файли потрібно від- кривати, сервер без фіксації стану має виконати відкриття файлу. Стандарт- ний підхід полягає в тому, щоб сервер, обробляючи запит на запис у файл або читання з файлу, відкривав потрібний файл, виконував операцію читання чи запису і негайно його закривав.
В інших випадках сервер може зберігати записи про поведінку клієнтів, щоб ефективніше обробляти їх запити, але лише за умови, що сервер зберіга-
тиме інформацію про клієнта. Традиційне рішення полягає в тому, щоб дозво- лити клієнтові надсилати додаткову інформацію про його попередні сеанси роботи із сервером, яку часто прозоро зберігає браузер клієнта у вигляді файлів cookie – маленьких фрагментів даних, що містять інформацію про клієнта, важливу для сервера. Файли cookie ніколи не виконуються браузером, а про- сто зберігаються.
Під час першого звертання клієнта до сервера останній пересилає файл cookie разом із запитаними Web-сторінками браузеру, а браузер зберігає цей файл cookie. Кожного разу під час звертання клієнта до сервера файли cookie пересилаються браузером на сервер разом із текстом запиту. Теоретично цей підхід працює добре, на практиці ж файли cookie для безпечного зберігання відсилаються браузером назад на сервер так, щоб цей процес був скритим від користувача.