Proxycache ошибка загрузки кэша прокси сервера
В жизни каждого проекта настает время, когда сервер перестает отвечать требованиям SLA и буквально начинает захлебываться количеством пришедшего трафика. После чего начинается долгий процесс поиска узких мест, тяжелых запросов, неправильно созданных индексов, не кэшированных данных, либо наоборот, слишком часто обновляемых данных в кэше и других темных сторон проекта.
Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.
Но если вас не покидает чувство, что ваш сервер способен на большее, или есть магический параметр, ускоряющий работу сайта в 100 раз, то можно вспомнить о встроенной возможности nginx, позволяющей кэшировать ответы от бэкенда. Давайте разберем по порядку, что это, и как это может помочь увеличить количество обрабатываемых запросов сервером.
Что такое Nginx cache и как он работает?
Для удобства можно вынести конфигурацию в отдельный файл, например “/etc/nginx/conf.d/cache.conf”. Давайте рассмотрим директиву “proxy_cache_path”, которая позволяет настроить параметры хранения кэша.
“/var/lib/nginx/proxy_cache” указывает путь хранения кэша на сервере. Именно в эту директорию nginx будет сохранять те самые файлы с ответом от бэкенда. При этом nginx не будет самостоятельно создавать директорию под кэш, об этом необходимо позаботиться самому.
“levels=1:2” — задает уровень вложенности директорий с кэшем. Уровни вложенности указываются через “:”, в данном случае будет созданы 2 директории, всего допустимо 3 уровня вложенности. Для каждого уровня вложенности доступны значения от 1 до 2, указывающие, как формировать имя директории.
Важным моментом является то, что имя директории выбирается не рандомно, а создается на основе имени файла. Имя файла в свою очередь является результатом функции md5 от ключа кэша, ключ кэша мы рассмотрим чуть позже.
Давайте посмотрим на практике, как строится путь до файла кэша:
“keys_zone=proxy_cache:15m” параметр задает имя зоны в разделяемой памяти, где хранятся все активные ключи и информация по ним. Через “:” указывается размер выделяемой памяти в Мб. Как заявляет nginx, 1 Мб достаточно для хранения 8 тыс. ключей.
“max_size=1G” определяет максимальный размер кэша для всех страниц, при превышении которого nginx сам позаботится об удалении менее востребованных данных.
Также есть возможность управлять временем жизни данных в кэше, для этого достаточно определить параметр “inactive” директивы “proxy_cache_path”, который по умолчанию равен 10 минутам. Если в течение заданного в параметре “inactive” времени к данным кэша не было обращений, то эти данные удаляются, даже если кэш еще не “скис”.
Что же из себя представляет этот кэш? На самом деле это обычный файл на сервере, в содержимое которого записывается:
• ключ кэша;
• заголовки кэша;
• содержимое ответ от бэкенда.
Если с заголовками и ответом от бэкенда все понятно, то к “ключу кэша” есть ряд вопросов. Как он строится и как им можно управлять?
Для описания шаблона построения ключа кэша в nginx существует директива “proxy_cache_key”, в которой в качестве параметра указывается строка. Строка может состоять из любых переменных, доступных в nginx.
Символ “:” между параметром куки и get-параметром используется для предотвращения коллизий между ключами кэша, вы можете выбрать любой другой символ на ваше усмотрение. По умолчанию nginx использует следующую строку для формирования ключа:
Следует отметить следующие директивы, которые помогут более гибко управлять кэшированием:
proxy_cache_valid — Задает время кэширования ответа. Возможно указать конкретный статус ответа, например 200, 302, 404 и т.д., либо указать сразу все, с помощью конструкции “any”. В случае указания только времени кэширования, nginx по дефолту будет кэшировать только 200, 301 и 302 статусы.
proxy_cache_lock — Эта директива поможет избежать сразу нескольких проходов на бэкенд за набором кэша, достаточно установить значение в положении “on”. Все остальные запросы будут ожидать появления ответа в кэше, либо таймаут блокировки запроса к странице. Соответственно, все таймауты возможно настроить.
proxy_cache_lock_age — Позволяет установить лимит времени ожидания ответа от сервера, после чего на него будет отправлен следующий запрос за набором кэша. По умолчанию равен 5 секундам.
proxy_cache_lock_timeout — Задает время ожидания блокировки, после чего запрос будет передан на бэкенд, но ответ не будет закэширован. По умолчанию равен 5 секундам.
proxy_cache_use_stale — Еще одна полезная директива, позволяющая настроить, при каких случаях возможно использовать устаревший кэш.
В данном случае будет использовать устаревший кэш в случае ошибки подключения, передачи запроса, чтения ответа с сервера, превышения лимита ожидания отправки запроса, чтения ответа от сервера, либо если в момент запроса происходит обновление данных в кэше.
proxy_cache_bypass — Задает условия, при которых nginx не станет брать ответ из кэша, а сразу перенаправит запрос на бэкенд. Если хотя бы один из параметров не пустой и не равен “0”. Пример:
proxy_no_cache — Задает условие при котором nginx не станет сохранять ответ от бэкенда в кэш. Принцип работы такой же как у директивы “proxy_cache_bypass”.
Возможные проблемы при кэшировании страниц
Следующая задача, с которой придется столкнуться — это управление кэшированием. Конечно можно установить незначительное время кэша в 2-5 минут и этого будет достаточно в большинстве случаев. Но не во всех ситуациях такое применимо, поэтому будем изобретать свой велосипед. Теперь обо всем по порядку.
Управление сохранением cookie
Управление сбросом кэша
Перед тем как начать писать свое решение, посмотрим, что предлагает nginx из “коробки”. Для сброса кэша в nginx предусмотрена специальная директива “proxy_cache_purge”, в которой записывается условие сброса кэша. Условие на самом деле является обычной строкой, которая при непустом и не “0” значении удалит кэш по переданному ключу. Рассмотрим небольшой пример.
Пример взят с официального сайта nginx.
За сброс кэша отвечает переменная $purge_method, которая является условием для директивы “proxy_cache_purge” и по дефолту установлена в “0”. Это означает, что nginx работает в “обычном” режиме (сохраняет ответы от бэкенда). Но если изменить метод запроса на “PURGE”, то вместо проксирования запроса на бэкенд с сохранением ответа будет произведено удаление записи в кэше по соответствующему ключу кэширования. Также возможно указать маску удаления, указывая знак “*” на конце ключа кэширования. Тем самым нам не нужно знать расположения кэша на диске и принцип формирования ключа, nginx берет на себя эти обязанности. Но есть и минусы этого подхода.
- Директива “proxy_cache_purge” доступна как часть коммерческой подписки
- Возможно только точечное удаление кэша, либо по маске вида “*”
Мы знаем, что nginx кэш — это обычный файл на сервере. Директорию для хранения файлов кэша мы самостоятельно указали в директиве “proxy_cache_path”, даже логику формирования пути до файла от этой директории мы указали с помощью “levels”. Единственное, чего нам не хватает, это правильного формирования ключа кэширования. Но и его мы можем подсмотреть в директиве “proxy_cache_key”. Теперь все что нам остается сделать это:
- сформировать полный путь до страницы, в точности как это указано в директиве “proxy_cache_key”;
- закодировать полученную строку в md5;
- сформировать вложенные директории пользуясь правилом из параметра “levels”.
- И вот у нас уже есть полный путь до файла кэша не сервере. Теперь все, что нам остается, это удалить этот самый файл. Из вводной части мы знаем, что nginx может быть расположен не на машине приложения, поэтому необходимо заложить возможность удалять сразу несколько адресов. Снова опишем алгоритм:
- Сформированные пути к файлам кэша мы будем записывать в файл;
- Напишем простой сценарий на bash, который поместим на машину с приложением. Его задачей будет подключиться по ssh к серверу, где у нас находится кэширующий nginx и удалить все файлы кэша, указанные в сформированном файле из шага 1;
Шаг 1. Формирование файла с путями до кэша.
Обратите внимание, что в переменной “$urls” содержатся url закэшированных страниц, уже в формате “proxy_cache_key”, указанном в конфиге nginx. Url выступает неким тегом для выводимых сущностей на странице. Например, можно создать обычную таблицу в бд, где каждый сущности будет сопоставлена конкретная страница, на которой она выводится. Тогда при изменении каких-либо данных мы можем сделать выборку по таблице и удалить кэш всех необходимых нам страниц.
Шаг 2. Подключение на кэширующий сервер и удаление файлов кэша.
Приведенные примеры несут ознакомительный характер, не стоит использовать их в production. В примерах опущены проверки входных параметров и ограничения команд. Одна из проблем с которой можно столкнутся — это ограничение длины аргумента команды “rm”. При тестировании в dev окружении на небольших объемах это можно легко упустить, а в production получить ошибку “rm: Argument list too long”.
Кэширование персонализированных блоков
Давайте подведем итог, что нам удалось сделать:
- снизили нагрузку на бэкенд;
- научились управлять кэшированием;
- научились сбрасывать кэш в любой момент времени.
Нужно рассмотреть альтернативную подгрузку таких частей страницы. Как всегда это можно сделать множеством способов, например после загрузки страницы отправлять ajax запрос, а на месте персонального контента отображать лоадер. Другим способом, который мы как раз сегодня и рассмотрим, будет использование ssi тегов. Давайте вначале разберемся что из себя представляет SSI, а затем, как мы можем его использовать в связке с nginx кэшем.
Что такое SSI и как он работает
SSI (Server-Side Includes, включения на стороне сервера) — это некий набор команд, встраиваемых в html страницу, указывающие серверу, что нужно сделать.
Вот некоторый перечень таких команд (директив):
• if/elif/else/endif — Оператор ветвления;
• echo — Выводит значения переменных;
• include — Позволяет вставлять содержимое другого файла в документ.
Как раз о последней директиве и пойдет речь. Директива include имеет два параметра:
• file — Указывает путь к файлу на сервере. Относительно текущей директории;
• virtual — Указывает виртуальный путь к документу на сервере.
Нас интересует параметр “virtual”, так как указывать полный путь до файла на сервере не всегда удобно, либо в случае распределенной архитектуры файла на сервере попросту нет. Пример директивы:
Для того, чтобы nginx начал обрабатывать ssi вставки, необходимо модифицировать location следующим образом:
Теперь все запросы, обрабатываемые location “/”, будут иметь возможность выполнять ssi вставки.
Как же во всей этой схеме будет проходить наш запрос?
- клиент запрашивает страницу;
- Nginx проксирует запрос на бэкенд;
- бэкенд отдает страницу с ssi вставками;
- результат сохраняется в кэш;
- Nginx “дозапрашивает” недостающие блоки;
- итоговая страница отправляется клиенту.
Избавляемся от постоянных запросов к бэкенду через ssi
В переменной $memcache_key мы указали ключ, по которому nginx попробует получить данные из memcache. Параметры подключения к серверу memcache задаются в директиве “memcached_pass”. Подключение можно указать несколькими способами:
• IP адрес и порт;
Если nginx удалось получить ответ от сервера кэша, то он отдает его клиенту. В случае когда данных в кэше нет, запрос будет передан на бэкенд через “@fallback”. Эта небольшая настройка memcached модуля под nginx поможет нам сократить количество проходящих запросов на бэкенд от ssi вставок.
Надеемся, эта статья была полезна и нам удалось показать один из способов оптимизации нагрузки на сервер, рассмотреть базовые принципы настройки nginx кэширования и закрыть возникающие проблемы при его использовании.
Прокси-сервис можно просто разделить на прямой и обратный прокси:
Обратный прокси-сервер: в отличие от прямого прокси-сервера, еслиЛВС предоставляет ресурсы для интернетаИ пусть другие пользователи в Интернете могут получить доступ к ресурсам в локальной сети, или вы можете настроить прокси-сервер, услуга, которую он предоставляет, - обратный прокси-сервер. Обратный прокси-сервер принимает подключения из Интернета, а затем перенаправляет запрос на сервер во внутренней сети. И отправьте ответ обратно клиенту в Интернете с просьбой подключиться:
- Форвард-агент и клиент принадлежат одному и тому же лагерю. Для целевого сервера их можно рассматривать как клиента;
- Обратный прокси-сервер и целевой сервер принадлежат одному и тому же лагерю, а для клиента они «маскируются» под целевой сервер.
Экспедитор
инструкция
- resolver
- resolver_timeout
- proxy_pass
Примечание: proxy_pass Он используется не только для прямого прокси-сервера, но также в основном используется для обслуживания обратного прокси-сервера. Ниже приводится подробное описание.
примеров
Обратный прокси
инструкция
То же, что и агент пересылки, эта команда используется для настройкиПрокси серверАдрес, можноИмя хоста/IP-адрес + номер портаРавные формы:
Если прокси-сервер представляет собой группу серверов, вы можете использовать upstream Инструкции по настройке группы внутренних серверов. Определяет группу серверов. Серверы могут прослушивать разные порты. Кроме того, серверы, прослушивающие сокеты TCP и UNIX-домена, могут быть смешанными.
Примечание: для proxy_pass / server После инструкцийURLВключать лиURIУ Nginx разные методы обработки:
1. ЕслиURLНе включеныURIТогда Nginx не изменит URI исходного адреса;
2. ЕслиURLСодержитURIТогда Nginx будет использовать новыйURI суррогат ОригинальныйURI.
Proxy-Buffer
Proxy BufferПри включении Nginx будет отправлять данные ответа прокси-сервераасинхронныйКлиенту:
И когдаProxy BufferПосле закрытия Nginx будет синхронно передавать его клиенту до тех пор, пока он получает данные ответа, и не будет читать полные данные ответа.
| инструкция | описание |
|---|---|
| proxy_buffering on | off; | Enables or disables buffering of responses from the proxied server. |
| proxy_buffers number size; | Sets the number and size of the buffers used for reading a response from the proxied server, for a single connection. |
| proxy_buffer_size size; | Sets the size of the buffer used for reading the first part of the response received from the proxied server. |
| proxy_busy_buffers_size size; | When buffering of responses from the proxied server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. |
| proxy_temp_path path [level1 [level2 [level3]]]; | Defines a directory for storing temporary files with data received from proxied servers. |
| proxy_temp_file_write_size size; | Limits the size of data written to a temporary file at a time, when buffering of responses from the proxied server to temporary files is enabled. |
| proxy_max_temp_file_size size; | This directive sets the maximum size of the temporary file. |
Примечание:Proxy BufferКонфигурация для каждого запроса, а не глобальная концепция, то есть каждый запрос будет настраивать свой собственный буфер в соответствии с этими инструкциями, Nginx не будет генерировать публичныйProxy BufferДля запросов прокси.
Балансировка нагрузки
Важное использование обратного прокси NginxБалансировка нагрузки:
В практических приложениях балансировка нагрузки будет разделена в соответствии с различными уровнями сети (как правило, в соответствии с эталонной моделью из семи уровней ISO / OSI). Современная технология балансировки нагрузки в основном реализует и функционируетЧетвертый этаж/Седьмой этаж, Полностью независимый от основного оборудования сети, Nginx обычно считается балансировкой нагрузки на уровне 7.
Существуют различные алгоритмы распределения нагрузки:Алгоритм статической балансировки нагрузки/Алгоритм динамического распределения нагрузкиАлгоритм статической балансировки нагрузки относительно прост, в основномОбщий алгоритм опроса/Алгоритм взвешенного опроса на основе отношенияиВзвешенный алгоритм опроса на основе приоритетаАлгоритм динамической балансировки нагрузки является более адаптируемым и работает лучше в более сложных сетевых средах, в основном, включаяАлгоритм наименьшего приоритета соединения на основе объема задачи/Алгоритм приоритета быстрого отклика на основе производительности/Алгоритм прогнозированияиАлгоритм динамического распределения производительностиEtc.; Реализация Nginx принятаВзвешенный алгоритм опроса на основе приоритета.
Балансировка нагрузки Nginx
Перед введением upstream Используется для всех запросовБалансировка нагрузки общих правил опросаПредставлено нижеПриоритетные взвешенные правила опросаБалансировка нагрузки:
upstream В каждой из групп серверов server Были даны разные приоритеты, weight Это «вес» стратегии опроса, где10.45.156.170:80Имеет самый высокий приоритет.
Скорость отклика является одним из важных показателей для измерения производительности сервисов веб-приложений. На динамическом веб-сайте, помимо оптимизации самого публикуемого контента, другим важным методом являетсяНе требуется обновление в реальном времениизДинамический вывод страницыПреобразуйте в статический кеш страниц, а затем заходите в соответствии со статической веб-страницей, чтобы повысить скорость отклика.
Технология привода кеша
В Nginx есть два типа технологии драйвера кеша:
404 водитель
Когда Nginx обрабатывает клиентский запрос, как только обнаруживается, что запрошенный ресурс не существует, он генерирует ошибку 404. Nginx дополнительно фиксирует ошибку и далееПереместить на внутренний серверЗапрашивать данные и, наконец, отправлять данные ответа внутреннего сервера клиенту и кэшировать их локально.
proxy_store Инструкции предоставлены Nginx-Proxy StoreПростой механизм кэширования, предоставляемый модулем, подробно описан ниже.
Ресурс не существует
Подобно драйверу 404, этот метод принят location В блоке if Условное суждение напрямую определяет, существует ли запрошенный ресурс, и, если он не существует, он напрямую заставляет Nginx взаимодействовать с внутренним сервером для обновления веб-кэша.
!-f Определите, существует ли запрошенный ресурс, если он не существует proxy_pass Создайте данные для внутреннего сервера и передайте их клиенту, покаProxy StoreКэш.
Nginx кеш
Proxy Cache
Proxy CacheЭто полноценная функция и механизм кэширования с хорошей производительностью, реализованный самим Nginx. После запуска службы Nginx будет сгенерирован специальный процесс для сканирования файла кэша на диске, в памяти будет установлен индекс кэша для повышения эффективности доступа, а также специальный Процесс управления файлом кеша на диске истекает при оценке / обновлении управления.Proxy CacheКэш поддерживает кеширование любых данных ответа соединения, не ограничиваясь200Данные о состоянии.
То же, что и ранееProxy BufferРазные:Proxy BufferРеализовать асинхронную передачу данных ответа внутреннего сервера иProxy CahceNginx быстро отвечает на запросы данных клиента. После получения данных ответа от внутреннего сервера NginxProxy BufferМеханизм передает данные клиенту, с другой стороны, в соответствии сProxy CahceКонфигурация кэширует эти данные локально, и в следующий раз, когда клиент получит доступ к тем же данным, Nginx напрямую извлекает данные из локального узла и возвращает их клиенту, тем самым сокращая время взаимодействия с внутренним сервером.
| инструкция | описание |
|---|---|
| proxy_cache zone | off; | Defines a shared memory zone used for caching. |
| proxy_cache_bypass string . ; | Defines conditions under which the response will not be taken from a cache. |
| proxy_cache_key string; | Defines a key for caching. |
| proxy_cache_lock on | off; | When enabled, only one request at a time will be allowed to populate a new cache element identified according to the proxy_cache_key directive by passing a request to a proxied server. |
| proxy_cache_lock_timeout time; | Sets a timeout for proxy_cache_lock. |
| proxy_cache_min_uses number; | Sets the number of requests after which the response will be cached. |
| proxy_cache_use_stale [stale] | Determines in which cases a stale cached response can be used when an error occurs during communication with the proxied server. The directive’s parameters match the parameters of the proxy_next_upstream directive. |
| proxy_cache_valid [code . ] time; | Sets caching time for different response codes. |
| proxy_cache_path path keys_zone=name:size; | Sets the path and other parameters of a cache |
| proxy_no_cache string . ; | Defines conditions under which the response will not be saved to a cache. |
Примечание:Proxy CacheЗависит отProxy Buffer. ИProxy CacheНет возможности автоматически очищать кэшированные данные на диске, поэтому это будет оказывать определенное давление на хранилище сервера при длительном использовании.
Proxy Store
Nginx также поддерживает другой метод локального кэширования данных внутреннего сервера.Proxy StoreСProxy CacheРазница в том, что он кэширует только данные ответа от внутреннего сервера, особенно статические, и может кэшировать только данные ответа под кодом состояния 200. Он не поддерживает обновление срока действия кэша, создание индекса памяти и другие функции, но поддерживает Установить доступ пользователя / группы пользователей к кешу.
| инструкция | описание |
|---|---|
| proxy_store on | off | string; | Enables saving of files to a disk. |
| proxy_store_access users:permissions . ; | Sets access permissions for newly created files and directories. |
Memcached кеш
| инструкция | описание |
|---|---|
| memcached_pass address; | Sets the memcached server address. |
| memcached_connect_timeout time; | Defines a timeout for establishing a connection with a memcached server. |
| memcached_read_timeout time; | Defines a timeout for reading a response from the memcached server. |
| memcached_send_timeout time; | Sets a timeout for transmitting a request to the memcached server. |
| memcached_buffer_size size; | Sets the size of the buffer used for reading the response received from the memcached server. |
| memcached_next_upstream status . | Specifies in which cases a request should be passed to the next server. |
При настройке Nginx для использования Memcached вам также необходимо настроить глобальные переменные для Nginx $memcached_key Сделайте настройки.
примеров
Nginx сначала запрашивает Memcached, если кеш не срабатывает (ключ "$uri?$args" ), Nginx proxy_pass Отвечайте на запрос к внутреннему серверу, но на этот раз также требуется, чтобы внутренний сервер взаимодействовал. После ответа клиенту содержимое ответа необходимо вручную записать в Memcached для следующего получения данных напрямую из Memcached.
Распределенный Memcached
Чтобы в полной мере воспользоваться распределенными преимуществами Memcached и повысить скорость отклика сервера, мы используем непротиворечивый хеш-модуль Nginx для распределения запросов по разным серверам Memcached. В то же время для пропусков доступа нам также необходима поддержка внутренних серверов. В то время как конечный сервер отвечает клиенту, ему необходимо записать данные ответа в Memcached в соответствии с согласованными правилами хэширования.
Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2.
Существует две основные причины, по которым используется веб-кэш:
1. Уменьшение времени ожидания — так как данные по запросу берутся из кэша (который располагается “ближе” к клиенту), требуется меньше времени для получения и отображения контента на стороне клиента. Это делает Веб более отзывчивым (прим. переводчика — “отзывчивым” в контексте быстроты реакции на запрос, а не эмоционально).
2. Снижение сетевого трафика — повторное использование контента снижает объем данных, передаваемых клиенту. Это, в свою очередь, экономит деньги, если клиент платит за трафик, и сохраняет низкими и более гибкими требования к пропускной способности канала.
Виды веб-кэшей
Кэш браузера (Browser cache)
Если вы изучите окно настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вы, вероятно, заметите параметр настройки «Кэш». Эта опция позволяет выделить область жесткого диска на вашем компьютере для хранения просмотренного ранее контента. Кэш браузера работает согласно довольно простым правилам. Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).
Прокси-кэш (Proxy cache)
Прокси-кэш работает по аналогичному принципу, но в гораздо большем масштабе. Прокси обслуживают сотни или тысячи пользователей; большие корпорации и интернет-провайдеры часто настраивают их на своих файрволах или используют как отдельные устройства (intermediaries).
Поскольку прокси не являются частью клиента или исходного сервера, но при этом обращены в сеть, запросы должны быть к ним как-то переадресованы. Одним из способов является использование настроек браузера для того, чтобы вручную указать ему к какому прокси обращаться; другой способ — использование перехвата (interception proxy). В этом случае прокси обрабатывают веб-запросы, перенаправленные к ним сетью, так, что клиенту нет нужды настраивать их или даже знать об их существовании.
Прокси-кэши являются своего рода общей кэш-памятью (shared cache): вместо обслуживания одного человека, они работают с большим числом пользователей и поэтому очень хороши в сокращении времени ожидания и сетевого трафика. В основном, из-за того, что популярный контент запрашивается много раз.
Кэш-шлюз (Gateway Cache)
Также известные как “реверсивные прокси-кэши” (reverse proxy cache) или “суррогаты” (surrogate cache) шлюзы тоже являются посредниками, но вместо того, чтобы использоваться системными администраторами для сохранения пропускной способности канала, они (шлюзы) обычно используются веб-мастерами для того, чтобы сделать их сайты более масштабируемыми, надежными и эффективными.
Запросы могут быть перенаправлены на шлюзы рядом методов, но обычно используется балансировщик нагрузки в той или иной форме.
Сети доставки контента (content delivery networks, CDN) распространяют шлюзы по всему интернету (или некоторой его части) и отдают кэшированный контент заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.
Это учебное пособие преимущественно сфокусировано на браузерных кэшах и прокси, но некоторая информация подходит также и тем, кому интересны шлюзы.
Почему я должен им пользоваться
Кэширование является одной из наиболее неправильно понятых технологий в интернете. Веб-мастера, в частности, боятся потерять контроль над их сайтом, потому что прокси могут “скрыть” их пользователей, сделав сложным наблюдение посещаемости.
К несчастью для них (веб-мастеров), даже если бы веб-кэша не существовало, есть слишком много переменных в интернете, чтобы гарантировать, что владельцы сайтов будут в состоянии получить точную картину того, как пользователи обращаются с сайтом. Если это является для вас большой проблемой, данное руководство научит вас как получить необходимую статистику, не делая ваш сайт “кэшененавистником”.
Другой проблемой является то, что кэш может хранить содержимое, которое устарело или просрочено.
С другой стороны, если вы ответственно подходите к проектированию вашего веб-сайта, кэш может помочь с более быстрой загрузкой и сохранением нагрузки на сервер и интернет-соединение в рамках допустимого. Разница может быть впечатляющей: загрузка сайта, не работающего с кэшем, может потребовать нескольких секунд; в то время как преимущества использования кэширования могут сделать её кажущейся мгновенной. Пользователи по достоинству оценят малое время загрузки сайта и, возможно, будут посещать его чаще.
Подумайте об этом в таком ключе: многие крупные интернет-компании тратят миллионы долларов на настройку ферм серверов по всему миру для репликации контента для того, чтобы ускорить, как только можно, доступ к данным для своих пользователей. Кэш делает то же самое для вас и он гораздо ближе к конечному пользователю.
CDN, с этой точки зрения, являются интересной разработкой, потому что, в отличие от многих прокси-кэшей, их шлюзы приведены в соответствие с интересами кэшируемого веб-сайта. Тем не менее, даже тогда, когда вы используете CDN, вы все равно должны учитывать, что там будет прокси и последующее кэширование в браузере.
Резюмируя, прокси и кэш браузера будут использоваться, нравится вам это или нет. Помните, если вы не настроите ваш сайт для корректного кэширования, он будет использовать настройки кэша по-умолчанию.
Как работает веб-кэш
Вообще говоря, это самые общие правила (не волнуйтесь, если вы не понимаете детали, они будут объяснены ниже):
Свежесть (freshness) и валидация (validation) являются наиболее важными способами, с помощью которых кэш работает с контентом. Свежий контент будет доступен мгновенно из кэша; валидное же содержимое избежит повторной отправки всех пакетов, если оно не было изменено.
В этой статье разберемся с распространенной ситуацией при использовании прокси. Если ваш прокси-сервер отказывается принимать соединения то, попробовав приведенные ниже действия, вы сможете решить эту проблему самостоятельно.
С первого взгляда неясно, что могло пойти не так, ведь обычно после первичной настройки подключение к прокси происходит автоматически. Причин возникновения проблемы может быть несколько, самые распространенные из них:
- При работе в сети была неумышленно нажата комбинация клавиш, приводящая к сбросу настроек;
- Внезапное отключение компьютера, послужившее причиной сбившихся настроек;
- Вредоносное воздействие на операционную систему вируса или последствия работы уже удаленного ПО.
Порядок действий для восстановления соединения с прокси
Итак, если вы обнаружили описанную выше проблему с вашим прокси-сервером, то в большинстве случаев вам достаточно проделать несложную последовательность действий для решения проблемы.
Порядок действий для восстановления соединения с прокси:
Очистка кеша браузера
Ручная настройка прокси-сервера
Проверка системы антивирусом
Очистка кеша в браузере
Первое действие при неудачной попытке установить соединение с прокси-сервером – это очистка кеша и истории браузера. Вообще эту процедуру рекомендуется периодически проделывать в любом браузере просто для профилактики.
Очистка кеша для всех браузеров производится примерно одинаково, поэтому мы ограничимся рассмотрением этой процедуры в Google Chrome.
Прежде всего, необходимо открыть раздел «История». Это можно сделать несколькими способами, но самым быстрым и удобным будет сочетание клавиш Ctrl + H. После нажатия этих клавиш откроется раздел История Chrome, в котором необходимо выбрать пункт «Очистить историю».
В открывшемся окне очистки истории можно настроить параметры удаления данных о вашей деятельности в интернете. Прежде всего, рекомендуется настроить временной диапазон, за который вы хотите очистить историю вашего браузера. Лучше всего выбрать пункт «Все время» для полной очистки, по умолчанию в меню может быть выбран другой диапазон времени.
Следующим шагом необходимо выбрать, какие данные вы хотите удалить из памяти браузера. Для этого предусмотрены вкладки основных и дополнительных настроек. Если вы не уверены в том, какие типы данных удалить, а какие можно оставить, то просто оставьте настройки по умолчанию. Тогда во вкладке основных настроек будут выбраны все три пункта «История браузера», «Файлы cookie и другие данные сайтов» и «Изображения и другие файлы, сохраненные в кеше».
После этого останется только нажать на кнопку «Удалить данные» и немного подождать пока вся эта информация удалится и можно будет перейти к следующему пункту на пути восстановления доступа к прокси.
Ручная настройка прокси-сервера
Очистка кеша сама по себе является лишь подготовительным этапом, теперь перейдем к процедуре настройки прокси-сервера. Неправильные или сбившиеся настройки чаще всего приводят к отказу принимать соединения.
Мы коротко перечислим здесь только основные этапы ручной настройки прокси-сервера, подробную статью по настройки прокси соединения в Windows 10 можете найти здесь). Заметим, что в статье представлены два способа настройки прокси, при этом второй способ подойдет и для более ранних версий Windows.
В целом процесс настройки прокси-сервера можно разделить на три основных этапа:
Настройка и сохранение параметров прокси заключается в заполнении соответствующих полей такими данными о прокси как IP-адрес и порт прокси, и выбор используемого протокола передачи данных. Если настройка проходит в Proxifier или похожем софте, то необходимо сразу же указать логин и пароль для доступа к прокси, если предусмотрена авторизация таким способом.
Авторизация для доступа к прокси зависит от типа и настроек самого прокси. Если вы используете бесплатный публичный прокси, то этот пункт вам не нужен. Если же вы используете приватный прокси-сервер, то необходимо уточнить какой метод авторизации доступен для вашего прокси.
Проверка системы антивирусом
Проблемы с доступом в интернет через браузер могут появиться в результате действия вируса. Следовательно, для исключения этой причины отказа прокси принимать соединения необходимо проверить свой компьютер на наличие вредоносного программного обеспечения.
Желательно проверить систему антивирусом, отличающимся от того, который уже установлен у вас. Сделать это можно, например, с помощью бесплатных антивирусов позволяющих разово просканировать компьютер. Такие сканеры бесплатно предлагают большинство крупных разработчиков антивирусов. Найти их можно по простому запросу в поисковой системе.
В случае обнаружения вирусного ПО на вашем компьютере необходимо принять дополнительные меры по повышению безопасности личных данных, чтобы не допустить повторного заражения.
Чистка реестра
Если приведенные выше способы не решили проблему с прокси соединением, то следует попробовать очистить реестр. Чистка производится в несколько шагов.
Шаг 1. Открыть диалоговое окно «Выполнить» и в появившейся строке вызвать команду Regedit, чтобы открыть редактор реестра.
Шаг 2. В поле редактора реестра найти нужный для редактирования раздел по пути: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
Шаг 3. В найденной папке найти файл Appinit_DLLs (для Windows 10 – AutoAdminLogan) и полностью очистить его содержимое. Если этот файл оказался уже пустым, то никаких операций проделывать не требуется.
Шаг 4. Закрыть редактор реестра и перезагрузить компьютер.
Так же очистку реестра возможно провести с помощью специализированного программного обеспечения, например CCleaner.
Отключение прокси
Если после всех проделанных шагов прокси все еще не принимает соединение, а доступ в интернет вам нужен как можно быстрее, то всегда есть возможность просто отключить использование прокси-сервера и выйти в сеть без анонимизации личных данных. Отключение прокси происходит так же как включение из меню настроек в вашем браузере или в параметрах операционной системы, например, в Windows 10 нужно перевести переключатель «Использовать прокси-сервер» в положение «Откл». Более подробное описание есть здесь
Если ничего не помогает. Дополнительные действия
Но все же отключение прокси не является предпочтительным вариантом. Если прокси отказывается принимать соединения после всех проделанных операций, то есть смысл дополнительно проделать следующее:
- Отключить VPN соединения и все дополнения в браузере, поскольку некоторые браузеры оснащены собственными анонимайзерами или VPN;
- Проверить работу вашего интернет соединения напрямую, без использования прокси;
- Проверить исправность самого прокси. Это можно сделать в приложении Proxifier или в прокси-чекере. Если ваш прокси не работает, то обратитесь в службу поддержки. При использовании бесплатных публичных прокси найдите в сети новый актуальный порт.
- Переустановить операционную систему. Но это стоит проделать только в самом крайнем случае.
Описанные в этой статье способы решения проблемы с подключением прокси помогут вам в большинстве случаев. Если вдруг проблема сохранилась, то лучше всего обратиться за помощью к специалисту.
Читайте также: