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

• Маршрутизация . Прокси-сервер пересылает данные в разные пункты назначения в соответствии с характеристиками передаваемых данных.
• Балансировка нагрузки . Во время пересылки данные распределяются по разным адресам, чтобы повысить пропускную способность и избежать единой точки отказа. Балансировка нагрузки уровня 4 или уровня 7 является одним из вариантов использования прокси-серверов.
• Отказоустойчивость . В случае сбоя переадресации в указанное место назначения прокси-сервер может выбрать альтернативное место назначения, обеспечивая бесперебойное обслуживание запрашивающей стороне.
• Контроль доступа. Прокси может решить, какой трафик разрешен, а какой должен быть заблокирован. Типичным примером являются брандмауэры веб-приложений (WAF).
• Управление идентификацией . Управление доступом часто основано на идентификационной информации, поэтому прокси-серверы также часто имеют возможности управления идентификацией.
• Сетевое ускорение . Прокси ускоряет доступ к сети за счет кэширования данных.
• Сбор метрик . Proxy собирает статистику данных и обобщает ее для программного обеспечения Network Performance Monitor (NPM) для оптимизации сети и планирования сети.
• Информационная безопасность . Помимо управления доступом, прокси-серверы также можно использовать для аудита безопасности, разгрузки TLS/SSL и шифрования данных в соответствии с требованиями безопасности.

Прокси, работающие на уровнях 4 и 7 модели ISO/OSI, иногда называют прокси «режим маршрутизации». Большинство прокси-сервисов доступны как программное обеспечение с открытым исходным кодом и составляют большую часть программного обеспечения сетевой инфраструктуры, предоставляя специализированные функции в различных областях, такие как прокси для определенных протоколов, прокси для балансировки нагрузки, прокси для ускорения кэширования и т. д.

Эволюция программного обеспечения прокси

Прокси-серверы прошли разные этапы развития:

Эпоха конфигурационных файлов

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

Конфигурация эпохи DSL

Статические файлы конфигурации затрудняют выражение сложной логики, поэтому многие прокси-серверы ввели тонкие сценарии поверх файлов конфигурации. Их обычно называют «языками конфигурации» или предметно-ориентированными языками (для краткости DSL), такими как ACL Haprxoy или VCL Varnish .

Эпоха скриптовых языков

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

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

Такие языки обеспечивают удобство написания сценариев и структурные преимущества полноценного языка программирования. Примерами этого являются OpenResty (Nginx + Lua) и Nginx Plus (Nginx + NJS). В эту категорию также входят прокси-серверы, реализованные на ряде языков прикладного программирования, таких как StrongLoop Microgateway на основе Node и Spring Cloud Gateway на основе Java , которые часто имеют собственные возможности сценариев.

Кластерная эра

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

В то же время использование прокси-серверов перешло от одиночных экземпляров к кластерам прокси-серверов. Фактически, прокси-программы, такие как Envoy и Kong на основе OpenResty , часто сами поддерживают возможности кластеризации, реализуя их каким-то централизованным или общим (через RDBMS и т. д.) способом, а также предоставляя административные интерфейсы REST для управления конфигурациями.

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

Облачная эра

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

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

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

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

Сервисные сетки являются представителями этой эпохи. Сервисные сетки состоят из двух ключевых архитектурных компонентов: плоскости данных и плоскости управления. Вопреки тому, что следует из названия, сервисная сетка не является «сеткой сервисов». Это сеть прокси-серверов, к которым сервисы могут подключаться, чтобы полностью абстрагироваться от сети. Типичными примерами являются istio+envoy , Linkerd + Linkerd proxy.

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

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

Требования к программному обеспечению прокси и их эволюция

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

Эпоха конфигурационных файлов

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

Программное обеспечение прокси на этом этапе было в основном разработано на C, как и в случае с модулями расширения, которые загружаются динамически в начале процесса.

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

Конфигурация эпохи DSL

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

Эпоха скриптовых языков

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

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

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

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

Кластерная эра

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

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

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

Облачная эра

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

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

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

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

• Внутренние функции прокси-сервера могут быть расширены, включая базовые базовые возможности, поддерживаемые протоколы и возможности обработки уровня 7 (пересылка, маршрутизация, оценка, контроль доступа и т. д.). Мощность обработки Layer7 требует более удобного способа программирования, то есть сценариев и структурного программирования.
• Прокси-серверы должны предоставлять внешние интерфейсы для интеграции в более крупные системы управления (такие как облачные платформы), включая управление конфигурацией, управление ресурсами и т. д.
• Прокси-серверы должны предоставлять расширяемые возможности для различных ролей, включая операции, администраторов, поставщиков ресурсов и арендаторов, все из которых в той или иной степени требуют программируемости.
• Также, как и любой программируемый компонент, программируемый прокси требует сопроводительной документации, руководств по разработке, управления кодом, управления зависимостями, инструментов сборки и развертывания и, желательно, визуальной среды разработки и отладки. Только при полном соблюдении этих требований пользователи могут эффективно управлять сетевым трафиком и службами, его создающими.

Резюме

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