Modern cloud-native and data centre applications are increasingly deployed using service meshes such as Istio and Linkerd. These architectures are designed to simplify application development by abstracting away the underlying networking layer, making complex microservices easier to deploy, monitor, and manage. Under the hood, these service meshes rely heavily on service proxies, often referred to as "sidecars," with Envoy being one of the most prominent examples. These proxies sit in the critical path of network traffic to enforce vital policies, such as load balancing and rate limiting, operating either at the transport layer—Layer 4 (L4)—or at the application layer—Layer 7 (L7).
However, while service proxies offer immense convenience and flexibility, they come with a severe performance penalty. Previous research has demonstrated that routing all traffic through these user-space proxies can increase request latency by up to 185%. In hyperscale data centre environments where microservices communicate constantly, this latency overhead can severely degrade overall application performance.
To mitigate these bottlenecks, state-of-the-art service meshes like Cilium and Calico have begun offloading transport-layer L4 policies directly into the Linux kernel using eBPF, bypassing traditional user-space processing paths. Despite these advancements, Layer 7 policies remain stubbornly bound to user-space processing.
Industry giants have highlighted the urgency of addressing this limitation. Data from Alibaba, for instance, indicates that up to 95% of their service mesh customers utilize L7 policies in their production deployments. Consequently, the vast majority of modern cloud deployments are left largely unoptimized for application-layer handling, forcing requests to endure significant latency overheads even for basic HTTP policies.
The core challenge in optimizing L7 policies lies in the complexity of application-layer protocols and the strict safety limitations imposed by the eBPF kernel subsystem. Protocols such as HTTP utilize self-describing structures that require intricate parsing logic and state management compared to protocols with implicit structures. Although recent kernel-level features like strparser or the Kernel Connection Multiplexor (KCM) have attempted to improve L7 support within the kernel, processing complex L7 protocols directly within eBPF remains highly impractical. This is primarily due to the way the eBPF verifier operates: it performs an exhaustive execution path traversal to guarantee system safety, a process that quickly becomes intractable for programs featuring complex control flows.
Yet, a compelling operational opportunity exists beneath this technical complexity. While many L7 protocols are notoriously complex to parse, the actual logic required to enforce the vast majority of L7 policies tends to be remarkably simple.
To quantify this hypothesis, researchers conducted a comprehensive empirical analysis examining L7 policies deployed across 2,417 open-source projects hosted on GitHub. By scrutinizing 4,699 distinct Envoy configurations, categorizing them by their core functionality, and manually inspecting each policy type to determine compatibility, the study revealed that the logic underpinning 89% of all deployed L7 policies can actually be implemented directly in eBPF without requiring any modifications to the underlying Linux kernel.
This critical observation forms the foundation of a split design architecture. In this model, the complex parsing and exceptional policy handling remain offloaded to a user-space fallback path, while the high-frequency, simple policy enforcement is shifted entirely to an eBPF-driven fast path.
The Case for an L7 Fast Path
Realizing this split design in practice presents significant engineering hurdles, particularly when navigating the stringent safety and complexity limits enforced by the eBPF verifier. Overcoming these barriers requires automatically mapping L7 policies into restricted eBPF templates. These templates must be expressive enough to handle required parsing logic and traffic actions while guaranteeing successful passage through the eBPF verification phase.
Addressing this challenge directly, researchers developed an eBPF-based fast path known as Beeline, detailed in their recent academic work titled "Enforcing Application-Layer Policies in eBPF." For the vast majority—89%—of L7 policies encountered in real-world environments, Beeline successfully eliminates the traditional service proxy from the critical network path.
By removing this user-space bottleneck, Beeline reduces the average request latency of realistic web applications by up to six times while simultaneously increasing overall throughput by a factor of three. Crucially, it achieves these performance gains entirely without requiring coordination or modification of the underlying service proxy, operating transparently to accelerate virtually any standard service proxy implementation.
Beeline relies on two foundational techniques to enforce L7 policies successfully within the rigid structural limitations of eBPF: data plane synthesis and optimized protocol parsing.
Data Plane Synthesis
Beeline generates custom code for eBPF-compatible policies by leveraging a small, carefully curated set of simple yet highly expressive eBPF templates. Each template includes predefined placeholders that Beeline automatically populates with specific parameters dictated by the target service policy.
For instance, if a service policy specifies that incoming requests directed to the /feed endpoint must be redirected, Beeline selects an appropriate routing template and seamlessly inserts the IP address of the intended forwarding destination. The resulting eBPF code is subsequently compiled and inserted directly into the data plane. Because each foundational template is engineered to consistently pass the eBPF verifier, the synthesized data plane inherits this compatibility, enabling high-performance packet handling with minimal overhead.
Protocol Parsing
To maintain efficiency and avoid triggering verifier complexity limits, Beeline purposefully extracts only the specific information required to process each individual request. Continuing the previous example, when enforcing a policy targeting the /feed endpoint, Beeline extracts strictly the HTTP path necessary to identify matching traffic.
To achieve this efficiently, Beeline constructs a Deterministic Finite Automaton during the startup phase running in user space. This approach drastically reduces the computational complexity of the runtime eBPF program. The eBPF data plane then utilizes this finite automaton to rapidly identify relevant data segments within the raw message buffer, executing message delineation swiftly and securely.
Where to Go From Here
The Beeline project is open source and currently provides native support for both HTTP/1.1 and HTTP/2 protocols. While initial deployments focus primarily on accelerating service meshes within data centre environments, the overarching architectural concepts hold broad applicability across a wide spectrum of network applications.
For example, network operators can leverage Beeline’s underlying parser infrastructure to collect application-layer telemetry directly from the kernel level, completely bypassing the need for modifications to the host applications themselves. For developers and researchers interested in experimenting with these capabilities, a streamlined and packaged version of the parsing stage, known as Beeper, is available for public testing.
Laurin is a PhD student in the Networked Systems Group at ETH Zurich, focusing primarily on the end-host network stack and its intricate interactions with the application layer.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Leave a Reply