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)