TCP/IP Protocol Stack Diagram

+-----------------------------------------------------+
|                Application Layer                     |
|   HTTP | FTP | SMTP | DNS | Telnet | SNMP             |
+-----------------------------------------------------+
|                Transport Layer                        |
|              TCP            |          UDP             |
+-----------------------------------------------------+
|                 Internet Layer                        |
|          IP  |  ICMP  |  ARP  |  IGMP                  |
+-----------------------------------------------------+
|              Network Access Layer                     |
|      Ethernet | Wi-Fi (802.11) | PPP | Frame Relay     |
+-----------------------------------------------------+
              |  physical medium (copper/fiber/air)  |

Data flows top-down at the sender (each layer adds its own header — encapsulation) and bottom-up at the receiver (each layer strips its header — decapsulation).

Why layered architecture is needed

1. Modularity — each layer solves one well-defined problem (e.g. routing, reliable delivery) independently of the others, making the system easier to design, understand, and reason about.

2. Independent evolution — a layer's internal implementation can change (e.g. Ethernet replaced by Wi-Fi) without requiring changes to the layers above it, as long as the interface between layers stays the same.

3. Interoperability — standardized interfaces between layers let hardware and software from different vendors work together, since each only needs to honor the layer boundary contract.

4. Simplified troubleshooting — problems can be isolated to a specific layer (e.g. a routing issue is a Network-layer problem, not an Application-layer one), speeding up diagnosis.

5. Reusability — lower layers (e.g. IP, Ethernet) can be reused by many different upper-layer applications, avoiding duplicated effort.

Without layering, every application would need to handle addressing, routing, framing, and physical transmission itself — an unmanageable, tightly-coupled design.