HyperText Transfer Protocol (HTTP)- Це протокол високого рівня(а саме рівня додатків), що забезпечує необхідну швидкість передачі даних, потрібну для розподілених інформаційних систем гіпермедіа. HTTP використовується проектом World Wide Web з 1990 року.

Практичні інформаційні системивимагають більшого, ніж примітивний пошук, модифікація та інструкція даних. HTTP/1.0 надає відкриту множину методів, які можуть бути використані для вказівки цілей запиту. Вони побудовані на дисципліні посилань, де для вказівки ресурсу, до якого має бути застосований даний метод, використовується Універсальний Ідентифікатор Ресурсів (Universal Resource Identifier — URI), як місцезнаходження (URL) або ім'я (URN). Формат повідомлень подібний до формату Internet Mail або Multipurpose Internet Mail Extensions (MIME-Многоцільове Розширення Пошти Internet).

HTTP/1.0 використовується також для комунікацій між різними користувальницькими переглядачами та шлюзами, що дають гіпермедіа доступ до існуючих Internet протоколам, такі як SMTP, NNTP, FTP, Gopher і WAIS. HTTP/1.0 розроблений, щоб дозволяти таким шлюзам через proxy сервери, без будь-якої втрати передавати дані за допомогою згаданих протоколів попередніх версій.

Загальна структура

HTTP ґрунтується на парадигмі запитів/відповідей. Програма, що запитує (зазвичай вона називається клієнт) встановлює зв'язок з обслуговуючою програмою-отримувачем (зазвичай називається сервер) і посилає запит серверу в наступній формі: метод запиту, URI, версія протоколу, за якою слідує MIME-подібне повідомлення, що містить керуючу інформацію запиту, інформацію про клієнта і, можливо, тіло повідомлення. Сервер відповідає повідомленням, що містить рядок статусу (включаючи версію протоколу і код статусу - успіх або помилка), за якою слідує MIME-подібне повідомлення, що включає інформацію про сервер, метаінформацію про зміст відповіді, і, ймовірно, саме тіло відповіді. Слід зазначити, що одна програма може бути одночасно клієнтом і сервером. Використання цих термінів у даному текстівідноситься тільки до ролі, що виконується програмою протягом даного конкретного сеансу зв'язку, а не до загальних функцій програми.

У Internet комунікації зазвичай ґрунтуються на TCP/IP протоколах. Для WWW номер порту за замовчуванням – TCP 80, але також можуть бути використані й інші номери портів – це не виключає можливості використовувати HTTP як протокол верхнього рівня.

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

Загальні поняття

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

Запит = Простий-Запит | Повний-Запит Простий-Запит = "GET" SP Запитуваний-URI CRLF Повний-Запит = Рядок-Статус *(Загальний-Заголовок | Заголовок-Запиту | Заголовок-Змісту) CRLF [ Зміст-Запиту ]

Якщо HTTP/1.0 сервер отримує Простий-Запит, він повинен відповідати простим-відповіддю HTTP/0.9. HTTP/1.0 клієнт, здатний обробляти Повний Відповідь, ніколи не повинен посилати Простий Запит.

Рядок Статус

Рядок Статус починається з рядка з назвою методу, за яким слідує URI-Запиту і версія протоколу, що використовується. Рядок Статус закінчується символами CRLF. Елементи рядка поділяються пробілами (SP). У Рядку Статус не допускаються символи LF і CR, за винятком послідовності CRLF.

Рядок-Статус = Метод SP URI-Запиту SP Версія-HTTP CRLF

Слід зазначити, що відмінність Рядки Статус Повного-Запиту від Рядки Статус Простого- Запитуполягає у присутності поля Версія-HTTP.

Метод

У полі Метод вказується метод, який має бути застосований до ресурсу, що ідентифікує URI-Запиту. Назви методів чутливі до регістру. Існуючий перелік методів може бути розширений.

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" | додатковий метод

Список методів, що допускаються окремим ресурсом, може бути зазначений у полі Заголовок-Зміст «Баллів». Тим не менш, клієнт завжди повідомляє сервер через код статусу відповіді, чи допускається застосування даного методудля зазначеного ресурсу, оскільки допустимість застосування різних методівможе динамічно змінюватись. Якщо цей метод відомий серверу, але не допускається для зазначеного ресурсу, сервер повинен повернути код статусу "405 Method Not Allowed" і код статусу "501 Not Implemented", якщо метод не відомий або не підтримується даним сервером. Загальні методи HTTP/1.0 описуються нижче.

GET

Метод GET служить для отримання будь-якої інформації, що ідентифікована URI-Запиту. Якщо URI- Запиту посилається на процес, що видає дані, як відповідь виступатимуть дані, згенеровані цим процесом, а не код самого процесу (якщо тільки це не є вихідними даними процесу).

Метод GET змінюється на «умовний GET», якщо повідомлення запиту включає поле заголовка «If-Modified-Since». У відповідь на умовний GET, тіло запитуваного ресурсу передається тільки, якщо він змінювався після дати, вказаної в заголовку If-Modified-Since. Алгоритм визначення цього включає такі випадки:

• Якщо код статусу відповіді на запит буде відрізнятися від "200 OK", або дата, вказана в полі заголовка "If-Modified-Since" некоректна, відповідь буде ідентична відповіді на звичайний запит GET.
• Якщо після вказаної дати ресурс змінювався, відповідь також ідентична відповіді на звичайний запит GET.
• Якщо ресурс не змінювався після вказаної дати, сервер поверне код статусу "304 Not Modified".

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

HEAD

Метод HEAD аналогічний методу GET, за винятком того, що у відповіді сервер не повертає тіло-відповіді. Метаінформація, що міститься в заголовках HTTP відповіді на запит HEAD, повинна бути ідентична інформації HTTPзаголовків відповіді запит GET. Даний метод може використовуватися для отримання метаінформації про ресурс без передачі по мережі самого ресурсу. Метод «Умовний HEAD», аналогічний умовному GET, не визначено.

POST

Метод POST використовується для запиту сервера, щоб той прийняв інформацію, включену до запиту, як субординантну для ресурсу, зазначеного у Рядку Статус у полі URI-Запиту. Метод POST був розроблений, щоб була можливість використовувати один загальний методдля наступних функцій:

• Анотація існуючих ресурсів
• Додавання повідомлень до груп новин, поштових списків або подібних груп статей
• Доставка блоків даних процесам, які обробляють дані
• Розширення баз даних через операцію додавання

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

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

Якщо в результаті обробки запиту POSTбув створений новий ресурс, відповідь повинна мати код статусу, що дорівнює «201 Created», і містити URI нового ресурсу.

PUT

Метод PUT запитує сервер про збереження Тіло-Запиту під URI, що дорівнює URI-Запиту. Якщо URI-Запит посилається на вже існуючий ресурс, Тіло-Запит має розглядатися як модифікована версіяданого ресурсу. Якщо ресурс, на який посилається URI-Запиту не існує, і даний URI може розглядатися як опис нового ресурсу, сервер може створити ресурс з даним URI. Якщо було створено новий ресурс, сервер повинен інформувати клієнта, що направив запит, через відповідь з кодом статусу «201 Created». Якщо існуючий ресурс був модифікований, має бути надіслана відповідь «200 OK», для інформування клієнта про успішне завершення операції. Якщо ресурс із зазначеним URI не може бути створений або модифікований, має бути надіслано відповідне повідомлення про помилку.

Фундаментальна різниця між методами POST та PUT полягає у різному значенні поля URI-Запиту. Для способу POST даний URI показує ресурс, який керуватиме інформацією, що міститься в тілі запиту, як деяким придатком. Ресурс може бути обробним дані процесом, шлюзом в якийсь інший протокол, або окремим ресурсом, що допускає інструкції. На противагу цьому, URI для запиту PUT ідентифікує інформацію, що міститься в Зміст-Запит. PUT, що використовує запит, точно знає який URI він збирається використовувати, і одержувач запиту не повинен намагатися застосувати цей запит до якогось іншого ресурсу.

DELETE

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

LINK

Метод LINK встановлює взаємозв'язки між існуючим ресурсом, зазначеним у URI-Запиті, та іншими існуючими ресурсами. Відмінність методу LINK від інших методів, що допускають встановлення посилань між документами, полягає в тому, що метод LINK не дозволяє передавати в запиті Тіло-Запиту, і в тому, що в результаті цього методу не створюються нові ресурси.

UNLINK

Метод UNLINK видаляє один або більше посилань для ресурсу, зазначеного в URI- Запиту. Ці взаємозв'язки можуть бути встановлені за допомогою методу LINK або іншого методу, що підтримує заголовок «Link». Видалення посилання на ресурс не означає, що ресурс припиняє існування або стає недоступним для майбутніх посилань.

Поля Заголовок-Запиту

Поля Заголовок-Запиту дозволяють клієнту передавати серверу додаткову інформаціюпро запит та про самого клієнта.

Заголовок-Запиту = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | від | If-Modified-Since | Pragma | Referer | User-Agent | extension-header

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

Нижче буде розглянуто деякі поля заголовка запиту.

від

У разі присутності поля From воно має містити повний E-mailадресу користувача, який керує програмою-агентом, яка здійснює запити. Ця адреса повинна бути задана у форматі, визначеному RFC 822. Формат даного поля наступний: From = «From» «:» специфікація адреси. Наприклад:

Від: [email protected]

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

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

If-Modified-Since

Поле заголовка If-Modified-Since використовується з методом GET для того, щоб зробити його умовним: якщо запитуваний ресурс не змінювався у часі, вказаному в цьому полі, копію цього ресурсу не буде повернуто сервером; натомість, буде повернено відповідь «304 Not Modified» без Тіла-Відповіді.

If-Modified-Since = "If-Modified-Since" ":" HTTP-дата

Приклад використання заголовка:

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

User-Agent

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

User-Agent = "User-Agent" ":" 1*(продукт) продукт = рядок ["/" версія-продукту] версія-продукту = рядок

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

Структура відповіді

Після отримання та інтерпретації запиту, сервер надсилає відповідь відповідно до наступної форми:

Відповідь = Простий-Відповідь | Повний-Відповідь Простий-Відповідь = [ Зміст-Відповіді ] Повний-Відповідь = Рядок-Статус *(Загальний-Заголовок | Заголовок-Відповіді | Заголовок-Змісту) CRLF [ Зміст-Відповіді ]

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

Рядок Статус

Перший рядок Повного-Запиту є Рядком-Статус, що складається з версії протоколу, за якою слідує цифровий кодстатусу та асоційована з ним текстова пропозиція. Всі елементи Рядки-Статус розділені пробілами. Не дозволені символи CR та LF, за винятком завершальної послідовності CRLF.

Рядок-Статус=Версія-HTTP SP Статус-Код SP Фраза-Пояснення.

Оскільки Рядок-Статус завжди починається з версії протоколу «HTTP/» 1*ЦИФРА «.» 1*ЦИФРА (наприклад HTTP/1.0), існування цього виразу розглядається як основне визначення того, чи є відповідь Простим-Ответом, чи Повним-Ответом. Хоча формат Простого-Відповіді не виключає появи такого рядка (що призвело б до неправильної інтерпретації повідомлення відповіді та прийняття його за Повну-Відповідь), ймовірність такої появи близька до нуля.

Статус-код та пояснення до нього

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

Перша цифра Статус-Коду призначена визначення класу відповіді. Останні дві цифри не виконують жодної ролі, що категоризує. Існує 5 значень для першої цифри:

1. 1xx: Інформаційний — Не використовується, але зарезервований для використання у майбутньому
2. 2x: Успіх - Запит був повністю отриманий, зрозумілий, і прийнятий до обробки.
3. 3xx: Перенаправлення — Клієнту слід зробити подальші діїдля успішного виконання запиту. Необхідна додаткова дія може бути виконана клієнтом без взаємодії з користувачем, але настійно рекомендується, щоб це мало місце лише в тих випадках, коли метод, що використовується в запиті байдужий (GET або HEAD).
4. 4xx: Помилка клієнта — Запит, який містить неправильні синтаксичні конструкції, не може бути успішно виконаний. Клас 4xx призначений для опису тих випадків, коли помилку було допущено з боку клієнта. Якщо клієнт ще не завершив запит, коли він отримав відповідь із Статус-кодом-4xx, він повинен негайно припинити передачу даних серверу. Цей типСтатус-кодів застосовується для будь-яких методів, що вживаються у запиті.
5. 5xx: Помилка Сервера — Сервер не зміг відповідати на коректно поставлений запит. У цих випадках
   сервер або знає, що він припустився помилки, або не здатний обробити запит. За винятком відповідей на запити HEAD, сервер посилає опис помилкової ситуації і те, чи є цей стан тимчасовим або постійним, у Зміст-Відповіді. Даний тип Статус-кодів застосовується для будь-яких методів, що вживаються у запиті.

Окремі значення Статус-Кодів та відповідні їм Фрази-Пояснення наведено нижче. Дані Фрази-Пояснення тільки рекомендуються — вони можуть бути заміщені будь-якими іншими фразами, що зберігають сенс і протоколом, що допускаються.

Статус-Код = "200"; Добре | "201"; Created | "202"; Прийнято | "203"; Provisional Information | "204"; No Content | "300"; Multiple Choices | "301"; Moved Permanently | "302"; Moved Temporarily | "303"; Метод | "304"; Not Modified | "400"; Bad Request | "401"; Unauthorized | "402"; Payment Required | "403"; Forbidden | "404"; Not Found| "405"; Method Not Allowed | "406"; None Acceptable | "407"; Proxy Authentication Required | "408"; Request Timeout | "409"; Конфлікт | "410"; Gone | "500"; Internal Server Error| "501"; Not Implemented | "502"; Bad Gateway | "503"; Service Unavailable | "504"; Gateway Timeout | Код-Розширення Код-Розширення = 3ЦИФРА Фраза-Пояснення = рядок *(SP рядок)

Від HTTP додатківне потрібне розуміння всіх Статус-Кодів, хоча таке розуміння, очевидно, бажане. Тим не менш, від додатків потрібна здатність розпізнавання класів Статус-кодів (ідентифікуються першою цифрою) і відношення до всіх статусів-кодів статусу відповіді, ніби вони були еквівалентні Статус-коду x00.

Поля Заголовок-Відповіді

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

Заголовок-Відповіді = Public | Retry-After | Server | WWW-Authenticate | extension-header

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

Загальні поняття

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

Поля Заголовок-Змісту

Поля Заголовок-Змісту містять необов'язкову метаінформацію про Зміст-Запит або Зміст-Відповідь відповідно. Якщо тіло відповідного повідомлення (запиту чи відповіді) немає, то Заголовок-Змісту містить інформацію про запитуваному ресурсі.

Деякі з полів заголовка змісту описані нижче.

Allow

Поле заголовка Allow є переліком методів, які підтримує ресурс, ідентифікований URI-Запиту. Призначення цього поля - точне інформування одержувача про допустимі методи, асоційовані з ресурсом; це поле має бути у відповіді зі статусом кодом «405 Method Not Allowed».

Allow = "Allow" ":" 1#метод

Приклад використання:

Allow: GET, HEAD, PUT

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

Content-Length

Поле Content-Length вказує розмір тіла повідомлення, надісланого сервером у відповідь на запит або, у разі запиту HEAD, розмір тіла повідомлення, яке було надіслано у відповідь на запит GET.

Content-Length = "Content-Length" ":" 1*ЦИФРА

Наприклад:

Content-Length: 3495

Хоча це не обов'язково, але все ж додаткам настійно рекомендується використовувати це поле для аналізу розмірів повідомлення, що передається, незалежно від типу інформації, що міститься в ньому. Для поля Content-Length допустимим є будь-яке ціле значення більше нуля.

Content-Type

Поле заголовка Content-Type ідентифікує тип інформації в тілі повідомлення, яка надсилається стороні, що отримує, або, у разі методу HEAD, тип інформації (середовища), який був би посланий, якщо використовувався метод GET.

Content-Type = "Content-Type" ":" тип-середовища

Типи середовищ визначено окремо.
Приклад:

Content-Type: text/html; charset=ISO-8859-4

Поле Content-Type не має значення за промовчанням.

Last-Modified

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

Last-Modified = "Last-Modified" ":" HTTP-дата

Приклад використання:

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

Тіло повідомлення

Під тілом повідомлення розуміється Зміст-Запиту або Зміст-Відповіді відповідно. Тіло повідомлення, якщо воно є, надсилається в HTTP/1.0 запиті або відповіді у форматі та кодуванні, що визначаються полями Заголовок-Змісту.

Тіло-Повідомлення = *OCTET (де OCTET це будь-який 8-бітний символ)

Тіло повідомлення включається у запит, лише якщо метод запиту має на увазі його наявність. Для специфікації HTTP/1.0 такими методами є POST та PUT. Загалом, на присутність тіла повідомлення вказує присутність таких полів заголовка змісту, як Content-Length та/або Content-Transfer-Encoding, у запиті, що передається.

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

6.1 Служба WWW

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

Проект було запропоновано у 1989 році. У 1993 році з'явився перший браузер.

WWW побудовано за схемою "клієнт-сервер".

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

Сервер HTTP(Apeche, IIS…) обробляє запити клієнта на отримання файлу (у найпростішому випадку).

Взаємодія клієнта та сервера за протоколом HTTP.

На початку служба WWW базувалася на трьох стандартах:

HTML (HyperText Markup Lan-guage) - мова гіпертекстової розміткидокументів;

URL (Universal Resource Locator) - універсальний спосібадресації ресурсів у мережі;

HTTP (HyperText Transfer Protocol) - протокол обміну гіпертекстової інформацією.

CGI ( Common Gateway Interface) – універсальний інтерфейс шлюзів. Створений для взаємодії HTTP-сервера з іншими програмами, встановленими на сервері (наприклад, СУБД).

6.2 Протокол HTTP

Перший документ (але не стандарт) - RFC1945 (Hypertext Transfer Protocol - HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996)

Деякі можливості програми:

завдання глибини сканування сайту, та зовнішніх посилань

завдання типу файлів (розширення) для скачування, наприклад, можна завантажити тільки графіку.

виставити ліміт за розміром файла.

сканування графічних карток.

завдання розкладу роботи, вбудований Scheduler.

завдання назви клієнта, якщо є обмеження для деяких клієнтів.

завдання кількості файлів, що одночасно скачуються.

HTTP(HyperText Transfer Protocol – «протокол передачі гіпертексту») – протокол прикладного рівняпередачі даних (спочатку - як гіпертекстових документів). Основою HTTP є технологія «клієнт-сервер», тобто передбачається існування споживачів (клієнтів), які ініціюють з'єднання та надсилають запит, та постачальників (серверів), які чекають на з'єднання для отримання запиту, виробляють необхідні діїта повертають назад повідомлення з результатом.

HTTP використовується також як «транспорт» для інших протоколів прикладного рівня, таких як SOAP, XML-RPC, WebDAV.

Основним об'єктом маніпуляції в HTTP є ресурс, який вказує URI (Uniform Resource Identifier) ​​у запиті клієнта. Зазвичай такими ресурсами є файли, що зберігаються на сервері, але ними можуть бути логічні об'єктиабо щось абстрактне. Особливістю протоколу HTTP є можливість вказати в запиті та відповіді спосіб подання одного і того ж ресурсу по різним параметрам: формат, кодування, мови і т. д. Саме завдяки можливості вказівки способу кодування повідомлення клієнт і сервер можуть обмінюватися двійковими даними, хоча даний протоколє текстовим.

HTTP – протокол прикладного рівня, аналогічними йому є FTP та SMTP – простий протокол передачі пошти. Обмін повідомленнями йде за звичайною схемою "запит-відповідь". Для ідентифікації ресурсів HTTP використовує глобальні URI. На відміну від багатьох інших протоколів, HTTP не зберігає свого стану. Це означає відсутність збереження проміжного стану між парами «запит-відповідь». Компоненти, що використовують HTTP, можуть самостійно здійснювати збереження інформації про стан, пов'язаний з останніми запитамита відповідями. Браузер, який надсилає запити, може відстежувати затримки відповідей. Сервер може зберігати IP-адреси та заголовки запитів останніх клієнтів. Проте сам протокол не обізнаний з попередніми запитами та відповідями, в ньому не передбачена внутрішня підтримка стану, до нього не пред'являються такі вимоги.

Розширюваність

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

HTTP/1.1 - поточна версіяпротоколу. Новим у цій версії був режим «постійного з'єднання»: TCP-з'єднання може залишатися відкритим після надсилання відповіді запит, що дозволяє посилати кілька запитів за одне з'єднання. Клієнт тепер зобов'язаний надсилати інформацію про ім'я хоста, до якого він звертається, що уможливило більш просту організацію віртуального хостингу.

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

Методи HTTP запиту

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

Кожен сервер повинен підтримувати як мінімум способи GET і HEAD. Якщо сервер не розпізнав вказаний клієнтом метод, він повинен повернути статус 501 (Not Implemented). Якщо серверу метод відомий, але не застосовний до конкретного ресурсу, то повертається повідомлення з кодом 405 (Method Not Allowed). В обох випадках серверу слід включити у повідомлення відповіді заголовок Allow зі списком підтримуваних методів.

Крім методів GET та HEAD, часто застосовується метод POST.

• Заголовки (параметри) HTTP запиту, відповіді, сутності

  Усі заголовки в протоколі HTTP поділяються на чотири основні групи (у нижченаведеному порядку рекомендується надсилати заголовки одержувачу):

  General Headers(Основні заголовки) - повинні включатись у будь-яке повідомлення клієнта та сервера.

  Request Headers(Заголовки запиту) – використовуються лише у запитах клієнта.

  Response Headers(Заголовки відповіді) – лише для відповідей від сервера.

  Entity Headers(Заголовки сутності) – супроводжують кожну сутність повідомлення. В окремий клас заголовки сутності виділені для того, щоб не плутати їх із заголовками запиту або заголовками відповіді під час передачі множинного вмісту (MIME).

  Усі необхідні для функціонування HTTP заголовки описані в основних RFC. За потреби можна створювати свої заголовки. Традиційно до імен таких додаткових заголовків додають префікс "X-" для уникнення конфлікту імен з можливо існуючими.

  Рядки після головного рядка запиту (GET /index.html HTTP/1.1) мають наступний формат: Параметр: значення. У такий спосіб задаються параметри запиту. Це необов'язково, всі рядки після головного рядка запиту можуть бути відсутніми; у цьому випадку сервер набирає їх значення за замовчуванням або за результатами попереднього запиту (під час роботи в режимі Connection: Keep-Alive).

  Параметр Connection(з'єднання) - може приймати значення Keep-Alive та close. У HTTP 1.0 за передачею сервером затребуваних даних слід роз'єднання з клієнтом, і транзакція вважається завершеною, якщо не передано заголовок Connection: Keep Alive. У HTTP 1.1 сервер за замовчуванням не розриває з'єднання і клієнт може надсилати інші запити. Оскільки в багато документів вбудовані інші документи - зображення, кадри, аплети і т.д., це дозволяє заощадити час і витрати клієнта, якому в іншому випадку довелося б для отримання лише однієї сторінки багаторазово з'єднуватися з одним сервером. Таким чином, HTTP 1.1 транзакція може циклічно повторюватися, поки клієнт або сервер не закриє з'єднання явно.

  Параметр User-Agent- значенням є кодове позначення браузера.

  Параметр Accept- список типів вмісту, що підтримуються браузером, в порядку їх переваги даним браузером.

  Параметр Host- Ім'я домену, з якого запитується ресурс. Корисно, якщо на сервері є кілька віртуальних серверівпід одним IP-адресою. У цьому випадку ім'я віртуального домену визначається цим полем.

  Параметр Last-Modified(в останній раз модифіковано) (W3C Last-Modified) - дата і час останньої змінидокумента. Використовуючи його, клієнт, подібно до випадку з ETag, може звертатися до сервера із запитом "If-Modified-Since" - у цьому випадку сервер повинен порівняти дату останньої модифікації копії, збереженої на клієнті, з актуальною датою останньої модифікації. Якщо вони співпадуть, це означає, що копія в кеші клієнта не застаріла, і повторне скачування не потрібне (код відповіді "304 Not Modified"). Last-Modified також необхідний для коректної обробки сайту роботами, які використовують інформацію про дату модифікації сторінок для сортування результатів пошуку за датою, а також для визначення частоти оновлюваності Вашого сайту.

  Для SSI документів Apache видаватиме "Last-Modified" у тому випадку, якщо вказана директива "XBitHack full" (наприклад, у файлі.htaccess)

  Параметр ETag(Об'єктна мітка) - з'явився в HTTP 1.1 (W3C ETag). ETag служить для присвоєння кожній сторінці унікального ідентифікатора, значення якого змінюється за зміни сторінки (документа). ETag є хеш («відбиток») байтів документа, якщо у документі зміниться хоч один байт, то зміниться і ETag. ETag використовується для кешування документа. Цей заголовок зберігається на клієнті, і в разі повторного звернення до документа дозволяє браузеру звернутися до сервера із запитом 'If-None-Match', а сервер повинен за значенням ETag-мітки визначити, чи не змінився документ(сторінка), і якщо ні, відповісти кодом '304 Not Modified'.

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

  Інші заголовки HTTP:

  HTTP_X_FORWARDED_FOR

  HTTP_X_FORWARDED

  HTTP_FORWARDED_FOR

  • HTTP_X_COMING_FROM

    HTTP_COMING_FROM

  • HTTP_X_CLUSTER_CLIENT_IP

  • HTTP_XROXY_CONNECTION

    HTTP_PROXY_CONNECTION

    HTTP_USERAGENT_VIA - проксі

  Приклад аналізу HTTP запиту

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

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

  Клієнт ініціює транзакцію таким чином:

  Клієнт встановлює зв'язок із сервером за призначеним номером порту, офіційний номерпорту за замовчуванням - 80. Потім клієнт надсилає запит документа, вказавши метод, адресу документа та номер версії HTTP. Наприклад, у головному рядку запиту GET/index.html HTTP/1.1

  використовується метод GET, яким за допомогою версії 1.1 HTTP запитується документ index.html.

  Клієнт надсилає інформацію заголовка (необов'язкову, заголовок host є обов'язковим), щоб повідомити серверу інформацію про свою конфігурацію та дані про формати документів, які він може приймати. Вся інформація заголовка вказується рядково, при цьому в кожному рядку наводиться ім'я та значення. Наприклад, наведений нижче заголовок, надісланий клієнтом, містить його ім'я та номер версії, а також інформацію про деякі кращі для клієнта типи документів: User-Agent: Mozilla/5.0 (Ubuntu; :8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

  Завершується заголовок порожнім рядком.

  Надіславши запит і заголовки, клієнт може надіслати і додаткові дані, наприклад, для CGI скриптів.

  Сервер відповідає на запит клієнта так:

  Перша частина відповіді сервера - рядок стану, що містить три поля: версію HTTP, код стану та опис. Поле версії містить номер версії HTTP, який сервер використовує для передачі відповіді. Код стану – це трирозрядне число, що означає результат обробки сервером запиту клієнта. Опис, що йде за кодом стану, є просто зрозумілий для людини текст, що пояснює код стану. Наприклад, рядок стану HTTP/1.1 304 Відмінно

  говорить про те, що для відповіді сервер використовує версію HTTP 1.1. Код стану 304 означає, що клієнт запросив документ методом GET, використовував заголовок If-Modified-Since або If-None-Match та документ не змінився із зазначеного моменту.

  Після рядка стану сервер передає клієнту інформацію заголовка, що містить дані про сервер і затребуваний документ. Нижче наведено приклад заголовка: Date: Thu, 15 Dec 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8

  Завершує заголовок порожній рядок.

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

  HTTP status code

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

  Клієнт може знати всі коди стану, але він має відреагувати відповідно до класу коду. В даний час виділено п'ять класів кодів стану:

  1xx: Informational (Інформаційні). Інформаційні коди стану, які повідомляють клієнту, що сервер перебуває у процесі обробки запиту. Реакція клієнта на ці коди не потрібна;

  2xx: Success (Успішно).

  1. 200 OK(Добре). З'явився у HTTP/1.0. Успішний запит ресурсу. Якщо клієнт запросив будь-які дані, то вони знаходяться в заголовку та/або тілі повідомлення.

  3xx: Redirection (Перенаправлення). Коди класу 3xx повідомляють клієнту, що з успішного виконання операції необхідно зробити інший запит (зазвичай інакше URI). З цього класу п'ять кодів 301, 302, 303, 305 і 307 відносяться безпосередньо до перенаправлень (редирект). Адреса, за якою клієнту слід зробити запит, сервер вказує в заголовку Location. Багато клієнтів при перенаправленні з кодами 301 і 302 помилково застосовують метод GET до другого ресурсу незважаючи на те, що перший запит був з іншим методом. Щоб уникнути непорозумінь у версії HTTP/1.1, були введені коди 303 і 307 замість 302. Змінювати метод запиту потрібно тільки якщо сервер відповів 303. В інших випадках наступний запит робити з вихідним методом.

  1. 302 Found(Знайдено). Введено у HTTP/1.0. Запитаний документ тимчасово доступний за іншим URI , вказаним у заголовку в полі Location.

  4xx: Client Error (Помилка клієнта). Клас кодів 4xx призначений для вказівки помилок клієнта. При використанні всіх методів, крім HEAD, сервер повинен повернути в тілі повідомлення гіпертекстове пояснення для користувача.

  1. 404 Not Found (Не знайдено). З'явився у HTTP/1.0. Сервер зрозумів запит, але не знайшов відповідного ресурсу за вказаним URI.

  5xx: Server Error (Помилка сервера)

  Посилання на тему HTTP 1.1

  HTTP/2

  HTTP/2 (спочатку HTTP/2.0) – друга велика версія мережевого протоколу HTTP. Протокол заснований на SPDY (HTTP-сумісний протокол, розроблений Google).

  Протокол HTTP/2 є бінарним. Порівняно з попереднім стандартом змінено способи розбиття даних на фрагменти та транспортування їх між сервером та клієнтом.

  У HTTP/2 сервер має право надіслати той вміст, який ще не був запрошений клієнтом. Це дозволить серверу відразу вислати додаткові файли, які будуть потрібні браузеру для відображення сторінок, без необхідності аналізу браузером основної сторінки та запиту необхідних додатків.

Протокол HTTP або HyperText Transfer Protocol – це головний прокол (всесвітньої павутини). Основне завдання протоколу забезпечити передачу гіпертексту в мережі. У протоколі точно описується формат повідомлень для обміну клієнтів і серверів.

Описано протокол HTTP RFC 2616(HTTP1.1).

Основа протоколу забезпечити взаємодію клієнта та сервера за допомогою одного ASCII-запиту, і наступної на нього відповіді у стандарті RFC 822 MIME.

На практиці протокол HTTP працює на основі порту 80, але можна налаштувати і по-іншому. І хоча TCP/IP не є обов'язковим, він залишається кращим, тому що бере на себе розбиття та складання повідомлень на себе і не напружує ні браузер, ні сервер.

Слід зазначити, що протокол HTTP може використовуватися не тільки у веб-технологіях, але й інших програмах ООП (об'єктивно-орієнтованих).

URL

Основою веб-спілкування клієнт-сервер є запит. Запит надсилається за допомогою URL-єдиного покажчика ресурсів Інтернет. Нагадаю, що таке URL-адреса.

Зрозуміла та проста структура URL складається з таких елементів:

• Протокол;
• Хост;
• Порт;
• Каталок ресурсу;
• Мітки (запит).

Примітка: Протокол http – це протокол для простих, не захищених з'єднань. Захищені з'єднання працюють за протоколом https. Він безпечніший для обміну даними.

Методи HTTP запитів

Один з параметрів URL визначає назву хоста, з яким ми хочемо спілкуватися. Але цього замало. Потрібно визначити дію, яку потрібно вчинити. Зробити це можна за допомогою методу, визначеного протоколом HTTP.

Методи HTTP

• Метод/Опис
• HEAD/Прочитати заголовок веб-сторінки
• GET/Прочитати веб-сторінку
• POST/Додати до веб-сторінки
• PUT/Зберегти веб-сторінку
• TRACE/Надіслати запит
• DELETE/Видалити веб-сторінку
• OPTIONS/Відобразити параметри
• CONNECT/Зарезервовано для майбутнього використання

Розберемо методи HTTP докладніше

Метод GET.запитує сторінку (файл, об'єкт), закодовану за стандартом MIME. Це найбільш уживаний метод. Структура методу:
GET ім'я_файлу HTTP/1.1

Метод HEAD.Цей метод вимагає заголовок повідомлення. При цьому сторінка не завантажується. Цей метод дозволяє дізнатися час останнього оновлення сторінки, що потрібно керувати КЕШом сторінок. Цей метод дозволяє перевірити працездатність запитуваного URL-адреси.

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

Метод POST.Цей метод додає вміст до наявної сторінки. Використовується як приклад для додавання запису на форум.

Метод DELETE.Цей спосіб знищує сторінку. Метод видалення вимагає підтвердження прав користувача видалення.

Метод TRACE.Цей метод налагодження. Він вказує серверу відправити запит назад і дозволяє дізнатися, чи спотворюється ні, запит клієнта, повернувшись від сервера.

Метод CONNECT– метод резерву, який не використовується.

Метод OPTIONSдозволяє запросити властивості сервера та властивості будь-якого файлу.

У спілкуванні клієнта та сервера «запит-відповідь», сервер обов'язково генерує відповідь. Це може бути веб-сторінка або рядок стану з кодом стану. Код стану вам добре відомий. Один із кодів відомий код 404 –Сторінку не знайдено.

Групи кодів стану

1хх: Готовність сервера, Код 100 - сервер готовий обробляти запити клієнта;

2хх: Успіх.

• Код 200 – запит опрацьовано успішно;
• Код 204 – Вмісту немає.

3хх: Перенаправлення.

• Код 301 – Запрошувану сторінку перенесено;
• Код 304 – Сторінка у КЕШі ще актуальна.

4хх: Помилка клієнта.

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

Клієнти та сервери взаємодіють, обмінюючись індивідуальними повідомленнями (а не потоком даних). Повідомлення, надіслані клієнтом, зазвичай веб-браузером, називаються запитами, а повідомлення, надіслані сервером, називаються відповідями.

Хоча HTTP був розроблений ще на початку 1990-х років, за рахунок своєї розширюваності надалі він постійно вдосконалювався. HTTP є протоколом прикладного рівня, який найчастіше використовує можливості іншого протоколу – TCP (або TLS – захищений TCP) – для пересилання своїх повідомлень, проте будь-який інший надійний транспортний протокол теоретично може бути використаний для доставки таких повідомлень. Завдяки своїй розширюваності він використовується не тільки для отримання клієнтом гіпертекстових документів або зображень і відео, але і для передачі контенту серверам, наприклад, за допомогою HTML-форм. HTTP також може бути використаний для отримання лише частин документа з метою оновлення веб-сторінки на запит.

Компоненти систем на основі HTTP

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

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

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

Клієнт: користувач-агент

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

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

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

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

Веб-сервер

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

Сервер не обов'язково розташований на одній машині, і навпаки - кілька серверів можуть бути розташовані (хоститися) на одній і тій же машині. Відповідно до версії HTTP/1.1 і маючи Host заголовок, вони навіть можуть ділити ту ж саму IP-адресу.

Проксі

Між веб-браузером та сервером знаходяться велика кількістьмережевих вузлів передавальних HTTP повідомлення. З-за шаруватої структури, більшість з них оперують також на транспортному мережевому або фізичному рівнях, стаючи прозорим на шарі HTTP і потенційно знижуючи продуктивність. Ці операції на рівні додатків називаються проксі . Вони можуть бути прозорими, чи ні (зміни запитів не пройдуть через них), і здатні виконувати безліч функцій:

• caching (кеш може бути публічним або приватним, як кеш браузера)
• фільтрація (як сканування антивірусу, батьківський контроль, …)
• вирівнювання навантаження (дозволити кільком серверам обслуговувати різні запити)
• аутотентифікація (контролювати доступом до різних ресурсів)
• протоколювання (дозвіл на зберігання історії операцій)

Основні аспекти HTTP

HTTP - простий

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

HTTP - розширюваний

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

HTTP не має стану, але має сесію

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

HTTP та з'єднання

З'єднання керується на транспортному рівні, І тому важливо виходить за межі HTTP. Хоча HTTP не вимагає, щоб базовий транспортний протокол був заснований на з'єднаннях, вимагаючи лише надійність, або відсутність втрачених повідомлень (тобто як мінімум подання помилки). Серед двох найбільш поширених транспортних протоколів Інтернету TCP надійний, а UDP - ні. HTTP згодом покладається на стандарт TCP, заснований на з'єднаннях, незважаючи на те, що з'єднання не завжди потрібне.

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

Для пом'якшення цих недоліків, HTTP/1.1 надав конвейєрну обробку (яку виявилося важко реалізувати) та стійкі з'єднання: лежаче в основі TCPЗ'єднання можна частково контролювати через заголовок Connection. HTTP/2 зробив наступний крок, додавши мультиплексування повідомлень через просте з'єднання, що допомагає тримати з'єднання теплим та ефективнішим.

Проводяться експерименти з розробки кращого транспортного протоколу, що підходить для HTTP. Наприклад, Google експериментує з QUIC , яка заснована на UDP для надання більш надійного та ефективного транспортного протоколу.

Чим можна керувати через HTTP

Природна розширюваність HTTP згодом дозволила більше управління та функціональність Мережі. Кеш і методи автентифікації були ранніми функціями історії HTTP. Здатність послабити початкові обмеження, навпаки, було додано у 2010-ті.

Нижче наведено загальні функції, керовані з HTTP.

• 
  Сервер може інструктувати проксі та клієнти: що та як довго кешувати. Клієнт може інструктувати проксі проміжних кешів ігнорувати документи, що зберігаються.
• Ослаблення обмежень джерела
  Для запобігання шпигунським та іншим, що порушують приватність, вторгнень, веб-браузер забезпечує строгий поділ між веб-сайтами. Тільки сторінки з того ж джереламожуть отримати доступ до інформації на веб-сторінці. Хоча такі обмеження навантажують сервер, заголовки HTTP можуть послабити строго поділ на стороні сервера, дозволяючи документу стати частиною інформації з різних доменів(З причин безпеки).
• Аутентифікація
  Деякі сторінки доступні лише спеціальним користувачам. Базова автентифікаціяможе надаватися через HTTP, або через використання заголовка WWW-Authenticate і подібних до нього, або за допомогою налаштування спецсесії, використовуючи куки.
• Проксі та тунелювання
  Сервери та/або клієнти часто розміщуються в інтранеті, і приховують свої справжні IP-адреси від інших. HTTP запити йдуть через проксі для перетину цього бар'єру. Не всі проксі - HTTP проксі. SOCKS-протокол, наприклад, оперує на нижчому рівні. Інші, наприклад, ftp, можуть бути оброблені цими проксі.
• Сесії
  Використання HTTP кук дозволяє пов'язати запит із станом на сервері. Це створює сесію, хоча ядро ​​HTTP - протокол без стану. Це корисно не тільки для кошиків в інтернет-магазинах, але також для будь-яких сайтів, що дозволяють налаштувати користувачеві вихід.

HTTP потік

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

1. Відкриття TCP з'єднання: TCP-з'єднання буде використовуватися для надсилання запиту або запитів, та отримання відповіді. Клієнт може відкрити нове з'єднання, перевикористовувати існуюче або відкрити кілька TCP-з'єднань до сервера.
2. Надсилання HTTP-повідомлення: HTTP-повідомлення (до HTTP/2) - людино-читаемо. Починаючи з HTTP/2, прості повідомленняінкассилуються у кадри, унеможливлюючи їх читання безпосередньо, але принципово залишаються такими ж. GET / HTTP/1.1 Host: сайт Accept-Language: fr
3. Читає відповідь від сервера: HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html
4. Закриває або перевикористовує з'єднання для подальших запитів.

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

HTTP повідомлення

HTTP/1.1 і раніше HTTP повідомлення людино-читаемы. У версії HTTP/2 ці повідомлення вбудовані в нову бінарну структуру, кадр, що дозволяє оптимізації, такі як компресія заголовків та мультиплексування. Навіть якщо частина оригінального повідомлення HTTP відправлена ​​в цій версії HTTP, семантика кожного повідомлення не змінюється і клієнт відтворює (віртуально) оригінальний запит HTTP. Це також корисно для розуміння HTTP/2 повідомлень у форматі HTTP/1.1.