Networking Cheat Sheet for Developers and CS Students

Networking Cheat Sheet for Developers

Most application bugs that look like networking bugs are one of four things: DNS returning the wrong address, a firewall dropping a port, TLS failing to negotiate, or nothing listening on the other end.

This sheet gives you the model to reason about that, the tables you look up, and the command sequence that isolates the layer.

Updated for 2026. Covers IPv4/IPv6, HTTP/3 and TLS 1.3.

OSI vs TCP/IP

OSI is the vocabulary; TCP/IP is the machine. The internet was built first and modelled afterwards. Interviews ask for seven layers; debugging uses four.

The postal analogy holds well. Layer 7 is the letter you wrote. Layer 4 is whether you paid for tracked delivery. Layer 3 is the address on the envelope. Layer 2 is the van between two sorting offices.

What each layer actually does:

• Link moves a frame between two devices on the same physical segment, addressed by MAC address. ARP is how an IP address is translated to a MAC on a local network.
• Internet moves a packet across networks by IP address, hop by hop, with no guarantee it arrives.
• Transport adds ports, so one machine can run many services, and — if you chose TCP — reliability on top of an unreliable layer below.
• Application is your protocol: HTTP, DNS, SMTP.

Layer 3 does not guarantee delivery. Layer 4 is where reliability is invented. That single sentence explains why TCP exists.

Ports You Should Recognise

Ports 0–1023 are well-known and on Unix require root to bind — the historical reason apps run on 3000 or 8080 in development.

Never expose 3306, 5432, 6379 or 27017 to the internet. Redis and MongoDB in particular have been mass-compromised because of default configurations reachable from anywhere.

TCP vs UDP vs QUIC

TCP when every byte must arrive. Web pages, APIs, file transfer, databases.

UDP when late data is worthless. In a voice call, a packet that arrives 400 ms late is not useful — retransmitting it makes the call worse, not better.

QUIC exists to fix one specific TCP flaw. In HTTP/2 over TCP, many streams share one connection, so a single lost packet stalls all of them until it is retransmitted. QUIC runs its own streams over UDP, so loss only stalls the stream that lost a packet.

The TCP handshake

Client                          Server
  |------------ SYN ------------>|     "let's talk, my seq = x"
  |<-------- SYN + ACK ----------|     "ok, my seq = y, I got x"
  |------------ ACK ------------>|     "I got y"
  |======= connection open ======|

Three messages, one full round trip, before a single byte of your data moves. On a 200 ms link that is 200 ms of latency you cannot optimise away — which is why connection reuse and keep-alive matter so much.

Closing takes four messages (FIN, ACK, FIN, ACK), and the initiator sits in TIME_WAIT afterwards. Thousands of sockets in TIME_WAIT on a busy server is normal, not a leak.

DNS

A resolution walkthrough

Requesting www.example.com:

1. Browser and OS cache are checked, then /etc/hosts.
2. The query goes to your configured recursive resolver (your ISP, or a public one like 1.1.1.1).
3. If uncached, the resolver asks a root server. Root does not know the answer; it returns the name servers for com.
4. The resolver asks a com TLD server, which returns the authoritative name servers for example.com.
5. The resolver asks one of those authoritative servers, which returns the A record.
6. The resolver caches it for its TTL and answers you.

This is why DNS changes appear at different times for different people. Every resolver in the chain holds its own cached copy until its TTL expires. Lower the TTL before a migration, not during it.

CNAME cannot coexist with other records at the same name, which is why a root domain usually cannot be a CNAME — providers offer ALIAS or ANAME as a workaround.

HTTP Versions

HTTP/1.1's limitation drove a decade of workarounds — sprite sheets, file concatenation, domain sharding — all to work around six connections per host. HTTP/2 multiplexing made most of them counterproductive.

HTTP/2 moved the blocking problem, it did not remove it. Streams no longer block each other at the HTTP layer, but they still share one TCP connection, so one lost packet stalls everything. HTTP/3 solves this by leaving TCP entirely.

TLS

A TLS 1.3 handshake in outline:

1. ClientHello — supported versions and ciphers, plus a key share guess.
2. ServerHello — chosen cipher, its key share, and the certificate chain.
3. Both sides derive the same session key from their key shares; the client verifies the certificate against its trusted root store.
4. Encrypted application data flows.

TLS 1.3 completes in one round trip, down from two in TLS 1.2, and drops every cipher suite without forward secrecy. A resumed session can send data in zero round trips.

Common failures and what they actually mean:

The intermediate-certificate case is the sneaky one. Browsers often cache intermediates from previous sites and appear fine, while curl, mobile apps, and server-to-server calls fail. Always test with openssl s_client, not just a browser.

IP Addresses and CIDR

Private ranges (never routed on the internet):

Also reserved: 127.0.0.0/8 (loopback), 169.254.0.0/16 (link-local, meaning DHCP failed).

CIDR notation states how many leading bits are the network:

The arithmetic: host bits = 32 - prefix; usable hosts = 2^hostbits - 2. Two are subtracted for the network address and the broadcast address.

/32 means exactly one address and 0.0.0.0/0 means everything — the two you meet most in firewall rules and security groups.

NAT is why private addresses work. Your router rewrites the private source address of outgoing packets to its one public address, records the mapping, and reverses it on the reply. Fifty devices, one public IP.

The side effect: nothing outside can initiate a connection inward without an explicit port forward. That is a large part of why home networks are accidentally secure.

Load Balancer vs Reverse Proxy vs CDN

Every load balancer is a reverse proxy; not every reverse proxy is a load balancer. A CDN is a globally distributed cache that usually also acts as both.

Layer 4 versus layer 7 balancing: L4 forwards TCP connections without reading them — fast, protocol-agnostic, no routing by path. L7 parses HTTP, so it can route /api and /static to different pools, but must terminate TLS to do so.

The Diagnostic Sequence

When something cannot connect, go up the stack in order. Each step eliminates a class of cause.

# 1. DNS — does the name resolve, and to what?
dig example.com +short
dig example.com A +trace          # follow the full delegation chain
dig @1.1.1.1 example.com          # bypass your local resolver

# 2. Reachability — is the host there at all?
ping -c 4 93.184.216.34

# 3. Path — where does it stop?
traceroute example.com            # tracert on Windows

# 4. Ports — is anything listening?
ss -tulpn                         # local listening sockets (Linux)
ss -tn state established
nc -zv example.com 443            # can I open that remote port?

# 5. Application — what does the server actually say?
curl -v https://example.com
curl -I https://example.com       # headers only
openssl s_client -connect example.com:443 -servername example.com

Step 1 answers "is it DNS?" and it usually is. Compare dig against your resolver with dig @1.1.1.1 against a public one. Different answers mean a caching or split-horizon problem, not a server problem.

A failed ping is weak evidence. Many hosts and most cloud firewalls drop ICMP deliberately. ping failing while curl succeeds is normal and means nothing is wrong.

traceroute gaps are also normal. Routers that do not reply to ICMP show as * * * while still forwarding traffic perfectly. Only a consistent stop at the same hop, with nothing beyond it, is a real signal.

curl -v is the highest-information single command on this list. In one output you see the resolved IP, the TCP connection, the full TLS negotiation with certificate details, the request headers sent, and the response headers received.

The Five Mistakes

1. Concluding a host is down because ping fails. ICMP is routinely blocked. Test the actual port.

2. Assuming a DNS change is live everywhere. Every resolver caches until its TTL expires. Lower the TTL before migrating.

3. Trusting a browser to validate your TLS chain. Browsers cache intermediates. Verify with openssl s_client or curl.

4. Exposing database ports to 0.0.0.0/0. Bind to localhost or a private subnet, and put access behind a VPN or bastion.

5. Reading TIME_WAIT sockets as a leak. It is the normal end state of a closed TCP connection.

Print This Section

LAYERS      Link → Internet(IP) → Transport(TCP/UDP) → Application(HTTP)
            IP does not guarantee delivery; TCP adds it

PORTS       22 SSH · 53 DNS · 80 HTTP · 443 HTTPS+QUIC
            3306 MySQL · 5432 Postgres · 6379 Redis · 27017 Mongo

TCP/UDP     TCP = handshake, ordered, reliable   UDP = fire and forget
            QUIC = reliable streams over UDP, no TCP head-of-line block

DNS         cache → resolver → root → TLD → authoritative
            change not live everywhere until TTL expires

PRIVATE IP  10.0.0.0/8 · 172.16.0.0/12 · 192.168.0.0/16
            /24 = 254 hosts · /32 = one host · 0.0.0.0/0 = everything

DIAGNOSE    dig +short  →  ping  →  traceroute  →  ss -tulpn  →  curl -v
            ping failing proves nothing (ICMP is often blocked)

Nearly every "the network is broken" incident resolves to one question answered in the wrong order — so run dig, then ss, then curl -v, and let each command eliminate a layer before you form a theory.

🔗 Next in this collection: System Design Cheat Sheet, or return to The Complete Developer Cheat Sheet Collection.