As developers, we write a single line like fetch('https://api.example.com/profile') and wait for the response. It feels simple. But behind that one line, a complex chain of networking events moves your request from your laptop to a server on the other side of the world — and brings the answer back.
This post walks through the full anatomy of an HTTP request, step by step, from the moment you hit enter to the moment your JSON arrives.
1. The Starting Point: DNS Resolution
The internet doesn't understand strings like api.example.com — it needs a physical destination, an IP address.
So your browser fires off a DNS (Domain Name System) query, essentially asking: "What's the address for this name?" DNS takes a human-readable hostname and hands back something like 10.0.0.1 — the address your machine can actually route data toward.
2. Preparing the Data: From Text to Bytes
An HTTP request is really just text: a method (GET), a path (/profile), and a set of headers (auth tokens, cookies, content types). But networks don't move text — they move bits. So before anything leaves your machine, the browser encodes that text-based request into bytes.
3. Handing Off to the Operating System
Once the request is encoded and the destination IP is known, the browser's job is basically done. Actually pushing bytes onto a wire isn't the browser's business — that's the OS's job. The browser hands the request down to the TCP/IP stack, which controls the network interface card (NIC) and everything below it.
4. Establishing a Connection: The TCP Handshake
HTTP rides on top of TCP, a connection-oriented protocol — meaning a reliable "pipe" has to exist before any real data flows. The OS opens that pipe with the classic TCP three-way handshake (SYN, SYN-ACK, ACK), a quick back-and-forth that confirms both sides are ready to talk.
5. Segmentation and Port Addressing
With the connection live, the OS slices the HTTP request into smaller chunks called segments, sized according to the Maximum Segment Size (MSS). Each segment gets wrapped with:
- Source port (e.g.
3000) — identifies the process on your machine that sent it - Destination port (e.g.
443for HTTPS) — tells the server which process should receive it - Sequence numbers — so the receiving end can reassemble everything in the right order, even if segments arrive out of sequence
6. The Virtual Envelope: IP Packets
Those TCP segments get wrapped again — this time into IP packets, which add the source and destination IP addresses. These are the addresses routers along the way use to decide the next hop toward your destination.
7. The Physical Delivery: MAC Addresses and ARP
IP addresses get you across the internet, but delivery on the local network is a different job — that's what MAC addresses are for, the unique hardware address burned into a device's NIC.
If your machine doesn't already know the MAC address of the next hop (say, your router), it broadcasts an ARP (Address Resolution Protocol) request: "Who has this IP?" The owner responds with its MAC address, and the packet gets wrapped into a frame ready for physical transmission.
8. Transmission
Finally, that frame becomes physical signals — radio waves over Wi-Fi, electrical pulses over Ethernet, or pulses of light over fiber — and travels out into the world.
Conclusion
That JSON response landing in your app is the payoff of a massive, multi-layered handoff: browser, operating system, and global networking hardware all cooperating in milliseconds. DNS lookups, TCP handshakes, segment sequencing, IP routing, MAC resolution — every layer plays its part in getting your data there safely and in order.
Next time you write fetch(...), you'll know exactly what you're setting in motion.
0 Comments