Skip to content
DEFLECTO
Technology

Every refusal happens at the cheapest point that can make it.

Between the wire and your origin, a request passes a fixed sequence of gates. Each one can see more than the last and each one costs more to reach, so each decision is made as early as the information allows. This page is that sequence, in order.

Talk to an engineerFiltered below the socket
Request lifecycle

The path of one request.

Follow a single request from the moment it arrives to the moment your application sees it. Every stage says where it runs and what has already been spent by the time it gets to decide.

  1. Arrival

    Nearest edge location

    A request lands on the closest DEFLECTO location instead of travelling to your origin. Nothing has been decided yet. The only thing that has happened is that a flood is now spread across the network rather than converging on one address, which is what makes every decision below affordable.

    Work spent by this point

    A packet on the wire, and nothing allocated to hold it.

  2. Packet filter, in the driver

    Network driver, below the socket

    Filtering runs inside the network driver, before the kernel allocates a socket for the connection. Malformed packets, unroutable ports and unauthorised sources are discarded at the earliest point the hardware allows. They are not accepted and then rejected, they are never accepted. Most of a volumetric flood ends here, in the part of the machine that has no idea what a request is.

    Almost everything sold as DDoS protection filters above the socket, where the kernel has already done the accounting. Moving that decision into the driver is the single largest structural difference in this product.

    Work spent by this point

    No socket, no buffer, no application thread. This is the cheapest refusal that exists, and it is why absorbing an attack does not slow down the traffic you care about.

  3. Connection admission

    Before the TLS handshake

    Whatever survives the filter asks for a connection, and that request is judged on its own: concurrency per source, new connections per second, and a handshake budget. All of it is applied before any key exchange begins, because a handshake is the most expensive thing you can be talked into doing for a stranger.

    Work spent by this point

    A socket and a decision. No key exchange, no session state, no certificate work.

  4. TLS termination

    Edge, session established

    The session is terminated at the edge, with certificates issued and renewed for you. This stage refuses nothing on its own. It is worth naming because it is the point where a stranger stops being cheap: asymmetric crypto is real CPU, spent before a single byte of the request has been read.

    Work spent by this point

    Key exchange and session setup, committed on behalf of a client nobody has vouched for yet.

  5. Inspection and scoring

    Proxy, request fully parsed

    Now the request can be read. Heuristics, signatures and behavioural analysis combine into an anomaly score rather than a single verdict, so an unusual request and an obviously hostile one are not treated as the same event. Body size, header count, request shape and rate per route are all enforced here.

    Work spent by this point

    Headers and body parsed, signatures matched, behaviour compared against what this client did a moment ago.

  6. Challenge decision

    Proxy, before forwarding

    A score in the middle is not a reason to block someone, it is a reason to make them pay. Suspicious clients are handed a proof-of-work puzzle. A real visitor solves it invisibly, inside a page that is already loading. An attacker pays CPU on every single request, which is precisely the part of a flood that used to be free. Solve it once and a clearance carries the rest of the session, so nobody is asked twice.

    A challenged request is never metered. Quota counts legitimate requests forwarded to your origin, so traffic that is challenged, refused or dropped costs you nothing at all.

    Work spent by this point

    Everything above, plus a puzzle issued and verified. Still cheaper than waking a worker on your side of the network.

  7. Forward to origin

    Protected path to your infrastructure

    What is left is forwarded over the protected path. Your origin address is never published and never appears in a response, so the only route to your infrastructure runs through gates that have already made six decisions about this request.

    Work spent by this point

    Your bandwidth, your workers, your database. The most expensive outcome on this page, and the only one on your invoice.

Refused in the driver

Nearly free. Nothing was allocated, so a flood competes for none of the resources your visitors need. Capacity spent on an attack here is capacity you never notice.

Refused after TLS

Real work, already spent: a key exchange, a parse, a score. The edge absorbs that cost so your origin does not, and it is the reason the two cheaper gates run first.

Delivered to your origin

The expensive outcome, deliberately made the last one. It is also the only outcome that counts against your plan, which puts our incentive and yours on the same side.

Architecture

The attack stops at the edge. You stay at the centre.

Your infrastructure sits behind the network, not in front of it. Hostile traffic is absorbed and dispersed across dozens of locations, while legitimate users pass through to you without interruption.

  • Your origin address stays hidden behind the network.
  • Per-tenant rate and concurrency ceilings, applied at the edge.
  • Automatic failover between locations, with no change on your side.
Your origin
Hostile traffic, absorbed and filtered at the edge
Legitimate traffic, forwarded with minimal added latency
DEFLECTO network, distributed filtering across every location
Enforcement

What is actually applied to a client.

Limits are described rather than quoted. Defaults move to fit the traffic shape of the service behind them, so a figure printed here would be right for one tenant and wrong for everyone else.

Packet validity

Driver

Malformed frames, unroutable ports and unauthorised sources discarded before a socket is allocated.

Concurrent connections

Admission

A ceiling per source address. Reached, and further connections are refused without a handshake.

New connections per second

Admission

Sustained rate with a short burst allowance, so a page that opens several sockets at once is not punished for it.

TLS handshakes

Admission

Budgeted per source. Renegotiation abuse is refused before key exchange, the only point at which refusing it is cheap.

Request rate

Inspection

Per client and per route. A login endpoint and a static asset do not get the same allowance.

Request body size

Inspection

Capped by default, raised per route where uploads genuinely need the room.

Headers

Inspection

Count and total size both bounded. An oversized header set is refused before parsing continues.

Slow requests

Inspection

Read and write timeouts close connections that trickle instead of transfer.

Challenge difficulty

Challenge

Scales with current load and with the client's own recent behaviour. A quiet visitor is barely touched.

Clearance lifetime

Challenge

A solved challenge carries for the session rather than for a single request.

Transport

TCP
Terminated at the edge. Admission ceilings apply before any payload is read.
UDP
Filtered in the driver. Reflection and amplification sources are discarded without a socket.
HTTP and HTTPS
Fully proxied: TLS terminated, requests parsed, scored and challenged where the score calls for it.
DNS
Protected as a service in its own right, with query filtering ahead of the resolver.
GRE
Tunnel for returning clean traffic to your network where a proxy path is not appropriate.
IPsec
Encrypted transport for the protected path when it has to cross a network you do not control.

Onboarding

By DNS

Point a hostname at the edge. Cutting over takes minutes and cutting back takes the same, with no change to your application.

By BGP

We announce your prefix and take delivery of the whole network, for when the thing being protected is not a hostname.

Next step

The parts that do not fit on one page.

How the driver filter is deployed, how challenge difficulty is tuned against live load, how routing and failover behave when a location goes away, and what cutting over looks like for your stack. Ask, and an engineer answers rather than a form.