Systems Programming · C · Networking

Building a Multi-Threaded HTTP
Proxy Server in C

A deep technical walkthrough from raw sockets and POSIX threads to O(1) LRU caching with hash maps and doubly linked lists. Plus: how a proxy is a generic box you can turn into anything.

What Is a Proxy Server, Really?

A proxy server is a process that sits between a client and a backend server and relays traffic. When your browser sends a GET request, instead of going directly to example.com, it goes to the proxy. The proxy then opens its own connection to example.com, fetches the data, and pipes it back to your browser.

That sounds trivial. But the power of a proxy is that it is a programmable interception point. Every single byte of traffic passes through code you control. That means you can:

Cache responses so repeated requests never hit the backend
Inspect, log, or modify requests and responses
Block requests based on rules (firewall / content filter)
Rate-limit clients to prevent abuse
Load-balance across multiple backends
Strip identifying headers to add anonymity (VPN-like)
Detect and absorb DDoS floods before they reach the origin

This project implements a forward proxy — clients configure it explicitly (e.g. in curl with -x http://localhost:8080). Reverse proxies (like Nginx) are the other side of the coin; clients don't know they exist.

Browser / curl HTTP req PROXY SERVER accept() → thread_fn() cache check → forward / tunnel TCP Remote Server response forwarded

High-Level Architecture

The codebase is organized into three clear boundaries. Understanding this before diving into code matters:

src/server.c — The Core

Every important thing lives here. Socket lifecycle, thread pool management, request routing, the LRU cache with O(1) hash + DLL, and the HTTPS CONNECT tunnel. This is the file we'll spend most time in.

src/proxy_parse.c + include/proxy_parse.h — HTTP Parser

A standalone library that tokenizes a raw HTTP request buffer into a ParsedRequest struct. It handles the request line and all headers as key-value pairs, lets you set/remove/get headers programmatically, and can serialize the structure back to a wire-format string.

src/logger.c + include/logger.h — Thread-Safe Logger

A minimal mutex-protected logging layer. Three levels: LOG_INFO, LOG_ERROR, LOG_DEBUG. Every log call grabs a lock, prints a timestamp + level + message, and releases. Safe to call from any thread.

benchmarks/benchmark_cache.cpp — Google Benchmark harness

Measures the cache's addCache() and find() operations in nanoseconds across thousands of iterations.

The global constants that govern behavior — all in server.c:

#define MAX_CLIENTS        10  // max concurrent threads
#define MAX_BYTES          4096     // recv/send buffer size
#define MAX_ELEMENT_SIZE   10*(1<<10) // 10 KB max single cacheable item
#define MAX_SIZE           200*(1<<20) // 200 MB total cache budget
#define HASH_SIZE          1024     // hash table bucket count
#define MAX_CACHEABLE_SIZE (5 * 1024 * 1024) // 5 MB max response to cache

Sockets — The Foundation

Everything in this project starts with one concept: a socket. A socket is an endpoint for network communication represented by an integer file descriptor (fd) in the Linux kernel. You read from it and write to it like a file, but the data flows over TCP.

Here is exactly what main() does during startup:

socket() — create the listening socket

int socketID = socket(AF_INET, SOCK_STREAM, 0);
// AF_INET  = IPv4
// SOCK_STREAM = TCP (reliable, ordered, connection-based)
// 0 = default protocol for that socket type

setsockopt(SO_REUSEADDR) — avoid "Address already in use"

int reuse = 1;
setsockopt(socketID, SOL_SOCKET, SO_REUSEADDR, (const char*)&reuse, sizeof(reuse));
// Without this, if you kill and restart the proxy quickly,
// the port stays in TIME_WAIT state and bind() fails.

bind() — attach the socket to an address and port

struct sockaddr_in server_addr;
bzero((char*)&server_addr, sizeof(server_addr));
server_addr.sin_family      = AF_INET;
server_addr.sin_port        = htons(PORT);      // host-to-network byte order
server_addr.sin_addr.s_addr = INADDR_ANY;     // listen on all interfaces

bind(socketID, (struct sockaddr*)&server_addr, sizeof(server_addr));

htons() converts the port integer from host byte order (little-endian on x86) to network byte order (big-endian). Always required when filling socket address structs.

listen() — mark the socket as passive, set the backlog

listen(socketID, MAX_CLIENTS);
// The backlog (MAX_CLIENTS = 10) is the kernel's incoming
// connection queue. If you have 10 connections in flight
// and another arrives, the kernel queues it up to this limit.

accept() in a loop — one new fd per client

while(1){
    clientSocketID = accept(socketID,
                            (struct sockaddr*)&client_addr,
                            (socklen_t*)&clientLen);
    // accept() BLOCKS until a client connects.
    // It returns a BRAND NEW fd specific to this client.
    // socketID keeps listening. clientSocketID is the conversation.
    connectedSocketID[i] = clientSocketID;
    pthread_create(&threadID[i], NULL, thread_fn, (void*)&connectedSocketID[i]);
    i++;
}

Why two sockets?

The listening socket (socketID) is like a receptionist at a desk. When someone walks in, the receptionist creates a new private room (the clientSocketID) and hands off the conversation to a thread. The receptionist's desk stays free for the next arrival.

The Remote Server Socket

For every cache miss, the proxy also opens an outbound socket (socket created by a process to initiate a connection to a remote host) to the destination. This is connectRemoteServer():

int connectRemoteServer(char* hostaddr, int portNumber){
    int remoteSocket = socket(AF_INET, SOCK_STREAM, 0);

    // DNS resolution — hostname → IP
    struct hostent* host = gethostbyname(hostaddr);

    struct sockaddr_in server_addr;
    bzero(&server_addr, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port   = htons(portNumber);
    bcopy((char*)host->h_addr_list[0],
          (char*)&server_addr.sin_addr.s_addr,
          host->h_length);

    connect(remoteSocket,
            (struct sockaddr*)&server_addr,
            sizeof(server_addr));

    return remoteSocket;
}

gethostbyname() performs a DNS lookup — it resolves "www.example.com" into an IPv4 address. bcopy() copies the resolved IP bytes into the socket address struct. Then connect() initiates the TCP three-way handshake with the remote.

Threads, Semaphores & Mutexes

A single-threaded server can only handle one client at a time. If that client's request takes 200ms to fetch from the origin, every other client waits 200ms just to start. This is obviously unacceptable. The solution: POSIX threads (pthreads).

Thread Dispatch

In main(), every accepted client immediately gets its own thread:

// Globals set up before main() loop:pthread_t threadID[MAX_CLIENTS];
sem_t semaphore;
pthread_mutex_t lock;

// Inside main(), before the accept() loop:sem_init(&semaphore, 0, MAX_CLIENTS);   // starts at 10pthread_mutex_init(&lock, NULL);

// Each new connection:pthread_create(&threadID[i], NULL, thread_fn, (void*)&connectedSocketID[i]);

The Semaphore — Throttling Concurrency

The semaphore is initialized to MAX_CLIENTS = 10. This means at most 10 threads can be actively processing at once.

void* thread_fn(void* socketNew){

    sem_wait(&semaphore);   // DECREMENT. If 0, BLOCK here until a slot frees up.

    int* t = (int*)socketNew;
    int socket = *t;

    // ... handle the request ...

    sem_post(&semaphore);   // INCREMENT. Wake up one waiting thread.
    return NULL;
}

sem_wait() decrements the semaphore. If the count is already 0 (all 10 slots taken), the calling thread sleeps until another thread calls sem_post(). This is a counting semaphore acting as a concurrency throttle — it prevents resource exhaustion from thousands of simultaneous connections.

Semaphore vs Mutex

A mutex is a binary lock: one thread holds it, all others wait. A semaphore counts.A semaphore limits how many threads can run at the same time, preventing overload. A mutex allows only one thread at a time to access shared data, preventing corruption. In this code, the semaphore controls concurrency, while the mutex protects the cache.. In my code, semaphore limits active thread count (counting), while lock (mutex) protects the cache from concurrent modification.

Why Mutex on the Cache?

Imagine two threads simultaneously calling addCache(). Both check cacheSize, both see it's within budget, both write to the hash table. One overwrites the other's pointer. The cache is now corrupted — you have a dangling pointer and will crash on the next lookup. This is a data race.

The mutex prevents this. Only one thread can be inside addCache(), find(), or removeCache() at a time:

cache* find(char* url){
    pthread_mutex_lock(&lock);     // acquire — all other threads block here

    // ... do the lookup ...

    pthread_mutex_unlock(&lock);   // release — one waiting thread can proceed
    return site;
}

Limitation to note
The current implementation uses a coarse-grained lock — a single mutex for the entire cache. A production system would use reader-writer locks (pthread_rwlock_t) so that multiple concurrent cache reads don't block each other. Writes still lock exclusively.

HTTP Parsing — From Raw Bytes to Structure

HTTP is a text protocol. A raw HTTP/1.1 request looks like this:

GET http://httpbin.org/get HTTP/1.1\r\n
Host: httpbin.org\r\n
User-Agent: curl/8.1.2\r\n
Accept: */*\r\n
Proxy-Connection: Keep-Alive\r\n
\r\n

The proxy receives this as a raw char* buffer via recv(). The first step is reading until we see \r\n\r\n (the blank line that signals the end of headers):

char* buffer = (char*)calloc(MAX_BYTES, sizeof(char));
int bytesRead = recv(socket, buffer, MAX_BYTES, 0);

while(bytesRead > 0){
    len = strlen(buffer);
    if(strstr(buffer, "\r\n\r\n") == NULL){
        // headers not complete yet, keep reading
        bytesRead = recv(socket, buffer + len, MAX_BYTES, 0);
    } else {
        break;  // got the full header section
    }
}

Once we have the full header block, we extract the method and URL with a quick sscanf():

char original_method[16] = {0};
char target_url[1024]    = {0};
char http_version[16]   = {0};

sscanf(buffer, "%15s %1023s %15s", original_method, target_url, http_version);
// After: original_method = "GET"
//        target_url      = "http://httpbin.org/get"
//        http_version    = "HTTP/1.1"

ParsedRequest — The HTTP Parser Struct

For deeper inspection, the buffer is passed to ParsedRequest_parse(). The parser tokenizes it into:

struct ParsedRequest {
    char* method;    // "GET"
    char* protocol;  // "http"
    char* host;      // "httpbin.org"
    char* port;      // "80" or NULL
    char* path;      // "/get"
    char* version;   // "HTTP/1.1"
    struct ParsedHeader* headers; // linked list of key-value pairs
    size_t headersused;
    size_t headerslen;
};

Header Manipulation Before Forwarding

Before sending the request upstream to the remote server, the proxy modifies the headers. This is where a proxy's power becomes apparent — you can inject, remove, or rewrite any header:

// Force Connection: close (we don't support keep-alive to remote)ParsedHeader_set(request, "Connection", "close");

// Remove headers that shouldn't reach the origin serverParsedHeader_remove(request, "Proxy-Connection");
ParsedHeader_remove(request, "Keep-Alive");
ParsedHeader_remove(request, "Upgrade");
ParsedHeader_remove(request, "Transfer-Encoding");

// Serialize back to wire formatParsedRequest_unparse_headers(request, buffer + len, MAX_BYTES - len);

Routing: HTTP vs HTTPS (CONNECT Tunnel)

After parsing, the proxy hits a fork in the road. The method determines which path is taken:

Path A — Standard HTTP (GET, POST, PUT...)

For all non-CONNECT methods, the proxy parses the request with ParsedRequest_parse(), checks the cache, and if it's a miss, opens a socket to the remote server, forwards the modified request, streams the response back to the client, and caches it for GET requests.
The cache key is a composite string: METHOD:host:path. This means GET:httpbin.org:/get and POST:httpbin.org:/post are stored as separate entries, which is correct — POST responses should never be served from cache

char cacheKey[2048];
snprintf(cacheKey, sizeof(cacheKey), "%s:%s:%s",
        method,
        request->host,
        request->path);
// Example: "GET:httpbin.org:/get"

Path B — HTTPS CONNECT

When a browser wants to load https://google.com through a proxy, it first sends a CONNECT request:

CONNECT www.google.com:443 HTTP/1.1\r\n
Host: www.google.com:443\r\n
\r\n

The proxy cannot decrypt TLS traffic (it doesn't have google.com's private key). So instead of trying to parse it, it acts as a blind TCP pipe:

Parse the host and port from the CONNECT URI (www.google.com and 443)
Call connectRemoteServer("www.google.com", 443) — establish a TCP connection to Google's servers
Send HTTP/1.1 200 Connection Established\r\n\r\n back to the browser — this tells it the tunnel is ready
Call handle_connect_tunnel(clientSocket, remoteSocket) — enter the bidirectional relay loop

if (strcmp(original_method, "CONNECT") == 0) {
    char* host = target_url;  // "www.google.com:443"
    int   port = 443;

    char* colon = strchr(target_url, ':');
    if (colon != NULL) {
        *colon = '\0';           // split "www.google.com\0443"
        port = atoi(colon + 1);  // port = 443
    }

    int remoteSocketID = connectRemoteServer(host, port);

    const char* reply = "HTTP/1.1 200 Connection Established\r\n\r\n";
    send(socket, reply, strlen(reply), 0);

    handle_connect_tunnel(socket, remoteSocketID);
    close(remoteSocketID);
}

The `select()` System Call for HTTPS Tunneling

The CONNECT tunnel is bidirectional. The browser sends TLS handshake bytes, they go to Google. Google responds, the bytes come back to the browser. And this can happen in either direction, at any time, interleaved.

A naive approach — recv(clientSocket) then recv(remoteSocket) — would deadlock. If the client is waiting for the remote to respond, but we're blocking on recv(clientSocket), we never forward the remote's data. The tunnel freezes.

The solution is select(). It's an I/O multiplexer: you hand it a set of file descriptors and it tells you which ones are ready to read, without blocking on any individual one:

int handle_connect_tunnel(int clientSocket, int remoteSocket){
    fd_set read_fds;
    int max_fd = (clientSocket > remoteSocket) ? clientSocket : remoteSocket;
    char buffer[MAX_BYTES];

    while (1) {
        FD_ZERO(&read_fds);            // clear the fd set
        FD_SET(clientSocket, &read_fds); // watch client
        FD_SET(remoteSocket, &read_fds); // watch remote

        if (select(max_fd + 1, &read_fds, NULL, NULL, NULL) < 0) break;
        // select() BLOCKS until at least one fd is readable

        if (FD_ISSET(clientSocket, &read_fds)) {
            int n = recv(clientSocket, buffer, MAX_BYTES, 0);
            if (n <= 0) break;
            send(remoteSocket, buffer, n, 0);  // forward to remote
        }

        if (FD_ISSET(remoteSocket, &read_fds)) {
            int n = recv(remoteSocket, buffer, MAX_BYTES, 0);
            if (n <= 0) break;
            send(clientSocket, buffer, n, 0);  // forward to client
        }
    }
    return 0;
}

Why not epoll?

select() is POSIX-standard and portable. Its limitation is that it has to scan all fds up to max_fd on every call, so it's O(n) per invocation. epoll() (Linux-specific) is O(1) and scales to millions of connections. For a learning project, select() is perfectly appropriate — and sufficient for dozens of concurrent tunnels.

Cache v1 — The Naive Linked List

The first version of the cache was a simple singly linked list sorted by insertion time. Each node stored the URL, data, and a time_t timestamp. When the cache was full and eviction was needed:

Walk the entire list from head to tail
Find the node with the oldest time field
Remove it from the list
Free its memory

This is O(N) for every iteration, where N is the number of cached URLs. For lookups, it's also O(N) — you scan from head until you find a URL match, or exhaust the list on a miss.

In the old struct

struct cache {
    char*   data;
    size_t  len;
    char*   url;
    time_t  time;
    cache*  next;         // singly linked — only forward pointer
    // no prev, no hash_next
};

For a small cache, this works. But as the number of cached entries grows, every request that's a cache miss causes an O(N) linear scan. Under high traffic, this becomes a bottleneck inside a mutex — every thread waits for the entire list to be scanned.

Benchmark Result — v1
The old architecture clocked in at ~14,726 ns per cache operation in the Google Benchmark harness.

Cache v2 — O(1) LRU with Hash + Doubly Linked List

The upgraded cache uses two data structures in tandem. Understanding why requires understanding what each structure is good at:

Hash table — O(1) average lookup by key (URL)
Doubly linked list (DLL) — O(1) insertion at head, O(1) removal of tail, O(1) move-to-head of any node

Together, they implement a textbook LRU cache. The new struct:

struct cache {
    char*   data;       // the HTTP response bytes
    size_t  len;        // size of data
    char*   url;        // the cache key
    time_t  time;       // last access timestamp (for debugging)
    cache*  next;       // DLL forward pointer
    cache*  prev;       // DLL backward pointer  ← NEW
    cache*  hash_next;  // hash chain (collision handling) ← NEW
};

cache* head = NULL;                             // MRU endcache* tail = NULL;                             // LRU end (evict from here)cache* hash_table[HASH_SIZE] = {NULL};          // 1024 bucketssize_t cacheSize = 0;                           // running total bytes

find() — O(1) Lookup

cache* find(char* url){
    pthread_mutex_lock(&lock);

    unsigned int hash_idx = hash_url(url);    // O(|url|) ≈ O(1)
    cache* site = hash_table[hash_idx];        // direct array index

    while (site != NULL) {
        if (!strcmp(site->url, url)) {         // collision? check key
            site->time = time(NULL);
            move_to_head(site);               // mark as most recently used
            pthread_mutex_unlock(&lock);
            return site;
        }
        site = site->hash_next;               // walk hash chain
    }

    pthread_mutex_unlock(&lock);
    return NULL;   // cache miss
}

move_to_head() — O(1) Recency Update

Every cache hit promotes the accessed node to the head of the DLL. The most-recently-used item is always at head, the least-recently-used is always at tail. This is the core invariant:

void move_to_head(cache* node) {
    if (node == head) return;   // already MRU, nothing to do

    // 1. Unlink from current position
    if (node->prev) node->prev->next = node->next;
    if (node->next) node->next->prev = node->prev;
    if (node == tail) tail = node->prev;

    // 2. Prepend to head
    node->next = head;
    node->prev = NULL;
    if (head) head->prev = node;
    head = node;

    if (tail == NULL) tail = head;
}

addCache() — O(1) Insert with Eviction

int addCache(char* data, size_t size, char* url){
    pthread_mutex_lock(&lock);

    int elementSize = size + 1 + strlen(url) + sizeof(cache);

    if (elementSize > MAX_ELEMENT_SIZE) {
        pthread_mutex_unlock(&lock);
        return 0;   // single item too large, skip
    }

    // Evict LRU entries until there's room
    while (cacheSize + elementSize > MAX_SIZE)
        removeCache();

    // Allocate and fill the new node
    cache* element = (cache*)malloc(sizeof(cache));
    element->data = (char*)malloc(size + 1);
    memcpy(element->data, data, size);
    element->url  = strdup(url);
    element->time = time(NULL);
    element->len  = size;

    // Insert into hash table (chaining)
    unsigned int hash_idx = hash_url(url);
    element->hash_next   = hash_table[hash_idx];
    hash_table[hash_idx] = element;

    // Insert at DLL head (most recently used)
    move_to_head(element);
    cacheSize += elementSize;

    pthread_mutex_unlock(&lock);
    return 1;
}

removeCache() — O(1) LRU Eviction

Eviction always targets the tail of the DLL — the least recently used entry. We have a direct pointer to it, so removal is O(1). We also need to remove it from the hash table, which requires walking the hash chain (O(k) where k is collision chain length, usually 1):

void removeCache(){
    cache* temp = tail;      // O(1) — direct pointer to LRU node
    if (temp == NULL) return;

    // Remove from DLL
    if (temp->prev) temp->prev->next = NULL;
    tail = temp->prev;
    if (head == temp) head = NULL;

    // Remove from hash chain
    unsigned int hash_idx = hash_url(temp->url);
    cache* curr = hash_table[hash_idx];
    cache* prev = NULL;
    while (curr != NULL) {
        if (curr == temp) {
            if (prev) prev->hash_next = curr->hash_next;
            else      hash_table[hash_idx] = curr->hash_next;
            break;
        }
        prev = curr;
        curr = curr->hash_next;
    }

    // Account for all memory used by this node
    cacheSize -= (temp->len) + sizeof(cache) + strlen(temp->url) + 1;
    free(temp->data);
    free(temp->url);
    free(temp);
}

The djb2 Hash Function

The djb2 algorithm, created by Daniel J. Bernstein, is one of the most commonly used string hashing functions. It's fast, easy to implement, and distributes keys well:

unsigned int hash_url(const char* url) {
    unsigned long hash = 5381;   // magic seed
    int c;
    while ((c = *url++)) {
        hash = ((hash << 5) + hash) + c;
        // equivalent to: hash = hash * 33 + c
        // The bit shift by 5 then adding the original (× 33)
        // is a fast multiply chosen empirically to minimize collisions
    }
    return hash % HASH_SIZE;   // fold into [0, 1023]
}

The constant 5381 and the multiply-by-33 factor were chosen empirically — they produce a good avalanche effect where similar strings (like /page1 and /page2) map to very different buckets. With 1024 buckets and well-distributed URLs, hash collisions are rare. When they do occur, they're handled by walking the hash_next chain.

Why 1024 buckets?

It's a power of two. The % HASH_SIZE operation can be optimized by the compiler to a bitwise AND (& 1023) since 1024 - 1 = 0b1111111111. This makes the modulo near-free. More buckets = fewer collisions = shorter chains, at the cost of memory.

Thread-Safety: Mutex on Every Cache Operation

The cache is a shared global. Any of the 10 threads can call find(), addCache(), or removeCache() simultaneously. Without protection, this leads to:

Torn reads — thread A reads half a pointer while thread B updates it
Double free — two threads evict the same node and both call free()
Lost insert — two threads both see a cache miss, both fetch from origin, both try to insert the same URL
Corrupted DLL — two threads call move_to_head() simultaneously on different nodes, leaving dangling pointers

Every single cache function acquires the mutex at entry and releases it at every exit path:

// Pattern used in ALL three cache functions:pthread_mutex_lock(&lock);     // ENTRY — one thread only past here

// ... critical section ...

pthread_mutex_unlock(&lock);   // EXIT (must happen at every return path)

The Thread-Safe Logger

Logging in a multi-threaded program without synchronization produces garbled output — lines from different threads interleave mid-character. The logger uses its own dedicated mutex, separate from the cache lock:

// logger.cstatic pthread_mutex_t log_lock;

void log_msg(int level, const char* msg){
    pthread_mutex_lock(&log_lock);

    time_t now = time(NULL);
    struct tm* t = localtime(&now);
    char timebuf[64];
    strftime(timebuf, sizeof(timebuf), "%Y-%m-%d %H:%M:%S", t);

    const char* level_str;
    if(level == LOG_INFO)   level_str = "INFO";
    else if(level == LOG_ERROR) level_str = "ERROR";
    else                    level_str = "DEBUG";

    printf("[%s] [%s] %s\n", timebuf, level_str, msg);

    pthread_mutex_unlock(&log_lock);
}

Using a separate mutex for logging (rather than sharing the cache lock) is intentional — logging inside a cache operation holding the cache lock, if the log lock were the same, would be a no-op. Separate locks keep concerns separated and avoid lock-order violations.

Sample log output from the proxy running:

[2025-01-15 14:32:01] [INFO ] Starting proxy server at port: 8080
[2025-01-15 14:32:05] [INFO ] Client connected PORT:54321 IP:127.0.0.1
[2025-01-15 14:32:05] [DEBUG] Thread started, semaphore value: 9
[2025-01-15 14:32:05] [INFO ] Cache MISS for URL: GET:httpbin.org:/get
[2025-01-15 14:32:05] [INFO ] Connecting to remote server httpbin.org:80
[2025-01-15 14:32:05] [INFO ] Connection to remote server successful
[2025-01-15 14:32:05] [INFO ] Response received and forwarded to client
[2025-01-15 14:32:05] [INFO ] Cache INSERT: URL=GET:httpbin.org:/get SIZE=1247
[2025-01-15 14:32:07] [INFO ] Client connected PORT:54322 IP:127.0.0.1
[2025-01-15 14:32:07] [INFO ] Cache HIT for URL: GET:httpbin.org:/get
[2025-01-15 14:32:07] [INFO ] Serving response from cache

The Proxy as a Generic Interception Box

Thanks to Abhinay Ragam (@abhinay-ragam-3104) for valuable insights into the wide range of applications of this proxy architecture.

This is the insight worth sitting with. The proxy is fundamentally a generic programmable middlebox. Everything flowing between client and server passes through code you control. The current implementation caches — but with minor modifications, the same architecture can become:

VPN / Anonymizer

Strip the X-Forwarded-For, Via, and X-Real-IP headers before forwarding. The origin server sees only the proxy's IP, not the client's. Add encryption between client and proxy using TLS (making it a forward proxy with TLS, i.e. a VPN-like setup):

// In handle_request(), add before forwarding:ParsedHeader_remove(request, "X-Forwarded-For");
ParsedHeader_remove(request, "X-Real-IP");
ParsedHeader_remove(request, "Via");
ParsedHeader_set(request, "X-Forwarded-For", "10.0.0.1"); // spoof

Rate Limiter

Maintain a hash map of IP → (request_count, window_start). In thread_fn(), before doing any work, check if the client's IP has exceeded N requests per second. If so, send 429 Too Many Requests and call sem_post() to free the slot:

// Pseudocode — rate limiter check at top of thread_fn():char client_ip[INET_ADDRSTRLEN];
// ... extract IP from client_addr ...

if (rate_limit_exceeded(client_ip)) {
    sendErrorMessage(socket, 429);
    shutdown(socket, SHUT_RDWR);
    close(socket);
    sem_post(&semaphore);
    return NULL;
}

DDoS Absorber

Combine the rate limiter with an IP blocklist. Maintain a set of banned IPs (another hash map for O(1) lookup). Connections from banned IPs are immediately dropped with close(clientSocketID) — they never even reach thread_fn(). You can also implement SYN flood protection by setting SO_REUSEPORT and distributing connections across multiple proxy processes.

Content Filter / Firewall

After parsing the URL, check it against a blocklist. If the requested host or path matches, send a 403 Forbidden and close. This is exactly how corporate content filters work:

if (is_blocked_host(request->host)) {
    sendErrorMessage(socket, 403);
    shutdown(socket, SHUT_RDWR);
    close(socket);
    sem_post(&semaphore);
    return NULL;
}

Load Balancer

Instead of connecting to the host specified in the request, maintain a pool of backend servers and implement a selection algorithm (round-robin, least-connections, weighted). Replace the single connectRemoteServer(request->host, port) call with connectRemoteServer(pick_backend(), port):

const char* backends[] = {"10.0.0.1", "10.0.0.2", "10.0.0.3"};
int rr_idx = 0;

const char* pick_backend(){
    int idx = __sync_fetch_and_add(&rr_idx, 1) % 3; // atomic
    return backends[idx];
}

Request/Response Logger (Wiretap)

Since all HTTP traffic flows through the proxy unencrypted (for non-HTTPS), you can log every request URL, response status, latency, and body size to a file or a database. This is useful for analytics, debugging, and compliance.

The Key Insight
The architecture doesn't change. socket() → bind() → listen() → accept() → thread_fn() is always the same. What changes is what you do inside thread_fn() between receiving the client's request and forwarding it (or responding directly). That's your entire design space.

Benchmarks — Proving the O(1) Claim

Claims about algorithmic complexity are easy to make. What matters is whether it shows up in actual measurement. The project includes a Google Benchmark harness in benchmarks/benchmark_cache.cpp that runs addCache() and find() in a tight loop, measures the wall-clock time per operation, and outputs statistics.

14,726 nanoseconds — v1 (linked list)
6,327 nanoseconds — v2 (hash + DLL)
57% reduction in CPU time
O(1) amortized complexity
Metric
v1 — Linked List
v2 — Hash + DLL

Lookup complexityO(N)O(1)
Eviction complexityO(N) — scan for oldestO(1) — tail pointer
Insert complexityO(1) — prependO(1) — hash + DLL head
Cache hit latency~14,726 ns~6,327 ns
Lookup structureSingly linked listHash map (djb2, 1024 buckets)
Ordering structureTime-based (time_t field)Doubly linked list (DLL)
Eviction mechanismTraverse entire list for min time_tDirect removal of tail node
Extra pointer per node1 (next)3 (next, prev, hash_next)

The benchmark setup uses a CacheFixture class (Google Benchmark's fixture pattern) to initialize the mutex and logger before each benchmark run and tear them down after. The BENCHMARK_F macro registers each function as a timed benchmark:

// Build with: make report// Requires: apt install libbenchmark-dev

BENCHMARK_F(CacheFixture, BM_FindCache)(benchmark::State& state) {
    char url[] = "http://example.com";

    for (auto _ : state) {
        benchmark::DoNotOptimize(find(url));
        // DoNotOptimize prevents the compiler from
        // eliminating the call as a dead store
    }
}

What This Project Taught

Building a proxy server from scratch in C forces you to confront every layer of networking that higher-level frameworks hide from you. You manually manage memory. You think about what happens when recv() returns less than you expected. You feel the difference between O(N) and O(1) in nanoseconds, not just in theory.

The architectural insight that sticks: a proxy is just a middlebox. The socket lifecycle, the thread pool, the request parsing loop — all of it is reusable infrastructure. The thing that makes it a caching proxy vs a rate limiter vs a VPN is three to five lines of code inside thread_fn(). Every major piece of infrastructure you use on the internet — Nginx, Cloudflare, AWS ALB — is built on exactly this pattern, just scaled to millions of connections per second.

The cache improvement from a linked list to a hash + DLL is a textbook lesson in why data structure choice matters. The algorithm didn't change — LRU is LRU. But the implementation went from O(N) to O(1) and cut latency by 57%, measurable with a benchmark, not just claimable in a README.

Source code: github.com/Kaushikmak/http_server_c
Project website: https://http-server-c.vercel.app/

Written in C11. Tested on Ubuntu 22.04 LTS. Benchmarked with Google Benchmark.