In enterprise traffic management, HTTP, TCP and Layer4 services are not the same thing. For HTTP traffic, headers, cookies, paths, WAAP scores and content rules matter. For TCP, connection handling, SSL termination and SNI dominate. At Layer4, kernel-level protocol, algorithm and persistence behaviour are what drive decisions. If these differences are not modelled explicitly, operators encounter settings that cannot work in their current context.
In traditional approaches, service type is often scattered across separate objects, profiles, screens or manual configuration blocks. Operators must memorise which features apply to which traffic type. A header rule in the wrong place, a WAAP setting on the wrong service, or a Layer 7 expectation on a Layer4 flow all translate into runtime errors and wasted time.
A second problem is managing multiple backend groups under a single service. Sending read and write requests to different targets, separating mobile and desktop traffic, or running regional service groups under a single entry point is treated as a separate feature in most platforms — adding conceptual weight to what should be a straightforward routing requirement.
The right approach is to declare the service type explicitly inside a single pool object and have the feature matrix filter itself automatically. Multiple backend groups should be supported under the same pool, while operators see only the relevant options without being overwhelmed by unnecessary technical detail.
The TR7 Three Service Types model reduces this complexity: service type is chosen upfront, the appropriate features appear automatically, and backend groups are managed within the same configuration model.
TR7 makes service type the central switch of configuration and organises all feature visibility around that architectural choice.
The operator creates a pool by choosing HTTP, TCP or Layer4. That single selection determines which actions, health checks and traffic features will be available going forward.
The central feature matrix defines which actions are valid for which service type. The GUI shows only settings that are meaningful for the selected pool type; technically invalid options never appear in front of the operator.
Every pool starts with a default backend group, and additional groups can be added as needed. Traffic is routed to the relevant group through ACL and rule logic.
Service type is the architectural decision that affects the entire feature matrix of the pool. Rather than converting an existing pool to a different type, the recommended path is to create a new pool and perform a controlled migration.
The Three Service Types model delivers the right capabilities in the right place for HTTP, TCP and Layer4 traffic.
The HTTP type is used for full Layer 7 proxy behaviour. WAAP, content-aware rules, header and cookie manipulation, redirect, captcha, response cache, compression and AAM integration are meaningful in this type. ALPN h2 and http/1.1 options can be included in HTTP service behaviour. HTTP is the right choice when detailed decision-making, transformation and security policy are needed across application and API traffic.
The TCP type is used for services that need SSL termination or passthrough over a Layer 4 connection flow. SNI-based routing, TLS hello inspection and TCP connection management are prominent here. TCP-specific persistence needs such as RDP cookie persistence can be addressed in this type. Protocol functions like MQTT and FIX can also strengthen decision logic at the TCP level.
The Layer4 type is used for the high-performance distribution model that operates at kernel level. IPVS algorithms, NAT, DR and TUN modes can be applied to TCP, UDP or protocol-agnostic flows. No Layer 7 inspection is performed in this type; decisions are based on IP, port, protocol and persistence logic. This is the right architecture for DNS, telecom or pure Layer 4 services where low latency is essential.
Every pool has at least one default backend group. This group carries the service's primary target set and load-balancing algorithm. When no additional routing rule is written, traffic is forwarded to this default group. The model keeps simple services straightforward while allowing expansion for advanced scenarios.
Groups such as `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` or `be-writes` can be created under a single pool. Each group can have its own target set, health check profile and traffic behaviour. ACL and rule conditions steer requests to the appropriate group. This makes a multi-target architecture manageable under a single entry point.
Rules can be applied only on the backend group, on both the frontend and group sides, or on a specific named group. This targeting model makes each rule's scope explicit. For example, a header transformation, health behaviour or routing condition can be defined exclusively for one group. The operator separates different traffic slices within the same service in a controlled way.
CORS, cookie encryption, add header, delete header, path rewriting, URI normalisation and authorisation are HTTP-only actions. TCP connection management and TCP-specific persistence options appear only in the TCP type. Actions such as silent log, manual rule, quarantine table, deny and IP masking can be used across multiple types. Because the GUI enforces this split automatically, operators never struggle with the wrong action on the wrong service type.
Maximum connection count and connection rate limits can be defined at the pool level. Individual connection upper limits can also be applied per backend target. This model helps protect both the overall service and individual targets under heavy traffic. Capacity settings are planned according to service type, traffic behaviour and hardware resources.
The Three Service Types model is considered alongside type-change constraints, configuration generation, health monitoring, statistics paths and audit behaviour.
Service type cannot be changed after creation as a simple setting. HTTP, TCP and Layer4 types each require a different feature matrix, different processing path and different configuration generation. When a type change is needed, the correct approach is to create a new pool and perform a controlled migration.
Whether an ACL in a backend group rule is defined on the frontend side or the group side depends on the intended target. This distinction clarifies at which stage of traffic processing the rule fires. It prevents conditions placed in the wrong location from disrupting service behaviour.
Each backend group is emitted as a separate configuration block. The default group is defined separately from additional groups, and rules are bound to their respective targets. This structure benefits both configuration readability and rollback scenarios.
When the appropriate setting is enabled in the HTTP type, h2 and http/1.1 ALPN options can be used on server-side connections. This setting is only meaningful in an HTTP service context. Layer 7 HTTP behaviour should not be expected from TCP or Layer4 types.
In the TCP type, a routing decision can be made by inspecting the SNI field in the TLS hello message. This is used to separate TLS services to different targets without performing full HTTP parsing. SNI-based decisions must be planned carefully depending on passthrough versus termination requirements.
In the Layer4 type, statistics come from kernel-level distribution mechanisms rather than the Layer 7 proxy path. Identical behaviour to HTTP or TCP proxy statistics should not be assumed. Operators monitoring Layer4 services must use the appropriate statistics source.
SaaS teams can manage API traffic under full Layer 7 visibility using the HTTP type. WAAP, JWT validation, content-aware rules and path-based routing are applied within the same service model.
Enterprise teams can manage connection-oriented services that require SSL termination, passthrough or source-IP persistence using the TCP type. Services that do not need Layer 7 HTTP features are served with a simpler model.
Telecom and infrastructure teams can distribute UDP traffic at the kernel level using the Layer4 type. IPVS algorithms and persistence options enable low-latency, protocol-focused service delivery.
E-commerce teams can create groups such as `be-variant-a` and `be-variant-b` under the same HTTP service. ACL or hash-based conditions steer traffic to different experiences in a controlled way.
Manage HTTP, TCP and Layer4 traffic in a single configuration model — build a flexible target architecture with backend groups. Let's walk through a live setup in your own environment.