031.3 Урок 1

Перший етап обміну HTTP-даними між клієнтом і сервером ініціюється клієнтом, коли він пише запит серверу. Розглянемо, наприклад, звичайне завдання браузера: завантажити HTML-сторінку з сервера, на якому розміщено вебсайт, наприклад https://learning.lpi.org/en/. Адреса або URL-адреса, містить кілька частин важливої інформації. У цьому конкретному прикладі з’являються три складові:

Після того як HTTP-сервер отримує заголовок повідомлення запиту, сервер повертає клієнту відповідь. Запит HTML-файлу зазвичай має такий заголовок відповіді:

Перший рядок містить версію протоколу HTTP, що використовується в повідомленні відповіді, і вона повинна відповідати версії, яка використовувалась у заголовку запиту. Далі в першому рядку записаний код статусу відповіді, який вказує, як сервер інтерпретував і згенерував відповідь на запит.

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

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

Хоча ці коди вказують на те, що виконати запит було неможливо, коди статусу 4xx і 5xx принаймні вказують на те, що HTTP-сервер запущений і здатний отримувати запити. Коди 4xx вимагають виконання дії на клієнті, оскільки його URL-адреса або облікові дані неправильні. На відміну від цього коди 5xx вказують на те, що на стороні сервера щось не так. Тому в контексті вебзастосунків ці два класи кодів стану вказують на те, що джерело помилки криється в самій програмі, клієнті або сервері, а не в базовій інфраструктурі.

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

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

Наприклад, місце розташування статичних файлів, які можуть надаватися клієнту, визначається різними шляхами в Apache і NGINX. Угодою є те, що ці файли знаходяться в конкретному, призначеному для цього каталозі, який має ім’я, до складу якого входить ім’я хоста, наприклад /var/www/learning.lpi.org/. В Apache цей шлях визначається параметром DocumentRoot /var/www/learning.lpi.org, у розділі налаштувань, який визначає віртуальний хост. У NGINX використовується параметр root /var/www/learning.lpi.org в розділі server файлу налаштувань.

На будь-якому іншому сервері, який ви виберете, файли з /var/www/learning.lpi.org/ будуть обслуговуватися через HTTP майже так само. Деякі поля в заголовку відповіді та їх вміст можуть бути різними для різних серверів, але такі поля, як-от Content-Type, мають бути присутніми в заголовку відповіді та повинні бути незмінними для будь-якого сервера.

HTTP був розроблений для роботи з будь-яким типом інтернет-з’єднання, швидким або повільним. Крім того, більшість HTTP-обмінів змушені проходити багато вузлів мережі через розподілену архітектуру Інтернету. Із цієї причини, важливо прийняти певну стратегію кешування контенту, щоб уникнути зайвої передачі раніше завантаженого вмісту. HTTP-передачі можуть працювати з двома основними типами кешу: shared та private.

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

Приватний кеш (private cache) створюється самим клієнтом для його ексклюзивного використання. Це той тип кешування, який браузер виконує для зображень, CSS-файлів, JavaScript або самого HTML-документа, тому їх не потрібно завантажувати знову, якщо це буде потрібно найближчим часом.

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

Достовірність кешованого ресурсу можна оцінити кількома способами. Сервер може вказати дату закінчення терміну дії в заголовку відповіді для першого запиту, тож клієнт видаляє кешований ресурс після завершення терміну дії і знову запитує його, щоб отримати оновлену версію. Однак сервер не завжди може визначити дату закінчення терміну дії ресурсу, тому зазвичай використовується поле заголовка відповіді ETag для визначення версії ресурсу, наприклад, Etag: "606adcd4-46fa".

Щоб переконатися, що кешований ресурс потребує оновлення, клієнт запитує із сервера лише заголовок відповіді. Якщо поле ETag збігається з таким полем у локально збереженій версії, клієнт повторно використовує кешований контент. В іншому випадку оновлений вміст ресурсу завантажується із сервера.

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

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

Сервер встановлює файл cookie в заголовку відповіді за допомогою поля Set-Cookie. Значення поля – це пара name=value, обрана для представлення атрибута, пов’язаного з конкретним клієнтом. Сервер може, наприклад, створити ідентифікаційний номер для клієнта, який вперше запитує ресурс, і передати його клієнту в заголовку відповіді:

Якщо клієнт дозволяє використовувати файли cookie, нові запити до того самого сервера мають поле cookie в заголовку:

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

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