Различие уровней OSI, которое по-прежнему важно
Концепция балансировки нагрузки проста: распределить входящие запросы между несколькими экземплярами сервиса так, чтобы ни один сервер не перегружался, а приложение оставалось доступным. Интересно то, как вы принимаете решение о распределении. Самое значимое разделение находится между Layer 4 и Layer 7.
Layer 4 балансировка нагрузки работает на транспортном уровне модели OSI — TCP и UDP. Балансировщик видит IP источника, IP назначения и порты соединения; больше ничего. Он принимает решение о распределении на основе этих полей заголовка и затем пропускает байты, не проверяя полезную нагрузку. Прикладной протокол может быть HTTP, MySQL, Kafka или пользовательским бинарным — балансировщик не знает и его это не волнует.
Layer 7 балансировка нагрузки работает на прикладном уровне — HTTP, HTTPS, gRPC, WebSocket. Балансировщик разбирает каждый запрос, читает URL-путь, заголовки, cookies и метод и принимает решения о маршрутизации на основе этого содержимого. Он также может преобразовывать запросы на лету: сжатие, переписывание заголовков, терминация TLS, кэширование.
Layer 7 мощнее Layer 4 и дороже Layer 4. Выбор между ними зависит от того, имеет ли прикладной протокол HTTP-форму и стоят ли дополнительные возможности своей цены на соединение.
Когда Layer 4 — правильный выбор
Сценарии, где L4 — правильный ответ, разделяют одно свойство: разбор содержимого приложения либо не нужен, либо не помещается в бюджет.
Не-HTTP протоколы — самый ясный пример этой категории. Для баз данных (MySQL, PostgreSQL), очередей сообщений (Kafka, RabbitMQ), электронной почты (SMTP) и пользовательских TCP-сервисов балансировщику не нужно понимать содержимое приложения — распределение по портам и частоте соединений работает хорошо.
Чисто производительные требования также указывают на L4. Накладная нагрузка L4 на соединение самая низкая, потому что нет разбора приложения. Для высоконагруженных TCP-сервисов, где каждая микросекунда имеет значение — торговые платформы, чувствительные к задержке, backend-системы для игр в реальном времени и похожие задачи — L4 — правильный инструмент.
Сквозное шифрование — ещё один случай L4. Когда TLS должен терминироваться в приложении, а не на балансировщике — регуляторное требование, изоляция multi-tenant, ключи, контролируемые клиентом — L4 прозрачно пропускает TLS. Балансировщик никогда не видит открытый текст.
Наконец, если простой логики распределения достаточно, L4 работает с меньшими операционными накладными расходами. Если хватает round-robin, hash по IP источника или least-connections и не нужна маршрутизация на основе URL, L4 одновременно легче и проще для рассуждения.
Когда Layer 7 — правильный выбор
L7 отличает способность принимать решения о маршрутизации и преобразовании на основе содержимого приложения. Без этой способности большинство современных веб-приложений не работали бы.
Маршрутизация по URL — самый частый случай. Отправка разных путей в разные кластеры сервисов — /api/v1/users в один кластер, /api/v1/orders в другой, /static/* на CDN — невозможна с L4, потому что L4 не видит пути.
Маршрутизация по заголовку или cookie также требует L7. A/B-тесты, фиксация версии (X-Service-Version: 2.5 направляет на конкретное развёртывание), session affinity по идентификатору сессии приложения и маршрутизация по клиенту через заголовок — все требуют чтения содержимого приложения.
Терминация TLS — также задача L7. SSL offload терминирует TLS на балансировщике, освобождая сервисы от криптографической работы; обеспечивает централизованное управление сертификатами; обеспечивает WAF-инспекцию. WAF нужен открытый текст, чтобы увидеть атаки; без L7 этого не происходит.
Функции, осведомлённые о приложении — сжатие, кэширование, переписывание запросов, health check на основе содержимого (сервис возвращает 200 по /health, а не просто принимает соединение) и понижение HTTP/2 до HTTP/1.1 для устаревших сервисов — также требуют L7.
Наблюдаемость на уровне приложения следует той же логике. Латентность по endpoint'у, частота ошибок по URL, обнаружение медленных запросов — это требует видеть запросы, а не соединения. L7 выводит эти данные; L4 видит только уровень соединения.
Главная мысль такова: если вы принимаете решение на основе содержимого приложения, L7 обязателен. Если только на уровне соединения, L4 достаточно.
Прямое сравнение
| Параметр | Layer 4 | Layer 7 |
|---|---|---|
| Уровень OSI | Транспортный (TCP/UDP) | Прикладной (HTTP, HTTPS, gRPC, WebSocket) |
| Входы маршрутизации | IP источника, IP назначения, порты | URL, заголовки, cookies, метод, тело |
| Обработка TLS | Pass-through | Терминировать или pass-through |
| Накладная нагрузка на соединение | Минимальная | Выше (требуется разбор) |
| Алгоритмы распределения | Round-robin, hash IP источника, least-connections | Все алгоритмы L4 плюс маршрутизация по содержимому, вес по URL |
| Интеграция WAF | Невозможна (нет видимости содержимого) | Нативная |
| Наблюдаемость | Уровень соединения | Уровень запроса |
| Типичный сценарий | Проксирование БД, игры, RTMP, SMTP | Веб-приложения, API, микросервисы |
Современные развёртывания используют оба
Решение редко формулируется как «L4 или L7» для всей инфраструктуры. Оно принимается на уровне приложения — иногда на уровне listener'а.
Типичная корпоративная схема сочетает оба режима. L7 на границе для HTTPS-трафика пользователей; L4 для внутреннего восток-западного трафика, где протокол нативно TCP и бюджет задержки жёсткий; L7 снова там, где восток-западный трафик идёт по RPC поверх HTTP, например gRPC.
Архитектурный вопрос в том, может ли одно развёртывание балансировщика обрабатывать оба режима или организация должна эксплуатировать отдельные L4 и L7 продукты. Подход с раздельными продуктами был исторически распространён, потому что у L4 и L7 были разные требования к реализации — L4 хотел packet-path сеть, L7 — богатый разбор HTTP. Современные ADC закрыли этот разрыв; одно устройство обрабатывает оба режима через конфигурацию на уровне listener'а.
Операционная польза от их объединения такая же, как у любой консолидации: один продукт для развёртывания, одна поверхность наблюдаемости, один набор операционных runbook'ов, один путь обновления. Для организаций, которые ранее эксплуатировали L4 и L7 продукты от разных вендоров, консолидация на одном ADC часто является наибольшим доступным операционным упрощением.
Как TR7 Load Balancer обрабатывает оба режима
Load Balancer (LB) от TR7 несёт оба режима L4 и L7 на одном устройстве через конфигурацию на уровне listener'а. Одно развёртывание может разместить эти listener'ы бок о бок: L7 listener на 443 обрабатывает HTTPS веб-трафик с WAF и SSL-ускорением; L4 listener на 5432 обрабатывает соединения PostgreSQL с привязкой по IP источника; ещё один L7 listener на 8080 обрабатывает внутренние gRPC сервисы с mTLS. Все настроены вместе, разделяя наблюдаемость и единый жизненный цикл обновлений.
Аппаратное ускорение применяется к обоим режимам. L4-соединения выигрывают от packet-path обработки пакетов; L7-соединения выигрывают от offload-терминации TLS и разбора HTTP/2 / HTTP/3. Одно физическое устройство может нести тысячи L4 TCP-сервисов одновременно с тысячами L7 HTTPS-сессий; предел — аппаратная огибающая, а не лицензия или feature gate по режимам.
Для организаций, выбирающих между вендорами в 2026 году, вопрос «поддерживает ли этот LB и L4, и L7?» больше не является дифференциатором; большинство поддерживают. Дифференциаторы — операционная история (один продукт или два), история наблюдаемости (единая или раздельная) и история модернизации (HTTP/3, TLS 1.3, поддержка постквантовой криптографии). TR7 позиционируется вокруг этих трёх осей; способность L4 и L7 — это вход.
L4 + L7 на одной платформе
TR7 Load Balancer несёт режимы L4 и L7 на одном устройстве с аппаратным ускорением для обоих. Одна поверхность наблюдаемости, один путь обновления, оба режима доступны на уровне listener'а.
Узнать о TR7 Load Balancer