When an engineer says "the network is broken," the next question should be: which part?

The OSI (Open Systems Interconnection) model gives engineers a shared way to answer that. It splits network communication into seven layers, from raw electrical or radio signals all the way up to application protocols like HTTP and DNS.

ISO published the model in the 1980s as a common vocabulary for network responsibilities.

Most production systems do not implement OSI literally. The internet is usually described with the TCP/IP model, and modern protocols often blur neat OSI boundaries. TLS sits between application and transport. QUIC adds transport behavior on top of UDP. Service meshes often work at both Layer 4 and Layer 7.

That is fine. The OSI model is still useful because it gives diagnostic clarity. It turns "the network is broken" into a sharper question: is this a cable problem, a local network problem, a routing problem, a TCP problem, a TLS problem, or an application problem?

This chapter explains each layer and how to use the model when diagnosing failures.

Early networks were split across vendor-specific protocols and hardware. Systems from one vendor often could not communicate with systems from another.

The OSI model gave the industry a shared vocabulary for the work every networked system has to do.

The model does not tell everyone to implement networking the same way. It separates responsibilities:

That separation still matters. When an API call fails, "the network is broken" is too vague to be useful.

A senior engineer narrows the problem: DNS lookup, TCP connection setup, TLS handshake, HTTP routing, load balancer policy, application timeout, or backend saturation. OSI helps structure that investigation.

A common mnemonic from bottom to top is Please Do Not Throw Sausage Pizza Away: Physical, Data Link, Network, Transport, Session, Presentation, Application.

The model splits networking into seven layers, starting with raw signals and ending with the application protocol.

Each layer handles one part of the job and passes the result to the next layer. A problem in a lower layer often appears as confusing behavior higher up.

Layer 1: Physical

The Physical layer moves raw bits over a physical medium.

That medium might be electrical signals over copper, light through fiber, or radio waves for WiFi and cellular networks. Layer 1 knows nothing about HTTP, IP addresses, ports, or files. Its job is simply to move signals well enough that the next layer can understand them.

Layer 1 concerns include:

If Layer 1 is failing, higher-layer fixes do not help. A bad cable, failing fiber module, weak WiFi signal, or overloaded radio channel can look like random application instability until you check the link.

Layer 2: Data Link

The Data Link layer turns raw bits into frames and handles delivery on a local network. Ethernet and WiFi are common examples.

Layer 2 introduces MAC addresses, which identify network interfaces on a local link. A MAC address is usually a 48-bit value such as 00:1A:2B:3C:4D:5E.

Older explanations often call MAC addresses permanent hardware addresses. In real systems, they can be configured, virtualized, or randomized by operating systems, hypervisors, containers, and cloud platforms.

Layer 2 responsibilities include:

The common Layer 2 device is an Ethernet switch. A switch learns which MAC addresses are reachable on which ports and forwards frames accordingly. A hub, by contrast, repeats signals to every port and is essentially a Layer 1 device.

Many modern switches also provide Layer 3 routing features, so "switch" describes a product class more than a strict OSI layer.

Layer 2 is local. It can deliver a frame to another device on the same link or VLAN. To reach a different network, traffic needs Layer 3.

Layer 3: Network

The Network layer routes traffic between networks.

It is what lets a laptop in Mumbai reach an API server in Virginia, or a service in one cloud VPC reach a database subnet in another region.

Layer 3 uses IP addresses, most commonly IPv4 and IPv6. Routers look at the destination IP address and forward each packet one hop closer to its destination.

Layer 3 responsibilities include:

MAC and IP addresses solve different problems. A MAC address is used for local delivery on one link. An IP address is used for routing across networks.

Protocols such as ARP for IPv4 and Neighbor Discovery for IPv6 connect those two worlds by mapping an IP address to a local-link address.

Be careful with the phrase "Layer 3 fragments packets." IPv4 supports fragmentation, but relying on it is a poor design choice. IPv6 routers do not fragment packets in transit.

Modern systems usually depend on path MTU discovery, which means finding the largest packet size the path can handle, and on sensible payload sizing.

Layer 3 gets a packet to the right host or network interface. It does not know which process on that host should receive the data. That is Layer 4.

Layer 4: Transport

The Transport layer delivers data between processes.

Layer 4 adds ports, which identify the application endpoint on a host. A web server often listens on port 443. SSH commonly listens on port 22. A client usually uses a temporary source port chosen by the operating system.

The combination of protocol, source IP, source port, destination IP, and destination port identifies a network flow.

Layer 4 responsibilities include:

TCP and UDP are the protocols engineers deal with most often at this layer.

TCP does not guarantee that an application operation succeeds. It guarantees reliable, ordered delivery of bytes while the connection is healthy.

If a connection breaks mid-request, the application still needs timeouts, retries, idempotency, and duplicate handling.

Before application data flows over TCP, the client and server establish a connection:

Port numbers are divided into ranges:

Layer 4 is also where many production load balancers operate. A Layer 4 load balancer forwards TCP or UDP flows without understanding HTTP routes, headers, cookies, or request bodies. That makes it fast and general, but less aware of application behavior.

Layer 5: Session

The Session layer describes how communication sessions are started, kept alive, resumed, and closed.

In modern internet stacks, there is rarely a separate Session-layer implementation. Session behavior is usually handled by application protocols, libraries, frameworks, or infrastructure.

Still, the concept is useful because production systems are full of session-like state:

For system design, the important question is what state exists across requests or connections, and what happens when that state is lost. Where the Layer 5 logic physically lives matters less than the lifecycle of that state.

Layer 6: Presentation

The Presentation layer deals with how data is represented before applications read it or after applications produce it.

This includes encoding, serialization, compression, and encryption. Serialization means turning structured data, such as objects, into bytes that can be sent or stored.

In real systems, these concerns are usually implemented inside application libraries or protocol stacks rather than as a separate layer. JSON, Protocol Buffers, Avro, and MessagePack define how structured data becomes bytes. UTF-8 defines how text becomes bytes. gzip, Brotli, and Zstandard reduce payload size. TLS encrypts data between endpoints.

Use current terminology here: TLS is the modern protocol. SSL is obsolete and should not be used for new systems.

Presentation choices have real operational consequences. A verbose JSON payload can dominate latency on mobile networks. A badly chosen compression setting can save bandwidth but burn too much CPU. A TLS misconfiguration can break clients or weaken security. A schema change can corrupt data if producers and consumers are not rolled out carefully.

Layer 7: Application

The Application layer is where application protocols define meaning.

This is the layer your software most directly speaks: HTTP requests, DNS queries, SMTP messages, SSH sessions, gRPC calls, Kafka protocol requests, and database wire protocols.

Layer 7 covers the protocol surface applications use to communicate. That is different from the business logic those applications implement.

Layer 7 is where API gateways, reverse proxies, WAFs, and many service meshes make richer decisions. They can route by hostname or path, enforce authentication, inspect headers, apply rate limits, terminate TLS, retry selected requests, and emit application-level metrics.

For an AI product, Layer 7 might be an HTTPS endpoint for chat completions, a gRPC interface to an inference service, a streaming response over Server-Sent Events, or a database protocol call to a vector store. The network layers below still matter, but Layer 7 defines the contract the application relies on.

When an application sends data, each lower layer adds its own wrapper. This is encapsulation.

For example, an HTTPS request from a client to an API service might flow like this:

On the receiving side, decapsulation happens in reverse. Each layer reads and removes the wrapper it understands, then passes the remaining data upward. In plain English, the receiver unwraps the data one layer at a time.

Each layer names its data unit differently:

This naming is useful during debugging. Packet captures, load balancer logs, TCP resets, TLS alerts, HTTP status codes, and application exceptions all describe different layers of the same communication path.

The OSI model is a reference model. The TCP/IP model is closer to how the internet is described and implemented in practice.

TCP/IP usually has four layers:

The mapping is approximate. Real protocols do not always fit perfectly into one box.

ARP and IPv6 Neighbor Discovery sit between local-link and network concerns. TLS is usually discussed near the application layer, but operationally it sits between application protocols and transport. QUIC is carried inside UDP datagrams but adds reliability, congestion control, streams, and TLS 1.3.

Layer models are useful mental models, not strict laws. These crossovers are expected.

The OSI model is most useful when diagnosing failures or choosing infrastructure.

Troubleshooting by Layer

If a client cannot reach a service, work from concrete signals instead of guessing.

This layered thinking prevents expensive wrong fixes. A team should not rewrite retry logic before checking whether a load balancer is closing idle connections. It should not tune database queries before confirming DNS, routing, and TLS are healthy.

Infrastructure Choices

Layer awareness also affects design choices:

For example, consider a model inference API:

Every step can fail differently. OSI gives you a clean way to reason about those failures without pretending the stack is simpler than it is.

The OSI model is a practical vocabulary for networked systems, even though production stacks are usually TCP/IP-based and do not map cleanly onto seven layers.

Its value is in separating concerns. Layer 1 covers signals and media. Layer 2 covers local frames and MAC-level delivery. Layer 3 covers IP addressing and routing. Layer 4 covers ports, TCP, UDP, and process-to-process delivery.

The upper layers cover session lifecycle and recovery, then data format, compression, serialization, and encryption, and finally application protocols and request behavior.

The most useful habit the model encourages is precision. When a distributed system fails, naming the layer and looking for evidence turns a vague network complaint into a fixable problem.