Когда тип сервиса не моделируется явно, неправильные функции появляются не там — и операционные ошибки становятся неизбежны.
В корпоративном управлении трафиком сервисы HTTP, TCP и Layer4 — это не одно и то же. Для HTTP-трафика важны заголовки, cookie, пути, WAAP-оценки и content rules. Для TCP доминируют управление соединением, SSL-терминация и SNI. На Layer4 решения принимаются на основе протокола ядра, алгоритма и поведения персистентности. Если эти различия не моделируются явно, операторы сталкиваются с настройками, которые не могут работать в текущем контексте.
В традиционных подходах тип сервиса часто разбросан по отдельным объектам, профилям, экранам или ручным блокам конфигурации. Операторы вынуждены запоминать, какие функции применяются к каким типам трафика. Header-правило не в том месте, WAAP-настройка на неправильном сервисе или Layer 7 ожидание на Layer4 потоке — всё это превращается в ошибки во время выполнения и потерянное время.
Вторая проблема — управление несколькими группами бэкендов под одним сервисом. Отправка запросов на чтение и запись к разным целям, разделение мобильного и десктопного трафика или запуск региональных групп сервисов под единой точкой входа — всё это рассматривается как отдельная функция на большинстве платформ, добавляя концептуальный вес к тому, что должно быть простым требованием маршрутизации.
Правильный подход — явно объявить тип сервиса внутри единого объекта pool и позволить матрице функций фильтроваться автоматически. Несколько групп бэкендов должны поддерживаться под одним pool, при этом операторы видят только нужные параметры, не перегружаясь излишними техническими деталями.
Модель TR7 «Три типа сервисов» снижает эту сложность: тип сервиса выбирается заранее, подходящие функции появляются автоматически, а группы бэкендов управляются в той же модели конфигурации.
Наш подход
TR7 делает тип сервиса центральным переключателем конфигурации и организует всю видимость функций вокруг этого архитектурного выбора.
Тип сервиса выбирается при создании pool
Оператор создаёт pool, выбирая HTTP, TCP или Layer4. Этот единственный выбор определяет, какие действия, проверки работоспособности и функции трафика будут доступны в дальнейшем.
Действия автоматически фильтруются по типу сервиса
Центральная матрица функций определяет, какие действия допустимы для какого типа сервиса. GUI показывает только настройки, имеющие смысл для выбранного типа pool; технически недопустимые параметры никогда не появляются перед оператором.
Несколько групп бэкендов можно определить под одним сервисом
Каждый pool начинается с группы бэкендов по умолчанию, и дополнительные группы могут быть добавлены по мере необходимости. Трафик направляется к нужной группе через ACL и логику правил.
Тип сервиса нельзя изменить после создания — требуется новый pool
Тип сервиса — это архитектурное решение, влияющее на всю матрицу функций pool. Вместо преобразования существующего pool в другой тип рекомендуется создать новый pool и выполнить контролируемую миграцию.
Возможности
Модель трёх типов сервисов обеспечивает нужные возможности в нужном месте для трафика HTTP, TCP и Layer4.
Тип HTTP обеспечивает полную видимость Layer 7 и безопасность приложений
Тип HTTP используется для полного проксирования на уровне Layer 7. WAAP, content-aware правила, работа с заголовками и cookie, redirect, captcha, кэш ответов, компрессия и интеграция с AAM имеют смысл именно в этом типе. ALPN-параметры h2 и http/1.1 могут быть включены в поведение HTTP-сервиса. HTTP — правильный выбор, когда нужны детальное принятие решений, трансформация и политика безопасности для трафика приложений и API.
Тип TCP сосредоточен на управлении соединениями и SSL-сценариях
Тип TCP используется для сервисов, которым нужна SSL-терминация или passthrough через Layer 4 поток соединений. SNI-маршрутизация, инспекция TLS hello и управление TCP-соединениями занимают здесь ключевое место. Специфические для TCP потребности в персистентности, такие как RDP cookie persistence, адресуются в этом типе. Протокольные функции, такие как MQTT и FIX, также могут усилить логику принятия решений на TCP-уровне.
Каждая служба получает свои ядра — всплеск HTTP не заморит службу UDP
Службы HTTP, TCP и UDP не просто делят платформу: каждой опубликованной службе выделяются собственные ядра, собственный приоритет CPU и собственный потолок памяти. Кампания на веб-службе, тяжёлая политика WAF на API и всплеск DNS на UDP-слушателе остаются каждая в своей полосе. Именно это делает плотную консолидацию безопасной: двадцать служб на одном устройстве ведут себя как двадцать устройств — без двадцати устройств.
Тип Layer4 распределяет трафик TCP и UDP на уровне пакетов
Тип Layer4 используется для высокопроизводительной модели распределения, работающей на уровне пакетов. Алгоритмы IPVS, режимы NAT, DR и TUN могут применяться к TCP, UDP или protocol-agnostic потокам. В этом типе не выполняется инспекция Layer 7; решения принимаются на основе IP, порта, протокола и логики персистентности. Это правильная архитектура для DNS, телекома или чистых Layer 4 сервисов, где критична минимальная задержка.
Балансировка межсетевых экранов — «сэндвич» остаётся симметричным
Пара межсетевых экранов между двумя уровнями TR7 полезна лишь тогда, когда поток и его обратное направление идут через один и тот же экран; иначе экран видит половину разговора и отбрасывает его. Выбор по хешу источника на протокол-независимом типе сервиса даёт эту симметрию, проверки состояния выводят отказавший экран из ротации за секунды, а наращивание ёмкости — это добавление участника, а не перестройка топологии. Чего TR7 не делает — так это не синхронизирует собственные таблицы сессий экранов: это задача самого экрана, и stateful-пару по-прежнему следует кластеризовать так, как задумал её производитель.
Группа бэкендов по умолчанию определяет основной набор целей для каждого pool
Каждый pool имеет как минимум одну группу бэкендов по умолчанию. Эта группа содержит основной набор целей сервиса и алгоритм балансировки нагрузки. Когда дополнительные правила маршрутизации не написаны, трафик направляется в эту группу по умолчанию. Модель сохраняет простые сервисы простыми, при этом допуская расширение для сложных сценариев.
Дополнительные группы бэкендов создают отдельные сегменты трафика под одним сервисом
Группы, такие как `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` или `be-writes`, могут быть созданы под одним pool. Каждая группа может иметь собственный набор целей, профиль проверки работоспособности и поведение трафика. ACL и условия правил направляют запросы к нужной группе. Это делает архитектуру с несколькими целями управляемой под единой точкой входа.
Правила уровня группы определяют, где применяется каждое правило
Правила могут применяться только к группе бэкендов, как к frontend, так и к группе, или к конкретной именованной группе. Эта модель нацеливания делает область действия каждого правила явной. Например, трансформация заголовков, поведение проверки работоспособности или условие маршрутизации может быть определено исключительно для одной группы. Оператор разделяет разные сегменты трафика в рамках одного сервиса контролируемым образом.
Действия HTTP, TCP и общие действия разделены матрицей типов
CORS, шифрование cookie, добавление заголовка, удаление заголовка, перезапись пути, URI-нормализация и авторизация — действия только для HTTP. Управление TCP-соединениями и специфические для TCP параметры персистентности появляются только в типе TCP. Действия, такие как silent log, ручное правило, таблица карантина, deny и IP masking, могут использоваться в нескольких типах. Поскольку GUI автоматически обеспечивает это разделение, операторы никогда не столкнутся с неправильным действием на неправильном типе сервиса.
Ёмкость pool и лимиты соединений управляются на уровне сервиса
Максимальное число соединений и лимиты скорости соединений могут быть определены на уровне pool. Индивидуальные верхние лимиты соединений также могут применяться per бэкенд-цель. Эта модель помогает защитить как весь сервис, так и отдельные цели при высокой нагрузке. Настройки ёмкости планируются в соответствии с типом сервиса, поведением трафика и ресурсами оборудования.
Операционная глубина
Модель трёх типов сервисов рассматривается вместе с ограничениями на изменение типа, генерацией конфигурации, мониторингом работоспособности, путями статистики и поведением аудита.
Ограничение на изменение типа
Тип сервиса нельзя изменить после создания как простую настройку. Типы HTTP, TCP и Layer4 требуют разных матриц функций, разных путей обработки и разной генерации конфигурации. Когда требуется изменение типа, правильный подход — создать новый pool и выполнить контролируемую миграцию.
Размещение ACL группы
Определяется ли ACL в правиле группы бэкендов на стороне frontend или на стороне группы — зависит от целевого назначения. Это разграничение уточняет, на каком этапе обработки трафика срабатывает правило. Оно предотвращает нарушение поведения сервиса условиями, размещёнными не в том месте.
Генерация блока конфигурации
Каждая группа бэкендов формируется как отдельный блок конфигурации. Группа по умолчанию определяется отдельно от дополнительных групп, а правила привязываются к соответствующим целям. Эта структура полезна как для читаемости конфигурации, так и для сценариев отката.
Поведение HTTP/2 ALPN
Когда соответствующая настройка включена в типе HTTP, ALPN-параметры h2 и http/1.1 могут использоваться для серверных соединений. Эта настройка имеет смысл только в контексте HTTP-сервиса. От типов TCP или Layer4 не следует ожидать поведения HTTP на уровне Layer 7.
TCP SNI-маршрутизация
В типе TCP решение о маршрутизации может быть принято путём инспекции поля SNI в TLS hello-сообщении. Это используется для разделения TLS-сервисов по разным целям без выполнения полного HTTP-парсинга. SNI-решения должны тщательно планироваться в зависимости от требований passthrough или терминации.
Путь статистики Layer4
В типе Layer4 статистика поступает из механизмов распределения на уровне пакетов, а не из пути Layer 7 прокси. Идентичного поведения со статистикой HTTP или TCP-прокси ожидать не следует. Операторы, мониторящие сервисы Layer4, должны использовать правильный источник статистики.
Когда применять
HTTP API-шлюз с защитой WAAP
Команды SaaS могут управлять API-трафиком с полной видимостью Layer 7, используя тип HTTP. WAAP, JWT-валидация, content-aware правила и path-based маршрутизация применяются в рамках одной модели сервиса.
TCP-шлюз корпоративного обмена сообщениями
Корпоративные команды могут управлять сервисами, ориентированными на соединения, которым требуется SSL-терминация, passthrough или source-IP персистентность, используя тип TCP. Сервисы, не нуждающиеся в HTTP-функциях Layer 7, обслуживаются по более простой модели.
Кластер DNS-сервисов на базе UDP
Команды телекома и инфраструктуры могут распределять UDP-трафик на уровне пакетов, используя тип Layer4. Алгоритмы IPVS и параметры персистентности обеспечивают низколатентную, protocol-focused доставку сервисов.
A/B-маршрутизация с группами бэкендов HTTP
Команды e-commerce могут создавать группы, такие как `be-variant-a` и `be-variant-b`, под одним HTTP-сервисом. ACL или hash-based условия направляют трафик к разным вариантам в контролируемом режиме.
Часто задаваемые вопросы
В чём принципиальная разница между типами HTTP, TCP и Layer4?
Можно ли изменить тип сервиса после создания pool?
Как определить несколько групп бэкендов под одним сервисом?
Как отслеживается статистика в типе Layer4?
Как работает SNI-маршрутизация в типе TCP?
Какие действия можно использовать в нескольких типах сервисов?
Откройте правильную модель функций для вашего типа сервиса
Управляйте трафиком HTTP, TCP и Layer4 в единой модели конфигурации — создайте гибкую архитектуру целей с группами бэкендов. Давайте пройдёмся по живой настройке в вашей среде.