All DDoS Definitions
DDoS Testing Definition

Deep Packet Inspection (DPI)

Deep packet inspection (DPI) is the control that decides on what a packet carries, not only on where it came from and where it is going. Whether it keeps doing so at attack packet rates, rather than shedding the inspection or the traffic, is what a DDoS test measures. Unlike header-only filtering such as an ACL, which matches on address, port and protocol, DPI reads into the payload to match signatures, malformed protocol fields and abusive request patterns, so it can drop floods that look valid at the transport layer.

Deep packet inspection: read the payload, not just the header header payload GET /? x 10k incoming packet Header filter (ACL) src, port, protocol only looks valid, pass Deep inspection reads into the payload, matches an L7 flood signature, drop drop Cost of inspecting every byte DPI CPU load, near saturation DPI catches what header filtering cannot, but the inspection tier can itself become the layer of first failure. A test characterizes the packet rate where inspection cost saturates the device, and checks its false-positive rate. BlackNeuron™
Diagram: deep packet inspection reads the payload to drop a flood that passed header-only filtering, at a high CPU cost

What inspection actually requires

Reading a payload is rarely a matter of reading one packet. An HTTP request can span several TCP segments, arrive out of order, or ride inside fragmented IP datagrams, so a DPI engine has to reassemble the stream before it can match anything.

That means keeping per-flow state: a buffer and a parser position for every connection in flight. DPI is a stateful device whatever its datasheet calls it, and its flow table is a finite resource that a flood of short connections can fill.

Matching is the other half. Signature engines run multi-pattern algorithms such as Aho-Corasick, or regular-expression libraries such as Intel's Hyperscan, over every inspected byte. Cost therefore scales with bytes and with new flows, not just with packets, and some rules cost far more than others.

A rule written as a backtracking regular expression can be pushed into very slow matching by a crafted payload. That is the ReDoS problem moved onto the inspection device, where one bad rule slows every flow behind it.

Deep packet inspection: the verdict comes from the payload, not the header incoming well-formed packets payload inspection reassemble the stream, then match content service behind it clean payloads only header valid, payload clean: forwarded header valid, payload malicious: dropped BlackNeuron™
Animated deep packet inspection: packets with valid headers enter a payload-inspection gate that reassembles the stream and matches content, forwarding clean payloads to the service and dropping packets whose payload carries the attack

Where it goes blind

Most web traffic is now TLS. An inline DPI box that does not hold the keys sees the handshake and little else: the ClientHello, the server name in SNI, packet sizes and timing. TLS 1.3 encrypts the server certificate, and Encrypted Client Hello hides the server name too.

So for an HTTPS flood, the inspection that counts happens wherever TLS terminates, at a proxy or WAF, not at a network tier upstream of it. What remains visible upstream is the handshake itself, which is exactly what a JA3 or JA4 fingerprint is built from.

What a DDoS test measures

The inspection ceiling comes first, in the units that hurt. Throughput figures are usually quoted on large packets or a representative traffic mix. A flood of minimum-size packets or of short new connections raises per-byte and per-flow cost and brings the ceiling down, so a test steps packet rate and new-flow rate separately and records where inspection stops keeping up.

Then the behaviour at that ceiling, which is a configuration choice that is easy to forget. A device set to fail open, often through a hardware bypass, keeps the service reachable and stops inspecting, so attack traffic passes untouched. A device set to fail closed keeps inspecting what it can and drops the rest, legitimate traffic included.

Either can be right. What matters is knowing which one is configured before an attack decides it. The test also records the latency added per packet under load, how full the flow table runs, and whether a single expensive rule is enough to pull the ceiling down.

Where DPI sits among the other filtering layers between the internet and an origin is laid out in DDoS Protection in the Path.