[PATCH 3 of 5] HTTP/3: traffic-based flood detection

[Vladimir Homutov]

On Thu, Oct 07, 2021 at 02:36:16PM +0300, Roman Arutyunyan wrote:
> # HG changeset patch
> # User Roman Arutyunyan <arut at nginx.com>
> # Date 1633602162 -10800
> #      Thu Oct 07 13:22:42 2021 +0300
> # Branch quic
> # Node ID 31561ac584b74d29af9a442afca47821a98217b2
> # Parent  1b87f4e196cce2b7aae33a63ca6dfc857b99f2b7
> HTTP/3: traffic-based flood detection.
>
> With this patch, all traffic over HTTP/3 bidi and uni streams is counted in
> the h3c->total_bytes field, and payload traffic is counted in the
> h3c->payload_bytes field.  As long as total traffic is many times larger than
> payload traffic, we consider this to be a flood.
>
> Request header traffic is counted as if all fields are literal.  Response
> header traffic is counted as is.

[..]

this looks more complex than QUIC part, as we don't have clear
understanding what 'payload' is.

Attempt to count literal fields vs bytes leads to situations when
payload is greater than total due to en/decoding. It looks like
it doesn't harm though, as the difference is not that big and we
should not have something like zip-bomb here
(i.e. decoded payload increases greatly in length, while total is quite
small)

I'm not sure that assuming reserved frames is not a good payload
is a good idea. While we don't know what is there, RFC tells us
not assume anything about their meaning. On the other side,
we can definitely consider huge number of reserved frames as a flood,
as we don't make any progress with request as we receive them
and waste resources.

overal, it looks working, and I have no better ideas how we can improve
it.