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 take you from basic socket programming to implementing real-world protocols from their RFC specifications.

Goal: Build the ability to read a protocol specification and turn it into a correct, interoperable implementation. You will learn how to translate RFC diagrams into byte layouts, how state machines control real traffic, how to debug mismatched implementations, and how to build tooling that reveals what’s happening on the wire. By the end, you will be able to implement or audit a protocol, write a small RFC-style spec of your own, and reason about performance and security implications of design choices.

Why Network Protocol Specifications Matter

Protocols are not just APIs. They are contracts that must work across operating systems, vendors, and decades of legacy behavior. In practice, even tiny ambiguities cause outages or security bugs.

Some real-world signals that protocols and specs dominate the modern Internet:

HTTPS is effectively universal: Google reports that HTTPS navigations in Chrome reached roughly 95-99% around 2020 and have plateaued since then, motivating Chrome’s move toward HTTPS-by-default. (This only happened because TLS specs became predictable and interoperable.)
HTTP is evolving in production: In Cloudflare’s 2025 Year in Review, global requests were roughly 50% HTTP/2, 21% HTTP/3, and 29% HTTP/1.x, showing real migration to new wire formats and transports.
DNS root is globally distributed: The DNS root is served by 13 named authorities implemented as hundreds of anycast instances worldwide, meaning protocol correctness matters at Internet scale.

Sources:

Google Security Blog, "HTTPS by default" (2025): https://security.googleblog.com/2025/09/https-by-default.html
Cloudflare Radar, 2025 Year in Review: https://blog.cloudflare.com/2025-year-in-review/
IANA Root Servers: https://www.iana.org/domains/root/servers

Loose Protocol                Strict Protocol
+---------------+             +--------------------------+
| "It works on   |             | RFC defines exact bytes, |
|  my machine"   |             | states, and timeouts     |
+-------+-------+             +--------------+-----------+
        |                                     |
        v                                     v
  Interop failures                      Works everywhere
  Security gaps                          Debuggable at scale

The RFC Language is a Contract

When you read MUST, SHOULD, and MAY, you’re reading normative requirements. RFC 2119 defines these keywords, and RFC 8174 clarifies that they only carry special meaning when UPPERCASE is used. Your implementation must track these requirements to be interoperable.

Specifications as “Source Code”

You are going to treat RFCs the way systems programmers treat a header file or ABI spec:

Field layouts become struct definitions.
State machines become explicit transition logic.
Timers and retries become measured timeouts.
Error semantics become test cases.

Prerequisites & Background Knowledge

Before starting these projects, you should have foundational understanding in these areas:

Essential Prerequisites (Must Have)

Programming Skills:

Ability to read and write C comfortably (pointers, structs, sockets)
Familiarity with bitwise operations and endianness
Ability to debug with gdb or similar

Networking Fundamentals:

IP addressing and subnetting basics
TCP vs UDP behavior at a high level
Familiarity with tcpdump or Wireshark
Recommended Reading: “TCP/IP Illustrated, Volume 1” – chapters on IP, ICMP, UDP, TCP

Systems Fundamentals:

Basic Linux process and file descriptor model
Understanding of system calls (socket, bind, recvfrom, sendto)
Recommended Reading: “The Linux Programming Interface” – sockets chapters

Helpful But Not Required

Packet Capture / Analysis:

Wireshark filters, pcap analysis
Can learn during: Projects 4, 7, 9, 15

Linux Kernel Networking:

sk_buff and netfilter basics
Can learn during: Projects 4, 5, 14

Cryptography Basics:

Symmetric vs asymmetric, hashes, key exchange
Can learn during: Project 15

Self-Assessment Questions

Can you open a TCP socket, connect to a server, and exchange bytes without using a library?
Can you parse a binary header that contains bitfields and variable-length sections?
Can you explain how a TCP handshake works at the packet level?
Can you read a small RFC and extract a message format diagram into code?
Can you capture and interpret packets with Wireshark or tcpdump?

If you answered “no” to questions 1-3: Spend 1-2 weeks on sockets and binary parsing before starting.

Development Environment Setup

Required Tools:

Linux machine (Ubuntu 22.04+ or Debian 12+ recommended)
gcc or clang
tcpdump and iproute2
openssl (for TLS project)

Recommended Tools:

Wireshark / tshark
strace, perf, bpftrace
libpcap development headers

Testing Your Setup:

# Verify toolchain
$ gcc --version
$ tcpdump --version
$ ip -V

# Check raw socket permissions
$ sudo sysctl net.ipv4.ping_group_range

Time Investment

Simple projects (1, 3, 11, 13): Weekend (4-8 hours each)
Moderate projects (2, 6, 7, 8, 10, 12, 16): 1-2 weeks each
Complex projects (4, 14, 15): 2-3 weeks each
Deep projects (5, 9, 17, 18): 1-2 months each

Important Reality Check

Protocols are built for interoperability, not developer comfort. Expect edge cases, subtle timing bugs, and unexpected behavior from real-world servers. The learning curve is normal and is the point.

Core Concept Analysis

1) Layering and Encapsulation

Every protocol is wrapped inside another. You will implement logic that respects this boundary.

Application data
   v
[TCP header][Payload]
   v
[IP header][TCP header][Payload]
   v
[Ethernet header][IP header][TCP header][Payload]

Key insight: Bugs often come from violating layer assumptions (e.g., confusing message boundaries in TCP).

2) Framing and Parsing

Protocols need to find message boundaries:

Length-prefixed (DNS, QUIC)
Delimiter-based (HTTP/1.1, SMTP)
Fixed-size (TCP header, ICMP)

Key insight: TCP is a byte stream; framing is your job.

3) State Machines

Protocols are rarely stateless:

TCP: 11 states
DHCP: INIT -> SELECTING -> BOUND
TLS: handshake stages

SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> TIME_WAIT

Key insight: Most bugs are incorrect transitions or missing edge states.

4) Reliability and Congestion Control

Reliability uses ACKs + retransmission, while congestion control prevents network collapse. TCP and QUIC combine both to keep the Internet stable.

Key insight: Reliability without congestion control breaks the Internet.

5) Security & Trust Boundaries

Protocols define who can spoof, replay, or downgrade messages. Security properties are part of the spec, not an afterthought.

Key insight: If the spec does not authenticate it, assume it can be forged.

6) Extensibility and Versioning

Protocols survive by designing for change (options, TLVs, negotiation). HTTP/2, TLS 1.3, and QUIC are examples of evolutionary design.

Key insight: Hardcoded assumptions become future interoperability failures.

Concept Summary Table

Concept	What You Must Internalize	Projects
Byte order & checksums	Endianness, ones’ complement checksum	1, 2, 3
Framing	Length-prefix vs delimiter parsing	7, 8, 9, 10
State machines	Explicit transitions with timers	4, 5, 14, 15, 17
Reliability	ACKs, retransmission, loss	5, 6, 9
Flow/congestion control	Windows, cwnd, backpressure	5, 6, 9
Security properties	Authentication, confidentiality	10, 15
Protocol evolution	Versioning, negotiation	8, 9, 10, 15, 16

Deep Dive Reading by Concept

Concept	Primary Book	Suggested Chapters / Sections
Socket API	UNIX Network Programming Vol 1 (Stevens)	Ch. 1-6 (sockets, TCP/UDP basics)
IP/ICMP/ARP	TCP/IP Illustrated Vol 1 (Stevens/Fall)	IP, ARP, ICMP chapters
TCP Internals	TCP/IP Illustrated Vol 1 + Understanding Linux Network Internals	TCP chapters; Linux TCP implementation chapters
Protocol Design	Computer Networks (Tanenbaum)	Ch. 1-5 (layering, transport, routing)
Binary Parsing	Fluent C (Preschern)	Parsing + state machine sections
Security / TLS	Bulletproof SSL and TLS (Ristic)	TLS handshake and PKI chapters

Quick Start (First 48 Hours)

Day 1

Read RFC 792 (ICMP) and write the ICMP Echo header struct.
Send a raw ICMP Echo Request to localhost and parse the reply.
Capture it with tcpdump -nn -vv icmp.

Day 2

Read the DNS header format in RFC 1035.
Write a DNS query builder for A records.
Parse the response from 8.8.8.8 and print the answer.

Recommended Learning Paths

Path A: Systems Programmer (C-first) 1 -> 3 -> 4 -> 6 -> 5 -> 7 -> 8 -> 9 -> 15 -> 17 -> 18

Path B: Web/Backend Engineer 8 -> 10 -> 9 -> 15 -> 7 -> 6 -> 18

Path C: Network/Security Engineer 1 -> 3 -> 7 -> 4 -> 15 -> 14 -> 17 -> 18

Big Picture / Mental Model

Spec -> Model -> Implementation -> Wire -> Capture -> Debug -> Correctness
   |        |          |               |        |           |
   v        v          v               v        v           v
 RFC     State     Socket code      Packets   Wireshark   Interop

Success Metrics

By the end you should be able to:

Implement a protocol directly from an RFC without copy/pasting a library.
Debug mismatched implementations with packet captures.
Explain how protocol state machines handle timeouts and retries.
Write a short RFC-style spec and build a compatible implementation.
Build at least one protocol analyzer or debugger.

How to Use This Guide

Read the RFC first – even if it feels slow.
Draw the message format in your notebook.
Implement parsing and serialization with tests.
Replay real traffic to validate behavior.
Capture and compare your implementation vs a known-good tool.
Write down every ambiguity you find in the RFC.

Core Subsystem Walkthrough (User Space -> Kernel -> Wire)

App (user space)
  -> socket()/connect()/send()
  -> libc -> syscall
  -> kernel TCP/UDP stack
  -> IP layer (routing, fragmentation)
  -> netfilter / firewall
  -> driver / NIC DMA
  -> Ethernet -> switch -> Internet

Key Linux files to map this flow:

net/ipv4/tcp.c, net/ipv4/udp.c
net/ipv4/ip_output.c
net/core/dev.c

Directories:

net/ipv4/ – TCP, UDP, ICMP
net/ipv6/ – IPv6 stack
net/core/ – generic networking
include/linux/ – skbuff.h, netdevice.h, socket.h

Useful ripgrep patterns:

rg "struct sk_buff" include/linux -n
rg "tcp_v4_connect|tcp_v4_rcv" net/ipv4 -n
rg "icmp_send|icmp_rcv" net/ipv4 -n
rg "udp_rcv|udp_sendmsg" net/ipv4 -n

Debugging Toolkit

Packet capture: tcpdump, tshark, Wireshark

Socket state: ss -tanp, ss -uap, netstat -s

Routing/ARP: ip route, ip neigh, arp -n

Kernel tracing: ftrace, perf, trace-cmd, bpftrace

Traffic control: tc qdisc, tc netem (simulate loss/latency)

Namespace isolation: ip netns, nsenter

Kernel Data Structure Atlas (Networking)

Struct	Purpose	Location
`sk_buff`	Packet buffer	`include/linux/skbuff.h`
`sock`	Generic socket	`include/net/sock.h`
`tcp_sock`	TCP-specific state	`include/net/tcp.h`
`udp_sock`	UDP-specific state	`include/net/udp.h`
`net_device`	NIC abstraction	`include/linux/netdevice.h`
`dst_entry`	Routing destination	`include/net/dst.h`
`neighbour`	ARP/ND cache entry	`include/net/neighbour.h`

Kernel Contribution Checklist (Networking)

Run scripts/checkpatch.pl on patches
Use scripts/get_maintainer.pl to find reviewers
Follow netdev patch submission guidelines
Include packet captures or reproduction steps
Keep commits focused (one logical change each)

Common Failure Signatures

Problem: “Ping sends but no replies”

Why: firewall drops ICMP echo replies, or raw socket blocked
Fix: check iptables/nftables, use sudo or set CAP_NET_RAW
Quick test: sudo ping -c 1 8.8.8.8

Problem: “TCP client hangs in SYN_SENT”

Why: SYN packets not reaching server or blocked
Fix: check routing, verify with tcpdump on both ends
Quick test: tcpdump -nn tcp and port 80

Problem: “DNS returns SERVFAIL”

Why: DNSSEC validation failure or upstream resolver error
Fix: try a different resolver, disable validation during debugging
Quick test: dig +dnssec example.com

Kernel Reading Plan (Networking Focus)

Day 1-2: net/core/ basics (sk_buff, net_device)

Day 3-4: IPv4 receive path (ip_rcv, routing)

Day 5-6: TCP handshake (tcp_v4_connect, tcp_rcv_state_process)

Day 7: UDP path (udp_rcv, udp_sendmsg)

Day 8: ICMP (icmp_rcv, icmp_send)

Day 9: Netfilter hooks and conntrack

Day 10: Packet scheduling and tc

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)                    |  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 small but strict. You’ll translate a spec’s bit diagram into code, handle checksums, and learn why network byte order matters.

Core challenges you’ll face:

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

Key Concepts:

ICMP Protocol: RFC 792
Checksum Algorithms: RFC 1071
Raw Sockets: “The Linux Programming Interface” (sockets chapters)
Byte Ordering: “Computer Systems: A Programmer’s Perspective” (data representation)

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. Build a struct that matches this layout, compute checksum per RFC 1071, and send via sendto() on a raw socket (SOCK_RAW, IPPROTO_ICMP).

Learning milestones:

Raw socket created and packet sent -> you understand protocol layer bypassing
Checksum validates correctly -> you can implement RFC algorithms
RTT calculated accurately -> you understand timing in protocols
Handles unreachable hosts gracefully -> you understand ICMP error messages

The Core Question You’re Answering

How does a protocol that lives “inside IP” report errors and measure reachability without making IP reliable?

Concepts You Must Understand First

IP header basics (RFC 791)
ICMP message types and codes (RFC 792)
Ones’ complement checksum (RFC 1071)
Endianness / network byte order

Questions to Guide Your Design

How will you correlate Echo Replies to requests (identifier + sequence)?
What do you do if you receive ICMP errors (Type 3, 11)?
How will you measure RTT accurately without skew from scheduling?

Thinking Exercise

Take an ICMP Echo Request hex dump from Wireshark. Annotate each field by hand, then verify your parser outputs the same values.

The Interview Questions They’ll Ask

Why does ICMP use a checksum while IP already has one?
What’s the difference between ICMP errors and replies?
Why does ping require raw sockets and privileges?
How does TTL affect ICMP time exceeded messages?

Hints in Layers

Layer 1: Build the struct icmphdr and zero the checksum first.
Layer 2: Use gettimeofday() to stamp send time in payload.
Layer 3: For checksum, sum 16-bit words and fold carries.
Layer 4: Track identifier by PID to distinguish multiple pings.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Operation not permitted”

Why: raw sockets require CAP_NET_RAW or root
Fix: run with sudo or set capabilities
Quick test: sudo ./myping 8.8.8.8

Problem: “Replies never arrive”

Why: firewall drops ICMP or wrong checksum
Fix: disable firewall temporarily, verify checksum in Wireshark
Quick test: tcpdump -nn icmp

Definition of Done

Echo Request packets are correctly formed and checksummed
Echo Replies are parsed and matched to requests
RTT stats match system ping within reasonable tolerance
Handles timeouts and unreachable errors gracefully

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) is the classic example of a protocol that exists because abstraction leaks. IP needs MAC addresses, but IP doesn’t know them. The spec solves that gap with a tiny request/response protocol.

Core challenges you’ll face:

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

Key Concepts:

ARP Protocol: RFC 826
Ethernet Framing: “Computer Networks” (LAN chapters)
Raw Packet Injection: “The Linux Programming Interface”
Security implications: “Practical Packet Analysis”

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, 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:

Read system ARP cache -> you understand OS network state
Send ARP requests and receive replies -> request/response protocol
Detect ARP spoofing attempts -> understand protocol weaknesses
Understand gratuitous ARP -> edge cases and cache updates

The Core Question You’re Answering

How does a host discover link-layer addresses when the network layer only knows IPs?

Concepts You Must Understand First

Ethernet frame structure
ARP request/reply format (RFC 826)
Broadcast vs unicast on Ethernet
ARP cache behavior on Linux

Questions to Guide Your Design

How will you bind to a specific interface and MAC address?
How will you parse and update ARP cache state?
How will you avoid poisoning your own cache during testing?

Thinking Exercise

Capture a real ARP request in Wireshark and manually parse the fields. Recreate that exact frame from your tool.

The Interview Questions They’ll Ask

Why does ARP have no authentication?
What is gratuitous ARP and why is it used?
How does ARP behave across VLANs or routers?
Why does IPv6 not use ARP?

Hints in Layers

Layer 1: Use ioctl(SIOCGIFHWADDR) to get MAC and SIOCGIFADDR for IP.
Layer 2: Build Ethernet header with destination ff:ff:ff:ff:ff:ff.
Layer 3: Fill ARP fields in network byte order.
Layer 4: Use recvfrom() with filter to capture only ARP replies.

Books That Will Help

Common Pitfalls & Debugging

Problem: “No replies”

Why: incorrect Ethernet header or wrong interface
Fix: verify interface index and MAC with ip link
Quick test: tcpdump -e -nn arp

Problem: “Spoofing crashes local network”

Why: repeated gratuitous ARP
Fix: rate-limit and restore cache after tests

Definition of Done

Can query and print local ARP cache
Sends valid ARP requests and parses replies
Can issue a single spoofed reply for demonstration
Restores network state after test

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 exploiting specified behavior.

Core challenges you’ll face:

TTL manipulation -> IP protocol details (RFC 791)
ICMP Time Exceeded parsing -> ICMP message types
UDP/ICMP/TCP probe modes -> protocol flexibility
Async response handling -> stateless protocol challenges
Firewall evasion -> real-world behavior

Key Concepts:

IP TTL Field: RFC 791
ICMP Errors: RFC 792
Routing Basics: “Computer Networks” routing chapters
Paris Traceroute: research 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
192.168.1.1 (192.168.1.1)  1.234 ms  1.123 ms  1.456 ms
10.0.0.1 (10.0.0.1)  8.234 ms  7.891 ms  8.012 ms
* * *
72.14.215.85 (72.14.215.85)  12.345 ms  11.987 ms  12.123 ms
142.250.185.78 (142.250.185.78)  14.234 ms  13.891 ms  14.012 ms

Implementation Hints: Send packets with TTL=1, then TTL=2, then TTL=3, etc. Each router decrements TTL and when it hits 0, the router sends ICMP Time Exceeded. Correlate responses using UDP ports or ICMP sequence numbers.

Learning milestones:

First hop discovered -> TTL mechanics understood
Full path mapped -> multi-hop routing understood
Multiple probe methods working -> protocol alternatives understood
Handles non-responsive hops -> real-world behavior understood

The Core Question You’re Answering

How can you map a path through the Internet without any router cooperation beyond RFC-compliant ICMP errors?

Concepts You Must Understand First

IP header TTL field (RFC 791)
ICMP Time Exceeded (RFC 792)
UDP vs ICMP probe behavior
ICMP quoting rules (original IP header included)

Questions to Guide Your Design

How will you correlate replies to probes across different TTLs?
What do you do with silent routers or firewalled hops?
How will you measure per-hop RTT accurately?

Thinking Exercise

Predict how a NAT or load balancer will affect traceroute output. Compare to a real run.

The Interview Questions They’ll Ask

Why does traceroute use TTL?
Why do some hops show * * *?
What’s the difference between UDP and ICMP traceroute?
How do load balancers break classic traceroute?

Hints in Layers

Layer 1: Use setsockopt(IP_TTL) for each probe.
Layer 2: Set unique UDP ports per TTL to match responses.
Layer 3: Parse ICMP payload to extract original probe.
Layer 4: Implement timeout and retry logic per hop.

Books That Will Help

Common Pitfalls & Debugging

Problem: “All hops show *“

Why: firewall blocks ICMP
Fix: try TCP SYN probes instead
Quick test: sudo ./mytraceroute --tcp 80 example.com

Definition of Done

Shows at least 5 hops on a real Internet path
Supports UDP and ICMP probe modes
Correlates replies to correct TTL
Handles timeouts gracefully

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 is the canonical stateful protocol. Its state machine is defined by RFC 9293 (which consolidates RFC 793 and later updates). You’ll internalize how reliability and flow control are negotiated.

Core challenges you’ll face:

Packet capture (libpcap/raw sockets) -> protocol inspection
TCP state machine tracking -> stateful protocol design
Sequence number tracking -> protocol arithmetic
Options parsing (MSS, Window Scale, SACK, Timestamps) -> extensibility
Connection matching (4-tuple) -> multiplexing

Key Concepts:

TCP Specification: RFC 9293
TCP Options: RFC 7323 (Window Scale, Timestamps)
Connection Tracking: “Understanding Linux Network Internals”

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

Implementation Hints: Use libpcap filter tcp port 80. Parse the TCP header, track each connection by 4-tuple, and apply the state transition rules from RFC 9293. Maintain a small state machine per connection.

Learning milestones:

Capture and parse TCP headers -> TCP header format
Track SYN/SYN-ACK/ACK -> connection establishment
Handle simultaneous open -> edge cases
Track FIN/RST -> teardown
Display options -> extensibility

The Core Question You’re Answering

How does TCP guarantee a reliable, ordered byte stream over an unreliable network?

Concepts You Must Understand First

TCP header layout (RFC 9293)
Sequence/ack number arithmetic
TCP state machine and timers
Window scaling and SACK

Questions to Guide Your Design

How will you normalize sequence numbers for display?
How will you handle retransmissions or duplicate ACKs?
How will you handle out-of-order packets?

Thinking Exercise

Capture a TCP handshake with Wireshark and manually trace the state transitions. Compare to your tool output.

The Interview Questions They’ll Ask

Why does TCP require a 3-way handshake?
What happens if the final ACK is lost?
What is SYN flooding and how does TCP mitigate it?
Why do we need sequence number randomization?

Hints in Layers

Layer 1: Use libpcap and parse Ethernet/IP/TCP headers.
Layer 2: Normalize sequence numbers to relative values.
Layer 3: Implement minimal TCP state machine.
Layer 4: Parse common options (MSS, WS, SACK, TS).

Books That Will Help

Common Pitfalls & Debugging

Problem: “State flips unexpectedly”

Why: multiple connections reuse ports, or you mis-handle direction
Fix: key connections by full 4-tuple and direction

Definition of Done

Detects and displays SYN/SYN-ACK/ACK
Tracks connection state changes correctly
Parses and prints TCP options
Handles connection teardown

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 your OS’s TCP stack via a TUN/TAP interface.

Why it teaches protocol specifications: You’ll implement RFC 9293 from scratch: state machine, sequence numbers, flow control, congestion control, retransmission timers, and error handling.

Core challenges you’ll face:

TUN/TAP interface -> virtual network devices
Full TCP state machine -> complete spec implementation
Retransmission timer -> Karn’s algorithm, exponential backoff
Flow control -> sliding window
Congestion control -> slow start, avoidance

Key Concepts:

TCP Spec: RFC 9293
Congestion Control: RFC 5681
Retransmission Timer: RFC 6298
User-space Networking: “Understanding Linux Network Internals”

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>
...

# 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). Parse IP, then TCP, then implement the handshake. Add data transfer, retransmission, and congestion control last. Use a test harness that simulates loss and reordering.

Learning milestones:

TUN device sending/receiving raw IP -> layering
Three-way handshake completes -> connection setup
Transfer small data reliably -> reliability
Retransmission works -> timers
Browse websites via your stack -> real TCP

The Core Question You’re Answering

What does it take to reimplement TCP correctly enough to interoperate with the Internet?

Concepts You Must Understand First

TCP state machine (RFC 9293)
Sliding window flow control
RTT/RTO estimation
Congestion control basics

Questions to Guide Your Design

How will you schedule retransmissions and avoid spurious timeouts?
How will you manage send/recv buffers and window updates?
How will you implement PMTU discovery or segment sizing?

Thinking Exercise

Write the sequence number and window evolution for a 3-packet transfer with one lost segment. Make sure your design handles it.

The Interview Questions They’ll Ask

Why does TCP need both flow control and congestion control?
How does slow start transition to congestion avoidance?
What is the difference between ACK and SACK?
How does TIME_WAIT prevent old packets from corrupting a new connection?

Hints in Layers

Layer 1: Implement IP + TCP parsing and checksum validation.
Layer 2: Implement handshake state machine and sequence numbers.
Layer 3: Add retransmission timer and basic ACK handling.
Layer 4: Add sliding window + congestion control.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Handshake succeeds but data never arrives”

Why: sequence number or ACK handling wrong
Fix: verify relative sequence/ack in Wireshark

Problem: “Retransmissions never stop”

Why: RTO calculation wrong or ACK parsing wrong
Fix: log RTT samples and verify timers

Definition of Done

Handshake and teardown work with real servers
Data transfer works across loss and reordering
Retransmission timeout adapts to RTT
Congestion window increases/decreases correctly

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: You design your own protocol spec. You’ll face the same tradeoffs as TCP and QUIC designers: ack strategy, sequence number space, timeout adaptation, and flow control.

Core challenges you’ll face:

Sequence number design -> protocol design
Acknowledgment strategy -> efficiency tradeoffs
Retransmission logic -> reliability
Ordering vs reliability -> protocol modularity
API design -> usability

Key Concepts:

Reliable Data Transfer: “Computer Networks” (transport chapter)
Stop-and-Wait vs Sliding Window: Kurose & Ross
QUIC Design: RFC 9000

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 first: sequence number, ack number, flags. Start with stop-and-wait, then sliding window. Use RTT samples to adapt timeouts. Document your protocol like an RFC.

Learning milestones:

Stop-and-wait works -> reliability basics
Handles packet loss -> retransmission
Sliding window implemented -> pipelining
RTT-adaptive timeouts -> practical reliability
Written protocol specification -> spec writing skill

The Core Question You’re Answering

How much reliability can you add over UDP without recreating TCP’s complexity?

Concepts You Must Understand First

UDP properties (RFC 768)
Sequence numbers and windowing
Loss detection and retransmission

Questions to Guide Your Design

How will you detect loss without ACKs for every packet?
How will you avoid head-of-line blocking in your design?
Will you support multiple streams or just one?

Thinking Exercise

Design a 16-bit sequence number scheme. How do you detect wrap-around and duplicates?

The Interview Questions They’ll Ask

Why might you want reliability over UDP?
What is head-of-line blocking and how can you avoid it?
How does QUIC differ from TCP reliability?
What tradeoffs exist between cumulative and selective ACKs?

Hints in Layers

Layer 1: Implement stop-and-wait with sequence + ACK.
Layer 2: Add sliding window and retransmit queue.
Layer 3: Add RTT-based timeout adaptation.
Layer 4: Add optional selective ACK bitmap.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Infinite retransmits”

Why: ACKs not matched to correct sequence
Fix: log seq/ack pairs and confirm wrap handling

Definition of Done

Ordered, reliable delivery across loss
Sliding window implemented
RTT-based timeout adapts
Protocol documented in RFC style

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 to authoritative nameservers.

Why it teaches protocol specifications: DNS (RFC 1035) is a masterclass in compact binary protocol design: variable-length labels, compression pointers, multiple record types, and caching rules.

Core challenges you’ll face:

DNS message format -> binary parsing
Label encoding -> compression pointers
Record type handling -> extensibility
Recursive resolution -> distributed design
Caching -> TTL-based state

Key Concepts:

DNS Protocol: RFC 1035
DNS Message Format: RFC 1035 sections 4.1-4.2
DNSSEC Basics: RFC 4033/4034/4035

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

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: top 2 bits set to 11. Parse carefully and detect loops.

Learning milestones:

Parse DNS responses from 8.8.8.8 -> message format
Handle compression pointers -> binary parsing
Implement recursive resolution -> hierarchy
Add caching with TTL -> stateful handling
Handle multiple record types -> extensibility

The Core Question You’re Answering

How does DNS scale globally while keeping packets tiny and responses fast?

Concepts You Must Understand First

DNS header and sections (RFC 1035)
Name compression pointers
UDP request/response patterns
Cache TTL semantics

Questions to Guide Your Design

How will you prevent compression pointer loops?
How will you decide when to retry via TCP?
How will you cache and expire records?

Thinking Exercise

Manually decode a DNS response hex dump with compression pointers. Verify your output.

The Interview Questions They’ll Ask

Why is DNS usually UDP and sometimes TCP?
What is a DNS referral vs an authoritative answer?
How does DNS caching improve performance?
How does DNSSEC change the trust model?

Hints in Layers

Layer 1: Implement header + question parsing only.
Layer 2: Add answer parsing for A/AAAA records.
Layer 3: Add name compression decoding.
Layer 4: Implement recursive resolution.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Compression pointer loop”

Why: invalid pointer handling
Fix: track visited offsets

Definition of Done

Queries root servers and follows referrals
Correctly decodes compressed names
Supports at least A, AAAA, CNAME
Implements TTL cache

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 full spec behavior: chunked encoding, keep-alive connections, and correct error handling.

Why it teaches protocol specifications: HTTP/1.1 is text-based but subtle. Its updated spec is RFC 9112 (syntax) and RFC 9110 (semantics). You’ll discover how tolerant parsing can still be spec-compliant.

Core challenges you’ll face:

Request line parsing -> framing
Header parsing -> text protocol complexity
Body length determination -> protocol state
Chunked transfer decoding -> streaming
Keep-alive connection reuse -> parser reentrancy

Key Concepts:

HTTP Semantics: RFC 9110
HTTP/1.1 Syntax: RFC 9112
Parsing Techniques: “Fluent C” (state machines)

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...

$ 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
  Body: (none)
Response sent: 200 OK

$ 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, headers, empty line, body. Handle Content-Length vs Transfer-Encoding: chunked. Implement a state machine: REQUEST_LINE -> HEADERS -> BODY -> COMPLETE.

Learning milestones:

Parse simple GET requests -> framing
Handle header edge cases -> parsing
Chunked encoding works -> streaming
Keep-alive handles 100 requests -> reuse
Proper error responses -> robustness

The Core Question You’re Answering

How does a text-based protocol remain interoperable across decades of clients and servers?

Concepts You Must Understand First

HTTP/1.1 syntax (RFC 9112)
HTTP semantics (RFC 9110)
Chunked transfer encoding
Connection reuse and pipelining

Questions to Guide Your Design

How will you parse partial lines arriving byte-by-byte?
How will you prevent header injection or request smuggling?
How will you handle malformed requests?

Thinking Exercise

Build a minimal HTTP request byte-by-byte stream and feed it into your parser one byte at a time.

The Interview Questions They’ll Ask

Why is HTTP/1.1 a byte stream protocol despite being line-based?
How do you detect the end of a request body?
What is chunked transfer encoding and why is it used?
How does keep-alive change parser design?

Hints in Layers

Layer 1: Parse request line and basic headers.
Layer 2: Implement Content-Length handling.
Layer 3: Add chunked decoding.
Layer 4: Add keep-alive + multiple requests per connection.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Parser hangs waiting for body”

Why: incorrect Content-Length or chunked handling
Fix: log parsed lengths and compare to raw capture

Definition of Done

Parses request line, headers, body correctly
Supports chunked requests
Handles keep-alive with multiple requests
Generates correct error responses

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 binary framing: frame types, stream multiplexing, flow control, and HPACK header compression.

Why it teaches protocol specifications: HTTP/2 is now RFC 9113. It replaces text framing with binary frames and introduces multiplexing, flow control, and header compression.

Core challenges you’ll face:

Binary frame parsing -> binary protocol design
Stream multiplexing -> interleaving
HPACK decompression -> compression
Flow control -> backpressure
Settings negotiation -> protocol negotiation

Key Concepts:

HTTP/2 Spec: RFC 9113
HPACK: RFC 7541

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

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=HEADERS, Stream=1, Length=45, Flags=END_HEADERS
  HPACK decoded:
    :method = GET
    :path = /
    :authority = localhost

Implementation Hints: Frame header is 9 bytes: length (24 bits), type (8), flags (8), reserved (1), stream ID (31). HPACK requires a static table and dynamic table with Huffman decoding.

Learning milestones:

Parse frame headers correctly -> framing
Decode SETTINGS and HEADERS -> basics
HPACK decompression works -> compression
Track multiple streams -> multiplexing
Implement flow control -> backpressure

The Core Question You’re Answering

How can HTTP multiplex many concurrent streams without opening many TCP connections?

Concepts You Must Understand First

HTTP/2 frame header format (RFC 9113)
HPACK static/dynamic table
Flow control windows

Questions to Guide Your Design

How will you reorder frames per stream while reading a single byte stream?
How will you handle HEADERS continuation frames?
How will you enforce flow control?

Thinking Exercise

Take a Wireshark HTTP/2 capture and manually parse the first SETTINGS frame bytes.

The Interview Questions They’ll Ask

How does HTTP/2 solve head-of-line blocking?
What is HPACK and why isn’t it just gzip?
Why are stream IDs odd/even for client/server?
What is the difference between stream and connection flow control?

Hints in Layers

Layer 1: Parse 9-byte frame header.
Layer 2: Handle SETTINGS and PING frames.
Layer 3: Implement HEADERS and CONTINUATION.
Layer 4: Add HPACK decoding.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Frame length mismatch”

Why: 24-bit length parsing error
Fix: ensure correct endian and bit shifts

Definition of Done

Parses all frame headers correctly
Decodes SETTINGS and HEADERS frames
HPACK decoding passes test vectors
Tracks stream state transitions

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: RFC 6455

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

Why it teaches protocol specifications: WebSocket upgrades from HTTP and then uses its own binary framing. The masking rule is a security requirement you must implement exactly.

Core challenges you’ll face:

HTTP Upgrade handshake -> negotiation
Frame parsing -> variable-length headers
Masking/unmasking -> XOR with 4-byte key
Ping/pong -> keepalive
Fragmentation -> streaming messages

Key Concepts:

WebSocket Protocol: RFC 6455
SHA-1 Hashing: for Sec-WebSocket-Accept

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...

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

Implementation Hints: Handshake uses SHA-1: concatenate client’s key with magic string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, SHA-1 hash, base64 encode. Frame header uses FIN + opcode, MASK + length (with 126/127 extended lengths). Client must mask; server must not.

Learning milestones:

Handshake completes -> protocol upgrade
Send/receive frames -> framing
Masking works -> security requirement
Ping/pong -> keepalive
Fragmentation -> streaming

The Core Question You’re Answering

How does a protocol safely upgrade from HTTP to a long-lived bidirectional channel?

Concepts You Must Understand First

HTTP upgrade headers
WebSocket frame structure
Masking rules and security rationale

Questions to Guide Your Design

How will you handle fragmented messages?
How will you enforce masking rules for clients vs servers?
How will you close connections gracefully?

Thinking Exercise

Create a raw WebSocket frame by hand and confirm your parser decodes it.

The Interview Questions They’ll Ask

Why must client frames be masked?
How does WebSocket avoid cross-protocol attacks?
What happens if a frame is fragmented?
How does the close handshake work?

Hints in Layers

Layer 1: Implement HTTP upgrade handshake only.
Layer 2: Parse frames with basic lengths.
Layer 3: Implement masking and unmasking.
Layer 4: Handle fragmentation and control frames.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Browser disconnects immediately”

Why: invalid handshake or accept key
Fix: verify key generation and CRLF formatting

Definition of Done

Handshake passes in browser and in websocat
Correctly parses masked frames
Handles ping/pong and close
Supports fragmented messages

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 directly: EHLO, MAIL FROM, RCPT TO, DATA, with TLS upgrade.

Why it teaches protocol specifications: SMTP (RFC 5321) is a command-response protocol with multiline replies, extensions, and legacy constraints. It shows how protocol negotiation works in practice.

Core challenges you’ll face:

Command-response parsing -> text protocol flow
ESMTP extension negotiation -> capability discovery
STARTTLS upgrade -> in-band security
Message formatting -> RFC 5322 + MIME
Error handling -> 4xx vs 5xx responses

Key Concepts:

SMTP Protocol: RFC 5321
Internet Message Format: RFC 5322
STARTTLS: RFC 3207

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic socket programming

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 with 3-digit codes. Multi-line responses have - after the code; last line has a space. DATA is terminated by a line containing only . (dot-stuffing required).

Learning milestones:

Connect and complete EHLO -> protocol greeting
Send email without auth -> basic flow
STARTTLS works -> security upgrade
AUTH LOGIN works -> authentication
Handle MIME -> attachments

The Core Question You’re Answering

How does a decades-old protocol evolve to add security and authentication without breaking compatibility?

Concepts You Must Understand First

SMTP command/response syntax
Multi-line replies
TLS upgrade flow (RFC 3207)
Email header format (RFC 5322)

Questions to Guide Your Design

How will you parse multi-line responses correctly?
How will you handle STARTTLS and reset state?
How will you handle dot-stuffing correctly?

Thinking Exercise

Write a valid RFC 5322 message with headers and body; send it manually using telnet.

The Interview Questions They’ll Ask

Why does SMTP use a separate submission port (587)?
What is dot-stuffing and why is it needed?
How does STARTTLS protect SMTP?
What is the difference between SMTP and IMAP/POP?

Hints in Layers

Layer 1: Implement command send + response parse.
Layer 2: Implement EHLO + capability parsing.
Layer 3: Add STARTTLS + TLS handshake.
Layer 4: Add AUTH and DATA handling.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Server rejects DATA”

Why: missing blank line between headers and body
Fix: ensure \r\n\r\n separation

Definition of Done

Sends a valid SMTP message
Handles multi-line responses
Supports STARTTLS
Supports at least one AUTH method

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 and data connection separately.

Why it teaches protocol specifications: FTP (RFC 959) is unique: two connections (control + data). It shows how protocols adapt to NAT and firewalls.

Core challenges you’ll face:

Dual connections -> multi-channel protocols
Active mode -> server connects back
Passive mode -> NAT traversal
Transfer modes -> ASCII vs binary
Response parsing -> multi-line codes

Key Concepts:

FTP Protocol: RFC 959
Passive Mode: RFC 1579
FTP Security: RFC 4217 (FTPS)

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Socket programming

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
... file list ...
< 226 Directory send OK

Implementation Hints: Control connection uses port 21. PASV response contains IP and port. Active mode uses PORT command and requires you to listen on a port. Always switch to binary mode (TYPE I).

Learning milestones:

Login and navigate -> control channel
LIST in passive mode -> data channel
Binary file download -> transfer
Active mode works -> connection direction

The Core Question You’re Answering

Why does FTP use two connections, and how does that complicate traversal of NAT/firewalls?

Concepts You Must Understand First

FTP control vs data channels
PASV and PORT commands
Response codes and multi-line replies

Questions to Guide Your Design

How will you parse PASV responses safely?
How will you handle firewalls in active mode?
How will you resume transfers?

Thinking Exercise

Manually parse a PASV response and compute the port number.

The Interview Questions They’ll Ask

Why does FTP require two connections?
Why does passive mode work better behind NAT?
How does FTPS add security to FTP?
What is the difference between ASCII and binary transfer?

Hints in Layers

Layer 1: Implement login + PWD + CWD.
Layer 2: Implement PASV + LIST.
Layer 3: Implement RETR and STOR.
Layer 4: Add REST for resume.

Books That Will Help

| Topic | Book | Sections | |——|——|———-| | FTP | TCP/IP Illustrated Vol 1 | FTP sections |

Common Pitfalls & Debugging

Problem: “Data connection fails in active mode”

Why: NAT blocks inbound connection
Fix: use passive mode for Internet tests

Definition of Done

Supports PASV and PORT
Downloads a file in binary mode
Correctly parses multi-line replies

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: RFC 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 2812) is simple but stateful. It teaches line-based parsing, prefix routing, and numeric replies.

Core challenges you’ll face:

Message parsing -> prefix, command, params
Connection registration -> NICK/USER/PING
Channel state -> JOIN, PART, MODE
Numeric replies -> 3-digit codes

Key Concepts:

IRC Client Protocol: RFC 2812

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 IRC Network
> JOIN #test
< :server 353 mybot = #test :mybot @operator user1 user2
[#test] <user2> !help
[#test] <mybot> Available commands: !help, !time, !dice

Implementation Hints: IRC messages are CRLF-terminated lines: [:prefix] command params.... The last param can contain spaces if it starts with :. Respond to PING with PONG.

Learning milestones:

Connect and register -> handshake
Join channels and send messages -> basic operations
Parse message types -> protocol parsing
Bot responds to commands -> event-driven handling

The Core Question You’re Answering

How does a simple text protocol manage many simultaneous users in shared rooms?

Concepts You Must Understand First

IRC message format (RFC 2812)
Numeric reply meanings
Keepalive via PING/PONG

Questions to Guide Your Design

How will you parse the optional prefix?
How will you handle multiple channels simultaneously?
How will you avoid blocking reads?

Thinking Exercise

Write a parser that splits prefix, command, and params for 10 example IRC lines.

The Interview Questions They’ll Ask

Why does IRC use numeric replies?
How does PING/PONG prevent timeouts?
What is CTCP and how is it encoded?
How would you implement a simple IRC bot framework?

Hints in Layers

Layer 1: Implement basic line parsing.
Layer 2: Handle PING/PONG keepalive.
Layer 3: Track channel membership.
Layer 4: Add bot command handling.

Books That Will Help

| Topic | Book | Sections | |——|——|———-| | IRC | RFC 2812 | message format sections |

Common Pitfalls & Debugging

Problem: “Disconnected after 5 minutes”

Why: missed PING/PONG
Fix: respond to PING immediately

Definition of Done

Connects and joins a channel
Parses incoming messages
Responds to PING
Bot responds to at least 3 commands

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 process.

Why it teaches protocol specifications: DHCP (RFC 2131) shows how protocols bootstrap devices that don’t yet have an IP address. It is a state machine with strict timing and option parsing.

Core challenges you’ll face:

Broadcast communication -> bootstrap protocols
Options encoding -> TLV parsing
Lease state machine -> protocol lifecycle
Transaction ID matching -> correlation
Raw socket handling -> special network access

Key Concepts:

DHCP Protocol: RFC 2131
DHCP Options: RFC 2132
DHCPv6: RFC 8415 (optional extension)

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

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

Implementation Hints: DHCP uses UDP ports 67/68. Messages have fixed BOOTP fields followed by options (TLV). Magic cookie 0x63825363 begins the options. Follow the state machine from RFC 2131.

Learning milestones:

DISCOVER/OFFER works -> broadcast
Full DORA completes -> state machine
Options parsed correctly -> TLV parsing
Lease renewal works -> timers

The Core Question You’re Answering

How does a host configure itself without any prior IP configuration?

Concepts You Must Understand First

UDP broadcast and binding to 0.0.0.0:68
BOOTP header format
DHCP state machine
TLV option parsing

Questions to Guide Your Design

How will you retransmit on timeout?
How will you handle multiple offers?
How will you safely configure the interface?

Thinking Exercise

Draw the DORA state diagram and annotate where you store lease info.

The Interview Questions They’ll Ask

Why does DHCP use broadcast?
What is the purpose of the transaction ID (XID)?
How does a DHCP client renew vs rebind a lease?
What does the DHCP server identifier option do?

Hints in Layers

Layer 1: Implement DHCPDISCOVER send.
Layer 2: Parse DHCPOFFER and pick a server.
Layer 3: Send DHCPREQUEST and parse DHCPACK.
Layer 4: Implement renewal timers.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Never receives OFFER”

Why: firewall or binding issue
Fix: use tcpdump -nn udp port 67 or 68

Definition of Done

Completes full DORA handshake
Correctly parses DHCP options
Renews lease before expiry
Configures local interface safely

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 Ristic

What you’ll build: A tool that captures and decodes TLS handshakes, showing every message: ClientHello, ServerHello, Certificate, key exchange, and Finished – without decrypting application data.

Why it teaches protocol specifications: TLS 1.3 (RFC 8446) is the backbone of modern security. You’ll learn negotiation, extensions, key exchange, and the difference between TLS 1.2 and 1.3 handshakes.

Core challenges you’ll face:

Record layer parsing -> protocol framing
Handshake message parsing -> complex structures
Extension parsing -> extensibility
Certificate chain validation -> PKI model
TLS 1.2 vs 1.3 differences -> protocol evolution

Key Concepts:

TLS 1.3: RFC 8446
TLS 1.2: RFC 5246
X.509 Certificates: RFC 5280

Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Understanding of public key crypto

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)
   Cipher Suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
   Extensions: server_name, supported_versions, key_share

<- ServerHello (TLS 1.3)
   Cipher Suite: TLS_AES_256_GCM_SHA384
   Extensions: supported_versions, key_share

<- Certificate (chain length: 2)
<- CertificateVerify
<- Finished
-> Finished
[ESTABLISHED] TLS 1.3

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). Extensions are TLV. Parse but do not decrypt.

Learning milestones:

Parse record layer -> framing
Decode ClientHello -> negotiation
Parse certificates -> PKI basics
Distinguish TLS 1.2 vs 1.3 -> evolution

The Core Question You’re Answering

How does TLS negotiate security parameters and establish trust without revealing secrets?

Concepts You Must Understand First

TLS record + handshake layer
Cipher suite negotiation
X.509 certificate chain
TLS 1.3 message flow

Questions to Guide Your Design

How will you detect TLS 1.2 vs 1.3?
How will you parse variable-length extensions safely?
How will you present the certificate chain?

Thinking Exercise

Capture a TLS 1.2 and 1.3 handshake and compare message flow.

The Interview Questions They’ll Ask

What changed from TLS 1.2 to TLS 1.3?
What is SNI and why is it needed?
How does certificate validation work?
What is forward secrecy?

Hints in Layers

Layer 1: Parse record headers and handshake headers.
Layer 2: Decode ClientHello extensions.
Layer 3: Parse certificate chain.
Layer 4: Add pretty-print output for debugging.

Books That Will Help

| Topic | Book | Sections | |——|——|———-| | TLS | Bulletproof SSL and TLS | handshake chapters | | PKI | RFC 5280 | certificate format |

Common Pitfalls & Debugging

Problem: “Handshake parse stops early”

Why: record length misparsed
Fix: verify 5-byte header handling and length

Definition of Done

Parses TLS record layer and handshake messages
Displays cipher suites and extensions
Parses X.509 certificate chain
Distinguishes TLS 1.2 vs 1.3

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)

What you’ll build: An MQTT broker that handles CONNECT, PUBLISH, SUBSCRIBE with QoS 0 (at most once delivery).

Why it teaches protocol specifications: MQTT is a compact binary protocol designed for constrained devices. It teaches variable-length integer encoding and pub/sub semantics.

Core challenges you’ll face:

Binary packet parsing -> variable-length encoding
Topic matching -> wildcard matching
Session state -> clean vs persistent
QoS handling -> delivery guarantees
Keepalive -> PINGREQ/PINGRESP

Key Concepts:

MQTT 3.1.1: OASIS Standard (ISO/IEC 20922)
MQTT 5.0: OASIS Standard (optional extension)

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Socket programming

Real world outcome:

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

$ mosquitto_sub -h localhost -t 'sensors/+/temperature'
[Subscribed]

$ mosquitto_pub -h localhost -t 'sensors/living-room/temperature' -m '22.5'

Implementation Hints: MQTT uses variable-length integer encoding. Packet type is high nibble of first byte. Topic filters support + (single level) and # (all levels).

Learning milestones:

CONNECT/CONNACK works -> connection
PUBLISH forwarded -> pub-sub
Topic wildcards -> matching
QoS 0 complete -> delivery

The Core Question You’re Answering

How does a lightweight binary protocol enable scalable pub-sub on constrained devices?

Concepts You Must Understand First

MQTT fixed header format
Variable-length integer encoding
Topic wildcard matching

Questions to Guide Your Design

How will you store subscriptions efficiently?
How will you handle keepalive and idle connections?
How will you scale to many clients?

Thinking Exercise

Write a function that matches sensors/+/temperature against example topics.

The Interview Questions They’ll Ask

Why is MQTT good for IoT?
What are QoS levels 0/1/2?
How do wildcards work?
Why is MQTT stateful?

Hints in Layers

Layer 1: Implement CONNECT/CONNACK.
Layer 2: Implement SUBSCRIBE and topic matching.
Layer 3: Implement PUBLISH forwarding.
Layer 4: Add keepalive and disconnect handling.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Clients disconnect”

Why: keepalive or malformed CONNACK
Fix: verify keepalive and return codes

Definition of Done

CONNECT and SUBSCRIBE work
PUBLISH routes to subscribers
Wildcard topic matching passes tests
Idle connections handled correctly

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. You’ll learn policy-based routing, path-vector algorithms, and convergence.

Core challenges you’ll face:

FSM implementation -> complex state machine
UPDATE parsing -> binary message format
Path selection algorithm -> decision logic
RIB management -> routing state
Timer management -> protocol timing

Key Concepts:

BGP Protocol: RFC 4271
BGP FSM: RFC 4271 section 8
Path Selection: RFC 4271 section 9.1

Difficulty: Master Time estimate: 1-2 months Prerequisites: strong networking knowledge

Real world outcome:

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

[AS65001-R1] OPEN sent
[AS65002-R1] OPEN received
[AS65001-R1] Session ESTABLISHED

[AS65001-R1] Advertising 10.1.0.0/16
[AS65002-R1] Route installed via AS65001

Implementation Hints: BGP runs over TCP (port 179). Messages have a 16-byte marker, 2-byte length, 1-byte type. UPDATE messages contain withdrawn routes, path attributes, and NLRI. Simulate multiple routers in one process with virtual connections.

Learning milestones:

TCP connection and OPEN exchange -> session setup
UPDATE parsing -> BGP message format
Path selection works -> decision process
Convergence on change -> routing dynamics

The Core Question You’re Answering

How does the Internet coordinate routing between autonomous systems without a central controller?

Concepts You Must Understand First

BGP message types
Path attributes (AS_PATH, NEXT_HOP, LOCAL_PREF)
Route selection rules
Keepalive and hold timers

Questions to Guide Your Design

How will you represent RIB-In, Loc-RIB, and RIB-Out?
How will you simulate policy decisions?
How will you handle withdrawals and reconvergence?

Thinking Exercise

Given two routes with different AS_PATH lengths and LOCAL_PREF values, pick the winner using RFC 4271 rules.

The Interview Questions They’ll Ask

Why is BGP policy-based rather than shortest-path?
What is route flap and how does damping work?
How does BGP prevent loops?
What is the difference between iBGP and eBGP?

Hints in Layers

Layer 1: Implement OPEN/KEEPALIVE exchange.
Layer 2: Parse UPDATE messages.
Layer 3: Build RIB and path selection.
Layer 4: Add withdrawals and reconvergence events.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Routes never converge”

Why: missing withdrawal handling or incorrect timer logic
Fix: log RIB changes and check hold timers

Definition of Done

Simulates BGP sessions and OPEN/KEEPALIVE
Parses UPDATE messages and installs routes
Applies path selection rules
Converges after topology change

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 / RFC 8174

What you’ll build: A complete protocol specification in RFC format for a real problem, plus a reference implementation.

Why it teaches protocol specifications: The ultimate test is writing the spec yourself. You will define message formats, state machines, error handling, and security considerations.

Core challenges you’ll face:

Requirements analysis -> protocol purpose
Message format design -> encoding decisions
State machine design -> protocol behavior
Error handling -> robustness
Security considerations -> threat model
Writing clear spec -> technical writing

Key Concepts:

RFC Keywords: RFC 2119 + RFC 8174
IETF Process: RFC 2026

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

Real world outcome:

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
2. Protocol Overview
3. Message Format
4. Protocol Operation
5. Security Considerations

Implementation Hints: Start with the problem, not the solution. Use RFC 2119 keywords precisely. Write the spec first, then implement. Include diagrams and examples.

Learning milestones:

Problem statement written -> problem definition
Message formats designed -> encoding
State machine documented -> behavior
Security section complete -> threat modeling
Reference implementation passes interop test -> real protocol

The Core Question You’re Answering

Can you design a protocol that another engineer could implement without seeing your code?

Concepts You Must Understand First

RFC 2119/8174 keywords
Specification structure
Versioning and extensibility
Security considerations section

Questions to Guide Your Design

What are the minimum messages required?
How will you handle version negotiation?
How will you detect and recover from errors?
What security properties are required?

Thinking Exercise

Write the message format for a HELLO and ERROR message in TLV form.

The Interview Questions They’ll Ask

How do you design for forward compatibility?
What goes in a Security Considerations section?
How do you decide between binary and text formats?
How do you design for partial failure?

Hints in Layers

Layer 1: Write the protocol goals and constraints.
Layer 2: Define message formats with diagrams.
Layer 3: Define state machine transitions.
Layer 4: Add security and interoperability notes.

Books That Will Help

Common Pitfalls & Debugging

Problem: “Spec ambiguous”

Why: missing MUST/SHOULD language or unclear examples
Fix: add concrete examples and explicit requirements

Definition of Done

RFC-style document complete
Reference implementation matches spec
Interop test with a second implementation
Security considerations included

Project Comparison Table

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

Final Capstone Project: Full-Stack Protocol Implementation

Project: Secure Chat System (Ground Up)

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

Custom transport protocol (your UDP reliability layer or TCP)
Custom application protocol (RFC-documented)
TLS-like security layer (simplified)
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, spec writing. When it works, you’ve mastered protocol implementation.

Real world outcome:

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

$ ./chat_client --discover
Found: ChatRoom @ 192.168.1.50:9000

$ ./chat_client --connect 192.168.1.50:9000 --nick alice
[HANDSHAKE] Exchanging keys...
[SECURE] Connection established
[JOIN] You joined as 'alice'
[ROOM] Users online: bob, carol

Essential Resources

Books (Primary References)

“TCP/IP Illustrated, Volume 1” – core protocol reference
“Computer Networks” – theory and design principles
“The Linux Programming Interface” – socket programming
“Bulletproof SSL and TLS” – TLS deep dive

RFC Reading Guide

Start with these foundational RFCs:

RFC 791 (IP)
RFC 792 (ICMP)
RFC 768 (UDP)
RFC 9293 (TCP)
RFC 1035 (DNS)
RFC 9110/9112 (HTTP semantics + HTTP/1.1)
RFC 9113 (HTTP/2)
RFC 9114 (HTTP/3)
RFC 8446 (TLS 1.3)
RFC 4271 (BGP)

Online Resources

Beej’s Guide to Network Programming
“Let’s code a TCP/IP stack” (Saminiir)
Wireshark

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	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.”

Network Protocols: From Specification to Practice

Why Network Protocol Specifications Matter

The RFC Language is a Contract

Specifications as “Source Code”

Prerequisites & Background Knowledge

Essential Prerequisites (Must Have)

Helpful But Not Required

Self-Assessment Questions

Development Environment Setup

Time Investment

Important Reality Check

Core Concept Analysis

1) Layering and Encapsulation

2) Framing and Parsing

3) State Machines

4) Reliability and Congestion Control

5) Security & Trust Boundaries

6) Extensibility and Versioning

Concept Summary Table

Deep Dive Reading by Concept

Quick Start (First 48 Hours)

Recommended Learning Paths

Big Picture / Mental Model

Success Metrics

How to Use This Guide

Core Subsystem Walkthrough (User Space -> Kernel -> Wire)

Kernel Navigation Cheatsheet (Linux)

Debugging Toolkit

Kernel Data Structure Atlas (Networking)

Kernel Contribution Checklist (Networking)

Glossary of Network Terms

Common Failure Signatures

Kernel Reading Plan (Networking Focus)

The Protocol Stack You’ll Explore

Project 1: ICMP Ping Implementation

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Common Pitfalls & Debugging

Definition of Done

Project 2: ARP Cache Viewer and Spoofer

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Common Pitfalls & Debugging

Definition of Done

Project 3: Traceroute Implementation

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Common Pitfalls & Debugging

Definition of Done

Project 4: TCP Three-Way Handshake Visualizer

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Common Pitfalls & Debugging

Definition of Done

Project 5: Minimal TCP Stack (User-Space)

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask