The Web Servers' Battle for Supremacy

In each time period we find ourselves in some sort of battle. The battles are not always physical struggles against another person or group of people. Rather, they could be against principles, or in my case, software. As said by Paul in his letter to the Ephesians: "we wrestle not against flesh and blood, but against principalities, against powers, against the rulers of the darkness of this world, against spiritual wickedness in high places" (Eph. 6:12).

The battle I want to discuss today, is the battle of the web server.

Back in the 1990's and early 2000's there was one open source web server program that was dominant: Apache. Today, Apache is the name of a software foundation, and the web server rather be referred to as Apache http. But I sometimes call it "Apache httpd." This is a more explicit name for what it is and what it does. The acronym "httpd" stands for Hyper Text Transport Protocol Daemon. The "daemon" part is important, because this implies that the program runs as a server program and handles the incoming connections.

I suppose we could mention here that Microsoft always had their IIS server, but I mainly focus on open source. This is to help sanity, where users can avoid vendor-lockin.

But this dominance by Apache was 20 years ago! New players started to emerge, and there were some great options. In the Open Source world of today you will typically encounter the following web servers:

• Caddy
• Nginx
• Apache http

And in my world of things, I would also encounter:

• OpenBSD's httpd
• OpenBSD's relayd

And a developer might encounter more options, such as:

• Lighttpd
• Custom node.js server
• OpenResty

There is a lot of choices. But there is one main reason why I call this a "battle."

Our word "battle" may ultimately come from the Latin word battuere, which means "to beat, to strike" (etymonline). How can a web server beat or strike another web server? Well, outside of hacking, and causing malicious attacks, I think the effectiveness and usefulness of web servers can cause these soft-blows to each other.

There is basically one reason why I bring this up, and that is Caddy. The Caddy web server has been a disruptor in the web hosting world.

Caddy itself isn't too far functionally different than Nginx. And Nginx itself has some differences from Apache. But what separates Caddy is its ability and super-power to automatically retrieve, setup, and life-cycle manage SSL/TLS certificates for domain. For a number of years now there has been a push for all websites to offer a "secure" connection layer, and Caddy has fallen into that a near-perfect tool to solve the problem.

The Caddy server itself is quick and efficient. It handles most situations. Allows custom headers. Proxying. Load balancing. And it will get you an HTTPS connection in seconds.

For these reasons, I say that there is a battle. Each time you don't have to check on your HTTPS certificates, Caddy sends another damaging blow to all the other web server programs. Each time you deploy, and you don't have to specify or think about where the security certificates should live on the filesystem, or you don't have to remember where your specific operating system might store them, another punishing jab is received by the other vendors.

In a faceoff between the following, here is my predicated winners:

• Caddy vs. Nginx: Caddy. Nginx is a great reverse proxy, but all the https stuff must be configured or provided by certbot or some other 3rd party program. Also, Caddy provides a reverse proxy as well.
• Caddy vs Apache HTTP: Caddy. Apache is feeling dated at this point, and I haven't run into in the wild for quite some time.
• Caddy vs. OpenBSD httpd: Caddy. The httpd server has it's easy syntax, but Caddy's is even shorter. Plus, auto-https, win.
• Caddy vs. OpenBSD relayd: Caddy. Relayd and Caddy both provide a reverse proxy. But only Caddy has built in certificate management.

I usually don't like using software tools that are multi-use and begin doing more than they should. And for that reason, I think having all these other web servers is important. And having the ability to separate the tools for SSL/TLS certificates from the web server itself is important. But when deploying servers there is a clear winner.

I still enjoy using Nginx, and I appreciate the work that has gone into OpenBSD's httpd & relayd. But let's face it, Caddy is revolutionary. I think the auto-https is the way of the future.

Share