Introduction to Networking

Modern software is networked software. The frontend you build talks to a backend; the backend talks to databases, third-party APIs, and other services. Streaming a video, loading a web page, or sending a chat message all boil down to packets moving across wires and radio waves.

Because so much rides on the network, understanding it stops being optional. When a request is slow, times out, or silently fails, the engineers who understand the network can actually debug it — instead of guessing and restarting things until it works.

• ▸You make hundreds of HTTP requests a day, mostly without noticing.
• ▸The network is the invisible layer connecting every service you write.
• ▸The goal of this series: replace "it just works" with "I know exactly what happens under the hood".

This is the very first deep-dive of the series, and the question that ties everything together. You type a URL or your app calls an endpoint, and moments later a response appears. Between those two moments, a lot happens.

At a high level, the request has to find where the server lives, travel across many networks to get there, be understood by the server, and then make the whole trip back. Each of those steps is powered by a different protocol — and each becomes its own chapter later.

You type a URL

The browser or app starts a request (GET, POST, etc.).

DNS lookup

The human name (like example.com) is turned into an IP address.

Routing

Packets hop across routers and networks toward that IP.

Server

The destination machine processes the request.

Response

The answer travels all the way back to you.

Before higher-level protocols make sense, we need a solid core. These fundamentals are the alphabet of networking — once you can read them, everything else becomes spelling.

IP address & structure

The addressing scheme that identifies a device on a network.

Network vs Host

An IP splits into a network part (which network) and a host part (which device on it).

Subnet & Subnet Mask

How a big network is carved into smaller ones, and the mask that marks the split.

CIDR range

A compact notation (like /24) for describing a block of addresses.

Default Gateway

The exit door your device uses to reach anything outside its own network.

MAC address

A hardware address baked into a network interface.

ARP

Address Resolution Protocol — maps an IP address to a MAC address on the local network.

TCP/IP model

The layered model that organizes how all these pieces fit together.

MAC vs IP

Why we need two different addresses, and what each one is for.

Once we understand addresses, the next question is how a packet actually travels from one device to another that may be on the other side of the world.

The answer is routing: the journey is not one giant leap but a series of hops. Your packet reaches a router, which decides the best next hop and forwards it on. That router hands it to the next, and so on, until it arrives. No single router knows the whole path — each just knows the next best step.

• ▸Data is broken into packets that travel independently.
• ▸Each router inspects the destination and picks the next hop.
• ▸The full path is discovered hop by hop, not planned in advance.

ICMP (Internet Control Message Protocol) is one of the most important protocols for diagnosing networks. It is the machinery behind the everyday tools you already use.

ping

Sends an ICMP echo request and waits for an echo reply — a quick "are you alive and how far away?" check.

traceroute

Sends packets with a growing TTL (time to live) so each router along the way reveals itself, mapping the full path.

Once you understand ICMP, these utilities stop being magic commands and become tools you can reason about — and even build intuition for when a route breaks.

Now we climb to the transport layer, which is responsible for getting data between applications. The first protocol here is UDP (User Datagram Protocol) — the fast, no-frills option.

UDP is "fire and forget": it does not set up a connection, does not guarantee delivery, and does not guarantee order. That sounds bad, but for the right jobs the low overhead is exactly what you want.

• ▸No connection setup — just send the datagram.
• ▸No delivery or ordering guarantees — speed over reliability.
• ▸Great for live video/voice calls, gaming, DNS queries, and streaming.

TCP (Transmission Control Protocol) is arguably the most important protocol on the internet — its reliable backbone. Where UDP throws data and hopes, TCP guarantees it arrives, in order, intact.

It earns that reliability by first establishing a connection with a three-way handshake — SYN, then SYN-ACK, then ACK — and by tracking every byte with sequence and acknowledgement numbers so nothing is lost or duplicated.

3-way handshake

SYN → SYN-ACK → ACK sets up a reliable connection before any data flows.

Sequence & Ack numbers

Track exactly which bytes have been sent and received, enabling retransmission.

Connection teardown

A defined way to close the connection cleanly when done.

A common point of confusion: flow control and congestion control sound similar but solve different problems. Both keep TCP fast and stable, but they protect different things.

Flow control

Stops a fast sender from overwhelming a slow receiver, using the receiver window (window size / window scale).

Congestion control

Stops senders from overwhelming the network itself when links get busy.

Slow start & congestion avoidance

Algorithms that ramp the sending rate up carefully, then back off on trouble.

ECN

Explicit Congestion Notification — a signal that congestion is building, before packets are actually dropped.

Now we reach the application layer — where we, as developers, mostly live. DNS (Domain Name System) is the internet’s phone book: it turns human-friendly names like example.com into the IP addresses machines actually use.

DNS resolves names recursively, walking a chain of servers until it finds the answer. Beyond plain name lookups, DNS records power real-world features you use every day.

A / AAAA

Map a name to an IPv4 (A) or IPv6 (AAAA) address.

CNAME

An alias pointing one name at another.

MX

Points to the mail servers that handle email for a domain.

TXT (SPF / DKIM / DMARC)

Text records used to authenticate email and detect spam and spoofing.

HTTP is the application-layer protocol most of our work rides on. It has evolved a lot, and around it sit two more essentials: WebSockets for real-time two-way communication, and TLS for security.

HTTP/1 → 1.1 → 2 → 3

Each version improved speed and efficiency; HTTP/3 is built on QUIC (over UDP).

WebSockets

A persistent, full-duplex channel so client and server can push messages both ways in real time.

TLS

Transport Layer Security — encrypts the connection so data cannot be read or tampered with in transit.

We close the chapter with two protocols that quietly run every home and office network: DHCP and NAT. They are technically networking fundamentals, but they click faster once the earlier concepts are in place.

DHCP

Dynamic Host Configuration Protocol — automatically hands a new device an IP address (and gateway, DNS, etc.) so you do not configure it by hand.

NAT

Network Address Translation — lets many devices with private IPs (like 192.168.x.x) share a single public IP through the router.

Zooming out, all of these topics stack neatly into the TCP/IP model. Each chapter of the series fills in one part of this picture, from the wire up to your application.

Application

DNS, HTTP, WebSockets, TLS — where your code lives.

Transport

TCP and UDP — reliable vs fast delivery between apps.

Internet

IP, ICMP, and routing — addressing and moving packets across networks.

Link

MAC and ARP — communication on the local physical network.

By the end of the series you will be able to read IP and MAC addresses, reason about TCP and UDP, and — most usefully — debug real network problems as a software engineer. It is also a strong launchpad if you go deeper into network engineering later.