💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Протокол HTTP

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

Центральним об'єктом в HTTP є ресурс, на який вказує URI в запиті клієнта. Зазвичай такими ресурсами є ті, які зберігаються на сервері файли. Особливістю протоколу 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-запиту, переданого клієнтом серверу, входять наступні компоненти.

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

- поля заголовка;

- порожній рядок;

- тіло запиту.

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

Рисунок 6.1 - Структура запиту клієнта

Рядок стану має наступний формат: метод_запроса URL_pecypca версія_протокола_НТТР

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

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

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

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

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

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

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

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

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

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

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

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

Нижче представлений приклад HTML-запиту, згенерованого браузером

GET https://oak.oakland.edu/ HTTP/1.0

Connection: Keep-Alive

User-Agent: Mozilla/4.04 [en] (Win95; I)

Host: oak.oakland.edu

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Language: en

Accept-Charset: iso-8859-l, *, utf-8

Отримавши від клієнта запит, сервер повинен відповісти йому. Знання структури відповіді сервера необхідно розробнику веб-додатків, так як програми, які виконуються на сервері, повинні самостійно формувати відповідь клієнту.

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

- рядок стану;

- поля заголовка;

- порожній рядок;

- тіло відповіді.

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

Версія_протокола

Код_відповіді

Пояснювальне_повідомлення

- версія_протокола задається в тому ж форматі, що і в запиті клієнта, і має той же зміст;

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

- пояснювальне_повідомлення дублює код відповіді в символьному вигляді. Це рядок символів, яка не обробляється клієнтом. Вона призначена для системного адміністратора або оператора, що займається обслуговуванням системи, і є розшифровкою коду відповіді.

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

HТТР/1.0 200 ОК

Як видно, за версією протоколу HTTP 1.0 слід код 200. У цьому коді символ 2 означає успішну обробку запиту клієнта, а інші дві цифри (00) - номер даного повідомлення.

У використовуваних в даний час реалізаціях протоколу HTTP перша цифра не може бути більше 5 і визначає наступні класи відповідей.

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

- 2 - успішна обробка запиту клієнта.

- 3 - перенаправлення запиту. Щоб запит був обслужений, необхідно предпрінять додаткові дії.

- 4 - помилка клієнта. Як правило, код відповіді, що починається з цифри 4, повер-тається в тому випадку, якщо в запиті клієнта зустрілася синтаксична помилка.

- 5 - помилка сервера. З тих чи інших причин сервер не в змозі виполніть запит.

Приклади кодів відповідей, які клієнт може отримати від сервера, і поясняющіе повідомлення наведені в таблиці 6.2.

Таблиця 6.2 - Класи кодів відповіді сервера.

У відповіді використовується така ж структура полів заголовка, як і в запиті клієнта. Поля заголовка призначені для того, щоб уточнити відповідь сервера клієнту. Опис деяких з полів, які можна зустріти в заголовку відповіді сервера, в таблиці 6. 3

Таблиця 6.3 - Поля заголовка відповіді веб-сервера

В тілі відповіді міститься код ресурсу, переданого клієнтові у відповідь на запит. Це не обов'язково повинен бути HTML-текст веб-сторінки. У складі відповіді можуть передаватися зображення, аудіо-файл, фрагмент відеоінформації, а також будь-який інший тип даних, підтримуваних клієнтом. Про те, як слід обробляти отриманий ресурс, клієнту повідомляє вміст поля заголовка Content-type.

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

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

Поле з ім'ям 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 досить великий. У таблиці 6.4 наведені приклади MIME-типів, які найчастіше зустрічаються в заголовках HTML-запитів і відповідей.

Таблиця 6.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-шлях>

де:

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

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

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

- хост - повністю прописане доменне ім'я хоста в системі DNS або IP-адресу хоста;

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

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

Загальноприйняті схеми (протоколи) URL включають протоколи: ftp, http, https, telnet, а також:

- gopher - протокол Gopher;

- mailto - адреса електронної пошти;

- news - новини Usenet;

- nntp - новини Usenet через протокол NNTP;

- irc - протокол IRC;

- prospero - служба каталогів Prospero Directory Service;

- wais - база даних системи WAIS;

- xmpp - протокол XMPP (частина Jabber);

- file - ім'я локального файлу;

- data - безпосередні дані (Data: URL);