Modern data centre applications are increasingly deployed using service meshes—such as Istio or Linkerd—to simplify application development by abstracting away the complex networking layer. By handling these foundational routing and security layers externally, service meshes make applications significantly easier to deploy and manage across large-scale distributed architectures.
Under the hood, however, these service meshes rely heavily upon service proxies, often referred to as "sidecars," such as Envoy. These proxies are tasked with enforcing critical runtime policies, including load balancing and rate limiting, operating at both the transport layer (Layer 4, or L4) and the application layer (Layer 7, or L7).
While undeniably convenient for developers and operators, these traditional service proxies tend to introduce severe performance overheads, significantly slowing down service meshes. Previous industry studies have demonstrated that routing traffic through these user-space sidecar proxies can increase request latency by up to 185%.
To mitigate this heavy performance penalty, state-of-the-art service meshes like Cilium or Calico have successfully shifted lower-level responsibilities, offloading L4 policies directly into the operating system kernel using extended Berkeley Packet Filter (eBPF) technology. Despite these advancements, Layer 7 policies continue to be enforced entirely within user space, leaving a major performance bottleneck unaddressed in modern cloud-native infrastructures.
The Case for an L7 Fast Path
Unfortunately, Layer 7 policies constitute the vast majority of all policies utilized in modern data centre deployments. Highlighting the scale of this reliance, large-scale technology operations like Alibaba report that up to 95% of their customers actively utilize L7 policies within their production service meshes. Today, these massive deployments are left largely unoptimized, forcing massive amounts of application-layer traffic through performance-inhibiting user-space proxies.
State-of-the-art service meshes continue to process all L7 policies in user space simply because traditional methods are too complex to execute directly within eBPF. Despite recent technological advances aimed at improving L7 support within the Linux kernel—such as strparser or the Kernel Connection Multiplexor (KCM)—processing complex L7 protocols remains thoroughly impractical within the stringent technical limitations enforced by the eBPF subsystem.
This fundamental hurdle exists because of the rigorous way the kernel verifies the safety of any eBPF program before execution. The kernel performs an exhaustive execution path traversal that rapidly becomes computationally intractable for programs featuring complex control flows. This operational roadblock becomes a critical issue when attempting to process application-layer protocols like HTTP, which rely on self-describing structures, demanding considerably more intricate parsing logic and maintaining significantly more state than simpler protocols with implicit structures.
Yet, this operational challenge presents a clear systemic opportunity. While many L7 protocols are notoriously complex to parse, the core programmatic logic actually required to enforce typical L7 policies tends to be remarkably simple in practice. This insight was confirmed through an extensive empirical analysis examining the L7 policies deployed across 2,417 distinct open-source projects hosted on GitHub. Researchers meticulously analyzed 4,699 distinct Envoy configurations, categorized them according to their core functionality, and manually inspected each individual policy type to determine their compatibility with eBPF.
The findings revealed that the core logic underpinning a striking 89% of all deployed L7 policies can actually be implemented directly within eBPF without requiring any modifications to the underlying operating system kernel. This realization directly enables an innovative split design architectural model.
Realizing this split design approach, however, remains exceptionally challenging because it requires developers to skillfully navigate and overcome eBPF’s strict operating limitations. Researchers demonstrated how to successfully navigate these limitations by automatically mapping complex L7 policies into highly restricted eBPF templates. These specialized templates safely support the requisite parsing logic and necessary actions, while maintaining a strict mathematical guarantee that they will successfully pass the rigorous eBPF kernel verification process.
Despite being intentionally restricted by design, these templates remain expressive enough to capture the vast majority of L7 policies observed in real-world production environments.
In recent academic and industry work detailed in the research paper titled Enforcing Application-Layer Policies in eBPF, computer scientists addressed this persistent industry problem by introducing a novel eBPF-based fast path known as Beeline. Developed as an open-source project, Beeline can successfully eliminate the traditional service proxy from the critical traffic path for the vast majority—89%—of L7 policies found in the wild.
By bypassing the traditional user-space sidecar for these compatible policies, Beeline dramatically reduces the average request latency of realistic web applications by up to six times while simultaneously increasing overall system throughput by three times. Crucially, it achieves these dramatic performance gains without requiring any complex coordination or integration with the underlying service proxy itself. Because Beeline operates entirely transparently, it possesses the capability to accelerate virtually any existing service proxy deployed in the cloud.
Beeline achieves this by employing two core techniques designed to enforce complex L7 policies strictly within the technical boundaries of eBPF limitations.
Data Plane Synthesis
Beeline synthesizes execution code for eBPF-compatible policies utilizing a small, carefully curated set of simple yet highly expressive eBPF templates. Each individual template contains specific placeholders that Beeline automatically replaces with runtime, policy-specific parameters. For instance, if a service policy specifies that incoming traffic directed to the /feed endpoint should be redirected, Beeline automatically utilizes a predefined routing template and securely inserts the target IP address of the forwarding destination.
The resulting compiled code is then directly inserted into the data packet execution path before final compilation. Because each foundational template is engineered to pass the strict eBPF verifier, the resulting data plane inherits this compliance, successfully passing verification despite its advanced capabilities.
Protocol Parsing
To maintain high performance and avoid triggering verifier complexity limits, Beeline deliberately extracts only the precise information it strictly needs to process each individual incoming request. For example, to properly enforce a targeted routing or security policy, Beeline only needs to extract the specific HTTP path to successfully identify requests targeting a designated endpoint like /feed.
To accomplish this efficiently, Beeline constructs a Deterministic Finite Automaton during system startup operating entirely within user space. This architectural choice dramatically reduces the computational complexity of the runtime eBPF program itself. The high-performance eBPF data plane then utilizes this automaton directly to rapidly identify relevant data segments within the raw message buffer and perform precise message delineation without incurring heavy user-space round-trip penalties.
Where to Go From Here
Beeline is available as an open-source project and currently provides robust support for both HTTP/1.1 and HTTP/2 protocols. While this development focuses heavily on accelerating service mesh architectures, the high-level engineering principles and eBPF synthesis techniques can be readily applied across a broad spectrum of distributed applications.
For instance, network operators and systems engineers can leverage Beeline’s underlying parser technology to collect fine-grained application-layer telemetry directly from the operating system kernel, entirely eliminating the need for any intrusive modifications to the target applications themselves. Developers interested in experimenting with these parsing capabilities directly can reference Beeper, a streamlined and packaged iteration of Beeline’s core parsing stage.
Laurin is a PhD student within the Networked Systems Group located at ETH Zürich, where his primary research focus centers on the performance of the network stack on end hosts and its deep interaction with the application layer.
Leave a Reply