Layered Architecture in Computer Networks

When two web browsers exchange data, their HTTP implementations appear to communicate directly—browser to browser, HTTP to HTTP. But this is an illusion. The actual data path is radically different: down through the sender's protocol stack, across the physical network, and up through the receiver's protocol stack.

This concept of peer communication—where each layer behaves as if it communicates directly with the corresponding layer on remote systems—is central to network architecture. It's what makes protocols modular, what enables layers to be designed independently, and what allows a TCP implementation to be analyzed without considering Ethernet frame formats.

Peer entities are the corresponding layer implementations on different systems that communicate with each other. They are:

• The two TCP implementations managing a connection
• The two IP stacks routing packets between hosts
• The two HTTP implementations exchanging requests and responses
• The two Ethernet adapters sending frames over a cable

Each pair of peer entities has a defined protocol governing their interaction—the rules, message formats, and state machines that ensure they understand each other.

Key insight: Two types of communication

1. Vertical communication (actual): Data flows down through the sender's stack and up through the receiver's stack. This is what physically happens.

2. Horizontal communication (virtual): Each layer appears to communicate directly with its peer. HTTP talks to HTTP; TCP talks to TCP. This is the conceptual model.

The power of layering comes from this duality. Protocol designers think in terms of peer communication, designing protocols as if layers talk directly. But the layered implementation ensures data actually flows through proper channels.

Peer communication is enabled by Protocol Data Units (PDUs)—the formatted data units each layer exchanges with its peer. Each layer adds a header (and sometimes trailer) containing information for its peer, treating everything from above as an opaque payload.

How headers enable peer communication:

When data arrives at a layer, that layer:

1. Examines its header — Extract control information meant for this layer
2. Processes accordingly — Route the packet, deliver to correct port, reorder segments
3. Strips its header — Remove layer-specific information
4. Passes payload up — Deliver to the next higher layer

The receiving layer sees ONLY information from its peer sender. TCP sees TCP headers, not IP headers. HTTP sees HTTP headers, not TCP sequence numbers. This isolation is what makes peer communication work.

Example: TCP header for peer communication:

The virtual communication model is the mental framework that makes protocol design tractable. When designing or analyzing a protocol, we imagine that peer entities communicate directly, ignoring the underlying stack.

Why this abstraction works:

1. Reliability of lower layers: Each layer depends on the layer below providing certain services. TCP assumes IP will (eventually) deliver packets. IP assumes data link will transmit frames.

2. Independence of operations: What TCP does (ordering, reliability) doesn't depend on what IP does (routing). They're conceptually independent, interacting only through well-defined interfaces.

3. Composition of services: Each layer adds capabilities. Best-effort delivery (IP) + reliability (TCP) + application semantics (HTTP) = reliable web browsing. Each focused contribution combines into complex behavior.

Peer communication often involves state machines—formal models of the states each peer can be in and the transitions between them. Both peers maintain synchronized state machines, and protocol messages trigger transitions.

Why state machines matter:

1. Formal specification: State machines precisely define valid protocol behavior. Implementers know exactly what's expected.

2. Synchronization: Both peers MUST be in compatible states. A packet arriving in the wrong state indicates an error or attack.

3. Recovery: When state becomes inconsistent (due to failures), protocols define how to resynchronize.

4. Testing: State machines enable exhaustive testing—verify all states and transitions are handled correctly.

TCP state machine synchronization:

Consider the TCP three-way handshake:

Both peers now in ESTABLISHED state—synchronized and ready for data transfer.

What happens if states diverge:

• If server receives data while in LISTEN state → Error (no connection exists)
• If data arrives with unexpected sequence numbers → Possibly spoofing attack
• If FIN arrives while peer thinks connection is active → Graceful or abrupt close

The state machine defines correct behavior for all cases, including error recovery.

Real networks include intermediate devices—switches, routers, firewalls, load balancers—that process packets between source and destination. How does peer communication work through these devices?

The key insight: intermediate devices operate at specific layers and are transparent to layers above them.

Layer 2 devices (switches):

• Operate on Ethernet frames
• Look at MAC addresses to forward
• Transparent to IP and above
• From IP perspective, hosts appear directly connected

Layer 3 devices (routers):

• Operate on IP packets
• Look at IP addresses to route
• Rewrite Layer 2 (new MAC addresses per hop)
• Transparent to TCP and above
• From TCP perspective, hosts appear directly connected

End-to-end peer communication:

Despite passing through multiple intermediate devices:

• TCP peers are end hosts only — TCP connection exists between source and destination. Routers don't maintain TCP state (unless they're doing deep packet inspection).

• IP peers include routers — Each router is an IP peer, making routing decisions. But IP is designed for this—packets can take different paths without breaking anything.

• Ethernet peers are adjacent devices — Each Ethernet hop has new source/destination MACs. The MAC addresses change at every router, but IP addresses stay constant end-to-end.

Breaking the abstraction: Middleboxes

Some devices break layer transparency:

• NAT: Modifies IP addresses AND port numbers, breaking the end-to-end model
• Deep Packet Inspection: Examines application layer content at network middle
• Proxies: Terminate and re-initiate connections, appearing as the 'real' peer

These violations are controversial—they can break applications and complicate debugging—but they're widespread due to practical needs (IPv4 scarcity for NAT, security for DPI).

Peer communication often involves structured exchanges—predictable sequences of messages that accomplish specific functions. Understanding these patterns helps in protocol design, implementation, and debugging.

Common exchange patterns:

Idempotency and retries:

Peer communication often includes retry mechanisms for reliability. This raises the question of idempotency—whether repeating an operation has the same effect as performing it once.

• HTTP GET: Idempotent. Retrying is safe.
• HTTP POST: Not idempotent. Retrying may create duplicates.
• TCP retransmit: Idempotent. Sequence numbers identify duplicates.
• DNS query: Idempotent. Same question, same answer.

Protocol designers must consider what happens when messages are duplicated (network retry) or lost (timeout). The exchange pattern and idempotency properties determine correct application behavior.

Pipeline and multiplexing:

Advanced exchanges allow concurrent operations:

• HTTP/1.1 pipelining: Send multiple requests without waiting for responses
• HTTP/2 multiplexing: Multiple concurrent streams on one connection
• TCP: Multiple in-flight segments (windowing)

These optimize throughput by overlapping communication with processing.

Understanding peer communication directly enables effective debugging. When something goes wrong, you can think at the right layer and examine peer exchanges.

Layer-by-layer debugging approach:

1. Start at the application layer: Is the application protocol exchange correct? Are requests properly formed? Are responses valid?

2. Check transport layer: Is the connection established? Are there retransmissions? Is the connection being reset?

3. Check network layer: Are packets being routed correctly? Are they being dropped? Is there a path at all?

4. Check data link/physical: Is the link up? Are frames being transmitted? Is there signal quality issue?

We've explored how network layers communicate with their peers through protocols, headers, and state machines. Let's consolidate the key insights:

What's next:

Now that we understand how layers communicate with their peers, we'll complete our exploration by examining what each layer actually does. The next page covers layer functions—the specific responsibilities of each layer in the network stack, from physical bit transmission to application-level semantics.