hyper

hyper is the foundational HTTP implementation for the Rust ecosystem, providing both client and server building blocks over HTTP/1.1 and HTTP/2. It is deliberately low-level — it doesn’t ship a router, middleware system, or TLS implementation of its own — so that higher-level frameworks (Axum, warp, reqwest’s transport layer) and infrastructure tools can build exactly the stack they need on top of it without inheriting unwanted defaults.

Built on Tokio for async I/O, hyper exposes separate client and server modules alongside a Service trait (shared with the broader tower ecosystem) as its core abstraction for handling requests. Its combination of correctness, low overhead, and permissive MIT license has made it the de facto transport layer underneath a large share of production async Rust web services and HTTP clients.

What You Get

• A low-level async HTTP/1.1 and HTTP/2 client for making outbound requests
• A low-level async HTTP/1.1 and HTTP/2 server for accepting inbound connections
• The Service trait — a shared request-handling abstraction compatible with the tower middleware ecosystem
• Streaming request/response bodies via the http-body crate rather than buffering everything in memory
• Optional C API bindings (capi/) for embedding hyper in non-Rust applications

Common Use Cases

• Building a custom async web server or proxy that needs direct control over connection handling
• Serving as the transport layer underneath a higher-level framework (many Rust web frameworks build on hyper directly)
• Implementing an outbound HTTP client for a service that needs fine-grained control over connection pooling and timeouts
• Embedding HTTP client/server capability in latency-sensitive infrastructure (proxies, gateways, load balancers)

Under The Hood

Architecture The crate splits cleanly into src/client and src/server modules, each built atop a shared src/proto layer implementing the HTTP/1 and HTTP/2 wire protocols, with src/body handling streaming request/response bodies and src/service defining the Service trait both client and server code paths use to dispatch work — roughly 22,000 lines of Rust across the crate. An optional capi/ directory provides a C-callable API so non-Rust applications can embed hyper directly. Tech Stack Async I/O runs entirely on Tokio; HTTP/2 framing is delegated to the separate h2 crate, request/response types come from the http crate, and body streaming uses http-body/http-body-util — all as optional dependencies gated by Cargo feature flags so consumers only pay for the protocol versions and roles (client/server) they enable. Code Quality The tests/ directory includes dedicated client.rs, server.rs, h1_server/, and integration.rs suites, plus a h1_shutdown_while_buffered.rs test targeting a specific connection-lifecycle edge case — evidence of regression tests written directly against past bug classes rather than only happy-path coverage. API Design The Service trait is the single abstraction both client and server code build on, and it’s shared with the wider tower ecosystem, so middleware (timeouts, retries, logging) written against tower::Service works with hyper directly — a deliberate design choice that trades a slightly steeper initial learning curve for strong ecosystem composability.