DEV Community

Cover image for A beginner-friendly mental model of HTTP, HTTPS and how the web communicates
Omaima Ameen
Omaima Ameen

Posted on

A beginner-friendly mental model of HTTP, HTTPS and how the web communicates

HieešŸ„‚!!
Lately I’ve been diving deep into web internals and honestly the deeper I go, the crazier it feels.

So I thought of documenting whatever I’m learning and understanding along the way , not as an expert, but as a curious developer trying to connect the dots.
This is one of those notes.

I know there’s already a lot of content on HTTP and web architecture out there, but I still wanted to write this because writing things in my own words helps me understand them better

Will probably keep writing more about web internals, React internals and low-level web stuff as I learn :)

(Note that Networking goes wayyy deeper than this ,this is just me trying to understand and explain the core ideas in simple human language while learning)

So here we goo,

Every time we open a website, click a button or log into an app, there’s a silent conversation happening between the client and the server.

HTTP is basically the medium that makes this conversation possible.

Its through which client and server talks to each other as a means of request , as the name suggests already that request means asking something from someone , and response again as the name suggests its giving an answer to someone’s call (in this case the request’s call)

So a request is basically asking something from the server , and the response is what the server gives us (client) in the form of whatever we intend to see on the internet.

I hope you get the idea right..don't you?

Now what exactly is HTTP?

It’s a protocol , basically a defined set of rules for how requests and responses should happen between the client and the server.
And a request message usually looks something like this:

Request Line
Headers
Optional Message Body

alright?

Now obviously every request to the server cannot mean the same thing :}

Sometimes you want to fetch data.
Sometimes you want to create something.
Sometimes, update it.
Sometimes delete it.
So for that, HTTP provides different methods to tell the server what action the client actually wants to perform.

Some common HTTP methods are:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
  • HEAD
  • OPTIONS
  • TRACE
  • CONNECT

For me, the most fascinating (and honestly crazy) thing was knowing that HTTP is a stateless protocol.

Meaning?

You send a request.
The server processes it.
Give a response.
And then suddenly…

ā€œWho are you again?ā€

So in this case, you’d basically have to log in on every single page again and again because somehow the server has to remember the context of YOU, right? 😭

Like imagine opening Amazon.com, logging in, doing your shopping, ordering earpods, paying for them and everything is done,

then 2 hours later or maybe the next day , you open the app again and the website suddenly goes:

ā€œWho are you babe?ā€ šŸ’€

Wouldn’t that be complete chaos?

There had to be something which could tell the server:
ā€œ this is the same person, don’t you dare forget them ā€

And that ā€œnoble jobā€ is basically being done by Cookies and Session Storage.

Cookies: a small piece of text stored in the user’s device by the browser , which consists of name-value pairs containing bits of information about the user, so the web experience doesn’t reset every five seconds.

But remembering the user wasn’t the only challenge with HTTP
There was another problem too, speed and connection efficiency.

Pipelining, Multiplexing and the emergence of HTTPS

HTTP/1.0 was pretty straightforward:

One request.
One response.
Connection closed.

and then again,
new request = new connection setup every single time!!

which was obviously kinda slow and tiring.

So HTTP/1.1 introduced something called Pipelining.
Meaning?
The client could send multiple requests together without waiting for the previous response to arrive first.
Sounds cool, right?

but there was still a problem.

The server still had to return responses in order:
response 1 -> response 2 -> response 3 ...
So if request 1 became slow for some reason, the further requests had to wait too.

This problem was called HOL Blocking (Head Of Line Blocking).
and that’s where Multiplexing entered the chat !!

Multiplexing basically means sending and receiving multiple requests and responses simultaneously over the same connection.

Then came HTTP/2 which introduced proper multiplexing over a single connection along with header compression.

And later HTTP/3 came into the picture, running over UDP with faster connection setup and better performance during packet loss.

Then comes HTTPS (Secure HTTP).

Now obviously sending sensitive stuff like passwords, payment details and tokens in plain text over the internet would be a terrible ideašŸ’€

So HTTPS adds encryption to the communication between the client and the server.
Meaning?
Even if someone somehow intercepts the data in between, they still won’t be able to understand it.

Think of it like this

HTTP:
Client -> ā€œmy password is 12345ā€ -> Network
HTTPS:
Client -> encrypted unreadable gibberish -> Network
Server -> decrypts -> ā€œmy password is 12345ā€

and behind the scenes, things like TLS and digital certificates help establish this secure communication channel.

That’s basically the core idea behind HTTPS.

the deeper I go into web internals, the crazier the internet starts feeling,

Like imagine billions of devices continuously talking to servers through requests, responses, protocols, encryption, cookies, packets and what not !!!

and somehow all of this works so smoothly that we casually open Instagram while eating chips :)

Just curious hat was the first web/internet concept that completely blew your mind?

(If I misunderstood something anywhere, I’d genuinely love corrections or deeper insights from y’allšŸ™Œ)

Top comments (0)