Протоколи кешування web-трафіку у локальних мережах
Автори: Кузьмін О., Городечний О.
Вступ
Зростання обсягу послуг, що надаються через Internet, призводить до зростання відповідного трафіку інформації. Це призводить, своєю чергою, до зростання часу відповіді на запити до web-систем. Тому розробляються нові технології доступу, які забезпечують зменшення часу відповіді. Однією з таких технологій є застосування мережевого кешування. Тому в цій статті наведено комплексне дослідження чотирьох кешуючих веб-протоколів. Розглядаються такі протоколи, як: Internet Cache Protocol (ICP), Cache Digest Protocol (CADP), Cache Array Resolution Protocol (CARP) і Web Cache Coordination Protocol (WCCP). Метою цієї роботи є аналіз протоколів кешування web-трафіку та висвітлення переваг і недоліків кожного з них.
Протоколи веб-кешування
Протоколи веб-кешування можна класифікувати [1] на основі повідомлень, на основі каталогу, хеш-основі або маршрутизаторній основі. Прикладом протоколу на основі повідомлень є ICP. Протоколи на основі каталогу містять кеш-збірники. Прикладом є протокол CADP. До протоколів на хеш-основі можна зарахувати CARP. Прикладом протоколу на маршрутизаторній основі є протокол координаційного веб-кешування WCCP. В табл. 2 наведена порівняльна оцінка розглянутих нижче протоколів.
ICP
Кеш, у якому відсутній запитуваний об'єкт, може перевірити його наявність в іншому кеші. Такий метод взаємодії відрізняється від традиційного запиту ресурсів у вихідного сервера. У цьому випадку кеші є як джерелами, так і одержувачами повідомлень. Для цього необхідний спеціальний протокол міжкешевої взаємодії. Одним з перших протоколів для взаємодії кешів був ICP. Цей протокол є прикладом протоколу запитів. Лист, надісланий клієнтським кешем, є запитом про наявність кешованої копії певної відповіді, необхідної клієнтському кешу. Популярність ICP основана на тому, що він реалізований у вільно поширюваному і широко використовуваному кешуючому проксі-сервері.
Протокол ICP виявився придатним і для ієрархічних наборів кешей, що взаємодіють на кожному рівні ієрархії і мають загального батька. При переміщенні вгору по ієрархії ця схема повторюється аж до центрального кешу, який може бути під’єднаний до іншого центрального кешу в іншій локальній мережі за такою самою схемою. Центральний кеш може мати як батька регіональний кеш, а набір регіональних кешей може як батька мати національний кеш. Припустимо, що деякий кеш (назвемо його вихідним) не має запитуваного ресурсу. Він посилає ICP-запит (зазвичай це UDP-повідомлення) до всіх своїх сусідів на цьому рівні ієрархії одночасно. Успішна відповідь вказуватиме на наявність необхідного ресурсу в одному з кешів цього рівня, і вихідний кеш може запросити цей ресурс, використовуючи протокол HTTP. Якщо в кешах цього рівня ієрархії відсутній такий ресурс, то вихідний кеш надішле ICP-запит батьківському кешу. Можливий також варіант, коли відповіді від кешів цього рівня ієрархії не надійдуть за певний інтервал часу. Це ініціює у вихідному кеші подію, пов'язану з тайм-аутом. Батьківський кеш повторює зазначену процедуру. Якщо від кешів усіх рівнів не надійде відповіді, то початковий кеш запросить цей ресурс у відповідного сервера. Припущення, що лежить в основі ICP-протоколу, полягає в тому, що передавання кешам набору ICP-запитів стільки разів, скільки є рівнів у ієрархії, виконується швидше ніж взаємодія з відповідним сервером. Крім того, деяка оптимізація допомагає скоротити загальні витрати. Наприклад, коли відповідь повертається від сервера або кеша в ієрархії, то проміжні кеші можуть зберігати відповідь для майбутнього використання.
Хоча регіональні та національні проксі-сервери можуть скоротити відстань, яку проходять замовлені ресурси для великої кількості користувачів, переходи між рівнями ієрархії можуть знижувати продуктивність. Якщо на поточному рівні ієрархії ресурс не знайдений, то це дає додатковий внесок у загальну затримку. Навіть якщо ресурс буде виявлений в національному проксі-сервері, то це все одно зумовить затримку, пов'язану з передаванням ресурсу клієнту, який зробив запит.
Структура ICP-запиту така:
ICP-запит складається з двох розділів (табл. 1):
1. Заголовок (розмір якого 20 октетів (п'ять 32-бітних слів))
2. Дані (розмір яких змінний, обмежений максимальним розміром ICP-запиту у 16384 октетів, разом із заголовком).
ICP заголовок складається із семи полів, два з яких є додатковими (“Параметри” і “Варіант даних”) і необов’язковими.
CADP
Протокол Cache Digest Protocol (CADP) є розширенням протоколу ICP. Основна його м та полягає в обміні дайджестами кешування ресурсів. Дайджест – це стислий опис кешованих ресурсів і визначає наявність набору ресурсів у кеші. Коли кеш має дайджести всіх інших кешей на цьому рівні ієрархії, то можна швидко перевірити наявність шуканого об'єкта. Якщо пошук у дайджесті виявляється успішним, то кеш стає кандидатом на отримання запиту на шуканий об'єкт. Запитуваний кеш може навіть вибрати з декількох кешей, для яких пошук виявився успішним. Якщо перевірка за дайджестом виявилася невдалою, то взаємодії з кешем не відбувається. В результаті скорочується кількість повідомлень, які розсилаються кешам одного ієрархічного рівня.
Однією з очевидних проблем цього протоколу є старіння дайджестів та пересилання помилкових даних. Об'єкт може бути вилучений з кешу вже після створення дайджесту. Іншою проблемою є розмір набору дайджестів та обмін дайджестами на заданому рівні ієрархії кешів. За наявності великої кількості кешів розмір набору дайджестів стає дуже великим. Виконані дослідження дали змогу зменшити розміри дайджестів.
Для обміну дайджестом між кешами може використовуватися схема, прийнята в ICP й основана на протоколі UDP. Однак для надійності обмін дайджестами здійснюється за допомогою HTTP-повідомлень поверх TCP. Дайджести можуть розглядатися як звичайні ресурси, до яких для перевірки актуальності застосовна технологія поновлення ресурсів HTTP (за допомогою заголовків Expire і If-Modified-Since).
CARP
Протокол Cache Array Resolution Protocol (CARP) визначає механізм, за допомогою якого група кешуючих проксі-серверів може функціонувати як єдиний логічний кеш. Набір відповідей, який колективно кешується групою проксі-серверів, трактується як один великий кеш. Спеціальні хеш-функції використовуються для кодування URL ресурсів, що зберігаються в різних кешах. Клієнт, який намагається знайти кешований ресурс, може надіслати запит відповідного кешу, кодований за допомогою цієї функції. Хеш-функція перетворює запитаний URL та ідентифікатор потрібного проксі-сервера, створюючи спеціальний шлях виконання запиту. Порівняно з ICP протокол CARP має строго певний шлях вирішення запиту, завдяки чому не потрібне додаткове надсилання запитів. Порівняно з ICP в CARP використовується набагато менше повторних запитів. CARP використовує як HTTP, так і виклик віддалених процедур для взаємодії проксі-серверів. CARP пов'язує проксі-сервер з коефіцієнтом навантаження, що може бути взятий до уваги до того, як запит буде надісланий цьому проксі-серверу. CARP реалізований основними виробниками програмних продуктів.
Коли конфігурацію кешуючої системи змінюють, видаляючи або додаючи проксі-сервер, то кешовані URL повинні бути реорганізовані. При заміні вмісту кеша хешовані значення необхідно обчислити знову. URL не можуть бути подані в декількох кешуючих проксі-серверах, і, отже, вирівнювання навантаження проксі-серверів ускладнене. Висока популярність деяких ресурсів призводить до того, що лише невелика підмножина кешів одержує основну частину запитів. Якщо пошук кешованої відповіді виявляється невдалим, то на деякий час проксі-сервер повинен вважатися неактивним.
WCCP
На відміну від високорівневих протоколів типу ICP і CARP, протокол Web Cache Coordination Protocol (WCCP) є координаційним механізмом, який пов'язаний з мережевим рівнем. Призначенням WCCP є перехоплення HTTP-запитів і переадресації їх кешу. Оскільки запит може виявитися відкинутим (якщо кеш через деяку причину буде недоступний), то необхідний координаційний механізм. Завдання координатора полягає у вирівнюванні навантаження між безліччю кешів. Періодично перевіряючи працездатність кешу, ця технологія гарантує, що пакети не будуть послані непрацездатному кешу.
Такий координаційний механізм закладений в ядро протоколу WCCP, що реалізований як частина технології Cisco Cache Engine. Цей механізм налаштований на отримання Web-запитів, перескерованих йому маршрутизатором. Маршрутизатор, який підтримує протокол WCCP, здатний проаналізувати всі IP-заголовки і ТСР-пакети, що надходять на 80-й порт (стандартний порт HTTP), і перескерувати їх кешуючому серверу. Крім того, WCCP-маршрутизатор періодично зв'язується з кешуючим сервером, щоб переконатися в його доступності.
Сьогодні є дві версії протоколу:
Версія 1.
- Тільки один роутер обслуговує групу пристроїв.
- Підтримує тільки HTTP перенаправлення трафіку.
- Використовує протокол GRE, щоб запобігти модифікації пакетів.
- Роутери та пристрої зберігання кешу з'єднуються один з одним за протоколом UDP.
Версія 2.
- Дає змогу використовувати до 32 роутерів (серверів WCCP).
- Підтримує до 32 пристроїв/прискорювачів (клієнтів WCCP).
- Підтримує будь-які IP і TCP протоколи.
- Підтримує до 256 сервіc-груп (груп обслуговування).
- Додано шифрування з використанням хешу MD5.
До основних функцій WCCP належать:
- Реєстрація.
- Призначення.
- Редирект від роутера до пристрою зберігання кешу.
- Повернення від пристрою зберігання кешу до роутера.
Висновки
Розглянуто поширені протоколи кешування web-трафіку в локальних мережах. Описані основні їхні властивості, переваги та недоліки. Аналіз параметрів наведених протоколів дає підстави стверджувати, що кожен протокол треба використовувати там, де він буде найдоцільнішим, тобто не буде надлишковості у використанні (це особливо пов’язано з WCCP протоколом) і задовольнятиме поставлені вимоги.