Какое правило следует соблюдать при работе с кешем при тестировании
Обновлено: 21.11.2024
На этом этапе тестер проверяет, правильно ли приложение указывает браузеру не сохранять конфиденциальные данные.
Браузеры могут хранить информацию в целях кэширования и истории. Кэширование используется для повышения производительности, чтобы ранее отображавшуюся информацию не нужно было загружать повторно. Механизмы истории используются для удобства пользователя, поэтому пользователь может видеть именно то, что он видел в момент извлечения ресурса. Если пользователю отображается конфиденциальная информация (например, его адрес, данные кредитной карты, номер социального страхования или имя пользователя), то эта информация может быть сохранена в целях кэширования или истории и, следовательно, может быть извлечена путем изучения кеша браузера или просто нажав кнопку "Назад" в браузере.
Цели тестирования
- Проверьте, хранит ли приложение конфиденциальную информацию на стороне клиента.
- Проверьте, возможен ли доступ без авторизации.
Как тестировать
История браузера
Первый и самый простой тест состоит из ввода конфиденциальной информации в приложение и выхода из системы. Затем тестер нажимает кнопку "Назад" в браузере, чтобы проверить, можно ли получить доступ к ранее отображаемой конфиденциальной информации без аутентификации.
Если при нажатии кнопки "Назад" тестер может получить доступ к предыдущим страницам, но не может получить доступ к новым, то это не проблема аутентификации, а проблема истории браузера. Если эти страницы содержат конфиденциальные данные, значит, приложение не запрещало браузеру их сохранять.
Аутентификация не обязательно должна участвовать в тестировании. Например, когда пользователь вводит свой адрес электронной почты, чтобы подписаться на информационный бюллетень, эту информацию можно получить, если она не будет правильно обработана.
Кнопку "Назад" можно запретить показывать конфиденциальные данные. Это можно сделать следующим образом:
Кэш браузера
- Cache-Control: без кеша, без сохранения
- Срок действия: 0
- Прагма: без кеша
Эти директивы, как правило, надежны, хотя для заголовка Cache-Control могут потребоваться дополнительные флаги, чтобы лучше предотвратить постоянно связанные файлы в файловой системе. К ним относятся:
- Cache-Control: обязательная повторная проверка, max-age=0, s-maxage=0
Например, если тестировщики тестируют приложение для электронной коммерции, они должны найти все страницы, содержащие номер кредитной карты или другую финансовую информацию, и убедиться, что на всех этих страницах соблюдается директива об отсутствии кэширования. Если они находят страницы, содержащие важную информацию, но не указывающие браузеру не кэшировать их содержимое, они знают, что конфиденциальная информация будет храниться на диске, и они могут перепроверить это, просто отыскав страницу в кеше браузера. .
Точное место хранения этой информации зависит от операционной системы клиента и используемого браузера. Вот несколько примеров:
- Mozilla Firefox:
- Unix/Linux: ~/.cache/mozilla/firefox/
- Windows: C:\Users\\AppData\Local\Mozilla\Firefox\Profiles\
- C:\Users\\AppData\Local\Microsoft\Windows\INetCache\
- Windows: C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Cache
- Unix/Linux: ~/.cache/google-chrome
Просмотр кэшированной информации
Firefox предоставляет функции для просмотра кэшированной информации, что может быть полезно вам как тестировщику. Конечно, отрасль также выпускает различные расширения и внешние приложения, которые могут вам понадобиться для Chrome, Internet Explorer или Edge.
Сведения о кеше также доступны через инструменты разработчика в большинстве современных браузеров, таких как Firefox, Chrome и Edge. В Firefox также можно использовать URL-адрес about:cache для проверки сведений о кеше.
Проверить обработку для мобильных браузеров
Для мобильных браузеров обработка директив кеша может быть совершенно другой. Поэтому тестировщики должны начать новый сеанс просмотра с чистыми кэшами и воспользоваться преимуществами таких функций, как режим устройства Chrome или режим адаптивного дизайна Firefox, чтобы повторно протестировать или отдельно протестировать концепции, изложенные выше.
Кроме того, личные прокси-серверы, такие как ZAP и Burp Suite, позволяют тестировщику указать, какой User-Agent должен быть отправлен их поисковыми роботами/краулерами. Это можно настроить так, чтобы оно соответствовало строке User-Agent мобильного браузера, и использовать для просмотра того, какие директивы кэширования отправляются тестируемым приложением.
Тестирование серого ящика
Методология тестирования аналогична случаю черного ящика, поскольку в обоих сценариях тестировщики имеют полный доступ к заголовкам ответа сервера и к HTML-коду. Однако при тестировании серого ящика у тестировщика может быть доступ к учетным данным учетной записи, что позволит ему тестировать конфиденциальные страницы, доступные только пользователям, прошедшим проверку подлинности.
Инструменты
Ссылки
Технические документы
Фонд OWASP ® работает над повышением безопасности программного обеспечения с помощью своих проектов программного обеспечения с открытым исходным кодом под руководством сообщества, сотен отделений по всему миру, десятков тысяч членов и проведения местных и глобальных конференций.
Что касается кэширования API, мы обнаружили, что многие разработчики хотят получить более глубокое представление о том, как оно работает и какие преимущества оно предоставляет. Мы также заметили, что внедрение кэширования API было ограничено отсутствием инструментов для определения и управления правилами кэширования для каждого API (исторически было непрактично устанавливать правила кэширования для нескольких API, поскольку возможности кэширования ответов сильно различаются). .
В этой записи блога будет рассмотрено несколько различных сценариев реализации, которые помогут вам понять преимущества кэширования ответов API. Если вам уже интересно, что мы обнаружили, изучая эти сценарии, давайте дадим вам ключевой результат:
Исходя из методики тестирования, описанной ниже, мы заметили, что тестовый API доставлялся на 21 % быстрее при кэшировании.
Кроме того, в этой записи блога мы расскажем, как наш новый шлюз API Akamai предоставляет разработчикам API инструменты, необходимые для адаптации независимых политик кэширования для каждого API. Короче говоря, API Gateway значительно упрощает процесс использования преимуществ кэширования API, поэтому вы можете предоставлять больше данных за то же время.
Ключевые сценарии кэширования, которые следует учитывать:
- Локально без кэширования на уровне приложения
- Локально с кэшированием на уровне приложения
- IaaS (Digital Ocean) без кэширования на уровне приложений
- IaaS с кэшированием на уровне приложения
- Akamai без кэширования на уровне приложения
- Akamai с кэшированием на уровне приложения
- Кэширование Akamai и отсутствие кэширования на уровне приложения
- Кэширование Akamai с кэшированием на уровне приложения
Мы будем использовать инструмент нагрузочного тестирования и сравнительного анализа Siege для создания запросов к образцу API. Если вы не знакомы с Siege, это инструмент с открытым исходным кодом, используемый для определения нагрузки, которую приложение может выдержать при получении пиков трафика. У него есть и более гнусные применения, например, злоумышленники пытаются DDoS-атак на сервер с объемным трафиком. Если оставить в стороне более вредоносные варианты использования, это отличный инструмент для стресс-тестирования одного или нескольких URL-адресов API.
Запуск осады выглядит так, как показано на снимке экрана ниже: запрос за запросом по заданному URL-адресу:
API, который мы будем использовать для тестирования, представляет собой простой NodeJS API с написанной мной серверной частью MongoDB, которая возвращает пригодные для адаптации данные cat. В конце концов, это Интернет, а Интернет любит кошек, верно? Это базовый API на основе Express с использованием mongoose, bodyParser и т. д.:
Мы будем тестировать простой запрос GET, который возвращает ответ JSON размером 6,59 КБ длиной 227 строк, состоящий из приемлемых данных о кошках:
Ниже приведены заголовки, возвращаемые при выполнении команды GET. Обратите внимание, что мы поддерживаем подключение к серверу и что GZIP включен для уменьшения размера полезной нагрузки:
Для нашего первого теста давайте запустим Siege с 5 одновременными пользователями в течение 5 минут с локального хоста на сервере Express, работающем на локальном хосте — без подключения к сети. Мы хотим, чтобы любые задержки, связанные с сетью, не учитывались, чтобы установить базовый уровень. Вызов командной строки Siege указывает Siege работать в течение 5 минут, имитируя 5 одновременных пользователей, отправляющих запросы GET:
Результаты первого запуска Siege включают данные о количестве попаданий (транзакций), длительности выполнения теста, количестве переданных данных, частоте транзакций, а также количестве успешных и неудачных транзакций:
Это послужит нашим (несколько искусственным) исходным уровнем.
Теперь давайте добавим кэширование на уровне приложения. Мы собираемся использовать пакет apicache NPM, чтобы добавить в наше приложение простое кэширование ответов в памяти. После добавления пакета («npm install apicache») мы добавляем несколько строк конфигурации, чтобы включить его:
Теперь мы включим его для одного маршрута «get_all_cats». Обратите внимание, что исходный маршрут здесь закомментирован, а копия этого маршрута теперь использует apicache с директивой кэшировать ответ на 5 минут:
Мы будем переключаться между этими двумя маршрутами по мере включения и отключения кэширования для различных тестовых прогонов далее в этой статье. Теперь сервер NodeJS будет перезапущен, чтобы очистить память от всего, что может запутать наши тесты. Если вы делаете запрос к серверу, он показывает, что кэширование ответов действительно включено благодаря наличию нового заголовка: cache-control. Значение максимального возраста этого заголовка установлено на 300 секунд (5 минут, которые мы указали в приложении):
Вы также можете включить отладку модуля apicache, чтобы убедиться, что он работает:
Обратите внимание, что первый запрос потребовал 31 мс, чтобы вернуть данные клиенту, но последующие запросы не заняли столько времени. Первый запрос является полным запросом, но все последующие запросы обслуживались из кеша памяти и возвращались клиенту менее чем за 0,5 мс. Это основное преимущество кэширования.
Теперь давайте повторно запустим ту же самую команду Siege, что и в первый раз, чтобы увидеть, есть ли разница с кэшированием на основе приложений:
Вау! Кэширование на основе приложений имеет ОГРОМНОЕ значение. За те же пять минут затраченного времени мы обслужили на 60 % больше обращений с включенным кэшированием. При этом мы передавали больше данных, но смогли обработать 449 транзакций в секунду по сравнению с исходными 179 транзакциями в секунду — еще один скачок на 60%! Это довольно значительная отдача от затраченных средств, если просто добавить кеширование в API.
Теперь добавим в уравнение сеть. Для целей этой статьи я создал сервер Digital Ocean Droplet с 1 ГБ ОЗУ, 1 виртуальным ЦП и 25 ГБ SSD, работающим в их центре обработки данных в Нью-Йорке. Это минимальный аппаратный уровень, предлагаемый Digital Ocean для виртуальной машины, и я выбрал его намеренно; это позволит нам увидеть, что кэширование дает API в среде с аппаратными ограничениями. Я развернул API кошек NodeJS на сервере Droplet с Nginx впереди для прокси-запросов с порта 80 на порт 3000 NodeJS. Также запущен локальный экземпляр MongoDB, который действует как серверная часть для API. Никакое другое программное обеспечение не запущено на сервере.
Давайте отправим серверу запрос на просмотр заголовков ответов, которые он отправляет обратно. По наличию баннера Nginx видно, что мы больше не работаем на локальном хосте:
Теперь давайте повторно запустим команду Siege для сервера Digital Ocean (по IP-адресу) с идентичным вызовом командной строки Siege:
Ниже показан результат запуска Siege на VPS Digital Ocean без кэширования ответов API:
Обратите внимание на то, что вместо локального запуска этого теста вместо запуска его у поставщика инфраструктуры как услуги:
- Количество обращений и транзакций сократилось на 35 %.
- Мы впервые видим неудачные транзакции
Тридцать пять процентов – это довольно много, но вполне ожидаемо при запуске кода в многопользовательском облачном провайдере. Теперь давайте посмотрим, что может дать нам в Digital Ocean включение apicache. Мы включаем кэширование ответов в API, как описано ранее. Чтобы убедиться, что кеширование включено, давайте сделаем один запрос к API, чтобы убедиться, что кеширование ответов включено в Digital Ocean:
Снова мы видим наличие заголовка cache-control со значением 5 минут (т. е. 300 секунд), поэтому давайте повторно запустим ту же команду Siege для сервера Digital Ocean с включенным кэшированием приложений:
ВАУ! На этот раз включение кэширования позволяет нам совершать БОЛЬШЕ 4932 транзакций и дает нам возможность обслуживать эти транзакции на 21% быстрее (63/с против 80/с). Мы доставили больше данных за то же самое время, так как серверу не приходилось каждый раз повторно генерировать ответ. Это наглядно демонстрирует ценность включения кэширования ответов API везде, где это возможно.
Зачем кэшировать ответы API, как я только что показал? Вот семь причин:
- Большинство операций API — это операции чтения.
- Если данные не меняются, зачем их создавать?
- Поставщики облачных услуг взимают плату в зависимости от количества операций ввода-вывода в секунду и размера экземпляра. Какую вычислительную мощность вы могли бы отключить, заменив ее кэшированием?
- Вы можете уменьшить сетевой трафик.
- Вы можете сократить затраты на запросы к базе данных/вычисления.
- Вы можете отправить кешированный устаревший ответ в случае сбоя источника.
- Вы можете меньше полагаться на ограничение скорости (т. е. не отказывать действительным потребителям API!)
Вашим следующим вопросом может быть: "ЧТО мне кэшировать?" Вот несколько общих рекомендаций:
Поскольку возможность кэширования будет сильно различаться в зависимости от вашего портфеля API, крайне важно реализовать стратегию кэширования на основе отдельного API. Один размер не подходит для всех! И здесь Akamai API Gateway действительно сияет: одна из необычных особенностей API Gateway заключается в том, что он позволяет каждому разработчику API определять правила кэширования на независимой основе. Шлюз API не зависит от набора правил кэширования на уровне домена, поэтому каждый разработчик API имеет полную автономию для оптимизации доставки своего контента.
Это первая из двух статей о кэшировании API и шлюзе API. Я рекомендую вам прочитать второй пост, который основывается на приведенной выше информации и обсуждает, как улучшить результаты кэширования приложений с помощью API Gateway. Кроме того, посетите домашнюю страницу API Gateway, чтобы найти много полезной информации.
Джефф Коста – старший менеджер по продуктам в Akamai Technologies.
Кэш браузера — это механизм, используемый браузерами для локального хранения ресурсов веб-страницы. Это увеличивает производительность, минимизирует потребление полосы пропускания и в целом обеспечивает более быструю работу. В этой статье мы объясним, как работает кеширование в браузере и как реализовать его на своем веб-сайте.
Что такое кеш браузера?
Кэш — это программный или аппаратный компонент, который используется для временного хранения значений для более быстрого доступа в будущем. Кэш браузера — это небольшая база данных файлов, содержащая загруженные ресурсы веб-страницы, такие как изображения, видео, CSS, Javascript и т. д. Основная идея заключается в следующем:
Браузер запрашивает некоторый контент с веб-сервера. Если содержимое отсутствует в кеше браузера, оно извлекается непосредственно с веб-сервера. Если контент ранее был кэширован, браузер обходит сервер и загружает контент непосредственно из кэша.
Контент считается устаревшим в зависимости от того, истек ли срок действия кэшированного контента. Свежий, с другой стороны, означает, что срок годности контента еще не истек и его можно обслуживать непосредственно из кеша браузера без участия сервера.
Термин "проверка" относится к содержимому, которое необходимо сверить с самой последней версией, имеющейся на сервере. Короче говоря, чтобы определить, устарел ли контент или нет. Аннулирование происходит, когда содержимое было удалено из кэша до истечения срока действия. Это может быть принудительно выполнено сервером в тех случаях, когда содержимое изменилось, и в браузере должна быть установлена самая последняя версия, чтобы не создавать никаких проблем.
Кеширование заголовков браузера
Набор правил, определяющих, что можно кэшировать, а что нет и как долго, называется политикой кэширования. Она реализуется владельцем веб-сайта с помощью кэширующих заголовков ответа. Хотя это может быть достигнуто разными способами, вам, вероятно, следует поначалу заниматься только управлением кэшем.
Управление кешем
- Без кеша
Предписывает вашему веб-браузеру не обращаться к кешу сразу, а проверять содержимое на сервере. Если он свежий, то его можно подать из тайника. - No-store
Указывает браузеру не кэшировать содержимое каким-либо образом. В основном он используется при работе с конфиденциальными данными или данными, которые часто меняются. - Общедоступно
Содержимое помечается как общедоступное, что означает, что оно может кэшироваться браузером и любыми посредниками (например, прокси-серверами и т. д.). - Частный
Используется для пометки содержимого как частного, что означает, что его может кэшировать только браузер, а не промежуточные прокси-серверы и тому подобное. Обычно это относится к пользовательским данным. - Max-age
Max-age представляет максимальное время в секундах, в течение которого контент может оставаться в кеше браузера, прежде чем клиенту потребуется его повторная проверка. В отличие от заголовка Expires, который мы вскоре рассмотрим, max-age определяет относительное значение в секундах с момента кэширования содержимого, а не абсолютную дату истечения срока действия. - S-maxage
Похож на max-age, но используется только для промежуточных кэшей. - Обязательная повторная проверка
Заставляет браузер повторно проверять контент каждый раз, когда он в нем нуждается, а не просто показывать его непосредственно из кеша браузера.
Это удобно на случай, если происходит прерывание сети. - Прокси-повторная проверка
Аналогичен обязательной повторной проверке, но применяется только к промежуточным кэшам. - no-transform
Предписывает браузеру не преобразовывать содержимое, полученное с сервера, каким-либо образом (обычно сжатие и т. д.).
Этаг
Заголовок ответа Etag используется для идентификации определенного ресурса. Каждый раз, когда изменяется определенный ресурс, создается новый Etag. Таким образом экономится пропускная способность, потому что веб-серверу не нужно давать полный ответ, если Etag не изменился. Следовательно, заголовок Etag включен по умолчанию в Nginx и Apache, а значения Etag генерируются автоматически, поэтому вам не нужно ничего указывать.
Разместите свой веб-сайт с помощью Pressidium
60-ДНЕВНАЯ ГАРАНТИЯ ВОЗВРАТА ДЕНЕГ
Истекает
Прагма
Как реализовать политику кэширования на вашем сайте
Есть два способа реализовать политику кэширования на вашем веб-сайте. Во-первых, определить заголовки ответа кэширования в конфигурации веб-сервера. Во-вторых, сделать это непосредственно в PHP. Ниже приведены примеры двух самых популярных веб-серверов, Apache2 и Nginx:
Апач2
Набор заголовка Cache-Control "max-age=84600, public"
Нгинкс
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ истекает через 365 дней;
add_header Cache-Control "public" ;
>Как видите, это довольно просто. В первом примере мы используем директиву apache2 FileMatch для сопоставления с определенным набором типов файлов (.ico, .pdf и т. д.) и делаем их общедоступными с максимальным возрастом 84600 секунд. Во втором мы снова сопоставляем определенные типы файлов, используя директиву местоположения nginx, и включаем максимальный возраст 365 дней. Мы также определяем их как «общедоступные» с помощью предложения добавления заголовка.
PHP
Если вы хотите добавить заголовки ответов непосредственно в свой код, просто используйте команду PHP header.
Как проверить, работает ли это
Вы можете легко проверить правила кэширования браузера, используя, например, веб-консоль Firefox или инструменты разработчика Chrome:
- Нажмите на значок гамбургера в правом верхнем углу.
- Выберите «Дополнительные инструменты» > «Инструменты разработчика».
- Введите URL-адрес в адресную строку и нажмите Enter.
Это означает, что ресурс был загружен автоматически из локального хранилища кеша, а не запрашивался с сервера.
В случаях, когда в заголовке Cache-Control указано условие «обязательна повторная проверка», код состояния будет 304 (не изменено). Это означает, что ваш браузер перепроверил ресурс на сервере, и сервер ответил, что содержимое не изменилось, поэтому его можно обслуживать из кеша браузера.
Чтобы отключить кеш, установите флажок "Отключить кеш" и нажмите "Обновить".
В этом случае вы видите, что код состояния равен 200 без каких-либо указаний на использование кеша. Браузер запросил ресурс с веб-сервера, и веб-сервер ответил, предоставив новую копию.
Заключение
Кэширование браузера и политики кэширования могут стать довольно сложными. Но начать экспериментировать с Cache-Control, как мы продемонстрировали, несложно. В большинстве случаев реализации «общей» политики кэширования для статических ресурсов достаточно, чтобы изменить производительность вашего сайта. Тем не менее, это добавляет дополнительный уровень «беспокойства» поверх многих других вещей, и мы считаем, что так не должно быть. Следуйте за нами в нашей следующей публикации, где мы покажем, как мы реализуем кеширование браузера в Pressidium, что избавляет от всех этих забот.
Проверка состояния кеша объекта на вашем веб-сайте может помочь при устранении неполадок. Вы можете использовать веб-интерфейс или команду curl (инструмент командной строки с открытым исходным кодом для передачи данных с синтаксисом URL с сервера или на сервер с использованием одного из многих поддерживаемых протоколов), чтобы проверить узлы кеша Fastly для кэшированного объекта, и вы можете использовать информация, предоставляемая для проверки состояния объектов, времени отклика и хэша контента.
Использование веб-интерфейса
Выполните следующие шаги, чтобы проверить состояние кеша объекта с помощью веб-интерфейса Fastly:
-
Войдите в веб-интерфейс Fastly и нажмите ссылку «Доставить».
Нажмите кнопку "Проверить кэш". Появится окно Проверить кэш.
Нажмите кнопку "Проверить кэш". Результаты отображаются в окне Check Cache.
Эту информацию можно использовать для проверки того, что одна и та же копия объекта хранится на всех наших серверах. Если хэш контента отличается на разных узлах, это обычно указывает на проблему с кэшированием.
Использование завитка
Самый простой способ узнать, кешируется ли ваш запрос в сети Fastly, — использовать функцию проверки кеша в веб-интерфейсе Fastly, но если вы предпочитаете утилиты командной строки, вы также можете использовать одну из двух команд curl для целей отладки. :
- простая команда curl, отображающая заголовки запроса и ответа для заданного объекта
- немного более сложная команда curl, которая использует заголовок Fastly-Debug для предоставления информации, обычно удаляемой простым curl
Использование простой команды curl
Следующая команда curl отображает заголовки запроса и ответа для данного объекта:
Эти выходные данные сообщают нам текущий возраст объекта в кеше. Он также показывает, что экранирование включено, поскольку в X-Served-By отображаются два узла кэша. Однако нас больше всего интересует вывод заголовка X-Cache. Правильно кэшированный объект отображает значение X-Cache: HIT , X-Cache: HIT, HIT , X-Cache: HIT, MISS или X-Cache: MISS, HIT .
Использование заголовка Fastly-Debug с curl
Заголовок Fastly-Debug предоставляет дополнительную информацию для отладки, предоставляя определенную информацию, которая обычно удаляется при использовании простой команды curl:
Поскольку присутствуют суррогатные ключи, они отображаются в заголовке Fastly-Debug. Как и в случае с простой командой curl, этот раздел вывода сообщает нам текущий возраст объекта в кеше. Кроме того, Fastly-Debug предоставляет определенные сведения о заголовке, чтобы облегчить отладку, как указано ниже.
Информация, предоставляемая заголовком Fastly-Debug
Fastly-Debug Path содержит информацию о том, какой кэш-сервер обрабатывает выборку и доставку объекта. Крайний POP появляется первым в последовательности, а экранный POP появляется вторым.
- D представляет, какой кеш по имени в Edge или Shield запускал vcl_deliver.
- F представляет, какой кеш по имени в Edge или Shield запускал vcl_fetch
- число, следующее за каждым конкретным именем сервера, представляет собой отметку времени в секундах
При включенном экранировании в этом заголовке обычно отображаются четыре кэш-сервера. В редких случаях, когда сервер кеша существует как пограничный и как экран в кластере для этого объекта, вы можете увидеть два или три кеша в списке.
Fastly-Debug-TTL предоставляет информацию о времени HIT и MISS.
- H представляет собой HIT, то есть объект был найден в кеше.
- M представляет собой MISS, что означает, что объект не был кэширован во время запроса.
Для каждого из этих значений времени:
- первое число указывает оставшийся срок жизни объекта
- второе число указывает льготный период
- третье число указывает текущий возраст объекта в кеше
Может потребоваться несколько запросов, чтобы увидеть, как эти числа заполняются должным образом, потому что они должны либо попасть на узел кластера, либо на узел, где содержимое уже существует во временной памяти.
X-Served-By указывает экранный и пограничный серверы, которые были запрошены для запроса. POP экрана появляется первым в последовательности, а POP края появляется вторым.
X-Cache указывает, был ли запрос УДОВЛЕТВОРЕНИЕМ или ПРОМАХОМ для центра обработки данных.
Наша документация по отладке экранирования содержит подробные сведения, необходимые для понимания заголовков X-Served-By , X-Cache и X-Cache-Hits с экранированными службами.
Читайте также: