Налаштування обладнання та програмного забезпечення

Web протоколи. Введення в клієнт-серверні технології Веб

Ми випустили нову книгу «Контент-маркетинг у соціальних мережах: Як засісти в голову передплатників та закохати їх у свій бренд»

Web-сервіс (служба) – програма, яка організовує взаємодію між сайтами. Інформація з одного порталу передається на інший.

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

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

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

Архітектура та протоколи Web-сервісів

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

Механізм обміну даними формується у описі Web Services Description. Це специфікація, що охоплює формати пересилання, типи контенту, транспортні протоколи, що застосовуються у процесі обміну відомостями між замовником та транспортником послуг.

Сьогодні найчастіше використовуються кілька технологій для реалізації різноманітних веб-сервісів:

  1. TCP/IP - протокол, який розуміється практично будь-яким мережевим обладнанням, від мейнфреймів до портативних пристроївта PDA.
  2. HTML - це універсальна мова розмітки, яка використовується для демонстрації контенту пристроями споживачів.
  3. XML – універсальний засіб обробки всіх різновидів даних. На його основі можуть працювати інші протоколи обміну інформацією: SOAP і WSDL.
  4. UDDI – універсальне джерело розпізнавання, інтеграції та описи. Працює, як правило, у приватних мережах і поки що не знайшов достатнього поширення.

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

Переваги

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

Недоліки

  • Невисока продуктивність і великий обсяг трафіку, порівняно із системами RMI, CORBA, DCOM, за рахунок використання XML-повідомлень у розрізі тексту.
  • Рівень безпеки. Всі сучасні веб-сервіси повинні впроваджувати кодування та вимагати авторизації користувача. Чи вистачить тут наявності HTTPS або потрібні більш надійні протоколи, як XML Encryption, SAML і т.д. - вирішуються в ході розробки.

Завдання веб-сервісів

Веб-сервіси можуть використовуватись у багатьох сферах.

B2B-транзакції

Інтеграція процесів відбувається одразу, без участі людей. Наприклад, поповнення каталогу інтернет-магазину новими товарами. Їх привозять на склад, і комірник зазначає в базі даних парафію. Автоматично інформація передається до інтернет-магазину. І покупець замість позначки "Немає на складі" на картці товару бачить його кількість.

Інтеграція сервісів підприємств

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

Створення системи клієнт-сервер

Сервіси використовуються, щоб настроїти роботу клієнта та сервера. Це дає переваги:

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

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

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

UNIX

Можливо, найпростіший протокол у послуги daytime. Якщо підключитися до порту 13 машини, що підтримує daytime сервер, цей сервер відправить у відповідь інформацію про поточну дату і час і потім відключить з'єднання. Протокол виглядає так: «Якщо клієнт встановлює зв'язок із сервером daytime, йому надсилаються дані дати та часу, після чого з'єднання відключається». Більшість машин з UNIX підтримують цей сервер. Ви можете зв'язатися з ним за допомогою програми Telnet. У UNIX сесія матиме такий вигляд:

  • %telnet web67.ntx.net 13
  • З'єднання з web67.ntx.net.
  • Символ скасування "^]".
  • Неділя 25 жовтня 08:34:06 1998

Windows

На машині, яка працює під ОС Windows, можна отримати доступ до цього сервера, ввівши "telnet web67.ntx.net 13" у вікні MSDOS.

У цьому прикладі web67.ntx.net – серверна машина UNIX, а 13 – номер порту для послуги daytime. Програма Telnet підключається до порту 13 (telnet зазвичай підключається до порту 23, але можна вказати будь-який інший порт для підключення), потім сервер надсилає дані дати та часу, після чого розриває з'єднання. У більшості версій Telnet можна вказувати номер порту і цією можливістю можна користуватися незалежно від того, яка версія Telnet встановлена ​​на машині.

Більшість протоколів складніші, ніж протокол для daytime, вони визначені у наявних у вільному доступі Робочі пропозиції (Request for Comment, RFC) (хороший архів всіх RFC дивіться sunsite.auc.dk/RFC/). Кожен WEB серверв Інтернеті відповідає вимогам протоколу HTTP, зібраним у документі The Original HTTP у 1991 році. Найважливіша форма протоколу, яка сприймається HTTP сервером, включає лише одну команду: GET. Якщо встановити зв'язок із сервером, що працює за протоколом HTTP і надіслати запит «GET ім'я файлу», сервер відреагує надсиланням джерелу запиту вмісту вказаного файлу, після чого відключить з'єднання. Типова сесія має такий вигляд:

  • %telnet сайт 80
  • Спроба з'єднання з 78.110.59.235.
  • Поєднання з pcwork.ru.
  • Символ скасування "^]".
  • З'єднання відключено зовнішнім комп'ютером.

У початковому варіанті протоколу HTTP потрібно було відправити тільки дійсне ім'я файлу, наприклад [/] або Пізніше протокол змінили, щоб отримати можливість обробки повних URL. Це дозволило компаніям, які займаються віртуальним доменом, в умовах, коли багато доменів розміщують на одній машині, використовувати для всіх таких доменів одну IP адресу.

Підведемо підсумок

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

  1. розділив URL на три частини:
  • Протокол ("http")
  • Ім'я сервера («сайт») - останнім часом позитивна тенденція скорочувати перші три літери www
  • Ім'я файлу ("web server.htm")
  • Браузер зв'язується із сервером імен для перекладу імені сервера, в IP адресу, який використовується цим браузером для з'єднання з відповідною серверною машиною.
  • Після отримання IP адреси вказаний браузер встановлює з'єднання з WEB сервером, що має цю IP адресу, по порту 80.
  • Відповідно до протоколу HTTP, браузер відправляє на цей сервер запит GET на отримання файлу (зауважимо, що разом із запитом GET з браузера на сервер можуть відправлятися куки - подробиці можна дізнатися зі статті про те, як працюють куки).
  • Сервер відправляє текст HTMLзапитаної WEB-сторінки на браузер. (У заголовку сторінки сервера на браузер також можуть передаватися куки).
  • Браузер зчитує HTML та відтворює відповідну сторінку на екрані монітора.
  • Доповнення: Безпека

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

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

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

    Додаток: Динамічні сторінки

    А як із динамічними WEB сторінками? Наприклад:

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

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

    Кожна серверна машина відкриває доступ з Інтернету до послуг, використовуючи пронумеровані порти, по одному для кожної послуги, яка є на сервері. Наприклад, якщо на серверній машині є WEB сервер і FTP сервер, зазвичай доступ до WEB серверу здійснюється через порт 80, а до FTP серверу- через порт 21. Клієнти підключаються до послуги, вибравши відповідну адресу та підключившись до відповідного порту.

    Кожній популярній послузі поставлено у відповідність певний номерпорту. Нижче наводяться номери портів, що найчастіше використовуються:

    • echo 7
    • daytime 13
    • qotd 17 (Цитата дня)
    • ftp 21
    • telnet 23
    • smtp 25 (Електронна пошта)
    • time 37
    • nameserver 53 (Сервер імен)
    • nicname 43 (Хто є хто)
    • gopher 70
    • finger 79
    • WWW 80

    Обмеження

    Якщо серверна машина дозволяє підключення до порту з мережі Інтернет і цей порт не захищений, можна підключитися до нього з будь-якої точки Інтернету та користуватися відповідною послугою. Слід зазначити, що немає будь-яких обмежень, що наказують, наприклад, WEB серверу підключатися по порту 80. Вводячи в дію власну машину та встановлюючи на ній програмне забезпечення WEB сервера, можна за бажання вказати, щоб WEB сервер працював, наприклад, по порту 918 , або за будь-яким іншим незайнятим портом. Потім, якщо машині надано ім'я xxx.yyy.com, можна підключитися до цього сервера через Інтернет, використовуючи URL xxx.yyy.com:918. Частина «:918» явно вказує на номер порту і має додаватися всіма бажаючими зв'язатися з цим сервером. Якщо порт не вказано, стандартний браузер намагається підключитися до загальноприйнятого порту 80.

    HTTP. В його основу покладено взаємодію клієнт-сервер", тобто передбачається, що:
    1. Споживач- клієнтініціювавши з'єднання з постачальником-сервером, посилає йому запит;
    2. Постачальник- сервер, отримавши запит, робить необхідні дії та повертає назад клієнту відповідь із результатом.

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

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

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

    Протокол HTTP

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

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

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

    Усе програмне забезпеченнядля роботи з протоколом HTTP поділяється на три основні категорії:

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

    Основними клієнтами є браузери, наприклад: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator та інші. Найбільш популярними реалізаціями веб-серверів є: Internet Information Services (IIS), Apache, lighttpd, nginx. Найбільш відомі продажі проксі-серверів: Squid, UserGate, Multiproxy, Naviscope.

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

    1. Встановлення з'єднання TCP.
    2. Запит клієнта.
    3. Відповідь сервера.
    4. Розрив TCP-з'єднання.

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

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

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

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


    Рис. 2.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 зазвичай задається в наступному форматі:

    HTTP/версія.модифікація

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

    Ім'я_поля: Значення

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

    Імена деяких найпоширеніших у запиті клієнта полів заголовка та його призначення наведено у таблиці 2.1 .

    Таблиця 2.1. Поля заголовка запиту HTTP.
    Поля заголовка HTTP -запиту Значення
    Host Доменне ім'я або IP-адреса вузла, до якого звертається клієнт
    Referer URL документа, який посилається на ресурс, вказаний у рядку стану
    From Адреса електронної поштикористувача, що працює з клієнтом
    Accept MIME-типи даних, що обробляються клієнтом. Це поле може мати кілька значень, що відокремлюються одне від одного комами. Часто поле заголовка Accept використовується для того, щоб повідомити сервер про те, які типи графічних файлівпідтримує клієнт
    Accept-Language Набір двосимвольних ідентифікаторів, розділених комами, які позначають мови, що підтримуються клієнтом
    Accept-Charset Перелік наборів символів, що підтримуються
    Content-Type MIME-тип даних, які у тілі запиту (якщо запит складається з одного заголовка)
    Content-Length Число символів, що містяться в тілі запиту (якщо запит не складається з одного заголовка)
    Range Є в тому випадку, якщо клієнт запитує не весь документ, а лише його частина
    Connection Використовується для керування з'єднанням TCP. Якщо поле містить Close, це означає, що після обробки запиту сервер повинен закрити з'єднання. Значення Keep-Alive пропонує не закривати TCP-з'єднання, щоб воно могло бути використане для наступних запитів
    User-Agent Інформація про клієнта

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

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

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

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

    Складові системи, засновані на HTTP

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

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

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

    Клієнт: учасник обміну

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

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

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

    Веб-сторінка є гіпертекстовим документом. Це означає, що деякі частини тексту, що відображається, є посиланнями, які можуть бути активовані (зазвичай натисканням кнопки миші) з метою отримання і відповідно відображення нової веб-сторінки (перехід за посиланням). Це дозволяє користувачеві "переміщатися" сторінками мережі (Internet). Браузер перетворює ці гіперпосилання на 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 Дата: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc8 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.

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

    Запити

    Приклади HTTP запитів:

    • HTTP-метод , зазвичай дієслово подібно до GET ,
    • Заголовки (опціонально), що надають додаткову інформацію для сервера.
    • Або тіло для деяких методів, таких як POST , що містить відправлений ресурс.

    Відповіді

    Приклади відповідей:

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

    Висновок

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

    Хоча HTTP/2 додає деяку складність, вбудовуючи повідомлення HTTP у кадри для покращення продуктивності, базова структура повідомлень залишилася з HTTP/1.0. Сесійний потік залишається простим, дозволяючи досліджувати та налагоджувати з простим

    Сподобалась стаття? Поділіться з друзями!
    Чи була ця стаття корисною?
    Так
    Ні
    Дякую за ваш відгук!
    Щось пішло не так і Ваш голос не було враховано.
    Спасибі. Ваше повідомлення надіслано
    Знайшли у тексті помилку?
    Виділіть її, натисніть Ctrl+Enterі ми все виправимо!