Що таке кешовані дані? Що означає очищення кеш-пам'яті та що це робить?

По-перше, що таке кеш?

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

В інформатиці ці "матеріали" називаються ресурсами, де ресурси - це сценарії, код та вміст документа. Останній іноді більш конкретно називають "активами", такими як текст, статичні дані, носії інформації та гіперпосилання, але тут я просто використаю один термін " ресурси" .

Різниця між кешем та іншими типами сховищ

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

Ця стаття розгляне два поширені методи кешування: кешування браузера та мережі доставки вмісту (CDN).

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

Наприклад, Amazon Glacier - це сховище даних, призначене для дешевого зберігання даних, але не швидкого їх отримання. База даних SQL, навпаки, розроблена для гнучкості, оновлення та швидкості, але рідко є дешевою і зазвичай не такою швидкою, як кеш.

Кеш браузера: кеш пам'яті

Кеш пам’яті зберігає ресурси локально на комп’ютері, де працює браузер. Поки браузер активний, отримані ресурси зберігатимуться у фізичній пам’яті (ОЗУ) комп’ютера, а також, можливо, і на жорсткому диску.

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

Швидкість пошуку ресурсів має суттєве значення, але, як і необхідність, щоб ресурси були свіжими. Несвіжий ресурс - це застарілий ресурс, який може бути недійсним.

Частина роботи браузера полягає в тому, щоб визначити, які кешовані ресурси застаріли, та відновити ті, які є. Оскільки веб-сторінка, як правило, має майські ресурси, в кеші зазвичай міститься застаріла та свіжа версії.

Звідки браузер знає, що застаріло в кеш-пам’яті?

Відповідь не проста, але є два основних підходи: знищення кешу та поля заголовка HTTP.

знищення кешу

Італійці

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

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

Скажімо, у мене є веб-сторінка, на www.foobar.com/about.htmlякій написано все про foobar.com, про що ви коли-небудь хотіли б знати. Після того, як ви відвідаєте цю сторінку, вона та ресурси, пов’язані з нею, кешуються браузером.

Пізніше foobar.com викуповується корпорацією Quxbaz, і вміст сторінки про сторінку зазнає значних змін. У кеші браузера не буде нового вмісту, проте він все ще може вважати вміст, який він має, поточним, і ніколи не намагатиметься відновити його.

Що ви, веб-адміністратор Quxbaz, робите, щоб увесь новий вміст був витіснений?

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

Таким чином, змінивши URI ресурсу з www.foobar.com/about.htmlна www.foobar.com/about2.html(або на www.quxbaz.com/about.html), браузер не знайде жодного ресурсу кешу, пов’язаного з цим URI, і виконає повне завантаження з сервера. Ресурс може бути таким самим, як оригінал за старим URI, але браузер цього не знає.

Однак вам не потрібно міняти назву сторінки. Оскільки URI також включає в себе рядок запиту , за визначенням, ви можете додати параметр версії в URI: www.foobar.com/about.html?v=2hef9eb1.

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

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

Поля заголовка HTTP

Кожен запит на ресурс містить певну метаінформацію, відому як заголовок. І навпаки, кожна відповідь також має інформацію заголовка, пов’язану з нею.

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

Запити HEAD та умовні запити

Запит HEAD схожий на усічений запит GET або запит POST. Замість запиту повного ресурсу, запит HEAD запитує лише поля заголовка, які в іншому випадку будуть повернуті за повним запитом.

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

Запити HEAD часто використовуються для перевірки дійсності серверного ресурсу (тобто, чи існує ресурс все ще, і якщо так, чи оновлений він з часу останнього доступу до нього?). Браузер використовуватиме те, що знаходиться в кеші, якщо запит HEAD вказує, що ресурс є дійсним, інакше він виконає повний запит GET або POST та оновить кеш із тим, що повертається.

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

Якщо це так, сервер повертає відповідь 304 із лише інформацією заголовка ресурсу, а не тілом ресурсу (даними). Якщо кеш браузера визначений застарілим, тоді сервер поверне повну відповідь 200 ОК.

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

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

Керування кешем

Під час відповіді на запит сервер надсилає браузеру поля заголовка із зазначенням поведінки, яку слід адаптувати під час кешування. Якщо я завантажую сторінку в //en.wikipedia.org/wiki/Uniform_Resource_Identifier, відповідь містить це у своєму заголовку:

cache-control: private, s-maxage=0, max-age=0, must-revalidate 

private означає, що лише браузер повинен кешувати вміст документа.

s-maxage та max-age встановлені на 0 . Значення s-maxage призначено для проксі-серверів з кешами, тоді як max-age призначений для браузера. Ефект від встановлення максимального віку лише в тому, що кешований ресурс закінчується негайно, але він все ще може бути використаний (навіть несвіжий) під час перезавантаження сторінки під час одного сеансу браузера.

Несвіжий ресурс може бути повторно перевірений через запит HEAD, за яким може йти запит GET або POST, залежно від відповіді. Обов'язково перевірити ще раз директиву команди браузера перевірити кеш ресурс , якщо він є застарілим.

Оскільки в цьому випадку для max-age встановлено значення 0 , кешований ресурс одразу отримує застарілість. Поєднання двох директив еквівалентно єдиній директиві no-cache .

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

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

Електронний тег

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

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

Інші теги заголовка, що впливають на кешування

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

expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT 

Тут термін дії закінчується нульовою датою (історично, з операційної системи UNIX). Це означає, що ресурс закінчується негайно, як і max-age = 0 . Остання зміна повідомляє браузеру про те, коли було зроблено останнє оновлення ресурсу, яке він потім може використовувати, щоб вирішити, чи слід його перезавантажувати, а не використовувати значення кешу.

Примусове оновлення кешу з браузера

Що важко перезавантажити?

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

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

Браузер заздалегідь не знає, що це станеться, і коли це станеться, пізніші запити (ініційовані скриптами, як правило) все одно використовуватимуть кешовані копії цих ресурсів, якщо такі є.

Що таке чіткий кеш і жорстке перезавантаження?

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

Мережі доставки вмісту: кеш-пам’ять, розташована в географічному напрямку

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

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

CDN отримує свої ресурси через Internet Exchange Point (IXP), вузли, які є частиною основи Інтернету (великими літерами). Існують кроки, щоб налаштувати маршрутизацію запитів для переходу на CDN замість хост-сервера. Наступним кроком є ​​переконатися, що CDN містить поточний вміст вашого веб-сайту.

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

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