Клієнт-серверні технології веб

Вступ. Структура веб-технологій

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

Предметом даного курсу є технології глобальної мережі World Wide Web (скорочено WWW або просто Web). Російською мовою поширеним варіантом є назва "Веб".

Зокрема, в рамках курсу будуть розглянуті такі питання як: базові стандарти та протоколи мережі Інтернет, мови розмітки і програмування веб-сторінок, інструменти розробки і управління веб-контенту і додатків для Інтернет, засоби інтеграції веб-контенту і додатків в Веб.

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

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

Споживач-клієнт ініціювавши з'єднання з постачальником-сервером посилає йому запит;

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

При цьому можливі два способи організації роботи комп'ютера-клієнта:

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

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

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

протокол http

HTTP (HyperText Transfer Protocol - RFC 1945 року, RFC 2616) - протокол прикладного рівня для передачі гіпертексту.

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

Сервери - постачальники послуг зберігання та обробки інформації (обробка запитів).

Клієнти - кінцеві споживачі послуг сервера (відправка запитів).

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

"Класична" схема HTTP-сеансу виглядає так.

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

До складу HTTP-запиту, що передається клієнтом серверу, входять наступні компоненти.

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

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

Мал. 1.1. Структура запиту клієнта.

Рядок стану має такий вигляд:

метод_запроса URL_pecypca версія_протокола_НТТР

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

Метод. вказаний в рядку стану, визначає спосіб впливу на ресурс, URL якого заданий в тому ж рядку. Метод може приймати значення GET, POST, HEAD, PUT, DELETE і т.д. Незважаючи на велику кількість методів, для веб-програміста по-справжньому важливі лише два з них: GET і POST.

GET. Згідно формального визначення, метод GET призначається для отримання ресурсу з зазначеним URL. Отримавши запит GET, сервер повинен прочитати зазначений ресурс і включити код ресурсу до складу відповіді клієнту. Ресурс, URL якого передається в складі запиту, не обов'язково повинен являти собою HTML-сторінку, файл із зображенням або інші дані. URL ресурсу може вказувати на виконуваний код програми, який, при дотриманні певних умов, повинен бути запущений на сервері. У цьому випадку клієнтові повертається не код програми, а дані, згенеровані в процесі її виконання. Незважаючи на те що, за визначенням, метод GET призначений для отримання інформації, він може застосовуватися і в інших цілях. Метод GET цілком підходить для передачі невеликих фрагментів даних на сервер.

POST. Згідно з тим же формального визначення, основне призначення методу POST - передача даних на сервер. Однак, подібно до методу GET, метод POST може застосовуватися по-різному і нерідко використовується для отримання інформації з сервера. Як і у випадку з методом GET, URL, заданий в рядку стану, вказує на конкретний ресурс. Метод POST також може використовуватися для запуску процесу.

Методи HEAD і PUT є модифікаціями методів GET і POST.

Версія протоколу HTTP. як правило, задається в наступному форматі:

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

Призначення поля визначається його ім'ям, яке відокремлюється від значення двокрапкою.

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

Таблиця 1.1. Поля заголовка запиту HTTP.

Директиви управління кешуванням. Наприклад, no-cache означає, що дані не повинні кешуватися

Нижче представлений приклад відповіді сервера на запит, наведений в попередньому розділі. У тілі відповіді міститься вихідний текст HTML-документа.

Operand1:

Operand2:

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

Поле з ім'ям Content-type може зустрічатися як в запиті клієнта, так і у відповіді сервера. Як значення цього поля вказується MIME-тип вмісту запиту або відповіді. MIME-тип також передається в поле заголовка Accept, присутнього в запиті.

Специфікація MIME (Multipurpose Internet Mail Extension - багатоцільове поштове розширення Internet) спочатку була розроблена для того, щоб забезпечити передачу різних форматів даних в складі електронних листів. Однак застосування MIME не вичерпується електронною поштою. Засоби MIME успішно використовуються в WWW і, по суті, стали невід'ємною частиною цієї системи.

Стандарт MIME розроблений як розширюється специфікація, в якій мається на увазі, що число типів даних буде рости в міру розвитку форм представлення даних. Кожен новий тип в обов'язковому порядку повинен бути зареєстрований в IANA (Internet Assigned Numbers Authority).

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

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

Оскільки в переважній більшості випадків у відповідь на запит клієнта сервер повертає вихідний текст HTML-документа, то в поле Content-type відповіді зазвичай міститься значення text / html. Тут ідентифікатор text визначає тип, повідомляючи, що клієнту передається символьна інформація, а ідентифікатор html описує підтип, тобто вказує на те, що послідовність символів, що міститься в тілі відповіді, являє собою опис документа на мові HTML.

Перелік типів і підтипів MIME досить великий. У табл. 1.4 наведені приклади MIME-типу, найбільш часто зустрічаються в заголовках HTML-запитів і відповідей.

Таблиця 1.4. MIME типи даних.

Для однозначної ідентифікації ресурсів в мережі Інтернет використовуються унікальні ідентифікатори URL.

Однаковий ідентифікатор ресурсу URI (Uniform Resource Identifier) ​​являє собою коротку послідовність символів, що ідентифікує абстрактний або фізичний ресурс. URI не вказує на те, як отримати ресурс, а тільки ідентифікує його. Це дає можливість описувати за допомогою RDF (Resource Description Framework) ресурси, які не можуть бути отримані через Інтернет (імена, назви і т.п.). Найвідоміші приклади URI - це URL і URN.

URL (Uniform Resource Locator) - це URI, який, крім ідентифікації ресурсу, надає ще й інформацію про місцезнаходження цього ресурсу.

URN (Uniform Resource Name) - це URI, який ідентифікує ресурс в певному просторі назв, але, на відміну від URL, URN не вказує на місцезнаходження цього ресурсу.

URL має наступну структуру:

схема - схема звернення до ресурсу (зазвичай мережевий протокол);

логін - ім'я користувача, що використовується для доступу до ресурсу;

пароль - пароль, асоційований з вказаним ім'ям користувача;

порт - порт хоста для підключення;

URL-шлях - уточнююча інформація про місце знаходження ресурсу.