HTTP Confused Me for a Long Time...Here’s What Finally Helped!

For a long time, HTTP felt like background noise to me. Websites loaded, APIs responded, dashboards refreshed, and everything mostly worked. Whenever HTTP came up, I subconsciously filed it under “developer skills” and moved on. But the more I worked in cloud architecture, security, performance troubleshooting, and cost conversations, the more I realized I was making decisions that depended heavily on HTTP behavior without really understanding it.

So I finally slowed down and learned how to demystify this for myself (and now others - I've posted about REST APIs, how to call them, what makes up a REST call, how they're no longer only for developers, etc.). Ultimately my charter wasn't to become a protocol expert, but to understand why things behave the way they do. This post will hopefully be a helpful guide as you embark upon more and learn the cloudy ways of the world we're living in!

The idea behind this post is to highlight the brief history and explain where we collectively started, why we had to keep changing, and where we are today in the evolution of the world wide web. Hoping this post helps you absorb some of the denser content that exists out there to explain everything in full. If you're like me, you might find some of the granular components of that to be quite boring and complex (almost on purpose).

HTTP/0.9 (Early 1990s): When the Web Was Small and Simple

HTTP started around 1991, when the web was essentially an academic experiment. HTTP/0.9 could do one thing: request a document and receive it. There were no headers, no status codes, and no metadata of any kind. That simplicity made sense at the time because the web was tiny and slow, and expectations were low.

This version is long obsolete, but it matters because it explains why HTTP still feels simple at its core. That “just text over the wire” philosophy never went away.

If you want a very approachable explanation, this is a great starting point: https://http.dev/0.9

For a broader historical overview, MDN’s evolution guide is excellent: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Evolution_of_HTTP

HTTP/1.0 (Mid-1990s): Structure Arrives, Along With New Problems

By 1996, HTTP/1.0 was formally documented in RFC 1945. This is where HTTP started to look like something we recognize today. Headers were introduced, status codes appeared, and methods like POST became standardized. Clients and servers could finally communicate intent and outcome, not just content.

The downside was that every request opened a brand-new TCP connection and then closed it. That behavior was expensive even then, and it becomes painfully obvious in modern cloud environments. Connection churn increases latency, burns resources, and shows up as real money on your bill. Many legacy applications still carry this behavior with them, which is one reason they struggle when lifted into the cloud.

If you want to go straight to the source, RFC 1945 is here: https://datatracker.ietf.org/doc/rfc1945/

A lighter summary with historical context is here:

https://www.geeksforgeeks.org/http-full-form/

HTTP/1.1 (Late 1990s to Today): The Quiet Workhorse

HTTP/1.1 was introduced in 1997 and, in many ways, it is still the backbone of the internet. The most important change was persistent connections, which allowed multiple requests to reuse the same TCP connection. That single improvement made the web dramatically more efficient.

HTTP/1.1 also expanded HTTP methods, improved caching behavior, and made status codes far more meaningful. If you have ever configured a load balancer, set up health probes, relied on retries, or debugged a stubborn 500 error, you have been relying on HTTP/1.1 whether you realized it or not.

This version is still very active today, especially in enterprise environments. Understanding it helps explain why certain performance ceilings exist and why some optimizations only go so far.

MDN’s overview is a solid refresher:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Evolution_of_HTTP

Cloudflare’s comparison does a nice job explaining its limits compared to newer versions:

https://www.cloudflare.com/learning/performance/http2-vs-http1.1/

HTTP/2 (2015 to Today): Same Semantics, Better Performance

HTTP/2 became a standard in 2015, and what makes it interesting is that it did not change how applications behave on the surface. URLs stayed the same. Methods stayed the same. Status codes stayed the same. What changed was how data moved underneath.

HTTP/2 multiplexes multiple streams over a single TCP connection and compresses headers to reduce overhead. The result is better performance, especially on high latency networks, without requiring application rewrites. That is why HTTP/2 quietly delivers wins across performance, efficiency, and cost.

This is where HTTP clearly stops being “just a developer thing.” Faster responses, fewer connections, and better throughput directly affect infrastructure sizing and cloud spend.

A good practical explanation is here:

https://ably.com/topic/http2

Cloudflare’s overview is also helpful: https://www.cloudflare.com/learning/performance/what-is-http2/

HTTP/3 and QUIC (2020s): Built for How We Actually Use the Internet Now

HTTP/3 is the newest chapter, with standardization finalized around 2022. Unlike previous versions, HTTP/3 does not run on TCP at all. It runs on QUIC, which is built on UDP and was designed for modern realities like mobile networks, Wi-Fi roaming, and intermittent connectivity.

QUIC eliminates head-of-line blocking, speeds up connection establishment, and encrypts traffic by default. For users, this often just feels like “things load faster,” especially on mobile. For architects and platform teams, it changes assumptions about performance, reliability, and security at the transport layer.

Most modern browsers and CDNs already support HTTP/3, sometimes without users realizing it. If you want to go deeper, the RFC is here:

https://datatracker.ietf.org/doc/html/rfc9114

Cloudflare has a very approachable explanation as well: https://www.cloudflare.com/learning/performance/what-is-http3/

A Simple Way to See It All at Once

HTTP Version	Approx. Start	Still Active	What Changed
HTTP/0.9	~1991	No	Single GET request, no headers
HTTP/1.0	1996	Rare	Headers, status codes, methods
HTTP/1.1	1997	Yes	Persistent connections, better semantics
HTTP/2	2015	Yes	Multiplexing, header compression
HTTP/3	~2022	Growing	QUIC over UDP, modern network behavior

Why This Finally Clicked for Me

I stopped thinking about HTTP as a protocol I needed to master and started thinking about it as a set of tradeoffs that explain why systems behave the way they do. Performance, reliability, security, and cost are all shaped by these decisions, whether we acknowledge them or not.

You do not need to be a developer to care about HTTP. If you work in cloud, security, FinOps, or platform engineering, you are already living with its consequences. Understanding the basics just makes those consequences less surprising.