HTTP/2 and Proxy

Proxy services support HTTP/2 by acting as an intermediary that can either terminate HTTP/2 connections and forward requests over HTTP/1.1 to origin servers, or pass through HTTP/2 end-to-end between client and origin.

HTTP/2 is a significant revision of the HTTP protocol, designed to improve web performance by addressing inherent limitations of HTTP/1.1. Key features include full request and response multiplexing, header compression via HPACK, server push, and request prioritization. For a proxy service, managing these features requires specific architectural considerations to leverage HTTP/2's benefits while maintaining compatibility and control.

HTTP/2 Protocol Fundamentals

HTTP/2 operates over a single TCP connection, establishing multiple bidirectional streams for concurrent request and response messaging. This multiplexing eliminates head-of-line blocking present in HTTP/1.1. Header compression (HPACK) reduces overhead by encoding HTTP headers into a compact binary format and maintaining a shared dynamic table. Server push allows the server to proactively send resources to the client that it anticipates will be needed, reducing latency.

These features, while beneficial, introduce complexities for proxy services that traditionally operate on a request-response model over individual TCP connections.

Proxy Architectures for HTTP/2

Proxy services typically implement one of two primary architectures for HTTP/2 support: termination or end-to-end.

HTTP/2 Termination (Frontend HTTP/2, Backend HTTP/1.1)

In this model, the proxy server establishes an HTTP/2 connection with the client. It terminates the HTTP/2 protocol, decodes requests, and then forwards them to the origin server using HTTP/1.1. The responses from the origin server (HTTP/1.1) are then transcoded back into HTTP/2 and sent to the client.

Process Flow:

1. Client initiates an HTTP/2 connection to the proxy (typically over TLS with ALPN negotiating h2).
2. Proxy receives HTTP/2 frames, reconstructs HTTP/1.1-like requests (including decoding HPACK headers).
3. Proxy forwards HTTP/1.1 requests to the origin server.
4. Origin server responds with HTTP/1.1.
5. Proxy receives HTTP/1.1 responses, encodes them into HTTP/2 frames (including HPACK compression), and sends them to the client.

Advantages:

• Backend Compatibility: Origin servers do not need to support HTTP/2. This is beneficial for legacy systems or services that have not yet upgraded.
• Offloading: The proxy handles the computational overhead of HTTP/2 protocol negotiation, header compression/decompression, and stream management, reducing the load on origin servers.
• Control: Easier to perform traditional proxy functions like caching, load balancing, request modification, and security filtering, which are often designed for HTTP/1.1 semantics.

Disadvantages:

• Feature Loss: HTTP/2 features like server push from the origin server cannot be directly passed through. The proxy would need to implement its own server push logic.
• Protocol Mismatch Overhead: The constant transcoding between HTTP/2 and HTTP/1.1 introduces processing overhead at the proxy.
• Increased Latency: The additional processing step can introduce minor latency compared to a direct HTTP/2 connection.

Use Case: Ideal for scenarios where client-side performance benefits of HTTP/2 are desired, but the backend infrastructure is not yet HTTP/2-ready, or when extensive proxy-side request manipulation is required.

HTTP/2 End-to-End (Full Proxy)

In an end-to-end HTTP/2 proxy setup, the proxy maintains HTTP/2 connections with both the client and the origin server. The proxy acts as a transparent intermediary, forwarding HTTP/2 frames or streams directly without protocol conversion.

Process Flow:

1. Client initiates an HTTP/2 connection to the proxy.
2. Proxy establishes an HTTP/2 connection to the origin server.
3. Proxy forwards HTTP/2 frames/streams between client and origin.
4. The proxy manages stream IDs and potentially prioritizes streams.

Advantages:

• Full Feature Preservation: All HTTP/2 features, including server push from the origin, stream prioritization, and HPACK compression, are preserved end-to-end.
• Lower Latency: Eliminates the transcoding overhead, potentially leading to lower latency if the origin server is geographically close or highly optimized for HTTP/2.
• Reduced Proxy Overhead: The proxy's role is primarily frame forwarding and stream management, rather than full protocol conversion.

Disadvantages:

• Origin Server Requirement: Requires the origin server to fully support HTTP/2.
• Reduced Visibility/Control: Direct manipulation of HTTP headers or request bodies by the proxy becomes more complex due to HPACK compression and the binary nature of HTTP/2 frames. Deep packet inspection often requires full frame decoding and re-encoding.
• Security Implications: If the origin connection is also TLS, the proxy acts as a TLS termination point and re-establishes a new TLS connection to the origin, potentially impacting security posture or requiring certificate management.

Use Case: Best suited when both clients and origin servers support HTTP/2, and the goal is to maximize HTTP/2's performance benefits across the entire connection path, with minimal proxy-side interference beyond routing and load balancing.

Key Considerations for Proxy Services

Application-Layer Protocol Negotiation (ALPN)

HTTP/2 is typically negotiated over TLS using ALPN. When a client connects to a proxy, it sends an ALPN extension in the TLS ClientHello message, indicating support for h2 (HTTP/2 over TLS) and http/1.1. The proxy selects the preferred protocol.

Example (Conceptual ALPN handshake):

ClientHello (ALPN: [h2, http/1.1]) -> Proxy
Proxy selects h2
ServerHello (ALPN: h2) <- Proxy

Header Translation and HPACK

When transitioning between HTTP/2 and HTTP/1.1 (termination model), the proxy must decompress HPACK headers from HTTP/2 requests and re-encode HTTP/1.1 headers into HPACK for HTTP/2 responses. This involves managing the HPACK dynamic table, which is stateful.

Stream Management and Prioritization

HTTP/2 allows multiple concurrent streams over a single connection. A proxy must manage these streams, mapping them to backend connections (for HTTP/1.1 backends) or forwarding them while respecting priority hints. Incorrect stream management can negate HTTP/2's multiplexing benefits.

Server Push Handling

• Termination: If the proxy terminates HTTP/2, it cannot directly forward server push requests from the origin. The proxy can implement its own server push logic based on content analysis or configuration.
• End-to-End: In an end-to-end setup, server push frames from the origin are forwarded directly to the client.

Traffic Inspection and Modification

Inspecting or modifying HTTP/2 traffic is more challenging than HTTP/1.1.
* Encryption: HTTP/2 is almost universally used with TLS, requiring the proxy to terminate TLS for inspection.
* Header Compression: Modifying headers requires decoding, modifying, and re-encoding with HPACK, which can be stateful and complex.

Load Balancing

With HTTP/2, multiple requests from a single client might arrive over one connection. Load balancers must decide whether to route all streams from a single client connection to one backend server (session stickiness) or distribute individual streams across multiple backend servers. The latter requires more sophisticated stream-aware load balancing.

Configuration Examples (Nginx)

Nginx, a common reverse proxy, supports both HTTP/2 termination and end-to-end proxying.

HTTP/2 Termination (Frontend HTTP/2, Backend HTTP/1.1):

server {
    listen 443 ssl http2; # Enable HTTP/2 for client connections
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass http://backend_servers; # Backend is HTTP/1.1
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        # Nginx automatically converts HTTP/2 client requests to HTTP/1.1 for the backend
    }
}

upstream backend_servers {
    server 192.168.1.100:80;
    server 192.168.1.101:80;
}

HTTP/2 End-to-End (Frontend HTTP/2, Backend HTTP/2):

server {
    listen 443 ssl http2; # Enable HTTP/2 for client connections
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass https://backend_h2_servers; # Backend is HTTP/2
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on; # Pass SNI to backend
        proxy_http_version 2; # Instruct Nginx to use HTTP/2 for backend connection
    }
}

upstream backend_h2_servers {
    server 192.168.1.100:443;
    server 192.168.1.101:443;
}

Comparison: HTTP/2 Termination vs. End-to-End

Feature	HTTP/2 Termination (Frontend H2, Backend H1.1)	HTTP/2 End-to-End (Frontend H2, Backend H2)
Origin Server Support	HTTP/1.1 only required	HTTP/2 required
Protocol Conversion	Yes (H2 <-> H1.1)	No (H2 <-> H2)
Server Push	Proxy-generated only	Origin-generated can be passed through
Header Compression	Proxy handles HPACK encoding/decoding	Proxy forwards compressed headers
Performance	Good, but with transcoding overhead	Potentially better, lower proxy overhead
Proxy Control	High (easy modification/inspection)	Lower (more complex modification/inspection)
Complexity	Moderate	Moderate to High (backend H2 management)
Latency	Slightly higher due to transcoding	Potentially lower

Practical Implications

Implementing HTTP/2 in a proxy service directly impacts user experience and infrastructure efficiency. Users benefit from faster page loads and a more responsive web due to multiplexing and header compression. For the proxy infrastructure, supporting HTTP/2 requires careful resource management, especially concerning CPU utilization for TLS termination and HPACK processing. The choice between termination and end-to-end depends on the existing backend architecture, performance goals, and the need for proxy-level control over traffic. Security remains paramount, with TLS being a prerequisite for most HTTP/2 deployments, requiring robust certificate management and secure configuration.