Transport: TCP and UDP

Updated

September 4, 2026

Transport: TCP and UDP

The transport layer delivers data to the correct process on a host using ports, with different reliability and connection models.

Learning goals

  • Explain 5-tuples and port roles
  • Contrast TCP and UDP services
  • Read basic TCP handshake and teardown signals
  • Use ss to inspect listeners and connections

Ports and sockets

  • Port: 16-bit number (0–65535)
  • Well-known ports (e.g. 22 SSH, 53 DNS, 80 HTTP) vs ephemeral client ports
  • Socket: local address + port (+ protocol), often with peer

5-tuple: protocol, src IP, src port, dst IP, dst port — identifies a conversation.

ss -tulpn
ss -tan
ss -uan

UDP

Property UDP
Connection None
Reliability None (app may add)
Ordering Not guaranteed
Header Lightweight
Use cases DNS, DHCP, many tunnels, telemetry, real-time 
# one-shot listener / client ideas
nc -u -l -p 9999
nc -u <peer> 9999

TCP

Property TCP
Connection Yes (stateful)
Reliability Ack, retransmit
Ordering Byte stream reassembly
Flow / congestion control Yes
Use cases SSH, HTTP, BGP, config APIs

Three-way handshake (must know)

  1. Client → Server: SYN
  2. Server → Client: SYN-ACK
  3. Client → Server: ACK

Then data can flow. Teardown uses FIN/ACK (or RST for abort).

tcpdump -ni eth1 'tcp port 22'

States (operator view)

State Meaning
LISTEN Waiting for connections
SYN-SENT / SYN-RECV Handshake in progress
ESTABLISHED Data transfer
TIME-WAIT Waiting to be sure old segments die
CLOSE-WAIT / FIN-WAIT Teardown in progress

TCP vs UDP selection

Need Prefer
Reliable byte stream TCP
Simple request/response, app handles loss UDP
Multicast / lightweight tunnel outer Often UDP
Head-of-line sensitivity Design carefully (HTTP/2 vs QUIC later topics)

NAT and transports (preview)

NATS track transport state (especially TCP). UDP mappings time out differently. Edge/NAT chapter expands this.

Security basics

  • Do not expose admin TCP ports to untrusted networks without policy
  • Spoofing and scan noise are normal on open nets
  • TLS usually rides on TCP (or QUIC on UDP)—app layer crypto

TCP state machine (operator view)

CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT_* → TIME_WAIT → CLOSED
              ↘ (listen) LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED
State you see (ss / netstat) Meaning
LISTEN Server bound, waiting for SYN
ESTAB / ESTABLISHED Data can flow
TIME-WAIT Local side closed; holding tuple so delayed segments die (normal after busy services)
CLOSE-WAIT Peer closed; your app must close its side (often a bug if stuck)
SYN-SENT Client waiting for SYN-ACK (firewall/blackhole if stuck)

Flow control vs congestion control: window advertisements limit receiver buffer pressure; congestion control (slow start, Reno/CUBIC, …) limits network load. Both shrink effective throughput; do not “tune sysctls” before measuring.

UDP: no handshake, no stream—each datagram is independent. Good for DNS, DHCP, QUIC’s outer path, and lab pings of custom apps. Reliability, if needed, is your application’s job.

Three-way handshake and teardown (why captures look busy)

  1. Client → Server: SYN (seq=c)
  2. Server → Client: SYN-ACK (seq=s, ack=c+1)
  3. Client → Server: ACK (ack=s+1)

Teardown is often four segments (FIN/ACK each way) or RST on abort. In labs, filter tcp.flags.syn==1 or tcp.flags.fin==1 or tcp.flags.reset==1 in Wireshark/tshark to see only control.

Lab sketch

  1. ss -tulpn on a node before/after starting SSH
  2. Capture handshake for SSH (tcpdump -ni any port 22)
  3. nc UDP echo between two lab hosts
  4. Force a stuck CLOSE-WAIT by killing only one side of a netcat TCP session; observe with ss -tan
  5. Note TIME-WAIT count after many short connections (ss -tan state time-wait | wc -l)

Checkpoint

A client opens HTTPS to a server. Name protocol numbers/fields for: Ethernet type, IP protocol, TCP ports (client ephemeral + 443), and where TLS sits.

Next