Навчальний посібник з кешування, частина 1
Досить докладний та цікавий виклад матеріалу, що стосується кешу та використання.
Автор, Mark Nottingham, - визнаний експерт у галузі HTTP-протоколу та веб-кешування. Є головою IETF HTTPbis Working Group. Брав участь у редагуванні HTTP/1.1, part. 6: Caching. На даний момент бере участь у розробці HTTP/2.0.
Від перекладача: про помилки та неточності прохання повідомляти в особу. Дякую.
Існує дві основні причини, з яких використовується веб-кеш:
1.Зменшення часу очікування— оскільки дані за запитом беруться з кеша (який знаходиться “ближче” до клієнта), потрібно менше часу для отримання та відображення контенту на стороні клієнта. Це робить Інтернет більш чуйним (прим. перекладача - "чуйним" у контексті швидкості реакції на запит, а не емоційно).
2.Зниження мережевого трафіку- повторне використання контенту знижує обсяг даних, що передаються клієнту. Це, у свою чергу, економить гроші, якщо клієнт платить за трафік, і зберігає низькі та більш гнучкі вимоги до пропускної спроможності каналу.
Види веб-кешів
Кеш браузера (Browser cache)
Цей кеш особливо корисний, коли користувач натискає кнопку "Назад" або клацає на посилання, щоб побачити сторінку, яку щойно переглядав. Також, якщо ви використовуєте ті самі зображення навігації на вашому сайті, вони будуть вибиратися з браузерного кеша майже миттєво.
Проксі-кеш (Proxy cache)
Проксі-кеш працює за аналогічним принципом, але у значно більшому масштабі. Проксі обслуговують сотні чи тисячі користувачів; великі корпорації та інтернет-провайдери часто налаштовують їх на своїх файрволах або використовують як окремі пристрої (intermediaries).
Проксі-кеші є свого роду загальною кеш-пам'яттю (shared cache): замість обслуговування однієї людини, вони працюють з великою кількістю користувачів і тому дуже гарні у скороченні часу очікування та мережного трафіку. В основному через те, що популярний контент запитується багато разів.
Кеш-шлюз (Gateway Cache)
Також відомі як "реверсивні проксі-кеші" (reverse proxy cache) або "сурогати" (surrogate cache) шлюзи теж є посередниками, але замість того, щоб використовувати системні адміністратори для збереження пропускної спроможності каналу, вони (шлюзи) зазвичай використовуються веб-майстрами для того, щоб зробити їх сайти більш масштабованими, надійними та ефективними.
Запити можуть бути перенаправлені на шлюзи рядом методів, але зазвичай використовується балансувальник навантаження у тій чи іншій формі.
Мережі доставки контенту (content delivery networks, CDN) розповсюджують шлюзи по всьому інтернету (або деякій його частині) та віддають кешований контент зацікавленим веб-сайтам. Speedera та Akamai є прикладами CDN.
Цей навчальний посібник здебільшого сфокусований на браузерних кешах та проксі, але деяка інформація підходить також і тим, кому цікаві шлюзи.
Чому я маю ним користуватися
Кешування є однією з найнеправильніших технологій в інтернеті. Веб-майстри, зокрема, бояться втратити контроль над їхнім сайтом, тому що проксі можуть "приховати" їх користувачів, зробивши складним спостереження відвідуваності.
На нещастя для них (веб-майстрів), навіть якби веб-кеша не існувало, є занадто багато змінних в інтернеті, щоб гарантувати, що власники сайтів зможуть отримати точну картину того, як користувачі звертаються до сайту. Якщо це для васвеликою проблемою, це керівництво навчить вас як отримати необхідну статистику, не роблячи ваш сайт "кешененависником".
Іншою проблемою є те, що кеш може зберігати вміст, застарілий або прострочений.
З іншого боку, якщо ви відповідально підходите до проектування вашого веб-сайту, кеш може допомогти з більш швидким завантаженням та збереженням навантаження на сервер та інтернет-з'єднання в межах допустимого. Різниця може бути вражаючою: завантаження сайту, що не працює з кешем, може вимагати кількох секунд; у той час як переваги використання кешування можуть зробити її миттєвою. Користувачі гідно оцінять малий час завантаження сайту і, можливо, відвідуватимуть його частіше.
CDN, з цієї точки зору, є цікавою розробкою, тому що, на відміну від багатьох проксі-кешів, їх шлюзи приведені у відповідність до інтересів веб-сайту, що кешується. Тим не менш, навіть тоді, коли ви використовуєте CDN, ви все одно повинні враховувати, що там буде проксі та подальше кешування у браузері.
Резюмуючи, проксі та кеш браузера будуть використовуватися, подобається вам це чи ні. Пам'ятайте, якщо ви не налаштуєте ваш сайт для коректного кешування, він використовуватиме налаштування кешу за замовчуванням.
Як працює веб-кеш
Всі види кешів мають певний набір правил, які вони використовують, щоб визначити, коли брати контент з кешу, якщо він доступний. Деякі з цих правил встановлені протоколами (HTTP 1.0/HTTP 1.1), деякі – адміністраторами кешу (користувачами браузера або адміністраторами проксі).
Взагалі кажучи, це найзагальніші правила (не хвилюйтеся, якщо ви не розумієте деталі, вони будуть пояснені нижче):
Свіжий контент береться безпосередньо з кешу, безперевірки з сервера.
Якщо у відповіді немає валідатора ( ETag або Last-Modified заголовок), і він не містить жодної явної інформації про свіжість, контент, зазвичай (але не завжди) буде вважатися некешируемым.
Свіжість(freshness) тавалідація(validation) є найбільш важливими способами, за допомогою яких кеш працює з контентом. Свіжий контент буде доступний миттєво з кешу; валідний вміст уникне повторного відправлення всіх пакетів, якщо він не був змінений.