Computer Networking Cheatsheet

TCP and UDP

Use this Computer Networking reference while you build software engineering projects, review code, or refresh the syntax you reach for most.

TCP vs UDP

TCPUDP
IP protocol number617
Connectionhandshake firstnone, fire and forget
Header size20-60 bytes8 bytes
Orderingguaranteed by sequence numbernone
Retransmissionyes, on loss or timeoutnone, the app must handle it
Flow controlreceive windownone
Congestion controlyes (Reno, CUBIC, BBR)none by default
Checksummandatoryoptional in IPv4, mandatory in IPv6
Broadcast · multicastnoyes
Head-of-line blockingyesno
Used byHTTP/1.1 and /2, SSH, SMTP, TLSDNS, DHCP, NTP, QUIC, VoIP, games

Pick TCP when every byte must arrive in order. Pick UDP when late data is worthless (live audio) or when you are building your own reliability on top, as QUIC does.

TCP header and flags

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|         Source Port           |      Destination Port         |
+---------------------------------------------------------------+
|                    Sequence Number                            |
+---------------------------------------------------------------+
|                 Acknowledgment Number                         |
+-------+-----------+-----------+-------------------------------+
| Offs  |  Reserved |   Flags   |            Window             |
+-------+-----------+-----------+-------------------------------+
|          Checksum             |        Urgent Pointer         |
+-------------------------------+-------------------------------+
|                   Options (0-40 bytes)                        |
+---------------------------------------------------------------+
FlagNameMeaning
SYNsynchronizeopen a connection, carries the initial sequence number
ACKacknowledgethe ack field is valid, set on all but the first SYN
FINfinishno more data from this sender, graceful close
RSTresetabort now, no port listening or state is gone
PSHpushdeliver to the app immediately, do not buffer
URGurgenturgent pointer valid, effectively unused
ECE / CWRECNexplicit congestion notification signalling

Three-way handshake

client                                     server
  |  SYN  seq=x, mss, wscale, sackok         |   CLOSED → LISTEN
  |----------------------------------------->|   SYN_RECEIVED
  |  SYN, ACK  seq=y, ack=x+1                |
  |<-----------------------------------------|
  |  ACK  seq=x+1, ack=y+1                   |
  |----------------------------------------->|   ESTABLISHED

Costs one round trip before any data moves, which is why TLS 1.3 over TCP needs 2 RTT to first byte and QUIC needs 1. TCP Fast Open can carry data in the SYN, and options negotiated in the handshake (MSS, window scaling, SACK, timestamps) cannot be changed later.

Teardown, TIME_WAIT, and RST

Graceful close is four packets, because each direction closes independently.

  |  FIN, ACK   |------>|   active closer → FIN_WAIT_1
  |  ACK        |<------|   passive → CLOSE_WAIT
  |  FIN, ACK   |<------|   passive → LAST_ACK
  |  ACK        |------>|   active → TIME_WAIT (2×MSL, 60 s on Linux)
StateWho holds itWhat it means
SYN_SENTclientSYN out, nothing back yet
SYN_RECVserverhalf-open, piles up under SYN flood
ESTABLISHEDbothdata flowing
FIN_WAIT_1 / _2active closerwaiting on the peer's FIN
CLOSE_WAITpassive closerapp has not called close(), a code bug
LAST_ACKpassive closerits FIN is out
TIME_WAITactive closer60 s guard against stale duplicates

Many CLOSE_WAIT sockets means your application leaks file descriptors. Many TIME_WAIT is normal on a busy client and only a problem when it exhausts the ephemeral port range.

A RST instead of a handshake means nothing is listening on that port, which is why ECONNREFUSED is instant while a filtered (dropped) port hangs until timeout.

Ports, ephemeral range, and well-known numbers

Ports are 16 bit, so 0-65535. IANA splits them into well-known (0-1023, needs root on Unix), registered (1024-49151), and dynamic (49152-65535).

PortServiceL4
20, 21FTP data, controlTCP
22SSH, SCP, SFTPTCP
25SMTPTCP
53DNSUDP and TCP
67, 68DHCP server, clientUDP
80HTTPTCP
123NTPUDP
143, 993IMAP, IMAPSTCP
161SNMPUDP
389, 636LDAP, LDAPSTCP
443HTTPS, HTTP/3 (QUIC)TCP and UDP
587SMTP submissionTCP
3306MySQLTCP
3389RDPTCP
5432PostgreSQLTCP
6379RedisTCP
27017MongoDBTCP
cat /proc/sys/net/ipv4/ip_local_port_range   # ephemeral range, 32768 60999
ss -tan state established | wc -l
ss -tulpn                                    # listening TCP and UDP with PIDs

A single client IP to a single server IP and port is capped by the ephemeral range, roughly 28,000 concurrent connections, because the 4-tuple must be unique.

Windows, congestion control, and the numbers that matter

Receive window is flow control (do not overrun the receiver). Congestion window is congestion control (do not overrun the network). The sender is limited by whichever is smaller.

Throughput on a lossless path is bounded by the bandwidth-delay product:

max in flight = bandwidth × RTT
1 Gbit/s × 80 ms = 10 MB must be in flight to fill the pipe

Window scaling (RFC 7323) is required above 64 KB, and it is negotiated only in the SYN. Middleboxes that strip the option cap you at 64 KB per RTT, which looks like a slow link on a fast one.

AlgorithmSignal it reacts toWhere it shines
Reno / NewRenopacket losshistorical baseline
CUBICloss, cubic growthLinux default, high BDP
BBRmeasured bandwidth and RTTlossy or buffer-bloated paths
sysctl net.ipv4.tcp_congestion_control
sysctl -w net.ipv4.tcp_congestion_control=bbr
ss -ti                    # per-socket rtt, cwnd, retrans, pacing rate
nstat -az | grep -i retrans