1. Агентские услуги

Что такое агент? Давайте сфотографируемся, чтобы понять

Агенты делятся на прямых агентов и обратных агентов.

2. Форвард-агент

1.1 Что такое прямой прокси?

Дайте каштан:

Одноклассник любит программировать для поисковых систем и хочет найти некоторые учебные материалы через поисковую систему Baidu. Однако прямой доступ к некоторым веб-сайтам может быть небезопасным и раскроет его IP-адрес. Одноклассник очень расстроен и думает о том, как использовать Baidu для этого. искать нужные ему учебные материалы, не раскрывая свой IP на веб-сайте? В это время я сказал однокласснику, что у меня под рукой был прокси-сервер. Этот прокси-сервер был настроен с перенаправлением прокси-сервера для пересылки запросов http и https через nginx. Вам нужно настроить это только на шлюзе. ваш локальный компьютер с ОС Windows. Если вы укажете IP-адрес и номер порта прокси-сервера, вы обычно сможете получить доступ к Baidu через прокси-сервер и искать соответствующие учебные материалы, не раскрывая свой реальный IP-адрес~.

Переадресация прокси: относится к прокси-службе, которая перенаправляет запросы на целевой сервер через прокси-сервер и прокси-браузер/клиент.

Характеристики службы прямого прокси: Это прокси-сервер, а объектом прокси является браузер/клиент, то есть браузер/клиент скрыт от целевого сервера.

1.2 Как реализовать переадресацию nginx?

(1) Инструкции по переадресации https через прокси-сервер

Прежде чем реализовывать прокси-сервер nginx, позвольте мне объяснить, что большинство современных веб-сайтов в основном используют https. Поэтому для реализации запросов на пересылку прокси-сервера nginx, помимо настройки запросов на пересылку порта http80, также существует запрос на настройку порта https443 ~.

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

Хотя HTTP-запрос был перенаправлен нормально, было обнаружено, что передача https не была успешной, но было сообщено об ошибке HTTP/1.1 400 Bad Request~.

Позже я узнал, что nginx официально не поддерживает прямую пересылку https-запросов, но большой босс из Alibaba расширил nginx модулем ngx_http_proxy_connect_module и выложил его с открытым исходным кодом на github. https://github.com/chobits/ngx_http_proxy_connect_module

Однако исправление поддерживаемого модуля ngx_http_proxy_connect_module также ограничено версией nginx (в настоящее время поддерживается версия 1.4.x~1.25.x), как указано в README.md:

Если установленная вами версия nginx не находится в диапазоне 1.4.x~1.25.x, она не может поддерживать пересылку https-запросов на прокси-сервер пересылки.

(2) Установите nginx

Если nginx установлен (можно пропустить), в качестве примера приведена версия 1.9.2, для установки используйте пользователя root:

$ cd /usr/nginx
$ wget http://nginx.org/download/nginx-1.9.2.tar.gz
$ tar -xzvf nginx-1.9.2.tar.gz
$ cd /usr/nginx/nginx-1.9.2
$ make && make install

Здесь nginx устанавливается и компилируется через install. После компиляции каталог установки по умолчанию — /usr/local/nginx. Последующая настройка нового модуля ngx_http_proxy_connect_module требует переустановки и компиляции~.

(3) Загрузите новые модули.

Загрузите исходный код ngx_http_proxy_connect_module в zip-архиве на GitHub:

https://github.com/chobits/ngx_http_proxy_connect_module

(4) Разархивируйте исходный код нового модуля.

Загрузите сжатый пакет исходного кода нового модуля ngx_http_proxy_connect_module в каталог server/usr/nginx, разархивируйте и переименуйте его.

$ mkdir -p /usr/nginx
$ cd /usr/nginx
$ /usr/nginx
$ unzip ngx_http_proxy_connect_module-master.zip
$ mv ngx_http_proxy_connect_module-master ngx_http_proxy_connect_module

(5) Добавьте новые модули в nginx.

Используйте пользователя root, чтобы войти в каталог ресурсов nginx /usr/nginx/nginx-1.9.2, добавьте новый модуль ngx_http_proxy_connect_module в nginx и перекомпилируйте nginx.

$ /usr/nginx/nginx-1.9.2
$ patch -p1 < /usr/nginx/ngx_http_proxy_connect_module/patch/proxy_connect.patch
$ ./configure --add-module=/usr/nginx/ngx_http_proxy_connect_module
$ make && make install

-проиллюстрировать:

Версия nginx-1.9.2 здесь соответствует патчу proxy_connect.patch. Другие версии связанных патчей поддерживают версии. Подробности см. на GitHub~. https://github.com/chobits/ngx_http_proxy_connect_module

После установки и компиляции нового модуля с использованием пользователя root, если вы хотите в будущем использовать и обслуживать его без использования пользователя root, вы можете авторизовать каталог установки /usr/local/nginx для пользователя nginx или других обычных пользователей~

chown -R nginx:nginx /usr/local/nginx
chown root:root /usr/local/nginx/sbin/nginx
chmod +s /usr/local/nginx/sbin/nginx

-проиллюстрировать:

Двоичный файл /usr/local/nginx/sbin/nginx должен повторно принадлежать пользователю root, а бит разрешения добавляется с разрешением s (двоичный файл с битом разрешения + s является файлом конвейера, то есть обычные пользователи также могут выполнить двоичный файл, выполнить процесс, сгенерированный позже, принадлежит владельцу разрешения файла, здесь владельцем файла является root)

(6) Измените конфигурацию nginx.

Измените конфигурацию nginx, добавив серверы http и https соответственно, а остальные конфигурации оставьте без изменений~

vi /usr/local/nginx/conf/nginx.conf

Основная конфигурация этих двух серверов предназначена для разрешения DNS и прокси-сервера proxy_pass:

#Пересылаем http-запрос на прокси
server {
    #Указываем IP-адрес DNS-сервера 
    resolver 114.114.114.114;
    #Прослушиваем порт 80, http-порт по умолчанию 80
    listen 80;
    #IP-адрес сервера или имя домена
    server_name  localhost;
	
    #Пересылаем http-запрос на прокси
    location / {
        proxy_pass                 http://$host$request_uri;
        proxy_set_header           HOST $host;
        proxy_buffers              256 4k;
        proxy_max_temp_file_size   0k;
        proxy_connect_timeout      30;
        proxy_send_timeout         60;
        proxy_read_timeout         60;
        proxy_next_upstream error  timeout invalid_header http_502;
    }
}

#Пересылаем https-запросы на прокси
server {
    #Указываем IP-адрес DNS-сервера 
    resolver 114.114.114.114;
    #Прослушиваем порт 443, порт по умолчанию для https — 443
    listen 443;
	
    #Пересылаем https-запросы на прокси
    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_read_timeout     10s;
    proxy_connect_send_timeout     10s;
    location / {
        proxy_pass http://$host;
        proxy_set_header Host $host;
    }
}

– Инструкции DNS:

(Внутренние и зарубежные) В настоящее время более распространенный DNS:

(Иностранный) Google: 8.8.8.8 Developers.google.com

(Зарубежный) OpenDNS: 208.67.222.222signup.opendns.com

(Внутренний) 114: 114.114.114.114 www.114dns.com

(Внутренние) Tencent: 119.29.29.29 www.dnspod.cn

(Внутренний) Али: 223.5.5.5 alidns.com

(Внутренний) Baidu: 180.76.76.76 dudns.baidu.com

(7) Проверьте и обновите конфигурацию nginx.

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

1.3 Клиентский доступ (проверка перенаправления прокси)

Клиент хочет использовать прокси для доступа к объекту примера целевого веб-сайта:

http://www.baidu.com иhttps://www.baidu.com

(1) Клиент – доступ через браузер Windows

Сначала установите прокси-сервер и порт в браузере IE локального компьютера:

IE->верхний правый угол ->инструмент ->InternetПараметры->соединять->локальная сеть（LAN）настраивать ->Настроить проксиIPи порт

Доступ через браузер

http://www.baidu.com/ иhttps://www.baidu.com/

Просмотр журналов nginx в режиме реального времени

tail -f /usr/local/nginx/logs/access.log

Просматривая журнал доступа nginx в режиме реального времени, вы можете видеть, что после установки IP-адреса и порта прокси-сервера в Windows все веб-страницы, к которым обращается локальный компьютер, будут получать доступ к веб-странице через прокси-сервер, реализуя функцию перенаправления прокси-сервера и скрывая реальный IP пользователя ~

(2) Клиент – доступ к прокси-серверу Linux

В Linux вы также можете проверить, может ли прокси-сервер нормально пересылать запросы http и https~

curl http://www.baidu.com/ -v -x 127.0.0.1:80
curl https://www.baidu.com/ -v -x 127.0.0.1:443

nginx успешно пересылает https на прокси:

2. Обратный прокси

2.1 Что такое обратный прокси?

Обратный прокси-сервер означает, что браузер/клиент не знает, к какому целевому серверу он хочет получить доступ, а знает только о доступе к прокси-серверу. Затем прокси-сервер распределяет запрос на сервер приложений через обратный прокси-сервер + службы балансировки нагрузки. Особенностью службы обратного прокси является то, что объектом прокси-сервера является сервер приложений, то есть сервер приложений скрыт от браузера/клиента.

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

• Нам нужно заранее настроить nginx правила прокси,разные запросы,Передайте его на разные реальные серверы
• Когда запрос достигает nginx, nginx пересылает запрос в соответствии с определенными правилами для реализации функции маршрутизации.

Используя обратный прокси, вы можете решить проблему с портом, о которой мы упоминали ранее, как показано на рисунке.

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

#user  nobody;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;

    keepalive_timeout  65;

    gzip  on;
    server {
        listen       80;
        server_name  manage.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
            proxy_pass http://127.0.0.1:9001;
            proxy_connect_timeout 600;
            proxy_read_timeout 600;
        }
    }
    server {
        listen       80;
        server_name  api.leyou.com;

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
            proxy_pass http://127.0.0.1:10010;
            proxy_connect_timeout 600;
            proxy_read_timeout 600;
        }
    }
}

• Браузер готовится инициировать запрос,доступhttp://mamage.leyou.com,Но требуется разрешение доменного имени
• Приоритет отдается разрешению локального доменного имени. Поскольку мы изменили хосты, разрешение прошло успешно и был получен адрес: 127.0.0.1.
• Запрос отправляется на разрешенный IP-адрес, а порт 80 используется по умолчанию: http://127.0.0.1:80.

Локальный nginx прослушивает порт 80, поэтому этот запрос перехватывается.

• перемена настроена в nginx правила прокси,Прокси-сервер Manage.leyou.com для 127.0.0.1:9001,Итак, запрос перенаправлен
• Сервер веб-пакетов внутренней системы прослушивает порт 9001, получает запрос, обрабатывает его и возвращает ответ nginx после завершения.
• nginx возвращает результаты в браузер

2.2 nginx реализует обратный прокси

(1) Измените конфигурацию nginx.

Измените конфигурацию nginx vi /usr/local/nginx/conf/nginx.conf и настройте ее в модуле http следующим образом:

Обратный прокси nginx реализован в сочетании с балансировкой нагрузки. Здесь мы непосредственно предоставляем настройку обратного прокси + балансировку нагрузки.

#обратный прокси+ балансировка нагрузки
upstream reverseProxyServer{
    #Сервер приложений балансировки нагрузки A: Вес равен 10, а запрос на соединение не выполняется 2 раза в течение 10 с. nginx считает, что сервер недоступен в течение 10 с и больше не будет отправлять запросы на этот сервер.
    server IP сервера приложений A: 8080 weight=10 max_fails=2 fail_timeout=10s; 
    #Сервер приложений балансировки нагрузки B: Вес прокси-сервера равен 5. Запрос на соединение проваливается 2 раза в течение 10 секунд. nginx считает сервер недоступным в течение 10 секунд и больше не будет отправлять запросы на этот сервер.
    server IP сервера приложений B: 8080 weight=5 fail_timeout=10s max_fails=2;
    #Сервер приложений балансировки нагрузки C: Вес прокси-сервера равен 5. Запрос на соединение проваливается 2 раза в течение 10 секунд. nginx считает сервер недоступным в течение 10 секунд и больше не будет отправлять запросы на этот сервер.
    server IP сервера приложений C: 8080 weight=5 fail_timeout=10s max_fails=2;
}

server {
    #Прослушиваем порт 80, http-порт по умолчанию 80
    listen 80;
    #IP-адрес сервера или имя домена
    server_name  localhost;
    #обратный прокси Все запросы, содержащие /appname в пути запроса, переходят к соответствующему направлению, определенному восходящим потоком прокси-модуль
    location /appname {
        proxy_pass http://reverseProxyServer;
    }
}

(2) Проверьте и обновите конфигурацию nginx.

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

（3）Доступ через браузер

Прокси-сервер развернул приложение tomcat. Посетите статическую страницу tomcat, чтобы проверить~.

http://IP-прокси-сервера: 8080/имя приложения/ReverseProxy1.html

3. Балансировка нагрузки

3.1 Что такое балансировка нагрузки?

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

3.2 Каковы алгоритмы балансировки нагрузки?

Обычно используемые алгоритмы балансировки нагрузки включают алгоритмы опроса, веса и ip_hash. По умолчанию используется алгоритм опроса~.

(1) Алгоритм на основе опроса

Принцип заключается в том, что каждый запрос распределяется по разным серверам приложений один за другим в хронологическом порядке. Если сервер приложений, получающий запрос, зависает и запрос превышает максимальное количество сбоев max_fails (1 раз), он не будет обработан в пределах сбоя. timefail_timeout (10 секунд). Затем перенаправьте запрос на узел~.

upstream defaultReverseProxyServer{
    server 192.168.0.1:8080; 
    server 192.168.0.2:8080; 
}

(2) Алгоритм на основе веса

Принцип заключается в том, что каждый запрос распределяется по разным серверам приложений в соответствии с весом. Аналогично, если сервер приложений, получающий запрос, зависает и запрос превышает максимальное количество ошибок max_fails (по умолчанию 1 или может быть установлено в N раз), то таймаут сбоя (запрос не будет перенаправлен на узел в течение 10 секунд по умолчанию (можно установить на N секунд)~

upstream weightReverseProxyServer{
    server 192.168.0.1:8080 weight=10 max_fails=2 fail_timeout=5s;
    server 192.168.0.2:8080 weight=5 max_fails=2 fail_timeout=5s;
}

(3) Алгоритм на основе ip_hash

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

upstream ipHashReverseProxyServer{
    ip_hash;
    server 192.168.0.1:8080;
    server 192.168.0.2:8080;
}

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