How Tengine Enables Scalable HTTP Long‑Connection Pushes in Backend Systems

Tengine Overview

Tengine is a reverse proxy server extensively deployed across the organization, ranging from single‑machine instances to cluster‑based unified access servers (Aserver). Its high performance, low latency, and high availability make it a solid foundation for various applications.

Current HTTP Long‑Connection Situation

Regardless of whether the client uses HTTP/2 or HTTP/1.1, Tengine maintains short connections with the application servers (unless keepalive is configured). Tengine keeps the client‑side long connection alive and uses load‑balancing algorithms to schedule short connections to the back‑end.

Existing HTTP Push Solutions

Polling

Clients periodically send requests to poll for data. This method is simple but has two major drawbacks: short‑interval polling generates unnecessary QPS proportional to the number of clients, while long‑interval polling cannot guarantee timely delivery.

Application‑Side Handling

In this model, Tengine only forwards requests; the application holds the long connection and generates responses as needed. This approach forces each application to manage the connection lifecycle, which is resource‑intensive for large‑scale terminal devices.

HTTP/2 Server Push

HTTP/2 server push sends multiple responses for a single request, which does not align with the continuous data stream required for long‑connection push scenarios. The RFC description is omitted for brevity.

HTTP/2 allows a server to pre-emptively send (or "push") responses

Tengine Single‑Machine Push

Open‑source Nginx modules provide single‑machine push capabilities. The push flow is similar to MQTT's PUB/SUB model using HTTP:

A initiates a request; Tengine holds it and generates a KeyA.

B, wishing to push data to A, includes KeyA (or a header) in a POST request to Tengine.

Tengine retrieves the connection associated with KeyA and forwards the data to A.

Drawbacks include B needing to be aware of A’s existence and, in clustered deployments, requiring centralized storage for routing information.

Solutions involve using Tengine’s auth_request feature or Lua’s ngx.location.capture to handle the association.

Tengine Implementation Options

1. Built‑in Centralized Storage

Tengine generates a key for each TCP connection and stores the key‑to‑IP mapping in a centralized store. Applications can push data to any Tengine node; the system routes the push to the correct node.

Flow:

Application pushes to a random Tengine node with the target key.

The receiving node looks up the key in the store (e.g., Tair) to find the responsible Tengine instance.

The request is forwarded to that instance.

The target instance delivers the data to the client connection.

Applications may use a VIP or SLB to balance requests across the Tengine cluster.

2. Streaming Transfer Support

Tengine can use multipart/form-data with clear boundaries, allowing multiple push messages over a single long‑lived connection.

3. Multi‑Protocol Support

Tengine handles both HTTP and HTTP/2, inheriting the same push capabilities across protocols.

4. High Performance

As a proxy server, Tengine’s forwarding performance is industry‑leading. Adding centralized storage gives it distributed routing without sacrificing speed.