The TCP/IP model, despite its ubiquity, fundamentally views network communication as a series of independent, self-contained "conversations" between applications, rather than a single, monolithic data stream.

Let’s watch this in action. Imagine a simple HTTP request: your browser asks a web server for a webpage.

[Client Browser] --(HTTP GET /index.html)--> [Web Server]

At the Application Layer, your browser formats this request using HTTP. This is the language your application understands. It could be HTTP, FTP, SMTP, DNS, whatever. The Application Layer doesn’t care how it gets there, only that it’s sending application-specific data.

HTTP Request:
GET /index.html HTTP/1.1
Host: example.com
...

This HTTP request then gets handed down to the Transport Layer. Here, TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) takes over. For HTTP, TCP is almost always used because we need reliable, ordered delivery. TCP breaks the HTTP request into smaller chunks called segments. Each segment gets a header containing crucial information: source and destination port numbers (e.g., port 80 for HTTP, port 443 for HTTPS), sequence numbers (to reassemble the data in the correct order), and acknowledgment numbers (to confirm receipt). If you’re doing something like DNS or streaming video, UDP might be used for speed, sacrificing reliability.

TCP Segment (for a piece of the HTTP request):
Source Port: 50000
Dest Port: 80
Sequence Number: 12345
...
Payload: GET /index.html HTTP/1.1
         Host: example.com
         ...

Next, the TCP segment is passed to the Internet Layer. Here, IP (Internet Protocol) takes over. IP’s job is to route the data across networks. It encapsulates the TCP segment within an IP packet. The IP header contains the source and destination IP addresses (e.g., 192.168.1.100 to 93.184.216.34). This is the "where" of the communication. IP doesn’t know or care about ports or sequence numbers; it just ensures the packet gets from the source IP to the destination IP, potentially through many intermediate routers.

IP Packet (containing the TCP segment):
Source IP: 192.168.1.100
Dest IP: 93.184.216.34
Protocol: TCP (6)
...
Payload: [TCP Segment]

Finally, the IP packet is handed to the Network Access Layer (also sometimes called the Link Layer or Data Link Layer). This layer deals with the physical transmission of data over a specific medium (Ethernet, Wi-Fi, etc.). It takes the IP packet and encapsulates it into a frame. For Ethernet, this frame includes a MAC address header (source and destination MAC addresses, e.g., 00:1A:2B:3C:4D:5E to A1:B2:C3:D4:E5:F6) and a trailer (often for error checking like a Frame Check Sequence). The MAC addresses are for local network delivery – getting the frame from your machine to your router, or from one router to the next on the same physical link.

Ethernet Frame (containing the IP packet):
Dest MAC: A1:B2:C3:D4:E5:F6
Source MAC: 00:1A:2B:3C:4D:5E
EtherType: IPv4 (0x0800)
...
Payload: [IP Packet]
Trailer: FCS

This frame is then converted into bits and sent over the wire. At each hop (router), the frame is stripped off, the IP packet is examined to decide where to send it next, and a new frame is built for the next hop. The TCP segment and the HTTP request within it are generally untouched until they reach the final destination.

The most surprising thing about how TCP operates is its built-in congestion control mechanisms. When a TCP sender detects packet loss or increasing latency (which signals network congestion), it doesn’t just blindly retransmit. Instead, it dynamically adjusts its sending rate using algorithms like Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery to avoid overwhelming the network further. This ensures that multiple TCP connections can share a congested link without completely collapsing.

Once the frame arrives at the destination machine, the process reverses. The Network Access Layer strips off the frame header and trailer, passing the IP packet up. The Internet Layer checks the destination IP address and the protocol field, then passes the TCP segment up. The Transport Layer uses the port numbers to deliver the segment to the correct application and uses sequence and acknowledgment numbers to ensure all segments are received and in order, reassembling the original HTTP request. Finally, the Application Layer receives the complete HTTP request and processes it.

The next concept to explore is how routers make forwarding decisions based on IP addresses and routing tables.

Want structured learning?

Take the full Http course →