TCP/IP Deep Dive: What Happens When You Send a Packet
A layer-by-layer journey through the network stack — from application to wire and back.
When you type a URL in your browser, an extraordinary sequence of events unfolds across multiple layers of the network stack. Understanding this journey is fundamental to debugging network issues, optimizing performance, and designing reliable systems.
It starts at the application layer. Your browser constructs an HTTP request — a text-based protocol that specifies the method (GET), the path, headers (Host, User-Agent, Accept), and optionally a body. For HTTPS (which is nearly universal in 2026), TLS negotiation happens first: a handshake that establishes a shared secret using asymmetric cryptography (typically ECDHE for key exchange and AES-256-GCM for encryption).
The HTTP payload is then passed to the transport layer, where TCP takes over. TCP provides reliable, ordered delivery over an unreliable network. It segments the data into chunks, adds a header with source port, destination port, sequence number, acknowledgment number, flags (SYN, ACK, FIN, RST), and a checksum. Before any data flows, TCP performs the three-way handshake: SYN → SYN-ACK → ACK. This takes one round-trip time (RTT), which is why connection reuse (HTTP keep-alive, connection pooling) matters so much for performance.
TCP's flow control uses a sliding window mechanism. The receiver advertises a window size — how many bytes it can buffer. The sender never sends more than the window allows. Congestion control (algorithms like CUBIC, BBR, or the newer BBRv2) dynamically adjusts the sending rate to avoid overwhelming the network. TCP slow start begins with a small congestion window (typically 10 segments after RFC 6928) and doubles it each RTT until it detects congestion (via packet loss or ECN signals).
At the network layer, IP (Internet Protocol) adds source and destination IP addresses, a TTL (Time to Live) field to prevent infinite loops, and a protocol field indicating TCP (6) or UDP (17). If the packet exceeds the MTU (Maximum Transmission Unit, typically 1500 bytes for Ethernet), it's fragmented — though modern systems prefer Path MTU Discovery to avoid fragmentation overhead.
DNS resolution happens before the first SYN packet. Your system checks its local cache, then queries a recursive resolver (often your ISP's or a public resolver like 1.1.1.1). The resolver walks the DNS hierarchy: root servers → TLD servers (.com, .dev) → authoritative nameservers. The result is cached according to the TTL in the DNS record. A typical DNS lookup adds 20-120ms to the first request to a new domain.
The data link layer frames the IP packet with source and destination MAC addresses. On a local network, ARP (Address Resolution Protocol) maps IP addresses to MAC addresses. The frame is transmitted as a series of electrical signals (Ethernet), light pulses (fiber), or radio waves (Wi-Fi, cellular).
At each router along the path, the IP header is inspected, the TTL is decremented, and the next hop is determined by consulting the routing table (built by protocols like BGP for inter-AS routing and OSPF for intra-AS routing). The data link header is stripped and a new one is added for the next network segment.
Understanding this stack transforms how you think about performance. A 100ms API response might include 30ms of DNS resolution (cacheable), 40ms of TCP handshake (reusable connections), 20ms of TLS negotiation (session resumption), and only 10ms of actual server processing. Optimizing the server is necessary but not sufficient — the network is often the bottleneck.