Understanding Linux Network Stack: From OSI Model to Real‑World Commands

Network Model

Multiple servers connect via NICs, switches, routers, forming a network. Because of device heterogeneity and protocol complexity, the ISO defined a seven‑layer OSI model, but in practice the more usable TCP/IP model is used.

In the early days of computer networking, vendors introduced various architectures; the ISO created the Open System Interconnection Reference Model (OSI) to unify standards.

Layered networking solves complexity; different devices need a common data format, which leads to network protocols.

The OSI model divides networking into seven layers—Application, Presentation, Session, Transport, Network, Data Link, and Physical—each handling distinct functions.

Application layer: provides a unified interface for applications.

Presentation layer: converts data to a format compatible with the receiving system.

Session layer: maintains communication connections between computers.

Transport layer: adds transport headers to form packets.

Network layer: handles routing and forwarding.

Data Link layer: manages MAC addressing, error detection, and correction.

Physical layer: transmits data frames over the physical medium.

Because the OSI model is too complex, Linux actually uses a more practical four‑layer TCP/IP model.

The TCP/IP model consists of Application, Transport, Network, and Network Interface layers.

Application layer: provides services such as HTTP, FTP, DNS.

Transport layer: provides end‑to‑end communication (TCP, UDP).

Network layer: handles packet encapsulation, addressing, and routing (IP, ICMP).

Network Interface layer: manages physical transmission, MAC addressing, error detection, and framing.

Although Linux implements the network protocol stack according to the TCP/IP model, the OSI seven‑layer model is still commonly used for description.

Linux Network Stack

When a packet is transmitted, each layer of the stack processes the data from the upper layer, adds its own header, and passes it down.

For example, a REST API application uses HTTP to wrap JSON data before handing it to the TCP layer.

Encapsulation simply adds fixed‑format metadata before and after the original payload without modifying it.

Key points:

Transport layer adds a TCP header.

Network layer adds an IP header.

Network Interface layer adds frame header and trailer.

These headers increase packet size; the MTU (default 1500 bytes for Ethernet) limits the maximum IP packet size. If a packet exceeds the MTU, the network layer fragments it.

[root@dev ~]# ifconfig
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.0.1  netmask 255.255.255.0  broadcast 10.244.0.255
        ...
[root@dev ~]# ip -s addr show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
        inet 192.168.2.129/24 brd 192.168.2.255 scope global noprefixroute ens33
        ...

Linux’s network stack mirrors the TCP/IP four‑layer structure, as shown in the diagram below.

From top to bottom:

Applications interact with the kernel via socket system calls.

Sockets sit above the transport, network, and network‑interface layers.

At the bottom are NIC drivers and the physical network device.

Linux Packet Receive Flow

The NIC receives a frame, DMA‑writes it to the receive queue, and triggers a hardware interrupt.

The interrupt handler allocates an sk_buff, copies the frame into it, and raises a soft interrupt.

The kernel stack processes the frame layer by layer: the link layer validates the frame and determines the protocol (IPv4/IPv6), strips the frame header/trailer, then passes the packet to the network layer.

The network layer extracts the IP header, decides whether to forward or deliver locally, removes the IP header, and hands the payload to the transport layer.

The transport layer extracts the TCP/UDP header, uses the 4‑tuple to locate the corresponding socket, and copies data into the socket’s receive buffer.

The application reads the data via the socket API.

Linux Packet Send Flow

The application calls a socket API (e.g., sendmsg), which places data into the socket’s send buffer.

The stack then processes the data upward to downward, adding TCP and IP headers, performing routing, and fragmenting if necessary.

After fragmentation, the packet reaches the network‑interface layer, where MAC addressing is performed, a frame header/trailer is added, and the packet is queued for transmission.

A soft interrupt notifies the driver, which DMA‑reads the frame and transmits it via the NIC.

Common Network Commands

Use ifconfig or ip to view interface configuration and status.

# ifconfig ens33
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.129  netmask 255.255.255.0  broadcast 192.168.2.255
        ...
# ip -s addr show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
        inet 192.168.2.129/24 brd 192.168.2.255 scope global noprefixroute ens33
        RX: bytes  packets  errors  dropped  overrun  mcast
        24877      279      0       0        0        0
        TX: bytes  packets  errors  dropped  carrier  collsns
        24616      123      0       0        0        0

Key fields to monitor:

Interface state flags (e.g., RUNNING or LOWER_UP) indicate link connectivity.

MTU size (default 1500 bytes) may need adjustment for overlay networks.

IP address, subnet, and MAC address must be correct.

RX/TX byte and packet counters, plus error, dropped, overrun, carrier, and collision metrics, reveal problems when non‑zero.

Socket Information

Sockets are the kernel‑user interface for network programs; all TCP/IP functionality is exposed through them.

Use netstat or ss to view socket, stack, and routing details. ss is faster.

# netstat -nlp | head -n 4
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address   State   PID/Program name
tcp        0      0 0.0.0.0:22        0.0.0.0:*        LISTEN  952/sshd
tcp        0      0 127.0.0.1:25      0.0.0.0:*        LISTEN  11/master
# ss -ltnp | head -n 4

When a socket is ESTABLISHED :

Recv‑Q shows bytes not yet read by the application.

Send‑Q shows bytes not yet acknowledged by the peer.

When a socket is LISTENING :

Recv‑Q is the length of the pending connection queue.

Send‑Q is the maximum length of that queue.

Full connections are those that have completed the TCP three‑way handshake; they must be accepted via accept() before the server processes them. Half‑open connections are those that have only received the SYN and are awaiting completion.

Connection Statistics

# netstat -s
...Tcp:
    1898 active connections openings
    1502 passive connection openings
    24 failed connection attempts
    1304 connection resets received
    178 connections established
    133459 segments received
    133428 segments sent out
    22 segments retransmitted
    0 bad segments received.
    1400 resets sent
...
# ss -s
Total: 1700 (kernel 2499)
TCP:   340 (estab 178, closed 144, orphaned 0, synrecv 0, timewait 134/0), ports 0

Connectivity and Latency

Use ping (ICMP) to test reachability and round‑trip time.

# ping -c3 192.168.2.129
PING 192.168.2.129 (192.168.2.129) 56(84) bytes of data.
64 bytes from 192.168.2.129: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 192.168.2.129: icmp_seq=2 ttl=64 time=0.016 ms
64 bytes from 192.168.2.129: icmp_seq=3 ttl=64 time=0.015 ms
--- 192.168.2.129 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.015/0.019/0.026/0.005 ms

The output shows three packets sent and received with no loss; the average RTT is 0.026 ms, indicating a healthy connection.