← Back to all projects

NETWORK PROTOCOLS FROM SPEC TO PRACTICE

Network Protocols: From Specification to Practice

“The nice thing about standards is that you have so many to choose from.” — Andrew S. Tanenbaum

Understanding network protocols deeply means understanding why they exist, how they’re specified, and what happens when you implement them byte-by-byte. This guide provides 18 projects that will take you from basic socket programming to implementing complex, real-world protocols from their RFC specifications.

Why Specifications Matter

Before diving into projects, understand this fundamental truth: a protocol is a contract.

When two computers communicate, they must agree on:

  • Message format: What bytes mean what
  • State transitions: What messages are valid when
  • Error handling: What happens when things go wrong
  • Timing: Timeouts, retransmissions, keepalives

The RFC (Request for Comments) system, born from ARPANET in 1969, codifies these contracts. RFC 791 (IP), RFC 793 (TCP), RFC 2616 (HTTP/1.1) — these documents are the “source code” of the internet. When you read “MUST”, “SHOULD”, “MAY” in an RFC, you’re reading legal-style precision about behavior.

Why this matters: If your HTTP server sends content-length (lowercase) but the spec says Content-Length, some clients will break. Protocols are unforgiving — one wrong byte and the connection dies.

The Protocol Stack You’ll Explore

┌─────────────────────────────────────────────────┐
│  Application Layer (HTTP, DNS, SMTP, WebSocket) │  ← Projects 8-18
├─────────────────────────────────────────────────┤
│  Transport Layer (TCP, UDP, QUIC)               │  ← Projects 4-7
├─────────────────────────────────────────────────┤
│  Network Layer (IP, ICMP, ARP)                  │  ← Projects 1-3
├─────────────────────────────────────────────────┤
│  Link Layer (Ethernet, Wi-Fi)                   │  ← Explored via raw sockets
└─────────────────────────────────────────────────┘

Project 1: ICMP Ping Implementation

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go, Python (with root)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Network Layer / Raw Sockets
  • Software or Tool: ping utility
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A ping clone that sends ICMP Echo Request packets and receives Echo Replies, calculating round-trip time and packet loss — all using raw sockets.

Why it teaches protocol specifications: ICMP (RFC 792) is one of the simplest protocols to implement, yet it teaches the fundamentals: exact byte-level message formats, checksums, and working outside the comfort of TCP/UDP. You’ll read the RFC and translate its diagrams directly into struct definitions.

Core challenges you’ll face:

  • Raw socket programming (bypassing TCP/UDP) → maps to understanding protocol layers
  • Checksum calculation (RFC-specified algorithm) → maps to implementing spec requirements
  • Byte order handling (network vs host order) → maps to binary protocol fundamentals
  • Timing precision (microsecond RTT measurement) → maps to protocol timing requirements
  • Privilege requirements (root/capabilities needed) → maps to security constraints

Key Concepts:

  • Raw Sockets: “The Linux Programming Interface” Chapter 58 - Michael Kerrisk
  • ICMP Protocol: “TCP/IP Illustrated, Volume 1” Chapter 6 - W. Richard Stevens
  • Checksum Algorithms: RFC 1071 - “Computing the Internet Checksum”
  • Byte Ordering: “Computer Systems: A Programmer’s Perspective” Chapter 2.1 - Bryant & O’Hallaron

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Basic C, understanding of IP addresses

Real world outcome:

$ sudo ./myping google.com
PING google.com (142.250.185.78): 56 data bytes
64 bytes from 142.250.185.78: icmp_seq=0 ttl=117 time=14.2 ms
64 bytes from 142.250.185.78: icmp_seq=1 ttl=117 time=13.8 ms
64 bytes from 142.250.185.78: icmp_seq=2 ttl=117 time=15.1 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max = 13.8/14.4/15.1 ms

Implementation Hints: The ICMP Echo Request format from RFC 792 is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

Type=8 for Echo Request, Type=0 for Echo Reply. Your job is to translate this ASCII diagram into a C struct, fill it correctly, compute the checksum per RFC 1071, and send it via sendto() on a raw socket (SOCK_RAW, IPPROTO_ICMP).

Learning milestones:

  1. Raw socket created and packet sent → You understand protocol layer bypassing
  2. Checksum validates correctly → You can implement RFC algorithms
  3. RTT calculated accurately → You understand timing in protocols
  4. Handles unreachable hosts gracefully → You understand ICMP error messages

Project 2: ARP Cache Viewer and Spoofer

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python (with Scapy), Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Link Layer / Address Resolution
  • Software or Tool: arp utility / Network Analysis
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A tool that reads/manipulates the ARP cache and can send crafted ARP packets — demonstrating how IP addresses map to MAC addresses on a local network.

Why it teaches protocol specifications: ARP (RFC 826) operates at the boundary between Layer 2 and Layer 3. It shows how protocols handle the “gap” between abstractions (IP addresses) and reality (hardware addresses). You’ll see why ARP has no authentication and understand the security implications.

Core challenges you’ll face:

  • Link-layer raw sockets (AF_PACKET on Linux) → maps to Layer 2 protocol access
  • Ethernet frame construction (headers, MTU) → maps to frame format specifications
  • ARP packet format (hardware/protocol types, addresses) → maps to reading RFC diagrams
  • Cache timing (ARP cache expiry, gratuitous ARP) → maps to protocol state management
  • Security implications (ARP spoofing is trivial) → maps to understanding protocol weaknesses

Key Concepts:

  • ARP Protocol: “TCP/IP Illustrated, Volume 1” Chapter 4 - W. Richard Stevens
  • Ethernet Framing: “Computer Networks” Chapter 4 - Tanenbaum
  • Raw Packet Injection: “The Linux Programming Interface” Chapter 58.4 - Kerrisk
  • Network Security: “Practical Packet Analysis” Chapter 8 - Chris Sanders

Difficulty: Advanced Time estimate: 1 week Prerequisites: Project 1, understanding of MAC addresses, Linux environment

Real world outcome:

$ sudo ./arp_tool --scan 192.168.1.0/24
Scanning local network...
192.168.1.1   → 00:1a:2b:3c:4d:5e (Cisco Systems)
192.168.1.10  → aa:bb:cc:dd:ee:ff (Apple, Inc.)
192.168.1.15  → 11:22:33:44:55:66 (Unknown)

$ sudo ./arp_tool --cache
ARP Cache:
IP Address       MAC Address        State    Expires
192.168.1.1      00:1a:2b:3c:4d:5e  REACHABLE  45s
192.168.1.10     aa:bb:cc:dd:ee:ff  STALE      --

Implementation Hints: ARP packets have a specific format defined in RFC 826. On Linux, you’ll use AF_PACKET sockets to send raw Ethernet frames. The ARP header includes hardware type (Ethernet=1), protocol type (IPv4=0x0800), and operation (Request=1, Reply=2). Study how your OS resolves “Who has 192.168.1.1?” and caches the response.

Learning milestones:

  1. Can read system ARP cache → You understand OS network state
  2. Can send ARP requests and receive replies → You understand request/response protocols
  3. Can detect ARP spoofing attempts → You understand protocol security weaknesses
  4. Understand gratuitous ARP → You understand protocol edge cases

Project 3: Traceroute Implementation

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Go, Rust, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Network Layer / Routing
  • Software or Tool: traceroute utility
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A traceroute tool that discovers the path packets take across the internet by exploiting the IP TTL field and ICMP Time Exceeded messages.

Why it teaches protocol specifications: This project demonstrates how protocols interact across layers. You’ll use IP header fields (TTL), trigger ICMP responses, and understand how routing works — all by cleverly exploiting specified behavior.

Core challenges you’ll face:

  • TTL manipulation (setting IP header fields) → maps to IP protocol details (RFC 791)
  • ICMP Time Exceeded parsing (Type 11) → maps to ICMP message types
  • UDP/ICMP/TCP probe modes (different traceroute methods) → maps to protocol flexibility
  • Async response handling (responses may arrive out of order) → maps to stateless protocol challenges
  • Firewall evasion (some routers don’t respond) → maps to real-world protocol behavior

Key Concepts:

  • IP TTL Field: “TCP/IP Illustrated, Volume 1” Chapter 5 - Stevens
  • ICMP Error Messages: RFC 792, Section “Time Exceeded Message”
  • Routing Basics: “Computer Networks” Chapter 5 - Tanenbaum
  • Paris Traceroute: Research paper on load-balancer aware traceroute

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Project 1 completed, understanding of routing concepts

Real world outcome:

$ sudo ./mytraceroute google.com
traceroute to google.com (142.250.185.78), 30 hops max
 1  192.168.1.1 (192.168.1.1)  1.234 ms  1.123 ms  1.456 ms
 2  10.0.0.1 (10.0.0.1)  8.234 ms  7.891 ms  8.012 ms
 3  * * *
 4  72.14.215.85 (72.14.215.85)  12.345 ms  11.987 ms  12.123 ms
 5  142.250.185.78 (142.250.185.78)  14.234 ms  13.891 ms  14.012 ms

Implementation Hints: The clever trick: send packets with TTL=1, then TTL=2, then TTL=3, etc. Each router decrements TTL and when it hits 0, the router sends back an ICMP Time Exceeded message. This reveals each hop. The challenge is correlating responses to requests (use UDP port numbers or ICMP sequence numbers as identifiers).

Learning milestones:

  1. First hop discovered → You understand TTL mechanics
  2. Full path mapped → You understand multi-hop routing
  3. Multiple probe methods working → You understand protocol alternatives
  4. Handles non-responsive hops → You understand real-world network behavior

Project 4: TCP Three-Way Handshake Visualizer

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Transport Layer / Connection Management
  • Software or Tool: TCP/IP Stack Analysis
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A tool that captures TCP packets and visualizes the state machine transitions: SYN → SYN-ACK → ACK, showing sequence numbers, window sizes, and options negotiation in real-time.

Why it teaches protocol specifications: TCP (RFC 793) is the canonical example of a stateful protocol. Its state machine has 11 states with precise transition rules. Understanding TCP means understanding how specifications handle reliability over an unreliable network.

Core challenges you’ll face:

  • Packet capture (libpcap/raw sockets) → maps to protocol inspection
  • TCP state machine tracking (11 states, transition rules) → maps to stateful protocol design
  • Sequence number tracking (32-bit wrapping, relative vs absolute) → maps to protocol arithmetic
  • Options parsing (MSS, Window Scale, SACK, Timestamps) → maps to protocol extensibility
  • Connection matching (4-tuple identification) → maps to multiplexing in protocols

Key Concepts:

  • TCP State Machine: “TCP/IP Illustrated, Volume 1” Chapter 13 - Stevens (the canonical reference)
  • TCP Header Format: RFC 793, Section 3.1
  • TCP Options: RFC 7323 (Window Scale, Timestamps)
  • Connection Tracking: “Understanding Linux Network Internals” Chapter 20 - Benvenuti

Difficulty: Expert Time estimate: 2 weeks Prerequisites: Projects 1-3, strong C skills, understanding of state machines

Real world outcome:

$ sudo ./tcp_visualizer -i eth0 -p 80
Capturing TCP connections on eth0:80...

[NEW] 192.168.1.10:54321 → 93.184.216.34:80
  State: CLOSED → SYN_SENT
  │ SYN  seq=1000000000 win=65535 <mss 1460, wscale 6, sackOK>
  ↓
  State: SYN_SENT → ESTABLISHED
  │ SYN-ACK  seq=2000000000 ack=1000000001 win=65535 <mss 1380, wscale 7>
  │ ACK  seq=1000000001 ack=2000000001 win=65535
  ↓
  [ESTABLISHED] RTT=14.2ms  Window=65535

[DATA] 192.168.1.10:54321 → 93.184.216.34:80
  │ PSH-ACK  seq=1000000001 ack=2000000001 len=78 "GET / HTTP/1.1..."

Implementation Hints: Use libpcap to capture packets with filter tcp port 80. Parse the TCP header (20+ bytes), track each connection by its 4-tuple (src IP, src port, dst IP, dst port). Maintain a hash table of connections with their current state. On each packet, look up the connection and apply the state transition rules from RFC 793’s state diagram.

Learning milestones:

  1. Capture and parse TCP headers → You understand TCP header format
  2. Track SYN/SYN-ACK/ACK correctly → You understand connection establishment
  3. Handle simultaneous open → You understand edge cases in specs
  4. Track connection teardown (FIN/RST) → You understand connection lifecycle
  5. Display options negotiation → You understand protocol extensibility

Project 5: Minimal TCP Stack (User-Space)

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 5: Master
  • Knowledge Area: Transport Layer / Protocol Implementation
  • Software or Tool: TCP/IP Stack
  • Main Book: “TCP/IP Illustrated, Volume 2: The Implementation” by W. Richard Stevens

What you’ll build: A user-space TCP implementation that can establish connections, send/receive data, and handle retransmissions — running alongside (not replacing) your OS’s TCP stack via a TUN/TAP interface.

Why it teaches protocol specifications: This is the ultimate protocol project. You’ll implement RFC 793 from scratch: the state machine, sequence number arithmetic, flow control, congestion control (RFC 5681), and retransmission timers. You’ll understand why TCP is complex and why every “MUST” in the spec exists.

Core challenges you’ll face:

  • TUN/TAP interface (virtual network device) → maps to network stack architecture
  • Full TCP state machine (all 11 states, all transitions) → maps to complete spec implementation
  • Retransmission timer (Karn’s algorithm, exponential backoff) → maps to reliability mechanisms
  • Flow control (sliding window, receiver window) → maps to rate limiting in protocols
  • Congestion control (slow start, congestion avoidance) → maps to network fairness

Key Concepts:

  • TCP Implementation: “TCP/IP Illustrated, Volume 2” - Stevens (entire book is relevant)
  • Congestion Control: RFC 5681 - “TCP Congestion Control”
  • Retransmission: RFC 6298 - “Computing TCP’s Retransmission Timer”
  • User-Space Networking: “Understanding Linux Network Internals” - Benvenuti

Difficulty: Master Time estimate: 1-2 months Prerequisites: Projects 1-4, deep C knowledge, patience

Real world outcome:

$ sudo ./mytcp_stack --tun tun0 --ip 10.0.0.2
TCP stack running on 10.0.0.2 via tun0

# In another terminal:
$ curl --interface tun0 http://example.com/
<!doctype html>
<html>
<head>
    <title>Example Domain</title>
...
# Your TCP stack just fetched a webpage!

# Stack output:
[TCP] SYN sent to 93.184.216.34:80, seq=random
[TCP] SYN-ACK received, ack=random+1
[TCP] Connection ESTABLISHED (RTT: 45ms)
[TCP] Sending 78 bytes (HTTP GET)
[TCP] Received 1256 bytes
[TCP] FIN sent, entering FIN_WAIT_1
[TCP] Connection closed gracefully

Implementation Hints: Start with a TUN device (/dev/net/tun on Linux). This gives you raw IP packets to process. Implement in layers: first just parse IP headers, then add TCP header parsing, then implement the state machine for connection establishment, then add data transfer, finally add retransmission. The Saminiir blog series “Let’s code a TCP/IP stack” is an excellent companion.

Learning milestones:

  1. TUN device sending/receiving raw IP → You understand network stack layering
  2. Three-way handshake completes → You understand connection establishment
  3. Can transfer small data reliably → You understand basic reliability
  4. Retransmission works → You understand timer-based protocols
  5. Can browse websites via your stack → You’ve implemented a real TCP

Project 6: UDP Reliability Layer

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Transport Layer / Reliability Design
  • Software or Tool: Custom Protocol
  • Main Book: “Computer Networks” by Tanenbaum

What you’ll build: A reliability layer on top of UDP that provides ordered delivery, acknowledgments, and retransmission — essentially reinventing TCP’s reliability without TCP.

Why it teaches protocol specifications: This project forces you to design your own protocol specification. You’ll face the same decisions the TCP designers faced: sequence numbers (how many bits?), acknowledgment strategy (per-packet or cumulative?), timeout calculation (fixed or adaptive?). Then you’ll understand why QUIC, SCTP, and other protocols made different choices than TCP.

Core challenges you’ll face:

  • Sequence number space design (bits, wrapping, initial value) → maps to protocol design decisions
  • Acknowledgment strategy (individual, cumulative, selective) → maps to efficiency tradeoffs
  • Retransmission logic (timeout selection, duplicate detection) → maps to reliability implementation
  • Ordering vs reliability (separate concerns) → maps to protocol modularity
  • API design (blocking vs async, streams vs datagrams) → maps to protocol usability

Key Concepts:

  • Reliable Data Transfer: “Computer Networks” Chapter 3.4 - Tanenbaum
  • Stop-and-Wait vs Pipelining: “Computer Networking: A Top-Down Approach” Chapter 3 - Kurose
  • QUIC Design: RFC 9000 - “QUIC: A UDP-Based Multiplexed and Secure Transport”
  • SCTP: RFC 4960 for alternative reliability design

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Socket programming, understanding of TCP concepts

Real world outcome:

# Server:
$ ./reliable_udp_server 9000
Listening on UDP port 9000 with reliability layer...
[RECV] Message 1: "Hello from client"
[RECV] Message 2: "This is message 2"
[RECV] Message 3: "Messages arrive in order!"

# Client:
$ ./reliable_udp_client localhost 9000
Connected with reliability layer
> Hello from client
[SENT] seq=0, awaiting ACK... [ACK received, RTT=12ms]
> This is message 2
[SENT] seq=1, awaiting ACK... [timeout, retransmitting]... [ACK received]

Implementation Hints: Design your header format first: sequence number (32-bit), acknowledgment number (32-bit), flags (ACK, FIN, RST). Start with stop-and-wait (send one, wait for ACK) then evolve to sliding window. Use a single timer for simplicity, then implement per-packet timers for efficiency. Document your protocol as if writing an RFC!

Learning milestones:

  1. Stop-and-wait works → You understand basic reliability
  2. Handles packet loss (simulated) → You understand retransmission
  3. Sliding window implemented → You understand pipelining
  4. RTT-adaptive timeouts → You understand practical reliability
  5. Written protocol specification → You understand spec writing

Project 7: DNS Resolver from Scratch

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Application Layer / Name Resolution
  • Software or Tool: DNS Resolver
  • Main Book: “DNS and BIND” by Cricket Liu

What you’ll build: A DNS resolver that constructs queries, sends them to DNS servers, parses responses, and follows referrals from root servers all the way down to authoritative nameservers.

Why it teaches protocol specifications: DNS (RFC 1035) is a masterclass in binary protocol design: variable-length labels, compression pointers, multiple record types. It also demonstrates hierarchical protocol design and caching. The message format is compact yet extensible, showing how protocols balance efficiency with flexibility.

Core challenges you’ll face:

  • DNS message format (header, questions, answers, compression) → maps to binary protocol parsing
  • Label encoding (length-prefixed, compression pointers) → maps to efficient encoding schemes
  • Record type handling (A, AAAA, CNAME, MX, TXT, etc.) → maps to protocol extensibility
  • Recursive resolution (following referrals) → maps to distributed protocol design
  • Caching (TTL-based expiration) → maps to protocol state management

Key Concepts:

  • DNS Protocol: “DNS and BIND” Chapters 2, 12 - Cricket Liu
  • DNS Message Format: RFC 1035, Sections 4.1-4.2
  • DNS Compression: RFC 1035, Section 4.1.4
  • DNSSEC Basics: RFC 4033 for security extensions

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: UDP socket programming, binary data handling

Real world outcome:

$ ./mydns google.com A
Querying root server 198.41.0.4...
  → Referral to .com: a.gtld-servers.net (192.5.6.30)
Querying .com server 192.5.6.30...
  → Referral to google.com: ns1.google.com (216.239.32.10)
Querying google.com server 216.239.32.10...
  → Answer: google.com A 142.250.185.78 (TTL: 300)

Result: google.com → 142.250.185.78

$ ./mydns gmail.com MX
...
Result: gmail.com MX 5 gmail-smtp-in.l.google.com
                  MX 10 alt1.gmail-smtp-in.l.google.com

Implementation Hints: DNS messages have a 12-byte header, then questions, then answers. Names are encoded as length-prefixed labels (e.g., \x06google\x03com\x00). Compression uses pointers: if top 2 bits are 11, the next 14 bits point to an earlier name. Parse this carefully! Start by querying a local resolver (8.8.8.8), then implement recursive resolution from root servers.

Learning milestones:

  1. Parse DNS responses from 8.8.8.8 → You understand DNS message format
  2. Handle compression pointers → You understand binary protocol tricks
  3. Implement recursive resolution → You understand hierarchical protocols
  4. Add caching with TTL → You understand stateful protocol handling
  5. Handle multiple record types → You understand protocol extensibility

Project 8: HTTP/1.1 Protocol Parser

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Application Layer / Web Protocols
  • Software or Tool: HTTP Parser
  • Main Book: “HTTP: The Definitive Guide” by David Gourley

What you’ll build: A from-scratch HTTP/1.1 request/response parser that handles the full specification: chunked encoding, keep-alive connections, content negotiation, and proper error responses.

Why it teaches protocol specifications: HTTP/1.1 (RFC 2616, updated by RFC 7230-7235) is a text-based protocol, but don’t let that fool you — it’s complex. Headers have precise syntax, body length determination has multiple methods, and connection management has subtle rules. You’ll see how a “simple” protocol becomes complex when handling all edge cases.

Core challenges you’ll face:

  • Request line parsing (method, URI, version) → maps to protocol framing
  • Header parsing (folding, multiple values, case insensitivity) → maps to text protocol complexity
  • Body length determination (Content-Length vs chunked vs connection close) → maps to protocol state
  • Chunked transfer decoding (hex lengths, trailers) → maps to streaming protocols
  • Keep-alive connection reuse (reset parser state correctly) → maps to protocol reentrancy

Key Concepts:

  • HTTP Syntax: RFC 7230 - “Message Syntax and Routing”
  • HTTP Semantics: RFC 7231 - “Semantics and Content”
  • State Machine Design: “Language Implementation Patterns” Chapter 2 - Terence Parr
  • Parsing Techniques: “Fluent C” Chapter 6 - Christopher Preschern

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Socket programming, state machine understanding

Real world outcome:

$ ./http_server 8080
HTTP/1.1 Server running on port 8080...

# Test with curl:
$ curl -v http://localhost:8080/hello
[SERVER LOG]
Request parsed:
  Method: GET
  URI: /hello
  Version: HTTP/1.1
  Headers:
    Host: localhost:8080
    User-Agent: curl/7.68.0
    Accept: */*
  Body: (none)
Response sent: 200 OK

# Test chunked encoding:
$ curl -H "Transfer-Encoding: chunked" -d @largefile.txt http://localhost:8080/upload
[SERVER LOG]
Chunked request received:
  Chunk 1: 1000 bytes
  Chunk 2: 1000 bytes
  Chunk 3: 234 bytes
  Final chunk: 0 bytes (end)
Total body: 2234 bytes

Implementation Hints: HTTP is line-based: request line, then headers (each ending with CRLF), then empty line, then body. But watch out: headers can be folded (continuation with whitespace), Content-Length and Transfer-Encoding determine body handling, and you must handle requests arriving byte-by-byte (TCP doesn’t preserve message boundaries). Implement as a state machine: PARSING_REQUEST_LINE, PARSING_HEADERS, PARSING_BODY, COMPLETE.

Learning milestones:

  1. Parse simple GET requests → You understand HTTP framing
  2. Handle all header edge cases → You understand text protocol parsing
  3. Chunked encoding works → You understand streaming body protocols
  4. Keep-alive handles 100 requests → You understand connection reuse
  5. Proper error responses for malformed requests → You understand error handling in protocols

Project 9: HTTP/2 Frame Parser

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: C, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Application Layer / Binary Protocols
  • Software or Tool: HTTP/2 Protocol
  • Main Book: “HTTP/2 in Action” by Barry Pollard

What you’ll build: An HTTP/2 frame parser and multiplexer that handles the binary framing layer: frame types (DATA, HEADERS, SETTINGS, etc.), stream multiplexing, flow control, and HPACK header compression.

Why it teaches protocol specifications: HTTP/2 (RFC 7540) demonstrates protocol evolution. It solves HTTP/1.1’s head-of-line blocking with multiplexing, reduces overhead with binary framing and header compression. You’ll see how protocols are designed to fix predecessors’ problems while maintaining semantic compatibility.

Core challenges you’ll face:

  • Binary frame parsing (9-byte header, type-specific payloads) → maps to binary protocol design
  • Stream multiplexing (interleaved frames, stream IDs) → maps to protocol multiplexing
  • HPACK decompression (static table, dynamic table, Huffman) → maps to protocol compression
  • Flow control (per-stream and connection windows) → maps to backpressure in protocols
  • Settings negotiation (SETTINGS frames, ACKs) → maps to protocol negotiation

Key Concepts:

  • HTTP/2 Framing: RFC 7540, Section 4
  • HPACK Compression: RFC 7541 - “HPACK: Header Compression”
  • Stream States: RFC 7540, Section 5.1
  • HTTP/2 Design: “HTTP/2 in Action” - Barry Pollard

Difficulty: Expert Time estimate: 3-4 weeks Prerequisites: Project 8, binary parsing experience, understanding of multiplexing

Real world outcome:

$ ./h2_analyzer --capture localhost:443
Connected to localhost:443 via TLS + HTTP/2

[FRAME] Type=SETTINGS, Stream=0, Length=18
  SETTINGS_MAX_CONCURRENT_STREAMS = 100
  SETTINGS_INITIAL_WINDOW_SIZE = 65535

[FRAME] Type=SETTINGS, Stream=0, Length=0, Flags=ACK

[FRAME] Type=HEADERS, Stream=1, Length=45, Flags=END_HEADERS
  HPACK decoded:
    :method = GET
    :path = /
    :authority = localhost

[FRAME] Type=DATA, Stream=1, Length=1234, Flags=END_STREAM
  [1234 bytes of response body]

[FRAME] Type=HEADERS, Stream=3, Length=38, Flags=END_HEADERS
  [Second concurrent request on stream 3]

Implementation Hints: Every HTTP/2 frame has a 9-byte header: length (24 bits), type (8 bits), flags (8 bits), reserved (1 bit), stream ID (31 bits). Parse this first. HPACK is the hard part: maintain a dynamic table, look up indices in the static table (RFC 7541 Appendix A), handle Huffman decoding. Start by parsing frames from a Wireshark capture before trying live connections.

Learning milestones:

  1. Parse frame headers correctly → You understand binary framing
  2. Decode SETTINGS and simple HEADERS → You understand HTTP/2 basics
  3. HPACK decompression works → You understand protocol compression
  4. Track multiple streams simultaneously → You understand multiplexing
  5. Implement flow control → You understand backpressure in protocols

Project 10: WebSocket Protocol Implementation

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Application Layer / Real-Time Protocols
  • Software or Tool: WebSocket Server
  • Main Book: “The WebSocket Protocol” (RFC 6455)

What you’ll build: A WebSocket server and client that implements the full RFC 6455: upgrade handshake, frame parsing with masking, ping/pong, fragmentation, and close handshake.

Why it teaches protocol specifications: WebSocket (RFC 6455) shows how protocols can be layered: it upgrades from HTTP, then uses its own binary framing. The masking requirement (client must mask, server must not) teaches you about security constraints in specs. The close handshake shows how protocols handle graceful termination.

Core challenges you’ll face:

  • HTTP Upgrade handshake (Sec-WebSocket-Key, Accept hash) → maps to protocol negotiation
  • Frame parsing (variable-length header, payload length encoding) → maps to efficient framing
  • Masking/unmasking (XOR with 4-byte key) → maps to security requirements
  • Ping/pong (connection keepalive) → maps to protocol liveness
  • Fragmentation (splitting large messages) → maps to streaming in framed protocols

Key Concepts:

  • WebSocket Protocol: RFC 6455 (the entire specification is readable)
  • SHA-1 Hashing: For the Sec-WebSocket-Accept calculation
  • Binary Framing: “High Performance Browser Networking” Chapter 17 - Ilya Grigorik
  • Real-Time Web: “WebSocket” by Andrew Lombardi

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: HTTP basics, binary data handling

Real world outcome:

$ ./ws_server 9000
WebSocket server running on port 9000...

# Connect with websocat:
$ websocat ws://localhost:9000
Connected to ws://localhost:9000
> Hello server!
< Hello client! You said: "Hello server!"
> ping
< pong

# Server log:
[HANDSHAKE] Upgrade request from 127.0.0.1
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
[FRAME] Opcode=TEXT, Masked=true, Length=13, Payload="Hello server!"
[FRAME] Opcode=PING received
[FRAME] Opcode=PONG sent

Implementation Hints: The handshake uses SHA-1: concatenate client’s Sec-WebSocket-Key with the magic string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, SHA-1 hash it, base64 encode. Frames have a variable header: first byte is FIN+opcode, second byte is MASK+payload length. If length is 126, next 2 bytes are actual length. If 127, next 8 bytes. Client frames are masked with XOR.

Learning milestones:

  1. Handshake completes → You understand protocol upgrade
  2. Send/receive text frames → You understand basic framing
  3. Masking works correctly → You understand protocol security requirements
  4. Ping/pong implemented → You understand keepalive mechanisms
  5. Large fragmented messages work → You understand message fragmentation

Project 11: SMTP Client from Scratch

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, Rust, C
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Application Layer / Email Protocols
  • Software or Tool: Email Client
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: An SMTP client that connects to mail servers and sends emails by speaking the SMTP protocol directly: EHLO, MAIL FROM, RCPT TO, DATA, and handling responses.

Why it teaches protocol specifications: SMTP (RFC 5321) is a command-response protocol — one of the oldest internet protocols still in heavy use. It demonstrates stateful conversation, multi-line responses, the “dot-stuffing” encoding, and how extensions (ESMTP) are negotiated. You’ll see why email has odd behaviors and how legacy constraints shape protocols.

Core challenges you’ll face:

  • Command-response parsing (3-digit codes, multi-line responses) → maps to text protocol flow
  • ESMTP extension negotiation (EHLO response parsing) → maps to capability discovery
  • STARTTLS upgrade (TLS over existing connection) → maps to in-band security upgrade
  • Message formatting (headers, body, dot-stuffing) → maps to content encoding
  • Error handling (4xx temporary, 5xx permanent) → maps to protocol error semantics

Key Concepts:

  • SMTP Protocol: RFC 5321 - “Simple Mail Transfer Protocol”
  • MIME Encoding: RFC 2045-2049 for attachments
  • STARTTLS: RFC 3207 - “SMTP Service Extension for Secure SMTP”
  • Email Format: RFC 5322 - “Internet Message Format”

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic socket programming, understanding of email

Real world outcome:

$ ./mysmtp --server smtp.gmail.com --port 587 \
           --from me@gmail.com --to friend@example.com \
           --subject "Test Email" --body "Hello from my SMTP client!"

Connecting to smtp.gmail.com:587...
< 220 smtp.gmail.com ESMTP ready
> EHLO myhostname
< 250-smtp.gmail.com at your service
< 250-SIZE 35882577
< 250-STARTTLS
< 250-AUTH LOGIN PLAIN
< 250 OK
> STARTTLS
< 220 2.0.0 Ready to start TLS
[TLS handshake...]
> AUTH LOGIN
< 334 VXNlcm5hbWU6
> [base64 username]
< 334 UGFzc3dvcmQ6
> [base64 password]
< 235 2.7.0 Accepted
> MAIL FROM:<me@gmail.com>
< 250 2.1.0 OK
> RCPT TO:<friend@example.com>
< 250 2.1.5 OK
> DATA
< 354 Go ahead
> Subject: Test Email
> From: me@gmail.com
> To: friend@example.com
>
> Hello from my SMTP client!
> .
< 250 2.0.0 OK
Email sent successfully!

Implementation Hints: SMTP is line-based: send a command, read response lines. Response codes are 3 digits: 2xx=success, 3xx=need more input, 4xx=temporary error, 5xx=permanent error. Multi-line responses have - after the code; last line has space. The DATA command is special: send message ending with a line containing only . (dots at line starts in content must be doubled).

Learning milestones:

  1. Connect and complete EHLO → You understand protocol greeting
  2. Send email without auth → You understand basic SMTP flow
  3. STARTTLS works → You understand security upgrade
  4. AUTH LOGIN/PLAIN works → You understand protocol authentication
  5. Handle multipart MIME → You understand email content encoding

Project 12: FTP Client with Active/Passive Mode

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go, Python
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Application Layer / File Transfer
  • Software or Tool: FTP Client
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: An FTP client that supports both active and passive modes, handling the control connection (commands) and data connection (file transfers) separately.

Why it teaches protocol specifications: FTP (RFC 959) is unique: it uses two connections (control and data), demonstrating how protocols can split concerns. Active vs passive mode shows how protocols adapt to network constraints (NAT/firewalls). The command set is rich, showing how protocols evolve feature sets over time.

Core challenges you’ll face:

  • Dual connection management (control vs data) → maps to multi-channel protocols
  • Active mode (server connects back to client) → maps to connection direction challenges
  • Passive mode (PASV command, client connects out) → maps to NAT traversal
  • Transfer modes (ASCII, Binary) → maps to data encoding options
  • Response parsing (multi-line, various codes) → maps to text protocol parsing

Key Concepts:

  • FTP Protocol: RFC 959 - “File Transfer Protocol”
  • Passive Mode: RFC 1579 - “Firewall-Friendly FTP”
  • FTP Security: RFC 4217 - “FTP Security Extensions” (FTPS)
  • Two Connections: “TCP/IP Illustrated, Volume 1” Chapter 27 - Stevens

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Socket programming, understanding of client/server model

Real world outcome:

$ ./myftp ftp.gnu.org
Connected to ftp.gnu.org
< 220 GNU FTP server ready
> USER anonymous
< 331 Please specify the password
> PASS user@example.com
< 230 Login successful
> PWD
< 257 "/" is the current directory
> PASV
< 227 Entering Passive Mode (209,51,188,20,234,111)
[Parsed: 209.51.188.20:60015]
> LIST
[Connected to data port]
< 150 Here comes the directory listing
drwxr-xr-x    3 ftp      ftp          4096 Jan 01 00:00 gnu
drwxr-xr-x    3 ftp      ftp          4096 Jan 01 00:00 pub
< 226 Directory send OK
> CWD gnu
< 250 Directory successfully changed
> RETR hello-2.10.tar.gz
[Downloading... 741KB received]
< 226 Transfer complete

Implementation Hints: Control connection uses port 21. For PASV mode, parse the 227 response: (h1,h2,h3,h4,p1,p2) means IP h1.h2.h3.h4 port p1*256+p2. Open a new TCP connection to that address for data transfer. Active mode (PORT command) requires you to listen on a port and tell the server where to connect — harder with NAT. Always set binary mode (TYPE I) before file transfers.

Learning milestones:

  1. Login and navigate directories → You understand FTP control channel
  2. LIST in passive mode → You understand data channel setup
  3. Binary file download works → You understand file transfer
  4. Active mode works (local network) → You understand connection direction
  5. Resume interrupted transfers (REST) → You understand protocol features

Project 13: IRC Client and Bot

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, Rust, C
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Application Layer / Real-Time Chat
  • Software or Tool: IRC Client
  • Main Book: “IRC Protocol” (RFC 1459/2812)

What you’ll build: An IRC client that connects to servers, joins channels, sends/receives messages, and handles IRC protocol messages — plus a bot that responds to commands.

Why it teaches protocol specifications: IRC (RFC 1459, updated by RFC 2812) is one of the oldest real-time protocols still in use. It demonstrates message framing (lines), prefix-based routing (server/user prefixes), and numeric reply codes. The protocol is simple enough to implement in a weekend but rich enough to learn from.

Core challenges you’ll face:

  • Message parsing (prefix, command, params) → maps to text message formats
  • Connection registration (NICK, USER, PING/PONG) → maps to protocol handshake
  • Channel operations (JOIN, PART, MODE) → maps to stateful multi-user protocols
  • Numeric replies (3-digit codes with meanings) → maps to protocol response codes
  • CTCP (embedded protocol for actions, version) → maps to protocol layering

Key Concepts:

  • IRC Protocol: RFC 2812 - “Internet Relay Chat: Client Protocol”
  • IRC Server Protocol: RFC 2813 - “IRC Server Protocol”
  • Message Format: RFC 1459, Section 2.3
  • Real-Time Systems: Connection persistence and event handling

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Basic socket programming

Real world outcome:

$ ./myirc --server irc.libera.chat --nick mybot --channel '#test'
Connecting to irc.libera.chat:6667...
< :server NOTICE * :*** Looking up your hostname...
> NICK mybot
> USER mybot 0 * :My IRC Bot
< :server 001 mybot :Welcome to the Libera.Chat Internet Relay Chat Network mybot
> JOIN #test
< :mybot!~mybot@host JOIN #test
< :server 353 mybot = #test :mybot @operator user1 user2
< :server 366 mybot #test :End of /NAMES list.

[#test] <user1> Hello everyone!
[#test] <user2> !help
> PRIVMSG #test :Available commands: !help, !time, !dice
[#test] <mybot> Available commands: !help, !time, !dice
[#test] <user2> !dice
[#test] <mybot> 🎲 You rolled: 4

Implementation Hints: IRC messages are CRLF-terminated lines: [:prefix] command params.... Parse the optional prefix (starts with :), then the command, then space-separated params (last param can have spaces if it starts with :). Respond to PING with PONG to stay connected. Track channel state to know who’s in each channel. CTCP is embedded in PRIVMSG with \x01 delimiters.

Learning milestones:

  1. Connect and register → You understand IRC handshake
  2. Join channels and send messages → You understand basic IRC operations
  3. Parse all message types → You understand IRC message format
  4. Bot responds to commands → You understand event-driven protocol handling
  5. Handle CTCP (VERSION, ACTION) → You understand embedded protocols

Project 14: DHCP Client Implementation

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Network Layer / Auto-Configuration
  • Software or Tool: DHCP Client
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A DHCP client that discovers servers, requests an IP address, and handles lease renewal — using broadcast UDP and the DORA (Discover, Offer, Request, Ack) process.

Why it teaches protocol specifications: DHCP (RFC 2131) shows how protocols handle bootstrapping: how does a computer get an IP address before it has an IP address? You’ll understand broadcast protocols, option encoding (RFC 2132), lease management, and state machines for renewal.

Core challenges you’ll face:

  • Broadcast communication (before having an IP) → maps to bootstrap protocols
  • DHCP options encoding (TLV format, many option types) → maps to extensible binary formats
  • Lease state machine (SELECTING, REQUESTING, BOUND, RENEWING) → maps to protocol lifecycle
  • XID matching (correlating requests with responses) → maps to transaction IDs
  • Raw socket for broadcast (bind to 0.0.0.0:68) → maps to special network access

Key Concepts:

  • DHCP Protocol: RFC 2131 - “Dynamic Host Configuration Protocol”
  • DHCP Options: RFC 2132 - “DHCP Options and BOOTP Vendor Extensions”
  • Lease State Machine: RFC 2131, Section 4.4
  • BOOTP Format: RFC 951 (DHCP is based on BOOTP)

Difficulty: Expert Time estimate: 1-2 weeks Prerequisites: Projects 1-3, understanding of IP addressing, raw sockets

Real world outcome:

$ sudo ./mydhcp --interface eth0
DHCP client starting on eth0...
Current state: INIT

[DISCOVER] Broadcasting DHCPDISCOVER
  XID: 0x12345678

[OFFER] Received DHCPOFFER from 192.168.1.1
  Offered IP: 192.168.1.100
  Subnet Mask: 255.255.255.0
  Router: 192.168.1.1
  DNS: 8.8.8.8
  Lease Time: 86400 seconds

[REQUEST] Sending DHCPREQUEST for 192.168.1.100
  XID: 0x12345678

[ACK] Received DHCPACK
  State: SELECTING → BOUND

Configuring interface eth0:
  IP: 192.168.1.100/24
  Gateway: 192.168.1.1
  DNS: 8.8.8.8

Lease bound for 24 hours. Renewal in 12 hours.

[12 hours later]
[RENEWING] Sending DHCPREQUEST for renewal...
[ACK] Lease renewed for another 24 hours.

Implementation Hints: DHCP uses UDP ports 67 (server) and 68 (client). The message format is based on BOOTP: fixed fields (op, htype, hlen, xid, secs, flags, addresses, sname, file) followed by options. Options use TLV encoding: type byte, length byte, value bytes. Magic cookie 0x63825363 starts the options. You need a raw socket to receive broadcasts before having an IP. The state machine is crucial: handle timeouts and retransmissions.

Learning milestones:

  1. DISCOVER sent and OFFER received → You understand broadcast protocols
  2. Full DORA completes → You understand DHCP transaction
  3. Options parsed correctly → You understand TLV encoding
  4. Lease renewal works → You understand protocol state machines
  5. Interface actually configured → You understand OS integration

Project 15: TLS Handshake Analyzer

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Python
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Security / Cryptographic Protocols
  • Software or Tool: TLS Analyzer
  • Main Book: “Bulletproof SSL and TLS” by Ivan Ristić

What you’ll build: A tool that captures and decodes TLS handshakes, showing every message: ClientHello (cipher suites, extensions), ServerHello, Certificate, key exchange, and Finished — all without decrypting application data.

Why it teaches protocol specifications: TLS (RFC 8446 for 1.3, RFC 5246 for 1.2) is the most important security protocol on the internet. Understanding the handshake teaches you: how protocols negotiate parameters, how public key crypto establishes shared secrets, and how protocol evolution (TLS 1.0 → 1.3) happens while maintaining compatibility.

Core challenges you’ll face:

  • Record layer parsing (type, version, length, fragment) → maps to protocol framing
  • Handshake message types (ClientHello, ServerHello, Certificate, etc.) → maps to complex negotiations
  • Extension parsing (SNI, supported_versions, key_share) → maps to protocol extensibility
  • Certificate chain validation (X.509 parsing, chain building) → maps to trust models
  • TLS 1.2 vs 1.3 differences (different message flows) → maps to protocol evolution

Key Concepts:

  • TLS 1.3: RFC 8446 - “The Transport Layer Security (TLS) Protocol Version 1.3”
  • TLS 1.2: RFC 5246 - “The Transport Layer Security (TLS) Protocol Version 1.2”
  • X.509 Certificates: RFC 5280
  • TLS Deep Dive: “Bulletproof SSL and TLS” - Ivan Ristić

Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Understanding of public key crypto, packet capture experience

Real world outcome:

$ sudo ./tls_analyzer -i eth0 -p 443
Capturing TLS handshakes on eth0:443...

[NEW] 192.168.1.10:54321 → 93.184.216.34:443 (example.com)

→ ClientHello (TLS 1.3)
    Version: TLS 1.2 (compatibility)
    Random: a1b2c3d4e5f6...
    Session ID: (32 bytes)
    Cipher Suites (17):
      - TLS_AES_256_GCM_SHA384
      - TLS_CHACHA20_POLY1305_SHA256
      - TLS_AES_128_GCM_SHA256
      ...
    Extensions:
      - server_name: example.com
      - supported_versions: TLS 1.3, TLS 1.2
      - key_share: x25519 public key
      - signature_algorithms: ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256...

← ServerHello (TLS 1.3)
    Version: TLS 1.2 (compatibility)
    Random: f6e5d4c3b2a1...
    Cipher Suite: TLS_AES_256_GCM_SHA384
    Extensions:
      - supported_versions: TLS 1.3
      - key_share: x25519 server public key

← EncryptedExtensions

← Certificate
    Chain length: 2
    [0] CN=example.com
        Issuer: DigiCert TLS RSA SHA256 2020 CA1
        Valid: 2024-01-15 to 2025-01-15
        SANs: example.com, www.example.com
    [1] CN=DigiCert TLS RSA SHA256 2020 CA1
        Issuer: DigiCert Global Root CA

← CertificateVerify (signature verification)
← Finished (handshake MAC)
→ Finished
[ESTABLISHED] TLS 1.3 with TLS_AES_256_GCM_SHA384

Implementation Hints: TLS records have a 5-byte header: type (1), version (2), length (2). Handshake messages have a 4-byte header: type (1), length (3). ClientHello contains variable-length lists: cipher suites, compression methods, extensions. Each extension is TLV: type (2), length (2), data. Parse carefully — off-by-one errors will break everything. Don’t try to decrypt; just parse the plaintext handshake.

Learning milestones:

  1. Parse record layer → You understand TLS framing
  2. Decode ClientHello completely → You understand TLS negotiation
  3. Parse certificates (X.509) → You understand PKI basics
  4. Distinguish TLS 1.2 vs 1.3 → You understand protocol evolution
  5. Detect downgrade attacks → You understand security properties

Project 16: MQTT Broker (Simplified)

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: Go, C, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Application Layer / IoT Protocols
  • Software or Tool: MQTT Broker
  • Main Book: “MQTT Essentials” (HiveMQ Blog Series)

What you’ll build: An MQTT broker that handles CONNECT, PUBLISH, SUBSCRIBE, and manages topic subscriptions with QoS 0 (at most once delivery) — the core of IoT messaging.

Why it teaches protocol specifications: MQTT (v3.1.1: standard, v5.0: OASIS standard) is designed for constrained devices and low-bandwidth networks. It demonstrates publish-subscribe patterns, topic wildcards, quality of service levels, and session state. The binary encoding is compact and efficient.

Core challenges you’ll face:

  • Binary packet parsing (variable-length encoding) → maps to efficient binary protocols
  • Topic matching (wildcards: +, #) → maps to pattern matching in protocols
  • Session state (clean session vs persistent) → maps to stateful vs stateless design
  • QoS handling (0, 1, 2 with different guarantees) → maps to delivery semantics
  • Connection keepalive (PINGREQ/PINGRESP) → maps to connection liveness

Key Concepts:

  • MQTT Protocol: MQTT v3.1.1 Specification (OASIS Standard)
  • Publish-Subscribe Pattern: “Enterprise Integration Patterns” - Hohpe & Woolf
  • QoS Levels: MQTT spec Section 4.3
  • IoT Protocols: “Building the Web of Things” - Guinard & Trifa

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Socket programming, understanding of pub-sub

Real world outcome:

$ ./mybroker --port 1883
MQTT Broker started on port 1883

# Client 1 (subscriber):
$ mosquitto_sub -h localhost -t 'sensors/+/temperature'
[Connected to broker]
[Subscribed to sensors/+/temperature]
sensors/living-room/temperature: 22.5
sensors/bedroom/temperature: 19.8

# Client 2 (publisher):
$ mosquitto_pub -h localhost -t 'sensors/living-room/temperature' -m '22.5'
$ mosquitto_pub -h localhost -t 'sensors/bedroom/temperature' -m '19.8'

# Broker log:
[CONNECT] Client 'sub-client-1' connected (clean_session=true)
[SUBSCRIBE] Client 'sub-client-1' subscribed to 'sensors/+/temperature' QoS=0
[CONNECT] Client 'pub-client-1' connected
[PUBLISH] Topic='sensors/living-room/temperature' QoS=0 Payload='22.5'
  → Forwarding to 1 subscriber(s)
[PUBLISH] Topic='sensors/bedroom/temperature' QoS=0 Payload='19.8'
  → Forwarding to 1 subscriber(s)

Implementation Hints: MQTT uses variable-length integer encoding: each byte’s MSB indicates if more bytes follow. Packet types are in the first byte’s upper nibble. CONNECT contains client ID, optional will message, username/password. SUBSCRIBE contains a list of topic filters with QoS. Topic matching: + matches one level, # matches everything remaining. Maintain a data structure mapping topic patterns to subscribed clients.

Learning milestones:

  1. CONNECT/CONNACK works → You understand MQTT connection
  2. PUBLISH forwarded to subscribers → You understand pub-sub
  3. Topic wildcards work → You understand pattern matching
  4. QoS 0 complete → You understand basic delivery
  5. Session persistence optional → You understand stateful protocols

Project 17: BGP Route Simulator

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 5: Master
  • Knowledge Area: Routing / Internet Architecture
  • Software or Tool: BGP Simulator
  • Main Book: “BGP” by Iljitsch van Beijnum

What you’ll build: A BGP route simulator that maintains routing tables, exchanges UPDATE messages with peers, implements path selection, and simulates route propagation across a network of virtual routers.

Why it teaches protocol specifications: BGP (RFC 4271) is the protocol that makes the internet work. It teaches policy-based routing, path vector algorithms, and how autonomous systems interconnect. Understanding BGP means understanding internet architecture and why routing incidents happen.

Core challenges you’ll face:

  • FSM implementation (Idle, Connect, Active, OpenSent, OpenConfirm, Established) → maps to complex state machines
  • UPDATE parsing (path attributes, NLRI, withdrawn routes) → maps to binary message formats
  • Path selection algorithm (LOCAL_PREF, AS_PATH, MED, etc.) → maps to decision algorithms
  • Route table management (RIB-In, Loc-RIB, RIB-Out) → maps to routing state
  • Timer management (Hold, Keepalive, ConnectRetry) → maps to protocol timing

Key Concepts:

  • BGP Protocol: RFC 4271 - “A Border Gateway Protocol 4 (BGP-4)”
  • Path Selection: RFC 4271 Section 9.1
  • BGP FSM: RFC 4271 Section 8
  • Practical BGP: “BGP” by Iljitsch van Beijnum (O’Reilly)

Difficulty: Master Time estimate: 1-2 months Prerequisites: Strong networking knowledge, experience with routing concepts

Real world outcome:

$ ./bgp_sim --topology network.yaml
Loading topology with 5 routers, 3 AS...

[Router AS65001-R1] Starting BGP
[Router AS65002-R1] Starting BGP
[Router AS65003-R1] Starting BGP

[AS65001-R1 ↔ AS65002-R1] TCP connection established
[AS65001-R1 → AS65002-R1] OPEN: AS=65001, HoldTime=90, RouterID=1.1.1.1
[AS65002-R1 → AS65001-R1] OPEN: AS=65002, HoldTime=90, RouterID=2.2.2.2
[AS65001-R1 ↔ AS65002-R1] Session ESTABLISHED

[AS65001-R1] Advertising 10.1.0.0/16
[AS65001-R1 → AS65002-R1] UPDATE: NLRI=10.1.0.0/16, AS_PATH={65001}, ORIGIN=IGP

[AS65002-R1] Route 10.1.0.0/16 installed via AS65001
  AS_PATH: 65001
  NEXT_HOP: 192.168.1.1
  LOCAL_PREF: 100

[AS65002-R1 → AS65003-R1] UPDATE: NLRI=10.1.0.0/16, AS_PATH={65002,65001}

# Simulate link failure:
$ ./bgp_sim --event "link-down AS65001-R1 AS65002-R1"
[AS65002-R1] Peer AS65001-R1 down (HoldTimer expired)
[AS65002-R1] Withdrawing routes via AS65001
[AS65002-R1 → AS65003-R1] UPDATE: Withdrawn=10.1.0.0/16

Implementation Hints: BGP runs over TCP (port 179). Messages have a 16-byte marker (all 0xff), 2-byte length, 1-byte type. UPDATE messages are complex: withdrawn routes length, withdrawn routes, path attributes length, path attributes, NLRI. Path attributes include ORIGIN, AS_PATH, NEXT_HOP, LOCAL_PREF, MED. Simulate multiple routers in one process with virtual connections. Implement the FSM strictly per RFC.

Learning milestones:

  1. TCP connection and OPEN exchange → You understand BGP setup
  2. UPDATE messages parsed → You understand BGP message format
  3. Path selection working → You understand BGP decision process
  4. Route propagation across AS → You understand internet routing
  5. Convergence on topology change → You understand routing dynamics

Project 18: Design Your Own Protocol (RFC-Style)

  • File: NETWORK_PROTOCOLS_FROM_SPEC_TO_PRACTICE.md
  • Main Programming Language: Your Choice
  • Alternative Programming Languages: N/A (focus on specification)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Protocol Design / Standards
  • Software or Tool: Custom Protocol
  • Main Book: RFC 2119 (“Key words for use in RFCs”)

What you’ll build: A complete protocol specification in RFC format for a real problem, plus a reference implementation. Examples: a file synchronization protocol, a distributed lock service protocol, or a real-time collaboration protocol.

Why it teaches protocol specifications: The ultimate test of understanding protocols is designing one. You’ll face every decision: text vs binary, stateful vs stateless, how to handle errors, how to version, how to extend. Writing the spec forces clarity; implementing it reveals what you missed.

Core challenges you’ll face:

  • Requirements analysis (what problem are you solving?) → maps to protocol purpose
  • Message format design (efficient, parseable, extensible) → maps to encoding decisions
  • State machine design (what states, what transitions?) → maps to protocol behavior
  • Error handling (what can go wrong, how to recover?) → maps to robustness
  • Security considerations (authentication, encryption, replay) → maps to protocol security
  • Writing clear spec (unambiguous, testable) → maps to technical writing

Key Concepts:

  • RFC Keywords: RFC 2119 - “Key words for use in RFCs to Indicate Requirement Levels”
  • Protocol Design: “Designing Distributed Systems” - Brendan Burns
  • IETF Process: RFC 2026 - “The Internet Standards Process”
  • Good Spec Examples: Read well-written RFCs (RFC 7230, RFC 8446)

Difficulty: Expert (design), Intermediate-Advanced (implementation) Time estimate: 2-4 weeks Prerequisites: Completed several protocol projects, good technical writing skills

Real world outcome:

# Your RFC Document:
RFC XXXX: Simple File Synchronization Protocol (SFSP)

Abstract
  This document specifies the Simple File Synchronization Protocol,
  a binary protocol for efficient bidirectional file synchronization
  between two endpoints over TCP.

1. Introduction
   SFSP is designed for environments where...

2. Protocol Overview
   2.1. Connection Establishment
   2.2. Handshake Phase
   2.3. Synchronization Phase
   2.4. Termination

3. Message Format
   All messages begin with a 4-byte header:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |     Type      |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   3.1. HELLO Message
   3.2. MANIFEST Message
   3.3. REQUEST Message
   3.4. DATA Message
   3.5. ACK Message
   3.6. ERROR Message

4. Protocol Operation
   The synchronization process MUST proceed as follows:

   1. Client sends HELLO
   2. Server responds with HELLO
   3. Both parties exchange MANIFEST
   ...

5. Security Considerations
   5.1. Authentication
   5.2. Integrity
   5.3. Confidentiality

Appendix A. Example Message Exchange
Appendix B. Reference Implementation Notes

# Your reference implementation:
$ ./sfsp_server --dir /shared --port 9999
SFSP Server v1.0 listening on port 9999

$ ./sfsp_client --server localhost:9999 --dir /local
Connecting to localhost:9999...
[HELLO] Protocol version 1, features: COMPRESSION
[MANIFEST] Local: 45 files, Remote: 47 files
[SYNC] Need: 3 files from server, Send: 1 file to server
[REQUEST] document.pdf (1.2MB)
[DATA] Receiving document.pdf... 100%
[DATA] Sending notes.txt... 100%
[ACK] Synchronization complete

Implementation Hints: Start with the problem, not the solution. What are you synchronizing? What happens on conflict? What about partial failures? Draft message formats on paper. Use RFC 2119 keywords: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY. Write the spec first, then implement. Your spec should be detailed enough that someone else could implement a compatible version without seeing your code.

Learning milestones:

  1. Problem statement written → You understand the problem space
  2. Message formats designed → You understand protocol encoding
  3. State machine documented → You understand protocol behavior
  4. Security section complete → You understand protocol threats
  5. Reference implementation passes interop test → Your spec is implementable

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
1. ICMP Ping Intermediate Weekend ⭐⭐⭐ ⭐⭐⭐
2. ARP Cache Viewer Advanced 1 week ⭐⭐⭐⭐ ⭐⭐⭐⭐
3. Traceroute Intermediate Weekend ⭐⭐⭐ ⭐⭐⭐⭐
4. TCP Handshake Visualizer Expert 2 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
5. Minimal TCP Stack Master 1-2 months ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
6. UDP Reliability Layer Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
7. DNS Resolver Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
8. HTTP/1.1 Parser Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐
9. HTTP/2 Frame Parser Expert 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
10. WebSocket Implementation Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
11. SMTP Client Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐
12. FTP Client Intermediate 1 week ⭐⭐⭐ ⭐⭐
13. IRC Client/Bot Intermediate Weekend ⭐⭐⭐ ⭐⭐⭐⭐⭐
14. DHCP Client Expert 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
15. TLS Handshake Analyzer Expert 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
16. MQTT Broker Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
17. BGP Route Simulator Master 1-2 months ⭐⭐⭐⭐⭐ ⭐⭐⭐
18. Design Your Own Protocol Expert 2-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

Based on your goal of understanding protocols “from specification to practice,” here’s the optimal path:

Phase 1: Network Layer Foundations (2-3 weeks)

Projects: 1 (ICMP Ping) → 3 (Traceroute) → 2 (ARP)

Start here to understand how packets actually travel across networks. You’ll work with raw sockets, read your first RFCs, and see that protocols are just bytes with rules.

Phase 2: Transport Layer Mastery (3-4 weeks)

Projects: 4 (TCP Visualizer) → 6 (UDP Reliability) → 5 (TCP Stack, optional)

This is where you internalize how reliable communication works over unreliable networks. Project 4 shows you TCP’s complexity; Project 6 makes you recreate it; Project 5 is the ultimate challenge.

Phase 3: Application Layer Breadth (4-6 weeks)

Projects: 7 (DNS) → 8 (HTTP/1.1) → 10 (WebSocket) → 11 (SMTP)

Now you understand how protocols are layered and how applications communicate. DNS shows distributed lookup, HTTP shows request-response, WebSocket shows upgrade mechanisms.

Phase 4: Advanced Topics (4-6 weeks)

Projects: 9 (HTTP/2) → 15 (TLS) → 16 (MQTT)

Binary protocols, security protocols, pub-sub patterns. This is modern protocol design.

Phase 5: Protocol Design (2-4 weeks)

Project: 18 (Design Your Own)

The capstone. You now understand protocols well enough to design one.

Final Capstone Project: Full-Stack Protocol Implementation

After completing the learning path, build this comprehensive project that ties everything together:

Project: Secure Chat System (Ground Up)

What you’ll build: A complete secure chat system implementing:

  • Custom transport protocol (your UDP reliability layer or TCP)
  • Custom application protocol (your design, RFC-documented)
  • TLS-like security layer (simplified, but with proper key exchange)
  • Server discovery (mDNS or custom)
  • Client and server implementations

Why this is the ultimate test: You’ll use every skill: raw sockets, state machines, binary parsing, security, protocol design, specification writing. When it works, you’ve truly mastered network protocols.

Real world outcome:

# Start server
$ ./chat_server --port 9000 --announce
SecureChat Server v1.0
Announcing via mDNS as _securechat._tcp.local
Listening on port 9000...

# Client discovery
$ ./chat_client --discover
Discovering SecureChat servers...
Found: ChatRoom @ 192.168.1.50:9000
Found: DevChat @ 192.168.1.100:9000

# Connect and chat
$ ./chat_client --connect 192.168.1.50:9000 --nick alice
Connecting to 192.168.1.50:9000...
[HANDSHAKE] Exchanging keys...
[SECURE] Connection established (ECDH + ChaCha20-Poly1305)
[JOIN] You joined as 'alice'
[ROOM] Users online: bob, carol

<bob> Hey alice!
> Hello everyone!
<alice> Hello everyone!

# Your protocol trace:
[TRACE] TX: HELLO version=1 features=COMPRESSION|ENCRYPTION
[TRACE] RX: HELLO version=1 features=COMPRESSION|ENCRYPTION
[TRACE] TX: KEY_EXCHANGE pubkey=04a1b2c3...
[TRACE] RX: KEY_EXCHANGE pubkey=04d4e5f6...
[TRACE] Derived shared secret, switching to encrypted mode
[TRACE] TX: [encrypted] AUTH nick="alice"
[TRACE] RX: [encrypted] AUTH_OK

Essential Resources

Books (Primary References)

  1. “TCP/IP Illustrated, Volume 1” by W. Richard Stevens — The reference for protocol internals
  2. “Computer Networks” by Tanenbaum — Comprehensive theory and design principles
  3. “The Linux Programming Interface” by Kerrisk — Socket programming on Linux
  4. “Bulletproof SSL and TLS” by Ristić — Modern TLS deep dive

RFC Reading Guide

Start with these well-written, foundational RFCs:

  • RFC 791 (IP) — Network layer basics
  • RFC 793 (TCP) — The canonical stateful protocol
  • RFC 1035 (DNS) — Binary protocol example
  • RFC 2616/7230 (HTTP) — Text protocol evolution
  • RFC 8446 (TLS 1.3) — Modern security protocol

Online Resources

  • Beej’s Guide to Network Programming — Classic socket programming tutorial
  • “Let’s code a TCP/IP stack” (Saminiir) — Excellent TCP implementation guide
  • Julia Evans’ Networking Zines — Visual protocol explanations
  • Wireshark — Essential for seeing protocols in action

Summary

# Project Main Language
1 ICMP Ping Implementation C
2 ARP Cache Viewer and Spoofer C
3 Traceroute Implementation C
4 TCP Three-Way Handshake Visualizer C
5 Minimal TCP Stack (User-Space) C
6 UDP Reliability Layer C
7 DNS Resolver from Scratch C
8 HTTP/1.1 Protocol Parser C
9 HTTP/2 Frame Parser Rust
10 WebSocket Protocol Implementation C
11 SMTP Client from Scratch Python
12 FTP Client with Active/Passive Mode C
13 IRC Client and Bot Python
14 DHCP Client Implementation C
15 TLS Handshake Analyzer C
16 MQTT Broker (Simplified) Rust
17 BGP Route Simulator C
18 Design Your Own Protocol (RFC-Style) Your Choice

“The best way to understand a protocol is to implement it wrong, then read the RFC, then implement it again.”

Good luck on your journey from specification to implementation!