L4 и L7 балансировщики: отличия, практическое сравнение и выбор под задачу

L4-балансировщик распределяет трафик по IP-адресу и порту и не читает содержимое пакета. L7-балансировщик разбирает прикладной протокол, поэтому видит URL, заголовки, cookies и тело запроса и умеет маршрутизировать по ним. Из этого различия следуют все остальные: производительность, гибкость, набор поддерживаемых протоколов и стоимость эксплуатации.

Быстрое решение для выбора. Если задача сводится к распределению TCP- или UDP-сессий (доступ к базе данных, SMTP, MQTT, прокси для сервиса без HTTP-логики), нужен L4. Если требуются маршрутизация по пути и домену, canary-релизы, ограничение частоты запросов по API-ключу или завершение TLS на прокси, нужен L7. Когда нужны оба набора возможностей, применяют гибрид: L4 принимает трафик из интернета и распределяет его между пулами L7, а L7 выполняет HTTP-маршрутизацию.

Схемы в двух строках: клиент - L4 (IP:port) - backend; клиент - L7 (Host, Path, Header) - backend. Ниже разбор по критериям с примерами инструментов, ориентирами по нагрузке и подводными камнями, которые проявляются уже в продакшене.

Что такое L4 и L7 балансировка: разница на уровне модели OSI

Термины L4 и L7 взяты из модели OSI: транспортный уровень работает с TCP- и UDP-сессиями, прикладной отвечает за протоколы HTTP, gRPC, WebSocket. Практическая граница между двумя типами балансировщиков проходит по одному признаку: разбирает ли устройство payload. Разбор уровней маршрутизации L2, L3, L4 и L7 показывает, где заканчиваются возможности сетевого оборудования и начинается логика приложения.

Что видит L4-балансировщик в трафике

L4 оперирует кортежем из пяти полей: source IP, source port, destination IP, destination port, protocol. Всё, что находится внутри полезной нагрузки, для него невидимо: HTTP-заголовки, cookies, путь и домен недоступны. Решение о том, на какой backend отправить сессию, принимается один раз при установке соединения и дальше не пересматривается для отдельных запросов.

Алгоритмы распределения ограничены статистикой соединений: round-robin, weighted round-robin, least connections, source IP hash. Алгоритм source IP hash даёт sticky sessions, но при большом числе клиентов за одним NAT он же создаёт перекос: тысячи пользователей приходят с одного адреса и попадают на один backend.

Типовые реализации L4: IPVS (наследник LVS) внутри ядра Linux, HAProxy в режиме tcp, Nginx в блоке stream, AWS Network Load Balancer, F5 в режиме транспортного уровня. TLS при таком режиме чаще всего проходит насквозь (passthrough): балансировщик не расшифровывает трафик, сертификат живёт на backend. Часть инструментов умеет смотреть поле SNI в ClientHello и маршрутизировать по имени сервера, не разрывая шифрование: например, HAProxy в режиме TCP на порту 443 с директивой tcp-request inspect-delay и ACL req.ssl_sni направляет трафик в разные TCP-бэкенды без терминации TLS (разделение трафика TCP и HTTP в HAProxy). Health-check на L4 ограничен проверкой TCP-handshake или UDP-пробы.

Что видит L7-балансировщик и какие решения принимает

L7 разбирает запрос целиком: метод, путь, заголовок Host, произвольные заголовки, cookies, тело. Это открывает маршрутизацию, недоступную на транспортном уровне. Один домен обслуживает несколько сервисов: /api уходит на api-backend, /static отдаётся с кеширующего слоя или CDN, /admin попадает на admin-backend с проверкой токена. Canary-релиз делается заголовком X-Canary или весом: 5% запросов уходят на новую версию, остальные на стабильную.

К возможностям L7 относятся переписывание и добавление заголовков (X-Forwarded-For, X-Request-ID), health-check по HTTP-коду 200 и телу ответа, rate limiting по IP или API-ключу, аутентификация на прокси (JWT, OAuth2), трансформация запросов и ответов, завершение TLS и управление сертификатами, проксирование WebSocket с обработкой upgrade, маршрутизация gRPC по имени сервиса.

Протоколы с мультиплексированием требуют отдельного пояснения. HTTP/2 и gRPC передают множество запросов внутри одного TCP-соединения. Для L4 это один поток, и распределить нагрузку по отдельным вызовам невозможно. L7 видит фреймы, поэтому балансирует на уровне запросов. Типовые реализации L7: Nginx, HAProxy в режиме http, Envoy, Traefik, AWS Application Load Balancer.

Производительность и стоимость: где L4 экономичнее

L4 обрабатывает больше соединений и гигабит на том же железе, потому что не парсит payload и обычно не терминирует TLS. Конкретные значения сильно зависят от числа рабочих процессов, размера запросов, ядра, сетевой карты и наличия аппаратного ускорения. Воспроизводимых независимых замеров, которые подходили бы любой конфигурации, нет, поэтому числа ниже стоит читать как порядок величин для планирования и проверять нагрузочным тестом на своём стенде.

Почему L4 быстрее: отсутствие парсинга и TLS-терминации

IPVS работает в ядре и не поднимает соединение в пространство пользователя, поэтому стоимость обработки пакета сводится к маршрутизации и учёту в таблице соединений. Схемы на eBPF и XDP позволяют обрабатывать пакеты раньше сетевого стека, а DPDK выводит обработку из ядра в пользовательское пространство с прямым доступом к очереди сетевой карты. Состояние приложения такой балансировщик не хранит: нет буферов запроса, нет пула соединений к backend, нет разбора протокола.

TLS passthrough перекладывает шифрование на backend. Балансировщик пересылает байты, не участвуя в handshake, и CPU на нём тратится почти только на сетевой стек.

L7 вынужден расшифровывать TLS (handshake на каждое новое соединение и симметричное шифрование на каждый пакет), разбирать HTTP, хранить буферы запросов и ответов, поддерживать состояния запросов и пул upstream-соединений. Терминация TLS остаётся главным потребителем CPU: именно поэтому на L7 пропускная способность в пересчёте на ядро ниже, а требования к памяти выше.

Разница в задержке между уровнями существует, но её абсолютная величина мала и сильно зависит от конфигурации. Точных воспроизводимых замеров «L4 добавляет единицы микросекунд, L7 — десятки и сотни» в доступных источниках нет, поэтому ориентироваться на такие числа как на норматив не стоит. Практический вывод устойчив: для интерактивного веб-приложения вклад балансировщика в общую задержку неощутим, а для высокочастотных внутренних вызовов между сервисами накопленный эффект стоит измерять на своём стенде.

Отдельный ресурс, который ограничивает L4-схемы, это таблица conntrack в ядре. Она общая для узла и может закончиться раньше, чем CPU. В Linux число записей ограничено параметром net.netfilter.nf_conntrack_max: при достижении лимита ядро выводит сообщение «nf_conntrack: table full, dropping packet», новые потоки перестают нормально создаваться, пакеты дропаются, а соединения не устанавливаются или подвисают (nf_conntrack: table full при свободном канале). Значение по умолчанию зависит от объёма RAM: в ядре 6.12 на 64-битной машине с более 4 ГиБ это 262 144, с более 1 ГиБ — 65 536, меньше — производная от RAM, но не ниже 1024; на узлах Kubernetes его переопределяет kube-proxy. По скорости порта лимит не рассчитывается: нужны пиковая скорость создания новых потоков, их тайм-ауты, число долгоживущих соединений и запас — два шлюза на 1 Гбит/с могут требовать 32 тысячи и миллион записей соответственно. Поэтому утверждение, что L4 не имеет предела по числу соединений, неверно: предел есть, и он задаётся памятью под таблицу.

Когда L7-накладные расходы оправданы

L7 нужен там, где логика маршрутизации привязана к содержимому запроса. Десять микросервисов за одним доменом без L7 потребуют либо отдельных портов, либо поддоменов на каждый сервис. Разные порты ломают привычные схемы с cookies, CORS и единым origin, а поддомены усложняют управление сертификатами. Один L7-прокси решает задачу маршрутизацией по пути.

Второй класс задач: canary и blue-green релизы, A/B-тесты, ограничение частоты по API-ключу, снятие аутентификации с backend. Реализовать их на L4 нельзя, придётся встраивать логику в приложение или в отдельный сервис, что дороже в поддержке.

Третий класс: буферизация. L7 может принять запрос целиком, освободить backend и только потом отдать ответ медленному клиенту. Это снижает влияние медленных соединений на пул backend, но переносит расход памяти на балансировщик. L4 буферов не держит, поэтому медленный клиент занимает соединение и на балансировщике, и на backend.

Гибкость и поддержка протоколов: что умеет L7 и не умеет L4

Полный список возможностей L7: маршрутизация по пути, домену, заголовкам и cookies; canary, blue-green и A/B-тесты; rate limiting по IP, ключу и пути; аутентификация JWT и OAuth2 на прокси; переписывание запросов и ответов; health-check по HTTP; проксирование WebSocket и gRPC; терминация TLS и управление сертификатами; сжатие и кеширование статики.

У L4 список короткий: распределение TCP- и UDP-сессий, sticky sessions через source IP hash, проверка доступности порта. Различать запросы внутри одного TCP-соединения L4 не умеет, поэтому HTTP/2, gRPC и мультиплексированный трафик для него выглядят как один поток.

Маршрутизация по URL, заголовкам и cookies

Практический пример на одном домене. Путь /api уходит на api-backend, /admin на admin-backend с проверкой JWT на прокси, /static отдаётся напрямую или через CDN. На L4 тот же результат достигается разными портами или поддоменами, а значит требуется отдельная настройка DNS, сертификатов и CORS на каждом из них.

Cookies и заголовки позволяют делать sticky sessions без привязки к IP. Это важно для клиентов за NAT и для мобильных сетей, где адрес меняется при переключении между Wi-Fi и LTE: сессия, привязанная к IP, на L4 порвётся, а привязка по cookie на L7 сохранит её.

Canary-деплой, A/B-тесты и rate limiting на L7

Canary настраивается весом или заголовком: 5% трафика на новую версию, остальное на стабильную, с постепенным увеличением доли. A/B-тест делит аудиторию по cookie или user-agent. Rate limiting ограничивает частоту по IP, API-ключу или конкретному пути и защищает backend от всплесков и перебора. Всё это меняется в конфигурации прокси без правок в приложении и без релиза. На L4 такие задачи решаются только средствами самого приложения или внешних систем, например через WAF или сервис квот.

Сложность эксплуатации: что ломается на L4 и что на L7

L4 проще: меньше конфигурации, меньше состояния, легче отладка. Ломается он на границах: таблица conntrack, MTU, отсутствие нормальной проверки доступности. L7 сложнее: сертификаты, таймауты, буферизация, drain соединений, sticky sessions, обновление конфигурации без разрыва. И L7-балансировщик сам становится точкой отказа, для которой нужна пара узлов и виртуальный адрес.

Типичные ошибки при настройке L4

• Переполнение conntrack при высоком числе коротких соединений. Симптомы: потери пакетов, записи в логах ядра, рост задержки. Лечится увеличением таблицы и уменьшением времени жизни записей для короткоживущих сессий.
• Отсутствие health-check на уровне TCP. Трафик продолжает идти на backend, который слушает порт, но не отвечает по прикладной логике. Проверка должна включать не только handshake, но и готовность сервиса.
• Неправильный MTU при DSR и туннелировании. Инкапсуляция съедает часть MTU, крупные пакеты фрагментируются или отбрасываются, handshake проходит, а передача данных зависает.
• Source IP hash за NAT. Балансировка превращается в неравномерную, потому что тысячи клиентов выглядят как один адрес. Там, где sticky не обязателен, стоит брать least connections.

Готовые конфигурации для типовых сценариев на транспортном уровне собраны в материале балансировка TCP/UDP-трафика: от HAProxy до Nginx Stream, включая проверки доступности и работу с SSL.

Типичные ошибки при настройке L7

• Неверные таймауты. Короткий таймаут на upstream даёт 502 и 504 на долгих запросах, длинный удерживает воркеры и соединения под нагрузкой. Значения надо подбирать под профиль запросов, а не копировать из примеров.
• Потеря реального IP клиента. Без X-Forwarded-For или PROXY protocol логи, rate limiting и геофильтры видят адрес балансировщика.
• Буферизация крупных загрузок. Прокси, кеширующий тело запроса целиком, расходует память или диск и падает на больших файлах. Для загрузок буферизацию отключают.
• Sticky sessions без общего хранилища. Сессия, сохранённая в памяти одного узла L7, теряется при перезапуске или переключении на второй узел.
• Reload конфигурации с разрывом соединений. Обновление сертификата или правил без hot-reload и без connection draining рвёт активные запросы и заметно для пользователей.

Различия между популярными L7-прокси по производительности, конфигурации и поддержке HTTP/3 и gRPC разобраны в сравнении Nginx, HAProxy и Traefik в 2026 году.

Гибридная схема: L4 на входе, L7 внутри

Схема, которая закрывает оба набора требований: L4 (IPVS, облачный NLB, HAProxy в режиме tcp) принимает трафик из интернета, распределяет его между пулами L7-балансировщиков (Nginx, Envoy, Traefik), а те выполняют HTTP-маршрутизацию. L4 отвечает за отказоустойчивость и поглощение соединений, L7 за гибкость. Пул L7 можно масштабировать независимо, а L4 остаётся простым и предсказуемым по нагрузке.

Отказоустойчивость входа обеспечивают keepalived с VRRP (один виртуальный адрес на пару узлов) либо ECMP с анонсом адреса по BGP, когда трафик раскидывается на несколько узлов одновременно. Второй вариант даёт active-active вместо active-passive.

Как сохранить реальные IP клиентов

Вариантов три. PROXY protocol: L4 добавляет к соединению служебный заголовок с исходным адресом, L7 его читает. Включать нужно на обоих концах (send-proxy на входе, accept-proxy на L7), иначе соединения будут отклоняться или логи покажут адрес балансировщика. X-Forwarded-For работает только для HTTP и легко подделывается клиентом, если L7 не доверяет источнику. DSR (direct server return) — метод балансировки, при котором ответный трафик от сервера маршрутизируется асимметрично, минуя балансировщик, и уходит клиенту через шлюз по умолчанию сервера; для этого сервер должен получать исходный IP клиента, чтобы иметь возможность ответить ему напрямую (Direct Server Return with Kubernetes).

Пример гибридной схемы в Kubernetes

Service типа LoadBalancer создаёт транспортный балансировщик (облачный NLB либо MetalLB в bare-metal кластере). Ingress Controller (Nginx, Traefik, Envoy) работает на L7 и маршрутизирует по Host и Path, распределяя запросы между подами. L4 распределяет TCP-соединения между подами контроллера, а не между приложениями, поэтому число соединений здесь меньше, чем число запросов.

Если облачный балансировщик недоступен, вход делают через Service типа NodePort и внешний L4-балансировщик. Сохранение исходного адреса обеспечивают режим externalTrafficPolicy: Local на Service либо поддержка PROXY protocol в контроллере. В Kubernetes DSR реализуется через kube-proxy в режиме IPVS (поддерживается с версии 1.11) с externalTrafficPolicy: Local на сервисах LoadBalancer или NodePort (Direct Server Return with Kubernetes). Архитектурные схемы развёртывания, включая active-active и active-passive, разобраны в руководстве балансировка нагрузки: архитектура, типы и схемы развёртывания.

Цена гибрида: добавочный хоп, два набора конфигураций и более длинная цепочка при отладке. Проблему с реальным IP приходится решать явно, а трассировка запроса требует смотреть логи и на L4, и на L7.

Чек-лист выбора: L4 или L7 для вашего проекта

Ответьте на вопросы по своему проекту. Каждое «да» в первых четырёх пунктах сдвигает решение в сторону L7.

1. Нужна маршрутизация по URL, домену или заголовкам? Если да, L4 не подходит без смены портов и поддоменов.
2. Нужны canary-релизы, blue-green или A/B-тесты на уровне трафика?
3. Нужна терминация TLS, управление сертификатами или проверка JWT на прокси?
4. Нужны rate limiting, WAF-правила или трансформация заголовков?
5. Какой протокол у трафика: HTTP/HTTPS, gRPC, WebSocket или произвольный TCP/UDP? Первые три обычно требуют L7, последний чаще закрывает L4.
6. Какие требования по RPS, числу одновременных соединений и задержке? Если задержка критична и прикладная логика маршрутизации не нужна, выигрывает L4.
7. Есть ли ресурсы на эксплуатацию L7: обновление сертификатов, таймауты, релизы конфигурации без downtime, дежурство?

Правило сведения: хотя бы один пункт про маршрутизацию, canary или TLS-терминацию означает L7; только TCP/UDP с приоритетом производительности означает L4; совпадение обоих наборов требований означает гибрид.

Матрица решений по сценариям

Итог: как выбрать и что проверить перед запуском в продакшен

L4 даёт скорость и простоту, L7 гибкость и функциональность, гибрид объединяет оба набора свойств ценой усложнения отладки. Четыре шага перед запуском:

1. Зафиксируйте протоколы, требуемую логику маршрутизации и целевые показатели по RPS, соединениям и задержке. Это определяет уровень, а не наоборот.
2. Проведите нагрузочный тест выбранного варианта с реальным профилем запросов. Ориентиры по производительности из статей не заменяют замер на вашем железе, ядре и версии прокси.
3. Настройте мониторинг до релиза: занятость таблицы conntrack, число активных соединений, задержка на балансировщике, коды 5xx, время ответа upstream. Без этих метрик разница между L4 и L7 обсуждается теоретически.
4. Подготовьте план отката: резервный узел, сохранённая предыдущая конфигурация, порядок переключения. Для L7 добавьте процедуру обновления сертификатов без разрыва соединений.

Конфигурации и поведение зависят от версии ПО: синтаксис директив, поддержка HTTP/3 и PROXY protocol отличаются между релизами. Сверяйтесь с документацией вашей версии перед применением примеров. Общие принципы маршрутизации и фильтрации трафика, включая работу балансировщиков в связке с routing-политиками, разобраны в руководстве основы маршрутизации в 2026 году.