ddos-sim.com All simulations Build a test plan
Home › DDoS simulation testing › Slow read test

Layer 7 · Application · slow_read

Slow read test

The slow_read simulation opens TLS connections that make a normal request and then read the response as slowly as possible under a tiny window, so the server has to hold the response in its send buffers — the send-side mirror of Slowloris — against a domain you own.

Layer L7 Protocol HTTP/TLS Command slow_read Access Quote on request

On this page

  1. What a slow-read attack does
  2. How ddos-sim.com simulates it safely
  3. What the test exercises
  4. How to run the test
  5. Availability & limits
  6. FAQ
  7. Related simulations

What a slow-read attack does

A slow-read attack advertises a very small TCP receive window and then drains the response at a trickle. The server can only put a little data in flight before it blocks, so it must hold the rest — and the connection — open. It attacks the response and send-buffer side, the mirror image of Slowloris and RUDY attacking the request side.

How ddos-sim.com simulates it safely

ddos-sim.com completes a real TLS handshake to a single verified domain, shrinks its own receive buffer before the handshake so the advertised window stays tiny, sends a fixed request, and then reads a byte at a time within the domain’s rate and concurrency limits. The request is fixed and non-configurable.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • Send-buffer and response-buffering limits per connection
  • Per-connection memory when writes block on a slow reader
  • Whether the origin or proxy holds the whole response in memory
  • Concurrency caps that target slow or stalled clients
  • Recovery once the stalled connections disconnect

How to run a slow read test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the slow_read command to a timeline in the portal and set the rate, duration, and any concurrency limit.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a slow read test in the portal →

Availability & limits

Slow read is priced per engagement — request a quote. Verify your domain before it runs.

Frequently asked questions

Is this the same as Slowloris?

No. Slowloris and RUDY starve the request side; slow read starves the response side by refusing to receive, forcing the server to hold its send buffers and the connection open.

How small is the window?

The socket receive buffer is deliberately shrunk before the handshake so the advertised TCP window stays tiny for the whole connection.

Related simulations

Slowloris test slowloris_check Simulate a Slowloris slow-HTTP attack against a domain you own. Slow POST (RUDY) test slow_post Drip a large request body one byte at a time to tie up request readers. SSL/TLS exhaustion test tls_exhaustion_check Simulate a TLS handshake flood to expose the CPU cost of repeated negotiation.

Rehearse a slow read test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations
© 2026 ddos-sim.com · Authorized testing only. Simulations · Terms · Acceptable use · Privacy