Hi Pythonistas!
You use the web every day.
But have you ever thought about what actually happens when you type a URL and hit enter?
Not the browser rendering part.
The part before that.
How does your laptop talk to a server sitting in a data center thousands of kilometers away?
That's what this post is about.
The Basic Idea
Two things are always talking on the web.
A client. And a server.
Client = your browser. Server = the computer that has the data you want.
They need a common language.
That language is HTTP.
HyperText Transfer Protocol.
Protocol just means: an agreed set of rules for communication.
Like how a phone call has rules:
- one person talks
- the other listens
- then they switch
HTTP has rules too:
- client asks
- server responds
- done
Request and Response
Every HTTP interaction is a cycle.
Client → Request → Server
Client ← Response ← Server
You type parseltongue.co.in.
Your browser sends this:
GET / HTTP/1.1
Host: parseltongue.co.in
The server sends back:
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>Two parts to every request:
Method → what do you want to do?
Path → where do you want to do it?
Two parts to every response:
Status code → did it work?
Body → here's the data
HTTP Methods
The method tells the server what action you want.
GET → give me data
POST → create something new
PUT → replace something entirely
PATCH → update part of something
DELETE → remove something
Think of it like talking to a waiter:
GET → "show me the menu"
POST → "I want to order this"
PUT → "replace my entire order"
PATCH → "just change the drink"
DELETE → "cancel my order"
Status Codes
The server always replies with a 3-digit number.
It tells you what happened.
2xx → success
200 OK → worked perfectly
201 Created → new thing was created
204 No Content → worked, nothing to return
3xx → redirects
301 Moved Permanently → URL moved forever
302 Found → temporary redirect
4xx → your fault
400 Bad Request → you sent garbage
401 Unauthorized → you're not logged in
403 Forbidden → logged in but not allowed
404 Not Found → this doesn't exist
429 Too Many Requests → slow down
5xx → server's fault
500 Internal Server Error → server crashed
502 Bad Gateway → bad response from upstream
503 Service Unavailable → server is down or overloaded
Why does this matter in system design?
Your load balancer reads these codes.
Your monitoring alerts on these codes.
Your retry logic depends on these codes.
Not just browser stuff.
Headers
Every request and response carries headers.
Headers are metadata. Extra information about the message.
Request headers:
Host: parseltongue.co.in
Authorization: Bearer xyz123
Content-Type: application/json
Accept: application/json
Response headers:
Content-Type: text/html
Cache-Control: max-age=3600
Set-Cookie: session=abc123
Think of headers as the envelope around the letter.
The letter is the data.
The envelope tells everyone how to handle it.
HTTP Versions
HTTP has evolved over time.
HTTP/1.1
One request at a time per connection.
Want 10 resources? Wait in line.
Like a supermarket with one checkout counter.
HTTP/2
Multiple requests over one connection at the same time.
This is called multiplexing.
Same supermarket. Multiple counters open.
Much faster.
HTTP/3
Rebuilt from scratch using a new transport called QUIC.
Handles network drops better.
Faster on mobile.
Google, Cloudflare, most major services use HTTP/3 today.
The Big Problem with HTTP
Everything in HTTP is plain text.
Your request travels through:
your router
your ISP
multiple servers across the internet
Anyone in the middle can read it.
Passwords. Tokens. Private data. Everything.
This attack has a name:
Man-in-the-middle attack.
HTTP has no answer for this.
HTTPS does.
What is HTTPS?
HTTPS = HTTP + encryption.
The S stands for Secure.
Same request. Same response.
But wrapped inside an encrypted tunnel.
Anyone intercepting sees this:
x7Fg#@!kLm9$pQr2...
Useless.
That tunnel is created by TLS.
Transport Layer Security.
How TLS Works
Before any data flows, TLS does a handshake.
Both sides agree on a secret without ever sending it directly.
Here's the full flow:
Step 1 - Client Hello
Browser says:
"I want a secure connection.
Here are the encryption methods I support.
Here's a random number."
Step 2 Server Hello + Certificate
Server replies:
"Let's use this method.
Here's my random number.
Here's my certificate."
The certificate contains:
the server's domain name
the server's public key
a signature from a Certificate Authority
Step 3 - Browser Verifies the Certificate
Browser checks:
Is this signed by a CA I trust?
Does the domain match?
Is it expired?
Your browser ships with a list of trusted CAs built in.
Let's Encrypt. DigiCert. Comodo.
If checks pass → move on.
If not → you see that scary "Your connection is not private" warning.
Step 4 - Key Exchange
Now both sides need a shared secret to encrypt data.
But they can't just send it over the internet.
Anyone watching would see it.
So they use Diffie-Hellman Key Exchange.
The clever idea:
- Both sides exchange numbers publicly.
- Both compute the same final secret independently.
- Nobody watching can reverse-engineer that secret.
- It's mathematically proven to be practically impossible to crack.
- That secret becomes the Pre-Master Secret.
Step 5 - Session Key
Both sides now have:
Client Random (step 1)
Server Random (step 2)
Pre-Master Secret (step 4)
They feed all three into a function:
Session Key = f(Client Random + Server Random + Pre-Master Secret)
Both compute this independently.
Both get the same Session Key.
Step 6 - Encryption Starts
Browser: "Ready. Everything from here is encrypted."
Server: "Me too."
Done.
Why Three Inputs for the Session Key?
Why not just use the Pre-Master Secret directly?
Because if someone records your session today and steals the private key later
they could decrypt everything.
Adding unique randoms means:
every session produces a unique Session Key.
Stealing the private key later is useless for past sessions.
This property has a name:
Perfect Forward Secrecy.
What TLS Guarantees
Three things:
Encryption → nobody can read the data
Authentication → you're talking to the real server
Integrity → data wasn't tampered with in transit
Every message has a fingerprint called a MAC.
If anyone changes even one byte in transit:
fingerprint breaks.
connection drops.
immediately.
The Full Picture
Here's what happens when you visit https://parseltongue.co.in:
1. DNS resolves parseltongue.co.in → IP address
2. TCP connection opens on port 443
3. TLS handshake → encrypted tunnel created
4. Browser sends: GET / HTTP/2
5. Server processes the request
6. Server responds: 200 OK + HTML
7. Browser renders the page
8. Connection stays open for more requests
Eight steps.
Milliseconds.
That's the web.
Mental Model
HTTP → language client and server use to talk
HTTPS → same language, inside an encrypted tunnel
Method → what you want to do
Status code → what happened
Headers → metadata about the message
TLS → the handshake that builds the secure tunnel
Session Key → the shared secret that encrypts everything
Perfect Forward Secrecy → each session unique, past stays safe
What Changed for Me
Before this:
I thought HTTPS was just a green lock icon.
After this:
I realized it's a carefully engineered system
certificates, key exchanges, randoms, fingerprints
all working together in milliseconds
before a single byte of your data moves.
What's Coming Next
Now you know how client and server talk.
Next
how data actually travels between them.
TCP vs UDP reliability vs speed.
The two protocols that carry everything on the internet.