9 October 2026, 14:37Виталий Лещенко

Networking for beginners. Part 1: The OSI and TCP/IP models

All parts of the series “Networking for beginners”

This is the first article in the "Networking for beginners" series. The series is for people who write software, run servers, or simply want to understand what happens between pressing Enter in the address bar and the page appearing.

The series follows one principle: for every protocol, not only why it exists but how it works. Which bytes go over the wire, who answers them, what happens when something breaks. That is why almost every part has packet headers, commands and tcpdump output. To follow the examples, any Linux machine (WSL will do) with tcpdump installed, plus Wireshark on your workstation, is enough.

The plan: first the foundation — the models, Ethernet, Wi-Fi and PPPoE; then IPv4 with ARP and ICMP; transport — UDP and TCP; the service protocols DHCP and DNS; IPv6 as a separate block with Neighbor Discovery, SLAAC and DHCPv6; then VLAN, VXLAN, IPsec with IKEv2 and a discussion of how a VPN differs from a proxy; and finally routing between networks, OSPF and BGP, and TLS with certificates. The articles come out one at a time, and each one ends by saying what the next one covers.

The problem a network solves

Two programs on different computers want to exchange bytes. Between them are a cable or radio, switches, routers, several ISPs and half the globe. For the bytes to arrive, someone has to answer a whole list of questions:

how to encode bits into an electrical signal, light or a radio wave;
how to deliver data to one specific neighbour among a dozen devices on the same cable;
how to find a machine on the other side of the planet without knowing which networks lead to it;
how to make sure the data arrived complete and in the right order, and to resend what was lost;
which of the hundred processes on that machine should receive these bytes.

You could write one big program that solves everything at once. That is what people did in the 1970s, and every network turned out incompatible with the next one: a protocol for coaxial cable knew nothing about radio, and a program written for one network did not work on another.

The solution they arrived at was to split the problem into layers. Each layer solves one task from the list above, uses the services of the layer below and provides a service to the layer above. Layer N on one machine "talks" to layer N on the other and does not know how the lower layers deliver its data. The transport layer does not know whether the data travels over Wi-Fi or fibre; Wi-Fi does not know whether it carries TCP or UDP.

Two models used to describe networks grew out of this idea: OSI and TCP/IP.

The OSI model

The OSI (Open Systems Interconnection) model was published by ISO in 1984. It has seven layers, counted from the bottom up:

#	Layer	Responsible for	Unit of data	Examples
7	Application	The program's own protocol: what the transmitted data means	data, message	HTTP — the browser requests pages from a server; SMTP — servers pass mail to each other; SSH — a remote terminal; DNS — turns names into addresses (part 12)
6	Presentation	Encodings, compression, encryption of application data	data	TCP/IP has no separate protocol; TLS — encryption on top of TCP that HTTPS runs on — is loosely placed here
5	Session	Establishing and ending sessions, resuming a dialogue	data	no separate protocol: the application manages the session itself
4	Transport	Delivering data to a specific process; reliability and ordering when needed	segment (TCP), datagram (UDP)	UDP — just ports, no guarantees (part 9); TCP — with delivery, ordering and retransmission (part 10)
3	Network	Addressing machines across the whole network and choosing a path between networks	packet	IPv4 (parts 5–6), IPv6 (part 13), ICMP (part 8)
2	Data Link	Transferring data between neighbours in one segment: neighbour addresses, frames, error detection	frame	Ethernet (part 2), Wi-Fi (part 3), PPP (part 4), VLAN (part 17)
1	Physical	Bits into a signal: voltage levels, frequencies, connectors, cables	bits	twisted pair, Wi-Fi radio, optical fibre

It helps to see that each layer has its own kind of address:

Layer	Address	Answers the question
2	MAC address `3c:52:82:1a:2b:3c`	which neighbour on this cable gets the frame
3	IP address `192.168.1.10`	which machine in the world the packet is for
4	Port `443`	which process on that machine
7	Name `www.vitaliy.org`, URL	what exactly the person wants

The main thing to know about the OSI model: nobody implements it in pure form. ISO had its own set of protocols for each layer (X.400, CLNP, TP4), and it lost to TCP/IP back in the 1990s. What survived is the scheme itself — as a common language. When people say "L2 switch", "L3 switch", "L7 load balancer" or "L4 firewall", they mean the layers from exactly this table: the device looks at the headers of that layer and below and leaves everything above alone.

Layers 5 and 6 are blurry in real networks. The classic question "which layer is TLS on?" has no exact answer: it sits between transport and application, and it gets called L5, L6 and "L4.5". In practice it does not matter: all these functions live inside the application or its libraries.

The TCP/IP model

The model networks are actually built on is described in RFC 1122, and it has four layers:

TCP/IP	What is inside	OSI layers
Application	The application protocol, including encodings, sessions and TLS	7, 6, 5
Transport	TCP, UDP	4
Internet	IP, ICMP, routing	3
Link	Everything that delivers an IP packet to a neighbour: Ethernet, Wi-Fi, PPP together with the physical layer	2, 1

There is one difference from OSI: TCP/IP does not split what is indivisible in real systems anyway. The application itself decides whether to encrypt its data and how to keep a session, and the network card together with its driver is responsible for both the frames and the signal in the cable.

Throughout the series I will use OSI numbering (L2, L3, L4), because that is what everyone says, and follow TCP/IP for the structure, because that is how everything works.

Encapsulation: what a packet looks like on the wire

This is the most important idea of this article. Each layer takes data from the layer above, prepends its own header and passes it down. What ends up on the wire is a nesting doll of headers.

Take a request to a website over HTTPS. The browser handed an HTTP request to the TLS library, which encrypted it and passed the bytes into a TCP socket. Further down the stack:

                                        ┌───────────────────┐
application:                            │ TLS record (HTTP) │
                                        └───────────────────┘
                           ┌────────────┬───────────────────┐
transport (TCP):           │ TCP 20 B   │ data              │
                           │ ports,     │                   │
                           │ seq, ack   │                   │
                           └────────────┴───────────────────┘
              ┌────────────┬────────────┬───────────────────┐
network (IP): │ IPv4 20 B  │ TCP        │ data              │
              │ addresses, │            │                   │
              │ TTL, proto │            │                   │
              └────────────┴────────────┴───────────────────┘
 ┌────────────┬────────────┬────────────┬───────────────────┬───────┐
 │ Ethernet   │ IPv4       │ TCP        │ data              │ FCS   │
 │ 14 B: MAC, │            │            │                   │ 4 B   │
 │ EtherType  │            │            │                   │       │
 └────────────┴────────────┴────────────┴───────────────────┴───────┘
 ← this is what goes into the cable, left to right

The sizes here are minimal: IPv4 and TCP headers can carry options, and then they are longer than 20 bytes. For an Ethernet frame without options we get 14 + 20 + 20 + data + 4 bytes of checksum, which the network card computes.

On the receiving side the nesting doll is taken apart in reverse order, and here comes a question without which the scheme does not work: how does a layer know what is inside? Having received a frame, the network stack must figure out whether to hand its contents to IPv4, IPv6 or ARP. Having received an IP packet — to TCP, UDP or ICMP. Having received a TCP segment — to which process.

The answer: the header of every layer has a field that says what is inside. This is called demultiplexing.

Layer	Field	Values
Ethernet	EtherType (2 bytes)	`0x0800` IPv4, `0x86DD` IPv6, `0x0806` ARP, `0x8100` VLAN
IPv4 / IPv6	Protocol / Next Header (1 byte)	`1` ICMP, `6` TCP, `17` UDP, `50` ESP (an encrypted IPsec packet, part 19), `58` ICMPv6 (part 14)
TCP / UDP	destination port (2 bytes)	`443` HTTPS, `53` DNS, `22` SSH; in general — whatever a process listens on

So a network stack is essentially a chain of switch statements: read the header, look at the "what's inside" field, strip the header, hand the rest to the next handler.

Here is what this looks like in tcpdump for the first packet of a TCP connection to a web server. The -e flag asks it to show the Ethernet header too:

$ sudo tcpdump -i eth0 -n -e 'tcp port 443' -c 1
12:00:01.123456 3c:52:82:1a:2b:3c > d8:47:32:0a:0b:0c, ethertype IPv4 (0x0800), length 74:
    192.168.1.10.51234 > 203.0.113.10.443: Flags [S], seq 1234567890, win 64240,
    options [mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7], length 0

Layer by layer:

L2: a frame from MAC 3c:52:82:1a:2b:3c (my network card) to d8:47:32:0a:0b:0c (that is the router, not the server — why, in a section or two), EtherType 0x0800, meaning IPv4 inside. The frame is 74 bytes long: 14 Ethernet + 20 IPv4 + 40 TCP (20 of header and 20 of options). tcpdump does not show the checksum: the network card strips it.
L3: from 192.168.1.10 to 203.0.113.10, protocol TCP — otherwise tcpdump would not have parsed the ports.
L4: from port 51234 to port 443, flag S (SYN, the start of a connection), 0 bytes of data.

A note on the names of data units. Strictly speaking, at L2 it is a frame, at L3 a packet, at L4 a segment for TCP and a datagram for UDP. In conversation everything is called a packet, and I will do the same when the layer does not matter. When it does, I will say "frame" or "segment".

Who handles what along the way

The packet from the example above will travel roughly this path:

laptop ──► switch ──► home router ──► ISP router ──► … ──► server
 L1–L7       L2           L3              L3                L1–L7

Each device on the way unpacks the nesting doll only down to its own layer:

A switch reads the Ethernet header, picks a port by the destination MAC address and sends the frame there without changing a single byte. Whatever is inside — IPv4, IPv6, ARP — it does not care. This is an L2 device.
A router strips the Ethernet header entirely, reads the IP header, uses the destination address to find the next router (next hop) in its routing table, decrements TTL by one, recomputes the IP header checksum and wraps the packet into a new frame: with its own MAC address as the source and the next router's MAC address as the destination. If the next interface is not Ethernet but, say, PPPoE (part 4) or a cellular network, the packet leaves in a frame of a completely different format. The IP packet does not care. This is an L3 device.
The server unpacks everything up to the application.

Hence the table of what changes along the way:

What	Does it change
MAC addresses in the frame	new ones on every hop between routers
IP addresses	do not change from sender to receiver (the exception is NAT, part 6)
TTL in the IP header	minus one at every router
TCP header and data	untouched (the exceptions are NAT and firewalls, also part 6)

Now it is clear why in tcpdump the frame went to the router's MAC rather than the server's: a MAC address is the address of a neighbour on this cable, an IP address is the address of the final recipient. The laptop knows that 203.0.113.10 is not on its network, so the frame has to be handed to the router, and the router will figure out the rest. How the laptop learns the router's MAC is the subject of part 7 on ARP; how it decides that an address is "not on its network" is part 5.

This also answers the question every beginner asks: why two addresses if there is IP? Because they are about different things. An IP address is global and independent of the transmission medium; a MAC address lives within one Ethernet segment and knows nothing about networks beyond the router. Wi-Fi has MAC addresses, PPP has none at all, and IP runs over both.

Why layer independence matters and where it leaks

Unplug the cable and turn on Wi-Fi: the IP address may stay the same, and TCP connections will certainly not notice the change of medium (if the address did not change). Swap TCP for UDP: Ethernet will not notice. That is the payoff of layers: over forty years several generations of physical media have come and gone, from coax to 400-gigabit fibre, and the IP packet of 1981 is the same in all of them.

But the abstraction is not absolute, and most of the "interesting" network problems live where it leaks:

MTU. The size of an L2 frame limits the size of an L3 packet: in Ethernet it is 1500 bytes. A larger packet must either be cut up (fragmentation) or the limit must be learned in advance (Path MTU Discovery). More on this in parts 6 and 8; the "ping works but the site won't open" symptom grows right out of this.
NAT. A home router, an L3 device, rewrites addresses in the IP header and ports in the TCP/UDP header, that is, it reaches into the layer above its own. Part 6.
Firewalls and load balancers make decisions based on ports and even HTTP content, even though they sit in the middle of the network.
Wi-Fi retransmits frames lost on the radio, and TCP on top of it sees not losses but strange delays. Part 3.

Understanding that layers are independent by design but coupled in practice is half of the skill of troubleshooting network problems.

Seeing it for yourself

On any Linux machine the layers are visible right in the commands. Each command shows its own floor.

The link layer — interfaces and their MAC addresses:

$ ip link
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 3c:52:82:1a:2b:3c brd ff:ff:ff:ff:ff:ff

The network layer — IP addresses and the routing table the stack uses to decide whom to hand a packet to:

$ ip addr show eth0
    inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic eth0

$ ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

The transport layer — who listens on which ports:

$ ss -tlnp
State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
LISTEN  0       128           0.0.0.0:22          0.0.0.0:*      users:(("sshd",pid=812,fd=3))

And everything at once — tcpdump. Run it in one window and open any website in another:

$ sudo tcpdump -i eth0 -n -e -c 20

The flags: -i — the interface, -n — do not turn addresses into names (otherwise tcpdump will go to DNS itself and clutter the output), -e — show the Ethernet header, -c — how many packets to capture.

Wireshark is even clearer. Capture a file with the same tcpdump -w capture.pcap or start a capture in Wireshark itself, open it and click any packet. The middle pane is exactly our nesting doll, layer by layer:

▸ Frame 1: 74 bytes on wire
▸ Ethernet II, Src: 3c:52:82:1a:2b:3c, Dst: d8:47:32:0a:0b:0c
▸ Internet Protocol Version 4, Src: 192.168.1.10, Dst: 203.0.113.10
▸ Transmission Control Protocol, Src Port: 51234, Dst Port: 443, Seq: 0, Len: 0

Expand each layer: it holds all the header fields with their values, and the bottom pane highlights the bytes they correspond to. In every following part of the series we will look at headers exactly this way.

Key takeaways

The network stack is split into layers; each solves one task and uses the layer below it. OSI is a seven-layer model that serves as a language (L2, L3, L7); TCP/IP is a four-layer model of how things are actually built.
Each layer adds its own header; on the wire there is a nesting doll Ethernet → IP → TCP/UDP → data.
Every header has a "what's inside" field: EtherType, Protocol, port. The receiving side uses them to unpack the nesting doll.
A switch looks at L2, a router at L3, end hosts at everything. MAC addresses change on every hop, IP addresses go all the way.
The layer abstraction leaks: MTU, NAT, firewalls. That is where the most interesting problems live.

Next — Part 2: Ethernet: the frame format byte by byte, how a MAC address is structured, what a switch really does, why the minimum frame is 64 bytes, and what a duplex mismatch is.