every page load or API call begins with an HTTP request from a client (like a web browser) to a server. This request is central to the web’s client-server architecture.

However, before the server can receive an HTTP request, several network steps happen behind the scenes: first a DNS lookup translates the domain name to an IP address, then a TCP/IP connection is established.

Only after those steps does the actual HTTP request/response flow occur, with data exchanged as network packets. In this post, we’ll explore each stage of this process under the hood.

DNS Resolution: Finding the Server’s IP

The Domain Name System (DNS) acts like the Internet’s phonebook, mapping domain names (e.g. example.com) to IP addresses.

When you enter a URL, the browser first checks its cache (and the OS cache) for a cached result. If not found, a DNS query is sent to a DNS resolver (usually provided by your ISP). The DNS resolution process typically involves:

1. Resolver query – The resolver receives the request for the domain. If not cached locally, it will query the DNS hierarchy.
2. Root & TLD servers – The resolver first asks a root DNS server, which directs it to a Top-Level Domain (TLD) nameserver (for .com, .org, etc.).
3. Authoritative server – Next, the resolver queries the TLD-provided authoritative server for the domain’s IP address.
4. IP address returned – The authoritative DNS server returns the IP address, which the resolver then sends back to the browser.

Once the domain name is resolved to an IP, the browser can initiate a connection to that IP address.

TCP/IP Connection: Three-Way Handshake

With the IP address known, the client’s next step is to establish a TCP/IP connection to the server (typically on port 80 for HTTP or 443 for HTTPS).

TCP (Transmission Control Protocol) is a reliable, connection-oriented protocol that runs over IP (Internet Protocol).

TCP uses a three-way handshake to set up the connection. In this handshake:

• The client sends a SYN packet to the server to request a connection.
• The server responds with a SYN-ACK packet.
• The client replies with an ACK packet to confirm.

This SYN → SYN-ACK → ACK exchange ensures both sides agree to communicate and are synchronized. After the handshake, a TCP socket connection is open. (If using HTTPS, an additional TLS/SSL handshake secures the connection after TCP.)

The IP layer handles routing these packets across the network to reach the correct server.

HTTP Request/Response Flow

With a TCP connection in place, the browser sends the actual HTTP request. HTTP is an application-layer protocol that follows a request-response model.

An HTTP request consists of a request line (method, path, and HTTP version), followed by request headers, and an optional body (for methods like POST).

For example, a GET request might look like:

This asks the server for the /index.html page. The server then processes the request and sends back an HTTP response.

A response begins with a status line (e.g. HTTP/1.1 200 OK), includes response headers (e.g. content type, length, etc.), and then the response body (the content, such as the HTML of the page).

The status code 200 OK means success; other codes like 404 Not Found indicate an error. Once the client receives the response, it can render the page or use the data.

Packet Transmission and Data Transport

While HTTP defines the content of the messages, the actual data is transmitted over the internet as packets.

When an HTTP request or response is sent, it is broken into segments by TCP, then encapsulated into IP packets for transmission.

Each packet has a header (with source/destination IP, protocol, and sequence number) and a portion of the payload (the HTTP data).

These packets travel through routers to reach the destination. Packets may arrive out of order, but TCP reorders them using sequence numbers to reconstruct the original message.

TCP also ensures reliability: for each packet received, the receiver sends an ACK; if an ACK isn’t received for a packet, the sender retransmits that packet.

Even if some packets are lost, TCP’s retransmission mechanism guarantees the complete data will arrive. Once all the packets of a request reach the server, they are reassembled into the full message.

The server then generates a response, which is sent back in the same segmented way. After the exchange, the TCP connection is closed (unless kept alive for reuse).

From a simple URL to a rendered webpage, a lot happens under the hood. DNS finds the server’s address, TCP/IP establishes a reliable connection via a handshake, and HTTP handles the request/response transfer of data — all of this through packets moving across the network.

Understanding these layers helps developers troubleshoot issues and optimize web performance.