Multi-threaded HTTP Server with Thread Pool
Build a fast HTTP server in C++ on top of Boost.Asio that serves the files in a folder, like a small nginx. A fixed pool of threads runs the asynchronous event loop, so thousands of connections are handled without a thread for each one. The server parses HTTP/1.1 requests itself, sends files with the correct content type and headers, keeps connections open for more requests (keep-alive), refuses anything outside the folder, and logs every request with its timing. At the end, you measure how many requests per second it handles with wrk and tune it. You'll learn asynchronous I/O, the lifetimes of objects in async code, HTTP parsing, preventing path traversal attacks, thread safety, and performance measurement.
- Estimate
- ~14.5h
- Steps
- 7
- Completed by
- 0
- Proposed by
- codeseed.app
Boost.Asio · std::thread
Project roadmap
- 01
Accept connections asynchronously
~2hSet up a CMake project with Boost. Write a Server class that accepts connections with async_accept on a configurable port and document root, and a Connection class (kept alive with shared_from_this) that reads with async_read_until until the blank line ending the headers. Reply with a fixed Hello response for now. Done when: curl http://localhost:8080/ gets the Hello response.
- 02
Run a thread pool
~1.5hRun io_context::run() on N threads (default: the number of CPUs), and use a strand per connection so one connection's handlers never run at the same time. Stop cleanly on Ctrl+C with a signal_set: stop accepting, let current requests finish, then join the threads. Done when: the server uses all threads under load and shuts down cleanly.
- 03
Parse requests and serve files
~3hParse the request line and headers, rejecting malformed requests with 400, anything other than GET and HEAD with 405, and headers over 8 KB with 431. Decode the path, then resolve it inside the document root with std::filesystem and return 403 when it points outside (for example /../../etc/passwd). Serve index.html for folders, with Content-Type from the file extension, Content-Length and Last-Modified, or 404. Done when: files are served correctly, and path traversal attempts get 403.
- 04
Keep connections alive
~2hSupport HTTP/1.1 keep-alive: after a response, read the next request on the same connection, unless the client sent Connection: close. Close connections that stay idle for 15 seconds, using a steady_timer, and limit the number of requests per connection. Done when: curl -v fetching two URLs in one command reuses one connection, and idle connections close after the timeout.
- 05
Log every request
~1.5hLog each request as one line: time, client IP, method, path, status, bytes sent and duration in milliseconds. Make logging thread-safe without slowing down request handling, for example by having workers push lines onto a queue that a single logger thread writes to disk. Done when: the log has one correct line per request, and lines are never mixed together under load.
- 06
Benchmark and tune
~2.5hMeasure your server with wrk (for example wrk -t4 -c200 -d30s) on your own machine, for a small and a large file. Compare different thread counts and record requests per second and latency in README.md. Use perf or a profiler to find the biggest cost, improve one thing (for example caching small files in memory), and measure again. Done when: README.md has before-and-after numbers for the change you made.
- 07
Test it
~2hWrite tests for the request parser (valid, malformed and oversized requests) and path resolution (traversal attempts, encoded characters, folders). Add an integration test that starts the server on a free port and checks responses and keep-alive with a small client. Run the tests under ThreadSanitizer and AddressSanitizer. Done when: all tests pass with no sanitizer errors.
Resources
Ready to build this?
Get a GitHub repo and start building. Your AI reviewer checks each step as you go.
Tech stack