Глубокое понимание обратного HTTP-прокси

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

Кроме того, нужно сказать, что обратный прокси обычно упоминается, обычно имея в виду обратный прокси http, но объем обратного прокси может быть больше, например обратный прокси tcp, здесь я не собираюсь обсуждать обратный прокси-сервер, такой как tcp. Когда текст относится к обратному прокси-серверу, он относится к обратному http-прокси.

Форвардные прокси обычно вызываются напрямуюпрокси, не подчеркивая, что он прямой, в протоколе http прокси относится к прямому прокси.

прямое интервью

Чтобы поговорить о том, что такое прямой прокси, вам нужно сначала обсудить форму «прямого доступа».

То есть режима прокси нет.

Фактически, прямой доступ является наиболее распространенным методом для многих небольших веб-сайтов.Прямой доступ похож на «прямые продажи с фабрики» в нашей аналогии с ежедневными покупками, когда вы размещаете заказ непосредственно у производителя, минуя посредников.

С системной точки зрения «прямой доступ» означает, что запрос браузера направляется непосредственно на сервер, который в конечном итоге создает веб-страницу, без прохождения через какой-либо HTTP-прокси-сервер.Так что насчет прокси или более подробного «прямого прокси»? ?

прямой прокси

По-прежнему используя аналогию с покупками, вы покупаете товар в магазине, а не напрямую у производителя, что похоже на агентскую модель.

Например, если вы покупаете в магазине коробку лапши быстрого приготовления, очевидно, вы прекрасно знаете, что сам магазин не производит лапшу быстрого приготовления, он просто «посредник», он просто «посредник», он передается , и, кстати, заработайте для вас, лапша быстрого приготовления в магазине. Она также получена от производителя. Конечно, некоторые магазины перестарались и стали отвратительными «спекулянтами».

Тогда для обработки запросов браузера аналогичную роль играет прокси, точнее прокси-сервер, это просто посредник запросов.

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

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

Браузер конечного сервера знает, например, если вы введете мое доменное имя «xiaogd.net», соответствующий ip-адрес можно найти через системный браузер DNS как 118.89.55.54, но как браузер узнает, где находится прокси server и Проходит ли запрос через прокси-сервер?

Ответ в том, что вы хотитеИнициативаСообщите браузеру, что этот процесс обычно называется «настройка прокси-сервера».

Как вы увидите позже, это важное различие между прямыми и обратными прокси.

Это схематическая диаграмма настройки прокси-сервера в браузере IE:

Зачем включать прокси?

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

Один из них предназначен для аудита безопасности и контроля. В некоторых организациях веб-порты, такие как 80 и 443, заблокированы, и вы просто не можете получить доступ к Интернету вообще. Если вы хотите получить доступ к Интернету, вы можете настроить только прокси-сервер внутри сети. сервер, назначенный организацией для вас.

Разумеется, сам прокси-сервер ничем не ограничен, он может выходить во внешнюю сеть.

Таким образом, все ваши интернет-запросы проходят через прокси-сервер, и этот прокси контролируется организацией, и запрос может быть проверен:

• Например, если вы обнаружите, что загружаете конфиденциальную информацию внутри организации на внешний веб-сайт, вас заблокируют;
• Или обнаружив, что вы посетили небезопасный веб-сайт, который может привести к отравлению вашего компьютера, поэтому вы блокируете его;
• Или выяснится, что вы посещаете развлекательный сайт, не связанный с работой, поэтому я вас заблокирую~~ (За вашу работоспособность и соблюдение KPI организация тоже с разбитым сердцем!)

Есть также некоторые причины для ускорения или экономии трафика, потому что некоторые прокси-серверы могут не только пересылать, но и кэшировать веб-страницы и другие ресурсы.

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

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

Естественно, у кеша тоже будет срок годности, и он не будет кешироваться постоянно, иначе содержимое не будет обновляться.

Что касается того, как долго обновлять кэш, как обновлять и т. д., то они относятся к конкретной стратегии кэширования.

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

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

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

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

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

Разбираемся в прямом доступе, разбираемся в так называемом прямом прокси, поговорим о том, что такое обратный прокси.

Большая разница между обратным прокси-сервером и прямым прокси-сервером заключается в том, что он не требует, чтобы клиент (браузер) выполнял какую-либо настройку, и нет операции по настройке прокси-сервера.

Если прямой прокси-сервер активно настроен и активно ходит по прокси-серверу, то обратный прокси-сервер "быть проксированным", С этой точки зрения обратный прокси иногда называют"Прозрачный прокси", то есть браузер не знает, что его проксируют, и браузер думает, что отправленный ему ответ является конечным веб-сервером, а на самом деле это просто "прокси".

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

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

Он утверждает, что это Ли Куй, но на самом деле это Ли Гуй.

Сравните эти две ситуации с графиком:

Тогда такая модель была бы немногообратный проксиВы думаете, что купили прямые продажи, но на самом деле вы все еще «представлены» или через посредников.

Просто этот посредник для вас не столь очевиден, и даже говорит, что он для вас прозрачен, держа вас в неведении.

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

Тогда обратный прокси http на самом деле такой же.Например, вы посещаете мой сайтxiaogd.net, а затем вы просматриваете информацию о сервере в запросе домашней страницы, она говорит вам, что ответом на запрос домашней страницы является сервер Nginx, как показано на следующем рисунке:

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

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

Этот шлюз php-fpm можно рассматривать как веб-сервер php, но, строго говоря, он использует не http, а внутренне упрощенный протокол fastcgi.

Если вы хотите быть серьезным, это можно рассматривать как режим обратного прокси-сервера, но в целом это не весь обратный прокси-сервер HTTP, но это верно для внешнего мира.

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

Вот пример внутренней конфигурации:

location ~ \.php$ {
    root           /ftp/wwwroot;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;
    include        fastcgi_params;
}

Запрос перенаправляется на внутренний сервер приложений php, прослушивающий порт 9000.

С точки зрения внешнего браузера запрос отправляется непосредственно на сервер Nginx, а ответ также возвращается с сервера Nginx без какого-либо (прямого) прокси-сервера посередине.Что касается того, как ваш внутренний запрос перенаправляется, очевидно, Браузер Нет необходимости знать и знать.

Конечно, с точки зрения системного разработчика, но на многие запросы Nginx фактически не может ответить, он просто проксирует их на другой внутренний сервер приложений php, внутренний сервер приложений php является окончательным. Генератор ответов для .

Во всей системе роль Nginx - "обратный прокси" сервер, браузер проксируется, но у него нет возможности узнать, проксируется он или нет, все это для него прозрачно, во всяком случае, он не проявляет инициативу идти (вперед) прокси.

Конечно, теперь вы знаете мою внутреннюю конфигурацию, если вы напрямую обращаетесь кxiaogd.net:9000, то есть настоящий «прямой доступ» в обход Nginx.

Однако, когда это нужно объяснить, прямой доступ невозможен, потому что порт 9000 не открыт для внешнего мира, но к нему можно получить доступ внутри, например, попробуйте использовать wget для доступа:

wget localhost:9000

Это настоящий «прямой доступ», без всяких прокси, ни форвард прокси, ни реверс прокси.

Следует отметить, что использование wget для получения ответа по-прежнему будет сообщать об ошибке, потому что wget использует протокол http, а шлюз cgi в php фактически использует протокол fastcgi, который является более простым протоколом, чем http, и более эффективным в качестве внутренняя связь., но wget не поддерживает этот протокол, а вот Nginx этот протокол понимает, весь процесс такой:

browser -- [http] --> Nginx -- [fastcgi] --> php-fpm

Строго говоря, это не совсем http-прокси.Внутренний обратный прокси-сервер на самом деле использует протокол шлюза fastcgi, но принцип остается тем же.Если внутренний ответ — tomcat, весь процесс может быть протоколом http.

browser -- [http] --> Nginx -- [http] --> tomcat

И если вы запросите 80 внутренне, напримерwget localhostЭто все еще обратный прокси, запрос сначала идет к Nginx, который слушает порт 80, а затем Nginx перенаправляется на php-fpm.

Другой: Чтобы узнать о портах и ​​портах по умолчанию, вы можете обратиться к этой статье.Глубокое понимание портов.

Зачем использовать обратный прокси?

Итак, на этом этапе мы сталкиваемся с новой проблемой, то есть зачем нам исправлять этот обратный прокси?Подобно вопросу при встрече с прямым прокси, не хорошо ли иметь прямой доступ?Зачем нам нужно пройти через этот обратный прокси?Некоторые причины были объяснены ранее о прямом прокси, и появление обратного прокси, точно так же, как нет любви и ненависти в этом мире без причины, естественно, имеет свою причину.

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

Например, если я сейчас разрабатываю веб-приложение java в качестве фона своего веб-сайта, я развертываю его непосредственно на сервере tomcat, позволяю tomcat прослушивать порт 80 и напрямую обслуживать внешний.Сначала количество посещений невелико, так что это тоже не проблема, как показано на следующем рисунке:

Примечание. Поскольку порт по умолчанию протокола http — 80, пользователь может опустить этот номер порта при вводе адреса, то есть просто сделать следующее:xiaogd.net, вместо того, чтобы быть громоздким, как это:xiaogd.net:80, на тему дефолтных портов можно еще обратиться к предыдущемуГлубокое понимание портов.

Но через какое-то время трафик может увеличиться, и процесс tomcat не может его обработать, так что мне делать?Итак, я планирую запустить новый процесс tomcat, но столкнулся с проблемой.Имеется только один порт 80 , который использовался первым процессом tomcat.Один процесс tomcat занят, если вы хотите запустить другой, вы можете использовать только другие порты, например 8080.

При использовании другого порта действительно можно запустить два процесса tomcat, но если пользователь хочет получить доступ к службам второго процесса tomcat, он должен получить к нему доступ следующим образом:xiaogd.net:8080.Очевидно, что есть проблема с таким решением.Пользователь не знает о существовании сервиса на порту 8080. Даже если у вас есть способ сообщить пользователю, пользователь может этого не понять, и пользователь также боится Почему вы хотите, чтобы я ввел А как насчет добавления 8080 к двоеточию?

Кроме того, даже если некоторые пользователи захотят переключиться на доступ к порту 8080, как вы сказали, вы все равно не сможете контролировать равное распределение доступа к двум котам, ведь это случайное решение пользователей, и многие пользователи могут внезапно наступило Применение порта 8080 вызвало здесь перегрузку.

Или только несколько пользователей готовы последовать вашему совету перейти на новый порт 8080, а доступ по-прежнему сосредоточен на старом порту 80, поэтому реакция старого приложения все еще очень медленная, а нового приложения, потому что нет имеют мало доступа пользователей и кажутся бездействующими и не полностью используемыми.

Тогда в этом случае отражаются преимущества обратного прокси.Конкретная операция заключается в следующем, пусть Nginx служит фронтальным обратным прокси, прослушивая порт 80, а первый кот прячется за кулисами, в то же время , он больше не слушает порт 80 (который нужно предоставить Nginx), а вместо этого слушает неиспользуемый порт, например 8081, а затем позволяет Nginx перенаправить запрос на него для обработки.

Конечно, если есть только один кот, конфигурация, вероятно, будет такой:

location / {
    proxy_pass   http://127.0.0.1:8080;
}

Алгоритм обработки запроса выглядит следующим образом:

Запрос: браузер -- [http] --> Nginx -- [http] --> tomcat

Ответ: browser

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

А вот если котов два, то ситуация другая, в это время можно включить стратегию балансировки нагрузки на уровне Nginx, обратного прокси, примерная конфигурация такая:

http {
    upstream myapp1 {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

В это время, если одновременно поступает много запросов, Nginx будет отправлять половину запросов на tomcat на порт 8080, а другую половину запросов на tomcat на порт 8081, как показано на следующем рисунке:

Внешне все запросы по-прежнему обрабатываются Nginx, пользователям не нужно делать выбор и им не нужно знать о существовании приложений на портах 8080 и 8081, они могут продолжать посещать исходный сайт xiaogd.net без внесения каких-либо изменений.

Если у вас есть несколько хостов в облаке, вы даже можете создать интрасеть и развернуть Tomcat на разных хостах.Например, если у вас есть три хоста, один запускает Nginx, прослушивая порт 80, а два других запускают Tomcat, Monitor порты 8080 и 8081 соответственно, а также принимать и обрабатывать запросы от обратного прокси-сервера Nginx, как показано на следующем рисунке:

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

http {
    upstream myapp1 {
        server 192.168.0.20:8080 weight=3;
        server 192.168.0.21:8080 weight=2;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

Соотношение весов 3:2 настроено, как указано выше, так что один из них несет 60% запросов, а другой с низкой производительностью несет 40%, то есть из каждых 5 запросов 3 будут переданы хосту, чей ip равен 20. , 2 отправится на хост с ip 21.

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

Аналогичным образом, в режиме обратного прокси задача создания веб-страниц передается скрытому за кулисами коту Tomcat. Создание сложной динамической веб-страницы может потребовать некоторых сложных вычислений, таких как запрос к базе данных и объединение различных компонентов страницы. отнимать много времени, но эти запросы обрабатываются одновременно двумя приложениями tomcat, поэтому скорость ответа по-прежнему гарантирована, и это те преимущества, которые может принести нам обратный прокси.

Суммировать

На этом введение прямого доступа, (прямого) прокси-сервера и обратного прокси-сервера завершено, и, наконец, суммированы три ситуации и аналогия с примером с покупками.

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

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

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

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

Вот и все для прямого прокси-сервера http и обратного прокси-сервера.