Прокси кэширующий: Кэширующий анонимный прозрачный прокси сервер Squid

Кэширующий анонимный прозрачный прокси сервер Squid

    Squid — это мощный пакет, реализующий проксирование проходящих через него запросов, имеет огромный набор возможностей. В локальной сети чаще всего его используют как прозрачный кэширующий прокси. Настроим по порядку 3 основные возможности squid.

1. Для начал устанавливаем squid (для Debian 6)

apt-get install squid3

2. Файл с настройка squid.conf лежит в /etc/squid3/. Содержит он около 5,5 тысяч строк. Но не все так страшно, основная масса этого файла — это подробные комментарии к настройкам. Как удобнее внести изменения в файл выбирать Вам. Можно избавиться от всего лишнего в файле таким способом

# переходим в папку squid
cd /etc/squid3
# делаем резервную копию файла с настройками
cp squid.conf squid.conf_backup
# получаем из squid.conf_backup чистый файл с настройками без комментариев в squid.conf
cat squid.conf_backup | egrep -v '^#|^$' > squid.conf

и получить «голый» файл с настройка, следующего содеражания

acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl SSL_ports port 443
acl Safe_ports port 80        # http
acl Safe_ports port 21        # ftp
acl Safe_ports port 443        # https
acl Safe_ports port 70        # gopher
acl Safe_ports port 210        # wais
acl Safe_ports port 1025-65535    # unregistered ports
acl Safe_ports port 280        # http-mgmt
acl Safe_ports port 488        # gss-http
acl Safe_ports port 591        # filemaker
acl Safe_ports port 777        # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:        1440    20%    10080
refresh_pattern ^gopher:    1440    0%    1440
refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
refresh_pattern .        0    20%    4320

Останется внести лишь необходимые изменения в  строках. Второй вариант — это редактировать весь файл без его чистки. Что тоже довольно просто если уметь пользоваться поиском в редакторе vi. В этом случае у Вас в помощь останутся много полезных комментариев к настройкам.

Для поиска текста в редакторе vi нажимаем клавишу «/». Если Вы находитесь в режиме редактирования, нужно выйти из него для передачи команд редактору нажатием на «Esc». Получаем такую последовательность действий: «/» > «вводим поисковое слово» > «Enter».

Теперь редактируем файл, делаем основные настройки. Если нужных строк нет, то добавляем их или раскоментируем.

vi /etc/squid3/squid.conf

# Разрешаем доступ к прокси только из нашел сети
acl localnet src 172.16.0.0/24
http_access allow localnet
http_access allow localhost
# По умолчанию порт работы прокси 3128
# Так как у нас прокси будет прозрачным - указываем это
# а так же адрес интерфейса с портом на котором будет работать прокси
# на этот же порт будут перенаправляться запросы в iptables
http_port 172.16.0.1:3128 transparent

3. Обеспечиваем кэширование запросов

# Установка директории кэша и его настройка
# ufs - способ кэширования файлов на диске
# /var/spool/squid3 - папка кэша
# 5000 - размер кэша в мегабайтах
# 16 - количество папок 1 уровня в кэше
# 256 - количество папок 2 уровня в кэше
cache_dir ufs /var/spool/squid3 5000 16 256
# ограничим минимальный размер кэшируемого файла, чтобы облегчить работу жесткому диску
# либо можно потерять весь смысл кэша, если он будет медленно работать
minimum_object_size 2 KB
# ограничиваем и максимальный размер
maximum_object_size 61440 KB

4. Squid, сконфигурированный по умолчанию, добавляет к http-запросу несколько своих заголовков. При этом, в первых двух заголовках передается клиентский ip (или даже несколько ip, в случае цепочки прокси). Если нам это ни к чему, ну например, не хотим светить внутренние ip своей локалки, то сделать squid анонимным очень просто

via off
forwarded_for delete

После завершения всех настроек, стоит проверить анонимность запросов на страничке http://checker.samair.ru Если все сделано правильно, то результатом будет надпись «Resume: You are using high-anonymous (elite) proxy».

На этом внесение изменений в файл закончены. В конечном итоге squid.conf должен выглядеть так

acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

acl localnet src 172.16.0.0/24  # RFC1918 possible internal network

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localnet
http_access allow localhost

http_access deny all

http_port 172.16.0.1:3128 transparent

hierarchy_stoplist cgi-bin ?

cache_dir ufs /var/spool/squid3 5000 16 256
minimum_object_size 2 KB
maximum_object_size 61440 KB

coredump_dir /var/spool/squid3

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

via off
forwarded_for delete

Для применения настроек останавливаем squid

service squid3 stop

Подготавливаем директорию кэша squid

squid3 -z

Запускаем прокси

service squid3 start

Если Вы не делали изменения настроек связанных с кэшем прокси, то можно выполнить одну единственную команду. Настройки будут приняты автоматически без перезапуска squid.

squid3 -k reconfigure

5. Остается лишь настроить прозрачность прокси. Это обеспечивает незаметную для пользователей локальной сети работу через прокси, т.е. нет необходимости настраивать пользователям программы для работы с прокси. Прозрачность обеспечивается простым перенаправлением http запросов с 80 порта на порт прокси сервера посредством фаервола iptables и включением режима прозрачного прокси в самом squid. Изменения в настройках squid мы сделали выше. Добавляем к правилам iptables еще одну строку:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Обязательно в параметре указывайте нужный интерфейс на котором будет работать прокси: -i eth0. Это избавит Вас от проблем с доступом к web серверу из интернета при наличии более одного активного интерфейса, если таковой будет в будущем на этом сервере. А так же ради безопасности прокси.

Ну и на всякий случай squid.conf в разных вариантах:

Исходный файл без изменений

Исходный файл чищеный от комментариев

Настроенный файл squid.conf

Настроенный файл squid.conf без комментариев

VN:F [1.9.22_1171]

Рейтинг: 6.7/10 (6 голоса(ов))

Кэширующий анонимный прозрачный прокси сервер Squid, 6.7 out of 10 based on 6 ratings

Кэширующий прозрачный прокси сервер SQUID на Debian squeeze / Песочница / Хабр

Задача: Кэширующий прозрачный прокси сервер

Для начала нам понадобиться:

1. Чистая система с Debian Squeeze
2. Непосредственно сервер компьютер с двумя сетевыми картами eth0 и eth2.

Для чистоты эксперимента будем считать что eth0 смотрит к провайдеру и получает от него настройки по DHCP, а eth2 смотрит в нашу локальную сеть и имеет классический адресс вида 192.168.100.1.

Тогда:

1) Настроим нашу сеть вот так:

$ cat /etc/network/interfaces

#Localhost Network

auto lo

iface lo inet loopback

#WAN Network

auto eth0

iface eth0 inet dhcp

#LAN Netowrk

auto eth2

iface eth2 inet static

address 192.168.100.1

netmask 255.255.255.0

2) Установим и натсроим DHCP сервер вот так:

# apt-get -y install isc-dhcp-server

Отмечу, что сразу после установки он у нас не запустится, поэтому сразу приводим /etc/dhcp/dhcpd.conf к разумному виду

# cat /etc/dhcp/dhcpd.conf
dns-update-style none;

option domain-name "localdomain";

option domain-name-servers 192.168.100.1;

default-lease-time 600;

max-lease-time 7200;

log-facility local7;

subnet 192.168.100.0 netmask 255.255.255.0 {

range dynamic-bootp 192.168.100.10 192.168.100.99;

option broadcast-address 192.168.100.255;

option routers 192.168.100.1;

}

Из конфига видно что клиенты будут получать адреса от *.10 до *.99.

3) Для нормальной работы нам обязательно потребуется сервер имен.

# apt-get -y install bind9

4) Теперь пришло время поднять и настроить Squid как кэширующий прозрачный прокси сервер

# apt-get -y install squid3

Стоит заметить, что можно работать со стандартным конфигом, но это будет не так как нам требуется и уж совсем не Debian way.

Поэтому приводим конфиг к такому виду:

$ cat /etc/squid3/squid.conf

acl manager proto cache_object

acl localhost src 127.0.0.1/32 ::1

acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl my_network src 192.168.100.0/24

acl SSL_ports port 443

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 # https

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

http_access allow my_network

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost

http_access deny all

http_port 3128 transparent

hierarchy_stoplist cgi-bin ?

coredump_dir /var/spool/squid3

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

refresh_pattern . 0 20% 4320

shutdown_lifetime 5.00 second

cache_dir ufs /var/cache/squid 2048 16 256

maximum_object_size 10024.00 bytes

Как видно из конфига, мы создали правило my_network и разрешили ему смотреть интернеты.

Параметр http_port 3128 transparent означает что наш сервер будет прозрачным.

Также мы переобозначили кэш, задав под него директорию /var/cache/squid размером в 2 Гб.

Создадим ее:

# mkdir -p /var/cache/squid

Назначим права:

chmod 755 -R /var/cache/squid

И спокойно перезапускаем наш Squid.

/etc/init.d/squid3 restart

После перезапуска должен пересоздаться кэш.

5) Очень важно правильно настроить iptables.

На этом шаге я предлагаю Вам создать скрипт настройки, так как он пригодится как универсальное средство.

# vim ./setiptables.sh

#!/bin/bash

LAN=$1

WAN=$2

IP=$3

GW=$4

iptables -t nat -A PREROUTING -i $LAN -p tcp --dport 80 -j DNAT --to $IP:3128

iptables -t nat -A PREROUTING -i $WAN -p tcp --dport 80 -j REDIRECT --to-port 3128

iptables -t nat -A POSTROUTING -j MASQUERADE

iptables -A FORWARD -i $WAN -o $LAN -s $GW/24 -p tcp -m multiport --dport 443,21,22 -j ACCEPT

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.conf

sysctl -w net.ipv4.ip_forward=1

Мы обозначили переменные (для удобства), 3 правила для таблицы NAT и 1 для FORWARD.

Порты 443,21,22 пускаем в обход прокси сервера.

Помимо настроек iptables, в этом скрипте, мы включаем форвардинг пакетов.

Запускаем так:

# sh ./setiptables.sh eth0 eth2 192.168.100.1 192.168.100.0

6) Настроим автозагрузку натсроек iptables.

Сохраням настройки iptables.

# mkdir -p /usr/local/iptables && iptables-save > /usr/local/iptables/session.ipt

Добавляем команду авотзапуска в /etc/rc.local (мне нравится Perl но тут кому как).

# perl -i -pe 'print "iptables-restore < /usr/local/iptables/session.ipt\n" if $. == 2' /etc/rc.local

Также не забываем про форвардинг пакетов

# perl -i -pe 'print "sysctl -w net.ipv4.ip_forward=1\n" if $. == 3' /etc/rc.local

В целом настройка прозрачного прокси сервера закончена, но чтобы логи были читаемы, нам наобходимо отключить поддержку ipv6 (из за того что ipv6 у нас не настроен на адаптере будет много warnings).

7) Отключаем IPv6

Предлагаю опять же сделать скрипт чтобы не запутаться.

# vim ./ipv6disable.sh

#!/bin/bash

perl -i -pe 'print "alias net-pf-10 ipv6 off\n" if $. == 17' /etc/modprobe.d/aliases.conf

perl -i -pe 'print "alias net-pf-10 off\n" if $. == 18' /etc/modprobe.d/aliases.conf

perl -i -pe 'print "alias ipv6 off\n" if $. == 19' /etc/modprobe.d/aliases.conf

echo 1 | tee /proc/sys/net/ipv6/conf/all/disable_ipv6

echo "blacklist ipv6" | tee -a /etc/modprobe.d/blacklist.conf

STR=$(cat /boot/grub/grub.cfg | sed -n '67p')

STR=${STR}" ipv6.disable=1"

sed '67d' /boot/grub/grub.cfg > /boot/grub/grub.cfg.backup

cp /boot/grub/grub.cfg.backup /boot/grub/grub.cfg

sed -i 67i\ "$STR" /boot/grub/grub.cfg


В общих чертах что в этом скриптике происходит:

Сперва отключаем пожжержку ipv6 в модулях ядра.

Далее указываем маркер в /proc на не использование ipv6.

И в 67 строке /boot/grub/grub.cfg дописываем параметр ipv6.disable=1.

Такая канитель с tee и sed нужна для того чтобы сохранить настройки /boot/grub/grub.cfg, так как там устройства обозначаются не по /dev/sd* и по UUID.

Хотя все всегда можно дописать ручками.

И на последок, для тех кто ручками писать не хочет, я выложил скрипт:
www.uralcode.ru

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

Скрипт все время допиливается. В ближайшее время будет добавлена поддержка havp (проверка трафика антивирусом на лету до вхождения в squid) с кастомными темплейтами. Соответственно постараюсь максимально изложить мат. часть в необходимой для понимания мере.

Настройка прокси-кэширующего сервера  — Cайт «У Крайнего» . ИТ — Информ

Когда нужно предоставить совместный доступ к Web-сервисам с возможностью кэширования трафика, в первую очередь вспоминают о кэширующем прокси-сервере Squid. Это гибкое решение применяют и в мелких офисах с несколькими пользователями, и в корпоративных сетях со сложной топологией. Разберем, как настроить в Squid самые популярные функции — контроль доступа и работу с кэшем.

Для новичков — пара слов о самом Squid. Squid, он же “кальмар” (www.squid-cache.org) — приложение, позволяющее организовать прокси/кэширующий сервер для HTTP, FTP и некоторых других популярных протоколов. Поддерживается работа с защищенными TLS/SSL соединениями, кэширование DNS, возможно использование Squid в качестве прозрачного или реверсного прокси. Распространяется по лицензии GNU GPL. Работает во всех популярных вариантах Unix систем — GNU/Linux, *BSD, MAC OS X, SunOS/Solaris. ЕСть и для Windows.
В качестве примера буду использовать Ubuntu, как более удобного дистрибутива, но сказанное относится и к остальным дистрибутивам или ОС (установка происходит по разному, в различных дистрибуивах). Надо отметить, что сейчас параллельно развивается две ветки: 2.х и 3.х.Третья ветка перешла в разряд Stable в конце прошлого года, и разработчики рекомендуют ее к использованию. В репозитарии Ubuntu, начиная c Festy Fawn (7.04), есть и пакеты с третьей версией Squid. По описываемым в статье параметрам отличий у них практически нет, возможно только некоторые специфические.
Установка кальмара в Ubuntu довольно проста:

$ sudo apt-get install squid squid-common

Или, для Squid 3:
$ sudo apt-get install squid3 squid3-common
После инсталяции Squid будет запущен с установками по умолчанию. При первом запуске возможна ошибка “FATAL: Could not determine fully qualified hostname. Please set ‘visible_hostname’”. Это значит, что по дефолту разрешение имени узла, на котором работает Squid, осуществляется при помощи gethostname(). В зависимости от установок DNS он иногда не может однозначно определить имя, которое будет фигурировать в журналах и выводах об ошибках “Generated … by server.com (squid/3.0.STABLE2)”, поэтому просит тебя помочь. Все настройки Squid производяться в единственном файле /ect/squid/squid.conf. В нем до невероятности много параметров и бросаться менять их все и сразу не стоит. Просмотреть список парметров, убрав пустые и закомментированные строки, можно при помощи команды:
$ sudo grep -v “^#” /ect/squid/squid.conf | sed -e ‘/^$/d’
Формат squid.conf стандартен для Unix. Каждая запись состоит из строк вида: “параметр значение”. Строки, начинающиеся со знака решетки, — комментарии. Для удобства настройки все параметры разбиты по секциям. разбиение чисто условно и свои параметры можно заносить в любое место файла. Возможно подключение внешнего файла с настройками при помощи include. Помни, что установки применяются в порядке очередности.
Для начала запустим Squid, устранив ошибку, указанную выше. Заносим в конфиг строку с именем сервера Squid (необязательно должно совпадать с доменным):
visible_hostname mysquid
И запускаем:
$ sudo /ect/init.d/squid start
В настройках по умолчанию сквид принимает входящие соединение на 3128/tcp. Командой “netstats — ant / grep 3128″ проверяем, слушается ли этот порт. Если все ОК, настраиваем веб-браузер для работы через прокси-сервер и выходим в Сеть. Но сейчас это возможно только с localhost. Чтобы в интернет могли попасть остальные пользователи локальной сети, нужно установить соответствующие разрешения, используя контроль доступа.

НАСТРАИВАЕМ ДОСТУП

Изменив параметр http_port, мы можем подвесить Squid только на внутренний сетевой интерфейс:
http_port 192.168.0.1:3128
Чтобы разрешить всем пользователям сетей 19.168.0.0, 172.16.0.0 и компьютера 192.168.1.1 подключаться к Squid, добовляем описание нового списка доступа в секцию “ACCESS CONTROL”:
acl localhost src 192.168.0.0/24 172.16.0.0/12 192.168.1.1
Переменные чувствительны к регистру, но, применив параметр “ac1 -i”, это можно исправить. Чуть дальше покажу как. Если нужно настроить доступ не для всей сет, а для отдельных ее узлов, проще записать их адреса в файл (по одному в строке), которой и указать в качестве последнего параметра. Третья строка — тип списка доступа. В нашем случае используется src (от source). При помощи других параметров можно задать внешний адрес (dst), MAC-адрес (arp), деменное имя (srcdomain,dstdomain), порт (port), протокол (proto), время (time) и много друго. Фактически, работа по организации доступа сводится к описанию объекта в acl, а затем разрешению или запрету работы объекта при помощи http_access с требуемыми параметрами. Например, чтобы указать рабочее время, применем такую конструкцию:
acl work_hours time M T W T F 9:00 — 18:00
В описании используется первые буквы английского языка, соответствующие дням недели. В секции “ACCESS CONTROL” уже описаны некоторые ACl, в частности, описываются номера некоторых портов (привожу не все) b ACL, соотвестствующий всем адресам:
acl SSL_ports port 443 563 873
acl Safe_ports port 80 21 443 563 1025-65535
acl all src 0.0.0.0/0.0.0.0
Следует внимательно просмотреть весь список и закомментировать строки с портами ненужных или неиспользуемых сервисов. Когда списки составлены, при помощи параметра http_access разрешаем или запрещаем доступ указанному ACL. Общий формат вызова такой:
http_access allow|deny [!]название_ACL
Восклицательный знак инвентирует значение списка, то есть звучит, как “все кроме”. По умолчанию используется правило:
http_access deny all
Его мы обязательно помещаем в конец списка рулесетов. В этом случае все соединения, которое не разрешены явно, будут блокированы. Майнтэйнеры, собирающие пакеты в дистрибутивах, как правило, добавляют и несколько своих правил.
Чтобы разрешить подключение к Squid с указанных адресов и работу только с нужными портами, пишем:
http_access allow localnet
http_access deny !Safe_ports
http_access deny !SSL_ports
Сохраняем результат и перезапускаем Squid:
$ sudo/ect/init.d/squid restart
Проверяем. Если все нормально, идем дальше. Чтобы не перерастраивать клиентские системы, проще использовать iptables:
iptables -t nat -A PREROUTING -i eth2 \
-p tcp -m tcp –dport 80 -j DNAT \
–to-destination 192.168.0.1:3128

iptables -t nat -A PREROUTING -I eth0 -p tcp -m tcp \
–dport 80 -j REDIRECT –to-ports 3128
А вот ее один пример. Нам нужно, чтобы компьютеры с определенными IP могли выходить в инет только в рабочее время. Без проблем:
acl workip src 192.168.1.100 192.168.1.200-
192.168.1.210
http_access deny!work_hours workip
Получается не очень читабильно, но можно сделать так:
http_access allow work_hours workip
http_access deny workip
первая строка разрешит доступ при совпадении двух ACL: рабочее время и IP-адрес. Вторая запретит доступ всех записанных в ACL workip при несовпадении с первым правилом (тоесть в другой временной промежуток).

ЗАПРЕТ БАНЕРОВ И САЙТОВ

Одна из функций, которая делает Squid востребованным, — зпрет доступа к определенным интернет ресурсам. Это реализованно на той же сладкой парочке: acl и http_access. Зная адрес ресурса, можно просто закрыть доступ к конкретному адресу или целевой подсети:
acl denynet dst 194.55.0.0/16
http_access deny denynet
Но всмето того, чтобы использовать адрес, удобнее при помощи dstdomain указать домен назначения. Например, запретим доступ к сервисам вроде RapidShare:
acl rapida dstdomain .rapidshare.com .rapidshare.de
http_access deny rapida

НАСТРОЙКА КЭША

Борьбас баннерами — не единственная возможность сэкономить трафик. нельзя обойти стороной настройку кэширования. В Ubuntu кэш по умолчанию размещается в каталоге /var/spool/squid. В других дистрибутивах может быть иначе. Чтобы не искать, посмотри значение переменной cache_dir. Формат ее такой:
cache_dir type путь размер L1 L2 [options]
Например:
cache_dir ufs /var/spool/squid 10249 16 256
Поле type определят тип кэша: ufs (unix file system), aufs и diskd. Обычно используется ufs как наиболее надежный. Максимальный размер, после которого кэш будет очищаться, установлен по умолчанию в 100 Мб. При серьезных нагрузках он быстро заполнится, поэтому есть смысл увеличить его до нескольких гигабайт (я увеличил до 10 Гб). Удобно, что можно использовать несколько cache_dir, установив кэш на разных дисках, — положительно скажется на производительности. В Squid каждый кэшируемый объект распологается в отдельном файле, а сами файлы не сваливаются в одно место, благодаря механизму работы с двухуровневой иерархией каталогов. Количество каталогов первого и второго уровней определяют параметры L1 и L2. По умолчанию их значения 16 и 256, соответственно. Дополнительно для каждого cache_dir можно определить параметр read-only (только чтение) и max-size (максимальный размер объекта).
Максимальный размер объекта в кэше определяется переменной maximum_object_size. значение по умолчанию — 4Мб, есть смысл его увеличить:
maximum)object_size 10240 KB
Аналогично, есть пример minimum_object_size, отвечает за минимальный размер объекта, по дефолту он отключен (значение 0).Объем ОЗУ, используемый Squid для хранения обрабатываемых объектов, определяется пармаетром cache_mem (по умолчанию — 8 Мб). при большом размере кэша лучше увеличить это значение, тем более что объемы современных ОЗУ это позволяют. Иначе Squid будет сбрасывать всю информацию на диск, что замедлит его работу. Но это еще далеко не все. например, отключенный по умолчанию параметр reload_info_ims разрешает игнорировать nocache или reload и выдать объект из кэша. Это нарушение стандарта HTTP, но большинство серверов умеют корректно обрабатывать такой запрос, поэтому включаем:
reload_into_ime on
Вместо глобальной установки можно задать такой параметр для некоторых типов файлов.
Документация на странице reload_into_ims отсылает нас к не менее интересной директиве refresh_pattern, которая управляет параметрами кэширования:
refresh_pattern [-i] regex min percent max [options]
В regex пишем регулярное выражение, которое будет отвечать правило. Проверка производится до первого совпадения. Поэтому последним всегда устанавливается “.” — то есть правило для всех объектов. Параметр min и max указывают на минимальное и максимальное время в минутах, в течение которого объект считается новым. В percent указывается процент от времени последней модификации объекта. В min рекомендуется устанавливать 0, чтобы корректно работать с динамически обновляемыми страницами. В версии Squid 2.x по умолчанию используется инструкции:
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher:1440 0% 1440
refresh_pattern . 0 20% 4320
В версии 3.0 перед “.” добавлена строка:
refresh_pattern (cgi-bin|\?) 0 0% 0
В поле options через пробел указываются дополнительные параметры. В версии 2.х параметров семь, в 3.х добавилось еще два. Большинство из них идут в разрез со стандартами HTTP, и их использование может вызвать проблемы при работе с некоторыми серверами. Однако они весьма полезны для оптимизации кэша и понадобятся в дальнейших настройках:
— override-expire — в нарушение стандарта заставляет игнорировать параметр expire, то есть время актуальности объекта;
— override-lastmod — игнорирует время последней модификации объекта, переданного сервером;
— reload-inti-ims, ignore-reload — изменяет или игнорирует клиентские запросы nocache или reload и принудительно выдает объект, хранящийся в кэше;
— ignore-no-cache, ignore-private, ignore-auth — игнорирует заголовки “Pragma: no-cache”, “Cache-control: no-cache”, “Cache-control: private” и “Cache-control: public”, принудительное кэшируя такой объект. Параметры, появившиеся в третьей версии:
— ignore-no-store — Игнорировать заголовок “Cache-control: no-store”;
— refresh-ims — заставляет проверять наличие новой версии файла при получении от клиента if-Modified-Since.
В самом простом случае вместо правил по умолчанию можно написать одно правило, заставляющее принудительно кэшировать объекты на целый год:
refresh_pattern . 518400 80% 518400
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store
Устанавливаем размер кэша побольше и забываем о Squid. Это даст весьма ощутимую экономию трафика. Но таокй подход не всегда приемлен, да и кэш быстро заполнится старыми файлами. Поэтому лучше установить свои варианты кэширования для различных типов файлов. Например, часто на сайтах проектов экзешники, архивы и некоторые другие типы файлов имеют постоянный адрес, вроде server.com/current.exe. Укажем для таких файлов время хронения в месяц:
refresh_pattern \.exe$ 43200 100% 43200
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store

refresh_pattern \.zip$ 43200 100% 43200
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store
И так далее. Схожим образом “вырезаем” рекламу. Так как довольно трудно создать универсальное правило для acl/http_access и всегда можно допустить ошибку, рекламу проще кэшировать, чем блокировать:
refresh_pattern http://ad\. 43200
Это наиболее простой способ. При тщательном изучении логов можно составить коллекцию URL, которые стоит поместить в вечный кэш.
В настройки Squid, не так уж и сложен. Если не считешь удобную ручную настройку, обратись к Webmin, где большинство установок можно произвести в наглядной форме. Базовая настройка занимает минут 10. После определенной доводки пользователи будут радоваться скорости открытия страниц, да и по карману сильно не ударит.

• < Назад
• Вперёд >

Кеширующий прокси-сервер на nginx. Хитрая конфигурация / Хабр

На Хабре уже есть несколько описаний Nginx, но, думаю, моя конфигурация тоже будет интересна.
Ситуация выглядит следующим образом: есть размещённый на нескольких серверах IIS сайт (интернет-магазин), перед ним расположен балансировщик. Между ними решено установить nginx для уменьшения нагрузки на IIS.

Основная масса динамического контента отображается Ajax-ом, так что кеширование страниц каталога товаров вполне безопасно. Однако на них могут быть отзывы о товаре, за которые можно проголосовать — совсем как на Хабре, что тоже надо учесть.

Плюс к этому хочется поддерживать валидность популярных страниц в кеше автоматически.

Итак, сначала устанавливаем свежий nginx — без него не получится. Также нам понадобятся wget и curl.

Я не буду подробно описывать конфигурацию самого прокси, а детально остановлюсь на методах поддержания кеша в актуальном состоянии.

Конфигурация самого nginx:

worker_processes  4;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
        # Кеш у нас большой.
    proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=STATIC:512m
    inactive=24h max_size=32g;

    sendfile        on;
    keepalive_timeout  65;

    gzip                on;
    gzip_proxied        any;
    gzip_min_length     1100;
    gzip_http_version   1.0;
    gzip_buffers        4 8k;
    gzip_comp_level     9;
    gzip_types          text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;

server {

    server_name 127.0.0.1;
    listen 80;

    set $backend 127.0.0.2;
        # Меняем структуру логов. Они нам понадобятся. Разделитель полей - |
    log_format cache '$remote_addr|$time_local|$request_uri|$request_method|$status|$http_referer|$cookie___sortOrder|$IsAuth|$sent_http_content_type|$http_user_agent';
    access_log /var/log/nginx/proxy_access.log cache;
    error_log off;
        # Не кешируем полностью динамические пользовательские страницы
    location ~* /(basket.aspx|visitedgoods.aspx|users/|sale/order.aspx|sale/posted.aspx) {

         proxy_pass http://$backend;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_pass_header Set-Cookie;
         proxy_redirect off;

         set $IsAuth 1;
         if ($cookie_AUTH = "") {
         set $IsAuth 0;

         }

    }

    location / {
        # Убираем из урлов символ | - он там не должен оказаться, но если кто-то вобъёт его руками, он попортит нам логи
         if ($args ~* (.*)\|(.*)) {
            set $brand $1$2;
            rewrite ^(.*) $1?$brand? redirect;
         }

         if ($args ~* (.*)\%7C(.*)) {
            set $brand $1$2;
            rewrite ^(.*) $1?$brand? redirect;
         }

         rewrite   ([a-zA-Z0-9]+)\|([a-zA-Z0-9]+)  $1$2?  permanent;
         rewrite   ([a-zA-Z0-9]+)\%7C([a-zA-Z0-9]+)  $1$2?  permanent;
         rewrite   (.*)\%7C$  $1?  permanent;
         rewrite   (.*)\|  $1?  permanent;

         proxy_pass http://$backend;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_pass_header Set-Cookie;
         proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie";
            # Проверяем, аутентифицирован ли пользователь. Страницы у гостей и юзеров разные, эта переменная нужна для ключа кеша.
         set $IsAuth 1;
         if ($cookie_AUTH = "") {
            set $IsAuth 0;
         }
            # Проверяем, не нужно ли обновить кеш - это делается при запросе нашего робота
         set $DoBypass 0;
         if ($http_user_agent = "WGET-POST-daemon") {
            set $DoBypass 1;
         }

            # Кука __sortOrder задаёт метод сортировки товаров и тоже нужна в ключе
         proxy_cache STATIC;
         proxy_cache_key "$host$uri$is_args$args $cookie___sortOrder $IsAuth";

         proxy_cache_valid 200 301 302 304 30m;

         proxy_cache_bypass $DoBypass;

         proxy_cache_use_stale error timeout invalid_header updating;
         proxy_connect_timeout 100ms;

         proxy_redirect off;

         }

}

}

Итак, прокси готов. Теперь самое интересное.

Мы хотим иметь в кеше TOP-20000 страниц за последние сутки. Лог выглядит так:

127.0.0.3|20/Oct/2011:15:45:43 +0400|/catalog/25/women.aspx|GET|200|http://127.0.0.1/|-|0|text/html; charset=windows-1251|Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.51


Логи обращаются каждый час и хранятся сутки. Ксожалению, logrotate не умеет обращать логи менее, чем раз в день, поэтому применяется средней грязности хак: size 1 в файл конфигурации и logrotate -f /etc/nginx.rotate по крону раз в час.

Скрипт для создания списка наиболее посещаемых страниц:

#!/bin/bash

# Получаем собственный IP, чтобы не учитывать в статистике локальный трафик
ourIP=$(ifconfig  | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}')

# Получаем валидную куку аутентификации для скачки страниц, отображаемых зарегистрированным юзерам
curl -H "Cookie: BasketID=KYKY-B-PYKY" -H "Content-Type: application/json" -d "{\"login\":\"USERNAME\",\"password\":\"PASS\",\"remeberMe\":\"true\"}" -c /var/log/nginx/cookies1.txt http://127.0.0.1/Resources/Services/SystemService.asmx/SignIn
line=$(tail -n 1 /var/log/nginx/cookies1.txt)
AUTH=$(echo $line | awk '{wild=$7; print wild}')

# Собираем единый лог: сливаем вместе все файлы за сутки.
cp /var/log/nginx/proxy_access.log /var/log/nginx/overall_proxy

FILES=/var/log/nginx/*.gz
for f in $FILES
do
    cat $f | gunzip>> /var/log/nginx/overall_proxy
done

# удаляем старые файлы команд wget-у
rm -f /var/log/nginx/wget/*

# Выбираем из лога все запросы к кеширующимся страницам (по типу содержимого - text/html), которые были запрошены НЕ с локалхоста и успешно переданы клиенту, выбираем 20000 самых популярных и создаём список команд wget-у.
awk -v ourIP="$ourIP" '{ FS="|"; ip = $1; url = $3; code = $5; catsrt=$7; isauth=$8; ct=$9; if (ip != ourIP) if (url !~ "basket.aspx" && url !~ "visitedgoods.aspx" && url !~ "users/" && url !~ "sale/order.aspx" && url !~ "sale/posted.aspx") if (code = "200") if (ct ~ "text/html;") print "http://" ourIP url "|" catsrt "|" isauth}' /var/log/nginx/overall_proxy | sort | uniq -c | sort -n -k1,6 | tail -n20000 | awk  '{print $2}' | awk -v AUTH="$AUTH" '{FS="|"}$2=="-"{$2=""} $3=="0"{$3=""} $3=="1"{$3=AUTH}{print "-b --header=\"Cookie: __sortOrder="$2"; AUTH="$3"\" -o /dev/null -O /dev/null "$1 }'> /var/log/nginx/cache.dat

rm -f /var/log/nginx/overall_proxy

cd /var/log/nginx/wget

# Режем список команд на 10 частей - мы запустим 10 потоков закачки.
split -l 2000 /var/log/nginx/cache.dat

rm -f /var/log/nginx/cache.dat

Итак, на выходе получаем файлики с командами:
-b --header="Cookie: __sortOrder=; AUTH=" -o /dev/null -O /dev/null 127.0.0.1/catalog/25/women.aspx

Дальше каждые 20 минут мы должны пройти по этому списку и запросить каждую из страниц с сервера для валидации кеша.

#!/bin/bash

FILES=/var/log/nginx/wget/*

# Убиваем незавершённые с прошлого раза wget-ы
if [ -s /var/log/nginx/wgets.pid ]
then
    cat /var/log/nginx/wgets.pid | xargs kill
    rm -f /var/log/nginx/wgets.pid
fi

# И запускаем новые.
for f in $FILES
do
    cat $f | xargs wget & echo $! >> /var/log/nginx/wgets.pid
done

Теперь осталось только обновлять кеш страниц при голосовании за комментарий. Этим занимается демон, постоянно мониторящий логи на предмет голосования.

#!/bin/bash

# Получаем куку аутентификации
curl -H "Cookie: BasketID=KYKY-B-PYKY-U-ATAC" -H "Content-Type: application/json" -d "{\"login\":\"USERNAME\",\"password\":\"PASS\",\"remeberMe\":\"true\"}" -c /var/log/nginx/cookies.txt http://127.0.0.1/Resources/Services/SystemService.asmx/SignIn

line=$(tail -n 1 /var/log/nginx/cookies.txt)
AUTH=$(echo $line | awk '{wild=$7; print wild}')

# Проверяем, не запущен ли уже демон
if [ -f /var/log/nginx/post-daemon.pid ] ;
then
    echo "POST-daemon already running!"
    exit 
fi

# Вешаемся на хвост логу nginx-а и ждём голосования
(/usr/bin/tail -f /var/log/nginx/proxy_access.log & echo $! >/var/log/nginx/post-daemon.pid) |
while read -r line
do
    if [[ $line =~ '/Resources/Services/SystemService.asmx/VoteToComment|POST|200' ]];
    then
              # Собираем информацию для wget - ссылку и куки.
	ref=$(echo $line | awk -F"|" '{ FS="|"; ref=$6; print ref}')
	sortOrder=$(echo $line | awk -F"|" '{ FS="|"; co=$7; print co}')
	IsAuth=$(echo $line | awk -F"|" '{ FS="|"; IsAuth=$8; print IsAuth}')
	if [[ $sortOrder == "-" ]];
	then
	    sortOrder=""
	fi
              # Проверяем, какую страницу качать - для гостей или для регистрантов, и качаем. UserAgent скажет нашему nginx-у, что данный запрос должен быть обработан в обход кеша.
	if [[ $IsAuth == "0" ]];
	then
	    wget --user-agent="WGET-POST-daemon" --header="Cookie: __sortOrder=$sortOrder" -o /dev/null -O /dev/null $ref
	else
	    wget --user-agent="WGET-POST-daemon" --header="Cookie: __sortOrder=$sortOrder; AUTH=$AUTH" -o /dev/null -O /dev/null $ref
	fi
    fi
done
exit

Конфигурация для logrotate:

/var/log/nginx/*log {
    daily
    rotate 24
    size 1
    missingok
    notifempty
    compress
    postrotate
        /etc/init.d/nginx reload
        /etc/init.d/nginx-POSTcache restart
    endscript
}

init-скрипт для нашего демона:

#!/bin/sh
#
# This script starts and stops the nginx cache updater daemon
#
# chkconfig:   - 85 15 
#
# processname: post-daemon
# pidfile: /var/log/nginx/post-daemon.pid

. /etc/rc.d/init.d/functions

daemon="/usr/local/sbin/post-daemon.sh"
pidfile="/var/log/nginx/post-daemon.pid"
prog=$(basename $daemon)

start() {
    [ -x $daemon ] || exit 5
    echo -n $"Starting POST-daemon: "
    ($daemon &) &
    retval=$?
    echo
    [ $retval -eq 0 ]
    return $retval
}

stop() {
    echo -n $"Stopping POST-daemon: "
    pid=$(cat $pidfile)
    kill $pid
    rm -f $pidfile
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    stop
    start
}

rh_status() {
    status $prog
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        restart
        ;;
    status)
        rh_status
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart}"
        exit 2
esac

Решение слегка костылеподобное, но рабочее. Нагрузка на IIS упала, скорость отдачи страниц клиенту возросла. Отмечу, что все картинки сайта лежат на отдельном сервере и кешированию не подлежат.

Локальный прокси-сервер для фильтрации браузерного трафика / Хабр

Хочу рассказать о процессе разработки и поделиться прокси-сервером, которым сам пользуюсь для фильтрации всяческого мусора и других задач, требующих просмотра или вмешательства в браузерный траффик. Возможно, аналогичный функционал уже где-то есть, но мне хотелось сделать конкретно под свои нужды с возможностью real-time дописывания кода под любую сиюминутно понадобившуюся мелочь. Ну и под не-мелочи тоже, но это уже дольше.

Первоначально была задача упростить посещение сайтов через медленное (около 5-10кбайт/с с лагами) подключение. Тут два основных направления: 1) вырезать всё что не нужно (в первую очередь рекламу), и 2) закешировать всё что можно закешировать без особого вреда для функционала посещаемых сайтов, даже когда сами сайты не разрешают кеширование в http-заголовках, а то и явно препятствуют ему, дописывая после урлов статических файлов знак вопроса с рандомным числом.

Предупреждение: реализация, описанная ниже, делалась для Linux-а, вроде бы работает на других *nix, но даже компиляция её на винде не рассматривалась (хотя возможность адаптировать, конечно, есть).

Черновой вариант: nginx + php-fpm

Тратить на всё это время не хотелось, поэтому было решено по-быстрому настроить связку nginx + php-fpm, из которых первый разбирал входящие подключения, включая https и перенаправлял их все, без разбора хостов и урлов, в один и тот же php-скрипт. Так же была маленькая программа на C, которая конвертировала http-proxy-протокол в обычный http(s)-трафик. То есть превращала запросы GET http://host/path HTTP/1.x в GET /path HTTP/1.x (имя хоста всё равно есть в Host-заголовке) и проксировала все https CONNECT’ы на локальный nginx. Как потом выяснилось, убирать http://host из http-запросов было не обязательно, nginx их принимает так же как и обычные.

PHP-скрипт, в свою очередь, собирал назад разложенный по разным переменным запрос, через fsockopen() подключался к целевому серверу (благо там поддержка SSL встроенная), слал собранный http-запрос, забирал ответ и отправлял его браузеру с помощью header() и echo. Скрипт делался не совсем с нуля, спасибо некоей Évelyne Lachance за https://github.com/eslachance/php-transparent-proxy (но всё же то, что по ссылке, имеет несколько другую цель и поэтому просто скопировать его было нельзя).

Тут возникли две проблемы

Во-первых, если собрать сам исходный URL труда не представляло, то содержимое POST-запросов собирать было уже сложнее, а если там ещё и необычный Content-Type и отправка файлов — то php-шный парсер почти необратимо терял исходные данные, собрать всё это назад из массива $_POST[] и уже залитых в серверную файловую систему загруженных файлов, ничего не потеряв, было почти нереально (по крайней мере по моей оценке). Но спасла положение весьма кстати появившаяся в php 5.4 опция enable_post_data_reading — если её поставить в off, то тело запроса парситься не будет и его можно будет просто прочитать блобом из файла ‘php://input’. При этом массивы $_POST и $_FILES, естественно, не будут инициализироваться, но они нам и не нужны.

Во-вторых, nginx не умеет генерить сертификаты на лету из коробки, а настройку «игнорировать все проблемы с сертификатами» я в firefox не нашёл. Проблема была на тот момент решена патчем браузера, заставлявшим его любой сертификат считать доверенным и подходящим. Наверно были и другие способы это сделать, но все они казались сложнее. Патч естественно был кривой и сделанный почти методом тыка (желания изучать весь браузерный код проверки сертификатов не было), но он делал своё дело, а больше было и не надо.

Между сборкой исходного запроса и отправкой проксированного тривиальным образом были добавлены два куска кода. Один проверял, что host или host/path не из чёрного списка (организованного в виде отдельного php-файла с массивом внутри). Второй проверял, нет ли страницы в кеше (если есть — отдаётся из кеша). Если страницы в кеше нет, то делается проксированный запрос. Если запрос был GET и статус ответа 200, то полученная страница — кандидат на запоминание в кеше. Запоминать или нет — решалось функцией, которая по хосту, урлу (там просто были прописаны конкретные адреса, которые меня интересовали и которые я знал что надо кешировать) и content-type выносила вердикт. Кешировалось немного: http-статус, content-type и тело ответа. И при отдаче из кеша, соответственно, отдавались только эти данные, а все остальные заголовки, которые были в исходном ответе, безвозвратно терялись.

Вот такая грубая и костыльная реализация, на удивление, вполне себе работала, хотя конечно артефакты её присутствия время от времени проявлялись и раздражали.

В следующие полгода использования система дорабатывалась под решение возникающих проблем (как проблем из-за общей её кривости, так и проблем — возникающих задач).

Ещё через 3-4 месяца мне надоело патчить браузер после каждого апдейта и было решено сделать всё по-нормальному — nginx и php выкидываем и пишем всё на C.

Итоговый вариант

Маленькая программа (из старой версии), которая разбирала и перенаправляла прокси-протокол, была взята за основу. Первоочерёдной задачей было реализовать в ней разворачивание https, потому что всё остальное в общем-то уже известно как делать (делалось не раз в другим проектах), а с SSL где-то кроме php я на тот момент ни разу не работал.

Для этого взял библиотеку OpenSSL. Весь код, её использующий, было решено выделить в отдельные процессы. Потому что, во-первых, в ней тогда постоянно находились дыры (а межпроцессная изоляция может эту проблему иногда сгладить), во-вторых так проще делать (модульность и инкапсуляция на уровне сокетов), и в-третьих API OpenSSL местами весьма странное (мягко говоря), и для нейтрализации последствий то ли кривого API, то ли неправильного его применения (вследствие отсутствующей или двусмысленной документации) удобно просто убивать ssl-процесс после того как соединение завершилось (к сожалению, это плохо сказывается на производительности, но я с этим смирился).

Жалобы на OpenSSL и на SSL

Вообще, из-за регулярных уязвимостей и невнятного API я даже собирался написать свою реализацию TLS, и даже начал, но, дойдя до парсинга сертификатов (увы, без этого почти ничего не сделать, ибо сертификаты оказывается используются не только для защиты от подмены сервера, но и для согласования ключей, даже если защита от подмены не нужна), испытал ещё один дискомфорт от спецификации ASN1. Стало понятно, что API библиотеки это только вершина айсберга, а внутри оно всё такое уже начиная с RFC самого протокола. Хотя в последнее время я более менее с этим всем смирился.

SSL/TLS-обёртки

Итак, были сделаны две вспомогательные программы, одна для заворачивания клиентского нешифрованного сокета в SSL/TLS, и вторая для разворачивания зашифрованного сокета, принятого сервером, в незашифрованный. Принцип простой: у подпрограммы есть наследуемые от родительской программы файловые декрипторы, которые родительская программа может заранее открыть нужным образом так, что дочерний процесс будет выглядеть для неё просто сокетом, в который можно записывать и из которого можно читать. При этом практически никакого отличия этого межпроцессного сокета от сокета интернетного не будет.

Таким образом, сервер принимает (accept) входящее подключение, выясняет что на той стороне хотят SSL/TLS, после чего отдаёт соединение дочернему процессу (который поднимает SSL/TLS-сессию, генерирует сертификат если нужно или берёт уже ранее сгенерированный), а от дочернего процесса берёт межпроцессный сокет, через который передаются уже нешифрованные данные. В итоге весь дальнейший код может вообще не делать различий между http-соединением и https-соединением, прозрачно расшифровывающимся дочерним процессом, и использовать для работы с этими соединениями обычные функции для работы с сокетами.

Аналогично и на клиентской стороне, только в обратную сторону: клиент запускает дочерний шифрующий процесс, шлёт данные в межпроцессный сокет, а дочерний процесс уже обеспечивает их шифрование прозрачно для клиента.

Программы названы ssl-server-wrapper и ssl-client-wrapper. Кстати, второй можно запустить и отдельно вручную — тогда нешифрованный канал будет направлен в терминал, откуда его запустили, а установить SSL-соединение можно, набрав несколько простых команд.

Пример

Пишем

$ host ya.ru                        - узнаём ip-адрес
ya.ru has address 87.250.250.242
$ ./ssl-client-wrapper
T/etc/ssl/certs/ca-certificates.crt    - указать место где хранятся доверенные RootCA
C87.250.250.242:443/ya.ru              - подключиться по указанному адресу с указанным SNI

Ответ (много отладочных логов, можно скомпилировать чтобы было без них): дамп сертификата и предоставленной цепочки

DEBUG: cert[-1] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[-1] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[0] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[0] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] subject = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] issuer = /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] subject = /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] issuer = /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA

Попытка собрать trusted цепочку

DEBUG: cert[-1] issued by cert[1]
DEBUG: cert[1] issued by cert[2]
DEBUG: cert[2]=cert[*0] was not issued by something from trusted-cert-store - chain incomplete, trying to recover
DEBUG: cache miss at ./cert-pin/cache/9nqv0qm41tlxyel95bbods0famxjagbx.0
DEBUG: downloading AIA issuer cert: http://repository.certum.pl/ca.cer
DEBUG: cert[*0] issued by cert[*1]
DEBUG: cert[*1] is self-signed, chain ended

Как видно, «Certum CA» нет в списке доверенных Root CA, поэтому на первый взгляд это обрыв цепочки, но во втором сертификате цепочки (cert[2]) нашлась ссылка http://repository.certum.pl/ca.cer откуда можно скачать этот неизвестный сертификат; сертификат скачан (cert[*1]), но оказался самоподписанным и таким образом ничему не помогающим. На самом деле, в Root CA есть «Certum Trusted Network CA», так что всё в порядке и можно было ничего не скачивать.

Проверка соответствия доменного имени:

DEBUG: check wildcard '*.yandex.az' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ua' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.de' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard '*.xn--d1acpjx3f.xn--p1ai' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ge' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.kz' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.aero' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ee' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.com' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lv' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.az' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'ya.ru' against needed name 'ya.ru'

Итог:

DEBUG: protocol = TLSv1.2
DEBUG: cipher = ECDHE-RSA-AES128-GCM-SHA256
DEBUG: verify_result = 0
DEBUG: server_cert subject: /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: server_cert issuer: /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
OK: connection to 87.250.250.242:443/ya.ru established

Теперь есть прозрачное подключение, шлём http-запрос и получаем ответ

GET / HTTP/1.0
Host: ya.ru
Connection: close

HTTP/1.1 200 Ok
Accept-CH: Viewport-Width, DPR, Device-Memory, RTT, Downlink, ECT
Accept-CH-Lifetime: 31536000
(...)

Основной функционал

С шифрованием разобрались, теперь можно приступить к обработке полезной нагрузки.

Так как nginx у нас больше нет, то парсинг запроса придётся реализовывать заново. В целом ничего сложного тут нет, сначала парсятся заголовки через \r\n или \n разделитель, до тех пор пока не встретится пустая строка, а затем, если был заголовок Content-Length, читается тело запроса указанного количества байт. Chunked encoding в запросах можно и не поддерживать — никакие нормальные браузеры, да и вообще http-клиенты, его не генерируют.

После того, как запрос распарсен, он попадает в обработчик запроса — это та часть, которая раньше была написана на php, весьма увеличившаяся в размерах и количестве файлов. И хотя списки правил (кого блокировать, кого кешировать, кому резать куки и т.д.), ранее бывшие оформлены в виде php-массивов и коротких скриптовых функций, были переделаны в отдельные текстовые файлы специального удобного формата, но часть «пользовательской» логики всё ещё защита в коде (только теперь на C а не PHP), а код в целом унаследовал много признаков «сделать побыстрее как-нибуть» от своего предшественника. Сейчас обработчик (кроме капитально переделанных списков правил) всё так же сделан в виде одного «потока» кода из «главного» файла и вставленных в него include (не заголовочных файлов а сам код).

Изначально функционал обработчика был даже чуть меньше чем функционал последней из старых версий, но за 2 года плавно набрал ещё много нового. Из последнего — последние полгода-год всё чаще стали попадаться сайты с неполными цепочками сертификатов (потому что браузеры теперь их поддерживают без ругани), сначала я их просто вносил в белый список исключений, но это стало происходить слишком часто и пришлось реализовать кеширование и докачивание недостающих сертификатов в цепочке.

Что получилось

1. Отдельные модули для разворачивания шифрованного SSL/TLS-туннеля, один из которых при желании можно использовать как самостоятельную программу типа ssl-telnet. Ещё можно заменить их на какие-то альтернативные реализации (например с другой крипто-библиотекой), при этом остальная часть прокси ничего не заметит. Аналогично с инкрементальными обновлениями, ничего даже не нужно перезапускать. А ещё можно их использовать как демки по работе с OpenSSL (я прочёл много документации и всяких обсуждений в процессе их написания, возможно кто-то сможет теперь всё это быстрее усвоить). Код старался делать максимально понятным и простым.

   • У клиента есть хранилище сертификатов для: белый список по сайтам (принимать и не проверять), чёрный список по сайтам (не проверять и не принимать), список вопросов (те, которые не входят ни в белый, ни в чёрный и не прошли валидацию — аналог браузерной страницы с предложением внести подозрительный сертификат в список исключений). Для сайтов можно включать режим белого списка (то есть принимать только сертификаты из него, остальные считать недоверенными). К сожалению, всё это делается путём манипуляций над файлами, интерактивного приложения пока нет.
   • Серверная часть сама генерирует сертификаты ко всем сайтам на лету, ей нужен только корневой сертификат, добавленный как trusted root CA в браузер.

2. Возможность пробросить точку выхода в интернет через, например, ssh port forwarding (связанный с этим функционалом код расположен в helpers/remote.c и в proxy.c в месте где обрабатывается аргумент «—proxy». Это не тоже самое что запустить само прокси на удалённом сервере. Тут важно что кеш и расшифровка SSL/TLS находятся на локальном компе, а пробрасывается только «внешний» конец. Хотя я давно не проверял работу этого режима, могла и сломаться.

3. Единообразный формат файлов правил для: блокировки загрузки страниц, блокировки куков, управления кешированием, включения сниффера, включения raw-режима (для real-time стримингов).

4. Аналог /etc/hosts но усовершенствованный: возможность сопоставления айпи-адреса не только по хосту, но и по порту и по протоколу, а так же сменить порт и протокол подключения.

5. Кеш, управляемый прописанными ему настройками, а не заголовками, присланными сервером. Заголовки управления кешированием часто не отражают действительность (или отражают мнение владельца сайта, которое может расходиться с критериями удобства пользования этим сайтом), поэтому сейчас они игнорируются. Думаю что стоит сделать их учёт по принципу «если сайт разрешил кешировать то значит можно, а если нет — разбираемся сами можно или нельзя», но пока руки не дошли. Кеш хранится в интуитивно понятно организованном дереве директорий, хранится бессрочно, но можно либо вручную удалять отдельные сохранения, либо настройкой задать «игнорировать всё что сохранено раньше такого-то времени».

   • Кроме кеша есть ещё сохранения — это те страницы, которые не берутся с диска при запросе к ним, но на всякий случай всё равно сохраняются. При включении оффлайн-режима они тоже смотрятся (в файл offline.flag надо прописать предпочтительное время, за которое будут искаться сохранённые страницы при обращении к ним). При настройке сохранений учтите, что, несмотря на то, что сохраняются только ответы (содержимое POST-запросов не сохраняется), в них всё же могут быть некоторые данные, которые стоит беречь от кражи, а сохранённые на диске страницы — дополнительный вектор атаки.

6. Возможность кастомных действий перед, после или вместо загрузки страницы проксированным запросом. Реализваны хардкодом, файл handle/inc.rewrite.c

7. Есть dashboard (двоичный файл со статусами всех потоков прокси) и программа для его вывода на экран в удобном виде.
   ./dashboard --basedir=/path/to/proxy/base --highlight --loop

8. Любой аспект работы прокси можно легко переделать при необходимости. Код, несмотря на то, что он весьма разросся по сравнению с первыми версиями, всё ещё занимает очень мало места, и не потребует много времени как на первоначальное изучение, так и на освежение в памяти забытых деталей. С другой стороны, кому-то это и минус — для пользования всеми возможностями программы предполагается её регулярная пересборка и правка кода, а не «скомпилировал и удалил исходники».

Плюсы и минусы

(+) Модульность

(-) Из-за изоляции OpenSSL работает медленнее чем могло бы

(+) Гибкая настраиваемость под конкретные нужды

(+-) Много настроек прямо в исходном коде в виде #define и не только

(+-) IPv6 не поддерживается

(-) Нет интерактивного приложения для настройки и управления

(-) Код местами весьма плох и костылен

(-) До сих пор нет поддержки Access-Control-Allow-Origin с не ‘*’ в закешированных ответах — но единственное что у меня от этого ломалось это интерфейс мэйлру почты.

(-) До сих пор нет поддержки учёта настроек кеширования, присылаемых сервером

(-) Скачивать через него большие файлы (не в raw режиме) неэффективно — сначала прокси скачает файл себе на диск, затем будет через localhost-сеть отдавать его браузеру, который опять будет сохранять его на диск, а ещё там где-то (а может и в нескольких местах) прописано ограничение в 10мбайт на запрос

Как собрать/установить и технические детали кода

Из обычных библиотек используются стандартная C-библиотека, zlib (для распаковки gzip http-ответов), openssl (линкуется только к ssl-подпрограммам). В случае с Debian это были пакеты zlib1g-dev и libssl-dev. Так же используются свои библиотеки (маленькие) с кодом который мне часто оказывается нужен в разных местах и поэтому вместо регулярного копипаста выделен в отдельные компилируемые единицы.

В целях данной публикации, для упрощения всё это собрано в один пакет (скачать можно тут) и обёрнуто в один сборочный скрипт (да, не Makefile, так уж вышло что пока я обхожусь без make) build-all.sh.

Ряд настроек расположен в исходниках: в скрипте fproxy/build2.sh, в файле fproxy/config.h (если у вас файл с бандлом доверенных центров сертификации расположен не в /etc/ssl/certs/ca-certificates.crt то надо этот путь заменить тут). Настройки подпрограмм (helpers/) расположены прямо в их коде вверху в виде #define (config.h они не используют), но их менять вряд ли кому потребуется.

То, что некоторая часть настроек прописана в компилируемом коде, а не в файлах настроек сделано для (моего) удобства. В файлах настроек настраивается то, что можно назвать наиболее часто меняющимися пользовательскими настройками (списки правил), а всё остальное — в общем то первоначальная настройка программы при её установке, и крайне редкие изменения всяких технических параметров (даже чаще меняется логика работы кода чем #define-настройки). По факту сейчас вполне рабочая версия получается если просто запустить build-all.sh и не трогать никакие исходники перед этим.

Но переделать код на приём настроек через командную строку или из ещё одного файла конфигурации несложно.

Для работы прокси нужна заранее подготовленная структура директорий. Для её создания есть скрипт prepare-dir.sh — он создаёт рядом подготовленную директорию fproxy-target/ со всем что требуется и кладёт туда примеры правил (в том числе много блокировок спамных доменов).

Насчёт прав доступа и вообще безопасности

Простейший вариант установки — запустить всё из под своего обычного юзера с обычными правами на всё (можно даже прямо из директории fproxy-target/, созданной скриптом prepare-dir.sh).

Но по ряду причин имеет смысл сделать по-другому. Для прокси создаётся отдельный юзер и группа, ему выдаются эксклюзивные права на чтение данных прокси, и права на запись в несколько мест, где они нужны. Права «только чтение» можно реализовать, поставив владельца root и группу прокси, и поставив доступ 0640 или 0750. Делать что бы то ни было из данных world-readable в любом случае плохая идея, всё же там лежит вся история браузера, а где-то и сохранённое содержание страниц, а так же ключи, с помощью которых браузеру можно делать MITM.

Для работы программы dashboard ей нужен только доступ на чтение к файлу BASE/log/dashboard и ничего другого.

По умолчанию прокси слушает 127.0.0.10:3128. Для работы с 127.0.0.10 у меня ничего специально настраивать (в ОС) не пришлось, но возможно в каких-то системах нужно.

Рабочая директория по умолчанию — та, что была текущей при запуске, но это можно поменять в настройках.

Заключение

Ещё раз ссылка на скачивание: тут.

Для публикации код был дооформлен в такой вид, который на мой взгляд допустимо публиковать, но всё же делалось это исключительно для себя под локальное применение и «по-быстрее», так что сейчас код во многих местах не образец для подражания. Но основную задачу он выполняет, а со временем будет улучшаться.

Из наиболее приоритетных на данный момент планов на будущее в плане функционала — сделать интерактивную настройку и управление (сертификаты, кеш, история, менеджер загрузок больших файлов) либо отдельным приложением, либо в спецдомене через браузер, но ничего не обещаю.

Надеюсь, что кому-то это всё окажется интересным и так или иначе поможет.

Apache Traffic Server — уникальный кеширующий прокси-сервер для CDN / Хабр

Однажды возникла идея запустить русско-язычную версию популярного американского сайта. После недолгих размышлений было решено реализовать полностью интерактивную схему вида examplesite.com — > examplesite-ru.com и заставить машину делать как можно больше работы.

Некоторое изучение и эксперименты с различными прокси-серверами привели к интересному продукту — Apache Traffic Server, о котором я и хочу рассказать.

Traffic Server был изначально создан Inktomi Corporation, которая была куплена компанией Yahoo! в 2002 году. Долгое время продукт активно коммерчески использовался как внутри Yahoo!, так и на некоторых очень больших сайтах. С 2009 года проект открыл исходные коды и передал их в инкубатор Апача, а уже в апреле 2010 года появился Apache Traffic Server.

Подробно о сравнении ATS с другими кеширующим и балансирующими серверами можно почитать тут.

Коротко скажу лишь, что архитектура ATS превосходит по масштабируемости такие заслуженные аналоги, как Ngnix, HAproxy и Squid при том что каждый из перечисленных продуктов специализирован, в то время как ATS может больше (кроме пожалуй Squid, который умеет еще больше, но на порядок медленнее). Серьезная заявка? Нужно попробовать!

Установка ATS

В силу своей новизны документация проекта оставляет желать лучшего. Обилие конфигурационных директив, ужасающая куча файлов в etc/, недоделанная wiki и отсутствие пошагового мануала сначала напугали. Но затем я нашел замечательную презентацию Тома Мелендеза из Yahoo! и всё встало на свои места.

Дальнейшие настройки проводились на Centos 5.5 x64.

Шаг 1. Скачиваем дистрибутив ATS.
[root@Srv1 ~]# wget www.sai.msu.su/apache//trafficserver/trafficserver-2.1.5-unstable.tar.bz2

Шаг 2. Проверяем наличие необходимых библиотек
[root@Srv1 ~]# yum list autoconf automake libtool gcc-c++ glibc-devel openssl-devel tcl-devel expat-devel db4-devel pcre-devel

Шаг 3. Скорее всего придется поставить некоторые пакеты, в моем случае потребовались tcl-devel и pcre-devel. Без этого шага компиляция будет завершаться с ошибкой. Для пользователей Debian-based дистрибутивов набор компонентов слегка отличается и он описан в файле README.

Шаг 4. Распаковываем архив и переходи в директорию
[root@Srv1 ~]# tar -xjf trafficserver-2.1.5-unstable.tar.bz2

[root@Srv1 ~]# cd trafficserver-2.1.5-unstable

Шаг 5. Компилируем.

По умолчанию prefix==»/usr/local» чего достаточно для тестов
[root@Srv1 trafficserver-2.1.5-unstable]# ./configure [--prefix=PREFIX]

[root@Srv1 trafficserver-2.1.5-unstable]# make install

Настройка ATS

Напомню главную заповедь Тома Мелендеза: «Я РЕАЛЬНО ЛЕНИВЫЙ!»

Теперь опишу настройки для выполнения нашей задачи.

Шаг 1. Открываем /usr/local/etc/trafficserver/records.config
CONFIG proxy.config.proxy_name STRING examplesite-ru.com

CONFIG proxy.config.http.server_port INT 80

CONFIG proxy.config.reverse_proxy.enabled INT 1

Шаг 2. /usr/local/etc/trafficserver/remap.config
map examplesite-ru.com/ examplesite.com/

reverse_map examplesite.com/ examplesite-ru.com/

Шаг 3. Из чистого любопытства посмотрим /usr/local/etc/trafficserver/storage.config

И видим что ленивый Том добавил маленький кусочек диска в 256 Мбайт достаточный для тестов: var/trafficserver 256M

Запуск ATS

Запускается сервис командой
[root@Srv1 ~]# /usr/local/bin/trafficserver

Конфигурация обновляется командой
[root@Srv1 ~]# /usr/local/bin/traffic_line -x

Бинго!

Как видим для запуска действительно нужно минимум усилий.

Мой тестовый сервер сделан из самого маленького компьютера на базе Intel Atom 525, который подключен в интернет каналом со скоростью 1 мбит в секунду. Мой тестовый сайт имеет главную страницу размером примерно 85 Кбайт. Он при каждом обращении генерит уникальный Session ID (это всегда вводит в ступор качалки сайтов типа TeleportPro и разнообразные прокси).

Нетрудно посчитать, что обычный некеширующий реверс-прокси потратит только примерно 0,7 секунд на скачиваение страницы, потом 0,7 секунд на ее отдачу, а так же время на «проксификацию» содержимого.

В случае ATS дополнительная задержка при полной загрузке страницы составляет на круг значительно менее 1 секунды, а загрузка процессора попросту незаметна. Попеременно запуская загрузку сайта напрямую и через ATS я обратил внимание что довольно часто прокси отдает страницу быстрее оригинала! Как видим 8 лет эксплуатации на серверах Yahoo в роли CDN не пропали даром.

Вернемся к началу

Идея создания зеркала сайта никого не удивит, но в моих планах она должна быть дополнена системой автоматизированного перевода на русский язык текстов и графики с помощью… (в этом месте пока только вопросы). Такая система может быть подключена при помощи
плагина трансформации HTTP.

Лучшие прокси серверы Linux | Losst

В современных сетях прокси серверы используются достаточно часто. Особенно они полезны на предприятиях, здесь кэширующие прокси серверы могут применяться для снижения нагрузки на сеть, увеличения пропускной способности, экономии трафика и даже для отслеживания действий пользователей и блокировки нежелательных сайтов.

Другая сфера применения прокси серверов — это веб-сайты. Они используются для кэширования сгенерированных страниц, чтобы ускорить загрузку сайтов. В этой статье мы рассмотрим лучшие прокси серверы для linux, которые вы можете использовать в своих конфигурациях.

Содержание статьи:

1. Squid

Squid — это лучший прокси серевер для Linux с поддержкой таких протоколов, как: HTTP, HTTPS, FTP и многих других. Он позволяет повысить пропускную способность сети и сократить время отклика сайтов путем кэширования ресурсов и страниц. Страницы и файлы, которые запрашиваются часто могут быть использованы повторно. Вы можете настроить кэширование как в оперативную память, так и на жесткий диск, если нужно кэшировать много данных при медленном интернете.

Кроме того, в Squid есть очень широкие возможности контроля доступа к сетевым ресурсам. Вы можете блокировать не только банальные запросы к доменам или загрузку файлов определенных форматов, но и доступ к сети в определенное время, работу протоколов и портов, а также многое другое. Squid поддерживает не только операционную систему Linux, но и Windows. Изначально программа могла работать только в Linux, но затем была портирована и для Windows. Мы уже рассматривали настройку Squid в Ubuntu в одной из предыдущих статей.

2. Privoxy

Это еще один кэширующий прокси сервер linux, который устанавливается на стороне клиента. Поддерживаются все основные веб-протоколы. Но он направлен больше не на кэширование контента, а на фильтрацию и защиту конфиденциальности пользователей. С помощью него вы можете изменять интернет-страницы, вырезать рекламу, управлять cookies, ограничивать доступ к некоторым веб-сайтам, а также удалять любой нежелательный контент, управлять отправляемыми заголовками браузера.

В отличие от Squid программа настраивается через веб-интерфейс, и надо сказать, что достаточно удобный. Хотя в некоторых пунктах можно запутаться. При включенном прокси его настройка будет доступна по адресу config.privoxy.org. Кроме веб-интерфейса, можно использовать конфигурационный файл, но он намного сложнее.

3. Polipo

Небольшой, но быстрый кэширующий прокси сервер с открытым исходным кодом, поддерживающий протокол HTTP и DNS. Polipo можно использовать для фильтрации рекламы, повышения приватности или ускорения работы веб-сайтов с помощью кэширования страниц. Также как и Privoxy она рассчитан больше на обеспечение приватности. Настройка программы выполняется через веб-интерфейс, но кроме него, есть несколько графических оболочек, для интерактивного взаимодействия с программой. Поддерживается как Linux, так и Windows.

4. TinyProxy

TinyProxy — это очень простой и легкий прокси сервер с открытым исходным кодом для операционных систем Unix. Он разработан, чтобы быть маленьким и очень быстрым и поддерживает протоколы HTTP и HTTPS. Несмотря на легковесность этот прокси сервер linux поддерживает все необходимые функции, такие как удаленный доступ с помощью веб-интерфейса, фильтрация доступа к ресурсам, фильтрация на основе URL и другое.

5. ExaProxy

Этот прокси сервер предназначен не для кэширования трафика, а для его модификации. Поддерживается модификация трафика с помощью удобного языка программирования по протоколу HTTP. Все соединения HTTPS могут быть пропущены без изменения с помощью метода Connect. Прокси сервер linux работает очень быстро и имеет веб-интерфейс для доступа к статистике его работы и настройке.

6. Gate.js

Gate.js — это что-то новое и очень интересное. Это полнофункциональный кэширующий прокси сервер, написанный на JavaScript с использованием Node.js. Он написан с нуля и призван заменить Squid и Nginx. Он позволяет кэшировать контент, облегчая работу веб-серверам, а также ускоряя загрузку сайтов на стороне клиента. Его главная особенность в масштабируемости, поскольку программа написана на интерпретируемом языке, она может быть легко дополнена.

7. Artica Proxy

Artica Proxy — это мощный, но простой прокси сервер с открытым исходным кодом, который позиционирует себя как полноценная замена для Squid. Программа поддерживает фильтрацию интернет-трафика, фильтрацию запросов DNS, защиту от вирусов и спама, создание правил кэширования, а также аутентификацию через ACL списки.

Кроме того, здесь есть очень подробная страница статистики, с помощью которой вы сможете узнать все о работе программы и нагрузке на сеть.

8. Varnish Cache

В отличие от вышеперечисленных программ, этот прокси сервер рассчитан больше для работы на стороне сервера. Он предназначен для ускорения веб-сайтов. Его современная архитектура дает ему значительную производительность. Varnish Cache хранит веб-страницы в памяти сервера, чтобы программа веб-сервера Apache или Nginx не генерировала ее еще раз. Веб-сервер только обновляет страницы при изменении содержимого. Получение содержимого из памяти выполняется намного быстрее чем полная генерация.

9. Nginx

Все знают Nginx как отличный веб-сервер, рассчитанный на работу под большой нагрузкой. Но кроме этого, он может использоваться в качестве прокси сервера. Nginx не умеет кэшировать или фильтровать содержимое страниц. Но его задача принимать запросы от клиентов на сервере, передача их другим программам, а затем возврат ответа клиенту. Nginx выгодно использовать, потому что эта программа оптимизирована для максимальной производительности и может принимать до 10 000 запросов от пользователей одновременно.

Выводы

В этой статье мы рассмотрели лучшие прокси серверы Linux, возможно, это далеко не все программы, которые стоило бы добавить в этот список. Какие прокси серверы вы используете в своих системах? Какие считаете лучшими? Напишите в комментариях!

Proxy Caching Advanced
плагин | Kong

Этот плагин обеспечивает реализацию кэша обратного прокси для Kong. Он кэширует объекты ответа на основе настраиваемого кода ответа и типа содержимого, а также метода запроса. Он может кэшировать для каждого потребителя или для каждого API. Сущности кэша хранятся в течение настраиваемого периода времени, после которого последующие запросы к тому же ресурсу будут повторно извлекать и повторно сохранять ресурс. Сущности кеша также могут быть принудительно очищены через Admin API до истечения срока их действия.

Ссылка на конфигурацию

Вы можете настроить этот плагин с помощью
Kong Admin API
или через декларативную конфигурацию, которая включает непосредственное редактирование
конфигурационный файл Kong.

Включение подключаемого модуля в службе

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин в Сервисе,
сделав следующий запрос:

  $ curl -X POST http: // : 8001 / services /  / plugins \
    --data "name = proxy-cache-advanced" \
    --data "config.стратегия = память "
  

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  имя: 
config:
  стратегия: память
плагин: proxy-cache-advanced
  

Затем примените ресурс KongPlugin к
Сервис, аннотируя Сервис как
следует:

API

  Версия: v1
вид: Сервис
метаданные:
  имя: <услуга>
  ярлыки:
    приложение: <услуга>
  аннотации:
    плагины.konghq.com: 
спецификации:
  порты:
  - порт: 80
    targetPort: 80
    протокол: TCP
    имя: <услуга>
  селектор:
    приложение: <услуга>
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин в Сервисе,
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: proxy-cache-advanced
  услуга: <услуга>
  config:
    стратегия: память
  

— это id или имя Сервиса, который этот плагин
конфигурация будет нацелена.

Примечание: Устаревшая сущность API устарела в пользу Services
поскольку
CE 0.13.0 и
EE 0,32.

Включение плагина на маршруте

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин на Маршруте с:

  $ curl -X POST http: // : 8001 / routes /  / plugins \
    --data "name = proxy-cache-advanced" \
    --data "config.стратегия = память "
  

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  имя: 
config:
  стратегия: память
плагин: proxy-cache-advanced
  

Затем примените его к входу (Маршрут или Маршруты)
путем аннотирования входа следующим образом:

  apiВерсия: сеть / v1beta1
вид: Ingress
метаданные:
  имя: <маршрут>
  аннотации:
    кубернетес.io / ingress.class: kong
    plugins.konghq.com: 
спецификации:
  правила:
  - хост: examplehostname.com
    http:
      пути:
      - путь: / бар
        бэкэнд:
          serviceName: echo
          servicePort: 80
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин на Маршруте по
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: proxy-cache-advanced
  маршрут: <маршрут>
  config:
    стратегия: память
  

— это id или , имя маршрута, для которого эта конфигурация плагина
будет нацеливаться.

Включение плагина на потребителе

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин на потребителе с:

  $ curl -X POST http: // <имя-админа>: 8001 / потребители / <потребитель> / плагины \
    --data "name = proxy-cache-advanced" \
    --data "config.стратегия = память "
  

Можно объединить consumer.id , service.id или route.id
в том же запросе, чтобы еще больше сузить область действия плагина.

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  имя: 
config:
  стратегия: память
плагин: proxy-cache-advanced
  

Затем примените его к Потребителю
аннотируя ресурс KongConsumer следующим образом:

  apiVersion: configuration.konghq.com/v1
вид: KongConsumer
метаданные:
  имя: <потребитель>
  аннотации:
    plugins.konghq.com: 
    kubernetes.io/ingress.class: конг
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин на потребителе с помощью
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: proxy-cache-advanced
  потребитель: <потребитель>
  config:
    стратегия: память
  

<потребитель> — это id или имя пользователя Потребителя, которое этот плагин
конфигурация будет нацелена.

Включение плагина глобально

Плагин, не связанный с какой-либо Услугой, Маршрутом или Потребителем, является
считается глобальным и будет запускаться по каждому запросу.Прочтите
Справка по плагину и приоритет плагина
разделы для получения дополнительной информации.

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин глобально с помощью:

  $ curl -X POST http: // <имя-хоста>: 8001 / plugins / \
    --data "name = proxy-cache-advanced" \
    --data "config.strategy = memory"
  

Создание плагина KongClusterPlugin
ресурс и пометьте его как глобальный:

  apiVersion: configuration.konghq.com/v1
вид: KongClusterPlugin
метаданные:
  имя: 
  аннотации:
    kubernetes.io/ingress.class: конг
  ярлыки:
    глобальный: \ "правда \"
config:
  стратегия: память
плагин: proxy-cache-advanced
  

Например, настройте этот плагин, используя запись plugins: в декларативном
файл конфигурации:

  плагины:
- имя: proxy-cache-advanced
  config:
    стратегия: память
  

Параметры

Вот список всех параметров, которые можно использовать в конфигурации этого плагина:

Стратегии

kong-plugin-enterprise-proxy-cache разработан для поддержки хранения данных прокси-кеша в различных бэкэнд-форматах. В настоящее время предлагаются следующие стратегии:

• память : A lua_shared_dict . Обратите внимание, что словарь по умолчанию, kong_cache , также используется другими плагинами и элементами Kong для хранения несвязанных сущностей кэша базы данных. Использование этого словаря — простой способ начальной загрузки плагина proxy-cache-advanced, но он не рекомендуется для крупномасштабных инсталляций, поскольку значительное использование окажет давление на другие аспекты операций кэширования базы данных Kong.На данный момент рекомендуется определить отдельный lua_shared_dict через настраиваемый шаблон Nginx.
• redis : поддерживает развертывание Redis и Redis Sentinel.

Ключ кеша

Kong вводит ключи для каждого элемента кэша на основе метода запроса, полного запроса клиента (например, пути запроса и параметров запроса) и UUID API или потребителя, связанного с запросом. Это также означает, что кеши различны между API и / или потребителями.В настоящее время формат ключа кеша жестко запрограммирован и не может быть изменен. Внутренне ключи кэша представлены в виде суммы MD5 в шестнадцатеричном коде конкатенации составных частей. Это рассчитывается следующим образом:

  ключ = md5 (UUID | метод | запрос)
  

Где метод определяется через вызов OpenResty ngx.req.get_method () , а запрос определяется через переменную Nginx $ request . Kong вернет ключ кеша, связанный с данным запросом, как заголовок ответа X-Cache-Key .Также возможно предварительно вычислить ключ кеша для данного запроса, как указано выше.

Управление кешем

Когда включена опция конфигурации cache_control , Kong будет учитывать заголовки запросов и ответов Cache-Control, как определено в RFC7234, с несколькими исключениями:

• Повторная проверка кэша еще не поддерживается, поэтому такие директивы, как proxy-revalidate , игнорируются.
• Аналогично, поведение без кеширования упрощается, чтобы полностью исключить объект из кеширования.
• Вычисление вторичного ключа через Vary еще не поддерживается.

Состояние кэша

Kong определяет статус поведения кэша прокси-сервера запроса через заголовок X-Cache-Status . Для этого заголовка есть несколько возможных значений:

• Мисс : запрос может быть удовлетворен в кэше, но запись для ресурса не была найдена в кэше, и запрос был передан в восходящем направлении.
• Обращение : запрос был удовлетворен и обработан из кеша.
• Обновить : ресурс был найден в кэше, но не смог удовлетворить запрос из-за поведения Cache-Control или достижения жестко заданного порогового значения cache_ttl.
• Обход : запрос не может быть удовлетворен из кеша в зависимости от конфигурации подключаемого модуля.

Хранилище TTL

Kong может хранить объекты ресурсов в механизме хранения дольше, чем указывают предписанные значения cache_ttl или Cache-Control .Это позволяет Kong сохранять кэшированную копию ресурса по истечении срока его действия. Это позволяет клиентам, способным использовать заголовки max-age и max-stale , при необходимости запрашивать устаревшие копии данных.

Сбои в восходящем направлении

Из-за реализации в модели обработки запросов ядра Kong, на данном этапе плагин proxy-cache-advanced не может использоваться для обслуживания устаревших данных кеша, когда восходящий поток недоступен. Чтобы настроить Kong для обслуживания данных кэша вместо возврата ошибки, когда восходящий поток недоступен, мы рекомендуем определить очень большой storage_ttl (порядка часов или дней), чтобы хранить устаревшие данные в кеше.В случае сбоя в восходящем направлении устаревшие данные можно считать «свежими», увеличив значение конфигурации cache_ttl plugin. Таким образом, данные, которые раньше считались устаревшими, теперь обслуживаются клиентом до того, как Kong попытается подключиться к вышедшей из строя службе.

API администратора

Этот плагин предоставляет несколько конечных точек для объектов управляемого кэша. Эти конечные точки назначаются ресурсу proxy-cache-advanced RBAC.

В Admin API предусмотрены следующие конечные точки для проверки и очистки объектов кеша:

Получить объект из кэша

Доступны две отдельные конечные точки: одна для поиска известного экземпляра подключаемого модуля, а другая для поиска данного ключа кэша во всех хранилищах данных подключаемых модулей с расширенным прокси-кешем.Обе конечные точки имеют одинаковое возвращаемое значение.

Конечная точка

/ прокси-кеш-расширенный /: идентификатор_плагина / кэши /: идентификатор_кэша

Конечная точка

/ прокси-кеш-расширенный /: cache_id

Ответ

Если объект кеша существует

Если объект с данным ключом не существует

Удалить объект кеша

Доступны две отдельные конечные точки: одна для поиска известного экземпляра подключаемого модуля, а другая для поиска данного ключа кэша во всех хранилищах данных подключаемых модулей с расширенным прокси-кешем.Обе конечные точки имеют одинаковое возвращаемое значение.

Конечная точка

/ прокси-кеш-расширенный /: идентификатор_плагина / кэши /: идентификатор_кэша

Конечная точка

/ прокси-кеш-расширенный /: cache_id

Ответ

Если объект кеша существует:

Если объект с данным ключом не существует:

Очистить все объекты кэша

Конечная точка

/ прокси-кеш-расширенный /

Ответ

Обратите внимание, что эта конечная точка очищает все объекты кеша во всех подключаемых модулях proxy-cache-advanced .

.Кеширование

— Nginx proxy_no_cache и proxy_cache_bypass

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

Использование nginx в качестве обратного прокси-сервера

  map $ sent_http_content_type $ expires {
    эпоха "текст / HTML";
    "текст / html; charset = utf-8" эпоха;
    по умолчанию выключено;
}

server {
    слушать 80;
    имя_сервера ваш-домен;

    gzip дальше;
    gzip_types текст / обычное приложение / XML-текст / приложение css / javascript;
    gzip_min_length 1000;

    место расположения / {
        истекает $ истекает;

        proxy_redirect выключен;
        proxy_set_header Host $ host;
        proxy_set_header X-Real-IP $ remote_addr;
        proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
        proxy_set_header Схема X-Forwarded-Proto $;
        proxy_read_timeout 1 мин;
        proxy_connect_timeout 1 мин;
        proxy_pass http: // 127.0,0.1: 3000;
    }
}
  

Использование nginx со сгенерированными страницами и кеширующим прокси в качестве резервной копии:

Если у вас большой веб-сайт с регулярно меняющимся содержимым, вы можете воспользоваться возможностями генерации Nuxt и кешированием nginx.

Ниже приведен пример конфигурации. Имейте в виду, что:

• корневая папка должна быть такой же, как задано в конфигурации generate.dir
• Заголовки истечения срока действия, установленные Nuxt, удаляются (из-за кеширования)
• Nuxt as nginx может устанавливать дополнительные заголовки, рекомендуется выбрать один (если есть сомнения, выберите nginx)
• , если ваш сайт в основном статичный, увеличьте proxy_cache_path inactive и proxy_cache_valid номеров

Если вы не генерируете свои маршруты, но все же хотите использовать кеш nginx:

• удалить корень запись
• изменить местоположение @proxy { на местоположение / {
• удалить остальные 2 местоположения записи

  proxy_cache_path / data / nginx / cache levels = 1: 2 keys_zone = nuxt-cache: 25m max_size = 1g inactive = 60m use_temp_path = off;

map $ sent_http_content_type $ expires {
    "текст / html" 1ч;
    "текст / html; charset = utf-8" 1h;
    по умолчанию 7d;
}

server {
    слушать 80;
    имя_сервера ваш-домен;

    gzip дальше;
    gzip_types текст / обычное приложение / XML-текст / приложение css / javascript;
    gzip_min_length 1000;

    charset utf-8;

    корень / var / www / NUXT_PROJECT_PATH / dist;

    расположение ~ * \.(?: ico | gif | jpe? g | png | woff2? | eot | otf | ttf | svg | js | css) $ {
        истекает $ истекает;
        add_header Pragma public;
        add_header Cache-Control "общедоступный";

        try_files $ uri $ uri / @proxy;
    }

    место расположения / {
        истекает $ истекает;
        add_header Content-Security-Policy "default-src 'self' 'unsafe-inline';";
        add_header Strict-Transport-Security "max-age = 31536000; includeSubDomains; preload" всегда;
        add_header X-Frame-Options "SAMEORIGIN";

        try_files $ uri $ uri / index.html @   

.Кэш прокси

плагин | Kong

Этот плагин обеспечивает реализацию кэша обратного прокси для Kong. Он кэширует объекты ответа на основе настраиваемого кода ответа и типа содержимого, а также метода запроса. Он может кэшировать для каждого потребителя или для каждого API. Сущности кэша хранятся в течение настраиваемого периода времени, после которого последующие запросы к тому же ресурсу будут повторно извлекать и повторно сохранять ресурс. Сущности кеша также могут быть принудительно очищены через Admin API до истечения срока их действия.

Ссылка на конфигурацию

Вы можете настроить этот плагин с помощью
Kong Admin API
или через декларативную конфигурацию, которая включает непосредственное редактирование
конфигурационный файл Kong.

Этот плагин совместим с с режимом без DB.

В режиме без базы данных Kong не имеет API администратора. Если использовать это
mode, настройте плагин, используя декларативную конфигурацию.

Включение подключаемого модуля в службе

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин в Сервисе,
сделав следующий запрос:

  $ curl -X POST http: // <имя-хоста>: 8001 / services /  / plugins \
    --data "name = прокси-кеш" \
    --data "config.cache_ttl = 300" \
    --data "config.стратегия = память "
  

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  name: 
config:
  cache_ttl: 300
  стратегия: память
плагин: прокси-кеш
  

Затем примените ресурс KongPlugin к
Сервис, аннотируя Сервис как
следует:

API

  Версия: v1
вид: Сервис
метаданные:
  имя: <услуга>
  ярлыки:
    приложение: <услуга>
  аннотации:
    плагины.konghq.com: 
спецификации:
  порты:
  - порт: 80
    targetPort: 80
    протокол: TCP
    имя: <услуга>
  селектор:
    приложение: <услуга>
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин в Сервисе,
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: прокси-кеш
  услуга: <услуга>
  config:
    cache_ttl: 300
    стратегия: память
  

— это id или имя Сервиса, который этот плагин
конфигурация будет нацелена.

Включение плагина на Route

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин на Маршруте с:

  $ curl -X POST http: // : 8001 / routes /  / plugins \
    --data "name = прокси-кеш" \
    --data "config.cache_ttl = 300" \
    --data "config.стратегия = память "
  

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  name: 
config:
  cache_ttl: 300
  стратегия: память
плагин: прокси-кеш
  

Затем примените его к входу (Маршрут или Маршруты)
путем аннотирования входа следующим образом:

  apiВерсия: сеть / v1beta1
вид: Ingress
метаданные:
  имя: <маршрут>
  аннотации:
    кубернетес.io / ingress.class: kong
    plugins.konghq.com: 
спецификации:
  правила:
  - хост: examplehostname.com
    http:
      пути:
      - путь: / бар
        бэкэнд:
          serviceName: echo
          servicePort: 80
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин на Маршруте по
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: прокси-кеш
  маршрут: <маршрут>
  config:
    cache_ttl: 300
    стратегия: память
  

— это id или name Route, который эта конфигурация плагина
будет нацеливаться.

Включение подключаемого модуля на потребителе

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин на потребителе с:

  $ curl -X POST http: // <имя-хоста>: 8001 / потребители / <потребитель> / плагины \
    --data "name = прокси-кеш" \
    --data "config.cache_ttl = 300 "\
    --data "config.strategy = memory"
  

Можно объединить consumer.id , service.id или route.id
в том же запросе, чтобы еще больше сузить область действия плагина.

Сначала создайте KongPlugin
ресурс:

  apiВерсия: configuration.konghq.com/v1
вид: KongPlugin
метаданные:
  name: 
config:
  cache_ttl: 300
  стратегия: память
плагин: прокси-кеш
  

Затем примените его к Потребителю
аннотируя ресурс KongConsumer следующим образом:

  api Версия: конфигурация.konghq.com/v1
вид: KongConsumer
метаданные:
  имя: <потребитель>
  аннотации:
    plugins.konghq.com: 
    kubernetes.io/ingress.class: конг
  

Примечание: Ресурс KongPlugin необходимо определить только один раз.
и может применяться к любой Службе, Потребителю или Маршруту в пространстве имен. если ты
хотите, чтобы плагин был доступен для всего кластера, создайте ресурс как
KongClusterPlugin вместо KongPlugin .

Например, настройте этот плагин на потребителе с помощью
добавив этот раздел в декларативный файл конфигурации:

  плагины:
- имя: прокси-кеш
  потребитель: <потребитель>
  config:
    cache_ttl: 300
    стратегия: память
  

<потребитель> — это id или имя пользователя Потребителя, которое этот плагин
конфигурация будет нацелена.

Включение плагина глобально

Плагин, не связанный с какой-либо Услугой, Маршрутом или Потребителем, является
считается global и будет запускаться по каждому запросу. Прочтите
Справка по плагину и приоритет плагина
разделы для получения дополнительной информации.

Kong Admin API

Kubernetes

Декларативная (YAML)

Например, настройте этот плагин глобально с помощью:

  $ curl -X POST http: // <имя-хоста>: 8001 / plugins / \
    --data "name = прокси-кеш" \
    --data "config.cache_ttl = 300 "\
    --data "config.strategy = memory"
  

Создание плагина KongClusterPlugin
ресурс и пометьте его как глобальный:

  apiВерсия: configuration.konghq.com/v1
вид: KongClusterPlugin
метаданные:
  имя: 
  аннотации:
    kubernetes.io/ingress.class: конг
  ярлыки:
    глобальный: \ "правда \"
config:
  cache_ttl: 300
  стратегия: память
плагин: прокси-кеш
  

Например, настройте этот плагин, используя запись plugins: в декларативном
файл конфигурации:

  плагины:
- имя: прокси-кеш
  config:
    cache_ttl: 300
    стратегия: память
  

Параметры

Вот список всех параметров, которые можно использовать в конфигурации этого плагина:

Стратегии

kong-plugin-proxy-cache разработан для поддержки хранения данных прокси-кеша в различных бэкэнд-форматах.В настоящее время предлагаются следующие стратегии:

• память : A lua_shared_dict . Обратите внимание, что словарь по умолчанию, kong_cache , также используется другими плагинами и элементами Kong для хранения несвязанных сущностей кэша базы данных. Использование этого словаря — простой способ запустить плагин кэширования прокси, но он не рекомендуется для крупномасштабных инсталляций, так как значительное использование окажет давление на другие аспекты операций кэширования базы данных Kong.В настоящее время рекомендуется определить отдельный lua_shared_dict через настраиваемый шаблон Nginx.

Ключ кеша

Kong вводит ключи для каждого элемента кэша на основе метода запроса, полного запроса клиента (например, пути запроса и параметров запроса) и UUID API или потребителя, связанного с запросом. Это также означает, что кеши различны между API и / или потребителями. В настоящее время формат ключа кеша жестко запрограммирован и не может быть изменен.Внутренне ключи кэша представлены в виде суммы MD5 в шестнадцатеричном коде конкатенации составных частей. Это рассчитывается следующим образом:

  ключ = md5 (UUID | метод | запрос)
  

Где метод определяется через вызов OpenResty ngx.req.get_method () , а запрос определяется через переменную Nginx $ request . Kong вернет ключ кеша, связанный с данным запросом, как заголовок ответа X-Cache-Key .Также возможно предварительно вычислить ключ кеша для данного запроса, как указано выше.

Управление кешем

Когда включена опция конфигурации cache_control , Kong будет учитывать заголовки запросов и ответов Cache-Control, как определено в RFC7234, с некоторыми исключениями:

• Повторная проверка кэша еще не поддерживается, поэтому такие директивы, как proxy-revalidate , игнорируются.
• Аналогичным образом, поведение без кеширования упрощается, чтобы полностью исключить объект из кеширования.
• Расчет вторичного ключа с помощью Vary еще не поддерживается.

Состояние кеша

Kong определяет статус поведения кэша прокси-сервера запроса через заголовок X-Cache-Status . Для этого заголовка есть несколько возможных значений:

• Мисс : запрос мог быть удовлетворен в кэше, но запись для ресурса не была найдена в кэше, и запрос был передан в восходящем направлении.
• Обращение : запрос был удовлетворен и обработан из кеша.
• Обновить : ресурс был найден в кэше, но не смог удовлетворить запрос из-за поведения Cache-Control или достижения жестко заданного порогового значения cache_ttl.
• Обход : запрос не может быть удовлетворен из кеша в зависимости от конфигурации подключаемого модуля.

Хранилище TTL

Kong может хранить объекты ресурсов в механизме хранения дольше, чем указано в предписанных значениях cache_ttl или Cache-Control .Это позволяет Kong сохранять кэшированную копию ресурса по истечении срока его действия. Это позволяет клиентам, которые могут использовать заголовки max-age и max-stale , при необходимости запрашивать устаревшие копии данных.

Сбои в добыче

Из-за реализации в модели обработки запросов ядра Kong, на этом этапе плагин прокси-кеша не может использоваться для обслуживания устаревших данных кэша, когда восходящий поток недоступен. Чтобы оборудовать Kong для обслуживания данных кэша вместо возврата ошибки, когда восходящий поток недоступен, мы рекомендуем определить очень большой storage_ttl (порядка часов или дней), чтобы хранить устаревшие данные в кеше.В случае сбоя восходящего потока устаревшие данные можно считать «свежими», увеличив значение конфигурации плагина cache_ttl . Таким образом, данные, которые раньше считались устаревшими, теперь обслуживаются клиентом до того, как Kong попытается подключиться к вышедшей из строя службе.

API администратора

Этот плагин предоставляет несколько конечных точек для объектов управляемого кэша. Эти конечные точки назначаются ресурсу proxy-cache RBAC.

В Admin API предусмотрены следующие конечные точки для проверки и очистки объектов кеша:

Получить объект кеша

Доступны две отдельные конечные точки: одна для поиска известного экземпляра подключаемого модуля, а другая для поиска всех хранилищ данных подключаемых модулей прокси-кеша для данного ключа кеша.Обе конечные точки имеют одинаковое возвращаемое значение.

Конечная точка

/ прокси-кеш /: plugin_id / caches /: cache_id

Конечная точка

/ прокси-кеш /: cache_id

Ответ

Если объект кеша существует

Если объект с данным ключом не существует

Удалить объект кеша

Доступны две отдельные конечные точки: одна для поиска известного экземпляра подключаемого модуля, а другая для поиска всех хранилищ данных подключаемых модулей прокси-кеша для данного ключа кеша.Обе конечные точки имеют одинаковое возвращаемое значение.

Конечная точка

/ прокси-кеш /: plugin_id / caches /: cache_id

Конечная точка

/ прокси-кеш /: cache_id

Ответ

Если объект кеша существует

Если объект с данным ключом не существует

Очистить все объекты кэша

Конечная точка

/ прокси-кеш /

Ответ

Обратите внимание, что эта конечная точка очищает все объекты кеша во всех подключаемых модулях proxy-cache .

.