Think of TCP and UDP as ways to send data from one computer to another.

• TCP (Transmission Control Protocol)
  Careful, reliable, and ordered.

• UDP (User Datagram Protocol)
  Fast, lightweight, and “best effort”.

They both sit at the transport layer and decide how data moves — not what the data means.

2. Key Differences Between TCP and UDP

Simple idea:
TCP = safe but slower
UDP = fast but risky

3. When to Use TCP

Use TCP when data accuracy matters more than speed.

Examples:

• Web pages

• Login systems

• Payments

• File downloads

• Emails

If even one missing byte can break things — TCP is the right choice.

4. When to Use UDP

Use UDP when speed matters more than perfection.

Examples:

• Live video/audio

• Online gaming

• Video calls

• DNS lookups

• Live streaming

Here, losing a packet is better than waiting for it.

5. Real-World Analogy

• TCP → Courier service
  Delivers every package, in order, with confirmation.

• UDP → Live announcement
  If you miss a word, the speaker doesn’t repeat it.

TCP vs UDP Communication Flow

6. What is HTTP?

HTTP (HyperText Transfer Protocol) is not about sending data —
it’s about defining how browsers and servers talk.

HTTP answers questions like:

• What is a request?

• What is a response?

• What does GET or POST mean?

• How headers and status codes work

HTTP lives at the application layer.

7. Relationship Between TCP and HTTP

HTTP does not replace TCP.

Instead:

HTTP runs on top of TCP

Flow looks like this:

1. TCP establishes a reliable connection

2. HTTP sends requests over that connection

3. Server responds using HTTP

4. TCP ensures data arrives correctly

HTTP Request Flow Over TCP Connection

8. Common Beginner Confusion

“Is HTTP the same as TCP?”

No.

• TCP → How data is delivered

• HTTP → What the data means

They solve different problems.

9. Layering (Simplified)

Application Layer → HTTP
Transport Layer   → TCP / UDP
Internet Layer    → IP

Simplified TCP/IP Layer Mapping

10. Real-World Usage Mapping

Let’s understand the core ones, simply.

How the Internet Reaches Your Home or Office

At a very high level, the internet doesn’t magically appear in your laptop.
It travels through cables, devices, and rules.

Basic flow:

Internet → Modem → Router → Switch → Your Devices

1. What is a Modem?

A modem connects your local network to the internet.

• Internet signals coming from your ISP are not in a format your devices understand

• The modem converts those signals into usable digital data

• Without a modem, you simply cannot access the internet

Analogy:
Translator between your ISP and your home

Diagram: Internet → Modem → Router → Devices

2. What is a Router?

A router decides where data should go.

• It receives data from the modem

• Sends it to the correct device (laptop, phone, server)

• Uses IP addresses to make routing decisions

• Creates a local network (LAN)

Important:

• Modem = internet connection

• Router = traffic direction

Analogy:
Traffic police at a junction

Router directing traffic to multiple devices

3. Hub vs Switch (Local Network Devices)

Hub (Old & Dumb)

• Sends data to all devices

• No idea who actually needs it

• Causes collisions and slow networks

Switch (Smart & Modern)

• Sends data only to the intended device

• Learns MAC addresses

• Faster and more secure

Key difference:

Hub broadcasts, Switch delivers.

Analogy:

• Hub → shouting in a room

• Switch → delivering to the correct mailbox

Hub vs Switch packet broadcast comparison

4. What is a Firewall?

A firewall controls what is allowed in and out of a network.

• Blocks malicious traffic

• Allows trusted requests

• Can be hardware or software

• Rules are based on IP, port, protocol

Security lives here.

Analogy:
Security gate checking ID

Firewall placement between internet and internal network

5. What is a Load Balancer?

A load balancer distributes traffic across multiple servers.

• Prevents one server from getting overloaded

• Improves availability and performance

• Essential for scalable systems

Used heavily in:

• Production web apps

• Microservices

• Cloud infrastructure

Analogy:
Toll booth directing cars to multiple lanes

Load balancer distributing traffic to servers

6. How All These Devices Work Together (Real World)

For a typical web application:

User
 ↓
Internet
 ↓
Firewall
 ↓
Load Balancer
 ↓
Web Servers
 ↓
Database

At home or office:

Internet → Modem → Router → Switch → Devices

Each device does one job well — and together, they make the network reliable.

End-to-end network architecture for a web application

Why Software Engineers Should Care

Even if you write only code:

• APIs fail because of firewalls

• Servers crash without load balancing

• Latency issues often come from routing

• Production bugs are sometimes network bugs

Understanding hardware makes you a better backend and system engineer.

Let’s break it down step by step using the dig command.

1. What is DNS and why name resolution exists

Computers don’t understand domain names.
They only understand IP addresses like 142.250.190.14.

DNS (Domain Name System) exists to translate human-friendly names into machine-friendly IPs.

Think of DNS as the internet’s phonebook:

• Name → Phone number

• Domain → IP address

Without DNS, we’d have to remember IPs for every website.

2. What is the dig command and when it is used

dig stands for Domain Information Groper.

It is a command-line tool used to:

• Inspect DNS records

• Debug DNS issues

• Understand how name resolution works internally

Unlike browsers, dig shows raw DNS responses.

Example:

dig google.com

3. Understanding dig . NS (Root Name Servers)

Let’s start from the top of the DNS hierarchy.

dig . NS

This asks:

“Who controls the root of DNS?”

The response lists root name servers like:

a.root-servers.net
b.root-servers.net
...

These servers don’t know IPs of websites.
They only know where to find TLD servers.

Root servers are the starting point of every DNS lookup.

DNS hierarchy – Root level

4. Understanding dig com NS (TLD Name Servers)

Next layer: Top-Level Domain (TLD).

dig com NS

This asks:

“Who manages .com domains?”

The answer returns .com name servers (run by Verisign).

TLD servers:

• Don’t know IP addresses

• Know which authoritative servers manage a domain

Root → TLD (.com)

5. Understanding dig google.com NS (Authoritative Servers)

Now let’s ask about a specific domain.

dig google.com NS

This returns Google’s authoritative name servers like:

ns1.google.com
ns2.google.com

Authoritative servers:

• Hold the actual DNS records

• Are the final source of truth

This is where real answers live.

TLD → Authoritative servers

6. Understanding dig google.com (Full Resolution Flow)

Now the real question:

dig google.com

This returns:

• A record (IPv4 address)

• Sometimes AAAA (IPv6)

• TTL values

Behind the scenes, the resolver does this:

1. Ask root servers → where is .com?

2. Ask .com servers → where is google.com?

3. Ask Google’s authoritative servers → what is the IP?

Your browser never talks directly to root or TLD servers.
A recursive resolver (ISP / Google DNS / Cloudflare) does this for you.

Full DNS resolution flow for google.com

How recursive resolvers fit in

Recursive resolvers:

• Cache DNS results

• Reduce latency

• Protect root/TLD servers from overload

Popular resolvers:

• 8.8.8.8 (Google)

• 1.1.1.1 (Cloudflare)

They repeat the root → TLD → authoritative process only when needed.

Recursive resolver interaction

Connecting DNS to real browser requests

When DNS resolution finishes:

• Browser gets IP address

• TCP connection starts

• HTTPS handshake happens

• HTTP request is sent

DNS is step zero of every web request.

If DNS fails, nothing loads.

What is a Server?

A server is just another computer on the internet that:

• Receives requests

• Processes them

• Sends back a response

Your browser talks to servers all the time. cURL lets you talk to servers manually.

What is cURL?

cURL is a command-line tool used to send requests to a server and see the response.

Think of it as:

A browser, but without buttons—only commands.

You type a command → server responds → you see the result in the terminal.

Why Programmers Need cURL

Programmers use cURL to:

• Test APIs quickly

• Check server responses

• Debug backend issues

• Work without a browser or UI

• Automate requests

If you work with backend, APIs, or DevOps—cURL becomes a daily tool.

Your First cURL Request

The simplest possible command:

curl https://example.com

This command:

• Sends a request to the server

• Fetches the webpage

• Prints the response in your terminal

What Just Happened? (Request & Response)

When you ran the command:

1. cURL sent a request

2. The server processed it

3. The server sent back a response

The response usually contains:

• Status (was it successful or not?)

• Data (HTML, JSON, text, etc.)

Browser Request vs cURL Request

A browser:

• Sends requests automatically

• Renders HTML visually

• Hides technical details

cURL:

• Sends requests manually

• Shows raw data

• Gives full control

Both talk to the same server - just differently.

Browser request vs cURL request

Talking to APIs Using cURL

APIs are servers that usually return JSON instead of HTML.

Eg:

curl https://api.example.com/users

You’ll see raw data like:

[
  { "id": 1, "name": "John" }
]

This is how developers test APIs before connecting them to apps.

GET and POST (Only the Basics)

• GET → Fetch data

• POST → Send data

For now, just remember:

Most simple cURL commands you run are GET requests by default.

We’ll explore POST later—no rush.

Basic HTTP request & response structure

Common Mistakes Beginners Make

• Trying too many flags too early

• Copy-pasting complex commands without understanding

• Expecting cURL to behave like a browser

• Ignoring error messages

Start small. One command at a time.

Where cURL Fits in Backend Development

cURL is used:

• Before frontend exists

• While building APIs

• During debugging

• In CI/CD scripts

• On servers without browsers

If backend is the engine, cURL is the diagnostic tool.

Where cURL fits in backend development

When you type google.com in your browser, your computer doesn’t magically know where it is.
It needs an address — just like you need a house address to visit someone.

That’s where DNS comes in.

What is DNS? (Very simple)

DNS is the phonebook of the internet.

• You remember names like example.com

• Computers understand numbers like 142.250.190.14

DNS connects the name to the number.

What is DNS? (Very simple)

DNS is the phonebook of the internet.

• You remember names like example.com

• Computers understand numbers like 142.250.190.14

DNS connects the name to the number.

Why do we need DNS records?

A domain name needs different instructions:

• Where the website is hosted

• Who handles email

• Which service owns the domain

• Extra verification info

Each instruction is stored as a DNS record.

NS Record – Who is responsible for this domain?

NS (Name Server) records decide who controls the domain’s DNS.

They answer:

“Which DNS service should be trusted for this domain?”

ns1.hostinger.com
ns2.hostinger.com

If NS records point to Hostinger, Hostinger manages all other records.

A Record Domain - IPv4 address

A record connects a domain to a server IP (IPv4).

Eg:

example.com → 93.184.216.34

This is how browsers reach your website server.

AAAA Record – Domain → IPv6 address

Same as an A record, but for IPv6 (newer IP format).

Eg:

example.com → 2606:2800:220:1:248:1893:25c8:1946

Not mandatory, but good to have if your server supports IPv6.

CNAME Record – One name pointing to another name

CNAME is an alias.

Instead of pointing to an IP, it points to another domain.

Eg:

www.example.com → example.com

So you don’t manage multiple IPs.

A record → IP address
CNAME → another domain name

MX Record – How emails find your mail server

MX (Mail Exchange) records tell emails where to go.

When someone emails you@example.com, MX records guide the email to the correct mail server.

Eg:

example.com → mail.google.com

NS = who controls DNS
MX = who receives email

TXT Record - Extra information & verification

TXT records store plain text instructions.

Used for:

• Domain verification

• Email security (SPF, DKIM)

• Ownership proof

Example:

"v=spf1 include:_spf.google.com ~all"

You usually don’t “use” TXT records directly — services ask you to add them.

How all DNS records work together (one website example)

For a simple website:

• NS → DNS provider

• A / AAAA → Website server

• CNAME → www handling

• MX → Email service

• TXT → Verification & security

All records work silently in the background — fast and invisible.

This article explores why version control exists, using the pendrive analogy to explain the real problems developers faced before modern version control systems became mandatory.

Life Before Version Control

Imagine a small development team working on the same project.

There is no Git. No GitHub. No GitLab.

Instead, there is:

• A single pendrive

• Email attachments

• Shared folders on someone’s computer

The workflow usually looked like this:

1. Developer A writes code and saves it to a pendrive.

2. Developer A hands the pendrive to Developer B.

3. Developer B copies the files, makes changes, and saves them back.

4. Someone forgets to copy the latest version.

5. Chaos begins.

This approach worked only when projects were tiny and teams were small. As soon as complexity increased, problems became unavoidable.

The Pendrive Analogy in Software Development

Think of a pendrive as the single source of truth.

Whoever has the pendrive has the latest version of the code.

Sounds simple, right? But this simplicity hides serious flaws.

Example Scenario

• You update login.js on the pendrive.

• Your teammate updates dashboard.js on their local machine.

• Both changes are important.

• Only one version fits on the pendrive at a time.

Someone’s work will be lost.

To avoid this, developers started creating copies:

• project_final

• project_final_v2

• project_latest

• project_latest_final

Instead of solving the problem, this created confusion.

No one knew:

• Which version was correct

• Who changed what

• When the change was made

• Why the change was made

Problems Faced Before Version Control Systems

1. Overwriting Code

Two developers edited the same file. One copied their version last.

The other developer’s work vanished.

No warning. No recovery.

2. Losing Changes Forever

There was no history.

If something broke, you couldn’t:

• Go back to yesterday’s version

• Compare changes

• Undo a mistake

Once lost, the code was gone.

3. No Collaboration History

Questions like these had no answers:

• Who wrote this code?

• Why was this logic added?

• When did this bug appear?

Debugging became guesswork instead of investigation.

4. Fear of Making Changes

Developers were afraid to touch working code.

A simple update could break everything, and there was no safety net.

Innovation slowed down.

5. Impossible Team Scaling

Pendrive-based workflows collapse as soon as:

• The team grows

• Multiple features are developed in parallel

• Deadlines become tight

Collaboration simply does not scale.

Real-World Team Collaboration Problems

Now imagine this pendrive workflow in:

• A startup with 10 developers

• A company with remote teams

• An open-source project

It’s impossible.

Developers need to:

• Work in parallel

• Experiment without fear

• Track every change

• Merge work safely

The pendrive model cannot handle this reality.

Why Version Control Became Mandatory

Version control systems were created to solve exactly these problems.

They introduced:

• A complete history of changes

• Safe collaboration

• Conflict detection instead of silent overwrites

• The ability to roll back anytime

Instead of passing pendrives, developers now:

• Clone repositories

• Create branches

• Commit small, meaningful changes

• Merge work with confidence

Version control turned software development from a fragile process into a reliable system.

Pendrive Workflow vs Version Control Workflow

Pendrive Workflow:

• One copy at a time

• Manual sharing

• No history

• High risk of data loss

Version Control Workflow:

• Everyone has a full copy

• Automatic tracking

• Complete history

• Designed for collaboration

What once required discipline, memory, and luck is now handled by tools.

Why This Still Matters Today

If you’ve ever:

• Used Git

• Fixed a bug by checking commit history

• Reverted a broken deployment

You’ve benefited from lessons learned during the pendrive era.

Version control doesn’t just store code.

It stores context, history, and collaboration.

And that’s why version control exists.

Git works internally by storing project snapshots in a hidden .git folder using simple data chunks called objects.

Core Layers

Your files sit in the working directory, changes go to the staging area (index), and commits save full snapshots to the repository. This three-layer setup lets you prepare changes before locking them in. Hashes (SHA-1 codes) name each piece uniquely from its content.

Key Objects

• Blob: Raw file data, no path or name.
• Tree: Maps folders and files to their blobs or sub-trees.
• Commit: Links a tree snapshot, parents, author, date, and message.

These form chains; identical content reuses the same hash for efficiency.

git add Step

Git hashes changed files into blobs and updates the index with paths and hashes. Staging prepares a clean snapshot without altering your work files.

git commit Step

From the index, Git builds trees, creates a commit object, and points your branch (via refs/) to its hash. History grows as a chain or branches, all verified by hashes.

Simple Model

Picture a chain of photo albums (commits) where each photo (tree) shows folder layouts of pictures (blobs). Edit a picture? New hash ripples up, creating a fresh album. Branches are just labels sliding along the chain.

Understanding the .git Folder

The .git folder is Git’s hidden storage for all project history and data. It keeps your work safe without cluttering files.

Why It Exists

Git uses .git to track every change, store commits, and manage branches. Delete it, and your project loses all version history.

Main Parts Inside

• objects/: Packed files, folders, and commits as hashed data.
• refs/: Points to branches and tags.
• index: Staging area for git add.
• HEAD: Current branch or commit.
• config: Repo settings.

Git serves as a distributed version control system that tracks changes in your code, enabling multiple developers to collaborate efficiently without overwriting each other’s work. Before Git, developers faced issues like manually copying code via pendrives or email, leading to version confusion, lost changes, and merge nightmares when combining files.

Why Use Git

Git eliminates the chaos of traditional methods by creating snapshots of your project at any point, allowing you to revert changes, experiment safely, and maintain a complete history locally. Its distributed nature means every developer has a full copy of the repository, reducing reliance on central servers and enabling offline work.

Core Concepts

• Repository (Repo): A directory containing your project files and their complete revision history, either local or remote.

• Working Directory: Your everyday files where you edit code; changes here aren’t tracked until staged.
  Staging Area (Index): Intermediate zone where you select specific changes to prepare for a commit.

• Commit: A saved snapshot of staged changes with a unique ID and descriptive message, forming your project’s history.

• Branch: A lightweight pointer to a series of commits, letting you work on features independently from the main codebase.

• HEAD: Points to the current commit or branch you’re on, moving forward as you commit.

Basic Workflow

Start with an empty folder for your project.

• Initialize: git init creates a new repo with a .git folder.

• Check status: git status shows modified, staged, or untracked files.

• Stage changes: git add filename.txt (or git add . for all) moves files to staging.

• Commit: git commit -m "Initial project setup" saves the snapshot.

• View history: git log displays commits with IDs, authors, and messages.

• Create branch: git branch feature-x then git checkout feature-x (or git switch feature-x ) to work separately.

• Merge: Switch to main ( git checkout main ), then git merge feature-x to combine.

This workflow mirrors real development: edit in working directory → stage selectively → commit to repo → branch for features → merge when ready.

Common Commands

Workflow Example

Start with ChaiCode portfolio/tutorial site:

1. Create folder chai-code and navigate: cd chai-code .
2. git init – Initializes repo for your ChaiCode project.
3. Add files: Create index.html (homepage), app.js (basic JS logic), styles.css .
4. Check: git status reveals untracked files in your ChaiCode directory.
5. Stage selectively: git add index.html app.js (skip CSS for now).
6. Commit: git commit -m "Initial ChaiCode homepage and JS" .
7. Iterate: Edit app.js to add a “Brew Code” button function, then git add app.js , git commit -m "Add interactive brewing feature" .
8. History: git log --oneline shows clean ChaiCode evolution like e4f5g6 (HEAD -> main) Add brewing feature .