L4 vs L7 балансировка

L4 балансировщик пропускает миллионы пакетов в секунду, но не знает, что внутри. L7 понимает HTTP и может направить /api на одни серверы, /static на другие. Скорость или интеллект - что выбрать?

• **AWS NLB** (Network Load Balancer) - L4, миллионы соединений, минимальная задержка
• **AWS ALB** (Application Load Balancer) - L7, routing по URL, host-based routing
• **Cloudflare** - L7 LB с DDoS protection, WAF, кэшированием на edge

Предварительные знания

• Load Balancing: Basics

L4 Load Balancing: транспортный уровень

**L4 Load Balancer** работает на транспортном уровне (TCP/UDP). Он видит IP-адреса и порты, но не понимает содержимое пакетов. Решение о маршрутизации принимается по IP:port источника и назначения.

**Преимущества L4**: высокая производительность (миллионы соединений/сек), низкая задержка, не зависит от протокола приложения. Подходит для любого TCP/UDP трафика.

L4 LB может использовать **DSR (Direct Server Return)** - ответы от сервера идут напрямую клиенту, минуя балансировщик. Это снижает нагрузку на LB (ответы обычно больше запросов), но усложняет настройку.

L7 Load Balancing: прикладной уровень

**L7 Load Balancer** понимает протокол приложения (HTTP, gRPC, WebSocket). Он может маршрутизировать по URL, заголовкам, cookies, содержимому запроса. Это даёт гибкость, но требует больше ресурсов.

**Content-based routing** - L7 LB может направлять `/api/v1` на старые серверы, `/api/v2` на новые. Это позволяет делать canary deployments и A/B тестирование.

L7 LB терминирует TCP-соединение от клиента и открывает новое к backend. Это позволяет модифицировать запросы (добавлять заголовки), кэшировать ответы, сжимать данные.

SSL/TLS Termination

**SSL Termination** - расшифровка HTTPS на балансировщике. Backend-серверы получают обычный HTTP. Это упрощает управление сертификатами (один сертификат на LB вместо N на серверах) и снижает нагрузку на backend.

**SSL Passthrough** - альтернатива: LB не расшифровывает трафик, а передаёт TCP-пакеты напрямую. Backend сам терминирует SSL. LB работает на L4, не видит HTTP.

**SSL Re-encryption** - компромисс: LB расшифровывает HTTPS, делает routing, затем шифрует заново для backend. Двойное шифрование/дешифрование, но трафик защищён на всём пути.

Sticky Sessions: привязка к серверу

**Sticky Sessions** (session affinity) - все запросы от одного клиента идут на один сервер. Нужно, когда сервер хранит состояние сессии в памяти (legacy-приложения, WebSocket, корзина покупок).

**Проблема sticky sessions**: если сервер упал - пользователь теряет сессию. Лучший подход - stateless backend + внешнее хранилище сессий (Redis, PostgreSQL).

**IP Hash** работает на L4, но имеет проблему: за NAT сидят тысячи пользователей с одним IP - все попадут на один сервер. Cookie-based sticky работает только на L7, но точнее привязывает конкретного пользователя.

Итоги

• **L4 LB** - работает с TCP/UDP, быстрый, поддерживает DSR, но не видит HTTP. Для raw performance
• **L7 LB** - понимает HTTP, routing по URL/headers, SSL termination, кэширование. Для гибкости
• **Sticky Sessions** - привязка клиента к серверу через cookie/IP hash. Избегайте - используйте stateless + Redis

Связанные темы

L4/L7 балансировка связана с другими компонентами инфраструктуры:

• Load Balancing основы — Алгоритмы и health checks применяются на обоих уровнях
• Reverse Proxy — Nginx/HAProxy часто выполняют и L7 LB, и reverse proxy

Вопросы для размышления

• Почему для WebSocket обычно нужны sticky sessions, даже при stateless backend?
• Когда SSL Passthrough лучше SSL Termination с точки зрения безопасности?
• Как бы вы реализовали canary deployment с помощью L7 LB?

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

• alg-20-greedy