Networking terms come with layer numbers attached. L2 switch, L3 routing, L4 load balancer, L7 proxy. I used these terms daily without ever properly sorting out the OSI model the numbers come from. I remembered memorizing the layer names at some point, but that memorization never connected to reading the vocabulary I use at work.

Once I sorted it out, the OSI model turned out to be less about memorization and more about reading terminology. The real internet doesn’t run on OSI protocols, but the L2, L3, L4, and L7 in the names of network devices and software all come from this model.

The OSI Model and the TCP/IP Model

OSI (Open Systems Interconnection) is a reference model standardized by ISO in 1984 (ISO/IEC 7498). It divides the functions needed for communication into seven layers, where each layer uses the services of the layer below to provide services to the layer above.

What runs the internet is the TCP/IP stack. RFC 1122 defines communication for internet hosts in four layers: link, internet, transport, and application. The two models map to each other as follows.

flowchart LR
    subgraph OSI["OSI 7 Layers"]
        direction TB
        O7["L7 Application"]
        O6["L6 Presentation"]
        O5["L5 Session"]
        O4["L4 Transport"]
        O3["L3 Network"]
        O2["L2 Data Link"]
        O1["L1 Physical"]
        O7 --- O6 --- O5 --- O4 --- O3 --- O2 --- O1
    end
    subgraph TCPIP["TCP/IP 4 Layers"]
        direction TB
        T4["Application"]
        T3["Transport"]
        T2["Internet"]
        T1["Link"]
        T4 --- T3 --- T2 --- T1
    end
    O7 -.-> T4
    O6 -.-> T4
    O5 -.-> T4
    O4 -.-> T3
    O3 -.-> T2
    O2 -.-> T1
    O1 -.-> T1

    style O4 fill:#C8E6C9
    style O3 fill:#FFF3E0
    style T3 fill:#C8E6C9
    style T2 fill:#FFF3E0

TCP/IP won the protocol standards competition, and the OSI protocol stack itself sees little use. As vocabulary for naming layers, though, OSI survived. Nobody calls a transport-layer device an “L3 device” using TCP/IP numbering — it’s an “L4 load balancer” in OSI terms. Only L1, the physical layer, rarely appears in software vocabulary; it belongs to cables and signals.

L2 Switches and MAC Addresses

The data link layer delivers frames within a single network. Its address is the MAC (Media Access Control) address — a hardware identifier assigned per network interface, valid only within the same network.

The L2 switch is the representative device at this layer. It reads the MAC header of each frame, learns which MAC address is reachable through which port in a table, and forwards frames only to the matching port. The “L2” qualifier means the device interprets frames only up to the MAC header. It never looks at IP addresses.

Backend development rarely touches L2 directly, but communication within the same subnet ultimately happens as MAC-addressed frame delivery. Even when communication starts with an IP address, within the same network the host first resolves the corresponding MAC address via ARP (Address Resolution Protocol) and then delivers frames.

L3 Routing and IP

Crossing a network boundary is where the network layer takes over. The delivery unit is the packet, the address is the IP address, and the representative operation is routing. A router reads the IP header of each packet and forwards it to the next hop according to its routing table.

From L3 upward, the working vocabulary multiplies. Subnetting, routing tables, and NAT (Network Address Translation) gateways all operate on concepts from this layer. The CIDR (Classless Inter-Domain Routing) blocks, subnets, and routing tables you handle when designing a cloud VPC (Virtual Private Cloud) extend the same L3 vocabulary. There’s also a device called an “L3 switch” — a switch with routing capability — and the number in its name states plainly that it interprets packets up to the IP header.

L4 Load Balancers and Ports

Where IP handles the path to a host, the transport layer uses port numbers to decide which process on that host receives the data. TCP and UDP are the protocols at this layer.

An L4 load balancer distributes traffic by looking only at IP addresses and ports. It doesn’t interpret whether the payload is HTTP or gRPC. Distribution therefore happens per connection or per flow, overhead stays low, and the device works regardless of application protocol. AWS’s NLB (Network Load Balancer) belongs to this family.

L7 Proxies and HTTP

What the application layer handles is the data applications exchange. HTTP, gRPC, and DNS belong to this layer.

L7 proxies and L7 load balancers interpret request content. They parse HTTP requests and route by path, header, and method, distributing traffic per request. nginx, HAProxy, and Envoy operate at this layer, and AWS’s ALB (Application Load Balancer) belongs to the same family. Because the device can interpret requests, request-level control becomes possible: retries, timeouts, path-based routing.

Whether L4 or L7 sits in front is a workload decision.

When L4 fits:

  • TLS (Transport Layer Security) must terminate at the backend, so intermediate devices can’t interpret the payload (passthrough)
  • The traffic is TCP/UDP rather than HTTP
  • Parsing overhead matters and throughput comes first

When L7 fits:

  • Routing needs paths and headers (one entry point fanning out to multiple services)
  • Traffic must be distributed per request rather than per connection (HTTP/2 multiplexing environments)
  • Request-level control — retries, timeouts — should be handled at the entry point

Combining both is also common in practice: an L4 entry point with L7 proxies behind it interpreting requests.

The Session and Presentation Layers

Session-layer (L5) and presentation-layer (L6) vocabulary is hard to find in practice. I’ve never heard anyone say “L5 device” or “L6 proxy.” The TCP/IP model folded both layers into the application layer, and real protocols never implemented these boundaries separately either. Session management and data representation — serialization, encoding — are mostly handled by application protocols and libraries together.

TLS is a good example. It operates above the transport layer and below the application layer, and in OSI terms it’s described as session layer in some places and presentation layer in others. It doesn’t classify cleanly into either, because real protocols were never built to fit the OSI boundaries.

Recap

A layer number tells you up to which header a device interprets. An L2 switch interprets up to the MAC header, an L3 router up to the IP header, an L4 load balancer up to the port, and an L7 proxy up to the application data. With that criterion in place, the names switch, router, load balancer, and proxy read directly as what each device interprets. What happens at each layer is something I plan to work through protocol by protocol.

References