HTTP Server from Raw Sockets with a Load Test Report

The problem: frameworks hide the network

Most students write web backends with Express, Django or Spring and never see what happens between the socket and the route handler. Then the networks course describes TCP byte streams and the operating systems course describes threads and blocking I/O, and the two never meet in working code. Interviewers for backend and infrastructure roles notice: "what happens when a request arrives" is a common question, and few graduates can answer it from experience.

Writing an HTTP server from raw sockets closes that gap. TCP delivers bytes, not messages, so requests arrive in pieces. HTTP defines exactly where headers end. Status codes and headers have precise meanings. Serving many clients at once brings in threads, shared state, blocking calls and resource limits.

What already exists and the gap

• nginx and Caddy are production web servers; nginx is the classic example of an event-driven design, and both are far too large to learn from directly.
• The Tiny web server in the CS:APP textbook (Bryant and O'Hallaron) is a compact teaching server, and the book's Proxy Lab extends the idea.
• CodeCrafters' HTTP Server challenge walks learners through building one step by step in many languages.

The gap is not "another web server". It is a measured comparison: two concurrency designs in one codebase, tested against the same workload, with the results explained using operating systems concepts. Guided challenges stop at "it works"; this project asks why it behaves the way it does under load.

What you build

1. A listening socket that reads until the blank line ending the headers, with limits on header size.
2. A request parser that rejects malformed input with 400.
3. Static file serving from one folder with the right content types, conditional requests (304) and safe path handling.
4. Keep-alive with an idle timeout.
5. A thread pool design.
6. An event loop design with non-blocking sockets.
7. A test client and a load test harness that produce the report's graphs.

Users: you, your examiners, and future students. A clean codebase with a good README is a teaching artefact a networks lecturer could hand to the next batch.

The technically interesting part

Incremental parsing in the event loop. In the thread design, a thread can block reading until the request is complete. In the event loop, a read returns whatever bytes are available, so each connection needs a small state machine (reading headers, reading body, writing response, idle) and a buffer that survives between reads. Getting this right, including a slow client that sends one byte a second, is the heart of the project.

Show your supervisor the state diagram, the tests that feed requests in random fragment sizes, and a slow-client test that proves one bad client cannot freeze the server.

How to evaluate it

• Load test both designs at 10, 100, 1,000 and higher concurrent connections: requests per second, p50 and p99 latency, memory and thread count, with graphs.
• Explain the differences using context switches, per-thread stack memory and blocking I/O; profile with perf or pprof to back claims.
• Correctness: at least 40 automated cases, including fragments, malformed requests, oversized headers and traversal attempts.
• Baseline: run the same load against nginx serving the same folder, to put your numbers in context rather than to beat it.

Suggested plan

1. Weeks 1 to 2: sockets, request parsing, static files, tests.
2. Weeks 3 to 4: keep-alive, timeouts, traversal protection, thread pool.
3. Weeks 5 to 7: event loop with the connection state machine.
4. Weeks 8 to 9: load tests, profiling, nginx baseline.
5. Week 10: report and README.

Path to a product

This is a portfolio and teaching project, not a startup. Its value is in interviews at backend, infrastructure and networking companies, where you can talk through a real load test you ran. The codebase and report can also become a lab resource: offer it to your networks lecturer as a reference or starter for a future assignment, which is a better outcome than most FYPs get.

Scope warning

Do not use an HTTP parsing library: that is the point of the exercise. Do not attempt HTTP/2 or HTTP/3. Do not build a framework with routing and middleware. C shows the most detail, Go and Rust make the event loop safer to write, and Python will limit performance, which is itself worth discussing. If your networks course sets a similar assignment, follow its rules and do not publish solutions still in use.

Learn what you need on Sefism

• Beej's Guide to Network Programming : the sockets API explained clearly with examples.
• MDN: HTTP : status codes, headers and caching rules you need to implement.
• Operating Systems: Three Easy Pieces : threads, concurrency and I/O for the analysis section.
• Grafana k6 Documentation : scripting the load tests.
• Backend roadmap : where this fits in becoming a backend engineer.
• System design cheat sheet : vocabulary for latency, throughput and concurrency models.

Get help with this idea

The risk in this project is spending all the time on parsing and none on the comparison that makes it an A. A mentor can help you plan the load test methodology and decide which language gives you the right trade-off. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session