Networking
Intermediate 15 min read Networking

TCP/IP & the OSI Model

The TCP/IP protocol stack governs how applications talk across networks. Master the OSI model, encapsulation, the TCP three-way handshake, and the TCP versus UDP trade-off.

OSITCPUDPthree-way handshakeencapsulationportsRFC 9293
Prerequisites: Networking Fundamentals
Introduction

What is this?

TCP/IP is the suite of protocols that powers the internet. The OSI model describes networking in seven conceptual layers, and the TCP/IP model collapses them into four. TCP provides reliable, ordered, connection-oriented delivery on top of IP; UDP provides simple best-effort delivery without connections.

Motivation

Why do you need it?

  • The TCP three-way handshake is one of the most common interview questions in networking.
  • Choosing TCP or UDP changes reliability, ordering and latency — a fundamental design decision.
  • Encapsulation explains why you can put HTTP over TCP over IP over Ethernet and add layers like TLS and tunnels.
  • Every port, connection and packet capture you will ever read maps back to this stack.
Think about it

Mental model

Imagine

Registered mail with tracking

Think of

TCP connections

Registered mail requires a handshake at the post office, gives each letter a number so none is lost, and reorders everything correctly. UDP is a postcard dropped in the mailbox — cheap and fast, but no guarantee it arrives or arrives in order.

Mechanics

How it works

  • The application sends data to the transport layer, where TCP (RFC 9293) establishes a connection with a three-way handshake: SYN, SYN-ACK, ACK.
  • TCP numbers every byte and acknowledges received segments so lost data is retransmitted and reordered.
  • IP (RFC 791) wraps each TCP segment in a packet with source and destination addresses and routes it hop by hop.
  • The link layer frames the packet for the physical medium — Ethernet on wired LANs, Wi-Fi on wireless.
  • The receiver unwraps each layer (de-encapsulation) and delivers the stream to the application, connection intact.

The TCP three-way handshake and connection teardown.

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK
Data exchange
FIN → ACK, FIN → ACK
Reference

Key commands

ss -tn

List active TCP connections and their states (ESTAB, TIME-WAIT, etc.).

sudo tcpdump -i eth0 tcp port 443

Capture TCP traffic on port 443 for live protocol inspection.

nc -vz example.com 443

Open a TCP connection to a port and report whether the handshake succeeded.

curl -v https://example.com

Show TLS and HTTP details; useful when tracing the full stack.

ss -tulpn

Show listening TCP/UDP sockets with the owning process.

Hands-on

Examples

Watch the handshake with tcpdump

Watch the handshake with tcpdump
# terminal 1 — capture only the handshake on port 443
$ sudo tcpdump -i any 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-fin) != 0)' -nn
# terminal 2 — trigger a connection
$ curl -s https://example.com > /dev/null
 
15:04:05.123456 IP 10.0.1.5.52341 > 93.184.216.34.443: Flags [S], seq 3618284732
15:04:05.134567 IP 93.184.216.34.443 > 10.0.1.5.52341: Flags [S.], seq 1902208767, ack 3618284733
15:04:05.134589 IP 10.0.1.5.52341 > 93.184.216.34.443: Flags [.], ack 1902208768

tcpdump shows the exact handshake: a SYN with an initial sequence number, the server's SYN-ACK that acknowledges it, and a final ACK. From then on both sides can send data.

Real world

In production

  • Load balancers and service meshes tune TCP timeouts, keepalives and window sizes for latency-sensitive traffic.
  • TIME-WAIT port exhaustion under high connection churn is a classic production issue solvable with keepalives and connection reuse.
  • TCP backlogs and accept queues (ss -lnt) surface when a service cannot keep up with connection rate.
  • UDP is the right call for real-time media, DNS and game traffic where freshness beats reliability.
Guidelines

Best practices

  • Reuse connections (HTTP keep-alive) instead of opening a new TCP handshake per request.
  • Tune sysctls like tcp_keepalive_time and net.core.somaxconn deliberately, never blindly.
  • Terminate TCP at your load balancer or edge to keep backend connections pooled and warm.
  • Capture traffic on loopback and eth0 to separate app-internal from host-network issues.
Watch out

Common mistakes

  • Confusing TCP states: TIME-WAIT is normal and brief, not a leak.
  • Blocking UDP in a firewall and then wondering why DNS or VPNs break.
  • Forgetting the two-minute TIME-WAIT when load testing a single client to a server with many connections.
  • Assuming TCP guarantees exactly-once delivery — it guarantees reliability and ordering, not de-duplication.
Root cause analysis

Common issues

Error
Connection timed out during handshake
Root cause

SYN sent but never answered — firewall drops inbound, or the server is overloaded.

Fix

Run tcpdump on the server to see if the SYN arrives; check firewall rules and the listen backlog.

Error
Connection reset by peer (RST)
Root cause

A host actively rejected the connection — often no listener or an active firewall rejection.

Fix

Confirm the service listens (ss -tulpn), and check for iptables REJECT rules versus DROP.

Error
Too many TIME-WAIT connections
Root cause

Client-initiated short-lived connections exhausting ephemeral ports under load.

Fix

Enable keep-alive/connection reuse on the client, or raise net.ipv4.ip_local_port_range.

When things break

Debugging tips

  • ss -tn state ESTAB to spot connections stuck mid-handshake.
  • tcpdump -nn to bypass name resolution and see raw IPs and ports.
  • ss -s for a quick TCP socket summary including TIME-WAIT counts.
  • Compare SYN sent (ss) with SYN received on the server to find where the handshake stalls.
Interviews

Interview checkpoint

Practice

Hands-on lab

Capture the TCP Three-Way Handshake
30 min · intermediate
In progress
Objectives
  • Install and use tcpdump
  • Observe a real SYN, SYN-ACK, ACK handshake
  • Read TCP flags and sequence numbers
  • Verify a TCP port with nc

Capture the TCP Three-Way Handshake

30 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

What is the correct order of the TCP three-way handshake?

2

UDP provides guaranteed delivery and ordering.

3

Which of these is NOT one of the seven OSI layers?

Quick reference

Cheat sheet

The four TCP/IP layers
ApplicationHTTP, DNS, SSH, TLS — the protocols you code against
TransportTCP (reliable) and UDP (best-effort) + ports
InternetIP routing and addressing
LinkEthernet, Wi-Fi frames on the wire
TCP connection states
SYN_SENTClient sent SYN, waiting for SYN-ACK
ESTABConnection established and exchanging data
FIN_WAIT / CLOSE_WAITTeardown in progress on one side
TIME-WAITShort pause before the port is fully freed
Go deeper

Official documentation

Transmission Control Protocol — RFC 9293
rfc
User Datagram Protocol — RFC 768
rfc
Host Requirements — RFC 1122
rfc
tcpdump man page
docs