Computer Networks cheat sheet

A scannable Computer Networks reference: 30 short snippets across 14 topics, each linking back to the lesson it came from.

At a glance

Topic	What it covers
Layered models and TCP/IP	A network stack is a stack of promises. Each layer provides a service to the layer above and hides how that service is	lesson
HTTP and DNS in practice	Three consequences follow directly from that design. Answers are cached for their TTL, so a change is not visible	lesson
One page request, end to end	Reading the deltas rather than the totals tells you which team owns the problem. If time_connect minus time_namelookup	lesson
IP addressing, CIDR and subnetting	An IPv4 address is 32 bits written as four decimal octets. The address alone says nothing about which part is the	lesson
Ports, sockets and the client-server model	A port is not a channel; it is a demultiplexing key. The kernel identifies a connection by four values: source address	lesson
TCP in depth: handshake, windows and congestion control	Two different limits apply. Flow control protects the receiver's buffer with an advertised window; congestion control	lesson
UDP, QUIC and choosing reliability	UDP adds ports and a checksum to IP and nothing else. There is no handshake, no ordering, no retransmission and no	lesson
TLS and HTTPS: certificates and the handshake	A self-signed certificate fails step 1 unless it is explicitly added to the trust store. That is the whole difference	lesson
DNS deep dive: zones, records and DNSSEC	A DNS change does not propagate anywhere. It is simply not visible until the caches that hold the old answer expire	lesson
Routing, NAT and gateways	A router matches the destination against its forwarding table and picks the most specific route. Only if nothing	lesson
Network debugging toolkit	ping and mtr for reachability, dig for names, curl -v and openssl s_client for HTTP and TLS, ss for sockets, and	lesson
Proxies, load balancers and CDNs	Trust only the forwarded headers that come from your own edge. A client can send X-Forwarded-For itself, so an origin	lesson
Wireless, mobile and the last mile	When a device moves between networks, its address changes. Any connection bound to the old four-tuple breaks, which is	lesson
Network security: eavesdropping, MITM and DDoS	On a shared segment, a host can often see traffic not addressed to it. ARP has no authentication, so an attacker can	lesson

Quick snippets

Layered models and TCP/IP

Encapsulation in practice

# on Linux: watch a real request get wrapped, layer by layer
sudo tcpdump -n -i any 'tcp port 443 and host example.com'

# what a captured GET / looks like, from the inside out:
GET / HTTP/1.1
Host: example.com                 <- application data (layer 7)
  TCP: sport 51422 dport 443, seq/ack, SYN|ACK|PSH flags   <- layer 4
    IP: 10.0.0.7 -> 93.184.216.34, TTL 64, proto 6         <- layer 3
      Ethernet: src/dst MAC, ethertype 0x0800              <- layer 2
        ...bits on the wire                                <- layer 1

Full lesson: Layered models and TCP/IP →

HTTP and DNS in practice

DNS records that matter

dig example.com A +short
dig example.com MX
dig @1.1.1.1 example.com ANY

# follow the whole delegation chain from the root
dig +trace www.example.com

# check how long a resolver may cache the answer
dig example.com | grep -A1 "ANSWER SECTION"

HTTP versions on the wire

# which protocol did the server actually negotiate?
curl -sS -o /dev/null -w '%{http_version}\n' https://example.com

# HTTP/2 only if the server advertises it over TLS (ALPN)
curl -sSI https://example.com | head -1

Full lesson: HTTP and DNS in practice →

One page request, end to end

Measuring where the time goes

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Full lesson: One page request, end to end →

IP addressing, CIDR and subnetting

Four bytes, one dotted string

192.168.1.130/24

192       .168      .1        .130
11000000  .10101000  .00000001 .10000010

/24 means the first 24 bits are the network:
network  192.168.1.0
hosts    192.168.1.1 .. 192.168.1.254
broadcast 192.168.1.255

IPv6 in one section

2001:0db8:0000:0000:0000:ff00:0042:8329     full form
2001:db8::ff00:42:8329                     compressed (one :: run per address)
2001:db8::1/64                             a typical LAN: /64 for the host part

::1                                        loopback
fe80::/10                                  link-local, auto-configured per interface
fc00::/7                                   unique local (the private equivalent)

Full lesson: IP addressing, CIDR and subnetting →

Ports, sockets and the client-server model

A connection is a four-tuple

server listens on  0.0.0.0:443

connection 1  192.168.1.10:51001  ->  203.0.113.5:443
connection 2  192.168.1.10:51002  ->  203.0.113.5:443
connection 3  192.168.1.11:50000  ->  203.0.113.5:443

three distinct connections, one listening port

Port exhaustion and its symptoms

# inspect sockets on Linux
ss -tlnp                     # listening TCP sockets with owning process
ss -tan state established | wc -l
ss -s                        # a summary including TIME-WAIT counts

# count ephemeral ports in use toward one destination
ss -tan | grep '203.0.113.5:443' | wc -l

# widen the ephemeral range if the workload is outbound-heavy
sysctl net.ipv4.ip_local_port_range

Full lesson: Ports, sockets and the client-server model →

TCP in depth: handshake, windows and congestion control

Opening and closing a connection

open:  client --SYN seq=x-------->  server
       client <--SYN+ACK seq=y ack=x+1--  server
       client --ACK ack=y+1--------->  server
       (one round trip before any data can be sent)

close: FIN -> ACK <- FIN -> ACK     (four segments, or three with piggybacking)
       the closer waits in TIME-WAIT for twice the maximum segment lifetime

Sequence numbers and retransmission

# observe retransmissions and window behaviour
ss -tni | head -20
#   retrans:0/3   means three retransmits happened in this connection
#   rtt:12.4/1.2  smoothed RTT and variance, in milliseconds
#   cwnd:10       congestion window in segments
#   send 1.3Mbps  the delivery rate the kernel estimates

netstat -s | grep -A4 -i "^Tcp"   # counters: retrans, bad segments, resets

Flow control and congestion control

# inspect and tune the congestion algorithm on Linux
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

# per-route: a long fat network may need a larger window
ip route show

Full lesson: TCP in depth: handshake, windows and congestion control →

UDP, QUIC and choosing reliability

A datagram is a postcard

import socket

srv = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
srv.bind(("0.0.0.0", 9999))

data, addr = srv.recvfrom(2048)      # one datagram, no connection
srv.sendto(b"ack", addr)             # a reply is just another datagram

# a large datagram is fragmented by IP and lost entirely if any fragment is lost
# keep payloads well under the path MTU, or implement your own chunking

QUIC is TCP-like reliability in user space

HTTP/2 over TCP            HTTP/3 over QUIC
 one ordered byte stream     many independent streams
 one lost packet blocks      a lost packet blocks only
 all streams                 the stream it belongs to
 TLS handshake after TCP     TLS 1.3 integrated in the handshake
 (2 RTT, or 1 with resume)   (1 RTT, or 0 on resumption)
 connection identified by    connection identified by a
 four-tuple                  connection id, so it survives
                             a change of address

Full lesson: UDP, QUIC and choosing reliability →

TLS and HTTPS: certificates and the handshake

The handshake in outline

TLS 1.2                          TLS 1.3
ClientHello                      ClientHello + key share
                                  (guess at the group)
ServerHello, Certificate,        ServerHello, key share,
ServerKeyExchange,               Certificate, Finished
ServerHelloDone
ClientKeyExchange,
ChangeCipherSpec, Finished
ChangeCipherSpec, Finished

2 round trips before data         1 round trip before data

The handshake in outline

# inspect a live handshake
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# what the server offers
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -i "protocol\|cipher"

What a certificate actually asserts

verification steps a client performs

1  build a chain from the leaf to a trusted root
2  verify every signature in the chain
3  check the current time against validity
4  check the requested name against the SANs
5  check that no certificate in the chain is revoked
6  check that revocation data is fresh enough (or soft-fail)
7  confirm the server proves possession of the private key

Full lesson: TLS and HTTPS: certificates and the handshake →

DNS deep dive: zones, records and DNSSEC

TTL, caching and propagation

# ask a specific resolver, bypassing the local cache
dig +short @1.1.1.1 example.com A
dig @8.8.8.8 example.com MX +noall +answer
dig +trace example.com            # walk from the root down

# see the remaining TTL and the authority
dig example.com A | grep -A2 "ANSWER SECTION"

# reverse lookup
dig -x 203.0.113.10 +short

Full lesson: DNS deep dive: zones, records and DNSSEC →

Routing, NAT and gateways

Longest prefix wins

ip route show
# default via 192.168.1.1 dev wlan0 proto dhcp metric 600
# 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.10
# 10.8.0.0/24 via 192.168.1.1 dev wlan0
# 0.0.0.0/0 is the least specific possible route

ip route get 203.0.113.5
# 203.0.113.5 via 192.168.1.1 dev wlan0 src 192.168.1.10

NAT rewrites and the things it breaks

inside            NAT table                          outside

192.168.1.10:51001  <->  203.0.113.5:443
                    rewritten to
198.51.100.7:40001  <->  203.0.113.5:443

the reply arrives for 198.51.100.7:40001 and is rewritten back
to 192.168.1.10:51001 using the stored mapping

NAT rewrites and the things it breaks

# inspect NAT mappings on a Linux gateway
conntrack -L | head
# tcp 6 431999 ESTABLISHED src=192.168.1.10 dst=203.0.113.5 sport=51001 dport=443
#     src=203.0.113.5 dst=198.51.100.7 sport=443 dport=40001 [ASSURED]

sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count

Full lesson: Routing, NAT and gateways →

Network debugging toolkit

Reading curl timings

curl -sS -o /dev/null -w '
dns      %{time_namelookup}s
connect  %{time_connect}s
tls      %{time_appconnect}s
ttfb     %{time_starttransfer}s
total    %{time_total}s
http     %{http_code}
size     %{size_download} bytes
' https://api.example.com/health

Reading curl timings

# pin the address to test one backend behind a load balancer
curl -v --resolve api.example.com:443:203.0.113.10 https://api.example.com/health

# show only the handshake and headers
curl -sS -v -o /dev/null https://api.example.com/health 2>&1 | grep -E '^[<>*]'

When nothing above explains it

# capture on a specific interface and port, without resolving names
tcpdump -i eth0 -nn -s 0 port 443 -c 50 -w /tmp/cap.pcap

# show TCP flags, which reveals retransmits and resets
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'

# a connection refused arrives as a reset, not silence
# silence usually means a firewall dropped the packet

Full lesson: Network debugging toolkit →

Proxies, load balancers and CDNs

Who the proxy is serving

# headers that let the origin see the real client
X-Forwarded-For: 203.0.113.10, 198.51.100.7
X-Forwarded-Proto: https
X-Forwarded-Host: api.example.com
Forwarded: for=203.0.113.10;proto=https;host=api.example.com

# and the hop-by-hop headers a proxy must not forward
Connection: keep-alive
Transfer-Encoding: chunked

What a CDN caches

Cache-Control: public, max-age=31536000, immutable     # hashed static asset
Cache-Control: public, s-maxage=300, stale-while-revalidate=60
Cache-Control: private, no-store                         # per-user response
Cache-Control: no-cache                                  # revalidate every time
Vary: Accept-Encoding, Accept-Language                   # separate cache entries

Full lesson: Proxies, load balancers and CDNs →

Wireless, mobile and the last mile

Address changes and connection survival

TCP connection                QUIC connection
identified by the             identified by a
four-tuple                    connection id

address change -> the          address change -> the
connection is dead; a new      same logical connection
handshake is required          continues on the new path

Designing for the last mile

# emulate a mobile profile before blaming the server
# Chrome DevTools: Network -> throttling -> Slow 4G
# or on Linux, add delay and loss to a test interface
tc qdisc add dev eth0 root netem delay 100ms 40ms loss 2%
tc qdisc del dev eth0 root netem

Full lesson: Wireless, mobile and the last mile →

Network security: eavesdropping, MITM and DDoS

Eavesdropping on a local network

normal        client  --->  gateway        (ARP says this address is at that MAC)

spoofed       client  --->  attacker  --->  gateway
              attacker replies to ARP for the gateway address with its own MAC,
              then forwards the traffic so nothing looks broken

Man in the middle

pin the public key, not only the certificate

normal validation   chain -> trusted root -> hostname matches
pinning adds        the leaf or intermediate public key must match a known value

benefit   an attacker with a trusted-but-wrong certificate cannot intercept
cost      key rotation requires a release unless multiple pins are allowed

Denial of service and reflection

# confirm you are not running an open amplifier
ss -tlnp | grep -E ':53|:123|:1900'
dig +short CHAOS TXT version.bind @your-dns-server

# rate limit at the edge rather than in the application
# nginx example
# limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
# limit_req zone=api burst=40 nodelay;

Full lesson: Network security: eavesdropping, MITM and DDoS →

FAQ

Is this Computer Networks cheat sheet free to use?

Yes. No sign-up and no tracking: the page is static, every example is on the page itself, and you can print it or save it as a one-page reference.

Where do the examples come from?

Every snippet is taken from the 14 lessons of the Computer Networks course on this site, and each section links back to the lesson it was pulled from.

How do I go deeper than a cheat sheet?

Open the full Computer Networks course — it carries the worked explanations, the edge cases and the exercises behind every line here.

Algorithms Data Structures Operating Systems Character Encodings Hashing & Checksums Data Formats

Last refreshed 2026-09-27.