When service type is not clearly modelled, the wrong features appear in the wrong place and operational errors become inevitable.
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, packet-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.
Our approach
TR7 makes service type the central switch of configuration and organises all feature visibility around that architectural choice.
Service type is selected at pool creation time
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.
Actions are automatically filtered by service type
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.
Multiple backend groups can be defined under a single service
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 cannot be changed after creation — a new pool is required
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.
Capabilities
The Three Service Types model delivers the right capabilities in the right place for HTTP, TCP and Layer4 traffic.
HTTP type provides full Layer 7 visibility and application security
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.
TCP type focuses on connection management and SSL scenarios
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.
Each service gets its own cores — an HTTP surge cannot starve a UDP service
HTTP, TCP and UDP services do not merely share a platform; each published service is given its own cores, its own CPU priority and its own memory ceiling. A campaign on the web service, a heavy WAF policy on the API and a DNS burst on the UDP listener therefore stay in their own lanes. That is what makes dense consolidation safe: twenty services on one appliance behave like twenty appliances, without twenty appliances.
Layer4 type distributes TCP and UDP traffic at packet level
The Layer4 type is used for the high-performance distribution model that operates at packet 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.
Firewall load balancing — the sandwich stays symmetric
A pair of firewalls between two TR7 layers is only useful if a flow and its return take the same firewall; otherwise the firewall sees half a conversation and drops it. Source-hash selection on the protocol-agnostic service type gives that symmetry, health checks take a failed firewall out of rotation in seconds, and adding capacity is adding a member rather than rebuilding the topology. What TR7 does not do is synchronise the firewalls' own session tables — that remains the firewall's job, and a stateful pair should still be clustered as its vendor intends.
The default backend group defines the primary target set for every pool
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.
Additional backend groups create separate traffic slices under the same service
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.
Group-level rules determine where each rule is applied
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.
HTTP, TCP and shared actions are separated by the type matrix
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.
Pool capacity and connection limits are managed at the service level
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.
Operational depth
The Three Service Types model is considered alongside type-change constraints, configuration generation, health monitoring, statistics paths and audit behaviour.
Type-change constraint
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.
Group ACL placement
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.
Configuration block generation
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.
HTTP/2 ALPN behaviour
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.
TCP SNI routing
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.
Layer4 statistics path
In the Layer4 type, statistics come from packet-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.
When to use it
HTTP API gateway with WAAP protection
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.
TCP-based enterprise messaging gateway
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.
UDP-based DNS service cluster
Telecom and infrastructure teams can distribute UDP traffic at packet level using the Layer4 type. IPVS algorithms and persistence options enable low-latency, protocol-focused service delivery.
A/B routing with HTTP backend groups
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.
Frequently asked questions
What is the fundamental difference between HTTP, TCP and Layer4 types?
Can the service type be changed after the pool is created?
How are multiple backend groups defined under the same service?
How are statistics monitored in the Layer4 type?
How does SNI-based routing work in the TCP type?
Which actions can be used across more than one service type?
Discover the right feature model for your service type
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.