HTTP information
HTTP(S) ports are supported on all services and provide Layer 7 protection and HTTP rule capabilities. The protocol between a visitor and X4B is separate from the protocol and encryption used between X4B and your backend.
HTTP DNS Backend
HTTP(S) ports can forward to one or more backend IP addresses (the recommended setup) or to hostnames. A hostname lets the origin operator change addresses without editing the backend entry. This supports DNS-based load distribution, geographic routing and third-party integrations; ghs.google.com is an example of a provider-supplied hostname. It must resolve to an origin that accepts your site's requests; do not point it back at the protected frontend.
DNS resolution and connection reuse
| Backend configuration | Address selection | Backend keepalive |
|---|---|---|
| IP address | Uses the configured address | Available when enabled |
| Simple hostname backend, DNS Cache Hosts = 0 | Selects from cached DNS answers | New connection per request |
| Hostname with DNS Cache Hosts enabled, or in load-balancing mode | Refreshes up to the configured number of addresses | Available when enabled |
DNS answers are cached. When a hostname returns multiple addresses, requests can use any of them.
Hostname backends currently resolve to IPv4 addresses, with DNS answers cached for five minutes. Allow for that cache lifetime when changing backend addresses. Geographic DNS answers depend on the resolver's location and the DNS provider's policy. Use responsive DNS servers: a lookup can delay a request when no usable cached address is available.
See Load Balancing for DNS Cache Hosts, refresh failures and balancing methods. Configure the backend Host header and HTTPS settings to match your origin.
HTTP/2 Information
HTTP/2, originally called HTTP/2.0, is the second major HTTP version. It is enabled by default on HTTPS ports and can be disabled in the SSL options. Clients negotiate the supported frontend protocol. The backend does not need HTTP/2 support: X4B handles the visitor connection separately from the backend connection.
Benefits of HTTP/2
HTTP/2 can reduce page-loading delays, particularly for pages with many resources and visitors on higher-latency connections:
- Multiplexing: Requests and responses share one connection as independent streams. A browser can fetch HTML, stylesheets, scripts and images concurrently.
- Connection reuse: Sharing a connection reduces the TCP and TLS handshakes needed to fetch those resources and makes better use of an established connection.
- Header compression: HPACK compresses request and response headers, including repeated fields, reducing transferred bytes. Response-body compression remains a separate setting.
HTTP methods, URLs and status codes retain their meaning, so an existing web application can benefit without changing its request handling. Clients and servers can also prioritize streams so important resources receive attention earlier; the effect depends on their implementations.
HTTP/2 uses binary frames on the connection; use an HTTP/2-aware tool such as Wireshark when inspecting that traffic. Performance still depends on the page, backend response times and network conditions. HTTP/2 uses TCP, so packet loss can delay all streams sharing a connection. Test representative pages when assessing the benefit for your site.
See the HTTP/2 specification and HPACK header compression.
HTTP/3 Information
HTTP/3 carries HTTP over QUIC and was standardized in June 2022 in RFC 9114. At this time we do not offer Layer 7 protection over HTTP/3; however, HTTP/3 traffic is protected at Layer 4 and can be forwarded with a UDP type port.
