Beeper moves HTTP parsing into the kernel with eBPF and speeds up web servers up to 4.5x
Presented at Linux Plumbers Conference 2026, the Beeper project implements an HTTP parser in in-kernel eBPF with a built-in cache, and its hyper-fast-path claims up to 4.5x throughput. It is a signal for teams serving high-rate HTTP traffic: application-layer protocol parsing is moving down into the kernel.
October 27, 2026. Phoronix publishes a write-up of Beeper, a project born out of university research that performs application-layer protocol parsing directly in the kernel using eBPF. Earlier in October 2026. The work was presented at Linux Plumbers Conference 2026, whose videos have just been posted. October 27, 2026, again. The hyper-fast-path component, a fast path built on the Rust HTTP library Hyper, claims up to 4.5x maximum throughput. The point that matters: what was once the exclusive territory of nginx or Envoy — parsing HTTP in userspace — is migrating into the kernel, with gains that call the architecture of our web frontends into question.
What Beeper actually does: parsing HTTP inside the kernel
A classic web server always follows the same path. A packet arrives, traverses the kernel network stack, then rises to a userspace process — nginx, Apache, Envoy — that reads the bytes, parses the HTTP request, and decides what to do with it. Every round trip between the kernel and userspace has a cost, and that is the cost Beeper wants to eliminate.
Beeper implements an HTTP parser in eBPF, executed inside the kernel, and adds an in-kernel HTTP cache. In other words, part of the HTTP termination work — recognizing the request, caching it, serving it — happens before the packet ever leaves kernel space. The claimed gains are on the order of 3x throughput at high rates, with peaks measured at 3.4x.
The most striking demonstration comes from the companion project, hyper-fast-path. It is a fast path built on Hyper, the HTTP library written in Rust, and accelerated by eBPF: it reaches up to 4.5x maximum throughput in use cases where the request can be handled without touching userspace.
Academic research to watch, not yet a product
Keep your feet on the ground. Beeper comes out of academic research by researchers from ETH Zurich, NYU, and NVIDIA, and was presented at Linux Plumbers Conference 2026. The code, written in Rust, is available on GitHub — but it is a research proof of concept, not a production server you deploy on Monday.
The envisioned use cases do point the way: application-layer traffic monitoring, caching, and redirections based on payload content. Those are exactly the tasks a proxy or a WAF performs in userspace today, at higher latency and higher CPU cost.
The real subject: the risk-reward of moving into the kernel
The question is not “is it faster?” — the numbers say yes. The question is “at what cost?”. Moving protocol parsing into the kernel changes the security and maintainability calculus entirely.
On one side, eBPF is today the most controlled part of the kernel: a static verifier rejects any program that could loop forever, access invalid memory, or bypass permissions. An HTTP parser in eBPF is therefore not an arbitrary kernel module — it is verified before loading, like any other network eBPF program.
On the other side, an HTTP parser is notoriously hard code: request-parsing flaws (the kind that fueled CVEs in nginx or HAProxy) become, in this model, flaws inside the kernel. The attack surface does not disappear — it changes floors. It is the same trade-off that surrounded XDP, io_uring, and kTLS: you accept moving closer to the kernel what you gain in throughput, provided you do it with strict verification discipline.
A solid precedent: the kernel has already absorbed performance layers
Beeper does not start from scratch — it fits a trajectory where the Linux kernel has already reclaimed, piece by piece, functions long reserved for userspace. XDP moved packet filtering closest to the network card, and powers load balancers like Katran at Meta or the Cilium datapath. kTLS moved TLS termination into the kernel to offload reverse proxies that encrypt at scale. io_uring reinvented asynchronous I/O by eliminating syscall round trips.
What is new with Beeper is targeting layer 7 — the very content of the HTTP request — where its predecessors stayed at the transport or session layer. It is one more step in the logic of inverted kernel bypass: rather than avoiding the kernel with DPDK or AF_XDP in userspace, you push intelligence back down into the kernel, under the protection of the eBPF verifier. Both schools chase the same goal — reducing the cost per request — by opposite paths, and Beeper has just handed the second school its most compelling numbers.
What this changes for infrastructure teams
For now, there is nothing to deploy urgently. But three consequences are taking shape for teams that operate web frontends.
Throughput gains will no longer come only from userspace tuning. If HTTP parsing takes root in the kernel, part of the optimization that separates a nginx at 100,000 requests per second from another at 300,000 will play out below userspace, in eBPF programs you will need to know how to audit.
The language matters. The choice of Rust for the parser is not trivial: it points in the same direction as the Linux kernel itself, which is welcoming more and more Rust. An in-kernel HTTP parser written in Rust avoids entire classes of memory bugs that long plagued C parsing.
The boundary of the “proxy” is shifting. The features of a reverse proxy — caching, redirection, content filtering — are the first candidates for this migration. Teams designing their capacity plans should track this work, even if they adopt nothing.
Verdict
If you serve very high-rate HTTP traffic and already follow eBPF, Beeper and hyper-fast-path belong on your watchlist: they are the most convincing numbers yet for in-kernel application-layer parsing. If you run a production web frontend, change nothing: nginx, Envoy, and their peers remain the right answer, and an in-kernel parser lacks the maturity and ecosystem to replace them. The lasting lesson is elsewhere: eBPF keeps eroding the boundary between kernel and userspace, and HTTP — the most-served protocol on Earth — is now in its sights. The day a verified HTTP parser runs in production inside the kernel, our web-frontend architecture will not just speed up: it will reorganize.