In modern backend systems, being “fast” alone is no longer enough. How quickly your service responds to the first request, how little memory it consumes at startup, and how predictably it behaves are now just as important as raw throughput. Especially in serverless, short-lived container, edge worker, and bursty internal service scenarios, the real problem is often not steady-state throughput, but cold start performance, startup allocations, and operational simplicity.

Anka approaches this problem from the opposite direction of the traditional ASP.NET Core model: no middleware pipeline, no built-in routing, no TLS, no HTTP/2. Instead, it provides a Native AOT-friendly, HTTP/1.x-focused, allocation-conscious HTTP server core built on .NET 8+. The goal is straightforward: once the process starts, begin listening on the socket within milliseconds and keep the connection/request lifecycle as deterministic as possible.

The Problem

The traditional .NET web stack is extremely powerful, but that power comes with a cost. Middleware chains, reflection-heavy surfaces, dynamic extensibility, broad protocol support, and JIT warmup all introduce significant overhead on the cold-start path. If your actual requirement is simply:

“Open a socket, parse HTTP/1.1, execute a handler, and write the response,”

then the general-purpose framework model can become unnecessarily expensive.

The core question Anka focuses on is:

If we do not need a full-featured web framework, but only a fast-starting, low-memory, Native AOT-compatible HTTP listener, what should the minimum architecture look like?

The answer becomes visible in the performance characteristics as well. In measured environments, Anka reaches a time-to-ready of approximately 2.3 ms, startup allocations around 124.5 KB, and a steady-state RSS of roughly 15 MB. Kestrel, by comparison, offers a much broader feature set, but carries a heavier cold-start and memory profile. Interestingly, throughput differences are not dramatic; Anka’s real advantage is not raw requests-per-second, but startup cost and footprint.

Architecture: Minimal Layers, Maximum Control

Anka’s architecture is intentionally narrow:

Server.StartAsync()
-> parallel accept loops
-> Connection.RunAsync() (one task per TCP connection)
-> SocketReceiver.ReceiveAsync()
-> HttpParser
-> RequestHandler(request, response, ct)
-> HttpResponseWriter.WriteAsync()

The important aspect of this flow is that there is very little abstraction. Request processing starts directly at the socket layer and ends directly at the socket layer.

Server: The Acceptance Layer

The server opens the listening socket, configures the backlog, and runs multiple parallel accept loops instead of a single accept loop. This may sound like a small detail, but under burst traffic it prevents a single accept loop from serializing connection acceptance.

Additionally, the minimum thread pool size is increased to reduce thread injection latency during initial load. This may look like benchmark tuning, but in reality it is an operational decision intended to make cold-path behavior more deterministic.

Connection: The Real Unit of Execution

A Connection task is created for each TCP connection. This object:

• rents a pooled receive buffer,
• acquires a pooled HttpRequest,
• creates a connection-scoped HttpResponseWriter,
• reads and parses data from the socket,
• invokes the request handler,
• and if keep-alive is enabled, continues with the next request using the same resources.

The critical idea here is resource ownership at the connection level rather than the request level. This minimizes repetitive buffer rental and return operations across keep-alive requests.

SocketReceiver: Async I/O with Allocation Discipline

Instead of using the more convenient Socket.ReceiveAsync(Memory) APIs, Anka uses SocketAsyncEventArgs together with IValueTaskSource.

This is not micro-optimization for its own sake. The goal is to avoid state machine overhead and additional allocations when socket reads complete synchronously.

In loopback or LAN scenarios, data is often already available in the kernel buffer. In those cases, the receive operation completes synchronously and the system proceeds with almost direct function-call overhead. If data is not available, the OS I/O completion thread finishes the operation, while continuations are posted back to the thread pool using RunContinuationsAsynchronously = true.

The result: I/O threads are not blocked by request-processing work.

HttpParser: Single-Pass Parsing

The parser’s real value is not merely that it parses HTTP, but that it does so in a single pass using pooled buffers.

It performs:

• request line parsing,
• path/query separation,
• lowercase normalization of header names during ingestion,
• inline Content-Length tracking,
• request body reading when necessary,
• chunked request body decoding and reassembly into req.Body,
• keep-alive decision calculation during parsing.

This approach provides two important benefits:

1. No second header scan is required.
2. The HttpRequest passed to the handler is already in a usable, near zero-copy state.

HttpResponseWriter: Not a Framework, Just Wire Format

The response layer follows the same philosophy. HttpResponseWriter constructs the HTTP response header block inside a pooled buffer, inlines small bodies into the same buffer whenever possible, and writes directly through Socket.SendAsync().

Another important design choice here is the absence of chunked response encoding. All responses use Content-Length.

This constraint simplifies the response pipeline significantly and narrows the execution path for AOT and low-allocation goals.

Core Design Decisions

A Single RequestHandler Delegate

Anka has no middleware chain. There is only one RequestHandler.

This is a deliberate form of radical simplification.

Benefits

• shorter call chains,
• fewer abstraction layers,
• lower dispatch overhead,
• a cleaner surface for Native AOT.

Costs

• cross-cutting concerns must be implemented manually,
• routing, authentication, logging, and metrics are not framework-managed.

This is not an “incomplete framework”; it is a primitive-oriented design.

No Built-in Routing

Path dispatching is left entirely to user code. A simple switch statement is considered sufficient for many scenarios.

At first glance this may appear primitive, but routing costs are not limited to path matching itself. Routing systems also bring metadata graphs, endpoint conventions, and large API surfaces. Anka rejects that cost upfront.

Lowercasing Header Names During Ingestion

Instead of performing case-insensitive lookups repeatedly, header names are normalized during parsing. This allows lookups to use straightforward SequenceEqual comparisons.

It may seem like a small design detail, but on the hot path it reduces both branching and processing overhead.

Reusing HttpRequest and Buffers Across Connections

The HttpRequest.ResetForReuse() approach avoids discarding request objects after every request. The same object is reused throughout the connection lifetime.

This becomes especially effective under keep-alive workloads, because steady-state allocation reductions often come not from huge optimizations, but from many small, systematic reuse decisions.

Small CAS-Based Request Pool

The HttpRequestPool is lock-free and intentionally small.

The goal is not theoretical “infinite pooling,” but a practical, cache-friendly, low-overhead reuse mechanism. If all slots are occupied, objects are simply discarded.

This is another important engineering decision: trying to pool everything can sometimes become more expensive than not pooling at all.

Trade-offs: What This Architecture Gains — and Intentionally Gives Up

One of Anka’s strengths is that it clearly communicates what it is not.

The most important trade-off is this:

Anka does not exist to replace Kestrel. It exists to occupy a different optimization point.

If you need HTTP/2, TLS termination, middleware ecosystems, advanced hosting integrations, or rich observability plugins, then Kestrel is probably still the correct answer.

But if your priority is low footprint, rapid readiness, and a highly controlled request path, Anka becomes compelling.

The Strongest Part of This Design: Predictability, Not Performance

In my opinion, the real value here is not just “0 B allocations” or “2.3 ms startup.”

The real value is how easy it becomes to mentally model the system:

• one task per connection,
• connection-scoped buffers,
• parse → handle → write pipeline,
• very few failure states,
• limited protocol surface.

Architecturally, systems like this become valuable not because of benchmark presentations, but because of operational clarity. You know exactly what the system does, what it does not do, where behavior changes under load, and where costs are paid.

Example Use Cases

Serverless or Short-Lived Container APIs

If cold start is critical and the endpoint surface is small, Anka’s minimal startup overhead becomes a major advantage.

Sidecar / Internal Control Plane Endpoints

For health checks, readiness probes, metrics gateways, or simple control APIs, a full framework is often unnecessary.

Edge Compute and Appliance Deployments

Low RSS and Native AOT compatibility matter significantly in resource-constrained environments.

Benchmarking and Protocol Research

Anka provides a clean environment for teams that want to observe HTTP pipeline behavior without framework noise.

Narrowly Scoped, High-Control Services

It is well suited for single-purpose webhook receivers, internal callback endpoints, or lightweight ingestion services.

When I Would Not Use It

Personally, I would avoid this architecture for:

• large general-purpose product APIs developed by big teams,
• applications requiring rich middleware ecosystems,
• systems where streaming, TLS, or HTTP/2 are first-class requirements,
• organizations where framework integrations matter more than low-level control.

Because what you gain here is not “freedom.”

It is control.

And control always comes with increased engineering responsibility.

Conclusion

The most accurate technical summary of Anka is this:

It is not an HTTP server that gains performance by adding optimizations on top of features; it gains simplicity and predictability by deliberately reducing scope.

Native AOT compatibility, low startup allocations, connection-scoped resource management, single-pass parsing, and direct socket writing all serve the same goal:

a small, fast-starting, understandable request pipeline.

This approach is not for everyone — and it is not trying to be.

From an experienced backend engineering perspective, its most mature characteristic is precisely this: it defines the problem narrowly, optimizes aggressively for that problem, and consciously leaves everything else outside the boundary.

And often, that is a far more valuable engineering decision than building a system that tries to do everything.