When people talk about web servers, the conversation usually stops after three names: Apache, Nginx, and maybe IIS. It sounds like the history of serving HTTP is a neat little triangle: open source, high-performance, and Microsoft.
The real story is messier and much more interesting.
Behind the household names is a long line of lesser-known daemons that quietly pushed the web forward: tiny servers that fit into embedded devices, high-performance commercial engines that powered benchmarks, experimental platforms that played with new protocols long before the rest of us cared.
This is their story too.
The first web server: CERN httpd
The first web server wasn’t Apache, and it definitely wasn’t Nginx. It was CERN httpd, written in 1990 by Tim Berners-Lee and colleagues at CERN. It ran on a NeXT workstation and served pages for the very first website, which mostly explained… what the World Wide Web was.
CERN httpd was a small background daemon that spoke the brand-new HTTP protocol and handed out hypertext documents on request. It wasn’t glamorous, but it did something revolutionary: it turned “a bunch of files on a workstation” into a shared information space anyone on the network could browse.
By the mid-90s CERN httpd had been passed to the W3C and eventually retired, but its basic architecture — a network daemon that speaks HTTP and maps URLs to content — is still the skeleton of almost every web server you use today.
NCSA HTTPd, CGI, and the birth of Apache
After CERN’s prototype, the next big step was NCSA HTTPd, developed at the National Center for Supercomputing Applications (NCSA) in the early 1990s.
NCSA HTTPd did two really important things:
- Made it easy to deploy a web server on Unix boxes
For a while, NCSA HTTPd was the reference implementation. If you were standing up an early website, odds were good you were doing it with NCSA’s daemon. - Introduced the Common Gateway Interface (CGI)
CGI made it possible to execute external programs in response to HTTP requests. You could generate content dynamically instead of serving only static HTML. That unlocked the idea of “web applications,” long before that phrase was trendy.
But NCSA HTTPd had a problem: when its lead developer, Rob McCool, left NCSA in 1994, progress slowed dramatically. A group of administrators running large websites started maintaining their own patch sets to fix bugs and add features. They called themselves the Apache Group — partly a pun on “a patchy server.”
In 1995, the group released the first version of the Apache HTTP Server, initially based on the NCSA HTTPd codebase. By April 1996, Apache had surpassed NCSA HTTPd to become the most widely used web server on the internet, a position it held for roughly two decades.
Apache is not exactly “lesser-known,” but it is the spiritual bridge between those early academic daemons and the industrial-strength web stacks we use now.
The “big iron” era: commercial servers and the forgotten speed demons
While Apache was taking over the open web, vendors were chasing performance and enterprise features with commercial products. One of the more interesting — and now mostly forgotten — entries was Zeus Web Server.
Zeus Web Server
Released in the mid-1990s by Cambridge-based Zeus Technology, Zeus was designed from the ground up for speed on Unix and Unix-like platforms. It became a favorite in SPECweb benchmark results and high-traffic hosting environments that could justify the licensing cost.
Zeus never achieved high market share (a few percent at best), but it punched far above its weight in influence:
- It demonstrated that event-driven, highly tuned HTTP engines could handle far more concurrent connections than the traditional “process per connection” model.
- It helped push the industry toward treating HTTP serving as a performance engineering discipline, not just a background utility.
Meanwhile, Netscape Enterprise Server (later iPlanet, Sun ONE, and other names) and Microsoft’s IIS were carving out their own corners of the ecosystem. But it’s servers like Zeus that quietly set expectations for what “high performance” looked like on Unix.
Small and scrappy: the minimalist Unix daemons
Not every workload needs an all-singing, all-dancing web server. A big part of the web’s history was shaped by daemons aimed at being small, predictable, and easy to embed.
thttpd: tiny/turbo/throttling HTTP server
If CERN httpd was the first, thttpd is one of its spiritual grandchildren: a tiny, single-threaded HTTP server focused on doing just enough to be useful and fast, and no more.
Written by Jef Poskanzer, thttpd aimed for:
- A small executable (around tens of kilobytes).
- Minimal memory usage.
- Enough features to serve static files, run CGI, and enforce rudimentary throttling.
It’s not designed to be your everything server — but if you want to serve static content on constrained hardware (a router, an appliance, a development board), thttpd is exactly the kind of tool you reach for.
lighttpd: solving the c10k problem
In the early 2000s, the “c10k problem” — how to handle 10,000 concurrent connections on a single machine — was a hot topic. Out of that discussion came lighttpd (“lighty”), first released in 2003 by Jan Kneschke.
lighttpd’s goals:
- Use an event-driven architecture to handle massive concurrency gracefully.
- Keep memory and CPU usage low.
- Be easy to bolt onto stacks where Apache would be overkill.
For a time, lighttpd was used by high-traffic sites like parts of YouTube, Wikimedia, and others for static content and front-end roles.
Even if you don’t deploy lighttpd today, its approach helped normalize the idea that web servers should be asynchronous by default, a lesson Nginx later capitalized on in a big way.
Friendly faces: Cherokee and the quest for simpler administration
While some projects chased raw performance, others tried to make web servers less… cranky.
Cherokee: a GUI for your daemon
Cherokee is an open-source, cross-platform web server that set out to be fast, but also pleasant to administer.
Its notable ideas:
- A graphical admin interface (
cherokee-admin) for configuration, instead of only hand-editing text files. - A modular approach aimed at balancing high performance with a relatively small footprint.
- Built-in facilities for load balancing and handling many concurrent connections, making it viable both for small systems and larger deployments.
Cherokee never reached mainstream adoption like Apache or Nginx, but if you’ve ever wished your web server had a friendly web UI and sane defaults, you’re feeling some of the same pain it was designed to solve.
Caddy: automatic HTTPS and configuration as a first-class feature
Fast-forward to 2015: Let’s Encrypt is just around the corner, and managing TLS certificates is still one of the more tedious parts of running a site.
Enter Caddy, a modern web server written in Go. From its first release in 2015, Caddy’s headline feature was automatic HTTPS — it could obtain and renew certificates for you with almost no manual configuration.
Caddy is interesting for a few reasons:
- It treats TLS automation as a core feature, not an add-on or external tool.
- Its configuration model is modular and API-driven, so Caddy can act as a framework for long-running services, not just HTTP.
- It’s built with modern use cases in mind: reverse proxying, microservices, dynamic config updates, etc.
Concepts that felt novel in Caddy — especially fully automated TLS — have since influenced how we expect other web servers and proxies to behave. By lowering the barrier to HTTPS, it helped nudge the web toward “encrypt everything by default.”
Pushing the protocol: H2O and new-generation HTTP servers
Another class of lesser-known servers exists because someone said, “What if we redesigned this specifically for the next protocol, not the current one?”
H2O: built for HTTP/2 and beyond
H2O is a high-performance web server written in C, designed around HTTP/2 and, more recently, HTTP/3 from the ground up.
Key ideas:
- Full support for HTTP/2 prioritization and server push.
- Support for HTTP/3 and modern features like 103 Early Hints, aimed at squeezing as much perceived performance as possible out of the protocol.
- A strong focus on being an efficient TLS terminator and edge server.
H2O has been used in performance-sensitive environments, including as part of Fastly’s HTTP/2 stack via its libh2o library.
You might never run H2O directly in production, but its experiments feed back into the broader ecosystem: better benchmarks, better understanding of how to tune HTTP/2 and HTTP/3, and pressure on mainstream servers to adopt those lessons.
Why these obscure servers still matter
If your day job is running hosting infrastructure or managing Linux servers, you might reasonably ask: OK, neat history lesson — but why should I care about thttpd, lighttpd, Cherokee, Caddy, or H2O when Apache and Nginx already do the job?
Because these “minor characters” in web server history have shaped the defaults you rely on today:
- Architecture patterns
Event-driven designs popularized by servers like lighttpd and commercial engines like Zeus helped normalize the idea that async I/O is the right default for high-concurrency HTTP. - Operational expectations
Projects like Cherokee and Caddy raised the bar for usability: web UIs, simpler configuration languages, and zero-touch TLS automation. Even if you never deploy them, they influence what admins expect from any new web stack. - Protocol innovation
Servers like H2O became testbeds for HTTP/2 and HTTP/3 features before they were widely supported elsewhere. That accelerated adoption across the ecosystem. - Specialized use cases
Minimalist daemons such as thttpd still show up in embedded devices, lab environments, and small internal tools, where “fits in a few hundred kilobytes and runs forever” is more important than “supports every module under the sun.”
In short, even if you only ever systemctl restart apache2 or tweak your nginx.conf, you’re standing on the shoulders of a whole ecosystem of experiments, dead-end ideas, and success stories.
Where to go from here
If this history piques your curiosity, an easy next step is to treat these servers as learning tools:
- Spin up a small VM or container and try out lighttpd or thttpd for static content.
- Experiment with Caddy as a drop-in TLS-terminating reverse proxy in front of an internal app.
- Benchmark H2O or Caddy against your usual stack for a small, controlled workload just to see how they behave.
You don’t have to replace Apache or Nginx to get value from these lesser-known packages. Just knowing they exist — and understanding the ideas they brought to the table — makes you better equipped to design and troubleshoot the next generation of web infrastructure.
