fasthttp

fasthttp is a ground-up reimplementation of the HTTP/1.1 protocol for Go, built explicitly to outperform the standard library’s net/http package. Where net/http allocates a fresh Request and Response object per connection and parses headers into a map[string][]string, fasthttp reuses RequestCtx objects across requests via sync.Pool-backed object pooling, avoiding the allocation pressure that dominates net/http’s hot path. The project’s own benchmarks show it handling requests up to 10x faster with zero allocations per operation in common cases.

Both a server and a client ship in the same module. The server exposes a single-argument RequestHandler(ctx *RequestCtx) function signature instead of net/http’s Handler interface, giving callers direct access to header parsing, streaming body writers, TLS, and connection hijacking through one context object. The client mirrors this design with pooled Request/Response objects, connection reuse, load-balancing (LBClient), and a reverse-proxy dialer. Because the API intentionally diverges from net/http, fasthttp trades drop-in compatibility for raw throughput — it underpins higher-level frameworks such as Fiber and routers like fasthttp/router rather than being a direct net/http replacement.

What You Get

• A pooled-object HTTP/1.1 server (fasthttp.Server) that reuses RequestCtx, connection buffers, and readers/writers via sync.Pool to avoid per-request allocations
• A companion HTTP client (fasthttp.Client) with connection pooling, timeouts, and a load-balancing LBClient for calling multiple backends
• Built-in support for TLS, connection hijacking, request/response streaming, and static file serving (fs.go) with byte-range and compression support
• Helper subpackages: fasthttpadaptor (net/http handler bridging), fasthttpproxy (SOCKS5/HTTP proxy dialers), fasthttputil (in-memory listener for testing), pprofhandler, prefork, and reuseport
• Native gzip, brotli, and zstd response compression built in via bundled dependencies (andybalholm/brotli, klauspost/compress)

Common Use Cases

• High-throughput API gateways and reverse proxies that need to sustain tens of thousands of requests per second per node
• Backend services for frameworks like Fiber, Atreugo, and Gearbox that build routing and middleware on top of fasthttp’s primitives
• Static file servers and CDN edge nodes using fasthttp’s built-in fs.FS handler with caching and byte-range support
• Load testing and benchmarking tools or proxies where allocation overhead directly limits throughput
• WebSocket servers built via RequestCtx.Hijack combined with fasthttp/websocket or dgrr/websocket

Under The Hood

Architecture fasthttp is organized as a flat single-package library (root package fasthttp) with no internal layering — server.go, client.go, header.go, args.go, uri.go, cookie.go, and fs.go each implement one HTTP concern as sibling files sharing the package namespace, and cross-cutting object reuse is centralized through package-level sync.Pool instances (serverPool, ctxPool, readerPool, writerPool, hijackConnPool on Server, and equivalent pools in client.go) rather than through interfaces or dependency injection. The core data flow revolves around RequestCtx, which each incoming connection acquires from ctxPool, populates via header/body parsing (header.go, headerscanner.go), and releases back to the pool once the RequestHandler returns — so the object graph a handler sees is entirely mutable, reused state rather than freshly allocated values, a constraint documented explicitly in doc.go and the README (values must not be retained past the handler’s lifetime). Supporting transport concerns live as separate subpackages under the same module (fasthttpadaptor for net/http bridging, fasthttputil for in-memory listeners, prefork/reuseport for multi-process listening, tcplisten for OS-level socket tuning) rather than being folded into the core package, keeping the hot path free of optional features. Changing the RequestCtx pooling model would ripple through nearly every file in the root package, since header parsing, streaming, cookie handling, and the client’s response reuse all assume the same acquire/reset/release lifecycle.

Tech Stack fasthttp targets Go 1.25 (go.mod) and depends on a small, deliberately chosen set of packages: andybalholm/brotli v1.2.2 and klauspost/compress v1.19.2 for brotli/gzip/zstd compression, valyala/bytebufferpool v1.0.0 (from the same author) for pooled byte-buffer reuse, and golang.org/x/{crypto,net,sys,text} for TLS and platform primitives — no web framework, ORM, or database driver dependencies, since fasthttp itself is the low-level layer other frameworks build on. Build tooling is plain go build/go test with no code generation beyond bytesconv_table_gen.go (a generated lookup table checked into the repo), and CI (.github/workflows/test.yml, lint.yml, security.yml, cifuzz.yml) runs the standard toolchain plus golangci-lint and continuous fuzzing via OSS-Fuzz rather than a custom build pipeline. Deployment is simply go get into a consuming binary; the reuseport, prefork, and tcplisten subpackages provide optional OS-level socket tuning (SO_REUSEPORT, preforked worker processes) for production topologies rather than the core package itself being deployment-target-specific.

Code Quality The root package ships 53 _test.go files against 42 non-test source files, using the standard library testing package with explicit t.Fatalf/t.Errorf assertions rather than a third-party assertion library, plus race-build-tag files (race_enabled_test.go/race_disabled_test.go) that let tests behave differently under go test -race. Error handling is explicit and typed throughout — functions return error values that call sites check rather than panicking, consistent with idiomatic Go. Linting is enforced via a .golangci.yml that sets default: all linters and then curates a specific disable list, which is considerably stricter than most projects’ lint configs, and CI runs separate lint, test, security-scan, and continuous-fuzzing (cifuzz.yml, via OSS-Fuzz) workflows. Comment density is moderate — 17-21% of lines in the largest core files (server.go, header.go, client.go) are comments, mostly doc comments on exported identifiers rather than inline explanation.

API Design fasthttp trades net/http’s familiar Handler interface for a single RequestHandler(ctx *RequestCtx) signature — a deliberate ergonomic choice that concentrates request/response state into one object so handlers get path, headers, query args, and streaming body writers without separate imports or type assertions, at the cost of being incompatible with the net/http middleware ecosystem (the project ships fasthttpadaptor specifically to bridge that gap). Most work happens through RequestCtx methods (ctx.Path(), ctx.PostBody(), ctx.SetBodyStreamWriter()) rather than composable middleware, so a working server is a five-line example, but routing itself is deliberately left to companion projects like fasthttp/router. The README’s own “fasthttp might not be for you!” section and extensive FAQ set realistic expectations up front about API instability and the manual work required to port net/http-based code, which is unusually candid API-design communication for a project this widely depended on.