TCP Zero-Window starvation test

What Zero-Window starvation does

When a TCP receiver advertises win 0, the sender is prohibited by the TCP standard from transmitting further payload bytes until a window update arrives. While waiting, the server must keep the full pending response in memory (the socket send buffer) and maintain active worker state. By opening thousands of zero-window connections, an attacker exhausts origin RAM and socket descriptors with minimal client bandwidth.

How ddos-simulation.com simulates it safely

ddos-simulation.com establishes real, non-spoofed TCP connections to your verified domain and precisely controls TCP window advertisement headers within configured concurrency bounds.

What the test exercises

• Origin web server write timeout enforcement (e.g. NGINX send_timeout, Apache Timeout)
• Kernel TCP socket send-buffer limits (tcp_wmem, SO_SNDBUF)
• Reverse proxy / CDN buffer offloading and backpressure isolation
• Worker thread release under zero-throughput socket holds

When to run this test

• Tuning web server and reverse proxy send timeouts.
• Validating that slow clients cannot pin database-rendered or dynamic file download workers indefinitely.

How to run the test

1. Verify domain ownership in the portal.
2. Add tcp_zero_window_starvation to your timeline with target path and concurrency.
3. Observe origin worker memory and socket table utilization in real time.

Reading the results

Resilient: The server detects stalled progress and terminates the connection cleanly when the configured send timeout expires (typically 10–30s), releasing memory.

Under strain: Worker threads remain locked indefinitely, socket buffer allocations accumulate in the kernel, and new connections are refused.

Related simulations