Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Tools & Tips

HTTP: Протокол, який повинен розуміти кожний веб-розробник (Частина 2)

by
Difficulty:IntermediateLength:LongLanguages:

Ukrainian (українська мова) translation by Nadia Gonzales (you can also view the original English article)

У попередній частині ми розглянули деякі основні питання, пов'язані з HTTP – такі, як структура URL-адреси, коди стану та заголовки запиту/відповіді. Засвоївши ці базові знання, тепер ми розглянемо більш складні аспекти роботи HTTP: реалізація з'єднань, автентифікація та гешування. Засвоївши ці базові знання, тепер ми розглянемо більш складні аспекти роботи HTTP: реалізація з'єднань, автентифікація та гешування.


З'єднання HTTP

Між клієнтом та сервером повинно бути встановлено з'єднання до того, як вони зможуть спілкуватися один з одним; HTTP використовує надійний протокол транспортного рівня, TCP (* Transmission Control Protocol – протокол керування передаванням; широко використовуваний в Інтернеті мережний протокол транспортного рівня з набору TCP/IP. Гарантує доставку переданих пакетів даних у потрібній послідовності, але трафік у цьому разі може бути дуже нерівномірний, тому що пакети зазнають усіляких затримок. Протокол TCP ґрунтується на встановленні логічного з'єднання між клієнтом і сервером і містить   механізм контролю перевантаження мережі, забезпечуючи автоматичне зниження швидкості обміну даними. Першу версію визначено в RFC 793. Тут і надалі примітка перекладача), для реалізації цього з'єднання. За налаштуванням у мережі для передачі даних використовується TCP-порт 80. Послідовність даних, що передаються по TCP-з'єднанню, поділено на IP-пакети (* протокольна одиниця обміну (PDU) мережного рівня. Цей пакет даних містить свою адресу доставки і передається через мережу з комутацією пакетів незалежно від інших пакетів без розриву логічного з'єднання і квитирування. Містить посилання на попередні пакети, адресовані тому самому одержувачу. Дейтаграмний спосіб передавання, що ґрунтується на аналізі адреси одержувача. В Інтернеті реалізується за допомогою протоколу IP); завдяки цьому протоколу пакети завжди надходять у вірній послідовності. HTTP – протокол прикладного рівня на основі TCP, що, в свою чергу, працює на базі IP (* протокол мережного рівня (частина набору протоколів TCP/IP), відповідальний за передавання й маршрутизацію повідомлень між вузлами Інтернету. Описано у RFC 791. Визначає правила, за якими дані розбиваються на пакети, що передаються між кінцевими системами та маршрутизаторами).

HTTPS – це захищена версія HTTP, згідно з якою між HTTP і TCP додається додатковий шар – TLS або SSL (Transport Layer Security (* протокол захисту [безпеки] транспортного рівня) або Secure Sockets Layer (* протокол безпечних з'єднань; специфікація протоколу для передачі по Інтернету зашифрованих, автентифікованих повідомлень (наприклад, електронних транзакцій), розроблена фірмою Netscape Communications. Версію SSL 2.0 прийнято як стандарт IETF й широко застосовують для перевірки повноважень і шифрування даних на транспортному рівні у разі роботи веб-браузера з веб-сервером. Для доступу до сторінок, захищеного протоколом SSL, в URL замість звичайного префікса http зазвичай застосовують префікс https (порт 443), який указує на те, що використовуватиметься SSL-з'єднання. Оскільки операції шифрування/дешифрування вимагають значних обчислювальних ресурсів, щоб знизити навантаження на веб-сервери, використовують апаратні SSL-прискорювачі. SSL 3.0 знаходиться в розробці й відкрита для обговорення) відповідно). За налаштуванням HTTPS використовує порт 433, і ми розглянемо його пізніше в цій частині.

HTTP and HTTPS layers

З'єднання HTTP ідентифікується на основі <source-IP, source-port> та <destination-IP, destination-port> (* сокет (поєднання IP-адреси і номера порту) – інтерфейс між прикладним та транспортним рівнем хоста, тобто API між застосуванням та комп'ютерною мережею). На стороні клієнта застосування, що використовує HTTP, розпізнається за допомогою набору <IP, port>. Встановлення з'єднання між двома кінцевими вузлами локальної мережі (ЛМ) – процес, що складається з декількох етапів:

Connection Delays
  • встановлення відповідності імені хоста IP-адресі за допомогою DNS (* Domain Name Server – сервер, що виконує перетворення імен доменів у IP-адреси; інтернет-служба, яка становить розподілену по всій земній кулі БД для ієрархічної системи імен мереж і комп'ютерів, підключених до Мережі, а також спосіб [протокол прикладного рівня] перетворення рядкових   адресів інтернет-серверів у числові IP-адреси. Визначена в RFC 1034 і 1035. Протокол DNS працює над протоколом UDP і йому призначено порт за номером 35. DNS також часто використовують для розподілення навантаження між серверами ("дзеркалами"), що дублюють популярні сайти і поштові сервери). 
  • встановлення з’ єднатися з сервером
  • відправлення запиту
  • очікування відповіді
  • закриття з'єднання

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

Згідно з HTTP/1.0 всі з'єднання закривалися після здійснення однієї транзакції (* логічна одиниця роботи, складена із запиту (наприклад, до БД) і одержання  результатів його обробки. Механізм транзакцій забезпечує одночасний доступ до БД багатьох користувачів) (* тобто реалізовувалось короткочасне з'єднання – передавання протягом одного TCP-з'єднання тільки одного об'єкта). Таким чином, якщо клієнт хотів запитати три окремі зображення з сервера, то він встановлював три окремі з'єднання з віддаленим хостом. Як ви можете судити по вищенаведеній схемі, через це може виникнути багато мережевих затримок (* час, необхідний для пересилання даних між двома комп'ютерами мережі), у наслідок чого постраждає якість досвіду взаємодії користувача.

Для зменшення кількості мережевих затримок в HTTP/1.1 було введено постійні з'єднання – довготривалі з'єднання, що залишаються відкритими, доки клієнт їх не закриє. В HTTP/1.1 за налаштуванням застосовуються постійні з'єднання, і при встановленні з'єднання для виконання однієї транзакції клієнт повинен додати заголовок запиту Connection: close. Це повідомляє серверу, що з'єднання необхідно закрити після відправлення відповіді.

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

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

Реалізація з'єднання на стороні сервера

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

  • відкриття каналу для початку прослуховування 80 порту (або якого-небудь іншого)
  • отримання та розбір повідомлення
  • формування відповіді
  • додавання заголовків відповіді
  • відправлення відповіді клієнтові
  • закриття з'єднання за наявності заголовка запиту Connection: close

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


Ідентифікація та автентифікація

HTTP – протокол прикладного рівня на основі TCP, що, в свою чергу, працює на базі IP.

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

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

  • Заголовки запитуFrom, Referer, User-Agent - ми розглядали їх в Частині 1.
  • ІР-адреса клієнта
  • Fat Urls (* збагачене посилання; також називають "extended link" – розширене посилання) – стан (* інформація про сесію поточного користувача) зберігається завдяки зміні URL-адрес (* динамічно сервером) та переадресації його по мірі переглядання сайту за іншою адресою (* іншою, ніж було задано первісно, наприклад, сервер надсилає документ з ...  <a href="/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-1145265-8016838">All Gifts</a><br> ... , де до кожної URL-адреси додається суфікс «002-1145265-8016838»); по суті стан акумулюється при кожному переході користувача за URL-адресою.
  • Кукі (* підтримуваний протоко­лом HTTP текстовий запис розміром до 4 Кбайт із даними про користувача, що повертає веб-сервер під час реєстрації користувача, який зберігається на його ПК) – найбільш популярний та ненав'язливий підхід (* із перелічених тут, оскільки тільки при ньому від користувача необхідно отримати попередню згоду на використання кукі-файлів; проте самі кукі можна поділити на категорії в залежності від їх нав'язливості (ступінь посягання на персональну інформацію): від нульового до високого ступеня (докладніше тут https://www.cookielaw.org/blog/2012/2/16/how-intrusive-are-your-cookies.aspx)).

Завдяки кукі сервер може додати до відповідей довільну інформацію за допомогою заголовка відповіді Set-Cookie. Значення кукі задаються у формі пар name=value (* им'я=значення), відокремлених символом «;», наприклад: Set-Cookie: session-id=12345ABC; username=nettuts.

Сервер може також обмежити використання кукі тільки для певного домену або шляху, а також він може зробити їх постійними (* об'єкт, що пересилається по мережі, час дії якого не обмежується часом виконання програм, що його створили та використовують) за допомогою встановлення значення для заголовка Expires. Кукі автоматично відправляються браузером при кожному запиті до сервера; також браузер гарантує, що до запиту додаються тільки специфічні для певного домену або шляху кукі. Для відправлення цих кукі на сервер використовується заголовок запиту Cookie: name=value [; name2=value2].

Найкращий спосіб ідентифікації користувача – зобов'язати його реєструватися (sign up) або входити до додатка (log in), проте для реалізації цієї можливості необхідно докласти зусилля як розробникові, так і користувачеві.

Технології на зразок OAuth (* Open Authorization – відкритий стандарт авторизації, який дозволяє користувачам відкривати доступ до своїх приватних даних (фотографії, відео, списки контактів), що зберігаються на одному сайті, іншому сайту, без потреби вводу імені користувача та паролю) полегшують реалізацію цієї можливості, проте як і раніше потрібна згода користувача. Важливу роль при цьому відіграє автентифікація (*  у системі комп'ютерної безпеки – процес, що дозволяє встановити, що користувач або комп'ютер (сервер), що намагається отримати інтерактивний доступ до певної категорії інформації, комп'ютерної системи, електронної пошти, дійсно той, за кого себе видає); також це, напевно, – єдиний спосіб ідентифікувати та розпізнати користувача.

Автентифікація

У самому протоколі HTTP реалізована підтримка елементарної форми автентифікації – Basic Authentication, а також більш захищеної – Digest Authentication.

При Basic Authentication сервер спочатку відхиляє запит клієнта та відправляє відповідь із заголовком відповіді WWW-Authenticate та кодом стану 401 Unauthorized (* і відповідною фразою). Отримавши цей заголовок, браузер відображує діалог для входу на сайт, запитуючи пароль та ім'я користувача. Ця інформація відсилається у закодованому за допомогою коду Base-64 (* спосіб кодування електронної пошти, сумісний із МІМЕ, стандартизований у RFC 2045. Використовує для перетворення тексту на шестибітовий код (значення від 0 до 63) спеціальну таблицю) форматі у заголовку запиту Authentication. Після цього сервер перевіряє правильність даних у запиті та надає доступ у разі коректності даних. Деякі сервери також можуть надсилати заголовок Authentication-Info із додатковою інформацією про автентифікацію.

Authentication Challenge/Response

Логічно виведений із Basic-Authentication спосіб автентифікації – Proxy Authentication. У цьому випадку запит на автентифікацію відправляється не сервером, а проміжним проксі. Проксі-сервер відправляє заголовок Proxy-Authenticate з  кодом стану 407 Unauthorized (* і відповідною фразою). У відповідь клієнт повинен відіслати пароль та ім'я користувача в заголовку запиту Proxy-Authorization.

Digest Authentication подібна до Basic, і при ній  використовується та ж сама техніка «рукостискання» за допомогою заголовків WWW-Authenticate і Authorization, проте у цьому випадку використовується більш надійна хеш-функція для шифрування імені користувача та пароля (звичайно за допомогою функції шифрування MD5 або KD). Хоча вважається, що Digest Authentication набагато надійніше, ніж Basic, на веб-сайтах звичайно використовується Basic Authentication завдяки простоті використання. Для підвищення безпеки у парі з Basic Auth використовується SSL.

HTTPS

HTTPS AddressBar

Завдяки протоколу HTTPS (* HTTP Secure – протокол захищеного передавання гіпертексту) у мережі реалізуються захищені з'єднання. Найпростіший спосіб впевнитися, що ви використовуєте HTTPS – перевірити адресний рядок браузера. Захищена передача в HTTPS реалізується за допомогою додавання шару шифрування/дешифрування між HTTP та TCP. Цей шар – SSL або його удосконалена версія – TLS.

В SSL використовується надійна форма шифрування за допомогою RSA (* схема (алгоритм) симетричного шифрування з відкритим ключем. Названа за прізвищами авторів: Rivest - Shamir - Adelman (Рон Рівест, Аді Шамір і Леонард Адлман), які розробили цю схему шифрування в 1978 р. Із деякими змінами цю схему використовують у системі шифрування PGP) та public-key cryptography (* криптографія з відкритим ключем;  розроблена Уайтфільдом Діффи (Whitfield Diffi). Використовує асиметричне шифрування, тобто пару ключів, причому кожна пара має такі властивості: зашифроване одним із них можна розшифрувати за допомогою іншого; маючи один ключ із пари, іменований відкритим, не можна одержати інший, таємний). Оскільки дуже важливо, щоб транзакції в мережі були безпечними, повсюдно використовувана заснована на стандартах PKI (* Public-Key Infrastructure – інфраструктура (системи шифрування) з відкритими ключами; частина стандарту X.509 (стандарт на шифрування даних у разі їхнього пересилання в мережах); система, що дозволяє впевнитися, що відкритий ключ належить саме тій особі, за фку вона себе видає. Використовує для цього центри сертифікації (Certificate Authority, CA)) розроблялася доволі ретельно.

Існуючим клієнтам/серверам нема потреби змінювати свій спосіб оброблення повідомлень, оскільки головна частина тяжкої роботи виконується на рівні SSL. Тому ви можете розробляти ваш веб-додаток за допомогою Basic Authentication та автоматично скористатися перевагами SSL шляхом переключення на протокол https://. Проте для того, щоб ваш веб-додаток працював за HTTPS, на вашому сервері повинен бути дійсний цифровий сертифікат (* невеликий файл, вміст якого унікально ідентифікує користувача чи сайт, показуючи, що можна довіряти певній інформації. Таким чином підтримано безпечний конфіденційний зв'язок в Інтернеті. Він пов'язує ім'я об'єкта, що бере участь у таємній транзакції, (адресу електронної пошти чи сайту) з відкритим ключем. У шифруванні з відкритими ключами є проблема пересилання ключів через Інтернет. В основу цифрових сертифікатів покладено ідею цифрового підпису).

Сертифікат

Так само, як для підтвердження вашої особи вам необхідно посвідчення особи, для ідентифікації веб-додатка використовується цифровий сертифікат. Сертифікати видаються CA (* Certificate Authority – центр сертифікації) та ручаються за достовірність вашої особи у мережі. CA – це вартові PKI. Найпоширенішим стандартом сертифікатів є X.509 v3; в такому сертифікаті міститься наступна інформація:

  • видавник сертифікату
  • алгоритм, використовуваний для створення сертифікату
  • ім'я суб'єкта (окремий користувач або організація), для якого створено даний сертифікат
  • інформація про публічний ключ суб'єкта
  • підпис CA, виконаний за допомогою заданого алгоритму створення підпису

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

Тільки-но справжність сертифікату встановлено, SSL-рукостискання завершено і починається безпечне  пересилання даних.


Гешування

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

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

  • Приватний: усередині браузера; тут гешуються паролі, імена користувачів, URL-адреси, історія відвідування та веб-контент. Цей тип кеш-пам'яті звичайно невеликого об'єму та призначений для одного користувача.
  • Публічний: розміщується на проксі для гешування між сервером та клієнтом. Об'єм пам'яті цього типу кеш-пам'яті набагато більше, оскільки тут обслуговуються багато користувачів. Згідно з усталеною практикою (* загальноприйнята практика, що не є правилом) між клієнтом та первісним сервером слід розміщувати багато проксі-серверів для гешування. Завдяки цьому полегшується обслуговування контенту, до якого часто звертаються, і водночас зберігається можливість отримати контент, який рідко запитують.
Cache Topology

Підтримування кеш-пам'яті

Незалежно від того, де розташовується кеш, процес підтримування кеш-пам'яті доволі подібний:

  • Отримання повідомлення запиту.
  • Розбір URL-адреси та заголовків.
  • Пошук локальної копії; у випадку відсутності отримати ресурс та зберегти локально.
  • Перевірка актуальності контенту в кеш-пам'яті; виконати запит для оновлення контенту тільки у разі потреби.
  • Формування відповіді з тіла повідомлення з кеш-пам'яті та оновлених заголовків.
  • Відправлення відповіді клієнту.
  • Фіксування події в журналі реєстрації подій (Необов'язково)

Звісно ж, сервер зобов'язується завжди надсилати вірні заголовки та відповіді. Якщо документ не змінювався, то сервер повинен прислати відповідь із кодом стану (* і відповідною фразою) 304 Not Modified. Якщо термін дії копії із кеш-пам'яті закінчився, то сервер повинен згенерувати нову відповідь з оновленими заголовками відповіді та 200 OK. У випадку, якщо ресурс видалено, то повинно бути надіслано відповідь з 404 Not Found. Завдяки цим відповідям полегшується налаштування кеш-пам'яті та гарантується, що застарілий контент не зберігається занадто довго.

Заголовки для керування кеш-пам'яттю

Сьогодні за допомогою паралельних та постійних з'єднань мінімізується кількість мережевих затримок.

Тепер, коли ми розуміємо, як працює кеш, настав час подивитися на заголовки запиту та відповіді, завдяки яким з'являється можливість використовувати інфраструктуру гешування. Підтримування контенту в актуальному стані – це одне з головних завдань кешу. Для підтримання копії ресурсу в кеш-пам'яті у відповідності з ресурсом на сервері, HTTP надає деякі прості механізми, а саме: використання терміну придатності документа (Document Expiration) та повторну  перевірку ресурсу на сервері (Server Revalidation).

Використання терміну дії документа

HTTP надає можливість первісному серверу додавати дату закінчення терміну до кожного документа за допомогою заголовків відповіді Cache-Control та Expires. Завдяки цьому полегшується відстежування клієнтом та іншими серверами для гешування актуальності контенту. Копія із кеш-пам'яті при запитах буде відправлятися до тих пір, поки вік документа не перевищує дати закінчення терміну. Тільки-но ця умова не виконується, кеш повинен звіритися з сервером на наявність оновленої версії документа та оновити відповідно свою локальну копію.

Expires – це старіший заголовок відповіді HTTP/1.0, у якому задається абсолютне значення дати. Він буде корисним тільки в тому випадку, якщо час на сервері відповідає часу клієнта, що дуже малоймовірно. Цей заголовок менш корисний у порівнянні з більш новим – Cache-Control: max-age=<s>, що з'явився в HTTP/1.1. Тут в max-age задається відносний вік (у секундах) з моменту створення відповіді. Таким чином, якщо термін дії документа повинен закінчитися по завершенні одного дня (* з моменту створення), то необхідно використовувати наступний запис: Cache-Control: max-age=86400.

Повторна перевірка на сервері

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

Комбінація повторної перевірки ресурсу на сервері та використання терміну дії документа – дуже ефективний механізм (* підвищення якості використання мережі); завдяки ньому стає можливим підтримування у розподілених системах актуальності копій ресурсів на основі дати закінчення терміну.

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

Етап повторної перевірки може бути здійснено за допомогою двох видів заголовків запиту: If-Modified-Since та If-None-Match. Перший використовується для здійснення перевірки на основі дати, тоді як у другому використовується  Entity-Tag (ETag) – хеш-значення контенту. У цих заголовках використовуються значення дати або ETag, отримані у попередній відповіді сервера. У випадку з заголовком If-Modified-Since використовується заголовок відповіді Last-Modified; для If-None-MatchETag.

Контроль можливості гешування

Термін дії документа повинен визначатися сервером, що відправляє документ. У разі новосного веб-сайту термін головної сторінки повинен скінчатися по завершенні одного дня (або іноді навіть кожного часу!). HTTP надає заголовки відповіді Cache-Control і Expires для встановлення дати закінчення терміну документів. Як вже зазначалося раніше, Expires заснований на використанні абсолютних значень дати і не є надійним рішенням для контролювання кешу.

Заголовок Cache-Control значно корисніший, і у ньому можуть бути використані декілька різних значень для визначення способу гешування відповіді клієнтом:

  • Cache-Control: no-cache: клієнту дозволено зберігати документ; проте він повинен звіряти актуальність  контенту з сервером при кожному запиті. Є сумісний з HTTP/1.0 заголовок – Pragma: no-cache, що працює таким же чином.
  • Cache-Control: no-store: це більш сувора директива клієнту зовсім не зберігати документ.
  • Cache-Control: must-revalidate: клієнт повинен пропустити визначення актуальності контенту та завжди виконувати повторну перевірку ресурсу на сервері. Не дозволяється використовувати відповідь із кеш-пам'яті у разі недоступності сервера.
  • Cache-Control: max-age: тут задається відносний вік (у секундах) з моменту створення відповіді.

Якщо сервер не відправляє заголовок Cache-Control з яким-небудь значенням, то клієнт має право використовувати свій власний евристичний алгоритм (* алгоритм оптимізації, що генерує припустиме, але не обов'язково оптимальне рішення) для визначення актуальності контенту.

Обмеження актуальності контенту з боку клієнта

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

  • Cache-Control: min-fresh=<s>: документ повинен бути дійсним як мінімум <s> секунд.
  • Cache-Control: max-stale або Cache-Control: max-stale=<s>: документ не може бути відправлено із кеш-пам'яті, якщо він застарів більше, ніж на <s> секунд.
  • Cache-Control: max-age=<s>: документ не може бути відправлено з кеш-пам'яті, якщо він знаходився там більше <s> секунд.
  • Cache-Control: no-cache або Pragma: no-cache: клієнт не буде приймати ресурс із кешу до того часу, поки не буде виконано його перевірку на стороні сервера.

Гешування в HTTP – це дуже цікава тема, і є дуже складні алгоритми для керування контентом у кеш-пам'яті. За детальним розглядом цієї теми звертайтеся до Caching section специфікації HTTP.


Резюме

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

Посилання

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.