Mastering Network Fundamentals: From OSI Layers to TCP/IP Handshakes

In distributed service‑oriented architectures, communication between services relies on underlying network protocols, so a solid grasp of network fundamentals is essential for troubleshooting and designing reliable inter‑process communication.

Communication Protocols

What Is a Protocol?

A protocol is a pre‑agreed set of rules that enables computers from different vendors, CPUs, or operating systems to exchange data over a network.

Packet‑Switching Protocol

Packet Switching

When transmitting large data, it is divided into multiple packet‑sized blocks called packets.

Network Data Packet

A data packet (or frame) consists of a header (control information) and a payload (user data). The header contains source and destination IP addresses, sequence numbers, and other routing information.

A complete packet includes:

Routing addresses (source and destination)

Error detection and correction (parity bits or CRC)

TTL (time‑to‑live) hop limit

Packet length

Priority

Payload (actual data)

Protocol Stack and Network Layer Model

Protocol Stack

Protocol Stack (Network Stack)

A protocol stack is a set of cooperating network‑layer protocols. The OSI model defines seven layers, while the TCP/IP suite defines a stack that is implemented in operating systems as the IP stack, providing socket APIs for TCP, UDP, etc.

Load stack – load the software required for a specific protocol set.

Bind stack – bind a set of protocols to a network interface (INC).

Meaning of IP Stack

The IP stack offers a library for creating, managing, and closing connections and for sending/receiving data via TCP or UDP sockets.

Network Layer Model

Protocol Stack and OSI Seven‑Layer Model

In the OSI model, the application, presentation, and session layers transmit the payload; the transport layer uses segments; the network layer uses packets; the data‑link layer uses frames; and the physical layer transmits bits.

Each layer communicates with the adjacent layer through a defined interface, and each layer has its own protocol suite.

TCP/IP Protocol Transmission Process

The client sends payload to the application, which forwards it to the TCP/UDP transport layer, adding source and destination ports.

The transport layer adds its header and passes the segment to the IP layer, which adds source and destination IP addresses.

The IP layer forwards the packet to the data‑link layer, which adds source and destination MAC addresses, then the physical layer transmits the bits.

Handshake Protocol

TCP Three‑Way Handshake

Three‑Way Handshake

Client sends SYN with initial sequence number (ISN) x.

Server replies with SYN‑ACK, its own ISN y, and acknowledges x+1.

Client sends ACK acknowledging y+1, completing the connection.

Reason for Three‑Way Handshake

First handshake verifies client can send and server can receive.

Second handshake verifies server can send and client can receive.

Third handshake confirms both sides can exchange data.

Half‑Connection and Full‑Connection Queues

Half‑Connection Queue

When the server receives the initial SYN, it stores the request in the half‑connection queue until the handshake completes.

Full‑Connection Queue

After the handshake, established connections are placed in the full‑connection queue; if it overflows, packets are dropped.

SYN Attack (DoS/DDoS)

A SYN attack floods the server with forged SYN packets from non‑existent IPs, exhausting the half‑connection queue and causing denial of service.

Typical investigation command: netstat -n -p TCP | grep SYN_RECV Mitigation measures include shortening SYN timeout, increasing the half‑connection limit, firewall filtering, and SYN cookies.

TCP Four‑Way Termination

Four‑Way Termination Process

Client sends FIN with sequence number u.

Server acknowledges FIN (ACK u+1) and sends its own FIN with sequence v.

Client acknowledges server’s FIN (ACK v+1).

Both sides enter CLOSED state after waiting for any remaining data.

Reason for Four‑Way Termination

The server must ensure all pending data is processed before fully closing the connection.

Sliding Window and Congestion Control

Sliding Window

Why TCP Needs a Sliding Window

Without a sliding window, each packet must wait for an ACK before the next is sent, severely limiting throughput. The sliding window allows multiple packets to be in flight, improving latency and throughput.

Timeout‑based retransmission still applies; if the receiver acknowledges duplicate ACKs, fast retransmission is triggered.

Congestion Control

TCP uses a congestion window that starts at 1 segment and grows with each ACK (slow start). The effective sending window is the minimum of the congestion window and the receiver’s advertised window.

Packet Sticking and Splitting (粘包与拆包)

When custom protocols delimit messages only by special characters (e.g., newline), the receiver may read concatenated messages (sticking) or incomplete fragments (splitting).

// Code demonstration
String m1 = "this is the first msg";
String m2 = "this is the second msg";
client.send(m1);
client.send(m2);
while (true) {
    String msg = server.read();
    log.info("msg=" + msg);
}
// Result: msg=this is the first msgthis is the second msg

Solutions in Netty include:

LineBasedFrameDecoder – split on newline.

DelimiterBasedFrameDecoder – split on custom delimiters.

FixedLengthFrameDecoder – split by fixed length.

HTTP Protocol

Brief Overview

Client‑server communication via request/response.

Stateless; state is maintained via cookies and sessions.

URI identifies remote resources.

Supports methods such as GET, POST, PUT, DELETE, PATCH.

Short‑lived connections, but can use keep‑alive for persistence.

Pipeline technique allows multiple requests without waiting for each response.

Example request:

curl -v https://www.baidu.com
GET / HTTP/1.1   # request line (method + HTTP version)
Host: www.baidu.com
User-Agent: curl/7.54.0
Accept: */*

Example response:

curl -i https://www.baidu.com
HTTP/1.1 200 OK   # status line (HTTP version + status code)
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 2443
Content-Type: text/html
... (headers) ...
<!DOCTYPE html>
<html> ... </html>

Common HTTP Headers

General: Cache-Control, Pragma, Transfer-Encoding, Via, Warning.

Request: Accept, Accept-Charset, Accept-Encoding, Authorization, Referer.

Response: Location (for 302), WWW-Authenticate (for 401).

Entity: Allow, Content-Length, Content-Range.

Cache: Cache-Control directives (no-store, no-cache, private, public, max-age, must-revalidate), ETag, Last-Modified.

Other: X-Frame-Options, X-XSS-Protection.

Common HTTP Status Codes

2xx – success (200 OK, 204 No Content, 206 Partial Content).

3xx – redirection (301 Moved Permanently, 302 Found, 304 Not Modified).

4xx – client errors (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).

5xx – server errors (500 Internal Server Error, 503 Service Unavailable).

HTTPS Protocol

Difference Between HTTP and HTTPS

HTTPS adds an SSL/TLS layer on top of HTTP, encrypting the data exchanged between client and server.

HTTPS Handshake Process

Client initiates TCP three‑way handshake, then sends TLS version, client random, cipher suite, and session ID.

Server replies with TLS version, server random, chosen cipher suite, and its certificate.

Client validates the certificate, generates a pre‑master secret, encrypts it with the server’s public key, and sends it.

Server decrypts the pre‑master secret with its private key, derives the session key, and both sides verify handshake hashes.

Subsequent communication uses the derived symmetric session key for encryption.

Thank you for reading; feel free to share if you found this useful.