⚡ TITAN HTTP Server

A Simplified Web Server Built Using Raw Linux System Calls

Description: This is a fully functional HTTP/1.1 server that handles thousands of concurrent connections using the same Linux kernel APIs (epoll, fork, pipe, sendfile), and systems programming fundamentals as nginx, Node.js, and Redis.

🔧 Raw Linux Syscalls ⚡ epoll Event Loop 🧵 Thread Pool 🚀 Zero-Copy I/O 🐍 CGI Support

📊 Live Server Statistics

What's happening: These metrics update by polling the /stats JSON endpoint. The server tracks active connections using epoll and handles requests via a 4-thread pool.

🔥 Live Stress Testing: Click "Start Test" to trigger real load testing! The server uses curl + xargs -P 100 to send 100 parallel requests, bypassing browser limitations. As this was deployed on Railway, stress tests are capped at 500 requests to respect platform rate limits ...
0 Total HTTP Requests

Server-side counter (updates every 2s from /stats endpoint)

0 Active Connections

Live TCP sockets currently tracked by epoll (includes keep-alive)

4 Worker Threads

Pre-allocated threads in the pool handling blocking I/O operations

0 Live Stress Test

Status: 0 / 0

📤 Feature #1: HTTP POST & File Upload

Systems Concept: Demonstrates HTTP request parsing, POST body extraction, and file I/O using ofstream. Data is written to disk and persisted in uploaded_data.txt.

🐍 Feature #2: CGI (Common Gateway Interface)

Systems Concept: This triggers fork(), execve(), and pipe() syscalls to execute time_server.py as a child process. The output is captured via inter-process communication and returned as HTML.
Warning: This demo intentionally includes a 10-second sleep() to show the thread pool handling blocking I/O without freezing the server.

🗑️ Feature #3: HTTP DELETE Method

Systems Concept: Implements the HTTP DELETE verb and uses remove() syscall to delete files from the filesystem. This demonstrates RESTful API implementation at a low level.

🍪 Feature #4: HTTP Cookies & Session Management

Systems Concept: The server manually parses and sets HTTP Set-Cookie headers for stateful session tracking. This demonstrates understanding of HTTP's stateless nature and client-side storage.

🏗️ How This Compares to Production Servers

Context: This is a HTTP/1.1 web server — the same category as nginx, Apache, and the HTTP layer inside Node.js. It accepts TCP connections, parses HTTP requests, serves files, and executes backend scripts.

What makes this different: Most developers use high-level libraries (Express.js, Flask, Spring Boot) that hide how HTTP actually works. This implementation exposes the raw Linux kernel APIs that all servers ultimately rely on.

📚 Technical Implementation Breakdown

🔧 epoll Event Loop (Like Node.js's libuv, Redis's Event Loop)

What it does: Monitors thousands of network sockets simultaneously without blocking the CPU.

How it works: Uses Linux's epoll_wait() syscall in edge-triggered mode. When data arrives on any socket, the kernel wakes up the process instantly. O(1) complexity — unlike select() which is O(n).

Real-world equivalent: nginx uses epoll. Node.js uses libuv (which wraps epoll on Linux). Redis uses epoll for pub/sub.

🧵 Thread Pool Pattern (Like Apache Worker MPM, NGINX + FastCGI)

What it does: Pre-allocates 4 worker threads to handle slow operations (disk I/O, script execution) without freezing the main event loop.

How it works: Producer-Consumer pattern using std::mutex and std::condition_variable. Tasks are queued, and idle threads pick them up. Avoids the overhead of fork()-ing a new process per request (like old CGI).

Real-world equivalent: Apache's Worker MPM uses threads. Node.js offloads file I/O to a thread pool. Databases like PostgreSQL use background workers.

⚡ Zero-Copy Transfer with sendfile() (Like nginx, Kafka)

What it does: Streams files from disk to network socket without copying data into user-space memory.

How it works: Traditional I/O: read(file) → copy to buffer → write(socket) (4 context switches, 2 copies). sendfile(): Kernel transfers data directly from page cache to TCP buffer (2 context switches, 0 copies).

Real-world equivalent: nginx uses sendfile for static files. Kafka uses it for log replication. CDN edge servers rely on this for performance.

🐍 CGI Process Management (Like PHP-FPM, Early Web Servers)

What it does: Executes Python scripts as separate processes and captures their output.

How it works: Uses fork() to clone the server process, pipe() to create an IPC channel, dup2() to redirect stdout into the pipe, and execve() to replace the child process with Python. Parent reads the pipe.

Real-world equivalent: Original Apache + CGI worked this way. PHP-FPM improved it with persistent processes. Modern frameworks (Express, Flask) use in-process handlers instead.

❌ What's Simplified (For Educational Purposes)

✗ No HTTPS/TLS: Production servers use OpenSSL/mbedTLS for encryption. Adding TLS requires implementing the TLS handshake.

✗ No HTTP/2 or HTTP/3: This implements HTTP/1.1 only. HTTP/2 uses binary framing and multiplexing; HTTP/3 uses QUIC over UDP.

✗ No Virtual Hosts: Can't host multiple domains on one IP (nginx can). Would need Host header routing.

✗ No Load Balancing/Reverse Proxy: No upstream server pooling like nginx's proxy_pass.

✗ No Compression: No gzip/brotli encoding (nginx has this built-in).

✗ No Access Logs/Analytics: Production servers write to access.log, error.log with rotation.

✓ What we DO have: The core event loop, concurrency model, and I/O optimization that all servers need.

💡 More remarks on Generic HTTP Servers

An HTTP server is just software that speaks the HTTP protocol — it's not tied to any specific use case. nginx is an HTTP server (used for static files, reverse proxy). Apache is an HTTP server (used for hosting websites). Node.js contains an HTTP server (the http module). Even REST APIs are HTTP servers.