L4 (уровень транспортный) — как работает и что делает

L4-балансировщик оперирует на уровне транспортного протокола (TCP/UDP). Он смотрит на IP-адреса и порты, не заглядывая в содержимое пакетов (payload). При поступлении соединения балансировщик выбирает бэкэнд-сервер и либо перенаправляет (DNAT) поток на его IP:port, либо выступает в роли прозрачного прокси и терминирует TCP/UDP, создавая своё соединение к бэкенду.

Основные детали:

• маршрутизация по IP/портам; не разбирает HTTP-заголовки;

• использует алгоритмы round-robin, least-connections, source IP hash и т.д.;

• health-check обычно простой — TCP-handshake (порт открыт) или UDP probe;

• поддерживает очень низкую задержку и высокую пропускную способность (меньше CPU-затрат на обработку пакетов);

• может работать в режиме passthrough (TLS/SSH шифрование проходит насквозь, бэкенд расшифровывает) или proxy (терминирует соединение).
  Применение: базы данных, SMTP, SSH, игровые сервера, любые нестандартные TCP/UDP-протоколы, где важна производительность и прозрачность трафика.

L7 (уровень прикладной) — как работает и дополнительные возможности

L7-балансировщик — это reverse proxy, который полностью понимает протокол (чаще всего HTTP/HTTPS). Он парсит заголовки, метод, URL, тело запросов, и на основе этого принимает решения о маршрутизации.

Типичные возможности:

• host- и path-based routing (направить api.example.com/v1 в один сервис, а static.example.com — в другой);

• SSL/TLS termination (расшифровывает HTTPS) и SSL offloading; поддержка SNI и client certs; также возможен TLS passthrough;

• вставка/удаление заголовков (X-Forwarded-For, X-Real-IP), URL-rewrite, redirectы;

• sticky sessions: cookie-based affinity или application cookie insertion;

• HTTP/2 и WebSocket-прокси (терминирует и проксирует вышеуровневые протоколы);

• rate-limiting, WAF (Web Application Firewall), caching, compression, auth-hooks;

• health checks глубокие — HTTP endpoint с кодом 200/204 и проверкой payload/заголовков.
  Применение: веб-API, микросервисы, CDN-передняя логика, маршрутизация на основе контента, security-фильтры.

Ключевые различия (коротко)

• осведомлённость о протоколе: L4 — нет, L7 — да;

• гранулярность маршрутизации: L4 — IP/порт, L7 — URL/заголовки/методы;

• TLS: L4 часто passthrough или простая трансляция, L7 — может терминировать и управлять сертификатами;

• производительность: L4 быстрее и легче по CPU, L7 даёт богатые возможности, но дороже в ресурсах и с большей задержкой;

• сохранение IP клиента: L7 обычно добавляет X-Forwarded-For; L4 для сохранения оригинального IP требует proxy protocol или transparent routing.

Алгоритмы балансировки

• Round-robin — по очереди; прост и часто достаточен.

• Least connections — отдаёт новым соединениям сервера с наименьшим количеством активных сессий; лучше при долгоживущих соединениях.

• Source IP hash — привязка по IP клиента (affinity); полезно при stateful backend.

• Weighted — сервера с разной «весом» (мощностью).

• Consistent hashing — полезно для кэш-кластеров, чтобы минимизировать перекомпонование ключей при добавлении/удалении нод.

Практические нюансы и рекомендации

• Для статичных HTTP-сервисов и сложных правил маршрутизации берите L7; для высокопроизводительных TCP/UDP-нагрузок — L4.

• Sticky sessions удобны, но лучше переводить приложение на stateless (сессии в Redis), чтобы не зависеть от привязки.

• При использовании TLS-termination помните о безопасности: закрывайте доступ к бэкендам по HTTPS/TLS или используйте mTLS между LB и бэкендами.

• Если нужен оригинальный IP клиента на бэкенде и вы используете L4 passthrough, применяйте proxy protocol или делайте transparent routing; для L7 — считайте X-Forwarded-For.

• Планируйте drain/connection-draining: при выводе инстанса из пула LB должен дать время завершить текущие соединения.

• Health checks делайте как поверхностные (TCP) для L4, так и глубокие (HTTP endpoint /health) для L7, чтобы LB корректно исключал нездоровые ноды.