Сети и протоколы

Что делают обратные прокси

Суть Обратный прокси незаметно стоит между клиентами и backends — он завершает клиентское соединение, выбирает backend и пересылает запрос, отделяя масштабирование от клиентской видимости.

Высота — путь к senior

НольJuniorMiddleSenior

Ты на junior-высоте — поверхность

◷ 8 min

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

Невидимый посредник

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

Завершает TCP (и TLS) рукопожатие с клиентом.
Выбирает backend из своего пула.
Открывает отдельное TCP-соединение к этому backend.
Пересылает запрос клиента на backend.
Ждёт ответ backend и передаёт его клиенту.

Клиент никогда не видит IP-адрес backend и не знает, сколько backends существует. Это ключевое свойство: клиент говорит с одним адресом; прокси говорит со многими.

Почему два соединения, а не пересылка пакетов

Простой пересыльщик пакетов (layer 3 NAT) передаёт пакеты без изменений — он не может инспектировать или модифицировать полезную нагрузку. Обратный прокси, который маршрутизирует по HTTP, должен распарсить запрос, чтобы решить, куда его отправить. Парсинг требует владения обеими сторонами: клиентским TCP-соединением (для чтения запроса) и backend-TCP-соединением (для его отправки).

Именно эта двухсоединительная модель делает прокси мощным и видимым для каждой стороны. Backend видит IP прокси, а не IP клиента — вопрос, рассматриваемый в следующем уроке.

Метафора ресторана

Ресторан с одним хостом (load balancer) и несколькими шеф-поварами (backends). Когда гость (клиент) приходит, хост решает, кто из поваров наименее занят, передаёт заказ и возвращает блюдо гостю. Гости никогда не говорят с поварами. Если повар заболел, хост прекращает отправлять к нему заказы — незаметно.

Основы обратного прокси

Соединения, видимые клиенту: 1 (к IP прокси)
TCP-соединений на запрос (L7 прокси): 2 (клиент→прокси + прокси→backend)
Backends, видимых клиенту: 0 (прокси скрывает все)
Интервал health check (типичный): 10–30 с
Backends, которые может обслуживать один nginx: сотни
Zero-downtime деплой: drain + swap: да, через health check + draining

Что происходит при падении backend

Цикл health check прокси зондирует каждый backend с фиксированным интервалом (10–30 с). После 2–3 последовательных отказов backend помечается unhealthy и новые запросы к нему больше не маршрутизируются. Когда backend восстанавливается, он возвращается в пул после 2–3 последовательных успехов.

Это означает:

Клиенты маршрутизируются только к здоровым backends.
Падение backend невидимо для новых клиентов в пределах одного интервала health check.
Активные соединения к упавшему backend всё равно падают — прокси не может воскресить умершее TCP-соединение.

Почему это работает

Почему forward proxy отличается. Forward proxy (например, корпоративный веб-фильтр) стоит на исходящем пути: клиент знает о нём и подключается к нему умышленно. Reverse proxy стоит на входящем пути: клиент о нём не знает и считает, что говорит напрямую с origin-сервером. Forward proxies реализуют клиентскую политику; reverse proxies обеспечивают серверное масштабирование и отказоустойчивость.

Викторина

Почему обратный прокси открывает ДВА отдельных TCP-соединения вместо того, чтобы пересылать пакеты напрямую на backend?

Викторина

Backend падает в середине запроса. Что load balancer делает со СЛЕДУЮЩИМ клиентским запросом?

Расставь шаги по порядку

Расставьте последовательность, когда клиент делает запрос через load balancer:

1 Клиент устанавливает TCP-соединение к load balancer
2 Клиент отправляет HTTP-запрос к load balancer
3 Load balancer выбирает здоровый backend
4 Load balancer открывает TCP-соединение к этому backend
5 Load balancer пересылает запрос клиента на backend
6 Backend обрабатывает запрос и отправляет ответ
7 Load balancer пересылает ответ обратно клиенту

Закончи аналогию

Load balancer похож на ресторанного _______, который усаживает гостей и направляет заказы на кухню.

Вспомните перед уходом

01
Почему load balancer должен определять состояние backend?
02
В чём ключевое отличие forward proxy от reverse proxy?
03
Почему reverse proxy открывает два TCP-соединения на запрос, а не пересылает пакеты на уровне L3?

Итог

Обратный прокси является публичным лицом всего пула backends: клиенты подключаются к одному IP, прокси выбирает здоровый backend, открывает собственное соединение к нему и передаёт трафик в обе стороны. Два TCP-соединения на запрос — плата за возможность парсить и маршрутизировать HTTP. Health checks работают в фоне каждые 10–30 секунд; после 2–3 отказов backend удаляется из пула и трафик немедленно перераспределяется. Это разделение — клиенты говорят с одним адресом, backends меняются свободно — делает zero-downtime деплои и масштабирование невидимыми для пользователей.

Связанные уроки

углубляется в

встречается в258

Продолжить восхождение ↑Алгоритмы балансировки: от round-robin до power-of-two-choices