What is deep packet inspection?

Every packet crossing a network carries a set of nested headers. The outermost describes the link, then the IP header gives a source and destination address, then a TCP or UDP header gives a source and destination port. A plain router needs only these to do its job: read the destination, consult a table, forward. It never opens the payload, and it does not need to.

Deep packet inspection is the practice of reading past those headers into the payload — the actual bytes the application sent. A DPI engine sits inline on a link, reassembles the byte stream from the packets that make it up, and then tries to identify what protocol is being spoken and, where it can, what is being said. It is called "deep" because it goes deeper into the packet than routing requires.

• Shallow filtering blocks by address and port: "drop everything to 203.0.113.10", or "drop everything to port 1194". It is cheap, it is coarse, and it is trivially defeated by changing address or port.
• Deep inspection blocks by behaviour: "drop anything that looks like the OpenVPN handshake, wherever it is going and whatever port it is on". It costs far more to run, and changing address or port does not help.

A DPI engine rarely tries to understand a protocol in full. It looks for the cheapest signal that reliably distinguishes one protocol from another, because it has to make a decision within a few milliseconds on a link carrying millions of flows. In practice it draws on four families of signal.

Literal byte patterns

Fixed strings or structures that appear at known offsets. The first bytes of a TLS record are recognisable; so is an SSH banner, a BitTorrent handshake, or the opcode layout of an OpenVPN control packet. Matching a pattern at a known offset is close to free.

Plaintext metadata inside encrypted protocols

Encryption does not hide everything. A standard TLS handshake sends the requested hostname in the clear in the Server Name Indication field, and the server's certificate is visible on older TLS versions. This metadata is the single richest source of information a filter has about an otherwise opaque connection.

Handshake fingerprints

Even when the content is encrypted, the shape of the negotiation is not. The exact list of cipher suites a client offers, the order of TLS extensions, the sizes of the first few records — these differ between a browser, a mobile app and a VPN client, and can be hashed into a fingerprint.

Statistical and timing behaviour

Packet sizes, the ratio of upload to download, the rhythm of a connection over time. A video call, a file download and a tunnel that is carrying everything at once each have a distinguishable profile, and a classifier can be trained on it without reading a single byte of payload.

The first two are the ones that matter most in practice. They are exact, cheap, and produce very few false positives, which is why filtering systems reach for them first and why protocol designers spend most of their effort on removing them.

It is a common assumption that an encrypted connection is opaque to an observer. It is not. Encryption protects the confidentiality of the payload. It does not, on its own, hide that a connection exists, who the endpoints are, how large it is, how long it lasts, or which protocol is being spoken.

The practical consequence is that a filter does not need to decrypt anything to make a blocking decision. It needs only to decide, from the parts that were never encrypted, whether this connection belongs to a category it has been told to drop. That is a much easier problem, and it is the problem modern censorship systems are built to solve.

Once a flow is classified, the system has to act on it. The method chosen says a lot about the deployment, and it is usually possible to tell them apart from the client side.

1. Silent drop. Packets are discarded with no reply. The connection appears to hang and eventually times out. This is the most common behaviour for a filter that does not want to advertise itself.
2. Forged reset. The system injects a TCP RST packet spoofed to look as if it came from the far end. The connection dies abruptly, often after a few packets have already flowed, which is a strong tell — a genuinely unreachable server never answers at all.
3. DNS manipulation. The name lookup is answered with a wrong address, or with no address, before a connection is ever attempted. Cheap, and easily observed by comparing answers from different resolvers.
4. Throttling. The flow is allowed but rate-limited to the point of uselessness. Harder to attribute, because it is indistinguishable from ordinary congestion without careful measurement.
5. Active probing. Rather than blocking on the spot, the system records the endpoint and later connects to it itself, imitating a client, to confirm what is running there. If the server answers in a way only a proxy would, the address is added to a blocklist.

If you accept that a filter reads handshakes and metadata rather than payloads, the design goal for a tunnel changes completely. It is no longer enough to be encrypted. The connection has to avoid presenting any signal that distinguishes it from traffic the filter has decided to allow — which, on today's internet, means ordinary TLS to an ordinary web server.

This is why the protocols discussed elsewhere in this library converge on the same handful of ideas: remove protocol-specific byte patterns from the wire, make the TLS handshake fingerprint match a real browser, avoid sending a hostname that is itself a signal, and answer an unauthenticated prober exactly as a normal web server would. Each of those exists to remove one of the signals above.

It is also why no honest description of a tunnelling protocol promises to defeat DPI outright. A filter operator can always widen the policy — for example, by blocking categories of traffic by default rather than by exception — and no protocol design survives a network that simply refuses everything it cannot positively identify.