relay proxy что это
The Relay Proxy
Read time: 5 minutes
Last edited: Oct 20, 2021
This topic explains what the Relay Proxy is and how to use it.
The Relay Proxy is a small Go application that connects to the LaunchDarkly streaming API and proxies that connection to clients within an organization’s network.
The Relay Proxy lets multiple servers connect to a local stream instead of making a large number of outbound connections to LaunchDarkly’s streaming service ( stream.launchdarkly.com ). You can configure the Relay Proxy to carry multiple environment streams from multiple projects.
The Relay Proxy is an open-source project supported by LaunchDarkly. The full source is in a GitHub repository. There’s also a Docker image on Docker Hub.
Should I use the Relay Proxy?
We recommend using the Relay Proxy if you have certain specific configuration requirements, which are explained below. If you don’t meet those requirements, using the Relay Proxy is optional.
Some customers may find operating the Relay Proxy cost-prohibitive for their use case, especially customers on Pro or Starter plans.
Determining if your configuration is a good use case for the Relay Proxy
Adding the Relay Proxy to your LaunchDarkly configuration introduces architectural complexity that may not be necessary for smaller deployments.
The LaunchDarkly client-side and server-side SDKs you use also impacts whether you should use the Relay Proxy. The Relay Proxy provides performance and resilience improvements for all server-side SDKs and for SDKs configured to poll. To learn more, read Understanding the different types of SDKs.
The Relay Proxy works best with the default SDK configurations for all server-side SDKs and for the client-side JavaScript SDK. It does not scale well when it has to maintain streaming connections with a large number of client-side SDKs, including mobile SDKs. If you’re utilizing LaunchDarkly’s streaming architecture in a heavily-used client-side or mobile application, connecting directly to LaunchDarkly’s main service may give you the best performance.
The Relay Proxy was developed to address specific scenarios, and it works best when you use it for those purposes.
Those scenarios are:
Understanding the cost of using the Relay Proxy
The Relay Proxy has certain features that are available to customers on an Enterprise plan, including automatic configuration and offline mode. Access to these features may make using the Relay Proxy more beneficial than it would be with only its out-of-the-box feature set. To learn more, read Relay Proxy Enterprise.
In general, customers on Enterprise plans may be more tolerant of the infrastructural costs associated with using the Relay Proxy’s Enterprise features than customers with more limited budgets. If you’re on LaunchDarkly’s Starter or Pro plan, you can use the Relay Proxy but the operating costs associated with onboarding it may be prohibitive. To learn more, read Best practices for using the Relay Proxy.
Best practices for using the Relay Proxy
This section includes some guidelines for positioning and using the Relay Proxy successfully. These guidelines are not exhaustive or required. The most effective practices for your organization may be different based on your configuration and deployment requirements.
To learn more about performance expectations once the Relay Proxy is running, read Monitoring the Relay Proxy.
If you want to size or scale your Relay Proxy, the most important thing to consider is the amount of dedicated network bandwidth available to it. The Relay Proxy is not CPU or memory intensive, so these are unlikely to be performance bottlenecks. However, the Relay Proxy does require a significant amount of network bandwidth, because it makes many small requests, very frequently.
We have tested and developed the Relay Proxy to work with an AWS m4.xlarge instance, but you can use the Relay Proxy with any technical equivalent. The m4.xlarge instances we test against have 4 vCPUs and 16GiB of memory, but that is not a hard requirement. In fact, the Relay Proxy may use significantly less memory and CPU than the m4.xlarge instance offers. More importantly, the m4.xlarge instance has sufficient networking performance that the Relay Proxy should perform well.
The Relay Proxy works best with LaunchDarkly’s server-side SDKs and with SDKs configured for polling. It does not handle streaming connections from client-side SDKs efficiently. When you use LaunchDarkly’s streaming architecture in a heavily-used client-side or mobile application, be sure to monitor and scale the Relay Proxy accordingly.
If you choose to use the Relay Proxy, position it effectively within your network architecture. Your application must be able to access the Relay Proxy for it to work, and that architecture varies based on the type of app you have.
For example, do not put the Relay Proxy inside a firewall if you intend to connect it to any client-side apps.
If you have deployed your application to multiple regions, consider running one or more Relay Proxy instances in each of those regions in close proximity to your application. This limits latency between your application and the Relay Proxy.
If you have security requirements, such as enforcing the use of a particular authentication scheme, place the Relay Proxy behind a general purpose proxy so traffic from LaunchDarkly SDKs flows through the general purpose proxy before it reaches the Relay Proxy. The Relay Proxy does not replicate the functionality of a general purpose proxy. Do not use it as a replacement for a general purpose proxy.
We do not recommend relying solely on the Relay Proxy’s in-memory caching in a production environment. Instead, we recommend that you cache flag data in a persistent feature store.
Whether or not you utilize a persistent feature store impacts how the Relay Proxy handles inbound feature flag requests on initialization, before it establishes a connection to LaunchDarkly.
If you use a persistent feature store, Relay Proxy uses previously known-good values as stored in the persistent feature store. Without a persistent feature store, however, Relay Proxy doesn’t know anything about any feature flags yet. SDKs use default flag values until the Relay Proxy establishes a connection to LaunchDarkly.
Разница между обратным и прямым прокси
Если вы новичок в мире прокси, вы, должно быть, сталкивались с двумя терминами — обратный прокси и прямой прокси. На самом деле это не одно и то же понятие. Я видел, как люди ошибочно принимали одно за другое, и это проистекает из того факта, что они на самом деле не понимают обоих.
Именно поэтому я написал эту статью; чтобы узнать, что отличает обратный прокси от прямого и как они выполняют одну и ту же функцию в разных средах. Перед этим давайте посмотрим, что собой представляет каждый из них.
Определение обратного и прямого прокси
Я знаю, вам может быть интересно, зачем поднимать этот вопрос; это потому, что вам должно быть дано четкое определение прокси. Большинство людей рассматривают прокси как сервер, через который клиенты отправляют свои веб-запросы на веб-сайты.
Что ж, это еще не все, что касается прокси. В отличие от большинства наших статей, мы должны перейти к более техническим аспектам и переопределить прокси для вас. Прокси-сервер — это просто сервер, действующий в зависимости от поведения другого компьютера, который может быть клиентом или сервером. Это означает, что помимо вас как клиента, которому нужны прокси-серверы, чтобы прятаться, веб-сервер, с которого вы запрашиваете ресурсы, также может скрываться за прокси.
Что такое прямой прокси?
Когда вы слышите, как люди упоминают слово «прокси» в веб-технологиях, на самом деле они имеют в виду прямые прокси. Прямые прокси — это типы прокси, которые клиенты используют для сокрытия своих IP-адресов и сохранения анонимности при работе в Интернете.
Что они делают, так это пересылают запросы, отправляемые через них, на соответствующие веб-серверы, и когда ответ им возвращается, они отправляют его вам. В зависимости от уровня анонимности веб-сервер, с которого вы запрашиваете ресурсы, не будет знать, что вы инициировали запрос. Но Forward Proxy знает и вас, и веб-сервер, с которого вы запрашиваете содержимое.
Как работает прямой прокси
При подключении к прокси-серверу ваше устройство отправляет обычный запрос, как если бы прокси-сервер не существовал, но оно будет перенаправлять все свои запросы через этот прокси-сервер, и прокси будет принимать запросы и перенаправлять их через свой собственный IP-адрес, и если он запутан (анонимен), он скроет ваш IP-адрес и заменит его своим собственным адресом.
Лучший пример того, как прямой прокси-сервер может вам помочь, — это обход сетевой блокировки. Если ваша сеть блокирует Instagram, вы можете решить проблему блокировки с помощью прокси https://proxy-seller.ru/russian-proxy. Вы подключитесь к прокси-серверу вместо сервисов Instagram и будете получать информацию без предупреждения брандмауэра.
Что такое обратный прокси?
Хотя вышеперечисленное применимо только к клиентам, некоторые прокси также были разработаны для обеспечения конфиденциальности веб-серверов. Позвольте мне рассказать вам кое-что. Не только вам нужна конфиденциальность; веб-серверам это нужно, потому что они не знают, заслуживаете ли вы доверия или нет. Однако некоторые существуют по другим причинам.
Обратный прокси-сервер — это прокси-сервер, который принимает веб-запросы от имени веб-серверов. После получения запроса, основываясь на его конфигурации, он определяет, заслуживает ли запрос перенаправления на реальный сервер или нет.
При наличии обратного прокси-сервера вряд ли удастся напрямую поразить реальный сервер — это потому, что только IP-адрес обратного прокси является общедоступным. Это создает определенный уровень конфиденциальности для серверов.
Как работает обратный прокси
По сути, веб-сервером может быть один сервер или их набор, но они не подключаются напрямую к Интернету. Вместо этого они подключаются к обратному прокси. Этот обратный прокси-сервер действует как веб-сервер. Вы как веб-браузер подключаетесь к сайту и просто видите прокси; вы не видите ни одного из серверов, стоящих за ним. Прокси-сервер притворяется веб-сервером, выполняя такие функции, как скрытие настоящего IP-адреса сервера.
Обратный или Прямой прокси
Глядя на приведенные выше определения, вы можете увидеть, что эти два термина не совпадают и, по сути, совершенно разные. На всякий случай, если вы не заметили разницы, в этом разделе мы подробно обсудим различия между ними.
Структурная позиция
Самая важная отличительная черта как обратных прокси-серверов, так и их аналогов прямых прокси — это их структурное положение во всем сочетании отправки и получения ответа. Для прокси-серверов Forward они являются клиентскими и обеспечивают клиентскую анонимность для вашего ПК. Прямые прокси — это ваш шлюз в Интернет, и они могут изменять ваши запросы до того, как они попадут на веб-сайт, который вы собираетесь посетить. Чтобы вы могли использовать прокси-сервер пересылки, вам необходимо настроить их на своей стороне — на стороне клиента.
Для обратных прокси они ориентированы на сервер и обеспечивают анонимность на стороне сервера. Они служат шлюзом к веб-серверу, с которым вы собираетесь взаимодействовать. Так же, как вы не хотите, чтобы веб-серверы знали ваш реальный IP-адрес, некоторые организации также не хотят, чтобы вы знали о существовании их фактических серверов; Итак, они устанавливают прокси-сервер, который действует как их настоящий сервер. Но когда поступают запросы, он направляет их на настоящий сервер.
Область применения
Структурное расположение двух типов прокси сделало их область применения различной. Хотя оба могут блокировать умеренный трафик пользователей и оба являются шлюзами, их приложения различаются. Каковы же тогда варианты использования каждого из них?
Для форвардных прокси вариант их использования довольно прост и известен многим пользователям Интернета.
Сама идея предоставления IP-адреса и конфиденциальности местоположения открывает множество областей, в которых используются прокси-серверы. Прямые прокси полезны в области защиты бренда и проверки рекламы. Они также полезны при поисковой оптимизации, сканировании и парсинге в Интернете, а также при игре в онлайн-игры, социальные средствами автоматизации медиа, и многими другими.
Для обратных прокси их использование не известно широкой публике, за исключением тех, кто знаком с серверными технологиями.
Одним из наиболее важных применений обратных прокси является то, что они используются для балансировки нагрузки. Они распределяют входящие веб-запросы на группу веб-серверов, выполняющих одну и ту же функцию — это позволяет веб-сайту с высоким трафиком быстро отвечать на отправленные им запросы. Помимо этого, они используются для кеширования, что в конечном итоге приводит к более быстрому отклику и экономии полосы пропускания. Они также используются по соображениям безопасности, чтобы обеспечить некоторую форму оболочки для реальных серверов, чтобы было трудно атаковать их напрямую.
Вывод
Глядя на вышеизложенное, вы увидите, что, хотя все они имеют слово «прокси» в своих именах, на самом деле это не одно и то же. У них обоих есть свое уникальное использование, основанное на их позиции в цикле запроса-ответа. Однако важно знать, что каждый из них модерирует ваш трафик и может либо заблокировать ваши запросы, либо разрешить их.
Diameter. Базовый протокол. Часть 1
Обещал рассказать про Diameter. Начнем, но должен предупредить, писать буду вольным текстом, высока вероятность упрощения и опущения ряда важных моментов. Цель — обзорная статья и самое первое знакомство с протоколом, а детали можно прочитать в стандартах. Примеры будут из сотовой связи.
UPDATE: По просьбе ploop, спасибо за ценное замечание. Diameter – это протокол семейства AAA, и является развитием RADIUS. Предназначен он, главным образом, для оценки услуг в сетях связи. В частности, в сетях 3G с его помощью происходит оценка услуг передачи данных, а в IMS\LTE протокол является одним из основных управляющих элементов.
Введение
Первый документ, который описывал требования к новому протоколу был опубликован в 1998 году в рамках IETF, его авторами стали Pat R. Calhoun (Sun),Glen Zorn (MS), Ping Pan (IBM).
Коллектив авторов черновика менялся от версии к версии, они переходили из одной компании в другую, и наконец, в 2003 году был выпущен RFC 3588, но всегда первым стоит имя Pat R. Calhoun. В 3588 была описана базовая модель Diameter, которая включала в себя функционал Accounting и позволяла разработчикам создавать на ее основе новые приложения для протокола. И совсем недавно, в октябре 2012 года документ RFC 3588 был признан устаревшим, и его сменил RFC6733, в котором ничего кардинально не изменилось, обратная совместимость сохранена, изменения описаны в самом документе и выходят за рамки статьи.
Важной особенностью протокола является его расширяемость и возможность создания не только собственных атрибутов, но и приложений. Примером приложения является RFC 4006 Diameter Credit Control Application, разработка которого началась в 2003 году, а финальный RFC вышел в 2005. Далее комитет 3GPP оттолкнулся от RCF 3588 и создал ряд приложений, например 3GPP 32.299 Diameter charging applications, который является следствием развития RFC 4006 DCCA.
Для рассмотрения возможностей Diameter хватит и этих трех источников, во многом это будет пересказ рекомендаций. Ниже я приведу ссылки на некоторые открытые спецификации. Помимо открытых, я сталкивался с проприетарными реализациями приложений Diameter. В итоге реальное количество реализаций, версий и приложений Diameter оценить не могу. Но могу точно сказать, что сегодня, для оказания почти любому абоненту услуг мобильной связи Diameter применяется в том или ином виде. А с развитием 3G, IMS, LTE процент проникновения будет стремиться к 100%.
Базовый протокол
Базовый протокол реализует требования к протоколам ААА, детали которых отражены в RFC2989, и описывает процесс установления соединения, проверку совместимости, правила отправки сообщений и их маршрутизации, разрыв соединения.
В качестве транспорта могут использоваться TCP и SCTP. Безопасность протокола должна обеспечиваться на транспортном уровне, в рекомендациях также указано, что протокол не должен использоваться без TLS, DTLS или IPsec. В доверенной сети, разумеется, возможно обойтись и без них, в частности, если внутреннюю сеть предприятия можно считать надежной.
Спецификация определяет несколько типов узлов Diameter.
Для понимания роли узлов необходимо ввести две термина, которые более подробно будут рассмотрены ниже.
Сессия — контролирует состояние абонента и включает в себя те и только те сообщения, которые относятся к отдельно взятому абоненту.
Соединение — контролирует состояние связи между узлами Diameter.
Сессия определяется AVP SessionID, и этот идентификатор является сквозным для всех узлов, принимающих участие в обработке сессии абонента.
Клиент
Клиентом обычно выступает сетевое устройство, которое непосредственно обрабатывает трафик абонента.
Сервер
Роль сервера вполне понятна, он должен контролировать состояние абонентских сессий.
Агент.
DIAMETER агенты являются промежуточными узлами между клиентом и сервером и выполняют функции управления трафиком. Например, они могут агрегировать сообщения от устройств на одной площадке, выполнять роль балансировщика нагрузки, модифицировать пакеты Diameter, выступать в роли шлюзов безопасности при переходе из доверенной сети в публичную.
Функционально агенты делятся на несколько типов.
Relay agent (DRL)
Узлы данного типа принимают Diameter-сообщения от сетевых устройств и перенаправляют их на следующие узлы на основании данных, содержащихся в сообщениях на основании Realm и списка известных соседей. Relay могут быть использованы для агрегации сообщений с множества узлов, расположенных в одной географической зоне.
Relay никак не модифицируют значимые поля в теле сообщения, поэтому они могут работать любыми типами приложений Diameter, тем не менее, при установлении соединения, они должны анонсировать Relay Application Id.
Proxy agent.
Proxy очень похожи на Relay, но умеют модифицировать полезную нагрузку Diameter-сообщения. Например, контролировать доступ к определенным сервисам, модифицировать значения полей и тд. Чаще всего Relay и Proxy объединяют в одну сущность, т.к. Proxy без правил преобразования является Relay-агентом.
Redirect agent (DRD)
DRD используются в том случае, если правила маршрутизации Diameter-сообщений должны контролироваться из одной точки. DRD получает запрос, определяет узел на который его надо отправить и сообщает DRL куда его надо перенаправить.
На диаграммах все выглядит гораздо проще.
Translation Agents (TLA)
И самый интересный (с моей точки зрения) класс узлов Diameter — Трансляторы протоколов. Применяются они в том случае, если физические устройства несовместимы на уровне AAA протоколов. Например, реализовать преобразование из RADIUS в Diameter и обратно. Или поддержать преобразование между 2-мя несовместимыми версиями Diameter. TLA должны обеспечивать транзакционность и хранение состояния сессии во время ее обработки.
TLA должны анонсировать только те ApplicationID, поддержка которых реализована, т.к. только в этом случае агент сможет корректно обработать входящее сообщение.
Структура пакетов
Пакеты традиционно состоят из заголовка и полезной нагрузки (в виде AVP — Attribute-Value Pair).
Назначение первых трех полей понятно.
Command-Code — код команды, которая передается в пакете
Application-Id — указатель на тип приложения
Hop-by-Hop Identifier — уникальный номер запроса в рамках соединения, ответ должен иметь тот же самый номер, это поле может модифицироваться при необходимости агентами.
End-to-End Identifier — еще один идентификатор запроса, только в отличие от Hop-by-Hop, он должен оставаться уникальным в рамках сессии, и агенты не должны его изменять.
Далее идет полезная нагрузка в виде AVP (Attribute Value Pairs).
Структура AVP тоже очень проста.
AVP Code — код атрибута, описывается в рекомендации.
За кодом идут служебные биты, длина данных и необязательное поле Vendor-ID.
После идут сами данные с определенной длиной.
Данные в свою очередь могут содержать другие наборы AVP, структура AVP отлично описывается ASN.1.
В следующей части посмотрим на то, как протокол работает, вместо описательной части разберем порядок обмена сообщений по этапам: установка соединения, обработка Diameter сессий и завершение соединения. И самое интересное — рассмотрим расширяемость протокола и его приложения.
Прокси-сервер: что это, зачем нужен, как выбрать и пользоваться
Блочный редактор писем, готовые шаблоны email, формы подписки и автоматизация. Запускайте email-рассылки, чтобы быть на связи со своими клиентами.
Как развиваться в диджитал. Какие каналы сейчас в тренде. Как зарабатывать больше и поднимать чек за свои услуги.
Рассказываем про инструменты для email-рассылок. Обсуждаем лучшие примеры и механики. Говорим о деньгах. Публикуем вакансии.
Прокси-сервер — это компьютер-посредник между пользователем и ресурсом в интернете. Если нужно открыть веб-страницу, прокси может сам сделать соответствующий запрос к нужному сайту, взять оттуда данные, проверить и отправить в браузер.
С английского proxy можно перевести как «заместитель» или «доверенное лицо». Действительно, схема похожа на то, как по доверенности получают деньги или совершают сделки за других людей. Только прокси-сервер может общаться с сайтами, приложениями и сервисами от своего имени — не сообщать, кто конечный пользователь.
Для чего используют прокси
Конфиденциальность. Прокси сам взаимодействует с интернет-ресурсами, поэтому у них нет информации, кто же на самом деле запрашивает данные. Как минимум это позволяет защититься от таргетированной рекламы на основе просмотренных товаров.
Доступ к запрещённым ресурсам. Блокировки сайтов и ограничения контента настраиваются по IP-адресам — уникальным идентификаторам вида 192.158.1.38, которые есть у каждого устройства в интернете. А промежуточный сервер скрывает реальный IP, поэтому, например, российский пользователь может зайти на LinkedIn, а житель Украины — во ВКонтакте. Это главное, зачем нужен прокси большинству пользователей.
Фильтрация и контроль. Прокси подходит не только для снятия ограничений, но и для блокировки отдельных ресурсов. Например, его используют в корпоративной сети, чтобы запретить доступ к соцмедиа и файловым хранилищам. Другой вариант: не ограничивать посещение ресурсов, а просто следить, кто их посещает и сколько времени там проводит.
Экономия и ускорение. Если пользователь регулярно заходит на один и тот же сайт, прокси может отдавать ему уже сохранённый контент вместо того, чтобы каждый раз снова его загружать. Такая опция называется кешированием. Есть ещё сжатие, которое уменьшает объём скачиваемых данных: картинок и видео.
Тестирование. Прокси-серверы позволяют отправлять запросы с разных регионов и устройств — можно оценить, как меняются скорость загрузки сайта и отображение контента.